Re: [PATCH] drm/msm/dsi: Use connector directly in msm_dsi_manager_connector_init()
On 3/17/2022 5:07 PM, Stephen Boyd wrote:
The member 'msm_dsi->connector' isn't assigned until
msm_dsi_manager_connector_init() returns (see msm_dsi_modeset_init() and
how it assigns the return value). Therefore this pointer is going to be
NULL here. Let's use 'connector' which is what was intended.
Cc: Dmitry Baryshkov
Cc: Sean Paul
Fixes: 6d5e78406991 ("drm/msm/dsi: Move dsi panel init into modeset init path")
Signed-off-by: Stephen Boyd
Reviewed-by: Abhinav Kumar
---
I don't know if this is superseeded by something else but I found this
while trying to use the connector from msm_dsi in this function.
drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 0c1b7dde377c..9f6af0f0fe00 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -638,7 +638,7 @@ struct drm_connector *msm_dsi_manager_connector_init(u8 id)
return connector;
fail:
- connector->funcs->destroy(msm_dsi->connector);
+ connector->funcs->destroy(connector);
return ERR_PTR(ret);
}
base-commit: 05afd57f4d34602a652fdaf58e0a2756b3c20fd4
[PATCH 03/10] drm/sun4i: Remove obsolete references to PHYS_OFFSET
commit b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a
central place") added a platform device notifier that sets the DMA
offset for all of the display engine frontend and backend devices.
The code applying the offset to DMA buffer physical addresses was then
removed from the backend driver in commit 756668ba682e ("drm/sun4i:
backend: Remove the MBUS quirks"), but the code subtracting PHYS_OFFSET
was left in the frontend driver.
As a result, the offset was applied twice in the frontend driver. This
likely went unnoticed because it only affects specific configurations
(scaling or certain pixel formats) where the frontend is used, on boards
with both one of these older SoCs and more than 1 GB of DRAM.
In addition, the references to PHYS_OFFSET prevent compiling the driver
on architectures where PHYS_OFFSET is not defined.
Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a central
place")
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 56ae38389db0..462fae73eae9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -222,13 +222,11 @@ void sun4i_frontend_update_buffer(struct sun4i_frontend
*frontend,
/* Set the physical address of the buffer in memory */
paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
- paddr -= PHYS_OFFSET;
DRM_DEBUG_DRIVER("Setting buffer #0 address to %pad\n", );
regmap_write(frontend->regs, SUN4I_FRONTEND_BUF_ADDR0_REG, paddr);
if (fb->format->num_planes > 1) {
paddr = drm_fb_cma_get_gem_addr(fb, state, swap ? 2 : 1);
- paddr -= PHYS_OFFSET;
DRM_DEBUG_DRIVER("Setting buffer #1 address to %pad\n", );
regmap_write(frontend->regs, SUN4I_FRONTEND_BUF_ADDR1_REG,
paddr);
@@ -236,7 +234,6 @@ void sun4i_frontend_update_buffer(struct sun4i_frontend
*frontend,
if (fb->format->num_planes > 2) {
paddr = drm_fb_cma_get_gem_addr(fb, state, swap ? 1 : 2);
- paddr -= PHYS_OFFSET;
DRM_DEBUG_DRIVER("Setting buffer #2 address to %pad\n", );
regmap_write(frontend->regs, SUN4I_FRONTEND_BUF_ADDR2_REG,
paddr);
--
2.35.1
[PATCH 08/10] drm/sun4i: Add support for D1 TCON TOP
D1 has a TCON TOP with TCON TV0 and DSI, but no TCON TV1. This puts the
DSI clock name at index 1 in clock-output-names. Support this by only
incrementing the index for clocks that are actually supported.
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index 1b9b8b48f4a7..da97682b6835 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -189,22 +189,23 @@ static int sun8i_tcon_top_bind(struct device *dev, struct
device *master,
* if TVE is active on each TCON TV. If it is, mux should be switched
* to TVE clock parent.
*/
+ i = 0;
clk_data->hws[CLK_TCON_TOP_TV0] =
sun8i_tcon_top_register_gate(dev, "tcon-tv0", regs,
_top->reg_lock,
-TCON_TOP_TCON_TV0_GATE, 0);
+TCON_TOP_TCON_TV0_GATE, i++);
if (quirks->has_tcon_tv1)
clk_data->hws[CLK_TCON_TOP_TV1] =
sun8i_tcon_top_register_gate(dev, "tcon-tv1", regs,
_top->reg_lock,
-TCON_TOP_TCON_TV1_GATE, 1);
+TCON_TOP_TCON_TV1_GATE,
i++);
if (quirks->has_dsi)
clk_data->hws[CLK_TCON_TOP_DSI] =
sun8i_tcon_top_register_gate(dev, "dsi", regs,
_top->reg_lock,
-TCON_TOP_TCON_DSI_GATE, 2);
+TCON_TOP_TCON_DSI_GATE,
i++);
for (i = 0; i < CLK_NUM; i++)
if (IS_ERR(clk_data->hws[i])) {
@@ -272,6 +273,10 @@ static const struct sun8i_tcon_top_quirks
sun8i_r40_tcon_top_quirks = {
.has_dsi= true,
};
+static const struct sun8i_tcon_top_quirks sun20i_d1_tcon_top_quirks = {
+ .has_dsi= true,
+};
+
static const struct sun8i_tcon_top_quirks sun50i_h6_tcon_top_quirks = {
/* Nothing special */
};
@@ -282,6 +287,10 @@ const struct of_device_id sun8i_tcon_top_of_table[] = {
.compatible = "allwinner,sun8i-r40-tcon-top",
.data = _r40_tcon_top_quirks
},
+ {
+ .compatible = "allwinner,sun20i-d1-tcon-top",
+ .data = _d1_tcon_top_quirks
+ },
{
.compatible = "allwinner,sun50i-h6-tcon-top",
.data = _h6_tcon_top_quirks
--
2.35.1
[PATCH 09/10] drm/sun4i: Add support for D1 TCONs
D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
While there are some register changes, the part of the TCON TV supported
by the driver matches the R40 quirks, so that quirks structure can be
reused. D1 has the first supported TCON LCD with a TCON TOP, so the TCON
LCD needs a new quirks structure.
D1's TCON LCD hardware supports LVDS; in fact it provides dual-link LVDS
from a single TCON. However, it comes with a brand new LVDS PHY. Since
this PHY has not been tested, leave out LVDS driver support for now.
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 88db2d2a9336..2ee158aaeb9e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1542,6 +1542,12 @@ static const struct sun4i_tcon_quirks
sun9i_a80_tcon_tv_quirks = {
.needs_edp_reset = true,
};
+static const struct sun4i_tcon_quirks sun20i_d1_lcd_quirks = {
+ .has_channel_0 = true,
+ .dclk_min_div = 1,
+ .set_mux= sun8i_r40_tcon_tv_set_mux,
+};
+
/* sun4i_drv uses this list to check if a device node is a TCON */
const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun4i-a10-tcon", .data = _a10_quirks },
@@ -1559,6 +1565,8 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-lcd", .data =
_a80_tcon_lcd_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-tv", .data =
_a80_tcon_tv_quirks },
+ { .compatible = "allwinner,sun20i-d1-tcon-lcd", .data =
_d1_lcd_quirks },
+ { .compatible = "allwinner,sun20i-d1-tcon-tv", .data =
_r40_tv_quirks },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
--
2.35.1
[PATCH 07/10] drm/sun4i: Add support for D1 mixers
D1 has a display engine with the usual pair of mixers, albeit with
relatively few layers. In fact, D1 appears to be the first SoC to have
a mixer without any UI layers. Add support for these new variants.
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index f5e8aeaa3cdf..49c0d17c6f0a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -585,6 +585,24 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.mod_rate = 15000,
};
+static const struct sun8i_mixer_cfg sun20i_d1_mixer0_cfg = {
+ .ccsc = 2,
+ .mod_rate = 29700,
+ .scaler_mask= 0x3,
+ .scanline_yuv = 2048,
+ .ui_num = 1,
+ .vi_num = 1,
+};
+
+static const struct sun8i_mixer_cfg sun20i_d1_mixer1_cfg = {
+ .ccsc = 1,
+ .mod_rate = 29700,
+ .scaler_mask= 0x1,
+ .scanline_yuv = 1024,
+ .ui_num = 0,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun50i_a64_mixer0_cfg = {
.ccsc = 0,
.mod_rate = 29700,
@@ -638,6 +656,14 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = _v3s_mixer_cfg,
},
+ {
+ .compatible = "allwinner,sun20i-d1-de2-mixer-0",
+ .data = _d1_mixer0_cfg,
+ },
+ {
+ .compatible = "allwinner,sun20i-d1-de2-mixer-1",
+ .data = _d1_mixer1_cfg,
+ },
{
.compatible = "allwinner,sun50i-a64-de2-mixer-0",
.data = _a64_mixer0_cfg,
--
2.35.1
[PATCH 10/10] drm/sun4i: Add compatible for D1 display engine
Now that the various blocks in the D1 display engine pipeline are
supported, we can enable the overall engine.
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 6a9ba8a77c77..275f7e4a03ae 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -418,6 +418,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun8i-r40-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ .compatible = "allwinner,sun9i-a80-display-engine" },
+ { .compatible = "allwinner,sun20i-d1-display-engine" },
{ .compatible = "allwinner,sun50i-a64-display-engine" },
{ .compatible = "allwinner,sun50i-h6-display-engine" },
{ }
--
2.35.1
[PATCH 00/10] drm/sun4i: Allwinner D1 Display Engine 2.0 Support
This series adds binding and driver support for Display Engine 2.0 variant found in the Allwinner D1. So far it has only been tested with HDMI. I will be sending the HDMI support series separately, because the hardware comes with a brand new custom HDMI PHY, which requires some refactoring to support cleanly. Samuel Holland (10): dt-bindings: display: Separate clock item lists by compatible dt-bindings: display: Add D1 display engine compatibles drm/sun4i: Remove obsolete references to PHYS_OFFSET drm/sun4i: Allow building the driver on RISC-V drm/sun4i: csc: Add support for the new MMIO layout drm/sun4i: Allow VI layers to be primary planes drm/sun4i: Add support for D1 mixers drm/sun4i: Add support for D1 TCON TOP drm/sun4i: Add support for D1 TCONs drm/sun4i: Add compatible for D1 display engine .../allwinner,sun4i-a10-display-engine.yaml | 1 + .../display/allwinner,sun4i-a10-tcon.yaml | 2 + .../allwinner,sun8i-a83t-de2-mixer.yaml | 2 + .../display/allwinner,sun8i-r40-tcon-top.yaml | 145 -- drivers/gpu/drm/sun4i/Kconfig | 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 + drivers/gpu/drm/sun4i/sun4i_frontend.c| 3 - drivers/gpu/drm/sun4i/sun4i_tcon.c| 8 + drivers/gpu/drm/sun4i/sun8i_csc.c | 3 +- drivers/gpu/drm/sun4i/sun8i_csc.h | 1 + drivers/gpu/drm/sun4i/sun8i_mixer.c | 26 drivers/gpu/drm/sun4i/sun8i_mixer.h | 6 +- drivers/gpu/drm/sun4i/sun8i_tcon_top.c| 15 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 36 - 14 files changed, 196 insertions(+), 55 deletions(-) -- 2.35.1
[PATCH 06/10] drm/sun4i: Allow VI layers to be primary planes
D1's mixer 1 has no UI layers, only a single VI layer. That means the
mixer can only be used if the primary plane comes from this VI layer.
Add the code to handle this case, setting the mixer's global registers
in the same way as when the primary plane comes from a UI layer.
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 36 +-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index bb7c43036dfa..86212cb2098c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -146,6 +146,36 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
insize = SUN8I_MIXER_SIZE(src_w, src_h);
outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
+ if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
+ bool interlaced = false;
+ u32 val;
+
+ DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
+dst_w, dst_h);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_GLOBAL_SIZE,
+outsize);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_BLEND_OUTSIZE(bld_base), outsize);
+
+ if (state->crtc)
+ interlaced = state->crtc->state->adjusted_mode.flags
+ & DRM_MODE_FLAG_INTERLACE;
+
+ if (interlaced)
+ val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
+ else
+ val = 0;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_BLEND_OUTCTL(bld_base),
+ SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
+ val);
+
+ DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
+interlaced ? "on" : "off");
+ }
+
/* Set height and width */
DRM_DEBUG_DRIVER("Layer source offset X: %d Y: %d\n",
(state->src.x1 >> 16) & ~(format->hsub - 1),
@@ -542,6 +572,7 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
drm_device *drm,
struct sun8i_mixer *mixer,
int index)
{
+ enum drm_plane_type type = DRM_PLANE_TYPE_OVERLAY;
u32 supported_encodings, supported_ranges;
unsigned int plane_cnt, format_count;
struct sun8i_vi_layer *layer;
@@ -560,12 +591,15 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
drm_device *drm,
format_count = ARRAY_SIZE(sun8i_vi_layer_formats);
}
+ if (!mixer->cfg->ui_num && index == 0)
+ type = DRM_PLANE_TYPE_PRIMARY;
+
/* possible crtcs are set later */
ret = drm_universal_plane_init(drm, >plane, 0,
_vi_layer_funcs,
formats, format_count,
sun8i_layer_modifiers,
- DRM_PLANE_TYPE_OVERLAY, NULL);
+ type, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't initialize layer\n");
return ERR_PTR(ret);
--
2.35.1
[PATCH 04/10] drm/sun4i: Allow building the driver on RISC-V
Allwinner D1 is a RISC-V SoC which contains a DE 2.0 engine. Let's remove the dependency on a specific CPU architecture, so the driver can be built wherever ARCH_SUNXI is selected. Signed-off-by: Samuel Holland --- drivers/gpu/drm/sun4i/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig index befc5a80222d..3a43c436c74a 100644 --- a/drivers/gpu/drm/sun4i/Kconfig +++ b/drivers/gpu/drm/sun4i/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_SUN4I tristate "DRM Support for Allwinner A10 Display Engine" - depends on DRM && (ARM || ARM64) && COMMON_CLK + depends on DRM && COMMON_CLK depends on ARCH_SUNXI || COMPILE_TEST select DRM_GEM_CMA_HELPER select DRM_KMS_HELPER -- 2.35.1
[PATCH 05/10] drm/sun4i: csc: Add support for the new MMIO layout
D1 changes the MMIO address offset for the CSC blocks in the first
mixer. The ccsc field value is used as an index into the ccsc_base
array; allocate the next available value to represent the new variant.
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/sun4i/sun8i_csc.c | 3 ++-
drivers/gpu/drm/sun4i/sun8i_csc.h | 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.h | 6 --
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
b/drivers/gpu/drm/sun4i/sun8i_csc.c
index 9bd62de0c288..1ed10c6447a3 100644
--- a/drivers/gpu/drm/sun4i/sun8i_csc.c
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
@@ -8,9 +8,10 @@
#include "sun8i_csc.h"
#include "sun8i_mixer.h"
-static const u32 ccsc_base[2][2] = {
+static const u32 ccsc_base[][2] = {
{CCSC00_OFFSET, CCSC01_OFFSET},
{CCSC10_OFFSET, CCSC11_OFFSET},
+ {CCSC00_OFFSET, CCSC01_OFFSET_D1},
};
/*
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.h
b/drivers/gpu/drm/sun4i/sun8i_csc.h
index 022cafa6c06c..bd54166b2bcc 100644
--- a/drivers/gpu/drm/sun4i/sun8i_csc.h
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.h
@@ -13,6 +13,7 @@ struct sun8i_mixer;
/* VI channel CSC units offsets */
#define CCSC00_OFFSET 0xAA050
#define CCSC01_OFFSET 0xFA050
+#define CCSC01_OFFSET_D1 0xFA000
#define CCSC10_OFFSET 0xA
#define CCSC11_OFFSET 0xF
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 5b3fbee18671..22f1b7ef9225 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -151,8 +151,10 @@
* scaler and 2 UI channels with scaler, bitmask would be 0xC.
* @ccsc: select set of CCSC base addresses
* Set value to 0 if this is first mixer or second mixer with VEP support.
- * Set value to 1 if this is second mixer without VEP support. Other values
- * are invalid.
+ * Set value to 1 if this is second mixer without VEP support.
+ * Set value to 2 if this is first mixer or second mixer with VEP support,
+ * and the SoC uses the MMIO layout found in the D1 SoC.
+ * Other values are invalid.
* @mod_rate: module clock rate that needs to be set in order to have
* a functional block.
* @is_de3: true, if this is next gen display engine 3.0, false otherwise.
--
2.35.1
[PATCH 01/10] dt-bindings: display: Separate clock item lists by compatible
So far, the binding and driver have relied on the fact that the H6 clocks are both a prefix and a subset of the R40 clocks. This allows them to share the clocks/clock-names items and the clock-output-names order between the hardware variants. However, the D1 hardware has TCON TV0 and DSI, but no TCON TV1. This cannot be supported by the existing scheme because it puts a gap in the middle of the item lists. To prepare for adding D1 support, use separate lists for variants with different combinations of clocks. Signed-off-by: Samuel Holland --- .../display/allwinner,sun8i-r40-tcon-top.yaml | 111 +++--- 1 file changed, 67 insertions(+), 44 deletions(-) diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml index 61ef7b337218..784b267635fb 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml @@ -48,31 +48,15 @@ properties: clocks: minItems: 2 -items: - - description: The TCON TOP interface clock - - description: The TCON TOP TV0 clock - - description: The TCON TOP TVE0 clock - - description: The TCON TOP TV1 clock - - description: The TCON TOP TVE1 clock - - description: The TCON TOP MIPI DSI clock +maxItems: 6 clock-names: minItems: 2 -items: - - const: bus - - const: tcon-tv0 - - const: tve0 - - const: tcon-tv1 - - const: tve1 - - const: dsi +maxItems: 6 clock-output-names: minItems: 1 maxItems: 3 -description: > - The first item is the name of the clock created for the TV0 - channel, the second item is the name of the TCON TV1 channel - clock and the third one is the name of the DSI channel clock. resets: maxItems: 1 @@ -129,32 +113,71 @@ required: additionalProperties: false -if: - properties: -compatible: - contains: -const: allwinner,sun50i-h6-tcon-top - -then: - properties: -clocks: - maxItems: 2 - -clock-output-names: - maxItems: 1 - -else: - properties: -clocks: - minItems: 6 - -clock-output-names: - minItems: 3 - -ports: - required: -- port@2 -- port@3 +allOf: + - if: + properties: +compatible: + contains: +const: allwinner,sun8i-r40-tcon-top + +then: + properties: +clocks: + minItems: 6 + items: +- description: The TCON TOP interface clock +- description: The TCON TOP TV0 clock +- description: The TCON TOP TVE0 clock +- description: The TCON TOP TV1 clock +- description: The TCON TOP TVE1 clock +- description: The TCON TOP MIPI DSI clock + +clock-names: + minItems: 6 + items: +- const: bus +- const: tcon-tv0 +- const: tve0 +- const: tcon-tv1 +- const: tve1 +- const: dsi + +clock-output-names: + minItems: 3 + items: +- description: TCON TV0 output clock name +- description: TCON TV1 output clock name +- description: DSI output clock name + +ports: + required: +- port@2 +- port@3 + + - if: + properties: +compatible: + contains: +const: allwinner,sun50i-h6-tcon-top + +then: + properties: +clocks: + maxItems: 2 + items: +- description: The TCON TOP interface clock +- description: The TCON TOP TV0 clock + +clock-names: + maxItems: 2 + items: +- const: bus +- const: tcon-tv0 + +clock-output-names: + maxItems: 1 + items: +- description: TCON TV0 output clock name examples: - | -- 2.35.1
[PATCH 02/10] dt-bindings: display: Add D1 display engine compatibles
Allwinner D1 contains a display engine 2.0. It features two mixers, a TCON TOP (with DSI and HDMI), one TCON LCD, and one TCON TV. Signed-off-by: Samuel Holland --- .../allwinner,sun4i-a10-display-engine.yaml | 1 + .../display/allwinner,sun4i-a10-tcon.yaml | 2 ++ .../allwinner,sun8i-a83t-de2-mixer.yaml | 2 ++ .../display/allwinner,sun8i-r40-tcon-top.yaml | 34 +++ 4 files changed, 39 insertions(+) diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml index d4412aea7b73..c388ae5da1e4 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml @@ -62,6 +62,7 @@ properties: - allwinner,sun8i-r40-display-engine - allwinner,sun8i-v3s-display-engine - allwinner,sun9i-a80-display-engine + - allwinner,sun20i-d1-display-engine - allwinner,sun50i-a64-display-engine - allwinner,sun50i-h6-display-engine diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml index 3a7d5d731712..4a92a4c7dcd7 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml @@ -33,6 +33,8 @@ properties: - const: allwinner,sun8i-v3s-tcon - const: allwinner,sun9i-a80-tcon-lcd - const: allwinner,sun9i-a80-tcon-tv + - const: allwinner,sun20i-d1-tcon-lcd + - const: allwinner,sun20i-d1-tcon-tv - items: - enum: diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml index 4f91eec26de9..cb243bc58ef7 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml @@ -19,6 +19,8 @@ properties: - allwinner,sun8i-r40-de2-mixer-0 - allwinner,sun8i-r40-de2-mixer-1 - allwinner,sun8i-v3s-de2-mixer + - allwinner,sun20i-d1-de2-mixer-0 + - allwinner,sun20i-d1-de2-mixer-1 - allwinner,sun50i-a64-de2-mixer-0 - allwinner,sun50i-a64-de2-mixer-1 - allwinner,sun50i-h6-de3-mixer-0 diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml index 784b267635fb..cc32e2faed91 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml @@ -41,6 +41,7 @@ properties: compatible: enum: - allwinner,sun8i-r40-tcon-top + - allwinner,sun20i-d1-tcon-top - allwinner,sun50i-h6-tcon-top reg: @@ -154,6 +155,39 @@ allOf: - port@2 - port@3 + - if: + properties: +compatible: + contains: +const: allwinner,sun20i-d1-tcon-top + +then: + properties: +clocks: + minItems: 4 + maxItems: 4 + items: +- description: The TCON TOP interface clock +- description: The TCON TOP TV0 clock +- description: The TCON TOP TVE0 clock +- description: The TCON TOP MIPI DSI clock + +clock-names: + minItems: 4 + maxItems: 4 + items: +- const: bus +- const: tcon-tv0 +- const: tve0 +- const: dsi + +clock-output-names: + minItems: 2 + maxItems: 2 + items: +- description: TCON TV0 output clock name +- description: DSI output clock name + - if: properties: compatible: -- 2.35.1
Re: [PATCHv2] drm/amdgpu: disable ASPM on Intel AlderLake based systems
On 4/9/2022 12:35 AM, Richard Gong wrote:
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that cannot be
used with Intel AlderLake based systems to enable ASPM. Using these GFX
cards as video/display output, Intel Alder Lake based systems will hang
during suspend/resume.
Add extra check to disable ASPM on Intel AlderLake based systems.
Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
Signed-off-by: Richard Gong
---
v2: correct commit description
move the check from chip family to problematic platform
---
drivers/gpu/drm/amd/amdgpu/vi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 039b90cdc3bc..8b4eaf54b23e 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -81,6 +81,10 @@
#include "mxgpu_vi.h"
#include "amdgpu_dm.h"
+#if IS_ENABLED(CONFIG_X86_64)
+#include
+#endif
+
#define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6
#define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK
0x0001L
#define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK 0x0002L
@@ -1134,13 +1138,24 @@ static void vi_enable_aspm(struct amdgpu_device *adev)
WREG32_PCIE(ixPCIE_LC_CNTL, data);
}
+static bool intel_core_apsm_chk(void)
If this is only for Dell systems, use DMI_SYS_VENDOR/DMI_PRODUCT_NAME to
identify the platform information from SMBIOS.
Better to rename to aspm_support_quirk_check() or similar, and return
false on is_alderlake() or is_dell_xyz();
Thanks,
Lijo
+{
+#if IS_ENABLED(CONFIG_X86_64)
+ struct cpuinfo_x86 *c = _data(0);
+
+ return (c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
+#else
+ return false;
+#endif
+}
+
static void vi_program_aspm(struct amdgpu_device *adev)
{
u32 data, data1, orig;
bool bL1SS = false;
bool bClkReqSupport = true;
- if (!amdgpu_device_should_use_aspm(adev))
+ if (!amdgpu_device_should_use_aspm(adev) || intel_core_apsm_chk())
return;
if (adev->flags & AMD_IS_APU ||
[PATCH v3] drm/hyperv: Added error message for fb size greater than allocated
Added error message when the size of requested framebuffer is more than
the allocated size by vmbus mmio region for framebuffer
Signed-off-by: Saurabh Sengar
---
v2 -> v3 : then -> than (typo fix)
drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
index e82b815..6634818 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
@@ -123,8 +123,11 @@ static int hyperv_pipe_check(struct
drm_simple_display_pipe *pipe,
if (fb->format->format != DRM_FORMAT_XRGB)
return -EINVAL;
- if (fb->pitches[0] * fb->height > hv->fb_size)
+ if (fb->pitches[0] * fb->height > hv->fb_size) {
+ drm_err(>dev, "hv->hdev, fb size requested by process %s
for %d X %d (pitch %d) is greater than allocated size %ld\n",
+ current->comm, fb->width, fb->height, fb->pitches[0],
hv->fb_size);
return -EINVAL;
+ }
return 0;
}
--
1.8.3.1
[V2 1/3] drm/debug: Expose connector's max supported bpc via debugfs
It's useful to know the connector's max supported bpc for IGT
testing. Expose it via a debugfs file on the connector "output_bpc".
Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
V2:
* Fix typo in comments (Harry)
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Harry Wentland
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/drm_debugfs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 7f1b82dbaebb..fb04b7a984de 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -395,6 +395,23 @@ static int vrr_range_show(struct seq_file *m, void *data)
}
DEFINE_SHOW_ATTRIBUTE(vrr_range);
+/*
+ * Returns Connector's max supported bpc through debugfs file.
+ * Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
+ */
+static int output_bpc_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ seq_printf(m, "Maximum: %u\n", connector->display_info.bpc);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(output_bpc);
+
static const struct file_operations drm_edid_fops = {
.owner = THIS_MODULE,
.open = edid_open,
@@ -437,6 +454,10 @@ void drm_debugfs_connector_add(struct drm_connector
*connector)
debugfs_create_file("vrr_range", S_IRUGO, root, connector,
_range_fops);
+ /* max bpc */
+ debugfs_create_file("output_bpc", 0444, root, connector,
+ _bpc_fops);
+
if (connector->funcs->debugfs_init)
connector->funcs->debugfs_init(connector, root);
}
--
2.35.1
Re: [PATCH] dpu1: dpu_encoder: fix a missing check on list iterator
On 11/04/2022 03:56, Dmitry Baryshkov wrote:
On 27/03/2022 10:32, Xiaomeng Tong wrote:
The bug is here:
cstate = to_dpu_crtc_state(drm_crtc->state);
For the drm_for_each_crtc(), just like list_for_each_entry(),
the list iterator 'drm_crtc' will point to a bogus position
containing HEAD if the list is empty or no element is found.
This case must be checked before any use of the iterator,
otherwise it will lead to a invalid memory access.
To fix this bug, use a new variable 'iter' as the list iterator,
while use the origin variable 'drm_crtc' as a dedicated pointer
to point to the found element.
Cc: sta...@vger.kernel.org
Fixes: b107603b4ad0f ("drm/msm/dpu: map mixer/ctl hw blocks in encoder
modeset")
Signed-off-by: Xiaomeng Tong
Reviewed-by: Dmitry Baryshkov
On the other hand, this code has been removed in 5.18-rc1 in the commit
764332bf96244cbc8baf08aa35844b29106da312.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1e648db439f9..d3fdb18e96f9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -965,7 +965,7 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
struct dpu_kms *dpu_kms;
struct list_head *connector_list;
struct drm_connector *conn = NULL, *conn_iter;
- struct drm_crtc *drm_crtc;
+ struct drm_crtc *drm_crtc = NULL, *iter;
struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
@@ -1007,9 +1007,14 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
return;
}
- drm_for_each_crtc(drm_crtc, drm_enc->dev)
- if (drm_crtc->state->encoder_mask & drm_encoder_mask(drm_enc))
+ drm_for_each_crtc(iter, drm_enc->dev)
+ if (iter->state->encoder_mask & drm_encoder_mask(drm_enc)) {
+ drm_crtc = iter;
break;
+ }
+
+ if (!drm_crtc)
+ return;
/* Query resource that have been reserved in atomic check step. */
num_pp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
--
With best wishes
Dmitry
Re: [PATCH] dpu1: dpu_encoder: fix a missing check on list iterator
On 27/03/2022 10:32, Xiaomeng Tong wrote:
The bug is here:
cstate = to_dpu_crtc_state(drm_crtc->state);
For the drm_for_each_crtc(), just like list_for_each_entry(),
the list iterator 'drm_crtc' will point to a bogus position
containing HEAD if the list is empty or no element is found.
This case must be checked before any use of the iterator,
otherwise it will lead to a invalid memory access.
To fix this bug, use a new variable 'iter' as the list iterator,
while use the origin variable 'drm_crtc' as a dedicated pointer
to point to the found element.
Cc: sta...@vger.kernel.org
Fixes: b107603b4ad0f ("drm/msm/dpu: map mixer/ctl hw blocks in encoder modeset")
Signed-off-by: Xiaomeng Tong
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1e648db439f9..d3fdb18e96f9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -965,7 +965,7 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
struct dpu_kms *dpu_kms;
struct list_head *connector_list;
struct drm_connector *conn = NULL, *conn_iter;
- struct drm_crtc *drm_crtc;
+ struct drm_crtc *drm_crtc = NULL, *iter;
struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
@@ -1007,9 +1007,14 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
return;
}
- drm_for_each_crtc(drm_crtc, drm_enc->dev)
- if (drm_crtc->state->encoder_mask & drm_encoder_mask(drm_enc))
+ drm_for_each_crtc(iter, drm_enc->dev)
+ if (iter->state->encoder_mask & drm_encoder_mask(drm_enc)) {
+ drm_crtc = iter;
break;
+ }
+
+ if (!drm_crtc)
+ return;
/* Query resource that have been reserved in atomic check step. */
num_pp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
--
With best wishes
Dmitry
Re: [PATCH] drm/msm/dsi: Use connector directly in msm_dsi_manager_connector_init()
On 18/03/2022 03:07, Stephen Boyd wrote:
The member 'msm_dsi->connector' isn't assigned until
msm_dsi_manager_connector_init() returns (see msm_dsi_modeset_init() and
how it assigns the return value). Therefore this pointer is going to be
NULL here. Let's use 'connector' which is what was intended.
Cc: Dmitry Baryshkov
Cc: Sean Paul
Fixes: 6d5e78406991 ("drm/msm/dsi: Move dsi panel init into modeset init path")
Signed-off-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH] drm/msm/gpu: Avoid -Wunused-function with !CONFIG_PM_SLEEP
On 30/03/2022 21:05, Nathan Chancellor wrote:
When building with CONFIG_PM=y and CONFIG_PM_SLEEP=n (such as ARCH=riscv
allmodconfig), the following warnings/errors occur:
drivers/gpu/drm/msm/adreno/adreno_device.c:679:12: error:
'adreno_system_resume' defined but not used [-Werror=unused-function]
679 | static int adreno_system_resume(struct device *dev)
|^~~~
drivers/gpu/drm/msm/adreno/adreno_device.c:655:12: error:
'adreno_system_suspend' defined but not used [-Werror=unused-function]
655 | static int adreno_system_suspend(struct device *dev)
|^
cc1: all warnings being treated as errors
These functions are only used in SET_SYSTEM_SLEEP_PM_OPS(), which
evaluates to empty when CONFIG_PM_SLEEP is not set, making these
functions unused.
Traditionally, these functions are marked as __maybe_unused but in this
case, there is already an '#ifdef CONFIG_PM' in the code, so just do the
same thing with CONFIG_PM_SLEEP to resolve the warning.
Fixes: 7e4167c9e021 ("drm/msm/gpu: Park scheduler threads for system suspend")
Signed-off-by: Nathan Chancellor
I'd suggest using __maybe_unused instead (and maybe even sending the
followup patch changing the #ifdef CONFIG_PM to __maybe_unused too):
If the code is included into the compilation, it means it's more widely
compile tested. Which tends to reveal obscure bugs, dependencies, etc.
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 661dfa7681fb..b25915230bab 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -621,6 +621,7 @@ static int adreno_runtime_suspend(struct device *dev)
return gpu->funcs->pm_suspend(gpu);
}
+#ifdef CONFIG_PM_SLEEP
static void suspend_scheduler(struct msm_gpu *gpu)
{
int i;
@@ -681,8 +682,8 @@ static int adreno_system_resume(struct device *dev)
resume_scheduler(dev_to_gpu(dev));
return pm_runtime_force_resume(dev);
}
-
-#endif
+#endif /* CONFIG_PM_SLEEP */
+#endif /* CONFIG_PM */
static const struct dev_pm_ops adreno_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(adreno_system_suspend, adreno_system_resume)
base-commit: 05241de1f69eb7f56b0a5e0bec96a7752fad1b2f
--
With best wishes
Dmitry
[PATCH 2/2] drm/panel: lvds: Drop now redundant width-mm and height-mm check
The check for mandatory DT properties width-mm and height-mm is now
part of of_get_drm_panel_display_mode(), drop the redundant check
from this driver.
Signed-off-by: Marek Vasut
Cc: Christoph Niedermaier
Cc: Daniel Vetter
Cc: Dmitry Osipenko
Cc: Laurent Pinchart
Cc: Noralf Trønnes
Cc: Rob Herring
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-lvds.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm/panel/panel-lvds.c
index eca067e785796..f11252fb00fea 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -128,18 +128,6 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
return ret;
}
- if (lvds->dmode.width_mm == 0) {
- dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
- np, "width-mm");
- return -ENODEV;
- }
-
- if (lvds->dmode.height_mm == 0) {
- dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
- np, "height-mm");
- return -ENODEV;
- }
-
of_property_read_string(np, "label", >label);
ret = drm_of_lvds_get_data_mapping(np);
--
2.35.1
[PATCH 1/2] drm/modes: Make width-mm/height-mm check in of_get_drm_panel_display_mode() mandatory
All users of this function require width-mm/height-mm DT property to be present per their DT bindings, make width-mm/height-mm check mandatory. It is generally a good idea to specify panel dimensions, so userspace can configure e.g. scaling accordingly. Signed-off-by: Marek Vasut Cc: Christoph Niedermaier Cc: Daniel Vetter Cc: Dmitry Osipenko Cc: Laurent Pinchart Cc: Noralf Trønnes Cc: Rob Herring Cc: Robert Foss Cc: Sam Ravnborg Cc: Thomas Zimmermann To: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/drm_modes.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 6e7e10f16ec03..f0b000ddaddb5 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -735,8 +735,8 @@ EXPORT_SYMBOL_GPL(of_get_drm_display_mode); * @dmode: will be set to the return value * @bus_flags: information about pixelclk, sync and DE polarity * - * The Device Tree properties width-mm and height-mm will be read and set on - * the display mode if they are present. + * The mandatory Device Tree properties width-mm and height-mm + * are read and set on the display mode. * * Returns: * Zero on success, negative error code on failure. @@ -761,11 +761,11 @@ int of_get_drm_panel_display_mode(struct device_node *np, drm_bus_flags_from_videomode(, bus_flags); ret = of_property_read_u32(np, "width-mm", _mm); - if (ret && ret != -EINVAL) + if (ret) return ret; ret = of_property_read_u32(np, "height-mm", _mm); - if (ret && ret != -EINVAL) + if (ret) return ret; dmode->width_mm = width_mm; -- 2.35.1
Re: [PATCHv2] drm/amdgpu: disable ASPM on Intel AlderLake based systems
On 4/8/2022 7:19 PM, Paul Menzel wrote:
Dear Richard,
Thank you for your patch.
Am 08.04.22 um 21:05 schrieb Richard Gong:
Active State Power Management (ASPM) feature is enabled since kernel
5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that cannot be
used with Intel AlderLake based systems to enable ASPM. Using these GFX
Alder Lake
Actually there are 2 formats (one with space, another is w/o space) in
the upstream sources, so I will keep that unchanged and use the format
w/o space.
cards as video/display output, Intel Alder Lake based systems will hang
during suspend/resume.
Please reflow for 75 characters per line.
Also please mention the exact system you had problems with (also
firmware versions).
Add extra check to disable ASPM on Intel AlderLake based systems.
Is that a problem with Intel Alder Lake or the Dell system? Shouldn’t
ASPM just be disabled for the problematic cards for the Dell system.
You write newer cards worked fine.
Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1885data=04%7C01%7Crichard.gong%40amd.com%7C6b94ff2249244c04974e08da19bea71b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637850604066094079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2FiF%2Bnwzm5RlClT%2Fv%2B0RJvmVwsc%2FiwV3jCiFq7PB84wM%3Dreserved=0
Signed-off-by: Richard Gong
---
v2: correct commit description
move the check from chip family to problematic platform
---
drivers/gpu/drm/amd/amdgpu/vi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
b/drivers/gpu/drm/amd/amdgpu/vi.c
index 039b90cdc3bc..8b4eaf54b23e 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -81,6 +81,10 @@
#include "mxgpu_vi.h"
#include "amdgpu_dm.h"
+#if IS_ENABLED(CONFIG_X86_64)
+#include
+#endif
+
#define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6
#define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK
0x0001L
#define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK
0x0002L
@@ -1134,13 +1138,24 @@ static void vi_enable_aspm(struct
amdgpu_device *adev)
WREG32_PCIE(ixPCIE_LC_CNTL, data);
}
+static bool intel_core_apsm_chk(void)
aspm
+{
+#if IS_ENABLED(CONFIG_X86_64)
+ struct cpuinfo_x86 *c = _data(0);
+
+ return (c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
+#else
+ return false;
+#endif
Please do the check in C code and not the preprocessor.
+}
+
static void vi_program_aspm(struct amdgpu_device *adev)
{
u32 data, data1, orig;
bool bL1SS = false;
bool bClkReqSupport = true;
- if (!amdgpu_device_should_use_aspm(adev))
+ if (!amdgpu_device_should_use_aspm(adev) || intel_core_apsm_chk())
return;
if (adev->flags & AMD_IS_APU ||
Kind regards,
Paul
Re: [PATCHv2] drm/amdgpu: disable ASPM on Intel AlderLake based systems
Hi Nils,
On 4/10/2022 8:54 AM, Nils Wallménius wrote:
Hi Richard, see inline comment.
Den fre 8 apr. 2022 21:05Richard Gong skrev:
Active State Power Management (ASPM) feature is enabled since
kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that cannot be
used with Intel AlderLake based systems to enable ASPM. Using
these GFX
cards as video/display output, Intel Alder Lake based systems will
hang
during suspend/resume.
Add extra check to disable ASPM on Intel AlderLake based systems.
Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
Signed-off-by: Richard Gong
---
v2: correct commit description
move the check from chip family to problematic platform
---
drivers/gpu/drm/amd/amdgpu/vi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
b/drivers/gpu/drm/amd/amdgpu/vi.c
index 039b90cdc3bc..8b4eaf54b23e 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -81,6 +81,10 @@
#include "mxgpu_vi.h"
#include "amdgpu_dm.h"
+#if IS_ENABLED(CONFIG_X86_64)
+#include
+#endif
+
#define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6
#define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK
0x0001L
#define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK
0x0002L
@@ -1134,13 +1138,24 @@ static void vi_enable_aspm(struct
amdgpu_device *adev)
WREG32_PCIE(ixPCIE_LC_CNTL, data);
}
There's a typo in the new function name apsm/aspm. Btw might be worth
a comment why this check is done?
Thanks for review,
s/intel_core_apsm_chk/intel_core_aspm_chk in the next view.
Regards,
Richard
Regards
Nils
+static bool intel_core_apsm_chk(void)
+{
+#if IS_ENABLED(CONFIG_X86_64)
+ struct cpuinfo_x86 *c = _data(0);
+
+ return (c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
+#else
+ return false;
+#endif
+}
+
static void vi_program_aspm(struct amdgpu_device *adev)
{
u32 data, data1, orig;
bool bL1SS = false;
bool bClkReqSupport = true;
- if (!amdgpu_device_should_use_aspm(adev))
+ if (!amdgpu_device_should_use_aspm(adev) ||
intel_core_apsm_chk())
return;
if (adev->flags & AMD_IS_APU ||
--
2.25.1
Re: [PATCHv2] drm/amdgpu: disable ASPM on Intel AlderLake based systems
Hi Pail.
On 4/8/2022 7:19 PM, Paul Menzel wrote:
Dear Richard,
Thank you for your patch.
Am 08.04.22 um 21:05 schrieb Richard Gong:
Active State Power Management (ASPM) feature is enabled since kernel
5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that cannot be
used with Intel AlderLake based systems to enable ASPM. Using these GFX
Alder Lake
will correct in the next version.
cards as video/display output, Intel Alder Lake based systems will hang
during suspend/resume.
Please reflow for 75 characters per line.
Also please mention the exact system you had problems with (also
firmware versions).
Add extra check to disable ASPM on Intel AlderLake based systems.
Is that a problem with Intel Alder Lake or the Dell system? Shouldn’t
ASPM just be disabled for the problematic cards for the Dell system.
You write newer cards worked fine.
There is a problem with Dell system (Dell Precision DT workstation),
which is based on Intel Alder Lake.
ASPM works just fine on these GPU's. It's more of an issue with whether
the underlying platform supports ASPM or not.
Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1885data=04%7C01%7Crichard.gong%40amd.com%7C6b94ff2249244c04974e08da19bea71b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637850604066094079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2FiF%2Bnwzm5RlClT%2Fv%2B0RJvmVwsc%2FiwV3jCiFq7PB84wM%3Dreserved=0
Signed-off-by: Richard Gong
---
v2: correct commit description
move the check from chip family to problematic platform
---
drivers/gpu/drm/amd/amdgpu/vi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
b/drivers/gpu/drm/amd/amdgpu/vi.c
index 039b90cdc3bc..8b4eaf54b23e 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -81,6 +81,10 @@
#include "mxgpu_vi.h"
#include "amdgpu_dm.h"
+#if IS_ENABLED(CONFIG_X86_64)
+#include
+#endif
+
#define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6
#define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK
0x0001L
#define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK
0x0002L
@@ -1134,13 +1138,24 @@ static void vi_enable_aspm(struct
amdgpu_device *adev)
WREG32_PCIE(ixPCIE_LC_CNTL, data);
}
+static bool intel_core_apsm_chk(void)
aspm
s/apsm/aspm in the next version
+{
+#if IS_ENABLED(CONFIG_X86_64)
+ struct cpuinfo_x86 *c = _data(0);
+
+ return (c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
+#else
+ return false;
+#endif
Please do the check in C code and not the preprocessor.
followed the pattern with other upsteram drivers.
+}
+
static void vi_program_aspm(struct amdgpu_device *adev)
{
u32 data, data1, orig;
bool bL1SS = false;
bool bClkReqSupport = true;
- if (!amdgpu_device_should_use_aspm(adev))
+ if (!amdgpu_device_should_use_aspm(adev) || intel_core_apsm_chk())
return;
if (adev->flags & AMD_IS_APU ||
Kind regards,
Paul
Regards,
Richard
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 barn...@gmx.net changed: What|Removed |Added CC||barn...@gmx.net --- Comment #25 from barn...@gmx.net --- I have observed this as well on a 5.15.32 kernel. The system is equipped with an AMD Threadripper 3970X and 2 x LG HDMI displays connected via DP (4K@60Hz). The error happens when powering-up the monitors after a long power-down period. >[122427.564568] amdgpu :03:00.0: [drm] Cannot find any crtc or sizes >[122427.603599] amdgpu :03:00.0: [drm] Cannot find any crtc or sizes >[122427.954560] [drm] fb mappable at 0xC0E0 >[122427.954563] [drm] vram apper at 0xC000 >[122427.954563] [drm] size 33177600 >[122427.954564] [drm] fb depth is 24 >[122427.954564] [drm]pitch is 15360 >[122427.954625] fbcon: amdgpudrmfb (fb0) is primary device >[122427.954759] Console: switching to colour frame buffer device 480x135 >[122427.954763] amdgpu :03:00.0: [drm] fb0: amdgpudrmfb frame buffer >device >[122482.729791] [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for >>more than 20secs aborting >[122482.729839] [drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* >atombios stuck executing C220 (len 62, WS 0, PS 0) @ 0xC23C Ctrl-Alt-F1 and restarting X (i.e., the login manager) is sufficient to bring the system back into a useable state. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2 4/7] drm: mxsfb: Move mxsfb_get_fb_paddr() away from register IO functions
On 4/7/22 11:47, Lucas Stach wrote: Am Donnerstag, dem 07.04.2022 um 00:05 +0200 schrieb Marek Vasut: On 4/6/22 21:45, Lucas Stach wrote: Am Freitag, dem 11.03.2022 um 18:05 +0100 schrieb Marek Vasut: Move mxsfb_get_fb_paddr() out of the way, away from register IO functions. This is a clean up. No functional change. Signed-off-by: Marek Vasut Cc: Alexander Stein Cc: Laurent Pinchart Cc: Lucas Stach Cc: Peng Fan Cc: Robby Cai Cc: Sam Ravnborg Cc: Stefan Agner Hm, I don't see any real benefit, but I also fail to see why it shouldn't be done so: The entire point of this series is to clean up the mxsfb and isolate lcdif (the original lcdif) from any of the common code. Actually, just use drm_fb_cma_get_gem_addr() instead? That function seems to add only extra code that is executed, but does not do away with the !fb check anyway. So, why ? (Also, seems unrelated to this patch)
[PATCH] fbdev: i740fb: use memset_io() to clear screen
sparse complains that using memset() on __iomem pointer is wrong: incorrect type in argument 1 (different address spaces) Use memset_io() to clear screen instead. Tested on real i740 cards. Signed-off-by: Ondrej Zary --- drivers/video/fbdev/i740fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/i740fb.c b/drivers/video/fbdev/i740fb.c index 52cce0db8bd3..dd45ea8203be 100644 --- a/drivers/video/fbdev/i740fb.c +++ b/drivers/video/fbdev/i740fb.c @@ -740,7 +740,7 @@ static int i740fb_set_par(struct fb_info *info) if (i) return i; - memset(info->screen_base, 0, info->screen_size); + memset_io(info->screen_base, 0, info->screen_size); vga_protect(par); -- Ondrej Zary
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson wrote: > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard > wrote: > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > > wrote: > > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > > wrote: > > > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > > > This appears to be needed for video output to function correctly. > > > > > > > > Signed-off-by: James Hilliard > > > > > > Hi James, > > > EFI_FB is its own driver and not needed by gma500 to drive its > > > hardware. What makes you think it's required? > > > > I wasn't getting any HDMI video output without it enabled for some reason, > > I assume it is doing some sort of initialization needed by gma500 > > during startup. > > Then it sounds like you might just be using EFI_FB and not gma500. Can > you provide the kernel log with drm.debug=0x1f set on kernel > command-line. Seems efifb loads first and then hands off to gma500 [0.00] Linux version 5.17.1 (buildroot@james-x399) (x86_64-buildroot-linux-gnu-gcc.br_real (Buildroot 2022.02-439-ge14798fa29) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Thu Apr 7 00:14:30 MDT 2022 [0.00] Command line: root=PARTUUID=9bc7b8cb-3b3a-994c-9dca-0abbc5055e4d rootwait drm.debug=0x1f console=tty1 [0.00] Disabled fast string operations [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] signal: max sigframe size: 1440 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x000a-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcf32cfff] usable [0.00] BIOS-e820: [mem 0xcf32d000-0xcf374fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf375000-0xcf385fff] reserved [0.00] BIOS-e820: [mem 0xcf386000-0xcf38dfff] ACPI data [0.00] BIOS-e820: [mem 0xcf38e000-0xcf3b5fff] reserved [0.00] BIOS-e820: [mem 0xcf3b6000-0xcf3b6fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf3b7000-0xcf3c6fff] reserved [0.00] BIOS-e820: [mem 0xcf3c7000-0xcf3d2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf3d3000-0xcf3f7fff] reserved [0.00] BIOS-e820: [mem 0xcf3f8000-0xcf43afff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf43b000-0xcf5bafff] usable [0.00] BIOS-e820: [mem 0xcf5bb000-0xcf6e6fff] reserved [0.00] BIOS-e820: [mem 0xcf6e7000-0xcf6e] usable [0.00] BIOS-e820: [mem 0xcf6f-0xcfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffe0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00012fff] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0x021da018-0x021ea057] usable ==> usable [0.00] e820: update [mem 0x021da018-0x021ea057] usable ==> usable [0.00] e820: update [mem 0x020d9018-0x020e5857] usable ==> usable [0.00] e820: update [mem 0x020d9018-0x020e5857] usable ==> usable [0.00] e820: update [mem 0x02237018-0x02243857] usable ==> usable [0.00] e820: update [mem 0x02237018-0x02243857] usable ==> usable [0.00] e820: update [mem 0x02215018-0x0221d057] usable ==> usable [0.00] e820: update [mem 0x02215018-0x0221d057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0009] usable [0.00] reserve setup_data: [mem 0x000a-0x000f] reserved [0.00] reserve setup_data: [mem 0x0010-0x020d9017] usable [0.00] reserve setup_data: [mem 0x020d9018-0x020e5857] usable [0.00] reserve setup_data: [mem 0x020e5858-0x021da017] usable [0.00] reserve setup_data: [mem 0x021da018-0x021ea057] usable [0.00] reserve setup_data: [mem 0x021ea058-0x02215017] usable [0.00] reserve setup_data: [mem 0x02215018-0x0221d057] usable [0.00] reserve setup_data: [mem 0x0221d058-0x02237017] usable [0.00] reserve setup_data: [mem 0x02237018-0x02243857] usable [0.00] reserve setup_data: [mem
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sun, Apr 10, 2022 at 9:40 PM James Hilliard wrote: > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > wrote: > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > wrote: > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > This appears to be needed for video output to function correctly. > > > > > > Signed-off-by: James Hilliard > > > > Hi James, > > EFI_FB is its own driver and not needed by gma500 to drive its > > hardware. What makes you think it's required? > > I wasn't getting any HDMI video output without it enabled for some reason, > I assume it is doing some sort of initialization needed by gma500 > during startup. Then it sounds like you might just be using EFI_FB and not gma500. Can you provide the kernel log with drm.debug=0x1f set on kernel command-line. What machine is this? I've seen very few gma500 devices with UEFI. > > > > > -Patrik > > > > > --- > > > Changes v2 -> v3: > > > - select EFI_FB instead of depending on it > > > Changes v1 -> v2: > > > - use depends instead of select > > > --- > > > drivers/gpu/drm/gma500/Kconfig | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/gma500/Kconfig > > > b/drivers/gpu/drm/gma500/Kconfig > > > index 0cff20265f97..a422fa84d53b 100644 > > > --- a/drivers/gpu/drm/gma500/Kconfig > > > +++ b/drivers/gpu/drm/gma500/Kconfig > > > @@ -2,11 +2,13 @@ > > > config DRM_GMA500 > > > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > > > depends on DRM && PCI && X86 && MMU > > > + depends on FB > > > select DRM_KMS_HELPER > > > # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like > > > i915 > > > select ACPI_VIDEO if ACPI > > > select BACKLIGHT_CLASS_DEVICE if ACPI > > > select INPUT if ACPI > > > + select FB_EFI if EFI > > > help > > > Say yes for an experimental 2D KMS framebuffer driver for the > > > Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and > > > -- > > > 2.25.1 > > >
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson wrote: > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > wrote: > > > > Select the efi framebuffer if efi is enabled. > > > > This appears to be needed for video output to function correctly. > > > > Signed-off-by: James Hilliard > > Hi James, > EFI_FB is its own driver and not needed by gma500 to drive its > hardware. What makes you think it's required? I wasn't getting any HDMI video output without it enabled for some reason, I assume it is doing some sort of initialization needed by gma500 during startup. > > -Patrik > > > --- > > Changes v2 -> v3: > > - select EFI_FB instead of depending on it > > Changes v1 -> v2: > > - use depends instead of select > > --- > > drivers/gpu/drm/gma500/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig > > index 0cff20265f97..a422fa84d53b 100644 > > --- a/drivers/gpu/drm/gma500/Kconfig > > +++ b/drivers/gpu/drm/gma500/Kconfig > > @@ -2,11 +2,13 @@ > > config DRM_GMA500 > > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > > depends on DRM && PCI && X86 && MMU > > + depends on FB > > select DRM_KMS_HELPER > > # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 > > select ACPI_VIDEO if ACPI > > select BACKLIGHT_CLASS_DEVICE if ACPI > > select INPUT if ACPI > > + select FB_EFI if EFI > > help > > Say yes for an experimental 2D KMS framebuffer driver for the > > Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and > > -- > > 2.25.1 > >
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sat, Apr 9, 2022 at 6:23 AM James Hilliard wrote: > > Select the efi framebuffer if efi is enabled. > > This appears to be needed for video output to function correctly. > > Signed-off-by: James Hilliard Hi James, EFI_FB is its own driver and not needed by gma500 to drive its hardware. What makes you think it's required? -Patrik > --- > Changes v2 -> v3: > - select EFI_FB instead of depending on it > Changes v1 -> v2: > - use depends instead of select > --- > drivers/gpu/drm/gma500/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig > index 0cff20265f97..a422fa84d53b 100644 > --- a/drivers/gpu/drm/gma500/Kconfig > +++ b/drivers/gpu/drm/gma500/Kconfig > @@ -2,11 +2,13 @@ > config DRM_GMA500 > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > depends on DRM && PCI && X86 && MMU > + depends on FB > select DRM_KMS_HELPER > # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 > select ACPI_VIDEO if ACPI > select BACKLIGHT_CLASS_DEVICE if ACPI > select INPUT if ACPI > + select FB_EFI if EFI > help > Say yes for an experimental 2D KMS framebuffer driver for the > Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and > -- > 2.25.1 >
Re: [PATCH 10/11] dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support
Hi Jagan, Thank you for the patch. On Fri, Apr 08, 2022 at 09:51:07PM +0530, Jagan Teki wrote: > Samsung MIPI DSIM bridge can also be found in i.MX8MM/i.MX8MN SoC. > > Add dt-bingings for it. > > v1: > * new patch > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt > b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt > index be377786e8cd..5133d4d39190 100644 > --- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt > +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt > @@ -7,6 +7,7 @@ Required properties: May I try and ask you to convert the DT bindings to YAML as part of this series ? :-) > "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs > */ > "samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */ > "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */ > + "fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */ Should we have two different compatible strings for i.MX8MM and i.MX8MN ? >- reg: physical base address and length of the registers set for the device >- interrupts: should contain DSI interrupt >- clocks: list of clock specifiers, must contain an entry for each required -- Regards, Laurent Pinchart
Re: [PATCH 11/11] drm: bridge: samsung-dsim: Add i.MX8MM support
Hi Jagan,
Thank you for the patch.
On Fri, Apr 08, 2022 at 09:51:08PM +0530, Jagan Teki wrote:
> Samsung MIPI DSIM master can also be found in i.MX8MM SoC.
>
> Add compatible and associated driver_data for it.
>
> v1:
> * none
>
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 34 +++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 71bbaf19f530..d91510a51981 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -360,6 +360,24 @@ static const unsigned int exynos5433_reg_values[] = {
> [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
> };
>
> +static const unsigned int imx8mm_dsim_reg_values[] = {
> + [RESET_TYPE] = DSIM_SWRST,
> + [PLL_TIMER] = 500,
> + [STOP_STATE_CNT] = 0xf,
> + [PHYCTRL_ULPS_EXIT] = 0,
> + [PHYCTRL_VREG_LP] = 0,
> + [PHYCTRL_SLEW_UP] = 0,
> + [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
> + [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
> + [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
> + [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x26),
> + [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
> + [PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
> + [PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x08),
> + [PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
> + [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
> +};
Most of these values don't seem to be specific to a particular SoC
integration, but should be tuned for the board and the connected DSI
sink. That's out of scope for this patch of course.
> +
> static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
> .reg_ofs = exynos_reg_ofs,
> .plltmr_reg = 0x50,
> @@ -426,6 +444,18 @@ static const struct samsung_dsim_driver_data
> exynos5422_dsi_driver_data = {
> .platform_init = true,
> };
>
> +static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
> + .reg_ofs = exynos5433_reg_ofs,
> + .plltmr_reg = 0xa0,
> + .has_clklane_stop = 1,
> + .num_clks = 2,
> + .max_freq = 2100,
> + .wait_for_reset = 0,
> + .num_bits_resol = 12,
> + .pll_p_offset = 14,
> + .reg_values = imx8mm_dsim_reg_values,
> +};
I haven't verified the values, the rest looks good to me.
Reviewed-by: Laurent Pinchart
> +
> static const struct of_device_id samsung_dsim_of_match[] = {
> {
> .compatible = "samsung,exynos3250-mipi-dsi",
> @@ -447,6 +477,10 @@ static const struct of_device_id samsung_dsim_of_match[]
> = {
> .compatible = "samsung,exynos5433-mipi-dsi",
> .data = _dsi_driver_data
> },
> + {
> + .compatible = "fsl,imx8mm-mipi-dsim",
> + .data = _dsi_driver_data
> + },
> { /* sentinel. */ }
> };
>
--
Regards,
Laurent Pinchart
Re: [PATCH] drm: rcar-du: Extend CMM HDSE documentation
Hi Kieran, Thank you for the patch. On Sat, Apr 09, 2022 at 07:57:06PM +0100, Kieran Bingham wrote: > When the CMM is enabled, the HDSE offset is further adjusted to > compensate for consumed pixels. > > Explain this further, with an extra comment at the point the offset is > adjusted. > > Suggested-by: Laurent Pinchart > Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > index f361a604337f..23e1aedf8dc0 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > @@ -300,6 +300,11 @@ static void rcar_du_crtc_set_display_timing(struct > rcar_du_crtc *rcrtc) >| DSMR_DIPM_DISP | DSMR_CSPM; > rcar_du_crtc_write(rcrtc, DSMR, dsmr); > > + /* > + * When the CMM is enabled, an additional offset of 25 pixels must be > + * subtracted from the HDS (horizontal display start) and HDE > + * (horizontal display end) registers. > + */ > hdse_offset = 19; > if (rcrtc->group->cmms_mask & BIT(rcrtc->index % 2)) > hdse_offset += 25; -- Regards, Laurent Pinchart
Re: [PATCHv2] drm/amdgpu: disable ASPM on Intel AlderLake based systems
Hi Richard, see inline comment.
Den fre 8 apr. 2022 21:05Richard Gong skrev:
> Active State Power Management (ASPM) feature is enabled since kernel 5.14.
> There are some AMD GFX cards (such as WX3200 and RX640) that cannot be
> used with Intel AlderLake based systems to enable ASPM. Using these GFX
> cards as video/display output, Intel Alder Lake based systems will hang
> during suspend/resume.
>
> Add extra check to disable ASPM on Intel AlderLake based systems.
>
> Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
> Signed-off-by: Richard Gong
> ---
> v2: correct commit description
> move the check from chip family to problematic platform
> ---
> drivers/gpu/drm/amd/amdgpu/vi.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 039b90cdc3bc..8b4eaf54b23e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -81,6 +81,10 @@
> #include "mxgpu_vi.h"
> #include "amdgpu_dm.h"
>
> +#if IS_ENABLED(CONFIG_X86_64)
> +#include
> +#endif
> +
> #define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6
> #define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK
> 0x0001L
> #define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK 0x0002L
> @@ -1134,13 +1138,24 @@ static void vi_enable_aspm(struct amdgpu_device
> *adev)
> WREG32_PCIE(ixPCIE_LC_CNTL, data);
> }
>
There's a typo in the new function name apsm/aspm. Btw might be worth a
comment why this check is done?
Regards
Nils
> +static bool intel_core_apsm_chk(void)
> +{
> +#if IS_ENABLED(CONFIG_X86_64)
> + struct cpuinfo_x86 *c = _data(0);
> +
> + return (c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
> +#else
> + return false;
> +#endif
> +}
> +
> static void vi_program_aspm(struct amdgpu_device *adev)
> {
> u32 data, data1, orig;
> bool bL1SS = false;
> bool bClkReqSupport = true;
>
> - if (!amdgpu_device_should_use_aspm(adev))
> + if (!amdgpu_device_should_use_aspm(adev) || intel_core_apsm_chk())
> return;
>
> if (adev->flags & AMD_IS_APU ||
> --
> 2.25.1
>
>
Re: [PATCH v10 12/24] drm/rockchip: dw_hdmi: drop mode_valid hook
Am 08.04.22 um 13:22 schrieb Sascha Hauer:
> The driver checks if the pixel clock of the given mode matches an entry
> in the mpll config table. The frequencies in the mpll table are meant as
> a frequency range up to which the entry works, not as a frequency that
> must match the pixel clock. The downstream Kernel also does not have
> this check, so drop it to allow for more display resolutions.
>
> Signed-off-by: Sascha Hauer
> ---
>
You're correct: That frequency is meant to be greater or equal. But I'm
not sure if it makes sense to completely drop it - what happens for
clocks rates > 600 MHz which might be supported by later generation
sinks (HDMI 2.1 or later)?
As these are not supported by the IPs/PHYs currently supported by that
driver a reason a simple
int i;
for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
- if (pclk == mpll_cfg[i].mpixelclock) {
+ if (pclk >= mpll_cfg[i].mpixelclock) {
valid = true;
break;
}
would be the better idea, I guess.
Regards,
Alex
> Notes:
> Changes since v3:
> - new patch
>
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 25 -
> 1 file changed, 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index cb43e7b47157d..008ab20f39ee6 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -248,26 +248,6 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
> *hdmi)
> return 0;
> }
>
> -static enum drm_mode_status
> -dw_hdmi_rockchip_mode_valid(struct dw_hdmi *hdmi, void *data,
> - const struct drm_display_info *info,
> - const struct drm_display_mode *mode)
> -{
> - const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
> - int pclk = mode->clock * 1000;
> - bool valid = false;
> - int i;
> -
> - for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
> - if (pclk == mpll_cfg[i].mpixelclock) {
> - valid = true;
> - break;
> - }
> - }
> -
> - return (valid) ? MODE_OK : MODE_BAD;
> -}
> -
> static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
> {
> }
> @@ -433,7 +413,6 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
> };
>
> static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
> - .mode_valid = dw_hdmi_rockchip_mode_valid,
> .mpll_cfg = rockchip_mpll_cfg,
> .cur_ctr = rockchip_cur_ctr,
> .phy_config = rockchip_phy_config,
> @@ -450,7 +429,6 @@ static struct rockchip_hdmi_chip_data rk3288_chip_data = {
> };
>
> static const struct dw_hdmi_plat_data rk3288_hdmi_drv_data = {
> - .mode_valid = dw_hdmi_rockchip_mode_valid,
> .mpll_cfg = rockchip_mpll_cfg,
> .cur_ctr= rockchip_cur_ctr,
> .phy_config = rockchip_phy_config,
> @@ -470,7 +448,6 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
> };
>
> static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
> - .mode_valid = dw_hdmi_rockchip_mode_valid,
> .mpll_cfg = rockchip_mpll_cfg,
> .cur_ctr = rockchip_cur_ctr,
> .phy_config = rockchip_phy_config,
> @@ -488,7 +465,6 @@ static struct rockchip_hdmi_chip_data rk3399_chip_data = {
> };
>
> static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data = {
> - .mode_valid = dw_hdmi_rockchip_mode_valid,
> .mpll_cfg = rockchip_mpll_cfg,
> .cur_ctr= rockchip_cur_ctr,
> .phy_config = rockchip_phy_config,
> @@ -501,7 +477,6 @@ static struct rockchip_hdmi_chip_data rk3568_chip_data = {
> };
>
> static const struct dw_hdmi_plat_data rk3568_hdmi_drv_data = {
> - .mode_valid = dw_hdmi_rockchip_mode_valid,
> .mpll_cfg = rockchip_mpll_cfg,
> .cur_ctr= rockchip_cur_ctr,
> .phy_config = rockchip_phy_config,
Re: [PATCH 1/1] drm/vc4: hdmi: Replace drm_detect_hdmi_monitor() with is_hdmi
Hi Maxime,
Thanks for your comments.
On Fri, Apr 08, 2022 at 09:41:10AM +0200, Maxime Ripard wrote:
> Hi Jose,
>
> On Wed, Apr 06, 2022 at 06:55:14PM +0200, José Expósito wrote:
> > Once EDID is parsed, the monitor HDMI support information is cached in
> > drm_display_info.is_hdmi by drm_parse_hdmi_vsdb_video().
> >
> > This driver calls drm_detect_hdmi_monitor() to receive the same
> > information and stores its own cached value, which is less efficient.
> >
> > Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi
> > instead.
> >
> > drm_detect_hdmi_monitor() is called in vc4_hdmi_connector_detect() and
> > vc4_hdmi_connector_get_modes(). In both cases it is safe to rely on
> > drm_display_info.is_hdmi as shown by ftrace:
>
> How do you use ftrace to generate that?
I had to add noinline to a couple of relevant functions and run the
usual:
$ sudo trace-cmd record -p function_graph -l "vc4_hdmi_*" [...]
I'll add the command to v2.
> > vc4_hdmi_connector_detect:
> >
> > vc4_hdmi_connector_detect() {
> > drm_get_edid() {
> > drm_connector_update_edid_property() {
> > drm_add_display_info() {
> > drm_reset_display_info();
> > drm_for_each_detailed_block.part.0();
> > drm_parse_cea_ext() {
> > drm_find_cea_extension();
> > cea_db_offsets.part.0();
> > cea_db_is_hdmi_vsdb.part.0();
> > drm_parse_hdmi_vsdb_video();
> > /* drm_display_info.is_hdmi is cached here */
> > }
> > }
> > }
> > }
> > /* drm_display_info.is_hdmi is used here */
> > }
> >
> > vc4_hdmi_connector_get_modes:
> >
> > vc4_hdmi_connector_get_modes() {
> > drm_get_edid() {
> > drm_connector_update_edid_property() {
> > drm_add_display_info() {
> > drm_reset_display_info();
> > drm_for_each_detailed_block.part.0();
> > drm_parse_cea_ext() {
> > drm_find_cea_extension();
> > cea_db_offsets.part.0();
> > cea_db_is_hdmi_vsdb.part.0();
> > drm_parse_hdmi_vsdb_video();
> > /* drm_display_info.is_hdmi is cached here */
> > }
> > }
> > }
> > }
> > /* drm_display_info.is_hdmi is used here */
> > drm_connector_update_edid_property();
> > }
> >
> > Signed-off-by: José Expósito
>
> I think what you're hinting at in the cover letter would be best though:
> we should just remove that caching entirely and use is_hdmi everywhere
Cool, I'll work on a follow up patch to remove vc4_encoder.hdmi_monitor
and add it to v2.
Thanks,
Jose
Re: [PATCH v2 2/5] drm: bridge: dw_hdmi: default enable workaround to clear the overflow
Dne petek, 08. april 2022 ob 12:32:25 CEST je Sandor Yu napisal(a):
> i.MX8MPlus (v2.13a) has verified need the workaround to clear the
> overflow with one iteration.
> Only i.MX6Q(v1.30a) need the workaround with 4 iterations,
> the others versions later than v1.3a have been identified as needing
> the workaround with a single iteration.
>
> Default enable the workaround with one iteration for all versions
> later than v1.30a.
>
> Signed-off-by: Sandor Yu
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 23 +++
> 1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> 4befc104d220..02d8f7e08814 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2086,30 +2086,21 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
> *hdmi) * then write one of the FC registers several times.
>*
>* The number of iterations matters and depends on the HDMI TX
revision
> - * (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
> - * (v1.31a) and multiple Allwinner SoCs (v1.32a) have been
identified
> - * as needing the workaround, with 4 iterations for v1.30a and 1
> - * iteration for others.
> - * The Amlogic Meson GX SoCs (v2.01a) have been identified as
needing
> - * the workaround with a single iteration.
> - * The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs
(v2.11a) have
> - * been identified as needing the workaround with a single
iteration.
> + * (and possibly on the platform).
> + * 4 iterations for i.MX6Q(v1.30a) and 1 iteration for others.
> + * i.MX6DL (v1.31a), Allwinner SoCs (v1.32a), Rockchip RK3288 SoC
> (v2.00a), +* Amlogic Meson GX SoCs (v2.01a), RK3328/RK3399 SoCs (v2.11a)
> + * and i.MX8MPlus (v2.13a) have been identified as needing the
workaround
> + * with a single iteration.
>*/
It would be easier to read and modify later if platforms/controllers/variants
are given as list, one per line, but it could be done later.
Best regards,
Jernej
>
> switch (hdmi->version) {
> case 0x130a:
> count = 4;
> break;
> - case 0x131a:
> - case 0x132a:
> - case 0x200a:
> - case 0x201a:
> - case 0x211a:
> - case 0x212a:
> + default:
> count = 1;
> break;
> - default:
> - return;
> }
>
> /* TMDS software reset */
Re: [PATCH 1/7] video: fbdev: i740fb: Error out if 'pixclock' equals zero
On Friday 08 April 2022 03:58:10 Zheyu Ma wrote: > On Fri, Apr 8, 2022 at 3:50 AM Helge Deller wrote: > > > > On 4/4/22 10:47, Zheyu Ma wrote: > > > The userspace program could pass any values to the driver through > > > ioctl() interface. If the driver doesn't check the value of 'pixclock', > > > it may cause divide error. > > > > > > Fix this by checking whether 'pixclock' is zero in the function > > > i740fb_check_var(). > > > > > > The following log reveals it: > > > > > > divide error: [#1] PREEMPT SMP KASAN PTI > > > RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:444 [inline] > > > RIP: 0010:i740fb_set_par+0x272f/0x3bb0 drivers/video/fbdev/i740fb.c:739 > > > Call Trace: > > > fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1036 > > > do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1112 > > > fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1191 > > > vfs_ioctl fs/ioctl.c:51 [inline] > > > __do_sys_ioctl fs/ioctl.c:874 [inline] > > > > > > Signed-off-by: Zheyu Ma > > > > Hello Zheyu, > > > > I've applied the patches #2-#7 of this series, but left > > out this specific patch (for now). > > As discussed on the mailing list we can try to come up with a > > better fix (to round up the pixclock when it's invalid). > > If not, I will apply this one later. > > I'm also looking forward to a more appropriate patch for this driver! I was not able to reproduce it at first but finally found it: the monitor must be unplugged. If a valid EDID is present, fb_validate_mode() call in i740fb_check_var() will refuse zero pixclock. Haven't found any obvious way to correct zero pixclock value. Most other drivers simply return -EINVAL. > Thanks, > Zheyu Ma > -- Ondrej Zary
Re: vc4: Couldn't stop firmware display driver during boot
You know the drill, Stefan - what's in your config.txt? Phil On Sat, 9 Apr 2022, 20:26 Stefan Wahren, wrote: > Hi, > > today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected to my > HDMI display (multi_v7_defconfig + CONFIG_ARM_LPAE, firmware: > 2021-01-08T14:31:16) and i'm getting these strange errors from > raspberrypi-firmware driver / vc4 during boot: > > [ 13.094733] fb0: switching to vc4 from simple > [ 13.110759] Console: switching to colour dummy device 80x30 > [ 13.120691] raspberrypi-firmware soc:firmware: Request 0x00030066 > returned status 0x8001 > [ 13.120715] vc4-drm gpu: [drm] Couldn't stop firmware display driver: > -22 > [ 13.120839] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) > [ 13.121213] Bluetooth: Core ver 2.22 > [ 13.121266] NET: Registered PF_BLUETOOTH protocol family > [ 13.121270] Bluetooth: HCI device and connection manager initialized > [ 13.121281] Bluetooth: HCI socket layer initialized > [ 13.121286] Bluetooth: L2CAP socket layer initialized > [ 13.121297] Bluetooth: SCO socket layer initialized > [ 13.132879] cfg80211: Loading compiled-in X.509 certificates for > regulatory database > [ 13.164278] Bluetooth: HCI UART driver ver 2.3 > [ 13.164293] Bluetooth: HCI UART protocol H4 registered > [ 13.166608] raspberrypi-firmware soc:firmware: Request 0x00030066 > returned status 0x8001 > [ 13.166633] vc4-drm gpu: [drm] Couldn't stop firmware display driver: > -22 > [ 13.166717] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister > [vc4]) > [ 13.176173] Bluetooth: HCI UART protocol Broadcom registered > [ 13.182365] hci_uart_bcm serial0-0: supply vbat not found, using > dummy regulator > [ 13.182505] hci_uart_bcm serial0-0: supply vddio not found, using > dummy regulator > [ 13.300636] uart-pl011 fe201000.serial: no DMA platform data > [ 13.422683] raspberrypi-firmware soc:firmware: Request 0x00030066 > returned status 0x8001 > [ 13.422700] vc4-drm gpu: [drm] Couldn't stop firmware display driver: > -22 > [ 13.422788] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister > [vc4]) > [ 13.458620] bcmgenet fd58.ethernet: GENET 5.0 EPHY: 0x > [ 13.461925] raspberrypi-firmware soc:firmware: Request 0x00030066 > returned status 0x8001 > [ 13.461941] vc4-drm gpu: [drm] Couldn't stop firmware display driver: > -22 > [ 13.462006] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister > [vc4]) > [ 13.469287] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' > [ 13.507497] vc4-drm gpu: bound fef00700.hdmi (ops vc4_drm_unregister > [vc4]) > [ 13.521840] brcmfmac: brcmf_fw_alloc_request: using > brcm/brcmfmac43456-sdio for chip BCM4345/9 > [ 13.522128] brcmfmac mmc0:0001:1: Direct firmware load for > brcm/brcmfmac43456-sdio.raspberrypi,400.bin failed with error -2 > [ 13.535444] brcmfmac mmc0:0001:1: Direct firmware load for > brcm/brcmfmac43456-sdio.raspberrypi,400.txt failed with error -2 > [ 13.564153] Bluetooth: hci0: BCM: chip id 130 > [ 13.564675] Bluetooth: hci0: BCM: features 0x0f > [ 13.566157] Bluetooth: hci0: BCM4345C5 > [ 13.566164] Bluetooth: hci0: BCM4345C5 (003.006.006) build > [ 13.568434] Bluetooth: hci0: BCM4345C5 'brcm/BCM4345C5.hcd' Patch > [ 13.570485] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus > [ 13.576820] vc4-drm gpu: bound fef05700.hdmi (ops vc4_drm_unregister > [vc4]) > [ 13.576967] vc4-drm gpu: bound fe004000.txp (ops vc4_drm_unregister > [vc4]) > [ 13.577044] vc4-drm gpu: bound fe206000.pixelvalve (ops > vc4_drm_unregister [vc4]) > [ 13.577118] vc4-drm gpu: bound fe207000.pixelvalve (ops > vc4_drm_unregister [vc4]) > [ 13.577185] vc4-drm gpu: bound fe20a000.pixelvalve (ops > vc4_drm_unregister [vc4]) > [ 13.577237] vc4-drm gpu: bound fe216000.pixelvalve (ops > vc4_drm_unregister [vc4]) > [ 13.613504] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > > Best regards > >
