[PATCH v3 5/6] ARM: dts: msm8974: add display support
Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 132
1 file changed, 132 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..3f613c5b95a1 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1085,6 +1086,137 @@
};
};
};
+
+ mdss: mdss@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>,
+ <0xfd924000 0x1000>;
+ reg-names = "mdss_phys",
+ "vbif_phys";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdp: mdp@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <>;
+ interrupts = <0 0>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_MDP_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint =
<_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@fd922800 {
+ status = "disabled";
+
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+ assigned-clocks = < BYTE0_CLK_SRC>,
+ < PCLK0_CLK_SRC>;
+ assigned-clock-parents = <_phy0 0>,
+<_phy0 1>;
+
+ clocks = < MDSS_MDP_CLK>,
+< MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_BYTE0_CLK>,
+< MDSS_PCLK0_CLK>,
+< MDSS_ESC0_CLK>,
+< MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core",
+ "core_mmss";
+
+ phys = <_phy0>;
+ phy-names = "dsi-phy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
[PATCH v3 4/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight
Add necessary device tree nodes for the main LCD backlight.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index 1fd9f429f34a..51889d66b55a 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -290,6 +290,16 @@
};
};
+ i2c11_pins: i2c11 {
+ mux {
+ pins = "gpio83", "gpio84";
+ function = "blsp_i2c11";
+
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
i2c12_pins: i2c12 {
mux {
pins = "gpio87", "gpio88";
@@ -400,6 +410,30 @@
};
};
+ i2c@f9967000 {
+ status = "ok";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ clock-frequency = <355000>;
+ qcom,src-freq = <5000>;
+
+ led-controller@38 {
+ compatible = "ti,lm3630a";
+ status = "ok";
+ reg = <0x38>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0 1>;
+ label = "lcd-backlight";
+ default-brightness = <200>;
+ };
+ };
+ };
+
i2c@f9968000 {
status = "ok";
pinctrl-names = "default";
--
2.20.1
[PATCH v3 1/6] drm/msm: add dirty framebuffer helper
Use drm_atomic_helper_dirtyfb() as the dirty callback in the
msm_framebuffer_funcs struct. Call drm_plane_enable_fb_damage_clips()
when the planes are initialized in mdp4, mdp5, and dpu1.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 +++
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 3 +++
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 +++
drivers/gpu/drm/msm/msm_fb.c | 2 ++
4 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index d831cedb55ec..2ea42f50401f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include "msm_drv.h"
@@ -1535,6 +1536,8 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
if (ret)
DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
+ drm_plane_enable_fb_damage_clips(plane);
+
/* success! finalize initialization */
drm_plane_helper_add(plane, _plane_helper_funcs);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 005066f7154d..2d46d1126283 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -15,6 +15,7 @@
* this program. If not, see
[PATCH v3 2/6] drm/msm: add support for per-CRTC max_vblank_count on mdp5
The mdp5 drm/kms driver currently does not work on command-mode DSI
panels due to 'vblank wait timed out' errors. This causes a latency
of seconds, or tens of seconds in some cases, before content is shown
on the panel. This hardware does not have the something that we can use
as a frame counter available when running in command mode, so we need to
fall back to using timestamps by setting the max_vblank_count to zero.
This can be done on a per-CRTC basis, so the convert mdp5 to use
drm_crtc_set_max_vblank_count().
This change was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
Suggested-by: Jeffrey Hugo
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 16 +++-
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index c3751c95b452..6fde1097844f 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -450,6 +450,18 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc *crtc,
mdp5_crtc->enabled = false;
}
+static void mdp5_crtc_vblank_on(struct drm_crtc *crtc)
+{
+ struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
+ struct mdp5_interface *intf = mdp5_cstate->pipeline.intf;
+ u32 count;
+
+ count = intf->mode == MDP5_INTF_DSI_MODE_COMMAND ? 0 : 0x;
+ drm_crtc_set_max_vblank_count(crtc, count);
+
+ drm_crtc_vblank_on(crtc);
+}
+
static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -486,7 +498,7 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
}
/* Restore vblank irq handling after power is enabled */
- drm_crtc_vblank_on(crtc);
+ mdp5_crtc_vblank_on(crtc);
mdp5_crtc_mode_set_nofb(crtc);
@@ -1039,6 +1051,8 @@ static void mdp5_crtc_reset(struct drm_crtc *crtc)
mdp5_crtc_destroy_state(crtc, crtc->state);
__drm_atomic_helper_crtc_reset(crtc, _cstate->base);
+
+ drm_crtc_vblank_reset(crtc);
}
static const struct drm_crtc_funcs mdp5_crtc_funcs = {
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 97179bec8902..fcb0b0455abe 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -750,7 +750,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
dev->driver->get_vblank_timestamp =
drm_calc_vbltimestamp_from_scanoutpos;
dev->driver->get_scanout_position = mdp5_get_scanoutpos;
dev->driver->get_vblank_counter = mdp5_get_vblank_counter;
- dev->max_vblank_count = 0x;
+ dev->max_vblank_count = 0; /* max_vblank_count is set on each CRTC */
dev->vblank_disable_immediate = true;
return kms;
--
2.20.1
[PATCH v3 3/6] ARM: qcom_defconfig: add display-related options
Add the CMA (Contiguous Memory Allocator) for the MSM DRM/KMS driver, the simple panel, and the TI LM3630A driver in order to support the display on the LG Nexus 5 (hammerhead) phone. Signed-off-by: Brian Masney Reviewed-by: Linus Walleij --- arch/arm/configs/qcom_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index c1854751c99a..4f02636f832e 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -37,6 +37,7 @@ CONFIG_ARM_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_CMA=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -146,12 +147,14 @@ CONFIG_REGULATOR_QCOM_SMD_RPM=y CONFIG_REGULATOR_QCOM_SPMI=y CONFIG_MEDIA_SUPPORT=y CONFIG_DRM=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set +CONFIG_BACKLIGHT_LM3630A=y CONFIG_BACKLIGHT_LP855X=y CONFIG_SOUND=y CONFIG_SND=y @@ -262,6 +265,8 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y +CONFIG_DMA_CMA=y +CONFIG_CMA_SIZE_MBYTES=256 CONFIG_PRINTK_TIME=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y -- 2.20.1
[PATCH v3 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display
Add initial support for the display found on the LG Nexus 5 (hammerhead)
phone. This is based on work from Jonathan Marek.
Signed-off-by: Brian Masney
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index 51889d66b55a..4776f01f492c 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -332,6 +332,16 @@
function = "gpio";
};
};
+
+ panel_pin: panel {
+ te {
+ pins = "gpio12";
+ function = "mdp_vsync";
+
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
};
vibrator@fd8c3450 {
@@ -531,6 +541,54 @@
};
};
};
+
+ mdss@fd90 {
+ status = "ok";
+
+ mdp@fd90 {
+ status = "ok";
+ };
+
+ dsi@fd922800 {
+ status = "ok";
+
+ vdda-supply = <_l2>;
+ vdd-supply = <_lvs3>;
+ vddio-supply = <_l12>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel: panel@0 {
+ reg = <0>;
+ compatible = "lg,acx467akm-7";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+
+ dsi-phy@fd922a00 {
+ status = "ok";
+
+ vddio-supply = <_l12>;
+ };
+ };
};
_bus {
--
2.20.1
[PATCH v3 0/6] ARM: qcom: working Nexus 5 display support
This patch series adds working display support to the LG Nexus 5 (hammerhead) phone. Changes since v2: - Dropped two drm/msm bug fix patches that have been merged separately. - New patch: 'add support for per-CRTC max_vblank_count on mdp5'. Special thanks to Jeffrey Hugo for helping to track down this issue. - Add panel_pin to msm8974-hammerhead device tree. Dropped Linus Walleij's reviewed-by on this patch due to this change. Changes since v1: - Shortened problem description above. I'll reply to this email and send a full dmesg with the boot log with debugging turned on. - Dropped patch 'fix null pointer dereference in msm_atomic_prepare_fb()' - New patch: Remove resv fields from msm_gem_object struct that was incorrectly being referenced by the prepare_fb callbacks. - Add drm_plane_enable_fb_damage_clips() to plane init for mdp4, mdp5, and dpu1. - Add Linus Walleij's reviewed-by to patches 3-6 My status page at https://masneyb.github.io/nexus-5-upstream/ describes what is working so far with the upstream kernel on the Nexus 5. Brian Masney (6): drm/msm: add dirty framebuffer helper drm/msm: add support for per-CRTC max_vblank_count on mdp5 ARM: qcom_defconfig: add display-related options ARM: dts: qcom: msm8974-hammerhead: add support for backlight ARM: dts: msm8974: add display support ARM: dts: qcom: msm8974-hammerhead: add support for display .../qcom-msm8974-lge-nexus5-hammerhead.dts| 92 arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++ arch/arm/configs/qcom_defconfig | 5 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 + drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 3 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 16 ++- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 3 + drivers/gpu/drm/msm/msm_fb.c | 2 + 9 files changed, 256 insertions(+), 2 deletions(-) -- 2.20.1
linux-next: Fixes tag needs some work in the drm-fixes tree
Hi all,
In commit
137caa702f23 ("drm/imx: ipuv3-plane: fix atomic update status query for
non-plus i.MX6Q")
Fixes tag
Fixes: 70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic
update status")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
pgpjZQhsGF1F9.pgp
Description: OpenPGP digital signature
Re: [PATCH v9 0/9] drm/sun4i: Allwinner A64 MIPI-DSI support
On Fri, May 31, 2019 at 12:28 PM Maxime Ripard wrote: > > Hi, > > On Wed, May 29, 2019 at 04:26:06PM +0530, Jagan Teki wrote: > > This is v9 version for Allwinner A64 MIPI-DSI support > > and here is the previous version set[1]. > > > > This depends on dsi host controller fixes which were > > supported in this series[2]. > > > > All these changes are tested in Allwinner A64 with > > 2, 4 lanes devices and whose pixel clocks are 27.5 MHz, > > 30MHz, 55MHz and 147MHz. > > I wanted to apply this, but it wouldn't apply, can you send it without > dependencies? I can do that no problem, but [2] has dsi and dclk divider fixes that would require A64 MIPI-DSI to work. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/9] drm/sun4i: Allwinner A64 MIPI-DSI support
Hi, On Wed, May 29, 2019 at 04:26:06PM +0530, Jagan Teki wrote: > This is v9 version for Allwinner A64 MIPI-DSI support > and here is the previous version set[1]. > > This depends on dsi host controller fixes which were > supported in this series[2]. > > All these changes are tested in Allwinner A64 with > 2, 4 lanes devices and whose pixel clocks are 27.5 MHz, > 30MHz, 55MHz and 147MHz. I wanted to apply this, but it wouldn't apply, can you send it without dependencies? Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v9 1/9] dt-bindings: sun6i-dsi: Add A64 MIPI-DSI compatible
On Wed, May 29, 2019 at 04:26:07PM +0530, Jagan Teki wrote: > The MIPI DSI controller in Allwinner A64 is similar to A33. > > But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid > to with separate compatible for A64 on the same driver. > > Signed-off-by: Jagan Teki > Reviewed-by: Rob Herring > Tested-by: Merlijn Wajer > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > index 1cc40663b7a2..9877398be69a 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > @@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's. > Required properties: >- compatible: value must be one of: > * allwinner,sun6i-a31-mipi-dsi > +* allwinner,sun50i-a64-mipi-dsi >- reg: base address and size of memory-mapped region >- interrupts: interrupt associated to this IP >- clocks: phandles to the clocks feeding the DSI encoder We've switch to YAML now, and the compatible should be expressed that way now: compatible: enum: - allwinner,sun6i-a31-mipi-dsi - allwinner,sun50i-a64-mipi-dsi Maxime -- Maxime Ripard, 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
Re: [PATCH v9 2/9] dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)
On Wed, May 29, 2019 at 04:26:08PM +0530, Jagan Teki wrote: > The MIPI DSI PHY controller on Allwinner A64 is similar > on the one on A31. > > Add A64 compatible and append A31 compatible as fallback. > > Signed-off-by: Jagan Teki > Reviewed-by: Rob Herring > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > index 9877398be69a..d0ce51fea103 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > @@ -38,6 +38,7 @@ D-PHY > Required properties: >- compatible: value must be one of: > * allwinner,sun6i-a31-mipi-dphy > +* allwinner,sun50i-a64-mipi-dphy, allwinner,sun6i-a31-mipi-dphy >- reg: base address and size of memory-mapped region >- clocks: phandles to the clocks feeding the DSI encoder > * bus: the DSI interface clock And this one should be: compatible: oneOf: - const: allwinner,sun6i-a31-mipi-dphy - items: - const: allwinner,sun50i-a64-mipi-dphy - const: allwinner,sun6i-a31-mipi-dphy Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v9 1/9] dt-bindings: sun6i-dsi: Add A64 MIPI-DSI compatible
On Fri, May 31, 2019 at 12:29 PM Maxime Ripard wrote: > > On Wed, May 29, 2019 at 04:26:07PM +0530, Jagan Teki wrote: > > The MIPI DSI controller in Allwinner A64 is similar to A33. > > > > But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid > > to with separate compatible for A64 on the same driver. > > > > Signed-off-by: Jagan Teki > > Reviewed-by: Rob Herring > > Tested-by: Merlijn Wajer > > --- > > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > > index 1cc40663b7a2..9877398be69a 100644 > > --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > > @@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's. > > Required properties: > >- compatible: value must be one of: > > * allwinner,sun6i-a31-mipi-dsi > > +* allwinner,sun50i-a64-mipi-dsi > >- reg: base address and size of memory-mapped region > >- interrupts: interrupt associated to this IP > >- clocks: phandles to the clocks feeding the DSI encoder > > We've switch to YAML now, and the compatible should be expressed that > way now: Yes, I have seen it few days back will update on top of that, thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/22] gpu: i915.rst: Fix references to renamed files
On Wed, 29 May 2019, Mauro Carvalho Chehab wrote:
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with
> return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> Logical Rings, Logical Ring Contexts and Execlists
> ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
> ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
>
> Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/gpu/i915.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 055df45596c1..38fefeb99bba 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
> Workarounds
> ---
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/selftest_workarounds.c
> :doc: Hardware workarounds
Thanks for the patch. The basename should remain the same here.
I can pick up the updated version via drm-intel.
BR,
Jani.
>
> Display Hardware Handling
> @@ -379,10 +379,10 @@ User Batchbuffer Execution
> Logical Rings, Logical Ring Contexts and Execlists
> --
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :doc: Logical Rings, Logical Ring Contexts and Execlists
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :internal:
>
> Global GTT views
--
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 12/22] gpu: i915.rst: Fix references to renamed files
Quoting Mauro Carvalho Chehab (2019-05-30 02:23:43)
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with
> return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> Logical Rings, Logical Ring Contexts and Execlists
> ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
> ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
>
> Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/gpu/i915.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 055df45596c1..38fefeb99bba 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
> Workarounds
> ---
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/selftest_workarounds.c
This should be gt/intel_workarounds.c
Do you want me to merge this, or do you plan on merging through
documentation tree?
Regards, Joonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #8 from Richard Thier --- I became a bit uncertain now as after every bisect I am choosing "git bisect bad" and see no change so far. There is 4 more bisect to do still, but I expected at least one change so far. Maybe it is in xorg and not mesa??? Before bisecting with git I was "bisecting" with the arch and ubuntu repo archives and there I had to move xorg and mesa together always... Also I am now confused about the version string in the glxinfo output because I went through a point where I expected it to write "17.2.8" and still it is writing "17.4.0". Is there a trick to exactly know what git revision the 17.2.8 version was built out of? I might be bisecting against the wrong "good" target... :-( -- 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 110803] Coruption and flickering on polaris with mesa 19.0.5
https://bugs.freedesktop.org/show_bug.cgi?id=110803 Bug ID: 110803 Summary: Coruption and flickering on polaris with mesa 19.0.5 Product: Mesa Version: 19.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: diplosa...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 144396 --> https://bugs.freedesktop.org/attachment.cgi?id=144396=edit Flickering in blender I am an arch, using non composited xorg on kernel 5.1.5 with the kms ddx. Severe flickering occures in QWebengine, browsers paritcularly on youtube, and in blender (see video), but also to a lesser degree in other opengl apps. This occures with mesa 19.0.5 and disappears if mesa is downgraded to 19.0.3. -- 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][next] drm/i915: fix use of uninitialized pointer vaddr
Quoting Colin King (2019-05-31 11:32:01)
> From: Colin Ian King
>
> The assignment of err is using the incorrect pointer vaddr that has
> not been initialized. Fix this by using the correct pointer obj instead.
>
> Addresses-Coverity: ("Uninitialized pointer read")
> Fixes: 6501aa4e3a45 ("drm/i915: add in-kernel blitter client")
> Signed-off-by: Colin Ian King
Reviewed and pushed, thanks for the fix!
-Chris
Re: Panfrost impossible to probe without opp table
On 31/05/2019 14:09, Tomeu Vizoso wrote: > On Fri, 31 May 2019 at 14:03, Neil Armstrong wrote: >> >> Hi Tomeu, >> >> On 31/05/2019 13:59, Tomeu Vizoso wrote: >>> On Wed, 29 May 2019 at 23:29, Clément Péron wrote: Hi, I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is no more probing. The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e drm/panfrost: Select devfreq Currently, there is some logic for the driver to work without devfreq. However, the driver actually fails to probe if !CONFIG_PM_DEVFREQ. Fix this by selecting devfreq, and drop the additional checks for devfreq. It seems that with this commit the OPP table is now mandatory. is it intentional? >>> >>> Hi Clément, >>> >>> devfreq support is intentionally required. I got a H64 board which I'm >>> using to add T720 support to Panfrost. >> >> operating-points-v2 and clocks are optional, devfreq should be optional, >> this was the default behaviour of the first applied version. > > I'm concerned by the safety of running these GPUs all the time at > their maximum frequencies. Maybe not on Chromebooks and other consumer > devices, but the SBCs I have here have all very crappy heat > dissipation. Sure, it's logical to have devfreq running on these devices. > >> Amlogic dt does not have operating-points-v2, and devfreq won't be supported >> soon. > > What's the problem with coming up with the operating points? Because the bindings are optional : Optional properties: - clocks : Phandle to clock for the Mali Midgard device. - mali-supply : Phandle to regulator for the Mali device. Refer to Documentation/devicetree/bindings/regulator/regulator.txt for details. - operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt for details. Unless you change the bindings, it's mandated to be optional by the bindings. Neil > > Thanks, > > Tomeu > >> Neil >> >>> >>> Once I'm able to test the GPU properly along with frequency scaling, I >>> will ping you so you can retest and resubmit. >>> >>> Thanks, >>> >>> Tomeu >>> Actually [3.046237] panfrost 180.gpu: clock rate = 43200 [3.051593] panfrost 180.gpu: bus_clock rate = 1 [3.096012] panfrost 180.gpu: mali-t720 id 0x720 major 0x1 minor 0x1 status 0x0 [3.103682] panfrost 180.gpu: features: ,10309e40, issues: ,21054400 [3.111789] panfrost 180.gpu: Features: L2:0x07110206 Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf JS:0x7 [3.123435] panfrost 180.gpu: shader_present=0x3 l2_present=0x1 [3.130405] panfrost 180.gpu: Fatal error during devfreq init With commit reverted [3.038236] panfrost 180.gpu: clock rate = 43200 [3.043593] panfrost 180.gpu: bus_clock rate = 1 [3.087994] panfrost 180.gpu: mali-t720 id 0x720 major 0x1 minor 0x1 status 0x0 [3.095658] panfrost 180.gpu: features: ,10309e40, issues: ,21054400 [3.103763] panfrost 180.gpu: Features: L2:0x07110206 Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf JS:0x7 [3.115410] panfrost 180.gpu: shader_present=0x3 l2_present=0x1 [3.122798] [drm] Initialized panfrost 1.0.0 20180908 for 180.gpu on minor 0 Thanks, Clément ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to dts
On Tue, May 28, 2019 at 10:53 AM Tomi Valkeinen wrote: > > Hi, > > On 28/05/2019 18:09, Adam Ford wrote: > > On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen > > wrote: > >> > >> Hi, > >> > >> On 10/05/2019 22:42, Adam Ford wrote: > >>> Currently the source code is compiled using hard-coded values > >>> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this > >>> clock divider value to be moved to the device tree and be changed > >>> without having to recompile the kernel. > >>> > >>> Signed-off-by: Adam Ford > >> > >> I understand why you want to do this, but I'm not sure it's a good idea. > >> It's really something the driver should figure out, and if we add it to > >> the DT, it effectively becomes an ABI. > >> > >> That said... I'm not sure how good of a job the driver could ever do, as > >> it can't know the future scaling needs of the userspace at the time it > >> is configuring the clock. And so, I'm not nacking this patch, but I > >> don't feel very good about this patch... > >> > >> The setting also affects all outputs (exluding venc), which may not be > >> what the user wants. Then again, I think this setting is really only > >> needed on OMAP2 & 3, which have only a single output. But that's the > >> same with the current kconfig option, of course. > >> > >> So, the current CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is an ugly hack, in my > >> opinion, and moving it to DT makes it a worse hack =). But I don't have > >> any good suggestions either. > > > > As it stands the Logic PD OMAP35 and AM37/DM37 boards (SOM-LV and > > Torpedo) require this to be hard coded to 4 or it hangs during start. > > This is the case for all versions 4.2+. I haven't tested it with > > older stuff. Tony has a DM3730 Torpedo kit and reported the hanging > > issue to me. I told him to set that value to 4 to make it not hang. > > He asked that I move it to the DT to avoid custom kernels. I agree > > it's a hack, but if it's create a customized defconfig file for 4 > > boards or modify the device tree, it seems like the device tree > > approach is less intrusive. > > Ok, well, I think that's a separate thing from its intended use. The > point of the kconfig option is to ensure that the fclk/pclk ratio stays > under a certain number to allow enough scaling range. It should never > affect a basic non-scaling use case, unless you set it to a too high > value, which prevents finding any pclk. > > Has anyone debugged why the hang is happening? I tried debugging this years ago, and I was told to use the CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. > > If we can't fix the bug itself, rather than adding a DT option, we could > change add a min_fck_per_pck field (as you do), keep the kconfig option, > and set the min_fck_per_pck based on the kconfig option, _or_ in case of > those affected SoCs, set the min_fck_per_pck even without the kconfig > option. I am just curious if anyone else sees this. If nobody is using this hack, I wonder how much of the impact it will be. I'm trying trying to get my board to boot without hanging without creating a custom defconfig. adam > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCHv6 3/4] drm/omap: add framedone interrupt support
On 30/05/2019 00:55, Sebastian Reichel wrote: Oh sorry, I missed the part that omap_irq_wait_init() actually enables the framedone irq. It should be enough to just drop the warning (and the curly brackets) to keep existing behaviour. The code exits early with the above warning for any existing code (since that does not register a framedone handler). DSI on the other hand does not reach the omap_irq_wait_init() part. Regarding combining the logic: I don't think there is anything to combine right now. It should be possible to simplify the logic after DSI has been converted to drm_panel style, since this will move the update logic for the screen content from the panel driver to DSI core. TLDR: It's enough to remove the warning. Do you need a new submission for this? Ok. No, I can edit the patch. Nikolaus, are you able to test DSI videomode with these patches? Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Make sure a BO is only unmapped when appropriate
On Wed, 29 May 2019 at 11:18, Boris Brezillon
wrote:
>
> mmu_ops->unmap() will fail when called on a BO that has not been
> previously mapped, and the error path in panfrost_ioctl_create_bo()
> can call drm_gem_object_put_unlocked() (which in turn calls
> panfrost_mmu_unmap()) on a BO that has not been mapped yet.
>
> Keep track of the mapped/unmapped state to avoid such issues.
>
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Cc:
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_gem.h | 1 +
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 8
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
> b/drivers/gpu/drm/panfrost/panfrost_gem.h
> index 045000eb5fcf..6dbcaba020fc 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
> @@ -11,6 +11,7 @@ struct panfrost_gem_object {
> struct drm_gem_shmem_object base;
>
> struct drm_mm_node node;
> + bool is_mapped;
> };
>
> static inline
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index 762b1bd2a8c2..fb556aa89203 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -156,6 +156,9 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
> struct sg_table *sgt;
> int ret;
>
> + if (bo->is_mapped)
> + return 0;
In what circumstances we want to silently go on? I would expect that
for this function to be called when the BO has been mapped already
would mean that we have a bug in the kernel, so why not a WARN?
> +
> sgt = drm_gem_shmem_get_pages_sgt(obj);
> if (WARN_ON(IS_ERR(sgt)))
> return PTR_ERR(sgt);
> @@ -189,6 +192,7 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
>
> pm_runtime_mark_last_busy(pfdev->dev);
> pm_runtime_put_autosuspend(pfdev->dev);
> + bo->is_mapped = true;
>
> return 0;
> }
> @@ -203,6 +207,9 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
> size_t unmapped_len = 0;
> int ret;
>
> + if (!bo->is_mapped)
> + return;
Similarly, I think that what we should do is not to call
panfrost_mmu_unmap when a BO is freed if we know it isn't mapped. And
probably add a WARN here if it still gets called when the BO isn't
mapped.
> +
> dev_dbg(pfdev->dev, "unmap: iova=%llx, len=%zx", iova, len);
>
> ret = pm_runtime_get_sync(pfdev->dev);
> @@ -230,6 +237,7 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
>
> pm_runtime_mark_last_busy(pfdev->dev);
> pm_runtime_put_autosuspend(pfdev->dev);
> + bo->is_mapped = false;
> }
>
> static void mmu_tlb_inv_context_s1(void *cookie)
> --
> 2.20.1
>
Thanks for taking care of this!
Tomeu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 0/6] drm/bridge: sii902x: HDMI-audio support and some fixes
On 27.05.2019 15:47, Jyri Sarha wrote: > I think these should be ready for applying to drm-misc. > > Changes since v7: > - Debased on top of the lasts drm-misc-next and tested > - "dt-bindings: display: sii902x: Add HDMI audio bindings" >- Dropped off "or higher to avoid conflict with video ports" > and added "Reviewed-by: Rob Herring " > > Ther previous round: > https://patchwork.kernel.org/cover/10919173/ > > Jyri Sarha (5): > drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID > drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz > dt-bindings: display: sii902x: Remove trailing white space > dt-bindings: display: sii902x: Add HDMI audio bindings > drm/bridge: sii902x: Implement HDMI audio support > > Tomi Valkeinen (1): > drm/bridge: sii902x: add input_bus_flags > > .../bindings/display/bridge/sii902x.txt | 42 +- > drivers/gpu/drm/bridge/sii902x.c | 488 +- > 2 files changed, 522 insertions(+), 8 deletions(-) > Queued to drm-misc-next. -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_gem_dumb_map_offset patch
Hi, [add Daniel Vetter] [cc dri-devel] Den 29.05.2019 15.09, skrev Pierre Yves MORDRET: > Hello Noralf, > > Sorry for bothering you with question but I need to better understand the > rational about a patch you did in DRM/GEM. > > First of all, let me introduce myself. > I'm currently employee to STMicroelectronics company and in charge of GPU > integration within STM32 MPU (Cortex A7 + Cortex M4) > > On Cortex A7 is running a Linux Kernel 4.19 as for today. > > We came across some trouble when we switch from Kernel 4.14 to 4.19 for GPU > stack. On august you submit this commit : > > 90378e58919285637aa0f063c04ba0c6449d98b1 > drm/gem: drm_gem_dumb_map_offset(): reject dma-buf > > Reject mapping an imported dma-buf since is's an invalid use-case. > > In Userland GPU stack we have such statements : >bo_map_fd >DRM_IOCTL_MODE_MAP_DUMB >mmap (offset) > > With the patch above, ioctl returns an error EINVAL and prevents the nmap. > As for today we revert this patch and it works fine in our end. > > Thus the questions are : > - what is the rational behind this fix ? > - What we doing wrong this situation ? > - What do we need in such situation ? > I need to pass those on to Daniel Vetter (DRM maintainer) since he wanted the change. The details were never clear to me. Some of the discussion is here: https://patchwork.freedesktop.org/patch/172242/ Noralf. > Many thanks in advance. > Best Regards > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110730] [CI][RESUME] igt@kms_chamelium@hdmi-crc-single - crash - Received signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=110730 Lakshmi changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Component|DRM/Intel |IGT Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org --- Comment #3 from Lakshmi --- Moving to IGT to fix the test. -- 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 110730] [CI][RESUME] igt@kms_chamelium@hdmi-crc-single - crash - Received signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=110730 --- Comment #4 from Lakshmi --- Moving to IGT to fix the test. -- 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 0/6] Allwinner H6 Mali GPU support
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>
> On 29/05/2019 16:09, Tomeu Vizoso wrote:
> > On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
> >>
> > [snip]
> >> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> >> [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
> >> 0x02400400
> >
> > From what I can see here, 0x02400400 points to the first byte
> > of the first submitted job descriptor.
> >
> > So mapping buffers for the GPU doesn't seem to be working at all on
> > 64-bit T-760.
> >
> > Steven, Robin, do you have any idea of why this could be?
>
> I tried rolling back to the old panfrost/nondrm shim, and it works fine
> with kbase, and I also found that T-820 falls over in the exact same
> manner, so the fact that it seemed to be common to the smaller 33-bit
> designs rather than anything to do with the other
> job_descriptor_size/v4/v5 complication turned out to be telling.
Is this complication something you can explain? I don't know what v4
and v5 are meant here.
> [ as an aside, are 64-bit jobs actually known not to work on v4 GPUs, or
> is it just that nobody's yet observed a 64-bit blob driving one? ]
I'm looking right now at getting Panfrost working on T720 with 64-bit
descriptors, with the ultimate goal of making Panfrost
64-bit-descriptor only so we can have a single build of Mesa in
distros.
> Long story short, it appears that 'Mali LPAE' is also lacking the start
> level notion of VMSA, and expects a full 4-level table even for <40 bits
> when level 0 effectively redundant. Thus walking the 3-level table that
> io-pgtable comes back with ends up going wildly wrong. The hack below
> seems to do the job for me; if Clément can confirm (on T-720 you'll
> still need the userspace hack to force 32-bit jobs as well) then I think
> I'll cook up a proper refactoring of the allocator to put things right.
Mmaps seem to work with this patch, thanks.
The main complication I'm facing right now seems to be that the SFBD
descriptor on T720 seems to be different from the one we already had
(tested on T6xx?).
Cheers,
Tomeu
> Robin.
>
>
> ->8-
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 546968d8a349..f29da6e8dc08 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -1023,12 +1023,14 @@ arm_mali_lpae_alloc_pgtable(struct
> io_pgtable_cfg *cfg, void *cookie)
> iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
> if (iop) {
> u64 mair, ttbr;
> + struct arm_lpae_io_pgtable *data =
> io_pgtable_ops_to_data(>ops);
>
> + data->levels = 4;
> /* Copy values as union fields overlap */
> mair = cfg->arm_lpae_s1_cfg.mair[0];
> ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v6 0/6] Add support for Orange Pi 3
Hello, On Mon, May 27, 2019 at 06:22:31PM +0200, megous via linux-sunxi wrote: > From: Ondrej Jirman > > This series implements support for Xunlong Orange Pi 3 board. > > Unfortunately, this board needs some small driver patches, so I have > split the boards DT patch into chunks that require patches for drivers > in various subsystems. > > Suggested merging plan/dependencies: > > - stmmac patches are needed for ethernet support (patches 1-3) > - these should be ready now > - HDMI support (patches 4-6) > - should be ready If there are no futher comments, can all these patches please be merged? thank you and kind regards, Ondrej > Changes in v2: > - added dt-bindings documentation for the board's compatible string > (suggested by Clement) > - addressed checkpatch warnings and code formatting issues (on Maxime's > suggestions) > - stmmac: dropped useless parenthesis, reworded description of the patch > (suggested by Sergei) > - drop useles dev_info() about the selected io bias voltage > - docummented io voltage bias selection variant macros > - wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE", > because wifi depends on H6 RTC support that's not merged yet (suggested > by Clement) > - added missing signed-of-bys > - changed dr_mode to otg, and added a note about VBUS > - improved wording of HDMI driver's DDC power supply patch > > Changes in v3: > - dropped already applied patches > - changed pinctrl I/O bias selection constants to enum and renamed > - added /omit-if-no-ref/ to mmc1_pins > - made mmc1_pins default pinconf for mmc1 in H6 dtsi > - move ddc-supply to HDMI connector node, updated patch descriptions, > changed dt-bindings docs > > Changes in v4: > - fix checkpatch warnings/style issues > - use enum in struct sunxi_desc_function for io_bias_cfg_variant > - collected acked-by's > - fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156 > caused by missing conversion from has_io_bias_cfg struct member > (I've kept the acked-by, because it's a trivial change, but feel free > to object.) (reported by Martin A. on github) > I did not have A80 pinctrl enabled for some reason, so I did not catch > this sooner. > - dropped brcm firmware patch (was already applied) > - dropped the wifi dts patch (will re-send after H6 RTC gets merged, > along with bluetooth support, in a separate series) > > Changes in v5: > - dropped already applied patches (pinctrl patches, mmc1 pinconf patch) > - rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan) > - changed hdmi-connector's ddc-supply property to ddc-en-gpios > (Rob Herring) > > Changes in v6: > - added dt-bindings reviewed-by tag > - fix wording in stmmac commit (as suggested by Sergei) > > Please take a look. > > thank you and regards, > Ondrej Jirman > > Icenowy Zheng (2): > net: stmmac: sun8i: add support for Allwinner H6 EMAC > net: stmmac: sun8i: force select external PHY when no internal one > > Ondrej Jirman (4): > arm64: dts: allwinner: orange-pi-3: Enable ethernet > dt-bindings: display: hdmi-connector: Support DDC bus enable > drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue > arm64: dts: allwinner: orange-pi-3: Enable HDMI output > > .../display/connector/hdmi-connector.txt | 1 + > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 70 +++ > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55 ++- > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 3 + > .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 21 ++ > 5 files changed, 147 insertions(+), 3 deletions(-) > > -- > 2.21.0 > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/20190527162237.18495-1-megous%40megous.com. > For more options, visit https://groups.google.com/d/optout.
Re: drm_gem_dumb_map_offset patch
On Fri, May 31, 2019 at 1:28 PM Noralf Trønnes wrote: > > Hi, > > [add Daniel Vetter] > [cc dri-devel] > > Den 29.05.2019 15.09, skrev Pierre Yves MORDRET: > > Hello Noralf, > > > > Sorry for bothering you with question but I need to better understand the > > rational about a patch you did in DRM/GEM. > > > > First of all, let me introduce myself. > > I'm currently employee to STMicroelectronics company and in charge of GPU > > integration within STM32 MPU (Cortex A7 + Cortex M4) > > > > On Cortex A7 is running a Linux Kernel 4.19 as for today. > > > > We came across some trouble when we switch from Kernel 4.14 to 4.19 for GPU > > stack. On august you submit this commit : > > > > 90378e58919285637aa0f063c04ba0c6449d98b1 > > drm/gem: drm_gem_dumb_map_offset(): reject dma-buf > > > > Reject mapping an imported dma-buf since is's an invalid use-case. > > > > In Userland GPU stack we have such statements : > >bo_map_fd > >DRM_IOCTL_MODE_MAP_DUMB > >mmap (offset) > > > > With the patch above, ioctl returns an error EINVAL and prevents the nmap. > > As for today we revert this patch and it works fine in our end. Link to source code would be good. > > Thus the questions are : > > - what is the rational behind this fix ? > > - What we doing wrong this situation ? > > - What do we need in such situation ? > > > > I need to pass those on to Daniel Vetter (DRM maintainer) since he > wanted the change. The details were never clear to me. > Some of the discussion is here: > https://patchwork.freedesktop.org/patch/172242/ Dumb mmap is for buffer created using dumb_create ioctl, and nothing else. Anything else really has at best undefined behaviour. E.g. for dma-buf you really need to call the begin/end_cpu_access ioctl, and dumb buffers simply have no provision for that. Hence why we can't support this in general. Thanks, 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
Re: Panfrost impossible to probe without opp table
On Wed, 29 May 2019 at 23:29, Clément Péron wrote: > > Hi, > > I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is > no more probing. > > The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e > drm/panfrost: Select devfreq > > Currently, there is some logic for the driver to work without devfreq. > However, the driver actually fails to probe if !CONFIG_PM_DEVFREQ. > > Fix this by selecting devfreq, and drop the additional checks > for devfreq. > > It seems that with this commit the OPP table is now mandatory. > is it intentional? Hi Clément, devfreq support is intentionally required. I got a H64 board which I'm using to add T720 support to Panfrost. Once I'm able to test the GPU properly along with frequency scaling, I will ping you so you can retest and resubmit. Thanks, Tomeu > Actually > [3.046237] panfrost 180.gpu: clock rate = 43200 > [3.051593] panfrost 180.gpu: bus_clock rate = 1 > [3.096012] panfrost 180.gpu: mali-t720 id 0x720 major 0x1 > minor 0x1 status 0x0 > [3.103682] panfrost 180.gpu: features: ,10309e40, > issues: ,21054400 > [3.111789] panfrost 180.gpu: Features: L2:0x07110206 > Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf > JS:0x7 > [3.123435] panfrost 180.gpu: shader_present=0x3 l2_present=0x1 > [3.130405] panfrost 180.gpu: Fatal error during devfreq init > > With commit reverted > [3.038236] panfrost 180.gpu: clock rate = 43200 > [3.043593] panfrost 180.gpu: bus_clock rate = 1 > [3.087994] panfrost 180.gpu: mali-t720 id 0x720 major 0x1 > minor 0x1 status 0x0 > [3.095658] panfrost 180.gpu: features: ,10309e40, > issues: ,21054400 > [3.103763] panfrost 180.gpu: Features: L2:0x07110206 > Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf > JS:0x7 > [3.115410] panfrost 180.gpu: shader_present=0x3 l2_present=0x1 > [3.122798] [drm] Initialized panfrost 1.0.0 20180908 for > 180.gpu on minor 0 > > > Thanks, > Clément > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Panfrost impossible to probe without opp table
On Fri, 31 May 2019 at 14:03, Neil Armstrong wrote: > > Hi Tomeu, > > On 31/05/2019 13:59, Tomeu Vizoso wrote: > > On Wed, 29 May 2019 at 23:29, Clément Péron wrote: > >> > >> Hi, > >> > >> I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is > >> no more probing. > >> > >> The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e > >> drm/panfrost: Select devfreq > >> > >> Currently, there is some logic for the driver to work without devfreq. > >> However, the driver actually fails to probe if !CONFIG_PM_DEVFREQ. > >> > >> Fix this by selecting devfreq, and drop the additional checks > >> for devfreq. > >> > >> It seems that with this commit the OPP table is now mandatory. > >> is it intentional? > > > > Hi Clément, > > > > devfreq support is intentionally required. I got a H64 board which I'm > > using to add T720 support to Panfrost. > > operating-points-v2 and clocks are optional, devfreq should be optional, > this was the default behaviour of the first applied version. I'm concerned by the safety of running these GPUs all the time at their maximum frequencies. Maybe not on Chromebooks and other consumer devices, but the SBCs I have here have all very crappy heat dissipation. > Amlogic dt does not have operating-points-v2, and devfreq won't be supported > soon. What's the problem with coming up with the operating points? Thanks, Tomeu > Neil > > > > > Once I'm able to test the GPU properly along with frequency scaling, I > > will ping you so you can retest and resubmit. > > > > Thanks, > > > > Tomeu > > > >> Actually > >> [3.046237] panfrost 180.gpu: clock rate = 43200 > >> [3.051593] panfrost 180.gpu: bus_clock rate = 1 > >> [3.096012] panfrost 180.gpu: mali-t720 id 0x720 major 0x1 > >> minor 0x1 status 0x0 > >> [3.103682] panfrost 180.gpu: features: ,10309e40, > >> issues: ,21054400 > >> [3.111789] panfrost 180.gpu: Features: L2:0x07110206 > >> Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf > >> JS:0x7 > >> [3.123435] panfrost 180.gpu: shader_present=0x3 l2_present=0x1 > >> [3.130405] panfrost 180.gpu: Fatal error during devfreq init > >> > >> With commit reverted > >> [3.038236] panfrost 180.gpu: clock rate = 43200 > >> [3.043593] panfrost 180.gpu: bus_clock rate = 1 > >> [3.087994] panfrost 180.gpu: mali-t720 id 0x720 major 0x1 > >> minor 0x1 status 0x0 > >> [3.095658] panfrost 180.gpu: features: ,10309e40, > >> issues: ,21054400 > >> [3.103763] panfrost 180.gpu: Features: L2:0x07110206 > >> Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf > >> JS:0x7 > >> [3.115410] panfrost 180.gpu: shader_present=0x3 l2_present=0x1 > >> [3.122798] [drm] Initialized panfrost 1.0.0 20180908 for > >> 180.gpu on minor 0 > >> > >> > >> Thanks, > >> Clément > >> > >> ___ > >> linux-arm-kernel mailing list > >> linux-arm-ker...@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 23/24] drm/bridge: tc358767: add IRQ and HPD support
On 28.05.2019 10:27, Tomi Valkeinen wrote: > Add support for interrupt and hotplug handling. Both are optional. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/8] drm/fb-helper: Move out commit code
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v7: Export drm_client_panel_rotation() (Gerd Hoffmann)
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 | 288 +++
drivers/gpu/drm/drm_fb_helper.c | 282 --
include/drm/drm_client.h | 4 +
3 files changed, 292 insertions(+), 282 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 66770ed3299e..b1984f901a6d 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,286 @@ 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;
+}
+EXPORT_SYMBOL(drm_client_panel_rotation);
+
+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(, 0);
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out_ctx;
+ }
+
+ state->acquire_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, )) {
+ /* 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
+
[PATCH v7 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 b936db6280ac..e7f41e5d924c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -48,6 +48,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,
@@ -1809,7 +1813,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;
@@ -1888,7 +1892,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)
{
@@ -1921,7 +1925,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;
@@ -2085,7 +2089,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);
@@ -2255,30 +2259,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 = _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, _iter);
drm_client_for_each_connector_iter(connector, _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][next] drm/i915: fix use of uninitialized pointer vaddr
From: Colin Ian King
The assignment of err is using the incorrect pointer vaddr that has
not been initialized. Fix this by using the correct pointer obj instead.
Addresses-Coverity: ("Uninitialized pointer read")
Fixes: 6501aa4e3a45 ("drm/i915: add in-kernel blitter client")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
index 8de568d2c792..e23d8c9e9298 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
@@ -32,7 +32,7 @@ static int igt_fill_blt(void *arg)
obj = i915_gem_object_create_internal(i915, sz);
if (IS_ERR(obj)) {
- err = PTR_ERR(vaddr);
+ err = PTR_ERR(obj);
goto err_flush;
}
--
2.20.1
[PATCH] drm/panfrost: make devfreq optional again
Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
on Amlogic S912 SoCs missin the "operating-points-v2" property.
Make it optional again, leaving PM_DEVFREQ is selected by default.
Fixes: f3617b449d ("drm/panfrost: Select devfreq")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 29fcffdf2d57..dc75f99ad53b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -140,7 +140,9 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
return 0;
ret = dev_pm_opp_of_add_table(>pdev->dev);
- if (ret)
+ if (ret == -ENODEV) /* Optional, continue without devfreq */
+ return 0;
+ else
return ret;
panfrost_devfreq_reset(pfdev);
@@ -170,6 +172,9 @@ void panfrost_devfreq_resume(struct panfrost_device *pfdev)
{
int i;
+ if (!pfdev->devfreq.devfreq)
+ return;
+
panfrost_devfreq_reset(pfdev);
for (i = 0; i < NUM_JOB_SLOTS; i++)
pfdev->devfreq.slot[i].busy = false;
@@ -179,6 +184,9 @@ void panfrost_devfreq_resume(struct panfrost_device *pfdev)
void panfrost_devfreq_suspend(struct panfrost_device *pfdev)
{
+ if (!pfdev->devfreq.devfreq)
+ return;
+
devfreq_suspend_device(pfdev->devfreq.devfreq);
}
@@ -188,6 +196,9 @@ static void panfrost_devfreq_update_utilization(struct
panfrost_device *pfdev, i
ktime_t now;
ktime_t last;
+ if (!pfdev->devfreq.devfreq)
+ return;
+
now = ktime_get();
last = pfdev->devfreq.slot[slot].time_last_update;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110361] [CI][DRMTIP] igt@kms_chamelium@hdmi-cmp-planes-random - fail - Failed assertion: false, Conversion not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=110361 Lakshmi changed: What|Removed |Added Component|DRM/Intel |IGT QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org --- Comment #4 from Lakshmi --- Moving to IGT as igt_fb.c is missing fb format conversion path. Also, its a sporadic failure because the resources are choosing randomly (intentionally). -- 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 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 29.05.19 um 18:29 schrieb Emil Velikov: > On 2019/05/29, Koenig, Christian wrote: >> Am 29.05.19 um 15:03 schrieb Emil Velikov: >>> On 2019/05/29, Dave Airlie wrote: On Wed, 29 May 2019 at 02:47, Emil Velikov wrote: > On 2019/05/28, Koenig, Christian wrote: >> Am 28.05.19 um 18:10 schrieb Emil Velikov: >>> On 2019/05/28, Daniel Vetter wrote: On Tue, May 28, 2019 at 10:03 AM Koenig, Christian wrote: > Am 28.05.19 um 09:38 schrieb Daniel Vetter: >> [SNIP] >>> Might be a good idea looking into reverting it partially, so that at >>> least command submission and buffer allocation is still blocked. >> I thought the issue is a lot more than vainfo, it's pretty much every >> hacked up compositor under the sun getting this wrong one way or >> another. Thinking about this some more, I also have no idea how you'd >> want to deprecate rendering on primary nodes in general. Apparently >> that breaks -modesetting already, and probably lots more compositors. >> And it looks like we're finally achieve the goal kms set out to 10 >> years ago, and new compositors are sprouting up all the time. I guess >> we could just break them all (on new hardware) and tell them to all >> suck it up. But I don't think that's a great option. And just >> deprecating this on amdgpu is going to be even harder, since then >> everywhere else it'll keep working, and it's just amdgpu.ko that >> looks >> broken. >> >> Aside: I'm not supporting Emil's idea here because it fixes any >> issues >> Intel has - Intel doesn't care. I support it because reality sucks, >> people get this render vs. primary vs. multi-gpu prime wrong all the >> time (that's also why we have hardcoded display+gpu pairs in mesa for >> the various soc combinations out there), and this looks like a >> pragmatic solution. It'd be nice if every compositor and everything >> else would perfectly support multi gpu and only use render nodes for >> rendering, and only primary nodes for display. But reality is that >> people hack on stuff until gears on screen and then move on to more >> interesting things (to them). So I don't think we'll ever win this >> :-/ > Yeah, but this is a classic case of working around user space issues > by > making kernel changes instead of fixing user space. > > Having privileged (output control) and unprivileged (rendering > control) > functionality behind the same node is a mistake we have made a long > time > ago and render nodes finally seemed to be a way to fix that. > > I mean why are compositors using the primary node in the first place? > Because they want to have access to privileged resources I think and > in > this case it is perfectly ok to do so. > > Now extending unprivileged access to the primary node actually sounds > like a step into the wrong direction to me. > > I rather think that we should go down the route of completely dropping > command submission and buffer allocation through the primary node for > non master clients. And then as next step at some point drop support > for > authentication/flink. > > I mean we have done this with UMS as well and I don't see much other > way > to move forward and get rid of those ancient interface in the long > term. Well kms had some really good benefits that drove quick adoption, like "suspend/resume actually has a chance of working" or "comes with buffer management so you can run multiple gears". The render node thing is a lot more niche use case (prime, better priv separation), plus "it's cleaner design". And the "cleaner design" part is something that empirically doesn't seem to matter :-/ Just two examples: - KHR_display/leases just iterated display resources on the fd needed for rendering (and iirc there was even a patch to expose that for render nodes too so it works with DRI3), because implementing protocols is too hard. Barely managed to stop that one before it happened. - Various video players use the vblank ioctl on directly to schedule frames, without telling the compositor. I discovered that when I wanted to limite the vblank ioctl to master clients only. Again, apparently too hard to use the existing extensions, or fix the bugs in there, or whatever. One userspace got fixed last year, but it'll probably get copypasted around forever :-/ So I don't think we'll ever manage to roll a clean
Re: [PATCHv4 00/24] drm/bridge: tc358767: DP support
On 28.05.2019 10:27, Tomi Valkeinen wrote: > Hi, > > tc358767 bridge was originally implemented for eDP use with an embedded > panel. I've been working to add DP and HPD support, and this series is > the result. I did have a lot of issues with link training, but with > these, it's been working reliably with my devices. > > Changes in v2 > * Drop "implement naive HPD handling", and implement HPD interrupt handling. > > Changes in v3 > * Various small comment, description and formatting changes > * 'hpd-num' DT property renamed to 'toshiba,hpd-pin' > * Check DP0CTL == 0 at the beginning of tc_main_link_enable > * Disable only the video stream in tc_stream_disable() > * Fix tc_connector_detect for eDP panels > > Changes in v4 > * Add "read display_props in get_modes()" > * Remove the tc_get_display_props call from detect callback > * Fix the DP0CTL check in tc_main_link_enable. Only check for DP_EN bit, > as we can have other bits set (e.g. after reset VID_MN_GEN is set) > * Added some reviewed-bys > > Tomi > > Tomi Valkeinen (24): > drm/bridge: tc358767: fix tc_aux_get_status error handling > drm/bridge: tc358767: reset voltage-swing & pre-emphasis > drm/bridge: tc358767: fix ansi 8b10b use > drm/bridge: tc358767: cleanup spread & scrambler_dis > drm/bridge: tc358767: remove unused swing & preemp > drm/bridge: tc358767: cleanup aux_link_setup > drm/bridge: tc358767: move video stream setup to tc_main_link_stream > drm/bridge: tc358767: split stream enable/disable > drm/bridge: tc358767: move PXL PLL enable/disable to stream > enable/disable > drm/bridge: tc358767: add link disable function > drm/bridge: tc358767: disable only video stream in tc_stream_disable > drm/bridge: tc358767: ensure DP is disabled before LT > drm/bridge: tc358767: remove unnecessary msleep > drm/bridge: tc358767: use more reliable seq when finishing LT > drm/bridge: tc358767: cleanup LT result check > drm/bridge: tc358767: clean-up link training > drm/bridge: tc358767: remove check for video mode in link enable > drm/bridge: tc358767: use bridge mode_valid > drm/bridge: tc358767: remove tc_connector_best_encoder > drm/bridge: tc358767: copy the mode data, instead of storing the > pointer > drm/bridge: tc358767: read display_props in get_modes() > drm/bridge: tc358767: add GPIO & interrupt registers > drm/bridge: tc358767: add IRQ and HPD support > dt-bindings: tc358767: add HPD support > > .../display/bridge/toshiba,tc358767.txt | 1 + > drivers/gpu/drm/bridge/tc358767.c | 593 +++--- > 2 files changed, 382 insertions(+), 212 deletions(-) Queued to drm-misc-next. Regards Andrzej > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/22] gpu: amdgpu: fix broken amdgpu_dma_buf.c references
Am 30.05.19 um 01:23 schrieb Mauro Carvalho Chehab:
This file was renamed, but docs weren't updated accordingly.
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
PRIME Buffer Sharing ./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c' failed with
return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c' failed with return code 2
Fixes: 988076cd8c5c ("drm/amdgpu: rename amdgpu_prime.[ch] into
amdgpu_dma_buf.[ch]")
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Christian König
---
Documentation/gpu/amdgpu.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index a740e491dfcc..a15199b1b02e 100644
--- a/Documentation/gpu/amdgpu.rst
+++ b/Documentation/gpu/amdgpu.rst
@@ -37,10 +37,10 @@ Buffer Objects
PRIME Buffer Sharing
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
:doc: PRIME Buffer Sharing
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
:internal:
MMU Notifier
Re: Panfrost impossible to probe without opp table
Hi Tomeu, On 31/05/2019 13:59, Tomeu Vizoso wrote: > On Wed, 29 May 2019 at 23:29, Clément Péron wrote: >> >> Hi, >> >> I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is >> no more probing. >> >> The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e >> drm/panfrost: Select devfreq >> >> Currently, there is some logic for the driver to work without devfreq. >> However, the driver actually fails to probe if !CONFIG_PM_DEVFREQ. >> >> Fix this by selecting devfreq, and drop the additional checks >> for devfreq. >> >> It seems that with this commit the OPP table is now mandatory. >> is it intentional? > > Hi Clément, > > devfreq support is intentionally required. I got a H64 board which I'm > using to add T720 support to Panfrost. operating-points-v2 and clocks are optional, devfreq should be optional, this was the default behaviour of the first applied version. Amlogic dt does not have operating-points-v2, and devfreq won't be supported soon. Neil > > Once I'm able to test the GPU properly along with frequency scaling, I > will ping you so you can retest and resubmit. > > Thanks, > > Tomeu > >> Actually >> [3.046237] panfrost 180.gpu: clock rate = 43200 >> [3.051593] panfrost 180.gpu: bus_clock rate = 1 >> [3.096012] panfrost 180.gpu: mali-t720 id 0x720 major 0x1 >> minor 0x1 status 0x0 >> [3.103682] panfrost 180.gpu: features: ,10309e40, >> issues: ,21054400 >> [3.111789] panfrost 180.gpu: Features: L2:0x07110206 >> Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf >> JS:0x7 >> [3.123435] panfrost 180.gpu: shader_present=0x3 l2_present=0x1 >> [3.130405] panfrost 180.gpu: Fatal error during devfreq init >> >> With commit reverted >> [3.038236] panfrost 180.gpu: clock rate = 43200 >> [3.043593] panfrost 180.gpu: bus_clock rate = 1 >> [3.087994] panfrost 180.gpu: mali-t720 id 0x720 major 0x1 >> minor 0x1 status 0x0 >> [3.095658] panfrost 180.gpu: features: ,10309e40, >> issues: ,21054400 >> [3.103763] panfrost 180.gpu: Features: L2:0x07110206 >> Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf >> JS:0x7 >> [3.115410] panfrost 180.gpu: shader_present=0x3 l2_present=0x1 >> [3.122798] [drm] Initialized panfrost 1.0.0 20180908 for >> 180.gpu on minor 0 >> >> >> Thanks, >> Clément >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: make devfreq optional again
On Fri, 2019-05-31 at 14:37 +0200, Neil Armstrong wrote:
> Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
> on Amlogic S912 SoCs missin the "operating-points-v2" property.
> Make it optional again, leaving PM_DEVFREQ is selected by default.
>
> Fixes: f3617b449d ("drm/panfrost: Select devfreq")
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 29fcffdf2d57..dc75f99ad53b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -140,7 +140,9 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> return 0;
>
> ret = dev_pm_opp_of_add_table(>pdev->dev);
> - if (ret)
> + if (ret == -ENODEV) /* Optional, continue without devfreq */
> + return 0;
> + else
> return ret;
>
> panfrost_devfreq_reset(pfdev);
> @@ -170,6 +172,9 @@ void panfrost_devfreq_resume(struct panfrost_device
> *pfdev)
> {
> int i;
>
> + if (!pfdev->devfreq.devfreq)
> + return;
> +
> panfrost_devfreq_reset(pfdev);
> for (i = 0; i < NUM_JOB_SLOTS; i++)
> pfdev->devfreq.slot[i].busy = false;
> @@ -179,6 +184,9 @@ void panfrost_devfreq_resume(struct panfrost_device
> *pfdev)
>
> void panfrost_devfreq_suspend(struct panfrost_device *pfdev)
> {
> + if (!pfdev->devfreq.devfreq)
> + return;
> +
> devfreq_suspend_device(pfdev->devfreq.devfreq);
> }
>
> @@ -188,6 +196,9 @@ static void panfrost_devfreq_update_utilization(struct
> panfrost_device *pfdev, i
> ktime_t now;
> ktime_t last;
>
> + if (!pfdev->devfreq.devfreq)
> + return;
> +
> now = ktime_get();
> last = pfdev->devfreq.slot[slot].time_last_update;
>
This patch should also fix RK3288 platforms, which at the moment are broken
as well by my patch.
I will test and confirm next week.
Thanks for the fix,
Ezequiel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support
On 31/05/2019 13:04, Tomeu Vizoso wrote:
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
On 29/05/2019 16:09, Tomeu Vizoso wrote:
On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
[snip]
[ 345.204813] panfrost 180.gpu: mmu irq status=1
[ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
0x02400400
From what I can see here, 0x02400400 points to the first byte
of the first submitted job descriptor.
So mapping buffers for the GPU doesn't seem to be working at all on
64-bit T-760.
Steven, Robin, do you have any idea of why this could be?
I tried rolling back to the old panfrost/nondrm shim, and it works fine
with kbase, and I also found that T-820 falls over in the exact same
manner, so the fact that it seemed to be common to the smaller 33-bit
designs rather than anything to do with the other
job_descriptor_size/v4/v5 complication turned out to be telling.
Is this complication something you can explain? I don't know what v4
and v5 are meant here.
I was alluding to BASE_HW_FEATURE_V4, which I believe refers to the
Midgard architecture version - the older versions implemented by T6xx
and T720 seem to be collectively treated as "v4", while T760 and T8xx
would effectively be "v5".
[ as an aside, are 64-bit jobs actually known not to work on v4 GPUs, or
is it just that nobody's yet observed a 64-bit blob driving one? ]
I'm looking right now at getting Panfrost working on T720 with 64-bit
descriptors, with the ultimate goal of making Panfrost
64-bit-descriptor only so we can have a single build of Mesa in
distros.
Cool, I'll keep an eye out, and hope that it might be enough for T620 on
Juno, too :)
Long story short, it appears that 'Mali LPAE' is also lacking the start
level notion of VMSA, and expects a full 4-level table even for <40 bits
when level 0 effectively redundant. Thus walking the 3-level table that
io-pgtable comes back with ends up going wildly wrong. The hack below
seems to do the job for me; if Clément can confirm (on T-720 you'll
still need the userspace hack to force 32-bit jobs as well) then I think
I'll cook up a proper refactoring of the allocator to put things right.
Mmaps seem to work with this patch, thanks.
The main complication I'm facing right now seems to be that the SFBD
descriptor on T720 seems to be different from the one we already had
(tested on T6xx?).
OK - with the 32-bit hack pointed to up-thread, a quick kmscube test
gave me the impression that T720 works fine, but on closer inspection
some parts of glmark2 do seem to go a bit wonky (although I suspect at
least some of it is just down to the FPGA setup being both very slow and
lacking in memory bandwidth), and the "nv12-1img" mode of kmscube turns
out to render in some delightfully wrong colours.
I'll try to get a 'proper' version of the io-pgtable patch posted soon.
Thanks,
Robin.
Cheers,
Tomeu
Robin.
->8-
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 546968d8a349..f29da6e8dc08 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -1023,12 +1023,14 @@ arm_mali_lpae_alloc_pgtable(struct
io_pgtable_cfg *cfg, void *cookie)
iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
if (iop) {
u64 mair, ttbr;
+ struct arm_lpae_io_pgtable *data =
io_pgtable_ops_to_data(>ops);
+ data->levels = 4;
/* Copy values as union fields overlap */
mair = cfg->arm_lpae_s1_cfg.mair[0];
ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 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 b1984f901a6d..006bf7390e7d 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, >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 = >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, >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(>head, >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,
+ unsigned int connector_count,
+
[PATCH v7 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 7b388674a456..b936db6280ac 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -95,12 +95,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 _driver.lastclose callback.
* They should also notify the fb helper code from updates to the output
@@ -123,8 +117,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 _framebuffer_funcs.dirty is set, the
* drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functions will
@@ -137,165 +130,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(_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(_helper->lock);
- err = __drm_fb_helper_add_one_connector(fb_helper, connector);
- mutex_unlock(_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
- * @fb_helper:
[PATCH v7 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 6b34949416b1..d77a67cf3a89 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -66,6 +66,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 d36feb4a6233..86a2ceb95838 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(>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 = >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(>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 (tiled) {
+
[PATCH v7 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 4a63c1fcf389..d36feb4a6233 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_hdcp.o + drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.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 e7870a54f498..410572f14257 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
[PATCH v7 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: - Declare drm_mode_set and drm_plane_state in patch 1 - Export drm_client_panel_rotation() (Gerd Hoffmann) - Rebase Noralf. Cc: Gerd Hoffmann 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 | 1087 + drivers/gpu/drm/drm_crtc_internal.h |7 + 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, 1803 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 v7 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
v7: Declare drm_mode_set and drm_plane_state
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 | 7 ++
include/drm/drm_atomic_helper.h | 4 -
4 files changed, 175 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b640e77184e5..169f06d7c5ce 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1179,6 +1179,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(>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
[PATCH v7 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 b9b7c06cbc4f..64800d43837d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -393,9 +393,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;
@@ -436,10 +447,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 = _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;
@@ -479,7 +489,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, )) {
+ if (drm_client_panel_rotation(mode_set, )) {
/* 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;
@@ -521,15 +531,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 = _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);
@@ -558,35 +567,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(_helper->client.modeset_mutex);
+ mutex_lock(>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(_helper->client.modeset_mutex);
+ ret = drm_client_modeset_commit_legacy(client);
+ mutex_unlock(>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_client_modeset_commit(struct drm_client_dev
Re: [PATCH 11/22] gpu: amdgpu: fix broken amdgpu_dma_buf.c references
On Fri, May 31, 2019 at 10:00 AM Christian König
wrote:
>
> Am 30.05.19 um 01:23 schrieb Mauro Carvalho Chehab:
> > This file was renamed, but docs weren't updated accordingly.
> >
> > WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno
> > -function PRIME Buffer Sharing ./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c'
> > failed with return code 1
> > WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno
> > -internal ./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c' failed with return
> > code 2
> >
> > Fixes: 988076cd8c5c ("drm/amdgpu: rename amdgpu_prime.[ch] into
> > amdgpu_dma_buf.[ch]")
> > Signed-off-by: Mauro Carvalho Chehab
>
> Reviewed-by: Christian König
>
Applied. thanks!
Alex
> > ---
> > Documentation/gpu/amdgpu.rst | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
> > index a740e491dfcc..a15199b1b02e 100644
> > --- a/Documentation/gpu/amdgpu.rst
> > +++ b/Documentation/gpu/amdgpu.rst
> > @@ -37,10 +37,10 @@ Buffer Objects
> > PRIME Buffer Sharing
> >
> >
> > -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> > +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > :doc: PRIME Buffer Sharing
> >
> > -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> > +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > :internal:
> >
> > MMU Notifier
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] drm/msm: fix fb references in async update
Hello,
On 3/13/19 9:20 PM, Helen Koike wrote:
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Cc: # v4.14+
> Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic")
> Suggested-by: Boris Brezillon
> Signed-off-by: Helen Koike
>
> ---
> Hello,
>
> As mentioned in the cover letter,
> But I couldn't test on MSM because I don't have the hardware and I would
> appreciate if anyone could test it.
I got this tested on a dragonboard 410c, no regressions where found and
no extra warnings.
These two tests where already failing for other reasons:
flip-vs-cursor-crc-atomic
flip-vs-cursor-crc-legacy
If you want to see the full log:
https://people.collabora.com/~koike/drm-fixes-results.zip
Thanks
Helen
>
> In other platforms (VC4, AMD, Rockchip), there is a hidden
> drm_framebuffer_get(new_fb)/drm_framebuffer_put(old_fb) in async_update
> that is wrong, but I couldn't identify those here, not sure if it is hidden
> somewhere else, but if tests fail this is probably the cause.
>
> Thanks!
> Helen
>
> Changes in v3: None
> Changes in v2:
> - update CC stable and Fixes tag
>
> drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> index be13140967b4..b854f471e9e5 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> @@ -502,6 +502,8 @@ static int mdp5_plane_atomic_async_check(struct drm_plane
> *plane,
> static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
> struct drm_plane_state *new_state)
> {
> + struct drm_framebuffer *old_fb = plane->state->fb;
> +
> plane->state->src_x = new_state->src_x;
> plane->state->src_y = new_state->src_y;
> plane->state->crtc_x = new_state->crtc_x;
> @@ -524,6 +526,8 @@ static void mdp5_plane_atomic_async_update(struct
> drm_plane *plane,
>
> *to_mdp5_plane_state(plane->state) =
> *to_mdp5_plane_state(new_state);
> +
> + new_state->fb = old_fb;
> }
>
> static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
>
[Bug 110725] [CI][SHARDS] igt@kms_big_fb@(linear|x-tiled|y-tiled)-(16|32|64)bpp-rotate-(90|270) - skip - unsupported configuration, SKIP
https://bugs.freedesktop.org/show_bug.cgi?id=110725 Ville Syrjala changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #9 from Ville Syrjala --- (In reply to Martin Peres from comment #1) > How about skipping faster when the configuration is unsupported? Skipping should be faster now. I have no idea how to get cibuglog to show me the pretty graphs for that so no idea by how much. Going to assume it's good enough. -- 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: Flush output polling on shutdown
We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:c96cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: RBX: 88826759a168 RCX: <4> [341.846589] RDX: 0002 RSI: RDI: 8112844c <4> [341.846595] RBP: 8882708fa548 R08: R09: 00039600 <4> [341.846601] R10: R11: 0ce4 R12: a07de1e0 <4> [341.846607] R13: R14: R15: a07de2d0 <4> [341.846613] FS: 7f62b5ae0e40() GS:88827638() knlGS: <4> [341.846620] CS: 0010 DS: ES: CR0: 80050033 <4> [341.846626] CR2: 55a4e064f4a0 CR3: 000266b16006 CR4: 003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:7ffe7a227138 EFLAGS: 0206 ORIG_RAX: 00b0 <4> [341.846904] RAX: ffda RBX: 7ffe7a2272b0 RCX: 7f62b51871b7 <4> [341.846910] RDX: 0001 RSI: 0800 RDI: 557cd6b55948 <4> [341.846916] RBP: 557cd6b558e0 R08: 557cd6b5594c R09: 7ffe7a227160 <4> [341.846922] R10: 7ffe7a226134 R11: 0206 R12: <4> [341.846927] R13: 7ffe7a227820 R14: R15: <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware
Re: [git pull] drm fixes for 5.2-rc3
The pull request you sent on Fri, 31 May 2019 11:12:45 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-31 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ca1918049673a9be507c41fb7e4a69a57601a017 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Flush output polling on shutdown
Quoting Chris Wilson (2019-05-31 18:16:15) > We need to mark the output polling as disabled to prevent concurrent > irqs from queuing new work as shutdown the probe -- causing that work to > execute after we have freed the structs: > > <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) > <4> [341.846497] WARNING: CPU: 3 PID: 3300 at > kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 > <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt > snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp > x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 > btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei > prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] > <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U > 5.2.0-rc2-CI-CI_DRM_6175+ #1 > <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 > 07/09/2018 > <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 > <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 > 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> > 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 > <4> [341.846578] RSP: 0018:c96cfdb0 EFLAGS: 00010286 > <4> [341.846583] RAX: RBX: 88826759a168 RCX: > > <4> [341.846589] RDX: 0002 RSI: RDI: > 8112844c > <4> [341.846595] RBP: 8882708fa548 R08: R09: > 00039600 > <4> [341.846601] R10: R11: 0ce4 R12: > a07de1e0 > <4> [341.846607] R13: R14: R15: > a07de2d0 > <4> [341.846613] FS: 7f62b5ae0e40() GS:88827638() > knlGS: > <4> [341.846620] CS: 0010 DS: ES: CR0: 80050033 > <4> [341.846626] CR2: 55a4e064f4a0 CR3: 000266b16006 CR4: > 003606e0 > <4> [341.846632] Call Trace: > <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 > <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] > <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] > <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] > <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] > <4> [341.846784] pci_device_remove+0x36/0xb0 > <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 > <4> [341.846795] driver_detach+0x3f/0x80 > <4> [341.846800] bus_remove_driver+0x53/0xd0 > <4> [341.846805] pci_unregister_driver+0x25/0xa0 > <4> [341.846843] i915_exit+0x16/0x1c [i915] > <4> [341.846849] __se_sys_delete_module+0x162/0x210 > <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c > <4> [341.846859] ? do_syscall_64+0xd/0x1c0 > <4> [341.846864] do_syscall_64+0x55/0x1c0 > <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe > <4> [341.846875] RIP: 0033:0x7f62b51871b7 > <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 > ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> > 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 > <4> [341.846897] RSP: 002b:7ffe7a227138 EFLAGS: 0206 ORIG_RAX: > 00b0 > <4> [341.846904] RAX: ffda RBX: 7ffe7a2272b0 RCX: > 7f62b51871b7 > <4> [341.846910] RDX: 0001 RSI: 0800 RDI: > 557cd6b55948 > <4> [341.846916] RBP: 557cd6b558e0 R08: 557cd6b5594c R09: > 7ffe7a227160 > <4> [341.846922] R10: 7ffe7a226134 R11: 0206 R12: > > <4> [341.846927] R13: 7ffe7a227820 R14: R15: > > <4> [341.846936] irq event stamp: 3547847 > <4> [341.846940] hardirqs last enabled at (3547847): [] > _raw_spin_unlock_irqrestore+0x4c/0x60 > <4> [341.846949] hardirqs last disabled at (3547846): [] > _raw_spin_lock_irqsave+0xd/0x50 > <4> [341.846957] softirqs last enabled at (3547376): [] > __do_softirq+0x33a/0x4b9 > <4> [341.846966] softirqs last disabled at (3547367): [] > irq_exit+0xa9/0xc0 > <4> [341.846973] WARNING: CPU: 3 PID: 3300 at > kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 > <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- > <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: > no, modparam: yes > <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 > <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found > <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 > <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] > [CONNECTOR:86:eDP-1] probed modes : > <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 > 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa > <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 > 298600 3200 3248 3280 3360 1800
[PATCH v2] drm: Flush output polling on shutdown
We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:c96cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: RBX: 88826759a168 RCX: <4> [341.846589] RDX: 0002 RSI: RDI: 8112844c <4> [341.846595] RBP: 8882708fa548 R08: R09: 00039600 <4> [341.846601] R10: R11: 0ce4 R12: a07de1e0 <4> [341.846607] R13: R14: R15: a07de2d0 <4> [341.846613] FS: 7f62b5ae0e40() GS:88827638() knlGS: <4> [341.846620] CS: 0010 DS: ES: CR0: 80050033 <4> [341.846626] CR2: 55a4e064f4a0 CR3: 000266b16006 CR4: 003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:7ffe7a227138 EFLAGS: 0206 ORIG_RAX: 00b0 <4> [341.846904] RAX: ffda RBX: 7ffe7a2272b0 RCX: 7f62b51871b7 <4> [341.846910] RDX: 0001 RSI: 0800 RDI: 557cd6b55948 <4> [341.846916] RBP: 557cd6b558e0 R08: 557cd6b5594c R09: 7ffe7a227160 <4> [341.846922] R10: 7ffe7a226134 R11: 0206 R12: <4> [341.846927] R13: 7ffe7a227820 R14: R15: <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware
Re: [PATCH] drm/gem_shmem: Use a writecombine mapping for ->vaddr
Boris Brezillon writes: > Right now, the BO is mapped as a cached region when ->vmap() is called > and the underlying object is not a dmabuf. > Doing that makes cache management a bit more complicated (you'd need > to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about > to be passed to the GPU/CPU), so let's map the BO with writecombine > attributes instead (as done in most drivers). > > Signed-off-by: Boris Brezillon > --- > Found this issue while working on panfrost perfcnt where the GPU dumps > perf counter values in memory and the CPU reads them back in > kernel-space. This patch seems to solve the unpredictable behavior I > had. > > I can also go for the other option (call dma_map/unmap/_sg() when > needed) if you think that's more appropriate. writecombined was the intent, and this makes kernel vmap match the userspace mmap path. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Flush output polling on shutdown
We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:c96cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: RBX: 88826759a168 RCX: <4> [341.846589] RDX: 0002 RSI: RDI: 8112844c <4> [341.846595] RBP: 8882708fa548 R08: R09: 00039600 <4> [341.846601] R10: R11: 0ce4 R12: a07de1e0 <4> [341.846607] R13: R14: R15: a07de2d0 <4> [341.846613] FS: 7f62b5ae0e40() GS:88827638() knlGS: <4> [341.846620] CS: 0010 DS: ES: CR0: 80050033 <4> [341.846626] CR2: 55a4e064f4a0 CR3: 000266b16006 CR4: 003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:7ffe7a227138 EFLAGS: 0206 ORIG_RAX: 00b0 <4> [341.846904] RAX: ffda RBX: 7ffe7a2272b0 RCX: 7f62b51871b7 <4> [341.846910] RDX: 0001 RSI: 0800 RDI: 557cd6b55948 <4> [341.846916] RBP: 557cd6b558e0 R08: 557cd6b5594c R09: 7ffe7a227160 <4> [341.846922] R10: 7ffe7a226134 R11: 0206 R12: <4> [341.846927] R13: 7ffe7a227820 R14: R15: <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware
[PATCH] drm/amdgpu: Remove call to memset after dma_alloc_coherent
This patch fixes below warning reported by coccicheck ./drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c:63:13-31: WARNING: dma_alloc_coherent use in ih -> ring already zeroes out memory, so memset is not needed Signed-off-by: Hariprasad Kelam --- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c index 934dfdc..d922187 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c @@ -65,7 +65,6 @@ int amdgpu_ih_ring_init(struct amdgpu_device *adev, struct amdgpu_ih_ring *ih, if (ih->ring == NULL) return -ENOMEM; - memset((void *)ih->ring, 0, ih->ring_size + 8); ih->gpu_addr = dma_addr; ih->wptr_addr = dma_addr + ih->ring_size; ih->wptr_cpu = >ring[ih->ring_size / 4]; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] drm/msm: fix fb references in async update
On Fri, May 31, 2019 at 10:54 AM Helen Koike wrote:
>
> Hello,
>
> On 3/13/19 9:20 PM, Helen Koike wrote:
> > Async update callbacks are expected to set the old_fb in the new_state
> > so prepare/cleanup framebuffers are balanced.
> >
> > Cc: # v4.14+
> > Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through
> > atomic")
> > Suggested-by: Boris Brezillon
> > Signed-off-by: Helen Koike
Thanks, I'm not super happy about the refcnt'ing subtleness here
(mostly because it makes it harder to page in how things work on
kernel/display side after spending most of my time in userspace/mesa),
but I don't want to hold this up..
Acked-by: Rob Clark
> >
> > ---
> > Hello,
> >
> > As mentioned in the cover letter,
> > But I couldn't test on MSM because I don't have the hardware and I would
> > appreciate if anyone could test it.
>
> I got this tested on a dragonboard 410c, no regressions where found and
> no extra warnings.
>
> These two tests where already failing for other reasons:
> flip-vs-cursor-crc-atomic
> flip-vs-cursor-crc-legacy
>
> If you want to see the full log:
>
> https://people.collabora.com/~koike/drm-fixes-results.zip
>
> Thanks
> Helen
>
> >
> > In other platforms (VC4, AMD, Rockchip), there is a hidden
> > drm_framebuffer_get(new_fb)/drm_framebuffer_put(old_fb) in async_update
> > that is wrong, but I couldn't identify those here, not sure if it is hidden
> > somewhere else, but if tests fail this is probably the cause.
> >
> > Thanks!
> > Helen
> >
> > Changes in v3: None
> > Changes in v2:
> > - update CC stable and Fixes tag
> >
> > drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> > index be13140967b4..b854f471e9e5 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> > @@ -502,6 +502,8 @@ static int mdp5_plane_atomic_async_check(struct
> > drm_plane *plane,
> > static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
> > struct drm_plane_state *new_state)
> > {
> > + struct drm_framebuffer *old_fb = plane->state->fb;
> > +
> > plane->state->src_x = new_state->src_x;
> > plane->state->src_y = new_state->src_y;
> > plane->state->crtc_x = new_state->crtc_x;
> > @@ -524,6 +526,8 @@ static void mdp5_plane_atomic_async_update(struct
> > drm_plane *plane,
> >
> > *to_mdp5_plane_state(plane->state) =
> > *to_mdp5_plane_state(new_state);
> > +
> > + new_state->fb = old_fb;
> > }
> >
> > static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amd/display: remove redundant assignment to status
On 2019-05-30 12:12 p.m., Colin King wrote:
> From: Colin Ian King
>
> The variable status is initialized with a value that is never read
> and status is reassigned several statements later. This initialization
> is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 65d6caedbd82..cf6166a1be53 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -2367,7 +2367,7 @@ static bool retrieve_link_cap(struct dc_link *link)
> union down_stream_port_count down_strm_port_count;
> union edp_configuration_cap edp_config_cap;
> union dp_downstream_port_present ds_port = { 0 };
> - enum dc_status status = DC_ERROR_UNEXPECTED;
> + enum dc_status status;
Not sure this improves the situation.
I'd prefer to have a default here in case someone changes the code below
and forgets to set the status.
Harry
> uint32_t read_dpcd_retry_cnt = 3;
> int i;
> struct dp_sink_hw_fw_revision dp_hw_fw_revision;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm_memory: fix a few warnings
The opening comment mark "/**" is reserved for kernel-doc comments, so it will generate a warning with "make W=1". drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file drm_memory.c Also, silence a checkpatch warning, WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 Signed-off-by: Qian Cai --- drivers/gpu/drm/drm_memory.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c index 132fef8ff1b6..683042c8ee2c 100644 --- a/drivers/gpu/drm/drm_memory.c +++ b/drivers/gpu/drm/drm_memory.c @@ -1,4 +1,5 @@ -/** +// SPDX-License-Identifier: MIT +/* * \file drm_memory.c * Memory management wrappers for DRM * -- 1.8.3.1
[Bug 110658] MXGP3 (Steam, native Linux port, UE4): graphical glitches
https://bugs.freedesktop.org/show_bug.cgi?id=110658 --- Comment #6 from Alexander Mezin --- (In reply to Timothy Arceri from comment #4) > I've run it on llvm 8 and mesa 19.0.5 and was unable to reproduce the issues > seen in the screen capture on my Vega 64. What kernel version and distro are you running? Mine are kernel 5.1.5, distro Arch linux -- 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 110805] All the friends in the friend list is not listed
https://bugs.freedesktop.org/show_bug.cgi?id=110805 Bug ID: 110805 Summary: All the friends in the friend list is not listed Product: Mesa Version: 18.3 Hardware: x86 (IA32) OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 Assignee: dri-devel@lists.freedesktop.org Reporter: coolsm1...@gmail.com QA Contact: dri-devel@lists.freedesktop.org login to the fb using user credentials enter user name enter password click on login button the landing page is the home page click on the add friend the friend list should be listed. Expected results enter user name enter password click on login button the landing page is the home page click on the add friend the friend list should be listed. Actual results enter user name enter password click on login button the landing page is the home page click on the add friend All the friend in the list is not listed. -- 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/msm/adreno: Ensure that the zap shader region is big enough
Before loading the zap shader we should ensure that the reserved memory
region is big enough to hold the loaded file.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 6f7f411..3db8e49 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -67,7 +67,6 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname,
return ret;
mem_phys = r.start;
- mem_size = resource_size();
/* Request the MDT file for the firmware */
fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
@@ -83,6 +82,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname,
goto out;
}
+ if (mem_size > resource_size()) {
+ DRM_DEV_ERROR(dev,
+ "memory region is too small to load the MDT\n");
+ ret = -E2BIG;
+ goto out;
+ }
+
/* Allocate memory for the firmware image */
mem_region = memremap(mem_phys, mem_size, MEMREMAP_WC);
if (!mem_region) {
--
2.7.4
[Bug 110805] All the friends in the friend list is not listed
https://bugs.freedesktop.org/show_bug.cgi?id=110805 Andre Klapper changed: What|Removed |Added Component|Drivers/DRI/i915|Two Version|18.3|unspecified Group||spam Resolution|--- |INVALID Status|NEW |RESOLVED Product|Mesa|Spam --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- 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 203627] [Regression] Boot fails with linux-firmware 20190514
https://bugzilla.kernel.org/show_bug.cgi?id=203627 --- Comment #4 from Aleksandr Mezin (mezin.alexan...@gmail.com) --- Nothing changed with 4.19.46 and 4.19.47 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm/dsi: add protection against NULL dsi device
When panel probe happens after DSI probe, the DSI probe is deferred as
per current design. In the probe defer path dsi device is destroyed.
This NULL dsi device could be deferenced by the panel probe in the
mipi_dsi_attach path.
Check for NULL dsi device before accessing it.
Changes in v2:
- Add more comments on how this NULL pointer situation will be hit
Reported-by: Jeffrey Hugo
Tested-by: Jeffrey Hugo
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 80aa634..8fcb13f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base,
u32 len)
void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags)
{
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
- struct drm_device *dev = msm_dsi->dev;
+ struct drm_device *dev;
struct msm_drm_private *priv;
struct msm_kms *kms;
struct drm_encoder *encoder;
@@ -781,7 +781,17 @@ void msm_dsi_manager_attach_dsi_device(int id, u32
device_flags)
* (generally the case when we're connected to a drm_panel of the type
* mipi_dsi_device), this would be NULL. In such cases, try to set the
* encoder mode in the DSI connector's detect() op.
+*
+* msm_dsi pointer is assigned to a valid dsi device only when
+* msm_dsi_manager_register() succeeds. When panel hasnt probed yet
+* dsi_mgr_setup_components() could potentially return -EDEFER and
+* assign the msm_dsi->dev to NULL. When the panel now probes and calls
+* mipi_dsi_attach(), this will call msm_dsi_manager_attach_dsi_device()
+* which will result in a NULL pointer dereference
*/
+
+ dev = msm_dsi ? msm_dsi->dev : NULL;
+
if (!dev)
return;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/adreno: Ensure that the zap shader region is big enough
On Fri 31 May 15:09 PDT 2019, Jordan Crouse wrote:
> Before loading the zap shader we should ensure that the reserved memory
> region is big enough to hold the loaded file.
>
> Signed-off-by: Jordan Crouse
Reviewed-by: Bjorn Andersson
> ---
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 6f7f411..3db8e49 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -67,7 +67,6 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
> char *fwname,
> return ret;
>
> mem_phys = r.start;
> - mem_size = resource_size();
>
> /* Request the MDT file for the firmware */
> fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> @@ -83,6 +82,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
> char *fwname,
> goto out;
> }
>
> + if (mem_size > resource_size()) {
> + DRM_DEV_ERROR(dev,
> + "memory region is too small to load the MDT\n");
> + ret = -E2BIG;
> + goto out;
> + }
> +
> /* Allocate memory for the firmware image */
> mem_region = memremap(mem_phys, mem_size, MEMREMAP_WC);
> if (!mem_region) {
> --
> 2.7.4
>
