Re: [PATCH v9 0/6] drm/i915/dp: Support for DP YCbCr4:2:0 outputs
On Tue, 21 May 2019, Gwan-gyeong Mun wrote: > On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need > to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP. > In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0 > to MSA and VSC SDP. > And Link M/N values are calculated and applied based on the Full Clock > forYCbCr420. > The Bit per Pixel needs to be adjusted for YUV420 mode as it requires only > half of the RGB case. > - Link M/N values are calculated and applied based on the Full Clock > - Data M/N values needs to be calculated considering the data is half >due to subsampling > > These patches add a VSC structure for handling Pixel Encoding/Colorimetry > Formats and program YCBCR 4:2:0 to MSA and VSC SDP. And it changes a link > bandwidth computation for DP. Thanks for the patches, pushed to dinq with Laurent's and Maarten's acks to queue patch 2 via drm-intel. 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 5/6] dt-bindings: Add ANX6345 DP/eDP transmitter binding
Hi Torsten,
Thank you for the patch.
On Thu, May 23, 2019 at 08:54:00AM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng
>
> The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed
> for portable devices.
>
> Add a binding document for it.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Vasily Khoruzhick
> Reviewed-by: Rob Herring
> Signed-off-by: Torsten Duwe
Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/anx6345.txt | 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx6345.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt
> b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
> new file mode 100644
> index ..e79a11348d11
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
> @@ -0,0 +1,56 @@
> +Analogix ANX6345 eDP Transmitter
> +
> +
> +The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for
> +portable devices.
> +
> +Required properties:
> +
> + - compatible: "analogix,anx6345"
> + - reg : I2C address of the device
> + - reset-gpios : Which GPIO to use for reset
> + - dvdd12-supply : Regulator for 1.2V digital core power.
> + - dvdd25-supply : Regulator for 2.5V digital core power.
> +
> +Optional properties:
> +
> + - Video ports for RGB input and eDP output using the DT bindings
> + defined in [1]
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +anx6345: anx6345@38 {
> + compatible = "analogix,anx6345";
> + reg = <0x38>;
> + reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
> + dvdd25-supply = <®_dldo2>;
> + dvdd12-supply = <®_fldo1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + anx6345_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + anx6345_in_tcon0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_out_anx6345>;
> + };
> + };
> +
> + anx6345_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + anx6345_out_panel: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&panel_in_edp>;
> + };
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
Re: [PATCH 3/6] drm/bridge: extract some Analogix I2C DP common code
On Thu, May 23, 2019 at 2:54 PM Torsten Duwe wrote: > > From: Icenowy Zheng > > Some code can be shared within different DP bridges by Analogix. > > Extract them to a new module. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Vasily Khoruzhick > Signed-off-by: Torsten Duwe > --- > drivers/gpu/drm/bridge/analogix/Kconfig| 4 + > drivers/gpu/drm/bridge/analogix/Makefile | 2 + > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +- > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c| 169 > + > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 2 + > 5 files changed, 178 insertions(+), 145 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > ... > static int anx78xx_set_hpd(struct anx78xx *anx78xx) > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > new file mode 100644 > index ..9cb30962032e > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > @@ -0,0 +1,169 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright(c) 2017 Icenowy Zheng > + * > + * Based on analogix-anx78xx.c, which is: > + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved. If this was simple code movement, then the original copyright still applies. A different copyright notice should not be used. I suppose the same applies to the module author. ChenYu
Re: [PATCH 4/6] drm/bridge: Add Analogix anx6345 support
Hi Torsten,
Thank you for the patch.
On Thu, May 23, 2019 at 08:53:56AM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng
>
> The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
> for portable devices. This driver adds initial support for RGB to eDP
> mode, without HPD and interrupts.
>
> This is a configuration usually seen in eDP applications.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Vasily Khoruzhick
> Signed-off-by: Torsten Duwe
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig| 11 +
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 808
> +
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c| 2 +-
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 8 +
> .../drm/bridge/analogix/analogix-i2c-txcommon.h| 3 +
> 6 files changed, 832 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index ed2d05c12546..3c6ec535d361 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,3 +1,14 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +config DRM_ANALOGIX_ANX6345
> + tristate "Analogix ANX6345 bridge"
> + select DRM_ANALOGIX_DP_I2C
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> + ANX6345 is an ultra-low Full-HD DisplayPort/eDP
> + transmitter designed for portable devices. The
> + ANX6345 transforms the LVTTL RGB output of an
> + application processor to eDP or DisplayPort.
> +
> config DRM_ANALOGIX_ANX78XX
> tristate "Analogix ANX78XX bridge"
> select DRM_ANALOGIX_DP_I2C
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 2d523b67487d..12fed7b04e1e 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> analogix_dp_i2c-objs := analogix-i2c-dptx.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> obj-$(CONFIG_DRM_ANALOGIX_DP_I2C) += analogix_dp_i2c.o
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> new file mode 100644
> index ..36f38a9f042a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -0,0 +1,810 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(c) Icenowy Zheng
> + * Based on analogix-anx6345.c, which is:
> + * Copyright(c) 2016, Analogix Semiconductor.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Could you please sort the includes alphabetically to make it easer to
locate duplicates ?
> +
> +#include "analogix-i2c-dptx.h"
> +#include "analogix-i2c-txcommon.h"
> +
> +#define I2C_NUM_ADDRESSES2
> +#define I2C_IDX_DPTX 0
> +#define I2C_IDX_TXCOM1
> +
> +#define POLL_DELAY 5 /* us */
> +#define POLL_TIMEOUT 500 /* us */
> +
> +static const u8 anx6345_i2c_addresses[] = {
> + [I2C_IDX_DPTX] = ANALOGIX_I2C_DPTX,
> + [I2C_IDX_TXCOM] = ANALOGIX_I2C_TXCOMMON,
> +};
> +
> +struct anx6345 {
> + struct drm_dp_aux aux;
> + struct drm_bridge bridge;
> + struct i2c_client *client;
> + struct edid *edid;
> + struct drm_connector connector;
> + struct drm_dp_link link;
> + struct drm_panel *panel;
> + struct regulator *dvdd12;
> + struct regulator *dvdd25;
> + struct gpio_desc *gpiod_reset;
> + struct mutex lock;
Please add a comment to explain what the lock protects.
> +
> + /*
> + * I2C Slave addresses of ANX6345 are mapped as DPTX and SYS
> + */
This can hold on a single line comment.
> + struct i2c_client *i2c_clients[I2C_NUM_ADDRESSES];
> + struct regmap *map[I2C_NUM_ADDRESSES];
> +
> + u16 chipid;
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
> +
> + bool powered;
> +};
> +
> +static inline struct anx6345 *connector_to_anx6345(struct drm_connector *c)
> +{
> + return container_of(c, struct anx6345, connector);
> +}
> +
> +static inline struct anx6345 *bridge_to_anx6345(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct anx6345, bridge);
> +}
> +
> +static int anx6345_set_bits(struct regmap *map, u8 reg, u8 mask)
> +{
> + return regmap_update_bits(map, reg, mask, mask);
> +}
> +
> +static int anx6345_clear_bits(struct regmap *m
Re: [PATCH 3/6] drm/bridge: extract some Analogix I2C DP common code
On Thu, May 23, 2019 at 03:40:25PM +0800, Chen-Yu Tsai wrote: > On Thu, May 23, 2019 at 2:54 PM Torsten Duwe wrote: > > > > From: Icenowy Zheng > > > > Some code can be shared within different DP bridges by Analogix. > > > > Extract them to a new module. > > > > Signed-off-by: Icenowy Zheng > > Signed-off-by: Vasily Khoruzhick > > Signed-off-by: Torsten Duwe > > --- > > drivers/gpu/drm/bridge/analogix/Kconfig| 4 + > > drivers/gpu/drm/bridge/analogix/Makefile | 2 + > > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +- > > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c| 169 > > + > > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 2 + > > 5 files changed, 178 insertions(+), 145 deletions(-) > > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > > > > ... > > > static int anx78xx_set_hpd(struct anx78xx *anx78xx) > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > > b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > > new file mode 100644 > > index ..9cb30962032e > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > > @@ -0,0 +1,169 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright(c) 2017 Icenowy Zheng > > + * > > + * Based on analogix-anx78xx.c, which is: > > + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved. > > If this was simple code movement, then the original copyright still applies. > A different copyright notice should not be used. I suppose the same applies > to the module author. And likely to patch 2/6 too. -- Regards, Laurent Pinchart
Re: [PATCH 3/6] drm/bridge: extract some Analogix I2C DP common code
Hi Torsten,
Thank you for the patch.
On Thu, May 23, 2019 at 08:53:52AM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng
>
> Some code can be shared within different DP bridges by Analogix.
>
> Extract them to a new module.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Vasily Khoruzhick
> Signed-off-by: Torsten Duwe
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig| 4 +
> drivers/gpu/drm/bridge/analogix/Makefile | 2 +
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +-
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c| 169
> +
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 2 +
> 5 files changed, 178 insertions(+), 145 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index c4d343a2f04d..ed2d05c12546 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config DRM_ANALOGIX_ANX78XX
> tristate "Analogix ANX78XX bridge"
> + select DRM_ANALOGIX_DP_I2C
> select DRM_KMS_HELPER
> select REGMAP_I2C
> help
> @@ -11,3 +12,6 @@ config DRM_ANALOGIX_ANX78XX
> config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> +
> +config DRM_ANALOGIX_DP_I2C
> + tristate
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index ce1687e60975..2d523b67487d 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,4 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> +analogix_dp_i2c-objs := analogix-i2c-dptx.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> +obj-$(CONFIG_DRM_ANALOGIX_DP_I2C) += analogix_dp_i2c.o
Do we need a separate module for this, or could it be included in
analogix_dp ?
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index f8433c93f463..bf8291d0ddd0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -45,8 +45,6 @@
> #define I2C_IDX_RX_P14
>
> #define XTAL_CLK 270 /* 27M */
> -#define AUX_CH_BUFFER_SIZE 16
> -#define AUX_WAIT_TIMEOUT_MS 15
>
> static const u8 anx78xx_i2c_addresses[] = {
> [I2C_IDX_TX_P0] = TX_P0,
> @@ -109,153 +107,11 @@ static int anx78xx_clear_bits(struct regmap *map, u8
> reg, u8 mask)
> return regmap_update_bits(map, reg, mask, 0);
> }
>
> -static bool anx78xx_aux_op_finished(struct anx78xx *anx78xx)
> -{
> - unsigned int value;
> - int err;
> -
> - err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL2_REG,
> - &value);
> - if (err < 0)
> - return false;
> -
> - return (value & SP_AUX_EN) == 0;
> -}
> -
> -static int anx78xx_aux_wait(struct anx78xx *anx78xx)
> -{
> - unsigned long timeout;
> - unsigned int status;
> - int err;
> -
> - timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1;
> -
> - while (!anx78xx_aux_op_finished(anx78xx)) {
> - if (time_after(jiffies, timeout)) {
> - if (!anx78xx_aux_op_finished(anx78xx)) {
> - DRM_ERROR("Timed out waiting AUX to finish\n");
> - return -ETIMEDOUT;
> - }
> -
> - break;
> - }
> -
> - usleep_range(1000, 2000);
> - }
> -
> - /* Read the AUX channel access status */
> - err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_CH_STATUS_REG,
> - &status);
> - if (err < 0) {
> - DRM_ERROR("Failed to read from AUX channel: %d\n", err);
> - return err;
> - }
> -
> - if (status & SP_AUX_STATUS) {
> - DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n",
> - status);
> - return -ETIMEDOUT;
> - }
> -
> - return 0;
> -}
> -
> -static int anx78xx_aux_address(struct anx78xx *anx78xx, unsigned int addr)
> -{
> - int err;
> -
> - err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_7_0_REG,
> -addr & 0xff);
> - if (err)
> - return err;
> -
> - err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_15_8_REG,
> -(addr & 0xff00) >> 8);
> - if (err)
> - return err;
> -
> - /*
> - * DP AUX CH Address Register #2, only update bits[3:0]
> - * [7:4] RESERVED
> - * [3:0] AUX_ADDR[19:16], Register control AUX CH address.
> - */
> - err = regmap_upd
Re: [v11 00/12] Add HDR Metadata Parsing and handling in DRM layer
On Wed, 22 May 2019, Ville Syrjälä wrote: > Pushed the core/etc. bits to drm-misc-next so that other drivers > can base their work on that. We'll need a backmerge to get the > i915 stuff in via dinq. To avoid any confusion, drm-misc-next needs to get merged to drm-next, which then needs to be backmerged to drm-intel-next-queued. We don't do merges from drm-misc-next to drm-intel-next-queued directly. 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: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Stephen,
On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> between commit:
>
> 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
>
> from Linus' tree and commits:
>
> b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> S9700RTWV43TR-01B")
> fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
>
> from the drm-misc tree.
>
> I fixed it up (I deleted the file and added the patch 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
>
> From: Stephen Rothwell
> Date: Tue, 21 May 2019 10:48:36 +1000
> Subject: [PATCH] dt-bindings: fix up for vendor prefixes file conversion
>
> Signed-off-by: Stephen Rothwell
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 83ca4816a78b..749e3c3843d0 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -287,6 +287,8 @@ patternProperties:
> description: Everest Semiconductor Co. Ltd.
>"^everspin,.*":
> description: Everspin Technologies, Inc.
> + "^evervision,.*":
> +description: Evervision Electronics Co. Ltd.
>"^exar,.*":
> description: Exar Corporation
>"^excito,.*":
> @@ -851,6 +853,8 @@ patternProperties:
> description: Shenzhen Techstar Electronics Co., Ltd.
>"^terasic,.*":
> description: Terasic Inc.
> + "^tfc,.*":
> +description: Three Five Corp
>"^thine,.*":
> description: THine Electronics, Inc.
>"^ti,.*":
> @@ -925,6 +929,8 @@ patternProperties:
> description: Voipac Technologies s.r.o.
>"^vot,.*":
> description: Vision Optical Technology Co., Ltd.
> + "^vxt,.*"
> +description: VXT Ltd
I'm not sure whether or not you can change it, but this breaks the
users of that file.
What you want is:
- "^vxt,.*"
+ "^vxt,.*:"
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
RE: [PATCH 10/10] drm/amdgpu: stop removing BOs from the LRU v3
Hi, Christian
Thanks for you patch .Those patches can fix amdgpu bo pinned failed issue
during perform dm_plane_helper_prepare_fb
and Abaqus performance seems improved.
But there some error message can be observer. Do we need drop
amdgpu_vm_validate_pt_bos() error message
and other warning debug info .
[ 1910.674541] Call Trace:
[ 1910.676944] [] dump_stack+0x19/0x1b
[ 1910.682236] [] __warn+0xd8/0x100
[ 1910.687195] [] warn_slowpath_null+0x1d/0x20
[ 1910.693167] [] amdgpu_bo_move+0x169/0x1c0 [amdgpu]
[ 1910.699719] [] ttm_bo_handle_move_mem+0x26b/0x5d0 [amdttm]
[ 1910.706976] [] ttm_bo_evict+0x147/0x3b0 [amdttm]
[ 1910.713358] [] ? drm_mm_insert_node_in_range+0x299/0x4d0
[drm]
[ 1910.720881] [] ?
_kcl_reservation_object_reserve_shared+0xfe/0x1a0 [amdkcl]
[ 1910.729710] [] ttm_mem_evict_first+0x29e/0x3a0 [amdttm]
[ 1910.736705] [] amdttm_bo_mem_space+0x1ae/0x300 [amdttm]
[ 1910.743696] [] amdttm_bo_validate+0xc4/0x140 [amdttm]
[ 1910.750529] [] amdgpu_cs_bo_validate+0xa5/0x220 [amdgpu]
[ 1910.757625] [] amdgpu_cs_validate+0x47/0x2e0 [amdgpu]
[ 1910.764463] [] ? amdgpu_cs_bo_validate+0x220/0x220
[amdgpu]
[ 1910.771736] [] amdgpu_vm_validate_pt_bos+0x92/0x140
[amdgpu]
[ 1910.779248] [] amdgpu_cs_ioctl+0x18a7/0x1d50 [amdgpu]
[ 1910.785992] [] ? amdgpu_cs_find_mapping+0x120/0x120
[amdgpu]
[ 1910.793486] [] drm_ioctl_kernel+0x6c/0xb0 [drm]
[ 1910.799777] [] drm_ioctl+0x1e7/0x420 [drm]
[ 1910.805643] [] ? amdgpu_cs_find_mapping+0x120/0x120
[amdgpu]
[ 1910.813090] [] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu]
[ 1910.819639] [] do_vfs_ioctl+0x3a0/0x5a0
[ 1910.825217] [] ? __schedule+0x13a/0x890
[ 1910.830795] [] SyS_ioctl+0xa1/0xc0
[ 1910.835943] [] system_call_fastpath+0x22/0x27
[ 1910.842048] ---[ end trace a5c00b151c061d53 ]---
[ 1910.846814] [TTM] Buffer eviction failed
[ 1910.850838] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR*
amdgpu_vm_validate_pt_bos() failed.
[ 1910.858905] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to process the
buffer list -22!
...
Thanks,
Prike
-Original Message-
From: Christian König
Sent: Wednesday, May 22, 2019 9:00 PM
To: Olsak, Marek ; Zhou, David(ChunMing)
; Liang, Prike ;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: [PATCH 10/10] drm/amdgpu: stop removing BOs from the LRU v3
[CAUTION: External Email]
This avoids OOM situations when we have lots of threads submitting at the same
time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 20f2955d2a55..3e2da24cd17a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -648,7 +648,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
}
r = ttm_eu_reserve_buffers(&p->ticket, &p->validated, true,
- &duplicates, true);
+ &duplicates, false);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
DRM_ERROR("ttm_eu_reserve_buffers failed.\n"); diff
--git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 06f83cac0d3a..f660628e6af9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -79,7 +79,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
list_add(&csa_tv.head, &list);
amdgpu_vm_get_pd_bo(vm, &list, &pd);
- r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, true);
+ r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, false);
if (r) {
DRM_ERROR("failed to reserve CSA,PD BOs: err=%d\n", r);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index d513a5ad03dd..ed25a4e14404 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -171,7 +171,7 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
amdgpu_vm_get_pd_bo(vm, &list, &vm_pd);
- r = ttm_eu_reserve_buffers(&ticket, &list, false, &duplicates, true);
+ r = ttm_eu_reserve_buffers(&ticket, &list, false, &duplicates,
+ false);
if (r) {
dev_err(adev->dev, "leaking bo va because "
"we fail to reserve bo (%d)\n", r); @@ -608,7 +608,7 @@
int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
amdgpu_vm_get_pd_bo(&fpriv->vm, &list, &vm_pd);
- r = ttm_eu_reserve_buffers(&ticket, &list, true, &duplicates, true);
+ r = ttm_eu_reserve_buffers(&ticket, &list, tru
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Wed, May 22, 2019 at 02:38:48PM -0700, Brendan Higgins wrote: > +Bjorn Helgaas > > On Wed, May 15, 2019 at 12:41 AM Daniel Vetter wrote: > > > > On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote: > > > On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote: > > > > On Tue, May 14, 2019 at 8:04 AM Brendan Higgins > > > > wrote: > > > > > > > > > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote: > > > > > > On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote: > > > > > > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > > > > > > > > However, the reply is incorrect. Kselftest in-kernel tests > > > > > > > > (which > > > > > > > > is the context here) can be configured as built in instead of as > > > > > > > > a module, and built in a UML kernel. The UML kernel can boot, > > > > > > > > running the in-kernel tests before UML attempts to invoke the > > > > > > > > init process. > > > > > > > > > > > > > > Um, Citation needed? > > > > > > > > > > > > > > I don't see any evidence for this in the kselftest documentation, > > > > > > > nor > > > > > > > do I see any evidence of this in the kselftest Makefiles. > > > > > > > > > > > > > > There exists test modules in the kernel that run before the init > > > > > > > scripts run --- but that's not strictly speaking part of > > > > > > > kselftests, > > > > > > > and do not have any kind of infrastructure. As noted, the > > > > > > > kselftests_harness header file fundamentally assumes that you are > > > > > > > running test code in userspace. > > > > > > > > > > > > Yeah I really like the "no userspace required at all" design of > > > > > > kunit, > > > > > > while still collecting results in a well-defined way (unless the > > > > > > current > > > > > > self-test that just run when you load the module, with maybe some > > > > > > kselftest ad-hoc wrapper around to collect the results). > > > > > > > > > > > > What I want to do long-term is to run these kernel unit tests as > > > > > > part of > > > > > > the build-testing, most likely in gitlab (sooner or later, for > > > > > > drm.git > > > > > > > > > > Totally! This is part of the reason I have been insisting on a minimum > > > > > of UML compatibility for all unit tests. If you can suffiently > > > > > constrain > > > > > the environment that is required for tests to run in, it makes it much > > > > > easier not only for a human to run your tests, but it also makes it a > > > > > lot easier for an automated service to be able to run your tests. > > > > > > > > > > I actually have a prototype presubmit already working on my > > > > > "stable/non-upstream" branch. You can checkout what presubmit results > > > > > look like here[1][2]. > > > > > > > > ug gerrit :-) > > > > > > Yeah, yeah, I know, but it is a lot easier for me to get a project set > > > up here using Gerrit, when we already use that for a lot of other > > > projects. > > > > > > Also, Gerrit has gotten a lot better over the last two years or so. Two > > > years ago, I wouldn't touch it with a ten foot pole. It's not so bad > > > anymore, at least if you are used to using a web UI to review code. > > > > I was somewhat joking, I'm just not used to gerrit ... And seems to indeed > > be a lot more polished than last time I looked at it seriously. > > I mean, it is still not perfect, but I think it has finally gotten to > the point where I prefer it over reviewing by email for high context > patches where you don't expect a lot of deep discussion. > > Still not great for patches where you want to have a lot of discussion. > > > > > > > only ofc). So that people get their pull requests (and patch > > > > > > series, we > > > > > > have some ideas to tie this into patchwork) automatically tested > > > > > > for this > > > > > > > > > > Might that be Snowpatch[3]? I talked to Russell, the creator of > > > > > Snowpatch, > > > > > and he seemed pretty open to collaboration. > > > > > > > > > > Before I heard about Snowpatch, I had an intern write a translation > > > > > layer that made Prow (the presubmit service that I used in the > > > > > prototype > > > > > above) work with LKML[4]. > > > > > > > > There's about 3-4 forks/clones of patchwork. snowpatch is one, we have > > > > a different one on freedesktop.org. It's a bit a mess :-/ > > I think Snowpatch is an ozlabs project; at least the maintainer works at IBM. > > Patchwork originally was a ozlabs project, right? So there's two patchworks (snowpatch makes the 3rd): the one on freedesktop is another fork. > Has any discussion taken place trying to consolidate some of the forks? Yup, but didn't lead anywhere unfortunately :-/ At least between patchwork and patchwork-fdo, I think snowpatch happened in parallel and once it was done it's kinda too late. The trouble is that they all have slightly different REST api and functionality, so for CI integration you can't just switch one for the other. > Presubmit clearly
Re: [Intel-gfx] [v11 00/12] Add HDR Metadata Parsing and handling in DRM layer
On Thu, May 23, 2019 at 11:09:41AM +0300, Jani Nikula wrote: > On Wed, 22 May 2019, Ville Syrjälä wrote: > > Pushed the core/etc. bits to drm-misc-next so that other drivers > > can base their work on that. We'll need a backmerge to get the > > i915 stuff in via dinq. > > To avoid any confusion, drm-misc-next needs to get merged to drm-next, > which then needs to be backmerged to drm-intel-next-queued. We don't do > merges from drm-misc-next to drm-intel-next-queued directly. Yeah, I mentioned this also on some internal thread for clarification, just to make it clear that backmerges aren't instant. There's apparently also confusing about drm-tip, seems like people didn't know that drm-tip != drm-intel.git and that stuff fromm drm-misc immediately shows up in drm-tip ... -Daniel -- 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/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently vmw_execbuf_ioctl() open-codes the permission checking,
> size
> extending and copying that is already done in core drm.
>
> Kill all the duplication, adding a few comments for clarity.
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Tested using piglit quick using execbuf versions 1 and 2.
Tested-by: Thomas Hellstrom
Reviewed-by: Thomas Hellstrom
> ---
> Thomas, VMware team,
>
> Please give this some testing on your end. I've only tested it
> against
> mesa-master.
>
> Thanks
> Emil
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 52 +
>
> 3 files changed, 23 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index d3f108f7e52d..2cb6ae219e43 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -186,7 +186,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] =
> {
> DRM_RENDER_ALLOW),
> VMW_IOCTL_DEF(VMW_REF_SURFACE, vmw_surface_reference_ioctl,
> DRM_AUTH | DRM_RENDER_ALLOW),
> - VMW_IOCTL_DEF(VMW_EXECBUF, NULL, DRM_AUTH |
> + VMW_IOCTL_DEF(VMW_EXECBUF, vmw_execbuf_ioctl, DRM_AUTH |
> DRM_RENDER_ALLOW),
> VMW_IOCTL_DEF(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
> DRM_RENDER_ALLOW),
> @@ -1140,15 +1140,7 @@ static long vmw_generic_ioctl(struct file
> *filp, unsigned int cmd,
> &vmw_ioctls[nr - DRM_COMMAND_BASE];
>
> if (nr == DRM_COMMAND_BASE + DRM_VMW_EXECBUF) {
> - ret = (long) drm_ioctl_permit(ioctl->flags,
> file_priv);
> - if (unlikely(ret != 0))
> - return ret;
> -
> - if (unlikely((cmd & (IOC_IN | IOC_OUT)) !=
> IOC_IN))
> - goto out_io_encoding;
> -
> - return (long) vmw_execbuf_ioctl(dev, arg,
> file_priv,
> - _IOC_SIZE(cmd))
> ;
> + return ioctl_func(filp, cmd, arg);
> } else if (nr == DRM_COMMAND_BASE +
> DRM_VMW_UPDATE_LAYOUT) {
> if (!drm_is_current_master(file_priv) &&
> !capable(CAP_SYS_ADMIN))
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 9be2176cc260..f5bfac85f793 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -910,8 +910,8 @@ static inline struct page *vmw_piter_page(struct
> vmw_piter *viter)
> * Command submission - vmwgfx_execbuf.c
> */
>
> -extern int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long
> data,
> - struct drm_file *file_priv, size_t size);
> +extern int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
> extern int vmw_execbuf_process(struct drm_file *file_priv,
> struct vmw_private *dev_priv,
> void __user *user_commands,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 2ff7ba04d8c8..767e2b99618d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -3977,54 +3977,40 @@ void vmw_execbuf_release_pinned_bo(struct
> vmw_private *dev_priv)
> mutex_unlock(&dev_priv->cmdbuf_mutex);
> }
>
> -int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long data,
> - struct drm_file *file_priv, size_t size)
> +int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> {
> struct vmw_private *dev_priv = vmw_priv(dev);
> - struct drm_vmw_execbuf_arg arg;
> + struct drm_vmw_execbuf_arg *arg = data;
> int ret;
> - static const size_t copy_offset[] = {
> - offsetof(struct drm_vmw_execbuf_arg, context_handle),
> - sizeof(struct drm_vmw_execbuf_arg)};
> struct dma_fence *in_fence = NULL;
>
> - if (unlikely(size < copy_offset[0])) {
> - VMW_DEBUG_USER("Invalid command size, ioctl %d\n",
> -DRM_VMW_EXECBUF);
> - return -EINVAL;
> - }
> -
> - if (copy_from_user(&arg, (void __user *) data, copy_offset[0])
> != 0)
> - return -EFAULT;
> -
> /*
>* Extend the ioctl argument while maintaining backwards
> compatibility:
> - * We take different code paths depending on the value of
> arg.version.
> + * We take different code paths depending on the value of arg-
> >version.
> + *
> + * Not
Re: [PATCH 5/6] dt-bindings: Add ANX6345 DP/eDP transmitter binding
On Thu, May 23, 2019 at 08:54:00AM +0200, Torsten Duwe wrote: > From: Icenowy Zheng > > The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed > for portable devices. > > Add a binding document for it. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Vasily Khoruzhick > Reviewed-by: Rob Herring > Signed-off-by: Torsten Duwe > --- > .../bindings/display/bridge/anx6345.txt | 56 +++ > 1 file changed, 56 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/anx6345.txt > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt > b/Documentation/devicetree/bindings/display/bridge/anx6345.txt > new file mode 100644 > index ..e79a11348d11 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt > @@ -0,0 +1,56 @@ > +Analogix ANX6345 eDP Transmitter > + > + > +The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for > +portable devices. > + > +Required properties: > + > + - compatible: "analogix,anx6345" > + - reg : I2C address of the device > + - reset-gpios : Which GPIO to use for reset > + - dvdd12-supply : Regulator for 1.2V digital core power. > + - dvdd25-supply : Regulator for 2.5V digital core power. > + > +Optional properties: > + > + - Video ports for RGB input and eDP output using the DT bindings > + defined in [1] The output node can be optional, but the input one is probably going to be needed all the time, since otherwise you won't be able to fill the output port of the upstream device in the graph. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH 10/10] drm/amdgpu: stop removing BOs from the LRU v3
Leaving BOs on the LRU is harmless. We always did this for VM page table
and per VM BOs.
The key point is that BOs which couldn't be reserved can't be evicted.
So what happened is that an application used basically all of VRAM
during CS and because of this X server couldn't pin a BO for scanout.
Now we keep the BOs on the LRU and modify TTM to block for the CS to
complete, which in turn allows the X server to pin its BO for scanout.
Christian.
Am 22.05.19 um 21:43 schrieb Kuehling, Felix:
Can you explain how this avoids OOM situations? When is it safe to leave
a reserved BO on the LRU list? Could we do the same thing in
amdgpu_amdkfd_gpuvm.c? And if we did, what would be the expected side
effects or consequences?
Thanks,
Felix
On 2019-05-22 8:59 a.m., Christian König wrote:
[CAUTION: External Email]
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 20f2955d2a55..3e2da24cd17a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -648,7 +648,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
}
r = ttm_eu_reserve_buffers(&p->ticket, &p->validated, true,
- &duplicates, true);
+ &duplicates, false);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 06f83cac0d3a..f660628e6af9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -79,7 +79,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
list_add(&csa_tv.head, &list);
amdgpu_vm_get_pd_bo(vm, &list, &pd);
- r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, true);
+ r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, false);
if (r) {
DRM_ERROR("failed to reserve CSA,PD BOs: err=%d\n", r);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index d513a5ad03dd..ed25a4e14404 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -171,7 +171,7 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
amdgpu_vm_get_pd_bo(vm, &list, &vm_pd);
- r = ttm_eu_reserve_buffers(&ticket, &list, false, &duplicates, true);
+ r = ttm_eu_reserve_buffers(&ticket, &list, false, &duplicates, false);
if (r) {
dev_err(adev->dev, "leaking bo va because "
"we fail to reserve bo (%d)\n", r);
@@ -608,7 +608,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
amdgpu_vm_get_pd_bo(&fpriv->vm, &list, &vm_pd);
- r = ttm_eu_reserve_buffers(&ticket, &list, true, &duplicates, true);
+ r = ttm_eu_reserve_buffers(&ticket, &list, true, &duplicates, false);
if (r)
goto error_unref;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index c430e8259038..d60593cc436e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -155,7 +155,7 @@ static inline int amdgpu_bo_reserve(struct amdgpu_bo *bo,
bool no_intr)
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
int r;
- r = ttm_bo_reserve(&bo->tbo, !no_intr, false, NULL);
+ r = __ttm_bo_reserve(&bo->tbo, !no_intr, false, NULL);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
dev_err(adev->dev, "%p reserve failed\n", bo);
--
2.17.1
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/ttm: Make LRU removal optional.
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
drivers/gpu/drm/qxl/qxl_release.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c| 2 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c| 20 +++
drivers/gpu/drm/virtio/virtgpu_ioctl.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 2 +-
include/drm/ttm/ttm_bo_driver.h | 5 -
include/drm/ttm/ttm_execbuf_util.h| 3 ++-
13 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index e1cae4a37113..647e18f9e136 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -574,7 +574,7 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
amdgpu_vm_get_pd_bo(vm, &ctx->list, &ctx->vm_pd[0]);
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
-false, &ctx->duplicates);
+false, &ctx->duplicates, true);
if (!ret)
ctx->reserved = true;
else {
@@ -647,7 +647,7 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
}
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
-false, &ctx->duplicates);
+false, &ctx->duplicates, true);
if (!ret)
ctx->reserved = true;
else
@@ -1800,7 +1800,8 @@ static int validate_invalid_user_pages(struct
amdkfd_process_info *process_info)
}
/* Reserve all BOs and page tables for validation */
- ret = ttm_eu_reserve_buffers(&ticket, &resv_list, false, &duplicates);
+ ret = ttm_eu_reserve_buffers(&ticket, &resv_list, false, &duplicates,
+true);
WARN(!list_empty(&duplicates), "Duplicates should be empty");
if (ret)
goto out_free;
@@ -2006,7 +2007,7 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
}
ret = ttm_eu_reserve_buffers(&ctx.ticket, &ctx.list,
-false, &duplicate_save);
+false, &duplicate_save, true);
if (ret) {
pr_debug("Memory eviction: TTM Reserve Failed. Try again\n");
goto ttm_reserve_fail;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d72cc583ebd1..fff558cf385b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -648,7 +648,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
}
r = ttm_eu_reserve_buffers(&p->ticket, &p->validated, true,
- &duplicates);
+ &duplicates, true);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 54dd02a898b9..06f83cac0d3a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -79,7 +79,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
list_add(&csa_tv.head, &list);
amdgpu_vm_get_pd_bo(vm, &list, &pd);
- r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL);
+ r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, true);
if (r) {
DRM_ERROR("failed to reserve CSA,PD BOs: err=%d\n", r);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 7b840367004c..d513a5ad03dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -171,7 +171,7 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
amdgpu_vm_get_pd_bo(vm, &list, &vm_pd);
- r = ttm_eu_reserve_buffers(&ticket, &list, false, &duplicates);
+ r = ttm_eu_reserve_buffers(&ticket, &list, false, &duplicates, true);
if (r) {
dev_err(adev->dev, "leaking bo va because "
Re: [PATCH 1/4] drm/tegra: remove irrelevant DRM_UNLOCKED flag
On Wed, May 22, 2019 at 04:46:59PM +0100, Emil Velikov wrote: > From: Emil Velikov > > DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it. > > Cc: Thierry Reding > Cc: linux-te...@vger.kernel.org > Cc: Daniel Vetter > Signed-off-by: Emil Velikov > --- > drivers/gpu/drm/tegra/drm.c | 28 ++-- > 1 file changed, 14 insertions(+), 14 deletions(-) I assume you want to take this through drm-misc? In that case: Acked-by: Thierry Reding Otherwise let me know and I'll pick it up into the Tegra tree. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Maxime,
On Thu, 23 May 2019 10:10:22 +0200 Maxime Ripard
wrote:
>
> Hi Stephen,
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
> >
> > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> >
> > from Linus' tree and commits:
> >
> > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > S9700RTWV43TR-01B")
> > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
> >
> > from the drm-misc tree.
> >
> > I fixed it up (I deleted the file and added the patch 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
> >
> > From: Stephen Rothwell
> > Date: Tue, 21 May 2019 10:48:36 +1000
> > Subject: [PATCH] dt-bindings: fix up for vendor prefixes file conversion
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > index 83ca4816a78b..749e3c3843d0 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > @@ -287,6 +287,8 @@ patternProperties:
> > description: Everest Semiconductor Co. Ltd.
> >"^everspin,.*":
> > description: Everspin Technologies, Inc.
> > + "^evervision,.*":
> > +description: Evervision Electronics Co. Ltd.
> >"^exar,.*":
> > description: Exar Corporation
> >"^excito,.*":
> > @@ -851,6 +853,8 @@ patternProperties:
> > description: Shenzhen Techstar Electronics Co., Ltd.
> >"^terasic,.*":
> > description: Terasic Inc.
> > + "^tfc,.*":
> > +description: Three Five Corp
> >"^thine,.*":
> > description: THine Electronics, Inc.
> >"^ti,.*":
> > @@ -925,6 +929,8 @@ patternProperties:
> > description: Voipac Technologies s.r.o.
> >"^vot,.*":
> > description: Vision Optical Technology Co., Ltd.
> > + "^vxt,.*"
> > +description: VXT Ltd
>
> I'm not sure whether or not you can change it, but this breaks the
> users of that file.
>
> What you want is:
>
> - "^vxt,.*"
> + "^vxt,.*:"
I have fixed my version (but I put the ':' after the '"' like the
others).
Thanks for letting me know.
--
Cheers,
Stephen Rothwell
pgp4z66cZ0pdv.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/komeda: Add writeback support
Komeda driver uses a individual component to describe the HW's writeback
caps, but drivers doesn't define a new structure and still uses the
existing "struct komeda_layer" to describe this new component.
The detailed changes as follow:
1. Initialize wb_layer according to HW and report it to CORE.
2. CORE exposes wb_layer as a resource to KMS by private_obj.
3. Report writeback supporting by add a wb_connector to KMS, and then
wb_connector will take act as a component resources user,
so the func komeda_wb_encoder_atomic_check claims komeda resources
(scaler and wb_layer) accroding to its state configuration to the
wb_connector. and the wb_state configuration will be validated on the
specific component resources to see if the caps of component can
meet the requirement of wb_connector. if not check failed.
4. Update irq_handler to notify the completion of writeback.
NOTE:
This change doesn't add scaling writeback support, that support will
be added in the future after the scaler support.
v2: Rebase
v3: Rebase and constify the d71_wb_layer_funcs
v4: Addressed Ayan's comments
Depends on:
- https://patchwork.freedesktop.org/series/59915/
Signed-off-by: James Qian Wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
.../arm/display/komeda/d71/d71_component.c| 90 -
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 15 ++
.../arm/display/komeda/komeda_framebuffer.c | 19 ++
.../gpu/drm/arm/display/komeda/komeda_kms.c | 4 +
.../gpu/drm/arm/display/komeda/komeda_kms.h | 27 +++
.../drm/arm/display/komeda/komeda_pipeline.h | 7 +
.../display/komeda/komeda_pipeline_state.c| 51 -
.../arm/display/komeda/komeda_private_obj.c | 6 +
.../arm/display/komeda/komeda_wb_connector.c | 181 ++
10 files changed, 398 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
b/drivers/gpu/drm/arm/display/komeda/Makefile
index 62bd1bff66a3..d7e29fc688c3 100644
--- a/drivers/gpu/drm/arm/display/komeda/Makefile
+++ b/drivers/gpu/drm/arm/display/komeda/Makefile
@@ -14,6 +14,7 @@ komeda-y := \
komeda_kms.o \
komeda_crtc.o \
komeda_plane.o \
+ komeda_wb_connector.o \
komeda_private_obj.o
komeda-y += \
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 6bab816ed8e7..323e5994a55c 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -288,10 +288,98 @@ static int d71_layer_init(struct d71_dev *d71,
return 0;
}
+static void d71_wb_layer_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_layer_state *st = to_layer_st(state);
+ struct drm_connector_state *conn_st = state->wb_conn->state;
+ struct drm_framebuffer *fb = conn_st->writeback_job->fb;
+ struct komeda_fb *kfb = to_kfb(fb);
+ u32 __iomem *reg = c->reg;
+ u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN;
+ int i;
+
+ for (i = 0; i < fb->format->num_planes; i++) {
+ malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_LOW,
+ lower_32_bits(st->addr[i]));
+ malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_HIGH,
+ upper_32_bits(st->addr[i]));
+
+ malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_STRIDE,
+ fb->pitches[i] & 0x);
+ }
+
+ malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
+ malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
+ malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(&state->inputs[0]));
+ malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
+}
+
+static void d71_wb_layer_dump(struct komeda_component *c, struct seq_file *sf)
+{
+ u32 v[12], i;
+
+ dump_block_header(sf, c->reg);
+
+ get_values_from_reg(c->reg, 0x80, 1, v);
+ seq_printf(sf, "LW_INPUT_ID0:\t\t0x%X\n", v[0]);
+
+ get_values_from_reg(c->reg, 0xD0, 3, v);
+ seq_printf(sf, "LW_CONTROL:\t\t0x%X\n", v[0]);
+ seq_printf(sf, "LW_PROG_LINE:\t\t0x%X\n", v[1]);
+ seq_printf(sf, "LW_FORMAT:\t\t0x%X\n", v[2]);
+
+ get_values_from_reg(c->reg, 0xE0, 1, v);
+ seq_printf(sf, "LW_IN_SIZE:\t\t0x%X\n", v[0]);
+
+ for (i = 0; i < 2; i++) {
+ get_values_from_reg(c->reg, 0x100 + i * 0x10, 3, v);
+ seq_printf(sf, "LW_P%u_PTR_LOW:\t\t0x%X\n", i, v[0]);
+ seq_printf(sf, "LW_P%u_PTR_HIGH:\t\t0x%X\n", i, v[1]);
+ seq_printf(sf, "LW_P%u_STRIDE:\t\t0x%X\n", i, v[2]);
+ }
+
+ get_values_from_reg(c->reg, 0x130, 12, v);
+ for (i = 0; i < 12; i++)
+
Re: [PATCH 01/10] drm/ttm: Make LRU removal optional.
Am 23.05.19 um 11:15 schrieb zhoucm1: On 2019年05月22日 20:59, Christian König wrote: [SNIP] @@ -203,7 +204,10 @@ void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx *ticket, reservation_object_add_shared_fence(bo->resv, fence); else reservation_object_add_excl_fence(bo->resv, fence); - ttm_bo_add_to_lru(bo); + if (list_empty(&bo->lru)) + ttm_bo_add_to_lru(bo); + else + ttm_bo_move_to_lru_tail(bo, NULL); can ttm_bo_move_to_lru_tail be moved to ttm_eu_reserve_buffers when del_lru is false? No, that won't work. The BO might have moved to another domain and when we have the ttm_bo_move_to_lru_tail() in the reservation we won't be handling this correctly. Christian. -David ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel, Two scheduling fixes for to oversaturated (media transcoding scenarios) and their dependencies. On GVT side a reset robustness fix and context state restoring fix + error path fix caught by static checker. Regards, Joonas PS. As you are aware, -rc1 caused an explosion on the CI due to the ext4 regression, which in turn let other regressions creep in momentarily. Now there is huge backlog, so the CI results are interpreted from multiple runs. I have a good confidence on the PR, so decided to send anyway. *** drm-intel-fixes-2019-05-23: - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-05-23 for you to fetch changes up to 57cb853d1d5b07ed4e4647ad61b0c16a9c21996e: Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes (2019-05-21 14:37:38 +0300) - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 Chris Wilson (5): drm/i915: Rearrange i915_scheduler.c drm/i915: Pass i915_sched_node around internally drm/i915: Bump signaler priority on adding a waiter drm/i915: Downgrade NEWCLIENT to non-preemptive drm/i915: Truly bump ready tasks ahead of busywaits Dan Carpenter (1): drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry() Joonas Lahtinen (1): Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes Weinan (1): drm/i915/gvt: emit init breadcrumb for gvt request Yan Zhao (4): drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platform drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+ drm/i915/gvt: add 0x4dfc to gen9 save-restore list drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardware drivers/gpu/drm/i915/gvt/cmd_parser.c | 14 +- drivers/gpu/drm/i915/gvt/gtt.c | 4 +- drivers/gpu/drm/i915/gvt/handlers.c | 15 -- drivers/gpu/drm/i915/gvt/mmio_context.c | 23 ++- drivers/gpu/drm/i915/gvt/scheduler.c| 23 ++- drivers/gpu/drm/i915/i915_priolist_types.h | 5 +- drivers/gpu/drm/i915/i915_request.c | 42 ++--- drivers/gpu/drm/i915/i915_scheduler.c | 255 +++- drivers/gpu/drm/i915/i915_scheduler_types.h | 3 +- drivers/gpu/drm/i915/intel_lrc.c| 2 +- drivers/gpu/drm/i915/selftests/intel_lrc.c | 12 +- 11 files changed, 202 insertions(+), 196 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/komeda: Added AFBC support for komeda driver
For supporting AFBC:
1. Check if the user requested modifier can be supported by display HW.
2. Check the obj->size with AFBC's requirement.
3. Configure HW according to the modifier (afbc features)
This patch depends on:
- https://patchwork.freedesktop.org/series/59915/
- https://patchwork.freedesktop.org/series/59000/
v2: Rebase and addressed Ayan's comments
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 39 ++
.../arm/display/komeda/komeda_format_caps.c | 53 +
.../arm/display/komeda/komeda_format_caps.h | 5 ++
.../arm/display/komeda/komeda_framebuffer.c | 75 ++-
.../arm/display/komeda/komeda_framebuffer.h | 4 +
.../gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
.../drm/arm/display/komeda/komeda_pipeline.h | 4 +
.../display/komeda/komeda_pipeline_state.c| 18 -
.../gpu/drm/arm/display/komeda/komeda_plane.c | 15 +++-
9 files changed, 210 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 323e5994a55c..5c9bc859f886 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -134,6 +134,27 @@ static u32 to_rot_ctrl(u32 rot)
return lr_ctrl;
}
+static u32 to_ad_ctrl(u64 modifier)
+{
+ u32 afbc_ctrl = AD_AEN;
+
+ if (!modifier)
+ return 0;
+
+ if ((modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) ==
+ AFBC_FORMAT_MOD_BLOCK_SIZE_32x8)
+ afbc_ctrl |= AD_WB;
+
+ if (modifier & AFBC_FORMAT_MOD_YTR)
+ afbc_ctrl |= AD_YT;
+ if (modifier & AFBC_FORMAT_MOD_SPLIT)
+ afbc_ctrl |= AD_BS;
+ if (modifier & AFBC_FORMAT_MOD_TILED)
+ afbc_ctrl |= AD_TH;
+
+ return afbc_ctrl;
+}
+
static inline u32 to_d71_input_id(struct komeda_component_output *output)
{
struct komeda_component *comp = output->component;
@@ -173,6 +194,24 @@ static void d71_layer_update(struct komeda_component *c,
fb->pitches[i] & 0x);
}
+ malidp_write32(reg, AD_CONTROL, to_ad_ctrl(fb->modifier));
+ if (fb->modifier) {
+ u64 addr;
+
+ malidp_write32(reg, LAYER_AD_H_CROP, HV_CROP(st->afbc_crop_l,
+st->afbc_crop_r));
+ malidp_write32(reg, LAYER_AD_V_CROP, HV_CROP(st->afbc_crop_t,
+st->afbc_crop_b));
+ /* afbc 1.2 wants payload, afbc 1.0/1.1 wants end_addr */
+ if (fb->modifier & AFBC_FORMAT_MOD_TILED)
+ addr = st->addr[0] + kfb->offset_payload;
+ else
+ addr = st->addr[0] + kfb->afbc_size - 1;
+
+ malidp_write32(reg, BLK_P1_PTR_LOW, lower_32_bits(addr));
+ malidp_write32(reg, BLK_P1_PTR_HIGH, upper_32_bits(addr));
+ }
+
malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
index 1e17bd6107a4..b2195142e3f3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
@@ -35,6 +35,59 @@ komeda_get_format_caps(struct komeda_format_caps_table
*table,
return NULL;
}
+/* Two assumptions
+ * 1. RGB always has YTR
+ * 2. Tiled RGB always has SC
+ */
+u64 komeda_supported_modifiers[] = {
+ /* AFBC_16x16 + features: YUV+RGB both */
+ AFBC_16x16(0),
+ /* SPARSE */
+ AFBC_16x16(_SPARSE),
+ /* YTR + (SPARSE) */
+ AFBC_16x16(_YTR | _SPARSE),
+ AFBC_16x16(_YTR),
+ /* SPLIT + SPARSE + YTR RGB only */
+ /* split mode is only allowed for sparse mode */
+ AFBC_16x16(_SPLIT | _SPARSE | _YTR),
+ /* TILED + (SPARSE) */
+ /* TILED YUV format only */
+ AFBC_16x16(_TILED | _SPARSE),
+ AFBC_16x16(_TILED),
+ /* TILED + SC + (SPLIT+SPARSE | SPARSE) + (YTR) */
+ AFBC_16x16(_TILED | _SC | _SPLIT | _SPARSE | _YTR),
+ AFBC_16x16(_TILED | _SC | _SPARSE | _YTR),
+ AFBC_16x16(_TILED | _SC | _YTR),
+ /* AFBC_32x8 + features: which are RGB formats only */
+ /* YTR + (SPARSE) */
+ AFBC_32x8(_YTR | _SPARSE),
+ AFBC_32x8(_YTR),
+ /* SPLIT + SPARSE + (YTR) */
+ /* split mode is only allowed for sparse mode */
+ AFBC_32x8(_SPLIT | _SPARSE | _YTR),
+ /* TILED + SC + (SPLIT+SPARSE | SPARSE) + YTR */
+ AFBC_32x8(_TILED | _SC | _SPLIT | _SPARSE | _YTR),
+ AFBC_32x8(_TILED | _SC | _SPARSE | _YTR),
+ AFBC_32x8(_TILED | _SC | _YTR),
+ DRM_FORMAT_MOD_LINEAR,
+ DR
Re: [PATCH] drm/cirrus: remove leftover files
On Wed, May 22, 2019 at 05:06:34PM +0200, Sam Ravnborg wrote:
> On Wed, May 22, 2019 at 12:33:07PM +0200, Gerd Hoffmann wrote:
> > cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c
> > ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm"
> > instead of "git rm" on them so they are still in present the tree.
> >
> > Signed-off-by: Gerd Hoffmann
> Reviewed-by: Sam Ravnborg
>
> Always nice with the code removal patches.
> Will you apply yourself?
Yes.
thanks,
Gerd
Re: [PATCH 2/4] drm/virtio: remove irrelevant DRM_UNLOCKED flag
On Wed, May 22, 2019 at 04:47:00PM +0100, Emil Velikov wrote: > From: Emil Velikov > > DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it. Patch applied to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 77 ++--
1 file changed, 66 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 4c6389d849ed..861facac33d4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
- struct ttm_operation_ctx *ctx, bool *locked)
+ struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
{
bool ret = false;
- *locked = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
|| !list_empty(&bo->ddestroy))
ret = true;
+ *locked = false;
+ if (busy)
+ *busy = false;
} else {
- *locked = reservation_object_trylock(bo->resv);
- ret = *locked;
+ ret = reservation_object_trylock(bo->resv);
+ *locked = ret;
+ if (busy)
+ *busy = !ret;
}
return ret;
}
+/**
+ * ttm_mem_evict_wait_busy - wait for a busy BO to become available
+ *
+ * @busy_bo: BO which couldn't be locked with trylock
+ * @ctx: operation context
+ * @ticket: acquire ticket
+ *
+ * Try to lock a busy buffer object to avoid failing eviction.
+ */
+static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
+{
+ int r;
+
+ if (!busy_bo || !ticket)
+ return -EBUSY;
+
+ if (ctx->interruptible)
+ r = reservation_object_lock_interruptible(busy_bo->resv,
+ ticket);
+ else
+ r = reservation_object_lock(busy_bo->resv, ticket);
+
+ /*
+* TODO: It would be better to keep the BO locked until allocation is at
+* least tried one more time, but that would mean a much larger rework
+* of TTM.
+*/
+ if (!r)
+ reservation_object_unlock(busy_bo->resv);
+
+ return r == -EDEADLK ? -EAGAIN : r;
+}
+
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
const struct ttm_place *place,
- struct ttm_operation_ctx *ctx)
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
{
+ struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
- struct ttm_buffer_object *bo = NULL;
bool locked = false;
unsigned i;
int ret;
@@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked))
+ bool busy;
+
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked,
+ &busy)) {
+ if (busy && !busy_bo &&
+ bo->resv->lock.ctx != ticket)
+ busy_bo = bo;
continue;
+ }
if (place && !bdev->driver->eviction_valuable(bo,
place)) {
@@ -824,8 +871,13 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
}
if (!bo) {
+ if (busy_bo)
+ ttm_bo_get(busy_bo);
spin_unlock(&glob->lru_lock);
- return -EBUSY;
+ ret = ttm_mem_evict_wait_busy(busy_bo, ctx, ticket);
If you rely on EAGAIN, why do you still try to lock busy_bo? any
negative effect if directly return EAGAIN without tring lock?
-David
+ if (busy_bo)
+ ttm_bo_put(busy_bo);
+
Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
Am 23.05.19 um 12:24 schrieb zhoucm1:
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 77 ++--
1 file changed, 66 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 4c6389d849ed..861facac33d4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object
*bo,
- struct ttm_operation_ctx *ctx, bool *locked)
+ struct ttm_operation_ctx *ctx, bool *locked,
bool *busy)
{
bool ret = false;
- *locked = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
|| !list_empty(&bo->ddestroy))
ret = true;
+ *locked = false;
+ if (busy)
+ *busy = false;
} else {
- *locked = reservation_object_trylock(bo->resv);
- ret = *locked;
+ ret = reservation_object_trylock(bo->resv);
+ *locked = ret;
+ if (busy)
+ *busy = !ret;
}
return ret;
}
+/**
+ * ttm_mem_evict_wait_busy - wait for a busy BO to become available
+ *
+ * @busy_bo: BO which couldn't be locked with trylock
+ * @ctx: operation context
+ * @ticket: acquire ticket
+ *
+ * Try to lock a busy buffer object to avoid failing eviction.
+ */
+static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
+{
+ int r;
+
+ if (!busy_bo || !ticket)
+ return -EBUSY;
+
+ if (ctx->interruptible)
+ r = reservation_object_lock_interruptible(busy_bo->resv,
+ ticket);
+ else
+ r = reservation_object_lock(busy_bo->resv, ticket);
+
+ /*
+ * TODO: It would be better to keep the BO locked until
allocation is at
+ * least tried one more time, but that would mean a much
larger rework
+ * of TTM.
+ */
+ if (!r)
+ reservation_object_unlock(busy_bo->resv);
+
+ return r == -EDEADLK ? -EAGAIN : r;
+}
+
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
const struct ttm_place *place,
- struct ttm_operation_ctx *ctx)
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
{
+ struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
- struct ttm_buffer_object *bo = NULL;
bool locked = false;
unsigned i;
int ret;
@@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct
ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx,
&locked))
+ bool busy;
+
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx,
&locked,
+ &busy)) {
+ if (busy && !busy_bo &&
+ bo->resv->lock.ctx != ticket)
+ busy_bo = bo;
continue;
+ }
if (place &&
!bdev->driver->eviction_valuable(bo,
place)) {
@@ -824,8 +871,13 @@ static int ttm_mem_evict_first(struct
ttm_bo_device *bdev,
}
if (!bo) {
+ if (busy_bo)
+ ttm_bo_get(busy_bo);
spin_unlock(&glob->lru_lock);
- return -EBUSY;
+ ret = ttm_mem_evict_wait_busy(busy_bo, ctx, ticket);
If you rely on EAGAIN, why do you still try to lock busy_bo? any
negative effect if directly return EAGAIN without tring lock?
Yeah, that would burn a lot of CPU cycles because we would essentially
busy wait for the BO to become unlocked.
When we only return in case of a deadlock the other thread can continue
with its eviction while we rea
[PATCH] drm: assure aux_dev is nonzero before using it
>From Daniel Kwon
The system was crashed due to invalid memory access while trying to access
auxiliary device.
crash> bt
PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool"
#0 [89cedd7f3868] machine_kexec at b0663674
#1 [89cedd7f38c8] __crash_kexec at b071cf62
#2 [89cedd7f3998] crash_kexec at b071d050
#3 [89cedd7f39b0] oops_end at b0d6d758
#4 [89cedd7f39d8] no_context at b0d5bcde
#5 [89cedd7f3a28] __bad_area_nosemaphore at b0d5bd75
#6 [89cedd7f3a78] bad_area at b0d5c085
#7 [89cedd7f3aa0] __do_page_fault at b0d7080c
#8 [89cedd7f3b10] do_page_fault at b0d70905
#9 [89cedd7f3b40] page_fault at b0d6c758
[exception RIP: drm_dp_aux_dev_get_by_minor+0x3d]
RIP: c0a589bd RSP: 89cedd7f3bf0 RFLAGS: 00010246
RAX: RBX: RCX: 89cedd7f3fd8
RDX: RSI: RDI: c0a613e0
RBP: 89cedd7f3bf8 R8: 89f1bcbabbd0 R9:
R10: 89f1be7a1cc0 R11: R12:
R13: 89f1b32a2830 R14: 89d18fadfa00 R15:
ORIG_RAX: CS: 0010 SS: 0018
RIP: 2b45f0d80d30 RSP: 7ffc416066a0 RFLAGS: 00010246
RAX: 0002 RBX: 56062e212d80 RCX: 7ffc41606810
RDX: RSI: 0002 RDI: 7ffc41606ec0
RBP: R8: 56062dfed229 R9: 2b45f0cdf14d
R10: 0002 R11: 0246 R12: 7ffc41606ec0
R13: 7ffc41606ed0 R14: 7ffc41606ee0 R15:
ORIG_RAX: 0002 CS: 0033 SS: 002b
It was trying to open '/dev/ipmi0', but as no entry in aux_dir, it returned
NULL from 'idr_find()'. This drm_dp_aux_dev_get_by_minor() should have done a
check on this, but had failed to do it.
/usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/include/linux/idr.h:
114
114struct idr_layer *hint = rcu_dereference_raw(idr->hint);
0xc0a58998 : mov
0x8a41(%rip),%rax# 0xc0a613e0
/usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/include/linux/idr.h:
116
116if (hint && (id & ~IDR_MASK) == hint->prefix)
117return rcu_dereference_raw(hint->ary[id & IDR_MASK]);
0xc0a5899f : test %rax,%rax
0xc0a589a2 : je
0xc0a589ac
0xc0a589a4 : mov%ebx,%edx
0xc0a589a6 : xor%dl,%dl
0xc0a589a8 : cmp(%rax),%edx
0xc0a589aa : je
0xc0a589f0
/usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/include/linux/idr.h:
119
119return idr_find_slowpath(idr, id);
0xc0a589ac : mov%ebx,%esi
0xc0a589ae : mov
$0xc0a613e0,%rdi
0xc0a589b5 : callq
0xb09771b0
0xc0a589ba : mov%rax,%rbx
/usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/arch/x86/include/asm/atomic.h:
25
25return ACCESS_ONCE((v)->counter);
0xc0a589bd : mov0x18(%rbx),%edx
crash> struct file.f_path 0x89d18fadfa00
f_path = {
mnt = 0x89f23feaa620,
dentry = 0x89f1be7a1cc0
}
crash> files -d 0x89f1be7a1cc0
DENTRY INODE SUPERBLK TYPE PATH
89f1be7a1cc0 89f1b32a2830 89d293aa8800 CHR /dev/ipmi0
crash> struct inode.i_rdev 89f1b32a2830
i_rdev = 0xf20
crash> eval (0xf & 0xf20)
hexadecimal: 0
decimal: 0
octal: 0
binary:
As the index value was 0 and aux_idr had value 0 for all, it can have value
NULL from idr_find() function, but the below function doesn't check and just
tries to use it.
crash> aux_idr
aux_idr = $8 = {
hint = 0x0,
top = 0x0,
id_free = 0x0,
layers = 0x0,
id_free_cnt = 0x0,
cur = 0x0,
lock = {
{
rlock = {
raw_lock = {
val = {
counter = 0x0
}
}
}
}
}
}
crash> edis -f drm_dp_aux_dev_get_by_minor
/usr/src/debug/kernel-3.10.0-957.12.1.el7/linux-3.10.0-957.12.1.el7.x86_64/drivers/gpu/drm/drm_dp_aux_dev.c:
57
56 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned
index)
57 {
58struct drm_dp_aux_dev *aux_dev = NULL;
59
60mutex_lock(&aux_idr_mutex);
61aux_dev = idr_find(&aux_idr, index);
62if (!kref_get_unless_zero(&aux_dev->refcount))
63
[PATCH v2 0/6] Added scaler support for komeda
This patch series added scaling and image enhancement support for komeda driver. Enabled two different scaling usage: - layer scaling: scaling a input image before composite it with others - write-back scaling: scaling the composition result and write it to memory This patchset depends on: - https://patchwork.freedesktop.org/series/59915/ - https://patchwork.freedesktop.org/series/59000/ - https://patchwork.freedesktop.org/series/59000/ v2: - Rebase and correct typos - Rename "needs_scaling" to "en_scaling" - Rename "needs_img_enhancement" to "en_img_enhancement" james qian wang (Arm Technology China) (6): drm/komeda: Attach scaler to drm as private object drm/komeda: Add the initial scaler support for CORE drm/komeda: Implement D71 scaler support drm/komeda: Add writeback scaling support drm/komeda: Add engine clock requirement check for the downscaling drm/komeda: Add image enhancement support .../arm/display/komeda/d71/d71_component.c| 177 +- .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 2 +- .../gpu/drm/arm/display/komeda/d71/d71_dev.h | 2 + .../gpu/drm/arm/display/komeda/komeda_crtc.c | 66 ++- .../gpu/drm/arm/display/komeda/komeda_kms.h | 14 +- .../drm/arm/display/komeda/komeda_pipeline.c | 14 ++ .../drm/arm/display/komeda/komeda_pipeline.h | 32 +++- .../display/komeda/komeda_pipeline_state.c| 165 +++- .../gpu/drm/arm/display/komeda/komeda_plane.c | 75 +++- .../arm/display/komeda/komeda_private_obj.c | 49 + .../arm/display/komeda/komeda_wb_connector.c | 2 + 11 files changed, 583 insertions(+), 15 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/komeda: Add the initial scaler support for CORE
This patch add the initial and necessary logic for CORE to support scaler:
- Complete the struct komeda_scaler and komeda_scaler_state for adding
the scaler specific features and capablities.
- Implement komeda_scaler_validate to check the scaler with the data flow
configurations.
- Enable scaling support for plane input path (layer input data flow).
v2: Fix a typo, and rename "needs_scaling" to "en_scaling"
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/komeda/komeda_pipeline.c | 14 +++
.../drm/arm/display/komeda/komeda_pipeline.h | 20 ++-
.../display/komeda/komeda_pipeline_state.c| 116 ++
.../gpu/drm/arm/display/komeda/komeda_plane.c | 8 ++
4 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index a130b62fa6d1..96248586b4e8 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -126,6 +126,20 @@ komeda_pipeline_get_component(struct komeda_pipeline
*pipe, int id)
return c;
}
+struct komeda_component *
+komeda_pipeline_get_first_component(struct komeda_pipeline *pipe,
+ u32 comp_mask)
+{
+ struct komeda_component *c = NULL;
+ int id;
+
+ id = find_first_bit((unsigned long *)&comp_mask, 32);
+ if (id < 32)
+ c = komeda_pipeline_get_component(pipe, id);
+
+ return c;
+}
+
/** komeda_component_add - Add a component to &komeda_pipeline */
struct komeda_component *
komeda_component_add(struct komeda_pipeline *pipe,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index fdde93bad8de..400af217ed86 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -244,11 +244,17 @@ struct komeda_layer_state {
struct komeda_scaler {
struct komeda_component base;
- /* scaler features and caps */
+ struct malidp_range hsize, vsize;
+ u32 max_upscaling;
+ u32 max_downscaling;
};
struct komeda_scaler_state {
struct komeda_component_state base;
+ u16 hsize_in, vsize_in;
+ u16 hsize_out, vsize_out;
+ u8 en_scaling : 1,
+ en_alpha : 1; /* enable alpha processing */
};
struct komeda_compiz {
@@ -307,6 +313,7 @@ struct komeda_data_flow_cfg {
u32 rot;
int blending_zorder;
u8 pixel_blend_mode, layer_alpha;
+ u8 en_scaling : 1;
};
/** struct komeda_pipeline_funcs */
@@ -407,6 +414,9 @@ void komeda_pipeline_destroy(struct komeda_dev *mdev,
int komeda_assemble_pipelines(struct komeda_dev *mdev);
struct komeda_component *
komeda_pipeline_get_component(struct komeda_pipeline *pipe, int id);
+struct komeda_component *
+komeda_pipeline_get_first_component(struct komeda_pipeline *pipe,
+ u32 comp_mask);
void komeda_pipeline_dump_register(struct komeda_pipeline *pipe,
struct seq_file *sf);
@@ -423,6 +433,14 @@ komeda_component_add(struct komeda_pipeline *pipe,
void komeda_component_destroy(struct komeda_dev *mdev,
struct komeda_component *c);
+static inline struct komeda_component *
+komeda_component_pickup_output(struct komeda_component *c, u32 avail_comps)
+{
+ u32 avail_inputs = c->supported_outputs & (avail_comps);
+
+ return komeda_pipeline_get_first_component(c->pipeline, avail_inputs);
+}
+
struct komeda_plane_state;
struct komeda_crtc_state;
struct komeda_crtc;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index db2c3d6d2a8a..a5300ef92eb7 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -249,6 +249,26 @@ komeda_component_validate_private(struct komeda_component
*c,
return err;
}
+/* Get current available scaler from the component->supported_outputs */
+static struct komeda_scaler *
+komeda_component_get_avail_scaler(struct komeda_component *c,
+ struct drm_atomic_state *state)
+{
+ struct komeda_pipeline_state *pipe_st;
+ u32 avail_scalers;
+
+ pipe_st = komeda_pipeline_get_state(c->pipeline, state);
+ if (!pipe_st)
+ return NULL;
+
+ avail_scalers = (pipe_st->active_comps & KOMEDA_PIPELINE_SCALERS) ^
+ KOMEDA_PIPELINE_SCALERS;
+
+ c = komeda_component_pickup_output(c, avail_scalers);
+
+ return to_scaler(c);
+}
+
static int
komeda_layer_check_cfg(struct komeda_layer *layer,
struct komeda_plane_state *kplane_st,
@@ -355,6 +375,98 @@ komeda_wb_layer_validate(struct komeda_layer *wb_layer,
[PATCH v2 1/6] drm/komeda: Attach scaler to drm as private object
According to the komeda pipeline configuration, attach scaler to drm as
private object.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/komeda_private_obj.c | 49 +++
1 file changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
index d53bd6c23c5d..bac90ab8fdc9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
@@ -60,6 +60,49 @@ static int komeda_layer_obj_add(struct komeda_kms_dev *kms,
return 0;
}
+static struct drm_private_state *
+komeda_scaler_atomic_duplicate_state(struct drm_private_obj *obj)
+{
+ struct komeda_scaler_state *st;
+
+ st = kmemdup(obj->state, sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return NULL;
+
+ komeda_component_state_reset(&st->base);
+ __drm_atomic_helper_private_obj_duplicate_state(obj, &st->base.obj);
+
+ return &st->base.obj;
+}
+
+static void
+komeda_scaler_atomic_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+ kfree(to_scaler_st(priv_to_comp_st(state)));
+}
+
+static const struct drm_private_state_funcs komeda_scaler_obj_funcs = {
+ .atomic_duplicate_state = komeda_scaler_atomic_duplicate_state,
+ .atomic_destroy_state = komeda_scaler_atomic_destroy_state,
+};
+
+static int komeda_scaler_obj_add(struct komeda_kms_dev *kms,
+struct komeda_scaler *scaler)
+{
+ struct komeda_scaler_state *st;
+
+ st = kzalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+
+ st->base.component = &scaler->base;
+ drm_atomic_private_obj_init(&kms->base,
+ &scaler->base.obj, &st->base.obj,
+ &komeda_scaler_obj_funcs);
+ return 0;
+}
+
static struct drm_private_state *
komeda_compiz_atomic_duplicate_state(struct drm_private_obj *obj)
{
@@ -258,6 +301,12 @@ int komeda_kms_add_private_objs(struct komeda_kms_dev *kms,
return err;
}
+ for (j = 0; j < pipe->n_scalers; j++) {
+ err = komeda_scaler_obj_add(kms, pipe->scalers[j]);
+ if (err)
+ return err;
+ }
+
err = komeda_compiz_obj_add(kms, pipe->compiz);
if (err)
return err;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/komeda: Implement D71 scaler support
1. Add scaler component and initialize it according to D71 HW.
2. Implement d71_scaler_update/disable/dump
v2:
- Correct a typo
- Constify component_funcs: d71_scaler_funcs
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 131 +-
1 file changed, 130 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 5c9bc859f886..0bf5c7baedb5 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -551,6 +551,132 @@ static int d71_compiz_init(struct d71_dev *d71,
return 0;
}
+static void d71_scaler_update_filter_lut(u32 __iomem *reg, u32 hsize_in,
+u32 vsize_in, u32 hsize_out,
+u32 vsize_out)
+{
+ u32 val = 0;
+
+ if (hsize_in <= hsize_out)
+ val |= 0x62;
+ else if (hsize_in <= (hsize_out + hsize_out / 2))
+ val |= 0x63;
+ else if (hsize_in <= hsize_out * 2)
+ val |= 0x64;
+ else if (hsize_in <= hsize_out * 2 + (hsize_out * 3) / 4)
+ val |= 0x65;
+ else
+ val |= 0x66;
+
+ if (vsize_in <= vsize_out)
+ val |= SC_VTSEL(0x6A);
+ else if (vsize_in <= (vsize_out + vsize_out / 2))
+ val |= SC_VTSEL(0x6B);
+ else if (vsize_in <= vsize_out * 2)
+ val |= SC_VTSEL(0x6C);
+ else if (vsize_in <= vsize_out * 2 + vsize_out * 3 / 4)
+ val |= SC_VTSEL(0x6D);
+ else
+ val |= SC_VTSEL(0x6E);
+
+ malidp_write32(reg, SC_COEFFTAB, val);
+}
+
+static void d71_scaler_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_scaler_state *st = to_scaler_st(state);
+ u32 __iomem *reg = c->reg;
+ u32 init_ph, delta_ph, ctrl;
+
+ d71_scaler_update_filter_lut(reg, st->hsize_in, st->vsize_in,
+st->hsize_out, st->vsize_out);
+
+ malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize_in, st->vsize_in));
+ malidp_write32(reg, SC_OUT_SIZE, HV_SIZE(st->hsize_out, st->vsize_out));
+
+ init_ph = (st->hsize_in << 15) / st->hsize_out;
+ malidp_write32(reg, SC_H_INIT_PH, init_ph);
+
+ delta_ph = (st->hsize_in << 16) / st->hsize_out;
+ malidp_write32(reg, SC_H_DELTA_PH, delta_ph);
+
+ init_ph = (st->vsize_in << 15) / st->vsize_out;
+ malidp_write32(reg, SC_V_INIT_PH, init_ph);
+
+ delta_ph = (st->vsize_in << 16) / st->vsize_out;
+ malidp_write32(reg, SC_V_DELTA_PH, delta_ph);
+
+ ctrl = 0;
+ ctrl |= st->en_scaling ? SC_CTRL_SCL : 0;
+ ctrl |= st->en_alpha ? SC_CTRL_AP : 0;
+
+ malidp_write32(reg, BLK_CONTROL, ctrl);
+ malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(&state->inputs[0]));
+}
+
+static void d71_scaler_dump(struct komeda_component *c, struct seq_file *sf)
+{
+ u32 v[9];
+
+ dump_block_header(sf, c->reg);
+
+ get_values_from_reg(c->reg, 0x80, 1, v);
+ seq_printf(sf, "SC_INPUT_ID0:\t\t0x%X\n", v[0]);
+
+ get_values_from_reg(c->reg, 0xD0, 1, v);
+ seq_printf(sf, "SC_CONTROL:\t\t0x%X\n", v[0]);
+
+ get_values_from_reg(c->reg, 0xDC, 9, v);
+ seq_printf(sf, "SC_COEFFTAB:\t\t0x%X\n", v[0]);
+ seq_printf(sf, "SC_IN_SIZE:\t\t0x%X\n", v[1]);
+ seq_printf(sf, "SC_OUT_SIZE:\t\t0x%X\n", v[2]);
+ seq_printf(sf, "SC_H_CROP:\t\t0x%X\n", v[3]);
+ seq_printf(sf, "SC_V_CROP:\t\t0x%X\n", v[4]);
+ seq_printf(sf, "SC_H_INIT_PH:\t\t0x%X\n", v[5]);
+ seq_printf(sf, "SC_H_DELTA_PH:\t\t0x%X\n", v[6]);
+ seq_printf(sf, "SC_V_INIT_PH:\t\t0x%X\n", v[7]);
+ seq_printf(sf, "SC_V_DELTA_PH:\t\t0x%X\n", v[8]);
+}
+
+static const struct komeda_component_funcs d71_scaler_funcs = {
+ .update = d71_scaler_update,
+ .disable= d71_component_disable,
+ .dump_register = d71_scaler_dump,
+};
+
+static int d71_scaler_init(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ struct komeda_component *c;
+ struct komeda_scaler *scaler;
+ u32 pipe_id, comp_id;
+
+ get_resources_id(blk->block_info, &pipe_id, &comp_id);
+
+ c = komeda_component_add(&d71->pipes[pipe_id]->base, sizeof(*scaler),
+comp_id, BLOCK_INFO_INPUT_ID(blk->block_info),
+&d71_scaler_funcs,
+1, get_valid_inputs(blk), 1, reg,
+"CU%d_SCALER%d",
+pipe_id, BLOCK_INFO_BLK_ID(blk->block_info));
+
+ if (IS_ERR(c)) {
+ DRM_ERROR("Failed to initialize scaler");
+ return PTR_ERR(c);
[PATCH v2 4/6] drm/komeda: Add writeback scaling support
1. Add scaler to writeback pipeline to enable the writeback scaling support
2. Display HW can not do upscaling for writeback, check it when validate.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/komeda/komeda_pipeline.h | 2 ++
.../display/komeda/komeda_pipeline_state.c| 36 +++
.../gpu/drm/arm/display/komeda/komeda_plane.c | 8 +
.../arm/display/komeda/komeda_wb_connector.c | 2 ++
4 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 400af217ed86..9ffe11c9f386 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -470,4 +470,6 @@ void komeda_pipeline_disable(struct komeda_pipeline *pipe,
void komeda_pipeline_update(struct komeda_pipeline *pipe,
struct drm_atomic_state *old_state);
+void komeda_complete_data_flow_cfg(struct komeda_data_flow_cfg *dflow);
+
#endif /* _KOMEDA_PIPELINE_H_*/
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index a5300ef92eb7..9f07ef65008f 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -390,6 +390,7 @@ komeda_scaler_check_cfg(struct komeda_scaler *scaler,
struct komeda_data_flow_cfg *dflow)
{
u32 hsize_in, vsize_in, hsize_out, vsize_out;
+ u32 max_upscaling;
hsize_in = dflow->in_w;
vsize_in = dflow->in_h;
@@ -408,13 +409,21 @@ komeda_scaler_check_cfg(struct komeda_scaler *scaler,
return -EINVAL;
}
- if (!scaling_ratio_valid(hsize_in, hsize_out, scaler->max_upscaling,
+ /* If input comes from compiz that means the scaling is for writeback
+* and scaler can not do upscaling for writeback
+*/
+ if (has_bit(dflow->input.component->id, KOMEDA_PIPELINE_COMPIZS))
+ max_upscaling = 1;
+ else
+ max_upscaling = scaler->max_upscaling;
+
+ if (!scaling_ratio_valid(hsize_in, hsize_out, max_upscaling,
scaler->max_downscaling)) {
DRM_DEBUG_ATOMIC("Invalid horizontal scaling ratio");
return -EINVAL;
}
- if (!scaling_ratio_valid(vsize_in, vsize_out, scaler->max_upscaling,
+ if (!scaling_ratio_valid(vsize_in, vsize_out, max_upscaling,
scaler->max_downscaling)) {
DRM_DEBUG_ATOMIC("Invalid vertical scaling ratio");
return -EINVAL;
@@ -614,6 +623,17 @@ komeda_timing_ctrlr_validate(struct komeda_timing_ctrlr
*ctrlr,
return 0;
}
+void komeda_complete_data_flow_cfg(struct komeda_data_flow_cfg *dflow)
+{
+ u32 w = dflow->in_w;
+ u32 h = dflow->in_h;
+
+ if (drm_rotation_90_or_270(dflow->rot))
+ swap(w, h);
+
+ dflow->en_scaling = (w != dflow->out_w) || (h != dflow->out_h);
+}
+
int komeda_build_layer_data_flow(struct komeda_layer *layer,
struct komeda_plane_state *kplane_st,
struct komeda_crtc_state *kcrtc_st,
@@ -641,16 +661,18 @@ int komeda_build_layer_data_flow(struct komeda_layer
*layer,
return err;
}
+/* writeback data path: compiz -> scaler -> wb_layer -> memory */
int komeda_build_wb_data_flow(struct komeda_layer *wb_layer,
struct drm_connector_state *conn_st,
struct komeda_crtc_state *kcrtc_st,
struct komeda_data_flow_cfg *dflow)
{
- if ((dflow->in_w != dflow->out_w) ||
- (dflow->in_h != dflow->out_h)) {
- DRM_DEBUG_ATOMIC("current do not support scaling writeback.\n");
- return -EINVAL;
- }
+ struct drm_connector *conn = conn_st->connector;
+ int err;
+
+ err = komeda_scaler_validate(conn, kcrtc_st, dflow);
+ if (err)
+ return err;
return komeda_wb_layer_validate(wb_layer, conn_st, dflow);
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index cd3a7172a756..97d8adb6cd2b 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -16,7 +16,6 @@ komeda_plane_init_data_flow(struct drm_plane_state *st,
struct komeda_data_flow_cfg *dflow)
{
struct drm_framebuffer *fb = st->fb;
- u32 w, h;
memset(dflow, 0, sizeof(*dflow));
@@ -37,12 +36,7 @@ komeda_plane_init_data_flow(struct drm_plane_state *st,
dflow->in_w = st->src_w >> 16;
dflow->in_h = st->src_h >> 16;
- w = dflow->in_w;
- h = dflow->in_h
[PATCH v2 5/6] drm/komeda: Add engine clock requirement check for the downscaling
For downscaling there is a restriction, the downscaling needed engine
clock can not acceed the real engine clock, and the clock requirement
mostly depend on the specific HW, to solve this problem:
1. Add a pipeline func - downscaling_clk_check for CORE to query the real
HW if downscaling can be supported.
2. Add new property clock ratio which is the ratio of:
(mclk << 32) / pxlclk
then User driver can use this ratio to do the clock check to avoid post
an invalid downscaling to kernel.
v2: Rebase and Delete debug print
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 45 +
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 2 +-
.../gpu/drm/arm/display/komeda/d71/d71_dev.h | 2 +
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 66 ++-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 8 +++
.../drm/arm/display/komeda/komeda_pipeline.h | 8 ++-
.../display/komeda/komeda_pipeline_state.c| 17 -
7 files changed, 142 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 0bf5c7baedb5..2ea282c6a156 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -677,6 +677,47 @@ static int d71_scaler_init(struct d71_dev *d71,
return 0;
}
+static int d71_downscaling_clk_check(struct komeda_pipeline *pipe,
+struct drm_display_mode *mode,
+unsigned long mclk_rate,
+struct komeda_data_flow_cfg *dflow)
+{
+ u32 h_in = dflow->in_w;
+ u32 v_in = dflow->in_h;
+ u32 v_out = dflow->out_h;
+ u64 fraction, denominator;
+
+ /* D71 downscaling must satisfy the following equation
+*
+* MCLK h_in * v_in
+* --- >= -
+* PXLCLK (h_total - (1 + 2 * v_in / v_out)) * v_out
+*
+* In only horizontal downscaling situation, the right side should be
+* multiplied by (h_total - 3) / (h_active - 3), then equation becomes
+*
+* MCLK h_in
+* --- >=
+* PXLCLK (h_active - 3)
+*
+* To avoid precision lost the equation 1 will be convert to:
+*
+* MCLK h_in * v_in
+* --- >= ---
+* PXLCLK (h_total -1 ) * v_out - 2 * v_in
+*/
+ if (v_in == v_out) {
+ fraction = h_in;
+ denominator = mode->hdisplay - 3;
+ } else {
+ fraction = h_in * v_in;
+ denominator = (mode->htotal - 1) * v_out - 2 * v_in;
+ }
+
+ return mclk_rate * denominator >= mode->clock * 1000 * fraction ?
+ 0 : -EINVAL;
+}
+
static void d71_improc_update(struct komeda_component *c,
struct komeda_component_state *state)
{
@@ -939,3 +980,7 @@ int d71_probe_block(struct d71_dev *d71,
return err;
}
+
+const struct komeda_pipeline_funcs d71_pipeline_funcs = {
+ .downscaling_clk_check = d71_downscaling_clk_check,
+};
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 3a7248d42376..1c914f8ca016 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -390,7 +390,7 @@ static int d71_enum_resources(struct komeda_dev *mdev)
for (i = 0; i < d71->num_pipelines; i++) {
pipe = komeda_pipeline_add(mdev, sizeof(struct d71_pipeline),
- NULL);
+ &d71_pipeline_funcs);
if (IS_ERR(pipe)) {
err = PTR_ERR(pipe);
goto err_cleanup;
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h
index 7465c57d9774..84f1878b647d 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h
@@ -43,6 +43,8 @@ struct d71_dev {
#define to_d71_pipeline(x) container_of(x, struct d71_pipeline, base)
+extern const struct komeda_pipeline_funcs d71_pipeline_funcs;
+
int d71_probe_block(struct d71_dev *d71,
struct block_header *blk, u32 __iomem *reg);
void d71_read_block_header(u32 __iomem *reg, struct block_header *blk);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 6712603b8c7a..24a961356cb3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -18,6 +18,22 @@
#include "komeda_dev.h
[PATCH v2 6/6] drm/komeda: Add image enhancement support
Besides scaling, Arm display scaler also can support image enhancement.
For support it, Add a new property "img_enhancement" to plane, then user
can turn on/off it by this property, and kernel follow user's requirement
to maitain the state and enable/disable the real HW image enhancement.
v2: Rebase and rename "needs_img_enhancement" to "en_img_enhancement"
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 1 +
.../gpu/drm/arm/display/komeda/komeda_kms.h | 6 +-
.../drm/arm/display/komeda/komeda_pipeline.h | 6 +-
.../display/komeda/komeda_pipeline_state.c| 6 +-
.../gpu/drm/arm/display/komeda/komeda_plane.c | 73 ++-
5 files changed, 85 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 2ea282c6a156..1f7a5d572b1a 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -610,6 +610,7 @@ static void d71_scaler_update(struct komeda_component *c,
ctrl = 0;
ctrl |= st->en_scaling ? SC_CTRL_SCL : 0;
ctrl |= st->en_alpha ? SC_CTRL_AP : 0;
+ ctrl |= st->en_img_enhancement ? SC_CTRL_IENH : 0;
malidp_write32(reg, BLK_CONTROL, ctrl);
malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(&state->inputs[0]));
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index db59a9042beb..e6e059f2af52 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -32,6 +32,9 @@ struct komeda_plane {
* Layers with same capabilities.
*/
struct komeda_layer *layer;
+
+ /** @prop_img_enhancement: for on/off image enhancement */
+ struct drm_property *prop_img_enhancement;
};
/**
@@ -44,7 +47,8 @@ struct komeda_plane_state {
/** @base: &drm_plane_state */
struct drm_plane_state base;
- /* private properties */
+ /* @img_enhancement: on/off image enhancement */
+ u8 img_enhancement : 1;
};
/**
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index d0bf7d5b39a7..0e334f1cf18b 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -254,7 +254,8 @@ struct komeda_scaler_state {
u16 hsize_in, vsize_in;
u16 hsize_out, vsize_out;
u8 en_scaling : 1,
- en_alpha : 1; /* enable alpha processing */
+ en_alpha : 1, /* enable alpha processing */
+ en_img_enhancement : 1;
};
struct komeda_compiz {
@@ -313,7 +314,8 @@ struct komeda_data_flow_cfg {
u32 rot;
int blending_zorder;
u8 pixel_blend_mode, layer_alpha;
- u8 en_scaling : 1;
+ u8 en_scaling : 1,
+ en_img_enhancement : 1;
};
struct komeda_pipeline_funcs {
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index 01544c274848..db34ea26760c 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -457,7 +457,7 @@ komeda_scaler_validate(void *user,
struct komeda_scaler *scaler;
int err = 0;
- if (!dflow->en_scaling)
+ if (!(dflow->en_scaling || dflow->en_img_enhancement))
return 0;
scaler = komeda_component_get_avail_scaler(dflow->input.component,
@@ -482,9 +482,11 @@ komeda_scaler_validate(void *user,
st->vsize_in = dflow->in_h;
st->hsize_out = dflow->out_w;
st->vsize_out = dflow->out_h;
- st->en_scaling = dflow->en_scaling;
+
/* Enable alpha processing if the next stage needs the pixel alpha */
st->en_alpha = dflow->pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE;
+ st->en_scaling = dflow->en_scaling;
+ st->en_img_enhancement = dflow->en_img_enhancement;
komeda_component_add_input(&st->base, &dflow->input, 0);
komeda_component_set_output(&dflow->input, &scaler->base, 0);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 97d8adb6cd2b..e7cd690d933d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -15,6 +15,7 @@ static int
komeda_plane_init_data_flow(struct drm_plane_state *st,
struct komeda_data_flow_cfg *dflow)
{
+ struct komeda_plane_state *kplane_st = to_kplane_st(st);
struct drm_framebuffer *fb = st->fb;
memset(dflow, 0, sizeof(*dflow));
@@ -23,7 +24,7 @@ komeda_plane_init_data_flow(struct drm_plane_state *st,
/* if format doesn't have alpha, fix b
Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v8
Am 22.05.19 um 13:29 schrieb Daniel Vetter: > [SNIP] > Forgot to add: Iirc it was buffer sharing between i915 and amdgpu that > hits this. Can't say for sure since intel-gfx isn't cc'ed on this > version, so our CI hasn't picked this up. I've changed this so that when exporter/importer disagree on dynamic handling we always cache the sgt during the attachment process. Going to CC intel-gfx on the next version. > -Daniel > > +struct sg_table *sgt; > + > +sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL); And unfortunately the non-dynamic, i.e. legacy/current code importer is also the one which uses other flags than DMA_BIDIRECTIONAL. At least on ARM, and that's the only place where this matters because there the dma api might do cache flushing. >>> Well the only implementer for now is amdgpu, and amdgpu always requires >>> a coherent bidirectional mapping. >>> >>> So this won't be a problem unless the ARM drivers start to implement >>> dynamic DMA-buf handling themselves or start to talk to amdgpu (which >>> wouldn't have worked before anyway). >> Hm, feels a bit evil. I just heard a some soc people tell me that drm >> isn't cool because it likes to ignore soc at the expensive of x86. >> >> Otoh I don't see a way out either, and maybe this will be motivation >> enough to make the dma-api cache management a bit more explicit. Not >> that I expect much change there ... Actually it's not evil at all, see those exporters/importers could implement the callbacks for dynamic handling as well and the problem of the caching wouldn't appear either. Christian. >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] dma-buf: add dynamic caching of sg_table
Am 22.05.19 um 20:30 schrieb Daniel Vetter: > [SNIP] >> Well, it seems you are making incorrect assumptions about the cache >> maintenance of DMA-buf here. >> >> At least for all DRM devices I'm aware of mapping/unmapping an >> attachment does *NOT* have any cache maintenance implications. >> >> E.g. the use case you describe above would certainly fail with amdgpu, >> radeon, nouveau and i915 because mapping a DMA-buf doesn't stop the >> exporter from reading/writing to that buffer (just the opposite actually). >> >> All of them assume perfectly coherent access to the underlying memory. >> As far as I know there is no documented cache maintenance requirements >> for DMA-buf. > I think it is documented. It's just that on x86, we ignore that > because the dma-api pretends there's never a need for cache flushing > on x86, and that everything snoops the cpu caches. Which isn't true > since over 20 ago when AGP happened. The actual rules for x86 dma-buf > are very much ad-hoc (and we occasionally reapply some duct-tape when > cacheline noise shows up somewhere). Well I strongly disagree on this. Even on x86 at least AMD GPUs are also not fully coherent. For example you have the texture cache and the HDP read/write cache. So when both amdgpu as well as i915 would write to the same buffer at the same time we would get a corrupted data as well. The key point is that it is NOT DMA-buf in it's map/unmap call who is defining the coherency, but rather the reservation object and its attached dma_fence instances. So for example as long as a exclusive reservation object fence is still not signaled I can't assume that all caches are flushed and so can't start with my own operation/access to the data in question. Regards, Christian. > > I've just filed this away as another instance of the dma-api not > fitting gpus, and I think giving recent discussions that won't improve > anytime soon. So we're stuck with essentially undefined dma-buf > behaviour. > -Daniel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary" has been added to the 5.0-stable tree
This is a note to let you know that I've just added the patch titled PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary to the 5.0-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: pci-reset-lenovo-thinkpad-p50-nvgpu-at-boot-if-necessary.patch and it can be found in the queue-5.0 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. From e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 Mon Sep 17 00:00:00 2001 From: Lyude Paul Date: Tue, 12 Feb 2019 17:02:30 -0500 Subject: PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary From: Lyude Paul commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream. On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid Graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 3. Allow the Nvidia GPU to runtime suspend itself after being idle 4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help) 5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002 This causes a timeout trying to bring up the GR ctx: nouveau :01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown] The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) ... handlers: [<7faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 ... serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! This causes the touchpad and sometimes other things to get disabled. Since this happens without nouveau, we can't fix this problem from nouveau itself. Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003 Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Cc: nouv...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Karol Herbst Cc: Ben Skeggs Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/pci/quirks.c | 58 +++ 1 file changed, 58 insertions(+) --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5122,3 +5122,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3 SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */ SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */ SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */ + +/* + * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does + * not always reset the secondary Nvidia GPU between reboots if the system + * is configured to use Hybrid Graphics mode. This results in the GPU + * be
Re: [PATCH 01/12] dma-buf: add dynamic caching of sg_table
On Thu, May 23, 2019 at 1:21 PM Koenig, Christian wrote: > > Am 22.05.19 um 20:30 schrieb Daniel Vetter: > > [SNIP] > >> Well, it seems you are making incorrect assumptions about the cache > >> maintenance of DMA-buf here. > >> > >> At least for all DRM devices I'm aware of mapping/unmapping an > >> attachment does *NOT* have any cache maintenance implications. > >> > >> E.g. the use case you describe above would certainly fail with amdgpu, > >> radeon, nouveau and i915 because mapping a DMA-buf doesn't stop the > >> exporter from reading/writing to that buffer (just the opposite actually). > >> > >> All of them assume perfectly coherent access to the underlying memory. > >> As far as I know there is no documented cache maintenance requirements > >> for DMA-buf. > > I think it is documented. It's just that on x86, we ignore that > > because the dma-api pretends there's never a need for cache flushing > > on x86, and that everything snoops the cpu caches. Which isn't true > > since over 20 ago when AGP happened. The actual rules for x86 dma-buf > > are very much ad-hoc (and we occasionally reapply some duct-tape when > > cacheline noise shows up somewhere). > > Well I strongly disagree on this. Even on x86 at least AMD GPUs are also > not fully coherent. > > For example you have the texture cache and the HDP read/write cache. So > when both amdgpu as well as i915 would write to the same buffer at the > same time we would get a corrupted data as well. > > The key point is that it is NOT DMA-buf in it's map/unmap call who is > defining the coherency, but rather the reservation object and its > attached dma_fence instances. > > So for example as long as a exclusive reservation object fence is still > not signaled I can't assume that all caches are flushed and so can't > start with my own operation/access to the data in question. The dma-api doesn't flush device caches, ever. It might flush some iommu caches or some other bus cache somewhere in-between. So it also won't ever make sure that multiple devices don't trample on each another. For that you need something else (like reservation object, but I think that's not really followed outside of drm much). The other bit is the coherent vs. non-coherent thing, which in the dma-api land just talks about whether cpu/device access need extra flushing or not. Now in practice that extra flushing is always only cpu side, i.e. will cpu writes/reads go through the cpu cache, and will device reads/writes snoop the cpu caches. That's (afaik at least, an in practice, not the abstract spec) the _only_ thing dma-api's cache maintenance does. For 0 copy that's all completely irrelevant, because as soon as you pick a mode where you need to do manual cache management you've screwed up, it's not 0-copy anymore really. The other hilarious stuff is that on x86 we let userspace (at least with i915) do that cache management, so the kernel doesn't even have a clue. I think what we need in dma-buf (and dma-api people will scream about the "abstraction leak") is some notition about whether an importer should snoop or not (or if that device always uses non-snoop or snooped transactions). But that would shred the illusion the dma-api tries to keep up that all that matters is whether a mapping is coherent from the cpu's pov or not, and you can achieve coherence both with a cache cpu mapping + snooped transactions, or with wc cpu side and non-snooped transactions. Trying to add cache managment (which some dma-buf exporter do indeed attempt to) will be even worse. Again, none of this is about preventing concurrent writes, or making sure device caches are flushed correctly around batches. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary" has been added to the 5.1-stable tree
This is a note to let you know that I've just added the patch titled PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary to the 5.1-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: pci-reset-lenovo-thinkpad-p50-nvgpu-at-boot-if-necessary.patch and it can be found in the queue-5.1 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. From e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 Mon Sep 17 00:00:00 2001 From: Lyude Paul Date: Tue, 12 Feb 2019 17:02:30 -0500 Subject: PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary From: Lyude Paul commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream. On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid Graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 3. Allow the Nvidia GPU to runtime suspend itself after being idle 4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help) 5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002 This causes a timeout trying to bring up the GR ctx: nouveau :01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown] The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) ... handlers: [<7faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 ... serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! This causes the touchpad and sometimes other things to get disabled. Since this happens without nouveau, we can't fix this problem from nouveau itself. Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003 Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Cc: nouv...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Karol Herbst Cc: Ben Skeggs Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/pci/quirks.c | 58 +++ 1 file changed, 58 insertions(+) --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5124,3 +5124,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3 SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */ SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */ SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */ + +/* + * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does + * not always reset the secondary Nvidia GPU between reboots if the system + * is configured to use Hybrid Graphics mode. This results in the GPU + * be
Re: [PATCH 01/12] dma-buf: add dynamic caching of sg_table
On Thu, May 23, 2019 at 1:30 PM Daniel Vetter wrote: > > On Thu, May 23, 2019 at 1:21 PM Koenig, Christian > wrote: > > > > Am 22.05.19 um 20:30 schrieb Daniel Vetter: > > > [SNIP] > > >> Well, it seems you are making incorrect assumptions about the cache > > >> maintenance of DMA-buf here. > > >> > > >> At least for all DRM devices I'm aware of mapping/unmapping an > > >> attachment does *NOT* have any cache maintenance implications. > > >> > > >> E.g. the use case you describe above would certainly fail with amdgpu, > > >> radeon, nouveau and i915 because mapping a DMA-buf doesn't stop the > > >> exporter from reading/writing to that buffer (just the opposite > > >> actually). > > >> > > >> All of them assume perfectly coherent access to the underlying memory. > > >> As far as I know there is no documented cache maintenance requirements > > >> for DMA-buf. > > > I think it is documented. It's just that on x86, we ignore that > > > because the dma-api pretends there's never a need for cache flushing > > > on x86, and that everything snoops the cpu caches. Which isn't true > > > since over 20 ago when AGP happened. The actual rules for x86 dma-buf > > > are very much ad-hoc (and we occasionally reapply some duct-tape when > > > cacheline noise shows up somewhere). > > > > Well I strongly disagree on this. Even on x86 at least AMD GPUs are also > > not fully coherent. > > > > For example you have the texture cache and the HDP read/write cache. So > > when both amdgpu as well as i915 would write to the same buffer at the > > same time we would get a corrupted data as well. > > > > The key point is that it is NOT DMA-buf in it's map/unmap call who is > > defining the coherency, but rather the reservation object and its > > attached dma_fence instances. > > > > So for example as long as a exclusive reservation object fence is still > > not signaled I can't assume that all caches are flushed and so can't > > start with my own operation/access to the data in question. > > The dma-api doesn't flush device caches, ever. It might flush some > iommu caches or some other bus cache somewhere in-between. So it also > won't ever make sure that multiple devices don't trample on each > another. For that you need something else (like reservation object, > but I think that's not really followed outside of drm much). > > The other bit is the coherent vs. non-coherent thing, which in the > dma-api land just talks about whether cpu/device access need extra > flushing or not. Now in practice that extra flushing is always only > cpu side, i.e. will cpu writes/reads go through the cpu cache, and > will device reads/writes snoop the cpu caches. That's (afaik at least, > an in practice, not the abstract spec) the _only_ thing dma-api's > cache maintenance does. For 0 copy that's all completely irrelevant, > because as soon as you pick a mode where you need to do manual cache > management you've screwed up, it's not 0-copy anymore really. > > The other hilarious stuff is that on x86 we let userspace (at least > with i915) do that cache management, so the kernel doesn't even have a > clue. I think what we need in dma-buf (and dma-api people will scream > about the "abstraction leak") is some notition about whether an > importer should snoop or not (or if that device always uses non-snoop > or snooped transactions). But that would shred the illusion the > dma-api tries to keep up that all that matters is whether a mapping is > coherent from the cpu's pov or not, and you can achieve coherence both > with a cache cpu mapping + snooped transactions, or with wc cpu side > and non-snooped transactions. Trying to add cache managment (which > some dma-buf exporter do indeed attempt to) will be even worse. > > Again, none of this is about preventing concurrent writes, or making > sure device caches are flushed correctly around batches. btw I just grepped for reservation_object, no one outside of drivers/gpu is using that. So for device access synchronization everyone else is relying on userspace ordering requests correctly on its own. Iirc v4l/media is pondering adding dma-fence support, but that's not going anywhere. Also, for correctness reservations aren't needed, we allow explicit syncing userspace to managed dma-fences/drm_syncobj on their own, and they are allowed to get this wrong. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/syncobj: add an output syncobj parameter to find_fence
We would like to get both the fence & the syncobj in i915 rather than
doing 2 calls to drm_syncobj_find() & drm_syncobj_find_fence().
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: David(ChunMing) Zhou
Cc: Eric Anholt
CC: DRI-Devel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/drm_syncobj.c | 45 +-
drivers/gpu/drm/v3d/v3d_gem.c | 5 ++-
include/drm/drm_syncobj.h | 1 +
4 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2f6239b6be6f..09fde3c73a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1124,10 +1124,11 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
uint32_t handle, u64 point,
u64 flags)
{
+ struct drm_syncobj *syncobj;
struct dma_fence *fence;
int r;
- r = drm_syncobj_find_fence(p->filp, handle, point, flags, &fence);
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags, &syncobj,
&fence);
if (r) {
DRM_ERROR("syncobj %u failed to find fence @ %llu (%d)!\n",
handle, point, r);
@@ -1136,6 +1137,7 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
r = amdgpu_sync_fence(p->adev, &p->job->sync, fence, true);
dma_fence_put(fence);
+ drm_syncobj_put(syncobj);
return r;
}
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3d400905100b..f2fd0c1fb1d3 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -222,29 +222,32 @@ static void drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* @handle: sync object handle to lookup.
* @point: timeline point
* @flags: DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT or not
+ * @syncobj: out parameter for the syncobj
* @fence: out parameter for the fence
*
* This is just a convenience function that combines drm_syncobj_find() and
* drm_syncobj_fence_get().
*
- * Returns 0 on success or a negative error value on failure. On success @fence
- * contains a reference to the fence, which must be released by calling
- * dma_fence_put().
+ * Returns 0 on success or a negative error value on failure. On
+ * success @syncobj and @fence contains a reference respectively to
+ * the syncobj and to the fence, which must be released by calling
+ * respectively drm_syncobj_put() and dma_fence_put().
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point, u64 flags,
+ struct drm_syncobj **syncobj,
struct dma_fence **fence)
{
- struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
struct syncobj_wait_entry wait;
u64 timeout = nsecs_to_jiffies64(DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT);
int ret;
- if (!syncobj)
+ *syncobj = drm_syncobj_find(file_private, handle);
+
+ if (!(*syncobj))
return -ENOENT;
- *fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
+ *fence = drm_syncobj_fence_get(*syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
@@ -255,13 +258,15 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
ret = -EINVAL;
}
- if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)) {
+ drm_syncobj_put(*syncobj);
return ret;
+ }
memset(&wait, 0, sizeof(wait));
wait.task = current;
wait.point = point;
- drm_syncobj_fence_add_wait(syncobj, &wait);
+ drm_syncobj_fence_add_wait(*syncobj, &wait);
do {
set_current_state(TASK_INTERRUPTIBLE);
@@ -286,7 +291,10 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
*fence = wait.fence;
if (wait.node.next)
- drm_syncobj_remove_wait(syncobj, &wait);
+ drm_syncobj_remove_wait(*syncobj, &wait);
+
+ if (ret)
+ drm_syncobj_put(*syncobj);
return ret;
}
@@ -531,6 +539,7 @@ static int drm_syncobj_export_sync_file(struct drm_file
*file_private,
int handle, int *p_fd)
{
int ret;
+ struct drm_syncobj *syncobj;
struct dma_fence *fence;
struct sync_file *sync_file;
int fd = get_unused_fd_flags(O_CLOEXEC);
@@ -538,13 +547,14 @@ static int drm_syncobj_export_sync_file(struct drm_file
*file_private,
if (fd < 0)
return fd;
- ret = drm_syncobj_find_fence(file_private, handle, 0, 0, &fence);
+ ret =
Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
在 2019/5/23 19:03, Christian König 写道:
> [CAUTION: External Email]
>
> Am 23.05.19 um 12:24 schrieb zhoucm1:
>>
>>
>> On 2019年05月22日 20:59, Christian König wrote:
>>> [CAUTION: External Email]
>>>
>>> BOs on the LRU might be blocked during command submission
>>> and cause OOM situations.
>>>
>>> Avoid this by blocking for the first busy BO not locked by
>>> the same ticket as the BO we are searching space for.
>>>
>>> v10: completely start over with the patch since we didn't
>>> handled a whole bunch of corner cases.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/ttm/ttm_bo.c | 77
>>> ++--
>>> 1 file changed, 66 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>>> b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index 4c6389d849ed..861facac33d4 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>>> * b. Otherwise, trylock it.
>>> */
>>> static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object
>>> *bo,
>>> - struct ttm_operation_ctx *ctx, bool *locked)
>>> + struct ttm_operation_ctx *ctx, bool *locked,
>>> bool *busy)
>>> {
>>> bool ret = false;
>>>
>>> - *locked = false;
>>> if (bo->resv == ctx->resv) {
>>> reservation_object_assert_held(bo->resv);
>>> if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
>>> || !list_empty(&bo->ddestroy))
>>> ret = true;
>>> + *locked = false;
>>> + if (busy)
>>> + *busy = false;
>>> } else {
>>> - *locked = reservation_object_trylock(bo->resv);
>>> - ret = *locked;
>>> + ret = reservation_object_trylock(bo->resv);
>>> + *locked = ret;
>>> + if (busy)
>>> + *busy = !ret;
>>> }
>>>
>>> return ret;
>>> }
>>>
>>> +/**
>>> + * ttm_mem_evict_wait_busy - wait for a busy BO to become available
>>> + *
>>> + * @busy_bo: BO which couldn't be locked with trylock
>>> + * @ctx: operation context
>>> + * @ticket: acquire ticket
>>> + *
>>> + * Try to lock a busy buffer object to avoid failing eviction.
>>> + */
>>> +static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
>>> + struct ttm_operation_ctx *ctx,
>>> + struct ww_acquire_ctx *ticket)
>>> +{
>>> + int r;
>>> +
>>> + if (!busy_bo || !ticket)
>>> + return -EBUSY;
>>> +
>>> + if (ctx->interruptible)
>>> + r =
>>> reservation_object_lock_interruptible(busy_bo->resv,
>>> + ticket);
>>> + else
>>> + r = reservation_object_lock(busy_bo->resv, ticket);
>>> +
>>> + /*
>>> + * TODO: It would be better to keep the BO locked until
>>> allocation is at
>>> + * least tried one more time, but that would mean a much
>>> larger rework
>>> + * of TTM.
>>> + */
>>> + if (!r)
>>> + reservation_object_unlock(busy_bo->resv);
>>> +
>>> + return r == -EDEADLK ? -EAGAIN : r;
>>> +}
>>> +
>>> static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>>> uint32_t mem_type,
>>> const struct ttm_place *place,
>>> - struct ttm_operation_ctx *ctx)
>>> + struct ttm_operation_ctx *ctx,
>>> + struct ww_acquire_ctx *ticket)
>>> {
>>> + struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
>>> struct ttm_bo_global *glob = bdev->glob;
>>> struct ttm_mem_type_manager *man = &bdev->man[mem_type];
>>> - struct ttm_buffer_object *bo = NULL;
>>> bool locked = false;
>>> unsigned i;
>>> int ret;
>>> @@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct
>>> ttm_bo_device *bdev,
>>> spin_lock(&glob->lru_lock);
>>> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>>> list_for_each_entry(bo, &man->lru[i], lru) {
>>> - if (!ttm_bo_evict_swapout_allowable(bo, ctx,
>>> &locked))
>>> + bool busy;
>>> +
>>> + if (!ttm_bo_evict_swapout_allowable(bo, ctx,
>>> &locked,
>>> + &busy)) {
>>> + if (busy && !busy_bo &&
>>> + bo->resv->lock.ctx != ticket)
>>> + busy_bo = bo;
>>> continue;
>>> + }
>>>
>>> if (place &&
>>> !bdev->driver->eviction_valuable(bo,
>>> place)) {
>>> @@ -824,8 +871,13 @@ static int ttm_mem_evict_first(struct
>>> ttm_bo_device *bdev,
>>> }
>>>
>>>
Re: [PATCH 3/6] drm/bridge: extract some Analogix I2C DP common code
On Thu, May 23, 2019 at 10:50:35AM +0300, Laurent Pinchart wrote: > On Thu, May 23, 2019 at 03:40:25PM +0800, Chen-Yu Tsai wrote: > > > > If this was simple code movement, then the original copyright still applies. > > A different copyright notice should not be used. I suppose the same applies > > to the module author. > > And likely to patch 2/6 too. Absolutely correct. Wdiff does not lie. Re-evaluating... Torsten
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> between commit:
>
> 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
>
> from Linus' tree and commits:
>
> b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> S9700RTWV43TR-01B")
> fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
>
> from the drm-misc tree.
>
> I fixed it up (I deleted the file and added the patch 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.
I just took your patch and pushed a temp branch there:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next&id=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90
Rob, Stephen, are you ok with the change? If so, I'll push it.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:[PATCH 1/2] drm/syncobj: add an output syncobj parameter to find_fence
can you make the parameter optional? Otherwise looks good to me.
-David
Original Message
Subject: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to find_fence
From: Lionel Landwerlin
To: intel-...@lists.freedesktop.org
CC: Lionel Landwerlin ,"Koenig, Christian" ,"Zhou, David(ChunMing)" ,Eric
Anholt ,DRI-Devel
[CAUTION: External Email]
We would like to get both the fence & the syncobj in i915 rather than
doing 2 calls to drm_syncobj_find() & drm_syncobj_find_fence().
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: David(ChunMing) Zhou
Cc: Eric Anholt
CC: DRI-Devel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/drm_syncobj.c | 45 +-
drivers/gpu/drm/v3d/v3d_gem.c | 5 ++-
include/drm/drm_syncobj.h | 1 +
4 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2f6239b6be6f..09fde3c73a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1124,10 +1124,11 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
uint32_t handle, u64 point,
u64 flags)
{
+ struct drm_syncobj *syncobj;
struct dma_fence *fence;
int r;
- r = drm_syncobj_find_fence(p->filp, handle, point, flags, &fence);
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags, &syncobj,
&fence);
if (r) {
DRM_ERROR("syncobj %u failed to find fence @ %llu (%d)!\n",
handle, point, r);
@@ -1136,6 +1137,7 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
r = amdgpu_sync_fence(p->adev, &p->job->sync, fence, true);
dma_fence_put(fence);
+ drm_syncobj_put(syncobj);
return r;
}
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3d400905100b..f2fd0c1fb1d3 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -222,29 +222,32 @@ static void drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* @handle: sync object handle to lookup.
* @point: timeline point
* @flags: DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT or not
+ * @syncobj: out parameter for the syncobj
* @fence: out parameter for the fence
*
* This is just a convenience function that combines drm_syncobj_find() and
* drm_syncobj_fence_get().
*
- * Returns 0 on success or a negative error value on failure. On success @fence
- * contains a reference to the fence, which must be released by calling
- * dma_fence_put().
+ * Returns 0 on success or a negative error value on failure. On
+ * success @syncobj and @fence contains a reference respectively to
+ * the syncobj and to the fence, which must be released by calling
+ * respectively drm_syncobj_put() and dma_fence_put().
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point, u64 flags,
+ struct drm_syncobj **syncobj,
struct dma_fence **fence)
{
- struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
struct syncobj_wait_entry wait;
u64 timeout = nsecs_to_jiffies64(DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT);
int ret;
- if (!syncobj)
+ *syncobj = drm_syncobj_find(file_private, handle);
+
+ if (!(*syncobj))
return -ENOENT;
- *fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
+ *fence = drm_syncobj_fence_get(*syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
@@ -255,13 +258,15 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
ret = -EINVAL;
}
- if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)) {
+ drm_syncobj_put(*syncobj);
return ret;
+ }
memset(&wait, 0, sizeof(wait));
wait.task = current;
wait.point = point;
- drm_syncobj_fence_add_wait(syncobj, &wait);
+ drm_syncobj_fence_add_wait(*syncobj, &wait);
do {
set_current_state(TASK_INTERRUPTIBLE);
@@ -286,7 +291,10 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
*fence = wait.fence;
if (wait.node.next)
- drm_syncobj_remove_wait(syncobj, &wait);
+ drm_syncobj_remove_wait(*syncobj, &wait);
+
+ if (ret)
+ drm_syncobj_put(*syncobj);
return ret;
}
@@ -531,6 +539,7 @@ static int drm_syncobj_export_sync_file(struct drm_file
*file_private,
int handle, int *p_fd)
{
int ret;
+ struct drm_syncobj *
[Bug 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 Bug ID: 110736 Summary: Spotify rendering issues Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: 0xe2.0x9a.0...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 144330 --> https://bugs.freedesktop.org/attachment.cgi?id=144330&action=edit Screenshot_20190523_135549.png Hello. I am experiencing Spotify rendering issues with Mesa 19.0.5, 19.1.0-rc3 and git. Mesa 18.3.6 has no rendering issues. Please see the attached screenshot. This issue might be triggered by a special combination of Mesa and other graphics libraries, because there exist points in time where there were no rendering issues when using Mesa versions 19.1.0-rc3 and git. Passing --disable-gpu to Spotify removes the rendering issues. Spotify 1.1.5 download location: http://repository-origin.spotify.com/pool/non-free/s/spotify-client/ $ glversion 4.5 (Core Profile) Mesa 19.1.0-rc3 AMD Radeon (TM) RX 470/570 Graphics (POLARIS10, DRM 3.30.0, 5.1.0, LLVM 8.0.0) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
On Tue, May 21, 2019 at 02:15:19PM +0200, Ondřej Jirman wrote:
> Hi Maxime,
>
> On Tue, May 21, 2019 at 01:46:11PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, May 21, 2019 at 01:50:08AM +0200, meg...@megous.com wrote:
> > > From: Ondrej Jirman
> > >
> > > Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> > > for the DDC bus to be usable.
> > >
> > > Add support for hdmi-connector node's optional ddc-en-gpios property to
> > > support this use case.
> > >
> > > Signed-off-by: Ondrej Jirman
> > > ---
> > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55 +--
> > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 3 ++
> > > 2 files changed, 55 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > index 39d8509d96a0..59b81ba02d96 100644
> > > --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > @@ -98,6 +98,30 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct
> > > drm_device *drm,
> > > return crtcs;
> > > }
> > >
> > > +static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
> > > + struct platform_device **pdev_out)
> > > +{
> > > + struct platform_device *pdev;
> > > + struct device_node *remote;
> > > +
> > > + remote = of_graph_get_remote_node(dev->of_node, 1, -1);
> > > + if (!remote)
> > > + return -ENODEV;
> > > +
> > > + if (!of_device_is_compatible(remote, "hdmi-connector")) {
> > > + of_node_put(remote);
> > > + return -ENODEV;
> > > + }
> > > +
> > > + pdev = of_find_device_by_node(remote);
> > > + of_node_put(remote);
> > > + if (!pdev)
> > > + return -ENODEV;
> > > +
> > > + *pdev_out = pdev;
> > > + return 0;
> > > +}
> > > +
> > > static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
> > > void *data)
> > > {
> > > @@ -151,16 +175,29 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> > > struct device *master,
> > > return PTR_ERR(hdmi->regulator);
> > > }
> > >
> > > + ret = sun8i_dw_hdmi_find_connector_pdev(dev, &hdmi->connector_pdev);
> > > + if (!ret) {
> > > + hdmi->ddc_en = gpiod_get_optional(&hdmi->connector_pdev->dev,
> > > + "ddc-en", GPIOD_OUT_HIGH);
> > > + if (IS_ERR(hdmi->ddc_en)) {
> > > + platform_device_put(hdmi->connector_pdev);
> > > + dev_err(dev, "Couldn't get ddc-en gpio\n");
> > > + return PTR_ERR(hdmi->ddc_en);
> > > + }
> > > + }
> > > +
> > > ret = regulator_enable(hdmi->regulator);
> > > if (ret) {
> > > dev_err(dev, "Failed to enable regulator\n");
> > > - return ret;
> > > + goto err_unref_ddc_en;
> > > }
> > >
> > > + gpiod_set_value(hdmi->ddc_en, 1);
> > > +
> >
> > Do you really need this to be done all the time? I'm guessing you
> > would only need this when running .get_modes, right?
>
> I don't think it hurts anything. Enabled voltage shifting circuit doesn't
> draw any current, unless DDC is actually transmitting data. On most boards
> I'd imagine this circuit is always on anyway (Orange Pi 3 schematic even has
> an option to tie this signal to VCC-IO instead of GPIO).
Ok, it works for me then
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] dt-bindings: Add ANX6345 DP/eDP transmitter binding
On Thu, May 23, 2019 at 11:05:40AM +0200, Maxime Ripard wrote: > > +Optional properties: > > + > > + - Video ports for RGB input and eDP output using the DT bindings > > + defined in [1] > > The output node can be optional, but the input one is probably going > to be needed all the time, since otherwise you won't be able to fill > the output port of the upstream device in the graph. I guess so. A sibling product brief (anx9804) https://www.analogix.com/en/ttlconvertersbridges references it as | LVTTL to DisplayPort 1.2 _transmitter_ so it will probably always be used on the output side. Torsten
Re: [PATCH 4/6] drm/bridge: Add Analogix anx6345 support
On Thu, May 23, 2019 at 10:50:41AM +0300, Laurent Pinchart wrote:
> Hi Torsten,
>
> Thank you for the patch.
Thank you for the thorough review!
> On Thu, May 23, 2019 at 08:53:56AM +0200, Torsten Duwe wrote:
> > +{
> > + struct anx6345 *anx6345 = connector_to_anx6345(connector);
> > + int err, num_modes = 0;
> > + bool power_off = false;
> > +
> > + mutex_lock(&anx6345->lock);
> > +
> > + if (!anx6345->edid) {
>
> Could the chip be used with a hot-pluggable display, or is it guaranteed
> that EDID will never change ?
The chip itself is capable of (e)DP hot-plugging, so the signals suggest.
See the previous discussions about what to expect on the output side.
Currently, the driver does not handle hot-plugging.
> > +
> > + err = drm_of_find_panel_or_bridge(client->dev.of_node, 1, 0,
> > + &anx6345->panel, NULL);
> > + if (err == -EPROBE_DEFER)
> > + return err;
> > +
> > + if (err)
> > + DRM_DEBUG("No panel found\n");
>
> Shouldn't this be fatal ?
No, basically same as above. On the output side, there can be a panel,
another bridge, or some eDP plug. If the DT didn't explicitly specify
a panel or a bridge, we can still generate video output as soon as
there is valid EDID data.
Your other points went straight onto my TODO list.
Torsten
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Maxime,
On Thu, 23 May 2019 13:53:55 +0200 Maxime Ripard
wrote:
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
> >
> > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> >
> > from Linus' tree and commits:
> >
> > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > S9700RTWV43TR-01B")
> > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
> >
> > from the drm-misc tree.
>
> I just took your patch and pushed a temp branch there:
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next&id=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90
>
> Rob, Stephen, are you ok with the change? If so, I'll push it.
All that needs to be done is for my patch (slightly corrected) needs to
be applied to the drm-misc tree. That tree already has the back merge
of Linus' tree and the txt file has been removed (my patch should have
been applied as part of the merge resolution but doing it later is fine).
--
Cheers,
Stephen Rothwell
pgpvak0h66Fo7.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
On Thu, May 23, 2019 at 3:04 PM Stephen Rothwell wrote:
>
> Hi Maxime,
>
> On Thu, 23 May 2019 13:53:55 +0200 Maxime Ripard
> wrote:
> >
> > On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > > Documentation/devicetree/bindings/vendor-prefixes.txt
> > >
> > > between commit:
> > >
> > > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> > >
> > > from Linus' tree and commits:
> > >
> > > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > > S9700RTWV43TR-01B")
> > > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision
> > > Electronics")
> > >
> > > from the drm-misc tree.
> >
> > I just took your patch and pushed a temp branch there:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next&id=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90
> >
> > Rob, Stephen, are you ok with the change? If so, I'll push it.
>
> All that needs to be done is for my patch (slightly corrected) needs to
> be applied to the drm-misc tree. That tree already has the back merge
> of Linus' tree and the txt file has been removed (my patch should have
> been applied as part of the merge resolution but doing it later is fine).
That commit is on top of drm-misc, and somehow the .txt version has
been resurrect in drm-misc-next (so needs to be re-deleted too).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to find_fence
Sure
-Lionel
On 23/05/2019 13:11, Zhou, David(ChunMing) wrote:
can you make the parameter optional? Otherwise looks good to me.
-David
Original Message
Subject: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to
find_fence
From: Lionel Landwerlin
To: intel-...@lists.freedesktop.org
CC: Lionel Landwerlin ,"Koenig, Christian" ,"Zhou, David(ChunMing)"
,Eric Anholt ,DRI-Devel
[CAUTION: External Email]
We would like to get both the fence & the syncobj in i915 rather than
doing 2 calls to drm_syncobj_find() & drm_syncobj_find_fence().
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: David(ChunMing) Zhou
Cc: Eric Anholt
CC: DRI-Devel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/drm_syncobj.c | 45 +-
drivers/gpu/drm/v3d/v3d_gem.c | 5 ++-
include/drm/drm_syncobj.h | 1 +
4 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2f6239b6be6f..09fde3c73a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1124,10 +1124,11 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
uint32_t handle, u64
point,
u64 flags)
{
+ struct drm_syncobj *syncobj;
struct dma_fence *fence;
int r;
- r = drm_syncobj_find_fence(p->filp, handle, point, flags, &fence);
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags,
&syncobj, &fence);
if (r) {
DRM_ERROR("syncobj %u failed to find fence @ %llu
(%d)!\n",
handle, point, r);
@@ -1136,6 +1137,7 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
r = amdgpu_sync_fence(p->adev, &p->job->sync, fence, true);
dma_fence_put(fence);
+ drm_syncobj_put(syncobj);
return r;
}
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3d400905100b..f2fd0c1fb1d3 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -222,29 +222,32 @@ static void
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
* @handle: sync object handle to lookup.
* @point: timeline point
* @flags: DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT or not
+ * @syncobj: out parameter for the syncobj
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
* drm_syncobj_fence_get().
*
- * Returns 0 on success or a negative error value on failure. On
success @fence
- * contains a reference to the fence, which must be released by calling
- * dma_fence_put().
+ * Returns 0 on success or a negative error value on failure. On
+ * success @syncobj and @fence contains a reference respectively to
+ * the syncobj and to the fence, which must be released by calling
+ * respectively drm_syncobj_put() and dma_fence_put().
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point, u64 flags,
+ struct drm_syncobj **syncobj,
struct dma_fence **fence)
{
- struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
struct syncobj_wait_entry wait;
u64 timeout =
nsecs_to_jiffies64(DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT);
int ret;
- if (!syncobj)
+ *syncobj = drm_syncobj_find(file_private, handle);
+
+ if (!(*syncobj))
return -ENOENT;
- *fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
+ *fence = drm_syncobj_fence_get(*syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
@@ -255,13 +258,15 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
ret = -EINVAL;
}
- if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)) {
+ drm_syncobj_put(*syncobj);
return ret;
+ }
memset(&wait, 0, sizeof(wait));
wait.task = current;
wait.point = point;
- drm_syncobj_fence_add_wait(syncobj, &wait);
+ drm_syncobj_fence_add_wait(*syncobj, &wait);
do {
set_current_state(TASK_INTERRUPTIBLE);
@@ -286,7 +291,10 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
*fence = wait.fence;
if (wait.node.next)
- drm_syncobj_remove_wait(syncobj, &wait);
+ drm_syncobj_remove_wait(*syncobj, &wait);
+
+ if (ret)
+ drm_syncobj_put(*syncobj);
return ret;
}
@@ -531,6 +539,7 @@ static int drm_syncobj_export_sync_file(struct
drm_file *file_private,
Re: [Intel-gfx] [PATCH 1/2] drm/syncobj: add an output syncobj parameter to find_fence
I should mentioned that this is going to make the find_fence() function
a fair bit more complex :)
On 23/05/2019 14:35, Lionel Landwerlin wrote:
Sure
-Lionel
On 23/05/2019 13:11, Zhou, David(ChunMing) wrote:
can you make the parameter optional? Otherwise looks good to me.
-David
Original Message
Subject: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to
find_fence
From: Lionel Landwerlin
To: intel-...@lists.freedesktop.org
CC: Lionel Landwerlin ,"Koenig, Christian" ,"Zhou, David(ChunMing)"
,Eric Anholt ,DRI-Devel
[CAUTION: External Email]
We would like to get both the fence & the syncobj in i915 rather than
doing 2 calls to drm_syncobj_find() & drm_syncobj_find_fence().
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: David(ChunMing) Zhou
Cc: Eric Anholt
CC: DRI-Devel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/drm_syncobj.c | 45 +-
drivers/gpu/drm/v3d/v3d_gem.c | 5 ++-
include/drm/drm_syncobj.h | 1 +
4 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2f6239b6be6f..09fde3c73a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1124,10 +1124,11 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
uint32_t handle, u64
point,
u64 flags)
{
+ struct drm_syncobj *syncobj;
struct dma_fence *fence;
int r;
- r = drm_syncobj_find_fence(p->filp, handle, point, flags,
&fence);
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags,
&syncobj, &fence);
if (r) {
DRM_ERROR("syncobj %u failed to find fence @ %llu
(%d)!\n",
handle, point, r);
@@ -1136,6 +1137,7 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
r = amdgpu_sync_fence(p->adev, &p->job->sync, fence, true);
dma_fence_put(fence);
+ drm_syncobj_put(syncobj);
return r;
}
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 3d400905100b..f2fd0c1fb1d3 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -222,29 +222,32 @@ static void
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
* @handle: sync object handle to lookup.
* @point: timeline point
* @flags: DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT or not
+ * @syncobj: out parameter for the syncobj
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
* drm_syncobj_fence_get().
*
- * Returns 0 on success or a negative error value on failure. On
success @fence
- * contains a reference to the fence, which must be released by calling
- * dma_fence_put().
+ * Returns 0 on success or a negative error value on failure. On
+ * success @syncobj and @fence contains a reference respectively to
+ * the syncobj and to the fence, which must be released by calling
+ * respectively drm_syncobj_put() and dma_fence_put().
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point, u64 flags,
+ struct drm_syncobj **syncobj,
struct dma_fence **fence)
{
- struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
struct syncobj_wait_entry wait;
u64 timeout =
nsecs_to_jiffies64(DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT);
int ret;
- if (!syncobj)
+ *syncobj = drm_syncobj_find(file_private, handle);
+
+ if (!(*syncobj))
return -ENOENT;
- *fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
+ *fence = drm_syncobj_fence_get(*syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
@@ -255,13 +258,15 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
ret = -EINVAL;
}
- if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)) {
+ drm_syncobj_put(*syncobj);
return ret;
+ }
memset(&wait, 0, sizeof(wait));
wait.task = current;
wait.point = point;
- drm_syncobj_fence_add_wait(syncobj, &wait);
+ drm_syncobj_fence_add_wait(*syncobj, &wait);
do {
set_current_state(TASK_INTERRUPTIBLE);
@@ -286,7 +291,10 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
*fence = wait.fence;
if (wait.node.next)
- drm_syncobj_remove_wait(syncobj, &wait);
+ drm_syncobj_remove_wait(*syncobj, &wait);
+
+ if (ret)
+ drm_syncobj_p
[PATCH v6 1/8] drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */ on a separate line
- CHECK: Alignment should match open parenthesis
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c| 168
drivers/gpu/drm/drm_atomic_helper.c | 164 ---
drivers/gpu/drm/drm_crtc_internal.h | 5 +
include/drm/drm_atomic_helper.h | 4 -
4 files changed, 173 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f4924cb7f495..79335084a502 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1174,6 +1174,174 @@ int drm_atomic_nonblocking_commit(struct
drm_atomic_state *state)
}
EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
+/* just used from drm-client and atomic-helper: */
+int __drm_atomic_helper_disable_plane(struct drm_plane *plane,
+ struct drm_plane_state *plane_state)
+{
+ int ret;
+
+ ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+ if (ret != 0)
+ return ret;
+
+ drm_atomic_set_fb_for_plane(plane_state, NULL);
+ plane_state->crtc_x = 0;
+ plane_state->crtc_y = 0;
+ plane_state->crtc_w = 0;
+ plane_state->crtc_h = 0;
+ plane_state->src_x = 0;
+ plane_state->src_y = 0;
+ plane_state->src_w = 0;
+ plane_state->src_h = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL(__drm_atomic_helper_disable_plane);
+
+static int update_output_state(struct drm_atomic_state *state,
+ struct drm_mode_set *set)
+{
+ struct drm_device *dev = set->crtc->dev;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *new_crtc_state;
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
+ int ret, i;
+
+ ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
+ state->acquire_ctx);
+ if (ret)
+ return ret;
+
+ /* First disable all connectors on the target crtc. */
+ ret = drm_atomic_add_affected_connectors(state, set->crtc);
+ if (ret)
+ return ret;
+
+ for_each_new_connector_in_state(state, connector, new_conn_state, i) {
+ if (new_conn_state->crtc == set->crtc) {
+ ret = drm_atomic_set_crtc_for_connector(new_conn_state,
+ NULL);
+ if (ret)
+ return ret;
+
+ /* Make sure legacy setCrtc always re-trains */
+ new_conn_state->link_status = DRM_LINK_STATUS_GOOD;
+ }
+ }
+
+ /* Then set all connectors from set->connectors on the target crtc */
+ for (i = 0; i < set->num_connectors; i++) {
+ new_conn_state = drm_atomic_get_connector_state(state,
+
set->connectors[i]);
+ if (IS_ERR(new_conn_state))
+ return PTR_ERR(new_conn_state);
+
+ ret = drm_atomic_set_crtc_for_connector(new_conn_state,
+ set->crtc);
+ if (ret)
+ return ret;
+ }
+
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ /*
+* Don't update ->enable for the CRTC in the set_config request,
+* since a mismatch would indicate a bug in the upper layers.
+* The actual modeset code later on will catch any
+* inconsistencies here.
+*/
+ if (crtc == set->crtc)
+ continue;
+
+ if (!new_crtc_state->connector_mask) {
+ ret = drm_atomic_set_mode_prop_for_crtc(new_crtc_state,
+ NULL);
+ if (ret < 0)
+ return ret;
+
+ new_crtc_state->active = false;
+ }
+ }
+
+ return 0;
+}
+
+/* just used from drm-client and atomic-helper: */
+int __drm_atomic_helper_set_config(struct drm_mode_set *set,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct drm_plane_state *primary_state;
+ struct drm_crtc *crtc = set->crtc;
+ int hdisplay, vdisplay;
+ int ret;
+
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state
[PATCH v6 3/8] drm/fb-helper: Prepare to move out commit code
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index dee16d97f3da..d530fb315e52 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -388,9 +388,20 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
}
EXPORT_SYMBOL(drm_fb_helper_debug_leave);
-/* Check if the plane can hw rotate to match panel orientation */
-static bool drm_fb_helper_panel_rotation(struct drm_mode_set *modeset,
-unsigned int *rotation)
+/**
+ * drm_client_panel_rotation() - Check panel orientation
+ * @modeset: DRM modeset
+ * @rotation: Returned rotation value
+ *
+ * This function checks if the primary plane in @modeset can hw rotate to match
+ * the panel orientation on its connector.
+ *
+ * Note: Currently only 0 and 180 degrees are supported.
+ *
+ * Return:
+ * True if the plane can do the rotation, false otherwise.
+ */
+bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int
*rotation)
{
struct drm_connector *connector = modeset->connectors[0];
struct drm_plane *plane = modeset->crtc->primary;
@@ -431,10 +442,9 @@ static bool drm_fb_helper_panel_rotation(struct
drm_mode_set *modeset,
return true;
}
-static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool
active)
+static int drm_client_modeset_commit_atomic(struct drm_client_dev *client,
bool active)
{
- struct drm_client_dev *client = &fb_helper->client;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
struct drm_plane_state *plane_state;
struct drm_plane *plane;
struct drm_atomic_state *state;
@@ -474,7 +484,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
struct drm_plane *primary = mode_set->crtc->primary;
unsigned int rotation;
- if (drm_fb_helper_panel_rotation(mode_set, &rotation)) {
+ if (drm_client_panel_rotation(mode_set, &rotation)) {
/* Cannot fail as we've already gotten the plane state
above */
plane_state = drm_atomic_get_new_plane_state(state,
primary);
plane_state->rotation = rotation;
@@ -516,15 +526,14 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
goto retry;
}
-static int restore_fbdev_mode_legacy(struct drm_fb_helper *fb_helper)
+static int drm_client_modeset_commit_legacy(struct drm_client_dev *client)
{
- struct drm_client_dev *client = &fb_helper->client;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
struct drm_mode_set *mode_set;
struct drm_plane *plane;
int ret = 0;
- drm_modeset_lock_all(fb_helper->dev);
+ drm_modeset_lock_all(dev);
drm_for_each_plane(plane, dev) {
if (plane->type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
@@ -553,35 +562,53 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper
*fb_helper)
goto out;
}
out:
- drm_modeset_unlock_all(fb_helper->dev);
+ drm_modeset_unlock_all(dev);
return ret;
}
-static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
+/**
+ * drm_client_modeset_commit_force() - Force commit CRTC configuration
+ * @client: DRM client
+ *
+ * Commit modeset configuration to crtcs without checking if there is a DRM
master.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_modeset_commit_force(struct drm_client_dev *client)
{
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
int ret;
- mutex_lock(&fb_helper->client.modeset_mutex);
+ mutex_lock(&client->modeset_mutex);
if (drm_drv_uses_atomic_modeset(dev))
- ret = restore_fbdev_mode_atomic(fb_helper, true);
+ ret = drm_client_modeset_commit_atomic(client, true);
else
- ret = restore_fbdev_mode_legacy(fb_helper);
- mutex_unlock(&fb_helper->client.modeset_mutex);
+ ret = drm_client_modeset_commit_legacy(client);
+ mutex_unlock(&client->modeset_mutex);
return ret;
}
-static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+/**
+ * drm_client_modeset_commit() - Commit CRTC configuration
+ * @client: DRM client
+ *
+ * Commit modeset configuration to crtcs.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_clien
[PATCH v6 0/8] drm/fb-helper: Move modesetting code to drm_client
This moves the modesetting code from drm_fb_helper to drm_client so it can be shared by all internal clients. Changes this time: - Improve commit messages All patches have been reviewed now, thanks alot for reviewing! Noralf. Noralf Trønnes (8): drm/atomic: Move __drm_atomic_helper_disable_plane/set_config() drm/fb-helper: Remove drm_fb_helper_crtc drm/fb-helper: Prepare to move out commit code drm/fb-helper: Move out commit code drm/fb-helper: Remove drm_fb_helper_connector drm/fb-helper: Prepare to move out modeset config code drm/fb-helper: Move out modeset config code drm/client: Hack: Add bootsplash example Documentation/gpu/drm-client.rst |3 + Documentation/gpu/todo.rst |7 + drivers/gpu/drm/Kconfig |5 + drivers/gpu/drm/Makefile |3 +- drivers/gpu/drm/drm_atomic.c | 168 drivers/gpu/drm/drm_atomic_helper.c | 164 drivers/gpu/drm/drm_bootsplash.c | 358 +++ drivers/gpu/drm/drm_client.c | 17 +- drivers/gpu/drm/drm_client_modeset.c | 1086 + drivers/gpu/drm/drm_crtc_internal.h |5 + drivers/gpu/drm/drm_drv.c|4 + drivers/gpu/drm/drm_fb_helper.c | 1305 ++ include/drm/drm_atomic_helper.h |4 - include/drm/drm_client.h | 49 + include/drm/drm_fb_helper.h | 92 +- 15 files changed, 1800 insertions(+), 1470 deletions(-) create mode 100644 drivers/gpu/drm/drm_bootsplash.c create mode 100644 drivers/gpu/drm/drm_client_modeset.c -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/8] drm/fb-helper: Remove drm_fb_helper_crtc
struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so use that directly instead and attach it as a modeset array onto drm_client_dev. drm_fb_helper will use this array to store its modesets which means it will always initialize a drm_client, but it will not register the client (callbacks) unless it's the generic fbdev emulation. Code will later be moved to drm_client, so add code there in a new file drm_client_modeset.c with MIT license to match drm_fb_helper.c. The modeset connector array size is hardcoded for the cloned case to avoid having to pass in a value from the driver. A value of 8 is chosen to err on the safe side. This means that the max connector argument for drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore, a todo entry for this is added. In pan_display_atomic() restore_fbdev_mode_force() is used instead of restore_fbdev_mode_atomic() because that one will later become internal to drm_client_modeset. Locking order: 1. drm_fb_helper->lock 2. drm_master_internal_acquire 3. drm_client_dev->modeset_mutex v6: Improve commit message (Sam Ravnborg) v3: - Use full drm_client_init/release for the modesets (Daniel Vetter) - drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter) - Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter) v2: - Add modesets array to drm_client (Daniel Vetter) - Use a new file for the modeset code (Daniel Vetter) - File has to be MIT licensed (Emmanuel Vadot) - Add copyrights from drm_fb_helper.c Signed-off-by: Noralf Trønnes Reviewed-by: Sam Ravnborg --- Documentation/gpu/drm-client.rst | 3 + Documentation/gpu/todo.rst | 3 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_client.c | 10 +- drivers/gpu/drm/drm_client_modeset.c | 104 + drivers/gpu/drm/drm_fb_helper.c | 301 +++ include/drm/drm_client.h | 30 +++ include/drm/drm_fb_helper.h | 8 - 8 files changed, 274 insertions(+), 187 deletions(-) create mode 100644 drivers/gpu/drm/drm_client_modeset.c diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst index 7e672063e7eb..58b5a1d1219d 100644 --- a/Documentation/gpu/drm-client.rst +++ b/Documentation/gpu/drm-client.rst @@ -10,3 +10,6 @@ Kernel clients .. kernel-doc:: drivers/gpu/drm/drm_client.c :export: + +.. kernel-doc:: drivers/gpu/drm/drm_client_modeset.c + :export: diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 66f05f4e469f..9d4038c50013 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -289,6 +289,9 @@ drm_fb_helper tasks these igt tests need to be fixed: kms_fbcon_fbt@psr and kms_fbcon_fbt@psr-suspend. +- The max connector argument for drm_fb_helper_init() and + drm_fb_helper_fbdev_setup() isn't used anymore and can be removed. + Core refactorings = diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 4c3dc4268b65..9ead6436fb87 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ - drm_atomic_uapi.o + drm_client_modeset.o drm_atomic_uapi.o drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o drm_dma.o drm_scatter.o drm_lock.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c index 5abcd83da6a6..77aa1cf09caa 100644 --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -27,7 +27,6 @@ * DOC: overview * * This library provides support for clients running in the kernel like fbdev and bootsplash. - * Currently it's only partially implemented, just enough to support fbdev. * * GEM drivers which provide a GEM based dumb buffer with a virtual address are supported. */ @@ -92,14 +91,20 @@ int drm_client_init(struct drm_device *dev, struct drm_client_dev *client, client->name = name; client->funcs = funcs; - ret = drm_client_open(client); + ret = drm_client_modeset_create(client); if (ret) goto err_put_module; + ret = drm_client_open(client); + if (ret) + goto err_free; + drm_dev_get(dev); return 0; +err_free: + drm_client_modeset_free(client); err_put_module: if (funcs) module_put(funcs->owner); @@ -148,6 +153,7 @@ void drm_client_release(struct drm_client_dev *client) DRM_DEV_DEBUG_KMS(dev->dev, "%s\n", client->name); + drm_client_modeset_free(client); drm_client_close(client); drm_dev_put(dev); if (client->funcs) diff --git a/drivers/gpu/drm/drm_client_modeset.
[PATCH v6 8/8] drm/client: Hack: Add bootsplash example
An example to showcase the client API.
TODO:
- A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be reversed for
bootsplash to fend off fbdev.
- Probably need some way to determine which is the primary display/device
on multi DRM device systems.
- Maybe do handover from early/simple DRM driver
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Kconfig | 5 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_bootsplash.c | 358 +++
drivers/gpu/drm/drm_client.c | 7 +
drivers/gpu/drm/drm_drv.c| 4 +
include/drm/drm_client.h | 3 +
6 files changed, 378 insertions(+)
create mode 100644 drivers/gpu/drm/drm_bootsplash.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index a461f078a0dd..aede0de0c9d9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -65,6 +65,11 @@ config DRM_DEBUG_SELFTEST
If in doubt, say "N".
+config DRM_CLIENT_BOOTSPLASH
+ bool "DRM Bootsplash"
+ help
+ DRM Bootsplash
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9ead6436fb87..78573ed02a4e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,6 +31,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_AGP) += drm_agpsupport.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_CLIENT_BOOTSPLASH) += drm_bootsplash.o
drm_vram_helper-y := drm_gem_vram_helper.o \
drm_vram_helper_common.o \
diff --git a/drivers/gpu/drm/drm_bootsplash.c b/drivers/gpu/drm/drm_bootsplash.c
new file mode 100644
index ..f58ee19e268f
--- /dev/null
+++ b/drivers/gpu/drm/drm_bootsplash.c
@@ -0,0 +1,358 @@
+/* DRM internal client example */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+// drm_lastclose()
+#include "drm_internal.h"
+
+static bool drm_bootsplash_enabled = true;
+module_param_named(bootsplash_enabled, drm_bootsplash_enabled, bool, 0600);
+MODULE_PARM_DESC(bootsplash_enabled, "Enable bootsplash client
[default=true]");
+
+struct drm_bootsplash {
+ struct drm_client_dev client;
+ struct mutex lock;
+ struct work_struct worker;
+ struct drm_client_buffer *buffers[2];
+ bool started;
+ bool stop;
+};
+
+static bool drm_bootsplash_key_pressed;
+
+static int drm_bootsplash_keyboard_notifier_call(struct notifier_block *blk,
+unsigned long code, void
*_param)
+{
+ /* Any key is good */
+ drm_bootsplash_key_pressed = true;
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block drm_bootsplash_keyboard_notifier_block = {
+ .notifier_call = drm_bootsplash_keyboard_notifier_call,
+};
+
+static void drm_bootsplash_buffer_delete(struct drm_bootsplash *splash)
+{
+ unsigned int i;
+
+ for (i = 0; i < 2; i++) {
+ if (!IS_ERR_OR_NULL(splash->buffers[i]))
+ drm_client_framebuffer_delete(splash->buffers[i]);
+ splash->buffers[i] = NULL;
+ }
+}
+
+static int drm_bootsplash_buffer_create(struct drm_bootsplash *splash, u32
width, u32 height)
+{
+ unsigned int i;
+
+ for (i = 0; i < 2; i++) {
+ splash->buffers[i] =
drm_client_framebuffer_create(&splash->client, width, height,
DRM_FORMAT_XRGB);
+ if (IS_ERR(splash->buffers[i])) {
+ drm_bootsplash_buffer_delete(splash);
+ return PTR_ERR(splash->buffers[i]);
+ }
+ }
+
+ return 0;
+}
+
+static int drm_bootsplash_display_probe(struct drm_bootsplash *splash)
+{
+ struct drm_client_dev *client = &splash->client;
+ unsigned int width = 0, height = 0;
+ unsigned int num_non_tiled = 0, i;
+ unsigned int modeset_mask = 0;
+ struct drm_mode_set *modeset;
+ bool tiled = false;
+ int ret;
+
+ ret = drm_client_modeset_probe(client, 0, 0);
+ if (ret)
+ return ret;
+
+ mutex_lock(&client->modeset_mutex);
+
+ drm_client_for_each_modeset(modeset, client) {
+ if (!modeset->mode)
+ continue;
+
+ if (modeset->connectors[0]->has_tile)
+ tiled = true;
+ else
+ num_non_tiled++;
+ }
+
+ if (!tiled && !num_non_tiled) {
+ drm_bootsplash_buffer_delete(splash);
+ ret = -ENOENT;
+ goto out;
+ }
+
+ /* Assume only one tiled monitor is possible */
+ if (ti
[PATCH v6 5/8] drm/fb-helper: Remove drm_fb_helper_connector
All drivers add all their connectors so there's no need to keep around an
array of available connectors. Instead we just put the useable (not
writeback) connectors in a temporary array using
drm_client_for_each_connector_iter() everytime we probe the outputs.
Other places where it's necessary to look at the connectors, we just
iterate over them using the same iterator function.
Rename functions which signature is changed since they will be moved to
drm_client in a later patch.
v6: Improve commit message (Sam Ravnborg)
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
Documentation/gpu/todo.rst | 4 +
drivers/gpu/drm/drm_fb_helper.c | 498 ++--
include/drm/drm_client.h| 15 +
include/drm/drm_fb_helper.h | 80 ++---
4 files changed, 193 insertions(+), 404 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 9d4038c50013..ab96ba0600a9 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -292,6 +292,10 @@ drm_fb_helper tasks
- The max connector argument for drm_fb_helper_init() and
drm_fb_helper_fbdev_setup() isn't used anymore and can be removed.
+- The helper doesn't keep an array of connectors anymore so these can be
+ removed: drm_fb_helper_single_add_all_connectors(),
+ drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector().
+
Core refactorings
=
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e9cfccda6533..c2719a632e3a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -90,12 +90,6 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
* down by calling drm_fb_helper_fbdev_teardown().
*
- * Drivers that need to handle connector hotplugging (e.g. dp mst) can't use
- * the setup helper and will need to do the whole four-step setup process with
- * drm_fb_helper_prepare(), drm_fb_helper_init(),
- * drm_fb_helper_single_add_all_connectors(), enable hotplugging and
- * drm_fb_helper_initial_config() to avoid a possible race window.
- *
* At runtime drivers should restore the fbdev console by using
* drm_fb_helper_lastclose() as their &drm_driver.lastclose callback.
* They should also notify the fb helper code from updates to the output
@@ -118,8 +112,7 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* encoders and connectors. To finish up the fbdev helper initialization, the
* drm_fb_helper_init() function is called. To probe for all attached displays
* and set up an initial configuration using the detected hardware, drivers
- * should call drm_fb_helper_single_add_all_connectors() followed by
- * drm_fb_helper_initial_config().
+ * should call drm_fb_helper_initial_config().
*
* If &drm_framebuffer_funcs.dirty is set, the
* drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functions will
@@ -132,165 +125,6 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* deferred I/O (coupled with drm_fb_helper_fbdev_teardown()).
*/
-#define drm_fb_helper_for_each_connector(fbh, i__) \
- for (({ lockdep_assert_held(&(fbh)->lock); }), \
-i__ = 0; i__ < (fbh)->connector_count; i__++)
-
-static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
-struct drm_connector *connector)
-{
- struct drm_fb_helper_connector *fb_conn;
- struct drm_fb_helper_connector **temp;
- unsigned int count;
-
- if (!drm_fbdev_emulation)
- return 0;
-
- lockdep_assert_held(&fb_helper->lock);
-
- count = fb_helper->connector_count + 1;
-
- if (count > fb_helper->connector_info_alloc_count) {
- size_t size = count * sizeof(fb_conn);
-
- temp = krealloc(fb_helper->connector_info, size, GFP_KERNEL);
- if (!temp)
- return -ENOMEM;
-
- fb_helper->connector_info_alloc_count = count;
- fb_helper->connector_info = temp;
- }
-
- fb_conn = kzalloc(sizeof(*fb_conn), GFP_KERNEL);
- if (!fb_conn)
- return -ENOMEM;
-
- drm_connector_get(connector);
- fb_conn->connector = connector;
- fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
-
- return 0;
-}
-
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
- struct drm_connector *connector)
-{
- int err;
-
- if (!fb_helper)
- return 0;
-
- mutex_lock(&fb_helper->lock);
- err = __drm_fb_helper_add_one_connector(fb_helper, connector);
- mutex_unlock(&fb_helper->lock);
-
- return err;
-}
-EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
-
-/**
- * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
- *emulation helper
-
[PATCH v6 6/8] drm/fb-helper: Prepare to move out modeset config code
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h | 4 ---
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c2719a632e3a..4788f5a28513 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -43,6 +43,10 @@
#include "drm_internal.h"
+struct drm_client_offset {
+ int x, y;
+};
+
static bool drm_fbdev_emulation = true;
module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
MODULE_PARM_DESC(fbdev_emulation,
@@ -1804,7 +1808,7 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
-struct drm_fb_offset *offsets,
+struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
int count, i, j;
@@ -1883,7 +1887,7 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
static int drm_client_get_tile_offsets(struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
int idx,
int h_idx, int v_idx)
{
@@ -1916,7 +1920,7 @@ static int drm_client_get_tile_offsets(struct
drm_connector **connectors,
static bool drm_client_target_preferred(struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
const u64 mask = BIT_ULL(connector_count) - 1;
@@ -2080,7 +2084,7 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
unsigned int connector_count,
struct drm_crtc **crtcs,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
unsigned int count = min_t(unsigned int, connector_count,
BITS_PER_LONG);
@@ -2250,30 +2254,47 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
return ret;
}
-static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
- u32 width, u32 height)
+/**
+ * drm_client_modeset_probe() - Probe for displays
+ * @client: DRM client
+ * @width: Maximum display mode width (optional)
+ * @height: Maximum display mode height (optional)
+ *
+ * This function sets up display pipelines for enabled connectors and stores
the
+ * config in the client's modeset array.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int
width, unsigned int height)
{
struct drm_connector *connector, **connectors = NULL;
- struct drm_client_dev *client = &fb_helper->client;
struct drm_connector_list_iter conn_iter;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
unsigned int total_modes_count = 0;
+ struct drm_client_offset *offsets;
unsigned int connector_count = 0;
struct drm_display_mode **modes;
- struct drm_fb_offset *offsets;
struct drm_crtc **crtcs;
+ int i, ret = 0;
bool *enabled;
- int i;
DRM_DEBUG_KMS("\n");
+ if (!width)
+ width = dev->mode_config.max_width;
+ if (!height)
+ height = dev->mode_config.max_height;
+
drm_connector_list_iter_begin(dev, &conn_iter);
drm_client_for_each_connector_iter(connector, &conn_iter) {
struct drm_connector **tmp;
tmp = krealloc(connectors, (connector_count + 1) *
sizeof(*connectors), GFP_KERNEL);
- if (!tmp)
+ if (!tmp) {
+ ret = -ENOMEM;
goto free_connectors;
+
[PATCH v6 4/8] drm/fb-helper: Move out commit code
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 287 +++
drivers/gpu/drm/drm_fb_helper.c | 282 --
include/drm/drm_client.h | 4 +
3 files changed, 291 insertions(+), 282 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 66770ed3299e..b2aedec65637 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -11,9 +11,14 @@
#include
#include
+#include
#include
#include
#include
+#include
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
int drm_client_modeset_create(struct drm_client_dev *client)
{
@@ -102,3 +107,285 @@ struct drm_mode_set *drm_client_find_modeset(struct
drm_client_dev *client, stru
}
/* TODO: Remove export when modeset code has been moved over */
EXPORT_SYMBOL(drm_client_find_modeset);
+
+/**
+ * drm_client_panel_rotation() - Check panel orientation
+ * @modeset: DRM modeset
+ * @rotation: Returned rotation value
+ *
+ * This function checks if the primary plane in @modeset can hw rotate to match
+ * the panel orientation on its connector.
+ *
+ * Note: Currently only 0 and 180 degrees are supported.
+ *
+ * Return:
+ * True if the plane can do the rotation, false otherwise.
+ */
+bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int
*rotation)
+{
+ struct drm_connector *connector = modeset->connectors[0];
+ struct drm_plane *plane = modeset->crtc->primary;
+ u64 valid_mask = 0;
+ unsigned int i;
+
+ if (!modeset->num_connectors)
+ return false;
+
+ switch (connector->display_info.panel_orientation) {
+ case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+ *rotation = DRM_MODE_ROTATE_180;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+ *rotation = DRM_MODE_ROTATE_90;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+ *rotation = DRM_MODE_ROTATE_270;
+ break;
+ default:
+ *rotation = DRM_MODE_ROTATE_0;
+ }
+
+ /*
+* TODO: support 90 / 270 degree hardware rotation,
+* depending on the hardware this may require the framebuffer
+* to be in a specific tiling format.
+*/
+ if (*rotation != DRM_MODE_ROTATE_180 || !plane->rotation_property)
+ return false;
+
+ for (i = 0; i < plane->rotation_property->num_values; i++)
+ valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+ if (!(*rotation & valid_mask))
+ return false;
+
+ return true;
+}
+
+static int drm_client_modeset_commit_atomic(struct drm_client_dev *client,
bool active)
+{
+ struct drm_device *dev = client->dev;
+ struct drm_plane_state *plane_state;
+ struct drm_plane *plane;
+ struct drm_atomic_state *state;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_mode_set *mode_set;
+ int ret;
+
+ drm_modeset_acquire_init(&ctx, 0);
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out_ctx;
+ }
+
+ state->acquire_ctx = &ctx;
+retry:
+ drm_for_each_plane(plane, dev) {
+ plane_state = drm_atomic_get_plane_state(state, plane);
+ if (IS_ERR(plane_state)) {
+ ret = PTR_ERR(plane_state);
+ goto out_state;
+ }
+
+ plane_state->rotation = DRM_MODE_ROTATE_0;
+
+ /* disable non-primary: */
+ if (plane->type == DRM_PLANE_TYPE_PRIMARY)
+ continue;
+
+ ret = __drm_atomic_helper_disable_plane(plane, plane_state);
+ if (ret != 0)
+ goto out_state;
+ }
+
+ drm_client_for_each_modeset(mode_set, client) {
+ struct drm_plane *primary = mode_set->crtc->primary;
+ unsigned int rotation;
+
+ if (drm_client_panel_rotation(mode_set, &rotation)) {
+ /* Cannot fail as we've already gotten the plane state
above */
+ plane_state = drm_atomic_get_new_plane_state(state,
primary);
+ plane_state->rotation = rotation;
+ }
+
+ ret = __drm_atomic_helper_set_config(mode_set, state);
+ if (ret != 0)
+ goto out_state;
+
+ /*
+* __drm_atomic_helper_set_config() sets active when a
+* mode is set, unconditionally clear it if we force DPMS off
+*/
+ if (!active) {
+ struct drm_crt
[PATCH v6 7/8] drm/fb-helper: Move out modeset config code
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 707 ++-
drivers/gpu/drm/drm_fb_helper.c | 692 --
include/drm/drm_client.h | 5 +-
3 files changed, 702 insertions(+), 702 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index b2aedec65637..e8b5c54d6c05 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -13,13 +13,22 @@
#include
#include
+#include
#include
#include
#include
+#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
+#define DRM_CLIENT_MAX_CLONED_CONNECTORS 8
+
+struct drm_client_offset {
+ int x, y;
+};
+
int drm_client_modeset_create(struct drm_client_dev *client)
{
struct drm_device *dev = client->dev;
@@ -58,7 +67,7 @@ int drm_client_modeset_create(struct drm_client_dev *client)
return -ENOMEM;
}
-void drm_client_modeset_release(struct drm_client_dev *client)
+static void drm_client_modeset_release(struct drm_client_dev *client)
{
struct drm_mode_set *modeset;
unsigned int i;
@@ -75,8 +84,6 @@ void drm_client_modeset_release(struct drm_client_dev *client)
modeset->num_connectors = 0;
}
}
-/* TODO: Remove export when modeset code has been moved over */
-EXPORT_SYMBOL(drm_client_modeset_release);
void drm_client_modeset_free(struct drm_client_dev *client)
{
@@ -95,7 +102,8 @@ void drm_client_modeset_free(struct drm_client_dev *client)
kfree(client->modesets);
}
-struct drm_mode_set *drm_client_find_modeset(struct drm_client_dev *client,
struct drm_crtc *crtc)
+static struct drm_mode_set *
+drm_client_find_modeset(struct drm_client_dev *client, struct drm_crtc *crtc)
{
struct drm_mode_set *modeset;
@@ -105,8 +113,695 @@ struct drm_mode_set *drm_client_find_modeset(struct
drm_client_dev *client, stru
return NULL;
}
-/* TODO: Remove export when modeset code has been moved over */
-EXPORT_SYMBOL(drm_client_find_modeset);
+
+static struct drm_display_mode *
+drm_connector_has_preferred_mode(struct drm_connector *connector, int width,
int height)
+{
+ struct drm_display_mode *mode;
+
+ list_for_each_entry(mode, &connector->modes, head) {
+ if (mode->hdisplay > width ||
+ mode->vdisplay > height)
+ continue;
+ if (mode->type & DRM_MODE_TYPE_PREFERRED)
+ return mode;
+ }
+ return NULL;
+}
+
+static struct drm_display_mode *
+drm_connector_pick_cmdline_mode(struct drm_connector *connector)
+{
+ struct drm_cmdline_mode *cmdline_mode;
+ struct drm_display_mode *mode;
+ bool prefer_non_interlace;
+
+ cmdline_mode = &connector->cmdline_mode;
+ if (cmdline_mode->specified == false)
+ return NULL;
+
+ /* attempt to find a matching mode in the list of modes
+* we have gotten so far, if not add a CVT mode that conforms
+*/
+ if (cmdline_mode->rb || cmdline_mode->margins)
+ goto create_mode;
+
+ prefer_non_interlace = !cmdline_mode->interlace;
+again:
+ list_for_each_entry(mode, &connector->modes, head) {
+ /* check width/height */
+ if (mode->hdisplay != cmdline_mode->xres ||
+ mode->vdisplay != cmdline_mode->yres)
+ continue;
+
+ if (cmdline_mode->refresh_specified) {
+ if (mode->vrefresh != cmdline_mode->refresh)
+ continue;
+ }
+
+ if (cmdline_mode->interlace) {
+ if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
+ continue;
+ } else if (prefer_non_interlace) {
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ continue;
+ }
+ return mode;
+ }
+
+ if (prefer_non_interlace) {
+ prefer_non_interlace = false;
+ goto again;
+ }
+
+create_mode:
+ mode = drm_mode_create_from_cmdline_mode(connector->dev, cmdline_mode);
+ list_add(&mode->head, &connector->modes);
+
+ return mode;
+}
+
+static bool drm_connector_enabled(struct drm_connector *connector, bool strict)
+{
+ bool enable;
+
+ if (connector->display_info.non_desktop)
+ return false;
+
+ if (strict)
+ enable = connector->status == connector_status_connected;
+ else
+ enable = connector->status != connector_status_disconnected;
+
+ return enable;
+}
+
+static void drm_client_connectors_enabled(struct drm_connector **connectors,
+
[PATCH] drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()
From: Sean Paul
Fixes the following warnings:
../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member
'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter
'hdr_metadata' description in 'drm_hdmi_infoframe_set_hdr_metadata'
Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: "Ville Syrjälä"
Cc: Hans Verkuil
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 262510c2a670..d87f574feeca 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4914,7 +4914,7 @@ static inline bool is_eotf_supported(u8 output_eotf, u8
sink_eotf)
* drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
* HDR metadata from userspace
* @frame: HDMI DRM infoframe
- * @hdr_metadata: hdr_source_metadata info from userspace
+ * @conn_state: Connector state containing HDR metadata
*
* Return: 0 on success or a negative error code on failure.
*/
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH] kernel.h: Add generic roundup_64() macro
From: Steven Rostedt (VMware)
In discussing a build failure on x86_32 due to the use of roundup() on
a 64 bit number, I realized that there's no generic equivalent
roundup_64(). It is implemented in two separate places in the kernel,
but there really should be just one that all can use.
Although the other implementations are a static inline function, this
implementation is a macro to allow the use of typeof(x) to denote the
type that is being used. If the build is on a 64 bit machine, then the
roundup_64() macro will just default back to roundup(). But for 32 bit
machines, it will use the version that is will not cause issues with
dividing a 64 bit number on a 32 bit machine.
Link: http://lkml.kernel.org/r/20190522145450.25ff4...@gandalf.local.home
Signed-off-by: Steven Rostedt (VMware)
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 34a998012bf6..cdacfe1f732c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -143,14 +143,6 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
kfree(nvbo);
}
-static inline u64
-roundup_64(u64 x, u32 y)
-{
- x += y - 1;
- do_div(x, y);
- return x * y;
-}
-
static void
nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
int *align, u64 *size)
diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h
index edbd5a210df2..13de9d49bd52 100644
--- a/fs/xfs/xfs_linux.h
+++ b/fs/xfs/xfs_linux.h
@@ -207,13 +207,6 @@ static inline xfs_dev_t linux_to_xfs_dev_t(dev_t dev)
#define xfs_sort(a,n,s,fn) sort(a,n,s,fn,NULL)
#define xfs_stack_trace() dump_stack()
-static inline uint64_t roundup_64(uint64_t x, uint32_t y)
-{
- x += y - 1;
- do_div(x, y);
- return x * y;
-}
-
static inline uint64_t howmany_64(uint64_t x, uint32_t y)
{
x += y - 1;
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 74b1ee9027f5..cd0063629357 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -115,6 +115,20 @@
(((x) + (__y - 1)) / __y) * __y;\
} \
)
+
+#if BITS_PER_LONG == 32
+# define roundup_64(x, y) (\
+{ \
+ typeof(y) __y = y; \
+ typeof(x) __x = (x) + (__y - 1);\
+ do_div(__x, __y); \
+ __x * __y; \
+} \
+)
+#else
+# define roundup_64(x, y) roundup(x, y)
+#endif
+
/**
* rounddown - round down to next specified multiple
* @x: the value to round
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #11 from Utku Helvacı (tuxutku) --- I have bisected the bug, also i have reported it: https://bugzilla.kernel.org/show_bug.cgi?id=201077 its been a month since reporting it to linux kernel amd team, they acknowledged the problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #12 from Utku Helvacı (tuxutku) --- its actually been more then two months since reporting it, its not fixed yet -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
Am 23.05.19 um 13:50 schrieb Zhou, David(ChunMing):
> 在 2019/5/23 19:03, Christian König 写道:
>> [CAUTION: External Email]
>>
>> Am 23.05.19 um 12:24 schrieb zhoucm1:
>>>
>>> On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 77
++--
1 file changed, 66 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 4c6389d849ed..861facac33d4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object
*bo,
- struct ttm_operation_ctx *ctx, bool *locked)
+ struct ttm_operation_ctx *ctx, bool *locked,
bool *busy)
{
bool ret = false;
- *locked = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
|| !list_empty(&bo->ddestroy))
ret = true;
+ *locked = false;
+ if (busy)
+ *busy = false;
} else {
- *locked = reservation_object_trylock(bo->resv);
- ret = *locked;
+ ret = reservation_object_trylock(bo->resv);
+ *locked = ret;
+ if (busy)
+ *busy = !ret;
}
return ret;
}
+/**
+ * ttm_mem_evict_wait_busy - wait for a busy BO to become available
+ *
+ * @busy_bo: BO which couldn't be locked with trylock
+ * @ctx: operation context
+ * @ticket: acquire ticket
+ *
+ * Try to lock a busy buffer object to avoid failing eviction.
+ */
+static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
+{
+ int r;
+
+ if (!busy_bo || !ticket)
+ return -EBUSY;
+
+ if (ctx->interruptible)
+ r =
reservation_object_lock_interruptible(busy_bo->resv,
+ ticket);
+ else
+ r = reservation_object_lock(busy_bo->resv, ticket);
+
+ /*
+ * TODO: It would be better to keep the BO locked until
allocation is at
+ * least tried one more time, but that would mean a much
larger rework
+ * of TTM.
+ */
+ if (!r)
+ reservation_object_unlock(busy_bo->resv);
+
+ return r == -EDEADLK ? -EAGAIN : r;
+}
+
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
const struct ttm_place *place,
- struct ttm_operation_ctx *ctx)
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
{
+ struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
- struct ttm_buffer_object *bo = NULL;
bool locked = false;
unsigned i;
int ret;
@@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct
ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx,
&locked))
+ bool busy;
+
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx,
&locked,
+ &busy)) {
+ if (busy && !busy_bo &&
+ bo->resv->lock.ctx != ticket)
+ busy_bo = bo;
continue;
+ }
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Daniel, On Thu, 23 May 2019 15:11:15 +0200 Daniel Vetter wrote: > > That commit is on top of drm-misc, and somehow the .txt version has > been resurrect in drm-misc-next (so needs to be re-deleted too). My mistake, the conflict went away (due to the back merge) so my scripts assumed the file no longer needed deleting. I didn't actually check to see if it was still there. -- Cheers, Stephen Rothwell pgpkEY83ZjdIJ.pgp Description: OpenPGP digital signature
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #13 from Andre Klapper --- > its actually been more then two months since reporting it, its not fixed yet You (or anyone else) needs to volunteer to investigate and provide a patch. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/todo: Add bootsplash entry
Ease entry for anyone wanting to pick up the bootsplash work by providing a couple of pointers. Signed-off-by: Noralf Trønnes --- Documentation/gpu/todo.rst | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index ab96ba0600a9..05d610321566 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -484,5 +484,19 @@ i915 device_link_add to model the dependency between i915 and snd_had. See https://dri.freedesktop.org/docs/drm/driver-api/device_link.html +Bootsplash +== + +There is support in place now for writing internal DRM clients making it +possible to pick up the bootsplash work that was rejected because it was written +for fbdev. + +- [v6,8/8] drm/client: Hack: Add bootsplash example + https://patchwork.freedesktop.org/patch/306579/ + +- [RFC PATCH v2 00/13] Kernel based bootsplash + https://lkml.org/lkml/2017/12/13/764 + + Outside DRM === -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()
>-Original Message-
>From: Sean Paul [mailto:s...@poorly.run]
>Sent: Thursday, May 23, 2019 7:25 PM
>To: dri-devel@lists.freedesktop.org
>Cc: Sean Paul ; Shankar, Uma ;
>Sharma, Shashank ; Ville Syrjälä
>; Maarten Lankhorst
>; Maxime Ripard
>; Sean Paul ; David Airlie
>; Daniel Vetter ; Bartlomiej Zolnierkiewicz
>; Hans Verkuil ; linux-
>fb...@vger.kernel.org
>Subject: [PATCH] drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()
>
>From: Sean Paul
>
>Fixes the following warnings:
>../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member
>'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
>../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter
>'hdr_metadata' description in 'drm_hdmi_infoframe_set_hdr_metadata'
Thanks Sean Paul for fixing this.
Reviewed-by: Uma Shankar
>Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
>Cc: Uma Shankar
>Cc: Shashank Sharma
>Cc: Ville Syrjälä
>Cc: Maarten Lankhorst
>Cc: Maxime Ripard
>Cc: Sean Paul
>Cc: David Airlie
>Cc: Daniel Vetter
>Cc: Bartlomiej Zolnierkiewicz
>Cc: "Ville Syrjälä"
>Cc: Hans Verkuil
>Cc: dri-devel@lists.freedesktop.org
>Cc: linux-fb...@vger.kernel.org
>Signed-off-by: Sean Paul
>---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
>262510c2a670..d87f574feeca 100644
>--- a/drivers/gpu/drm/drm_edid.c
>+++ b/drivers/gpu/drm/drm_edid.c
>@@ -4914,7 +4914,7 @@ static inline bool is_eotf_supported(u8 output_eotf, u8
>sink_eotf)
> * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
> * HDR metadata from userspace
> * @frame: HDMI DRM infoframe
>- * @hdr_metadata: hdr_source_metadata info from userspace
>+ * @conn_state: Connector state containing HDR metadata
> *
> * Return: 0 on success or a negative error code on failure.
> */
>--
>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 6/6] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Wed, May 22, 2019 at 11:54 PM Torsten Duwe wrote:
>
> From: Icenowy Zheng
>
> Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus. eDP output goes
> to an Innolux N116BGE panel.
>
> Enable it in the device tree.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Torsten Duwe
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 65
> +--
> 1 file changed, 61 insertions(+), 4 deletions(-)
>
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -65,6 +65,21 @@
> };
> };
>
> + panel: panel {
> + compatible ="innolux,n116bge", "simple-panel";
IIRC Rob wanted it to be edp-connector, not simple-panel. Also you
need to introduce edp-connector binding.
> + status = "okay";
> + power-supply = <®_dcdc1>;
> + backlight = <&backlight>;
> +
> + ports {
> + panel_in: port {
> + panel_in_edp: endpoint {
> + remote-endpoint = <&anx6345_out>;
> + };
> + };
> + };
> + };
> +
> reg_usb1_vbus: usb1-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb1-vbus";
> @@ -81,20 +96,48 @@
> };
> };
>
> +&de {
> + status = "okay";
> +};
> +
> &ehci1 {
> status = "okay";
> };
>
>
> -/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
> - * driver for this chip at the moment, the bootloader initializes it.
> - * However it can be accessed with the i2c-dev driver from user space.
> - */
> &i2c0 {
> clock-frequency = <10>;
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0_pins>;
> status = "okay";
> +
> + anx6345: anx6345@38 {
> + compatible = "analogix,anx6345";
> + reg = <0x38>;
> + reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
> + dvdd25-supply = <®_dldo2>;
> + dvdd12-supply = <®_dldo3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + anx6345_in: endpoint {
> + remote-endpoint =
> <&tcon0_out_anx6345>;
> + };
> + };
> + port@1 {
> + anx6345_out: endpoint {
> + remote-endpoint = <&panel_in_edp>;
> + };
> + };
> + };
> + };
> +};
> +
> +&mixer0 {
> + status = "okay";
> };
>
> &mmc0 {
> @@ -279,6 +322,20 @@
> vcc-hdmi-supply = <®_dldo1>;
> };
>
> +&tcon0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_rgb666_pins>;
> +
> + status = "okay";
> +};
> +
> +&tcon0_out {
> + tcon0_out_anx6345: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&anx6345_in>;
> + };
> +};
> +
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pb_pins>;
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
>
> +# define roundup_64(x, y) (\
> +{ \
> + typeof(y) __y = y; \
> + typeof(x) __x = (x) + (__y - 1);\
> + do_div(__x, __y); \
> + __x * __y; \
> +} \
The thing about this is that it absolutely sucks for power-of-two arguments.
The regular roundup() that uses division has the compiler at least
optimize them to shifts - at least for constant cases. But do_div() is
meant for "we already know it's not a power of two", and the compiler
doesn't have any understanding of the internals.
And it looks to me like the use case you want this for is very much
probably a power of two. In which case division is all kinds of just
stupid.
And we already have a power-of-two round up function that works on
u64. It's called "round_up()".
I wish we had a better visual warning about the differences between
"round_up()" (limited to powers-of-two, but efficient, and works with
any size) and "roundup()" (generic, potentially horribly slow, and
doesn't work for 64-bit on 32-bit).
Side note: "round_up()" has the problem that it uses "x" twice.
End result: somebody should look at this, but I really don't like the
"force division" case that is likely horribly slow and nasty.
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, 23 May 2019 08:10:44 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
> >
> > +# define roundup_64(x, y) (\
> > +{ \
> > + typeof(y) __y = y; \
> > + typeof(x) __x = (x) + (__y - 1);\
> > + do_div(__x, __y); \
> > + __x * __y; \
> > +} \
>
> The thing about this is that it absolutely sucks for power-of-two arguments.
>
> The regular roundup() that uses division has the compiler at least
> optimize them to shifts - at least for constant cases. But do_div() is
> meant for "we already know it's not a power of two", and the compiler
> doesn't have any understanding of the internals.
>
> And it looks to me like the use case you want this for is very much
> probably a power of two. In which case division is all kinds of just
> stupid.
>
> And we already have a power-of-two round up function that works on
> u64. It's called "round_up()".
>
> I wish we had a better visual warning about the differences between
> "round_up()" (limited to powers-of-two, but efficient, and works with
> any size) and "roundup()" (generic, potentially horribly slow, and
> doesn't work for 64-bit on 32-bit).
>
> Side note: "round_up()" has the problem that it uses "x" twice.
>
> End result: somebody should look at this, but I really don't like the
> "force division" case that is likely horribly slow and nasty.
I haven't yet tested this, but what about something like the following:
# define roundup_64(x, y) ( \
{ \
typeof(y) __y; \
typeof(x) __x; \
\
if (__builtin_constant_p(y) && \
!(y & (y >> 1))) { \
__x = round_up(x, y); \
} else {\
__y = y;\
__x = (x) + (__y - 1); \
do_div(__x, __y); \
__x = __x * __y;\
} \
__x;\
} \
)
If the compiler knows enough that y is a power of two, it will use the
shift version. Otherwise, it doesn't know enough and would divide
regardless. Or perhaps forget about the constant check, and just force
the power of two check:
# define roundup_64(x, y) ( \
{ \
typeof(y) __y = y; \
typeof(x) __x; \
\
if (!(__y & (__y >> 1))) { \
__x = round_up(x, y); \
} else {\
__x = (x) + (__y - 1); \
do_div(__x, __y); \
__x = __x * __y;\
} \
__x;\
} \
)
This way even if the compiler doesn't know that this is a power of two,
it will still do the shift if y ends up being one.
-- Steve
Re: [PATCH] drm/todo: Add bootsplash entry
Hi, On Thu, 2019-05-23 at 16:26 +0200, Noralf Trønnes wrote: > Ease entry for anyone wanting to pick up the bootsplash work by providing > a couple of pointers. > > Signed-off-by: Noralf Trønnes I think a native DRM bootsplash would be a great thing to have! Reviewed-by: Paul Kocialkowski Cheers, Paul > --- > Documentation/gpu/todo.rst | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index ab96ba0600a9..05d610321566 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -484,5 +484,19 @@ i915 >device_link_add to model the dependency between i915 and snd_had. See >https://dri.freedesktop.org/docs/drm/driver-api/device_link.html > > +Bootsplash > +== > + > +There is support in place now for writing internal DRM clients making it > +possible to pick up the bootsplash work that was rejected because it was > written > +for fbdev. > + > +- [v6,8/8] drm/client: Hack: Add bootsplash example > + https://patchwork.freedesktop.org/patch/306579/ > + > +- [RFC PATCH v2 00/13] Kernel based bootsplash > + https://lkml.org/lkml/2017/12/13/764 > + > + > Outside DRM > === -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Daniel and Dave, We keep adding support for panels at a high rate, is it still worth listing them individually under cross subsystem changes? First pull req for v5.3 here, enjoy! As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame for the unhandled HDR case in switch, hope it's not too bad or I will send another. :) drm-misc-next-2019-05-23: drm-misc-next for v5.3: UAPI Changes: - Add HDR source metadata property. - Make drm.h compile on GNU/kFreeBSD by including stdint.h - Clarify how the userspace reviewer has to review new kernel UAPI. - Clarify that for using new UAPI, merging to drm-next or drm-misc-next should be enough. Cross-subsystem Changes: - video/hdmi: Add unpack function for DRM infoframes. - Device tree bindings: * Updating a property for Mali Midgard GPUs * Updating a property for STM32 DSI panel * Adding support for FriendlyELEC HD702E 800x1280 panel * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 panel with resistive touch found on TI's AM335X-EVM. * Adding support for EDT ETM0430G0DH6 480x272 panel. - Add OSD101T2587-53TS driver with DT bindings. - Add Samsung S6E63M0 panel driver with DT bindings. - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. - Dma-buf: - Make mmap callback actually optional. - Documentation updates. - Fix debugfs refcount inbalance. - Remove unused sync_dump function. Core Changes: - Add support for HDR infoframes and related EDID parsing. - Remove prime sg_table caching, now done inside dma-buf. - Add shiny new drm_gem_vram helpers for simple VRAM drivers; with some fixes to the new API on top. - Small fix to job cleanup without timeout handler. - Documentation fixes to drm_fourcc. - Replace lookups of drm_format with struct drm_format_info; remove functions that become obsolete by this conversion. - Remove double include in bridge/panel.c and some drivers. - Remove drmP.h include from drm/edid and drm/dp. - Fix null pointer deref in drm_fb_helper_hotplug_event(). - Remove most members from drm_fb_helper_crtc, only mode_set is kept. - Remove race of fb helpers with userspace; only restore mode when userspace is not master. - Move legacy setup from drm_file.c to drm_legacy_misc.c - Rework scheduler job destruction. - drm/bus was removed, remove from TODO. - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, and convert some drivers to use it (conversion is not complete yet). - Bump vblank timeout wait to 100 ms for atomic. Driver Changes: - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. - v3d: Small cleanups, adding support for compute shaders, reservation/synchronization fixes and job management refactoring, fixes MMU and debugfs. - lima: Fix null pointer in irq handler on startup, set default timeout for scheduled jobs. - stm/ltdc: Assorted fixes and adding FB modifier support. - amdgpu: Avoid hw reset if guilty job was already signaled. - virtio: Add seqno to fences, add trace events, use correct flags for fence allocation. - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new drm_gem_vram API. - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. - gma500: header fixes - cirrus: Remove unused files. The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-05-23 for you to fetch changes up to cbb56814fbe7fedd71cd6b29dc83bab2915a5b74: drm/virtio: remove irrelevant DRM_UNLOCKED flag (2019-05-23 12:16:01 +0200) We keep adding support for panels at a high rate, is it still worth listing them individually? drm-misc-next for v5.3: UAPI Changes: - Add HDR source metadata property. - Make drm.h compile on GNU/kFreeBSD by including stdint.h - Clarify how the userspace reviewer has to review new kernel UAPI. - Clarify that for using new UAPI, merging to drm-next or drm-misc-next should be enough. Cross-subsystem Changes: - video/hdmi: Add unpack function for DRM infoframes. - Device tree bindings: * Updating a property for Mali Midgard GPUs * Updating a property for STM32 DSI panel * Adding support for FriendlyELEC HD702E 800x1280 panel * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 panel with resistive touch found on TI's AM335X-EVM. * Adding support for EDT ETM0430G0DH6 480x272 panel. - Add OSD101T2587-53TS driver with DT bindings. - Add Samsung S6E63M0 panel driver with
Re: [PULL] drm-misc-next
On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote: > Hi Daniel and Dave, > > We keep adding support for panels at a high rate, is it still worth listing > them individually under cross subsystem changes? > > First pull req for v5.3 here, enjoy! > As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame for > the unhandled > HDR case in switch, hope it's not too bad or I will send another. :) It's not, but we should wait for Maxime's fix to my botched backmerge [1] in order to avoid propagating the vendor prefixes file zombie to other trees. So can we backburner this until that lands? Sean [1]- https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next&id=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90 > > drm-misc-next-2019-05-23: > > drm-misc-next for v5.3: > > UAPI Changes: > - Add HDR source metadata property. > - Make drm.h compile on GNU/kFreeBSD by including stdint.h > - Clarify how the userspace reviewer has to review new kernel UAPI. > - Clarify that for using new UAPI, merging to drm-next or drm-misc-next > should be enough. > > Cross-subsystem Changes: > - video/hdmi: Add unpack function for DRM infoframes. > - Device tree bindings: > * Updating a property for Mali Midgard GPUs > * Updating a property for STM32 DSI panel > * Adding support for FriendlyELEC HD702E 800x1280 panel > * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel > * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. > * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 panel > with resistive touch found on TI's AM335X-EVM. > * Adding support for EDT ETM0430G0DH6 480x272 panel. > - Add OSD101T2587-53TS driver with DT bindings. > - Add Samsung S6E63M0 panel driver with DT bindings. > - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. > - Dma-buf: > - Make mmap callback actually optional. > - Documentation updates. > - Fix debugfs refcount inbalance. > - Remove unused sync_dump function. > > Core Changes: > - Add support for HDR infoframes and related EDID parsing. > - Remove prime sg_table caching, now done inside dma-buf. > - Add shiny new drm_gem_vram helpers for simple VRAM drivers; > with some fixes to the new API on top. > - Small fix to job cleanup without timeout handler. > - Documentation fixes to drm_fourcc. > - Replace lookups of drm_format with struct drm_format_info; > remove functions that become obsolete by this conversion. > - Remove double include in bridge/panel.c and some drivers. > - Remove drmP.h include from drm/edid and drm/dp. > - Fix null pointer deref in drm_fb_helper_hotplug_event(). > - Remove most members from drm_fb_helper_crtc, only mode_set is kept. > - Remove race of fb helpers with userspace; only restore mode > when userspace is not master. > - Move legacy setup from drm_file.c to drm_legacy_misc.c > - Rework scheduler job destruction. > - drm/bus was removed, remove from TODO. > - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, > and convert some drivers to use it (conversion is not complete yet). > - Bump vblank timeout wait to 100 ms for atomic. > > Driver Changes: > - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. > - v3d: Small cleanups, adding support for compute shaders, >reservation/synchronization fixes and job management refactoring, >fixes MMU and debugfs. > - lima: Fix null pointer in irq handler on startup, set default timeout for > scheduled jobs. > - stm/ltdc: Assorted fixes and adding FB modifier support. > - amdgpu: Avoid hw reset if guilty job was already signaled. > - virtio: Add seqno to fences, add trace events, use correct flags for fence > allocation. > - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new drm_gem_vram > API. > - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. > - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. > - gma500: header fixes > - cirrus: Remove unused files. > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-05-23 > > for you to fetch changes up to cbb56814fbe7fedd71cd6b29dc83bab2915a5b74: > > drm/virtio: remove irrelevant DRM_UNLOCKED flag (2019-05-23 12:16:01 +0200) > > > We keep adding support for panels at a high rate, is it still worth listing > them individually? > > drm-misc-next for v5.3: > > UAPI Changes: > - Add HDR source metadata property. > - Make drm.h compile on GNU/kFreeBSD by including stdint.h > - Clarify how the userspace reviewer has to review new kernel UAPI. > - Clarify that for using new UAPI, merging to drm-next or drm-misc-next > should be enough. > > Cross-subsystem Changes: > - video/hdmi: Add un
Re: [Intel-gfx] [PULL] drm-misc-next
On Thu, May 23, 2019 at 5:53 PM Sean Paul wrote: > > On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote: > > Hi Daniel and Dave, > > > > We keep adding support for panels at a high rate, is it still worth listing > > them individually under cross subsystem changes? > > > > First pull req for v5.3 here, enjoy! > > As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame > > for the unhandled > > HDR case in switch, hope it's not too bad or I will send another. :) > > It's not, but we should wait for Maxime's fix to my botched backmerge [1] in > order to avoid propagating the vendor prefixes file zombie to other trees. > > So can we backburner this until that lands? Yeah I want to land this until that's all settled. Also the hdr kerneldoc fix would be nice to land in this pull too, just for that soothing warning-free experience :-) -Daniel > > Sean > > [1]- > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next&id=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90 > > > > > drm-misc-next-2019-05-23: > > > > drm-misc-next for v5.3: > > > > UAPI Changes: > > - Add HDR source metadata property. > > - Make drm.h compile on GNU/kFreeBSD by including stdint.h > > - Clarify how the userspace reviewer has to review new kernel UAPI. > > - Clarify that for using new UAPI, merging to drm-next or drm-misc-next > > should be enough. > > > > Cross-subsystem Changes: > > - video/hdmi: Add unpack function for DRM infoframes. > > - Device tree bindings: > > * Updating a property for Mali Midgard GPUs > > * Updating a property for STM32 DSI panel > > * Adding support for FriendlyELEC HD702E 800x1280 panel > > * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel > > * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. > > * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 > > panel > > with resistive touch found on TI's AM335X-EVM. > > * Adding support for EDT ETM0430G0DH6 480x272 panel. > > - Add OSD101T2587-53TS driver with DT bindings. > > - Add Samsung S6E63M0 panel driver with DT bindings. > > - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. > > - Dma-buf: > > - Make mmap callback actually optional. > > - Documentation updates. > > - Fix debugfs refcount inbalance. > > - Remove unused sync_dump function. > > > > Core Changes: > > - Add support for HDR infoframes and related EDID parsing. > > - Remove prime sg_table caching, now done inside dma-buf. > > - Add shiny new drm_gem_vram helpers for simple VRAM drivers; > > with some fixes to the new API on top. > > - Small fix to job cleanup without timeout handler. > > - Documentation fixes to drm_fourcc. > > - Replace lookups of drm_format with struct drm_format_info; > > remove functions that become obsolete by this conversion. > > - Remove double include in bridge/panel.c and some drivers. > > - Remove drmP.h include from drm/edid and drm/dp. > > - Fix null pointer deref in drm_fb_helper_hotplug_event(). > > - Remove most members from drm_fb_helper_crtc, only mode_set is kept. > > - Remove race of fb helpers with userspace; only restore mode > > when userspace is not master. > > - Move legacy setup from drm_file.c to drm_legacy_misc.c > > - Rework scheduler job destruction. > > - drm/bus was removed, remove from TODO. > > - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, > > and convert some drivers to use it (conversion is not complete yet). > > - Bump vblank timeout wait to 100 ms for atomic. > > > > Driver Changes: > > - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. > > - v3d: Small cleanups, adding support for compute shaders, > >reservation/synchronization fixes and job management refactoring, > >fixes MMU and debugfs. > > - lima: Fix null pointer in irq handler on startup, set default timeout for > > scheduled jobs. > > - stm/ltdc: Assorted fixes and adding FB modifier support. > > - amdgpu: Avoid hw reset if guilty job was already signaled. > > - virtio: Add seqno to fences, add trace events, use correct flags for > > fence allocation. > > - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new drm_gem_vram > > API. > > - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. > > - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. > > - gma500: header fixes > > - cirrus: Remove unused files. > > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > > > are available in the Git repository at: > > > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-05-23 > > > > for you to fetch changes up to cbb56814fbe7fedd71cd6b29dc83bab2915a5b74: > > > > drm/virtio: remove irrelevant DRM_UNLOCKED flag (2019-05-23 12:16:01 > > +0200) > > > > > > We keep adding support for p
Re: [Intel-gfx] [PULL] drm-misc-next
On Thu, May 23, 2019 at 5:55 PM Daniel Vetter wrote: > > On Thu, May 23, 2019 at 5:53 PM Sean Paul wrote: > > > > On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote: > > > Hi Daniel and Dave, > > > > > > We keep adding support for panels at a high rate, is it still worth > > > listing them individually under cross subsystem changes? > > > > > > First pull req for v5.3 here, enjoy! > > > As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame > > > for the unhandled > > > HDR case in switch, hope it's not too bad or I will send another. :) > > > > It's not, but we should wait for Maxime's fix to my botched backmerge [1] in > > order to avoid propagating the vendor prefixes file zombie to other trees. > > > > So can we backburner this until that lands? > > Yeah I want to land this until that's all settled. Also the hdr /me not English I want to _not_ land this until ... ofc. -Daniel > kerneldoc fix would be nice to land in this pull too, just for that > soothing warning-free experience :-) > -Daniel > > > > > Sean > > > > [1]- > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next&id=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90 > > > > > > > > drm-misc-next-2019-05-23: > > > > > > drm-misc-next for v5.3: > > > > > > UAPI Changes: > > > - Add HDR source metadata property. > > > - Make drm.h compile on GNU/kFreeBSD by including stdint.h > > > - Clarify how the userspace reviewer has to review new kernel UAPI. > > > - Clarify that for using new UAPI, merging to drm-next or drm-misc-next > > > should be enough. > > > > > > Cross-subsystem Changes: > > > - video/hdmi: Add unpack function for DRM infoframes. > > > - Device tree bindings: > > > * Updating a property for Mali Midgard GPUs > > > * Updating a property for STM32 DSI panel > > > * Adding support for FriendlyELEC HD702E 800x1280 panel > > > * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel > > > * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB > > > TFT. > > > * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 > > > panel > > > with resistive touch found on TI's AM335X-EVM. > > > * Adding support for EDT ETM0430G0DH6 480x272 panel. > > > - Add OSD101T2587-53TS driver with DT bindings. > > > - Add Samsung S6E63M0 panel driver with DT bindings. > > > - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. > > > - Dma-buf: > > > - Make mmap callback actually optional. > > > - Documentation updates. > > > - Fix debugfs refcount inbalance. > > > - Remove unused sync_dump function. > > > > > > Core Changes: > > > - Add support for HDR infoframes and related EDID parsing. > > > - Remove prime sg_table caching, now done inside dma-buf. > > > - Add shiny new drm_gem_vram helpers for simple VRAM drivers; > > > with some fixes to the new API on top. > > > - Small fix to job cleanup without timeout handler. > > > - Documentation fixes to drm_fourcc. > > > - Replace lookups of drm_format with struct drm_format_info; > > > remove functions that become obsolete by this conversion. > > > - Remove double include in bridge/panel.c and some drivers. > > > - Remove drmP.h include from drm/edid and drm/dp. > > > - Fix null pointer deref in drm_fb_helper_hotplug_event(). > > > - Remove most members from drm_fb_helper_crtc, only mode_set is kept. > > > - Remove race of fb helpers with userspace; only restore mode > > > when userspace is not master. > > > - Move legacy setup from drm_file.c to drm_legacy_misc.c > > > - Rework scheduler job destruction. > > > - drm/bus was removed, remove from TODO. > > > - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, > > > and convert some drivers to use it (conversion is not complete yet). > > > - Bump vblank timeout wait to 100 ms for atomic. > > > > > > Driver Changes: > > > - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. > > > - v3d: Small cleanups, adding support for compute shaders, > > >reservation/synchronization fixes and job management refactoring, > > >fixes MMU and debugfs. > > > - lima: Fix null pointer in irq handler on startup, set default timeout > > > for scheduled jobs. > > > - stm/ltdc: Assorted fixes and adding FB modifier support. > > > - amdgpu: Avoid hw reset if guilty job was already signaled. > > > - virtio: Add seqno to fences, add trace events, use correct flags for > > > fence allocation. > > > - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new > > > drm_gem_vram API. > > > - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. > > > - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. > > > - gma500: header fixes > > > - cirrus: Remove unused files. > > > The following changes since commit > > > a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > > > > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > > > > > are available in the Git repository at: > > > > > >
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
On Thu, May 23, 2019 at 6:54 AM Maxime Ripard wrote:
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
> >
> > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> >
> > from Linus' tree and commits:
> >
> > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > S9700RTWV43TR-01B")
> > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
> >
> > from the drm-misc tree.
> >
> > I fixed it up (I deleted the file and added the patch 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.
>
> I just took your patch and pushed a temp branch there:
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next&id=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90
>
> Rob, Stephen, are you ok with the change? If so, I'll push it.
The 'tfc' line is missing a ':' on the end. Does the file pass
dt_binding_check like that?
Rob
[PATCH] drm/i915: Maintain consistent documentation subsection ordering
With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the docs build fails with: Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent: Global GTT Fence Handling ~ reST markup error: Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent: I "fixed" it by changing the subsections in i915.rst, but that didn't seem like the correct change. It turns out that a couple of i915 files create their own subsections in kerneldoc comments using apostrophes as the heading marker: Layout '' That breaks the normal subsection marker ordering, and newer Sphinx is rather more strict about enforcing that ordering. So fix the offending comments to make Sphinx happy. (This is unfortunate, in that kerneldoc comments shouldn't need to be aware of where they might be included in the heading hierarchy, but I don't see a better way around it). Signed-off-by: Jonathan Corbet --- [If I can possibly get an ack for this, I would like to send it up soon with the other Sphinx-related fixes.] drivers/gpu/drm/i915/i915_reg.h | 6 +++--- drivers/gpu/drm/i915/intel_workarounds.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b74824f0b5b1..249d35c12a75 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -35,7 +35,7 @@ * macros. Do **not** mass change existing definitions just to update the style. * * Layout - * '' + * ~~ * * Keep helper macros near the top. For example, _PIPE() and friends. * @@ -79,7 +79,7 @@ * style. Use lower case in hexadecimal values. * * Naming - * '' + * ~~ * * Try to name registers according to the specs. If the register name changes in * the specs from platform to another, stick to the original name. @@ -97,7 +97,7 @@ * suffix to the name. For example, ``_SKL`` or ``_GEN8``. * * Examples - * + * * * (Note that the values in the example are indented using spaces instead of * TABs to avoid misalignment in generated documentation. Use TABs in the diff --git a/drivers/gpu/drm/i915/intel_workarounds.c b/drivers/gpu/drm/i915/intel_workarounds.c index 9682dd575152..6decd432f4d3 100644 --- a/drivers/gpu/drm/i915/intel_workarounds.c +++ b/drivers/gpu/drm/i915/intel_workarounds.c @@ -37,7 +37,7 @@ *costly and simplifies things. We can revisit this in the future. * * Layout - * '' + * ~~ * * Keep things in this file ordered by WA type, as per the above (context, GT, * display, register whitelist, batchbuffer). Then, inside each type, keep the -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
On Thu, May 23, 2019 at 03:44:49PM +0100, Catalin Marinas wrote: > There is also the obvious requirement which I didn't mention: new user > space continues to run on new/subsequent kernel versions. That's one of > the points of contention for this series (ignoring MTE) with the > maintainers having to guarantee this without much effort. IOW, do the > 500K+ new lines in a subsequent kernel version break any user space out > there? I'm only talking about the relaxed TBI ABI. Are the usual LTP, > syskaller sufficient? Better static analysis would definitely help. We can't have perfect coverage of people actively (or accidentally) working to trick static analyzers (and the compiler) into "forgetting" about a __user annotation. We can certainly improve analysis (I see the other sub-thread on that), but I'd like that work not to block this series. What on this front would you be comfortable with? Given it's a new feature isn't it sufficient to have a CONFIG (and/or boot option)? > Or, if we ever want MTE to be turned on by default (i.e. tag checking), > even if everything is tagged with 0, we have to disallow TBI for user > and this includes hwasan. There were a small number of programs using > the TBI (I think some JavaScript compilers tried this). But now we are > bringing in the hwasan support and this can be a large user base. Shall > we add an ELF note for such binaries that use TBI/hwasan? Just to be clear, you say "disallow TBI for user" -- you mean a particular process, yes? i.e. there is no architectural limitation that says once we're using MTE nothing can switch to TBI. i.e. a process is either doing MTE or TBI (or nothing, but that's the same as TBI). > This needs solving as well. Most driver developers won't know why > untagged_addr() is needed unless we have more rigorous types or type > annotations and a tool to check them (we should probably revive the old > sparse thread). This seems like a parallel concern: we can do that separately from this series. Without landing it, is it much harder for people to test it, look for bugs, help with types/annotations, etc. > > So there needs to be some way to let the kernel know which of three > > things it should be doing: > > 1- leaving userspace addresses as-is (present) > > 2- wiping the top bits before using (this series) > > (I'd say tolerating rather than wiping since get_user still uses the tag > in the current series) > > The current series does not allow any choice between 1 and 2, the > default ABI basically becomes option 2. What about testing tools that intentionally insert high bits for syscalls and are _expecting_ them to fail? It seems the TBI series will break them? In that case, do we need to opt into TBI as well? > > 3- wiping the top bits for most things, but retaining them for MTE as > >needed (the future) > > 2 and 3 are not entirely compatible as a tagged pointer may be checked > against the memory colour by the hardware. So you can't have hwasan > binary with MTE enabled. Right: a process must be either MTE or TBI, not both. > > I expect MTE to be the "default" in the future. Once a system's libc has > > grown support for it, everything will be trying to use MTE. TBI will be > > the special case (but TBI is effectively a prerequisite). > > The kernel handling of tagged pointers is indeed a prerequisite. The ABI > distinction between the above 2 and 3 needs to be solved. Does that need solving now or when the MTE series appears? As there is no reason to distinguish between "normal" and "TBI", that doesn't seem to need solving at this point? > > AFAICT, the only difference I see between 2 and 3 will be the tag handling > > in usercopy (all other places will continue to ignore the top bits). Is > > that accurate? > > Yes, mostly (for the kernel). If MTE is enabled by default for a hwasan > binary, it will SEGFAULT (either in user space or in kernel uaccess). > How does the kernel choose between 2 and 3? Right -- that was my question as well. > > Is "1" a per-process state we want to keep? (I assume not, but rather it > > is available via no TBI/MTE CONFIG or a boot-time option, if at all?) > > Possibly, though not necessarily per process. For testing or if > something goes wrong during boot, a command line option with a static > label would do. The AT_FLAGS bit needs to be checked by user space. My > preference would be per-process. I would agree. > > To choose between "2" and "3", it seems we need a per-process flag to > > opt into TBI (and out of MTE). > > Or leave option 2 the default and get it to opt in to MTE. Given that MTE has to "start" at some point in the binary lifetime, I'm fine with opting into MTE. I do expect, though, this will feel redundant in a couple years as everything will immediately opt-in. But, okay, this is therefore an issue for the MTE series. > The current plan is that a future binary issues a prctl(), after > checking the HWCAP_MTE bit (as I replied to Elliot, the MTE instruction
Re: [PATCH v6 0/8] drm/fb-helper: Move modesetting code to drm_client
Hi Linus, Gerd. > This moves the modesetting code from drm_fb_helper to drm_client so it > can be shared by all internal clients. Could one of you take a look at this series. Daniel already ack'ed the series on irc, but an extra pair of eyes is never bad. For my part I have been through them all, but I still do not have the full picture of the DRM subsystem so my review may not suffice. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
>
> I haven't yet tested this, but what about something like the following:
So that at least handles the constant case that the normal "roundup()"
case also handles.
At the same time, in the case you are talking about, I really do
suspect that we have a (non-constant) power of two, and that you
should have just used "round_up()" which works fine regardless of
size, and is always efficient.
On a slight tangent.. Maybe we should have something like this:
#define size_fn(x, prefix, ...) ({ \
typeof(x) __ret;\
switch (sizeof(x)) {\
case 1: __ret = prefix##8(__VA_ARGS__); break; \
case 2: __ret = prefix##16(__VA_ARGS__); break; \
case 4: __ret = prefix##32(__VA_ARGS__); break; \
case 8: __ret = prefix##64(__VA_ARGS__); break; \
default: __ret = prefix##bad(__VA_ARGS__); \
} __ret; })
#define type_fn(x, prefix, ...) ({ \
typeof(x) __ret;\
if ((typeof(x))-1 > 1) \
__ret = size_fn(x, prefix##_u, __VA_ARGS__);\
else\
__ret = size_fn(x, prefix##_s, __VA_ARGS__);\
__ret; })
which would allow typed integer functions like this. So you could do
something like
#define round_up(x, y) size_fn(x, round_up_size, x, y)
and then you define functions for round_up_size8/16/32/64 (and you
have toi declare - but not define - round_up_sizebad()).
Of course, you probably want the usual "at least use 'int'" semantics,
in which case the "type" should be "(x)+0":
#define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
and the 8-bit and 16-bit cases will never be used.
We have a lot of cases where we end up using "type overloading" by
size. The most explicit case is perhaps "get_user()" and "put_user()",
but this whole round_up thing is another example.
Maybe we never really care about "char" and "short", and always want
just the "int-vs-long-vs-longlong"? That would make the cases simpler
(32 and 64). And maybe we never care about sign. But we could try to
have some unified helper model like the above..
Linus
Re: [PATCH] drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()
On Thu, May 23, 2019 at 02:38:37PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Sean Paul [mailto:s...@poorly.run]
> >Sent: Thursday, May 23, 2019 7:25 PM
> >To: dri-devel@lists.freedesktop.org
> >Cc: Sean Paul ; Shankar, Uma ;
> >Sharma, Shashank ; Ville Syrjälä
> >; Maarten Lankhorst
> >; Maxime Ripard
> >; Sean Paul ; David Airlie
> >; Daniel Vetter ; Bartlomiej
> >Zolnierkiewicz
> >; Hans Verkuil ; linux-
> >fb...@vger.kernel.org
> >Subject: [PATCH] drm/edid: Fix docbook in
> >drm_hdmi_infoframe_set_hdr_metadata()
> >
> >From: Sean Paul
> >
> >Fixes the following warnings:
> >../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member
> >'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
> >../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter
> >'hdr_metadata' description in 'drm_hdmi_infoframe_set_hdr_metadata'
>
> Thanks Sean Paul for fixing this.
> Reviewed-by: Uma Shankar
Pushed to -misc-next, thank you for the review!
Sean
>
> >Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
> >Cc: Uma Shankar
> >Cc: Shashank Sharma
> >Cc: Ville Syrjälä
> >Cc: Maarten Lankhorst
> >Cc: Maxime Ripard
> >Cc: Sean Paul
> >Cc: David Airlie
> >Cc: Daniel Vetter
> >Cc: Bartlomiej Zolnierkiewicz
> >Cc: "Ville Syrjälä"
> >Cc: Hans Verkuil
> >Cc: dri-devel@lists.freedesktop.org
> >Cc: linux-fb...@vger.kernel.org
> >Signed-off-by: Sean Paul
> >---
> > drivers/gpu/drm/drm_edid.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> >262510c2a670..d87f574feeca 100644
> >--- a/drivers/gpu/drm/drm_edid.c
> >+++ b/drivers/gpu/drm/drm_edid.c
> >@@ -4914,7 +4914,7 @@ static inline bool is_eotf_supported(u8 output_eotf, u8
> >sink_eotf)
> > * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
> > * HDR metadata from userspace
> > * @frame: HDMI DRM infoframe
> >- * @hdr_metadata: hdr_source_metadata info from userspace
> >+ * @conn_state: Connector state containing HDR metadata
> > *
> > * Return: 0 on success or a negative error code on failure.
> > */
> >--
> >Sean Paul, Software Engineer, Google / Chromium OS
>
--
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] drm/mediatek: Fix warning about unhandled enum value
On Thu, May 23, 2019 at 02:13:20PM +0800, CK Hu wrote:
> Hi, Sean:
>
> On Wed, 2019-05-22 at 16:21 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > Fixes the following build warning:
> > drivers/gpu/drm/mediatek/mtk_hdmi.c:327:2: warning: enumeration value
> > ‘HDMI_INFOFRAME_TYPE_DRM’ not handled in switch [-Wswitch]
> >
> > Introduced with the addition of HDMI_INFOFRAME_TYPE_DRM in the commit
> > below, but the code really should have been future-proofed from the
> > start.
>
> Acked-by: CK Hu
>
> >
> > Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
>
> I think "drm: Enable HDR infoframe support" exist only in drm-misc tree,
> could you just merge this patch to "drm: Enable HDR infoframe support"?
Yes, I've applied it to drm-misc-next. Thanks for your Ack!
Sean
>
> Regards,
> CK
>
> > Cc: Uma Shankar
> > Cc: Shashank Sharma
> > Cc: Ville Syrjälä
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: "Ville Syrjälä"
> > Cc: Hans Verkuil
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Sean Paul
> > ---
> > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index e04e6c293d39..10cc9910f164 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -341,6 +341,9 @@ static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi
> > *hdmi, u8 *buffer,
> > ctrl_frame_en = VS_EN;
> > ctrl_reg = GRL_ACP_ISRC_CTRL;
> > break;
> > + default:
> > + dev_err(hdmi->dev, "Unknown infoframe type %d\n", frame_type);
> > + return;
> > }
> > mtk_hdmi_clear_bits(hdmi, ctrl_reg, ctrl_frame_en);
> > mtk_hdmi_write(hdmi, GRL_INFOFRM_TYPE, frame_type);
>
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/msm/a6xx: Rename a6xx_gmu_probe to a6xx_gmu_init
From: Sean Paul
This rename makes it more clear that everything initialized in the _init
function must be cleaned up in a6xx_gmu_remove. This will hopefully
dissuade people from using device managed resources (for reasons laid
out in the previous patch).
Changes in v2:
- None
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index e2b839b5d3bd..5ab69dcd5479 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1259,7 +1259,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
gmu->initialized = false;
}
-int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
+int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
{
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
struct platform_device *pdev = of_find_device_by_node(node);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index e74dce474250..1f9f4b0a9656 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -854,7 +854,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
/* FIXME: How do we gracefully handle this? */
BUG_ON(!node);
- ret = a6xx_gmu_probe(a6xx_gpu, node);
+ ret = a6xx_gmu_init(a6xx_gpu, node);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index b46279eb18c5..64399554f2dd 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -53,7 +53,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu);
int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
-int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
+int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu);
void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/msm/a6xx: Remove duplicate irq disable from remove
From: Sean Paul a6xx_gmu_stop() already calls this function via shutdown or force_stop, so it's not necessary to call it twice. Previously this would have knocked the irq refcount out of sync, but now with the irqs_enabled flag it's just housekeeping. Changes in v2: - None Cc: Jordan Crouse Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index aa84edb25d91..742c8ff9a61c 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -1239,7 +1239,6 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) dev_pm_domain_detach(gmu->gxpd, false); } - a6xx_gmu_irq_disable(gmu); a6xx_gmu_memory_free(gmu, gmu->hfi); iommu_detach_device(gmu->domain, gmu->dev); -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/msm/a6xx: Remove devm calls from gmu driver
From: Sean Paul
The gmu driver is initialized and cleaned up with calls from the gpu driver. As
such, the platform device stays valid after a6xx_gmu_remove is called and the
device managed resources are not freed. In the case of gpu probe failures or
unbind, these resources will remain managed.
If the gpu bind is run again (eg: if there's a probe defer somewhere in msm),
these resources will be initialized again for the same device, creating multiple
references. In the case of irqs, this causes failures since the irqs are
not shared (nor should they be).
This patch removes all devm_* calls and manually cleans things up in
gmu_remove.
Changes in v2:
- Add iounmap and free_irq to gmu_probe error paths
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 33 ++-
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 7465423e9b71..f7240c9e11fb 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -505,9 +505,9 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
err:
if (!IS_ERR_OR_NULL(pdcptr))
- devm_iounmap(gmu->dev, pdcptr);
+ iounmap(pdcptr);
if (!IS_ERR_OR_NULL(seqptr))
- devm_iounmap(gmu->dev, seqptr);
+ iounmap(seqptr);
}
/*
@@ -1197,7 +1197,7 @@ static void __iomem *a6xx_gmu_get_mmio(struct
platform_device *pdev,
return ERR_PTR(-EINVAL);
}
- ret = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ ret = ioremap(res->start, resource_size(res));
if (!ret) {
DRM_DEV_ERROR(&pdev->dev, "Unable to map the %s registers\n",
name);
return ERR_PTR(-EINVAL);
@@ -1213,10 +1213,10 @@ static int a6xx_gmu_get_irq(struct a6xx_gmu *gmu,
struct platform_device *pdev,
irq = platform_get_irq_byname(pdev, name);
- ret = devm_request_irq(&pdev->dev, irq, handler, IRQF_TRIGGER_HIGH,
- name, gmu);
+ ret = request_irq(irq, handler, IRQF_TRIGGER_HIGH, name, gmu);
if (ret) {
- DRM_DEV_ERROR(&pdev->dev, "Unable to get interrupt %s\n", name);
+ DRM_DEV_ERROR(&pdev->dev, "Unable to get interrupt %s %d\n",
+ name, ret);
return ret;
}
@@ -1241,12 +1241,18 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
dev_pm_domain_detach(gmu->gxpd, false);
}
+ iounmap(gmu->mmio);
+ gmu->mmio = NULL;
+
a6xx_gmu_memory_free(gmu, gmu->hfi);
iommu_detach_device(gmu->domain, gmu->dev);
iommu_domain_free(gmu->domain);
+ free_irq(gmu->gmu_irq, gmu);
+ free_irq(gmu->hfi_irq, gmu);
+
gmu->initialized = false;
}
@@ -1281,24 +1287,24 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
/* Allocate memory for for the HFI queues */
gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K);
if (IS_ERR(gmu->hfi))
- goto err;
+ goto err_memory;
/* Allocate memory for the GMU debug region */
gmu->debug = a6xx_gmu_memory_alloc(gmu, SZ_16K);
if (IS_ERR(gmu->debug))
- goto err;
+ goto err_memory;
/* Map the GMU registers */
gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
if (IS_ERR(gmu->mmio))
- goto err;
+ goto err_memory;
/* Get the HFI and GMU interrupts */
gmu->hfi_irq = a6xx_gmu_get_irq(gmu, pdev, "hfi", a6xx_hfi_irq);
gmu->gmu_irq = a6xx_gmu_get_irq(gmu, pdev, "gmu", a6xx_gmu_irq);
if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0)
- goto err;
+ goto err_mmio;
/*
* Get a link to the GX power domain to reset the GPU in case of GMU
@@ -1315,7 +1321,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
gmu->initialized = true;
return 0;
-err:
+
+err_mmio:
+ iounmap(gmu->mmio);
+ free_irq(gmu->gmu_irq, gmu);
+ free_irq(gmu->hfi_irq, gmu);
+err_memory:
a6xx_gmu_memory_free(gmu, gmu->hfi);
if (gmu->domain) {
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] drm/msm/a6xx: Drop the device reference in gmu
From: Sean Paul of_find_device_by_node() grabs a dev reference, so make sure we clear it on error and remove. Changes in v2: - Added to the set (Jordan) Cc: Jordan Crouse Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index f7240c9e11fb..e2b839b5d3bd 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -1253,6 +1253,9 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) free_irq(gmu->gmu_irq, gmu); free_irq(gmu->hfi_irq, gmu); + /* Drop reference taken in of_find_device_by_node */ + put_device(gmu->dev); + gmu->initialized = false; } @@ -1277,12 +1280,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node) /* Get the list of clocks */ ret = a6xx_gmu_clocks_probe(gmu); if (ret) - return ret; + goto err_put_device; /* Set up the IOMMU context bank */ ret = a6xx_gmu_memory_probe(gmu); if (ret) - return ret; + goto err_put_device; /* Allocate memory for for the HFI queues */ gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K); @@ -1334,6 +1337,11 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node) iommu_domain_free(gmu->domain); } + ret = -ENODEV; - return -ENODEV; +err_put_device: + /* Drop reference taken in of_find_device_by_node */ + put_device(gmu->dev); + + return ret; } -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/msm/a6xx: Check for ERR or NULL before iounmap
From: Sean Paul pdcptr and seqptr aren't necessarily valid, check them before trying to unmap them. Changes in v2: - None Cc: Jordan Crouse Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index 742c8ff9a61c..7465423e9b71 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -504,8 +504,10 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu) wmb(); err: - devm_iounmap(gmu->dev, pdcptr); - devm_iounmap(gmu->dev, seqptr); + if (!IS_ERR_OR_NULL(pdcptr)) + devm_iounmap(gmu->dev, pdcptr); + if (!IS_ERR_OR_NULL(seqptr)) + devm_iounmap(gmu->dev, seqptr); } /* -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/msm/a6xx: Avoid freeing gmu resources multiple times
From: Sean Paul
The driver checks for gmu->mmio as a sign that the device has been
initialized, however there are failures in probe below the mmio init.
If one of those is hit, mmio will be non-null but freed.
In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
will in turn call a6xx_gmu_remove which checks gmu->mmio and tries to free
resources for a second time. This causes a great boom.
Fix this by adding an initialized member to gmu which is set on
successful probe and cleared on removal.
Changes in v2:
- None
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 38e2cfa9cec7..aa84edb25d91 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -74,7 +74,7 @@ bool a6xx_gmu_sptprac_is_on(struct a6xx_gmu *gmu)
u32 val;
/* This can be called from gpu state code so make sure GMU is valid */
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return false;
val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
@@ -90,7 +90,7 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
u32 val;
/* This can be called from gpu state code so make sure GMU is valid */
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return false;
val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
@@ -695,7 +695,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
int status, ret;
- if (WARN(!gmu->mmio, "The GMU is not set up yet\n"))
+ if (WARN(!gmu->initialized, "The GMU is not set up yet\n"))
return 0;
gmu->hung = false;
@@ -765,7 +765,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
{
u32 reg;
- if (!gmu->mmio)
+ if (!gmu->initialized)
return true;
reg = gmu_read(gmu, REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS);
@@ -1227,7 +1227,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
{
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return;
a6xx_gmu_stop(a6xx_gpu);
@@ -1245,6 +1245,8 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
iommu_detach_device(gmu->domain, gmu->dev);
iommu_domain_free(gmu->domain);
+
+ gmu->initialized = false;
}
int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
@@ -1309,6 +1311,8 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
/* Set up the HFI queues */
a6xx_hfi_init(gmu);
+ gmu->initialized = true;
+
return 0;
err:
a6xx_gmu_memory_free(gmu, gmu->hfi);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index bedd8e6a63aa..39a26dd63674 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -75,6 +75,7 @@ struct a6xx_gmu {
struct a6xx_hfi_queue queues[2];
+ bool initialized;
bool hung;
};
--
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: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, 23 May 2019 09:51:29 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
>
> So that at least handles the constant case that the normal "roundup()"
> case also handles.
>
> At the same time, in the case you are talking about, I really do
> suspect that we have a (non-constant) power of two, and that you
> should have just used "round_up()" which works fine regardless of
> size, and is always efficient.
I think you are correct in this.
act_size = roundup_64(attr->length, MLX5_SW_ICM_BLOCK_SIZE(dm_db->dev));
Where we have:
#define MLX5_SW_ICM_BLOCK_SIZE(dev) (1 << MLX5_LOG_SW_ICM_BLOCK_SIZE(dev))
Which pretty much guarantees that it is a power of two. Thus, the real
fix here is simply to s/roundup/round_up/ as you suggest.
>
> On a slight tangent.. Maybe we should have something like this:
>
> #define size_fn(x, prefix, ...) ({ \
> typeof(x) __ret;\
> switch (sizeof(x)) {\
> case 1: __ret = prefix##8(__VA_ARGS__); break; \
> case 2: __ret = prefix##16(__VA_ARGS__); break; \
> case 4: __ret = prefix##32(__VA_ARGS__); break; \
> case 8: __ret = prefix##64(__VA_ARGS__); break; \
> default: __ret = prefix##bad(__VA_ARGS__); \
> } __ret; })
>
> #define type_fn(x, prefix, ...) ({ \
> typeof(x) __ret;\
> if ((typeof(x))-1 > 1) \
> __ret = size_fn(x, prefix##_u, __VA_ARGS__);\
> else\
> __ret = size_fn(x, prefix##_s, __VA_ARGS__);\
> __ret; })
>
> which would allow typed integer functions like this. So you could do
> something like
>
> #define round_up(x, y) size_fn(x, round_up_size, x, y)
>
> and then you define functions for round_up_size8/16/32/64 (and you
You mean define functions for round_up_size_{u|s}8/16/32/64
> have toi declare - but not define - round_up_sizebad()).
>
> Of course, you probably want the usual "at least use 'int'" semantics,
> in which case the "type" should be "(x)+0":
>
> #define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
>
> and the 8-bit and 16-bit cases will never be used.
I'm curious to what the advantage of that is?
>
> We have a lot of cases where we end up using "type overloading" by
> size. The most explicit case is perhaps "get_user()" and "put_user()",
> but this whole round_up thing is another example.
>
> Maybe we never really care about "char" and "short", and always want
> just the "int-vs-long-vs-longlong"? That would make the cases simpler
> (32 and 64). And maybe we never care about sign. But we could try to
> have some unified helper model like the above..
It may be simpler and perhaps more robust if we keep the char and short
cases.
I'm fine with adding something like this for round_up(), but do we want
to have a generic roundup_64() as well? I'm also thinking that we
perhaps should test for power of two on roundup():
#define roundup(x, y) ( \
{ \
typeof(y) __y = y; \
typeof(x) __x; \
\
if (__y & (__y - 1))\
__x = round_up(x, __y); \
else\
__x = (((x) + (__y - 1)) / __y) * __y; \
__x;\
})
-- Steve
[Bug 110217] RX580: screen turns black or flickers until forced reconfiguration
https://bugs.freedesktop.org/show_bug.cgi?id=110217 --- Comment #3 from numz...@yandex.ru --- New information: 1. Screen turns black at module insertion, be it during bootup or later. But resuming from hibernation works. 2. On the system, the converter I use is problematic itself. When I connect it to another PC, HDMI port is shown as “connected” *until* I connect a monitor to the converter. Then, everything works but HDMI port is displayed as “disconnected” in xrandr. After updating the system, flicker seems to happen in X only, despite the “TearFree” option. Virtual consoles work well, albeit use the same mode (i.e. no mode change on VT switch). Not sure was that the case earlier. Also, after last hibernation, the old trick with resetting mode didn’t help, flicker continues. New X instances flicker as well. New kernel: Linux 5.1.2-arch1-1-ARCH New X driver: xf86-video-amdgpu 19.0.1-1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110217] RX580: screen turns black or flickers until forced reconfiguration
https://bugs.freedesktop.org/show_bug.cgi?id=110217 --- Comment #4 from numz...@yandex.ru --- Just downgraded xf86-video-amdgpu back to 19.0.0-1. The flicker disappeared. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 --- Comment #1 from Mathieu Belanger --- I have the same bug It started yesterday after a reboot. Between the reboot and the previous reboot I did emerge -e the whole things so I'm not totally sure it's mesa related I have the bug in: * Discord (only the rotating Discord logo when I load it, it spin like 30x on itself in the same amount of time it usually spin one time on itself.) * Brave browser (corruptopia like OP screen shot) * Chromium (partially, just the scroll bar) @Zak, is there is something else you also updated recently? Like libdrm, xorg parts, llvm? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 --- Comment #2 from Mathieu Belanger --- Created attachment 144332 --> https://bugs.freedesktop.org/attachment.cgi?id=144332&action=edit Brave browser Here a screenshot of a Brave browser tab -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 --- Comment #3 from Mathieu Belanger --- I would also add that the previous git version I did compile did not have the problem (Fri May 10 17:39:53 2019) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/8] drm/fb-helper: Remove drm_fb_helper_crtc
Den 23.05.2019 15.44, skrev Noralf Trønnes:
> struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
> use that directly instead and attach it as a modeset array onto
> drm_client_dev. drm_fb_helper will use this array to store its modesets
> which means it will always initialize a drm_client, but it will not
> register the client (callbacks) unless it's the generic fbdev emulation.
>
> Code will later be moved to drm_client, so add code there in a new file
> drm_client_modeset.c with MIT license to match drm_fb_helper.c.
>
> The modeset connector array size is hardcoded for the cloned case to avoid
> having to pass in a value from the driver. A value of 8 is chosen to err
> on the safe side. This means that the max connector argument for
> drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore,
> a todo entry for this is added.
>
> In pan_display_atomic() restore_fbdev_mode_force() is used instead of
> restore_fbdev_mode_atomic() because that one will later become internal
> to drm_client_modeset.
>
> Locking order:
> 1. drm_fb_helper->lock
> 2. drm_master_internal_acquire
> 3. drm_client_dev->modeset_mutex
>
> v6: Improve commit message (Sam Ravnborg)
>
> v3:
> - Use full drm_client_init/release for the modesets (Daniel Vetter)
> - drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter)
> - Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter)
>
> v2:
> - Add modesets array to drm_client (Daniel Vetter)
> - Use a new file for the modeset code (Daniel Vetter)
> - File has to be MIT licensed (Emmanuel Vadot)
> - Add copyrights from drm_fb_helper.c
>
> Signed-off-by: Noralf Trønnes
> Reviewed-by: Sam Ravnborg
> ---
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 4c3dc4268b65..9ead6436fb87 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -17,7 +17,7 @@ drm-y := drm_auth.o drm_cache.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> - drm_atomic_uapi.o
> + drm_client_modeset.o drm_atomic_uapi.o
The Intel CI informed me that this didn't apply on drm-tip.
There's commit 6498bf5800a3 ("drm: revocation check at drm subsystem")
coming in from drm-intel-next that conflicts. It's not in drm-next yet.
I won't be able to respin this for a week or so, so maybe by that time
it has even been backmerged into drm-misc-next.
Noralf.
>
> drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
> drm_dma.o drm_scatter.o drm_lock.o
> drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #13 from Mathieu Belanger --- That bug was affecting Discord, Brave and Chromium. Fixed by reverting : 811fa9a79cf -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 Mathieu Belanger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Mathieu Belanger --- *** This bug has been marked as a duplicate of bug 110721 *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
