Re: [PATCH] dt-bindings: Improve phandle-array schemas
On 18-01-22, 19:50, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > > .../devicetree/bindings/opp/opp-v2-base.yaml | 2 + > .../bindings/power/power-domain.yaml | 4 + Acked-by: Viresh Kumar -- viresh
Re: [PATCH] dt-bindings: Drop unnecessary pinctrl properties
On 19/01/2022 02:53, Rob Herring wrote: > For a single pinctrl mode, it is not necessary to define pinctrl > properties as the tools always allow pinctrl properties. > > Signed-off-by: Rob Herring > --- > .../display/rockchip/rockchip,rk3066-hdmi.yaml | 8 > Documentation/devicetree/bindings/input/gpio-keys.yaml | 6 -- > .../devicetree/bindings/pinctrl/cirrus,lochnagar.yaml | 9 - > .../devicetree/bindings/pinctrl/cirrus,madera.yaml | 10 -- > .../devicetree/bindings/sound/samsung-i2s.yaml | 6 -- > 5 files changed, 39 deletions(-) > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On 19/01/2022 02:50, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > Samsung and memory controller bits look good: Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2] phy: dphy: Correct clk_pre parameter
On 19.01.2022 03:37, Liu Ying wrote:
The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE
parameter's unit is Unit Interval(UI) and the minimum value is 8. Also,
kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy
mentions that it should be in UI. However, the dphy core driver wrongly
sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds.
And, the kernel doc of the 'clk_pre' member wrongly says the minimum value
is '8 UI', instead of 8.
So, let's fix both the dphy core driver and the kernel doc of the 'clk_pre'
member to correctly reflect the T-CLK-PRE parameter's unit and the minimum
value according to the D-PHY specification.
I'm assuming that all impacted custom drivers shall program values in
TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY
specification mentions that the frequency of TxByteClkHS is exactly 1/8
the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant
custom driver code is changed to program those values as
DIV_ROUND_UP(cfg->clk_pre, BITS_PER_BYTE), then.
Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK.
Help is needed to test with other i.MX8mq, Meson and Rockchip platforms,
as I don't have the hardwares.
Fixes: 2ed869990e14 ("phy: Add MIPI D-PHY configuration options")
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Cc: David Airlie
Cc: Daniel Vetter
Cc: Kishon Vijay Abraham I
Cc: Vinod Koul
Cc: Kevin Hilman
Cc: Jerome Brunet
Cc: Martin Blumenstingl
Cc: Heiko Stuebner
Cc: Maxime Ripard
Cc: Guido Günther
Tested-by: Liu Ying # RM67191 DSI panel on i.MX8mq EVK
Signed-off-by: Liu Ying
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
v1->v2:
* Use BITS_PER_BYTE macro. (Andrzej)
* Drop dsi argument from ui2bc() in nwl-dsi.c.
drivers/gpu/drm/bridge/nwl-dsi.c | 12 +---
drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c| 3 ++-
drivers/phy/phy-core-mipi-dphy.c | 4 ++--
drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 3 ++-
include/linux/phy/phy-mipi-dphy.h| 2 +-
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a7389a0facfb..af07eeb47ca0 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -196,12 +197,9 @@ static u32 ps2bc(struct nwl_dsi *dsi, unsigned long long
ps)
/*
* ui2bc - UI time periods to byte clock cycles
*/
-static u32 ui2bc(struct nwl_dsi *dsi, unsigned long long ui)
+static u32 ui2bc(unsigned int ui)
{
- u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
-
- return DIV64_U64_ROUND_UP(ui * dsi->lanes,
- dsi->mode.clock * 1000 * bpp);
+ return DIV_ROUND_UP(ui, BITS_PER_BYTE);
}
/*
@@ -232,12 +230,12 @@ static int nwl_dsi_config_host(struct nwl_dsi *dsi)
}
/* values in byte clock cycles */
- cycles = ui2bc(dsi, cfg->clk_pre);
+ cycles = ui2bc(cfg->clk_pre);
DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_pre: 0x%x\n", cycles);
nwl_dsi_write(dsi, NWL_DSI_CFG_T_PRE, cycles);
cycles = ps2bc(dsi, cfg->lpx + cfg->clk_prepare + cfg->clk_zero);
DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap (pre): 0x%x\n", cycles);
- cycles += ui2bc(dsi, cfg->clk_pre);
+ cycles += ui2bc(cfg->clk_pre);
DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_post: 0x%x\n", cycles);
nwl_dsi_write(dsi, NWL_DSI_CFG_T_POST, cycles);
cycles = ps2bc(dsi, cfg->hs_exit);
diff --git a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
index cd2332bf0e31..fdbd64c03e12 100644
--- a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
+++ b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -250,7 +251,7 @@ static int phy_meson_axg_mipi_dphy_power_on(struct phy *phy)
(DIV_ROUND_UP(priv->config.clk_zero, temp) << 16) |
(DIV_ROUND_UP(priv->config.clk_prepare, temp) << 24));
regmap_write(priv->regmap, MIPI_DSI_CLK_TIM1,
-DIV_ROUND_UP(priv->config.clk_pre, temp));
+DIV_ROUND_UP(priv->config.clk_pre, BITS_PER_BYTE));
regmap_write(priv->regmap, MIPI_DSI_HS_TIM,
DIV_ROUND_UP(priv->config.hs_exit, temp) |
diff --git a/drivers/phy/phy-core-mipi-dphy.c b/drivers/phy/phy-core-mipi-dphy.c
index 288c9c67aa74..ccb4045685cd 100644
--- a/drivers/phy/phy-core-mipi-dphy.c
+++ b/drivers/phy/phy-core-mipi-dphy.c
@@ -36,7 +36,7 @@ int phy_mipi_dphy_get_default_config(unsigned long
pixel_clock,
cfg->clk_miss = 0;
cfg->clk_post = 6 + 52 * ui;
- cfg->clk_pre =
[PATCH 3/3] drm: Convert open yes/no strings to yesno()
linux/string_helpers.h provides a helper to return "yes"/"no"
strings. Replace the open coded versions with yesno(). The places were
identified with the following semantic patch:
@@
expression b;
@@
- b ? "yes" : "no"
+ yesno(b)
Then the includes were added, so we include-what-we-use, and parenthesis
adjusted in drivers/gpu/drm/v3d/v3d_debugfs.c. After the conversion we
still see the same binary sizes:
textdata bss dec hex filename
1442171 60344 800 1503315 16f053 ./drivers/gpu/drm/radeon/radeon.ko
1442171 60344 800 1503315 16f053 ./drivers/gpu/drm/radeon/radeon.ko.old
5985991 324439 33808 6344238 60ce2e ./drivers/gpu/drm/amd/amdgpu/amdgpu.ko
5985991 324439 33808 6344238 60ce2e
./drivers/gpu/drm/amd/amdgpu/amdgpu.ko.old
411986 104906176 428652 68a6c ./drivers/gpu/drm/drm.ko
411986 104906176 428652 68a6c ./drivers/gpu/drm/drm.ko.old
1970292 1095152352 2082159 1fc56f ./drivers/gpu/drm/nouveau/nouveau.ko
1970292 1095152352 2082159 1fc56f ./drivers/gpu/drm/nouveau/nouveau.ko.old
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/amd/amdgpu/atom.c | 3 ++-
drivers/gpu/drm/drm_client_modeset.c | 3 ++-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
drivers/gpu/drm/drm_gem.c | 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 4 +++-
drivers/gpu/drm/radeon/atom.c | 3 ++-
drivers/gpu/drm/v3d/v3d_debugfs.c | 11 ++-
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 3 ++-
8 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 6fa2229b7229..3d7d0f4cfc05 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -740,7 +741,7 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
break;
}
if (arg != ATOM_COND_ALWAYS)
- SDEBUG(" taken: %s\n", execute ? "yes" : "no");
+ SDEBUG(" taken: %s\n", yesno(execute));
SDEBUG(" target: 0x%04X\n", target);
if (execute) {
if (ctx->last_jump == (ctx->start + target)) {
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index ced09c7c06f9..3c55156a75fa 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -241,7 +242,7 @@ static void drm_client_connectors_enabled(struct
drm_connector **connectors,
connector = connectors[i];
enabled[i] = drm_connector_enabled(connector, true);
DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- connector->display_info.non_desktop ? "non
desktop" : enabled[i] ? "yes" : "no");
+ connector->display_info.non_desktop ? "non
desktop" : yesno(enabled[i]));
any_enabled |= enabled[i];
}
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4d0d1e8e51fa..f600616839f3 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1122,7 +1123,7 @@ void drm_dp_downstream_debug(struct seq_file *m,
bool branch_device = drm_dp_is_branch(dpcd);
seq_printf(m, "\tDP branch device present: %s\n",
- branch_device ? "yes" : "no");
+ yesno(branch_device));
if (!branch_device)
return;
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4dcdec6487bb..6436876341bb 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1145,7 +1146,7 @@ void drm_gem_print_info(struct drm_printer *p, unsigned
int indent,
drm_vma_node_start(&obj->vma_node));
drm_printf_indent(p, indent, "size=%zu\n", obj->size);
drm_printf_indent(p, indent, "imported=%s\n",
- obj->import_attach ? "yes" : "no");
+ yesno(obj->import_attach));
if (obj->funcs->print_info)
obj->funcs->print_info(p, indent, obj);
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
index a11637b0f6cc..d39a9c1a2a6e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
@@ -21,6 +21,8 @@
*
* Authors: Ben Skeggs
*/
+#include
+
#include "aux.h"
#include "pad.h"
@@ -94,7 +96,7 @@ void
nvkm_i2c_aux_monitor(struct nvkm_i2c_aux *aux,
[PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
There are a few implementations of yesno() in the tree. Consolidate them
in include/linux/string_helpers.h. Quite a few users of open coded
yesno() could later be converted to the new function:
$ git grep '?\s*"yes"\s*' | wc -l
286
$ git grep '?\s*"no"\s*' | wc -l
20
The inlined function should keep the const strings local to each
compilation unit, the same way it's now, thus not changing the current
behavior.
Signed-off-by: Lucas De Marchi
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +-
drivers/gpu/drm/i915/i915_utils.h | 5 -
.../net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 11 ---
include/linux/string_helpers.h | 2 ++
security/tomoyo/audit.c| 2 +-
security/tomoyo/common.c | 18 --
security/tomoyo/common.h | 1 -
7 files changed, 8 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 9d43ecb1f692..b59760f91bf6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -23,6 +23,7 @@
*
*/
+#include
#include
#include "dc.h"
@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
uint32_t param1;
};
-static inline const char *yesno(bool v)
-{
- return v ? "yes" : "no";
-}
-
/* parse_write_buffer_into_params - Helper function to parse debugfs write
buffer into an array
*
* Function takes in attributes passed to debugfs write entry
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 7a5925072466..2a8781cc648b 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -414,11 +414,6 @@ wait_remaining_ms_from_jiffies(unsigned long
timestamp_jiffies, int to_wait_ms)
#define MBps(x) KBps(1000 * (x))
#define GBps(x) ((u64)1000 * MBps((x)))
-static inline const char *yesno(bool v)
-{
- return v ? "yes" : "no";
-}
-
static inline const char *onoff(bool v)
{
return v ? "on" : "off";
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 7d49fd4edc9e..61a04d7abc1f 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -2015,17 +2015,6 @@ static const struct file_operations rss_debugfs_fops = {
/* RSS Configuration.
*/
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
- static const char *yes = "yes";
- static const char *no = "no";
-
- return x ? yes : no;
-}
-
static int rss_config_show(struct seq_file *seq, void *v)
{
struct adapter *adapter = seq->private;
diff --git a/include/linux/string_helpers.h b/include/linux/string_helpers.h
index 4ba39e1403b2..e980dec05d31 100644
--- a/include/linux/string_helpers.h
+++ b/include/linux/string_helpers.h
@@ -102,4 +102,6 @@ char *kstrdup_quotable_file(struct file *file, gfp_t gfp);
void kfree_strarray(char **array, size_t n);
+static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
+
#endif
diff --git a/security/tomoyo/audit.c b/security/tomoyo/audit.c
index d79bf07e16be..1458e27361e8 100644
--- a/security/tomoyo/audit.c
+++ b/security/tomoyo/audit.c
@@ -166,7 +166,7 @@ static char *tomoyo_print_header(struct tomoyo_request_info
*r)
"#%04u/%02u/%02u %02u:%02u:%02u# profile=%u mode=%s
granted=%s (global-pid=%u) task={ pid=%u ppid=%u uid=%u gid=%u euid=%u egid=%u
suid=%u sgid=%u fsuid=%u fsgid=%u }",
stamp.year, stamp.month, stamp.day, stamp.hour,
stamp.min, stamp.sec, r->profile, tomoyo_mode[r->mode],
- tomoyo_yesno(r->granted), gpid, tomoyo_sys_getpid(),
+ yesno(r->granted), gpid, tomoyo_sys_getpid(),
tomoyo_sys_getppid(),
from_kuid(&init_user_ns, current_uid()),
from_kgid(&init_user_ns, current_gid()),
diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
index 5c64927bf2b3..304ed0f426dd 100644
--- a/security/tomoyo/common.c
+++ b/security/tomoyo/common.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "common.h"
/* String table for operation mode. */
@@ -174,16 +175,6 @@ static bool tomoyo_manage_by_non_root;
/* Utility functions. */
-/**
- * tomoyo_yesno - Return "yes" or "no".
- *
- * @value: Bool value.
- */
-const char *tomoyo_yesno(const unsigned int value)
-{
- return value ? "yes" : "no";
-}
-
/**
* tomoyo_addprintf - strncat()-like-snprintf().
*
@@ -730,8 +721,8 @@ static void tomoyo_print_config(struct tomoyo_io_buffer
*head, const u8 config)
{
tomoyo_io_printf(head, "={ mode=%s gra
[PATCH 2/3] lib/string_helpers: Add helpers for enable[d]/disable[d]
Follow the yes/no logic and add helpers for enabled/disabled and
enable/disable - those are not so common throughout the kernel,
but they give a nice way to reuse the strings to log things as
enabled/disabled or enable/disable.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_utils.h | 10 --
include/linux/string_helpers.h| 2 ++
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 2a8781cc648b..cbec79bae0d2 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -419,16 +419,6 @@ static inline const char *onoff(bool v)
return v ? "on" : "off";
}
-static inline const char *enabledisable(bool v)
-{
- return v ? "enable" : "disable";
-}
-
-static inline const char *enableddisabled(bool v)
-{
- return v ? "enabled" : "disabled";
-}
-
void add_taint_for_CI(struct drm_i915_private *i915, unsigned int taint);
static inline void __add_taint_for_CI(unsigned int taint)
{
diff --git a/include/linux/string_helpers.h b/include/linux/string_helpers.h
index e980dec05d31..e4b82f364ee1 100644
--- a/include/linux/string_helpers.h
+++ b/include/linux/string_helpers.h
@@ -103,5 +103,7 @@ char *kstrdup_quotable_file(struct file *file, gfp_t gfp);
void kfree_strarray(char **array, size_t n);
static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
+static inline const char *enabledisable(bool v) { return v ? "enable" :
"disable"; }
+static inline const char *enableddisabled(bool v) { return v ? "enabled" :
"disabled"; }
#endif
--
2.34.1
[PATCH 0/3] lib/string_helpers: Add a few string helpers
Add some helpers under lib/string_helpers.h so they can be used throughout the kernel. When I started doing this there were 2 other previous attempts I know of, not counting the iterations each of them had: 1) https://lore.kernel.org/all/20191023131308.9420-1-jani.nik...@intel.com/ 2) https://lore.kernel.org/all/20210215142137.64476-1-andriy.shevche...@linux.intel.com/#t Going through the comments I tried to find some common ground and justification for what is in here, addressing some of the concerns raised. a. This version should be a drop-in replacement for what is currently in the tree, with no change in behavior or binary size. For binary size what I checked wat that the linked objects in the end have the same size (gcc 11). From comments in the previous attempts this seems also the case for earlier compiler versions b. I didn't change the function name to choice_* as suggested by Andrew Morton in 20191023155619.43e0013f0c8c673a5c508...@linux-foundation.org because other people argumented in favor of shorter names for these simple helpers - if they are long and people simply not use due to that, we failed c. Use string_helper.h for these helpers - pulling string.h in the compilations units was one of the concerns and I think re-using this already existing header is better than creating a new string-choice.h d. This doesn't bring onoff() helper as there are some places in the kernel with onoff as variable - another name is probably needed for this function in order not to shadow the variable, or those variables could be renamed. Or if people wanting try to find a short one e. One alternative to all of this suggested by Christian König (43456ba7-c372-84cc-4949-dcb817188...@amd.com) would be to add a printk format. But besides the comment, he also seemed to like the common function. This brought the argument from others that the simple yesno()/enabledisable() already used in the code is easier to remember and use than e.g. %py[DOY] Last patch also has some additional conversion of open coded cases. I preferred starting with drm/ since this is "closer to home". I hope this is a good summary of the previous attempts and a way we can move forward. Andrew Morton, Petr Mladek, Andy Shevchenko: if this is accepted, my proposal is to take first 2 patches either through mm tree or maybe vsprintf. Last patch can be taken later through drm. thanks Lucas De Marchi Cc: Alex Deucher Cc: Andrew Morton Cc: Andy Shevchenko Cc: Andy Shevchenko Cc: Ben Skeggs Cc: Christian König Cc: Chris Wilson Cc: Daniel Vetter Cc: David Airlie Cc: David S. Miller Cc: Emma Anholt Cc: Eryk Brol Cc: Francis Laniel Cc: Greg Kroah-Hartman Cc: Harry Wentland Cc: Jakub Kicinski Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Julia Lawall Cc: Kentaro Takeda Cc: Leo Li Cc: Mikita Lipski Cc: Petr Mladek Cc: Rahul Lakkireddy Cc: Raju Rangoju Cc: Rasmus Villemoes Cc: Rodrigo Vivi Cc: Sakari Ailus Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: Vishal Kulkarni Lucas De Marchi (3): lib/string_helpers: Consolidate yesno() implementation lib/string_helpers: Add helpers for enable[d]/disable[d] drm: Convert open yes/no strings to yesno() drivers/gpu/drm/amd/amdgpu/atom.c | 3 ++- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +- drivers/gpu/drm/drm_client_modeset.c | 3 ++- drivers/gpu/drm/drm_dp_helper.c| 3 ++- drivers/gpu/drm/drm_gem.c | 3 ++- drivers/gpu/drm/i915/i915_utils.h | 15 --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 4 +++- drivers/gpu/drm/radeon/atom.c | 3 ++- drivers/gpu/drm/v3d/v3d_debugfs.c | 11 ++- drivers/gpu/drm/virtio/virtgpu_debugfs.c | 3 ++- .../net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 11 --- include/linux/string_helpers.h | 4 security/tomoyo/audit.c| 2 +- security/tomoyo/common.c | 18 -- security/tomoyo/common.h | 1 - 15 files changed, 31 insertions(+), 59 deletions(-) -- 2.34.1
Re: [PATCH v9 1/6] drm: move the buddy allocator from i915 into common drm
Am 18.01.22 um 11:44 schrieb Arunpravin:
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- add Makefile support for drm buddy
- export functions and write kerneldoc description
- Remove i915 selftest config check condition as buddy selftest
will be moved to drm selftest folder
cleanup i915 buddy references in i915 driver module
and replace with drm buddy
v2:
- include header file in alphabetical order(Thomas)
- merged changes listed in the body section into a single patch
to keep the build intact(Christian, Jani)
v3:
- make drm buddy a separate module(Thomas, Christian)
v4:
- Fix build error reported by kernel test robot
- removed i915 buddy selftest from i915_mock_selftests.h to
avoid build error
- removed selftests/i915_buddy.c file as we create a new set of
buddy test cases in drm/selftests folder
v5:
- Fix merge conflict issue
v6:
- replace drm_buddy_mm structure name as drm_buddy(Thomas, Christian)
- replace drm_buddy_alloc() function name as drm_buddy_alloc_blocks()
(Thomas)
- replace drm_buddy_free() function name as drm_buddy_free_block()
(Thomas)
- export drm_buddy_free_block() function
- fix multiple instances of KMEM_CACHE() entry
v7:
- fix warnings reported by kernel test robot
- modify the license(Christian)
v8:
- fix warnings reported by kernel test robot
Signed-off-by: Arunpravin
I've just gone ahead and pushed this version here to drm-misc-next.
That should at least reduce the amount of mails send back and forth.
Let me know when there are more rbs on the rest and I will push that as
well.
Thanks,
Christian.
---
drivers/gpu/drm/Kconfig | 6 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_buddy.c | 535
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/i915_buddy.c | 466 ---
drivers/gpu/drm/i915/i915_buddy.h | 143
drivers/gpu/drm/i915/i915_module.c| 3 -
drivers/gpu/drm/i915/i915_scatterlist.c | 11 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 33 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 4 +-
drivers/gpu/drm/i915/selftests/i915_buddy.c | 787 --
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
.../drm/i915/selftests/intel_memory_region.c | 13 +-
include/drm/drm_buddy.h | 150
15 files changed, 725 insertions(+), 1431 deletions(-)
create mode 100644 drivers/gpu/drm/drm_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
delete mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c
create mode 100644 include/drm/drm_buddy.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 91f54aeb0b7c..cc3e979c9c9d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -204,6 +204,12 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_BUDDY
+ tristate
+ depends on DRM
+ help
+ A page based buddy allocator
+
config DRM_VRAM_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 700abeb4945e..8675c2af7ae1 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -40,6 +40,8 @@ obj-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_cma_helper.o
drm_shmem_helper-y := drm_gem_shmem_helper.o
obj-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_shmem_helper.o
+obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
+
drm_vram_helper-y := drm_gem_vram_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
new file mode 100644
index ..d60878bc9c20
--- /dev/null
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -0,0 +1,535 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+static struct kmem_cache *slab_blocks;
+
+static struct drm_buddy_block *drm_block_alloc(struct drm_buddy *mm,
+ struct drm_buddy_block *parent,
+ unsigned int order,
+ u64 offset)
+{
+ struct drm_buddy_block *block;
+
+ BUG_ON(order > DRM_BUDDY_MAX_ORDER);
+
+ block = kmem_cache_zalloc(slab_blocks, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ block->header = offset;
+ block->header |= order;
+ b
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files
Quoting Tvrtko Ursulin (2022-01-17 18:02:50) > > On 17/01/2022 15:09, Andi Shyti wrote: > > The GT has its own properties and in sysfs they should be grouped > > in the 'gt/' directory. > > > > Create a 'gt/' directory in sysfs which will contain gt0...gtN > > directories related to each tile configured in the GPU. Move the > > power management files inside those directories. > > > > The previous power management files are kept in their original > > root directory to avoid breaking the ABI. They point to the tile > > '0' and a warning message is printed whenever accessed to. This is wrong. They should act as multiplexers to all the tiles. Needs to be fixed before merging. > > The > > deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2 > > flag in order to be generated. > > CONFIG_SYSFS_DEPRECATED_V2 idea was abandoned, no? This patch at least > does not appear to contain it so please update the commit message to > reflect current state. > > Adding Joonas to help address the question of how strict are userspace > requirements for sysfs additions. Personally sysadmin use sounds fine to > me, although it needs to be mentioned/documented as Matt requested, but > I fear it may not be enough to upstream. Is Level0 at the stage where we > can upstream for it I am also not sure. Sysadmin usage is fine for the simple interfaces that can truly be used from the command line. This patch seems to just expose the existing interface in per-tile manner, so should not be a concern. However, the controls not under gt directories, need to be converted to apply to all tiles. (I've definitely given that feedback multiple times). Otherwise it will be very unexpected to the end user when what previously applied to whole device would only apply to part of it. Regards, Joonas > > While I am here I also left some nits below (not full review). > > > > > The new sysfs structure will have a similar layout for the 4 tile > > case: > > > > /sys/.../card0 > > \u251c\u2500\u2500 gt > > \u2502 \u251c\u2500\u2500 gt0 > > \u2502 \u2502 \u251c\u2500\u2500 id > > \u2502 \u2502 \u251c\u2500\u2500 rc6_enable > > \u2502 \u2502 \u251c\u2500\u2500 rc6_residency_ms > > \u2502 \u2502 \u251c\u2500\u2500 rps_act_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_boost_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_cur_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_max_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_min_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_RP0_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_RP1_freq_mhz > > \u2502 \u2502 \u2514\u2500\u2500 rps_RPn_freq_mhz > >. . > >. . > >. . > > \u2502 \u2514\u2500\u2500 gt3 > > \u2502 \u251c\u2500\u2500 id > > \u2502 \u251c\u2500\u2500 rc6_enable > > \u2502 \u251c\u2500\u2500 rc6_residency_ms > > \u2502 \u251c\u2500\u2500 rps_act_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_boost_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_cur_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_max_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_min_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_RP0_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_RP1_freq_mhz > > \u2502 \u2514\u2500\u2500 rps_RPn_freq_mhz > > \u251c\u2500\u2500 gt_act_freq_mhz -+ > > \u251c\u2500\u2500 gt_boost_freq_mhz | > > \u251c\u2500\u2500 gt_cur_freq_mhz|Original interface > > \u251c\u2500\u2500 gt_max_freq_mhz+\u2500-> kept as existing > > ABI; > > \u251c\u2500\u2500 gt_min_freq_mhz|it points to gt0/ > > \u251c\u2500\u2500 gt_RP0_freq_mhz| > > \u2514\u2500\u2500 gt_RP1_freq_mhz| > > \u2514\u2500\u2500 gt_RPn_freq_mhz -+ > > > > As soon as multitile platforms will start being supported, this > > interface will allow to control the power (either manually or > > with tools) on each tile, instead of affecting only tile 0 and > > getting incomplete results. > > > > Signed-off-by: Andi Shyti > > Signed-off-by: Lucas De Marchi > > Cc: Matt Roper > > Cc: Sujaritha Sundaresan > > Cc: Tvrtko Ursulin > > Reviewed-by: Sujaritha Sundaresan > > --- > > drivers/gpu/drm/i915/Makefile | 4 +- > > drivers/gpu/drm/i915/gt/intel_gt.c| 2 + > > drivers/gpu/drm/i915/gt/sysfs_gt.c| 126 + > > drivers/gpu/drm/i915/gt/sysfs_gt.h| 44 +++ > > drivers/gpu/drm/i915/gt/sysfs_gt_pm.c | 393 ++ > > drivers/gpu/drm/i915/gt/sysfs_gt_pm.h | 16 ++ > > drivers/gpu/drm/i915/i915_drv.h | 2 + > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > drivers/gpu/drm/i915/i915
Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul,
> Am 18.01.2022 um 23:59 schrieb Paul Boddie :
>
> On Tuesday, 18 January 2022 17:58:58 CET Paul Cercueil wrote:
>>
>> Not at all. If the clock is disabled, the LCD controller is disabled,
>> so all the registers read zero, this makes sense. You can only read the
>> registers when the clock is enabled. On some SoCs, reading disabled
>> registers can even cause a complete lockup.
>
> My concern was that something might be accessing the registers before the
> clock had been enabled. It seems unlikely, given that the clock is enabled in
> the bind function, and I would have thought that nothing would invoke the
> different driver operations ("funcs") until bind has been called, nor should
> anything called from within bind itself be accessing registers.
>
>> Why is this JZ_LCD_OSDC_ALPHAEN bit needed now? I remember it working
>> fine last time I tried, and now I indeed get a black screen unless this
>> bit is set. The PM doesn't make it obvious that the bit is required,
>> but that wouldn't be surprising.
>
> It isn't actually needed. If the DMA descriptors are set up appropriately,
> the
> OSD alpha bit seems to be set as a consequence. In my non-Linux testing
> environment I don't even set any OSD registers explicitly, but the OSD alpha
> and enable flags become set when the display is active.
Is it set by DMA descriptors or by explicit code?
We did have an explicit setting of JZ_LCD_OSDC_ALPHAEN
https://www.spinics.net/lists/devicetree/msg438447.html
but that was postponed for further discussion. And now if we
add it (from basic functionality) back, it is fine again.
BR,
Nikolaus
Re: [PATCH v2 3/3] ASoC: rk3399_gru_sound: Wire up DP jack detection
On Wed, Jan 19, 2022 at 4:18 AM Brian Norris wrote:
>
> Hi Chen-Yu,
>
> On Mon, Jan 17, 2022 at 05:01:52PM +0800, Chen-Yu Tsai wrote:
> > On Sat, Jan 15, 2022 at 7:03 AM Brian Norris
> > wrote:
> > >
> > > Now that the cdn-dp driver supports plug-change callbacks, let's wire it
> > > up.
> > >
> > > Signed-off-by: Brian Norris
> > > ---
> > >
> > > (no changes since v1)
> > >
> > > sound/soc/rockchip/rk3399_gru_sound.c | 20
> > > 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
> > > b/sound/soc/rockchip/rk3399_gru_sound.c
> > > index e2d52d8d0ff9..eeef3ed70037 100644
> > > --- a/sound/soc/rockchip/rk3399_gru_sound.c
> > > +++ b/sound/soc/rockchip/rk3399_gru_sound.c
> > > @@ -164,6 +164,25 @@ static int rockchip_sound_da7219_hw_params(struct
> > > snd_pcm_substream *substream,
> > > return 0;
> > > }
> > >
> > > +static struct snd_soc_jack cdn_dp_card_jack;
> > > +
> > > +static int rockchip_sound_cdndp_init(struct snd_soc_pcm_runtime *rtd)
> > > +{
> > > + struct snd_soc_component *component = asoc_rtd_to_codec(rtd,
> > > 0)->component;
> >
> > Using snd_soc_card_get_codec_dai() might be a better choice throughout this
> > driver. While it will work for the cdn_dp case, because it is the first DAI
> > in |rockchip_dais[]|, all the invocations for the other codecs are likely
> > returning the wrong DAI.
>
> I'll admit, I'm not very familiar with the ASoC object model, so you may
> well be correct that there's something fishy in here. But I did trace
> through the objects involved here, and we *are* getting the correct DAI
> for both this case and the DA7219 case (preexisting code).
Neither am I, so ...
> It looks like we actually have a new runtime for each of our static
> dai_links:
>
> devm_snd_soc_register_card()
> ...
> for_each_card_prelinks()
> snd_soc_add_pcm_runtime()
>
> So I think this is valid to keep as-is.
I missed this bit. As you say, things are good.
> > For this particular patch it works either way, so
> >
> > Reviewed-by: Chen-Yu Tsai
>
> Thanks for looking!
And thanks for double checking!
[PATCH] drm/rockchip: Fix runtime PM imbalance on error
pm_runtime_get_sync() will increase the rumtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Yongzhi Liu
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 4740cc1..05c6abf 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -100,7 +100,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
goto err_core_clk;
}
- ret = pm_runtime_get_sync(dp->dev);
+ ret = pm_runtime_resume_and_get(dp->dev);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
goto err_pm_runtime_get;
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 0b97241..721ee0f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -146,7 +146,7 @@ static int rk3288_lvds_poweron(struct rockchip_lvds *lvds)
DRM_DEV_ERROR(lvds->dev, "failed to enable lvds pclk %d\n",
ret);
return ret;
}
- ret = pm_runtime_get_sync(lvds->dev);
+ ret = pm_runtime_resume_and_get(lvds->dev);
if (ret < 0) {
DRM_DEV_ERROR(lvds->dev, "failed to get pm runtime: %d\n", ret);
clk_disable(lvds->pclk);
--
2.7.4
Re: [PATCH] Revert "drm: exynos: dsi: Convert to bridge driver"
Hi, 22. 1. 17. 오후 6:55에 Robert Foss 이(가) 쓴 글: > Hi Inki, > > On Fri, 14 Jan 2022 at 02:18, Inki Dae wrote: >> >> Hi Robert, >> >> 22. 1. 12. 오후 7:05에 Robert Foss 이(가) 쓴 글: >>> Thank you again for catching this and submitting a revert. >>> >>> Reviewed-by: Robert Foss >> >>> Applied to drm-misc-next. >>> >> >> Trivial thing I think but just notice. With this applying - original patch >> set and revert one, merge conflict may happen on drm-next because >> drm-misc-next has this patch set exynos-drm-next tree doesn't include. >> Leaving this patch history in drm-misc-next is correct? > > Thanks for paying attention to this. > > If we end up seeing a conflict, the exynos patches can go in through drm-misc. > I mean is it correct to leave some patch set history - which is not reviewed and even not tested - exists in management tree? Anyway, it depends on maintainer of this tree. :) Thanks, Inki Dae
[PATCH] drm/rockchip: Fix runtime PM imbalance on error
pm_runtime_get_sync() will increase the rumtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Yongzhi Liu
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 4ed7a68..9cf53f0 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1188,7 +1188,7 @@ static int dw_mipi_dsi_dphy_power_on(struct phy *phy)
return i;
}
- ret = pm_runtime_get_sync(dsi->dev);
+ ret = pm_runtime_resume_and_get(dsi->dev);
if (ret < 0) {
DRM_DEV_ERROR(dsi->dev, "failed to enable device: %d\n", ret);
return ret;
--
2.7.4
[PATCH] drm/rockchip: Fix runtime PM imbalance on error
pm_runtime_get_sync() will increase the rumtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Yongzhi Liu
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9fb83b6..e0c48f1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -588,7 +588,7 @@ static int vop_enable(struct drm_crtc *crtc, struct
drm_crtc_state *old_state)
struct vop *vop = to_vop(crtc);
int ret, i;
- ret = pm_runtime_get_sync(vop->dev);
+ ret = pm_runtime_resume_and_get(vop->dev);
if (ret < 0) {
DRM_DEV_ERROR(vop->dev, "failed to get pm runtime: %d\n", ret);
return ret;
--
2.7.4
Re: [v3 1/3] dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties
On Wed, 19 Jan 2022 02:08:38 +0530, Rajeev Nandan wrote:
> In most cases, the default values of DSI PHY tuning registers should be
> sufficient as they are fully optimized. However, in some cases where
> extreme board parasitics cause the eye shape to degrade, the override
> bits can be used to improve the signal quality.
>
> The general guidelines for DSI PHY tuning include:
> - High and moderate data rates may benefit from the drive strength and
> drive level tuning.
> - Drive strength tuning will affect the output impedance and may be used
> for matching optimization.
> - Drive level tuning will affect the output levels without affecting the
> impedance.
>
> The clock and data lanes have a calibration circuitry feature. The drive
> strength tuning can be done by adjusting rescode offset for hstop/hsbot,
> and the drive level tuning can be done by adjusting the LDO output level
> for the HSTX drive.
>
> Signed-off-by: Rajeev Nandan
> ---
>
> Changes in v2:
> - More details in the commit text (Stephen Boyd)
> - Use human understandable values (Stephen Boyd, Dmitry Baryshkov)
> - Do not take values that are going to be unused (Dmitry Baryshkov)
>
> Changes in v3:
> - Use "qcom," prefix (Dmitry Baryshkov)
> - Remove encoding from phy-drive-ldo-level (Dmitry Baryshkov)
> - Use negative values instead of two's complement (Dmitry, Rob Herring)
>
>
> .../bindings/display/msm/dsi-phy-10nm.yaml | 34
> ++
> 1 file changed, 34 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:
properties:qcom,phy-rescode-offset-bot: 'minimum' should not be valid under
{'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum',
'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:
properties:qcom,phy-rescode-offset-bot: 'maximum' should not be valid under
{'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum',
'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:
properties:qcom,phy-rescode-offset-bot: 'minimum' should not be valid under
{'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum',
'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:
properties:qcom,phy-rescode-offset-bot: 'maximum' should not be valid under
{'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum',
'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:
properties:qcom,phy-rescode-offset-top: 'minimum' should not be valid under
{'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum',
'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:
properties:qcom,phy-rescode-offset-top: 'maximum' should not be valid under
{'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum',
'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:
properties:qcom,phy-rescode-offset-top: 'minimum' should not be valid under
{'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum',
'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:
properties:qcom,phy-rescode-offset-top: 'maximum' should not be valid under
{'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum',
'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords
Re: [PATCH 2/2] dt-bindings: msm: disp: add yaml schemas for QCM2290 DPU bindings
On Tue, 18 Jan 2022 16:47:34 +0100, Loic Poulain wrote: > QCM2290 MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks > like DPU display controller, DSI etc. Add YAML schema for DPU device > tree bindings > > Signed-off-by: Loic Poulain > --- > .../bindings/display/msm/dpu-qcm2290.yaml | 214 > + > 1 file changed, 214 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/msm/dpu-qcm2290.example.dts:19:18: fatal error: dt-bindings/clock/qcom,dispcc-qcm2290.h: No such file or directory 19 | #include | ^ compilation terminated. make[1]: *** [scripts/Makefile.lib:373: Documentation/devicetree/bindings/display/msm/dpu-qcm2290.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1413: dt_binding_check] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1581387 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [Freedreno] [PATCH v2 1/2] drm/msm/dpu: simplify clocks handling
On 11/25/2021 6:35 PM, Dmitry Baryshkov wrote:
DPU driver contains code to parse clock items from device tree into
special data struct and then enable/disable/set rate for the clocks
using that data struct. However the DPU driver itself uses only parsing
and enabling/disabling part (the rate setting is used by DP driver).
Move this implementation to the DP driver (which actually uses rate
setting) and replace hand-coded enable/disable/get loops in the DPU
with the respective clk_bulk operations. Put operation is removed
completely because, it is handled using devres instead.
DP implementation is unchanged for now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 24 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 6 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 46 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 26 +++
.../dpu1/dpu_io_util.c => dp/dp_clk_util.c} | 69 +--
.../dpu1/dpu_io_util.h => dp/dp_clk_util.h} | 2 -
drivers/gpu/drm/msm/dp/dp_parser.h| 2 +-
drivers/gpu/drm/msm/msm_drv.c | 49 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
11 files changed, 84 insertions(+), 147 deletions(-)
rename drivers/gpu/drm/msm/{disp/dpu1/dpu_io_util.c => dp/dp_clk_util.c} (61%)
rename drivers/gpu/drm/msm/{disp/dpu1/dpu_io_util.h => dp/dp_clk_util.h} (92%)
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 40577f8856d8..b6637da219b0 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -69,7 +69,6 @@ msm-y := \
disp/dpu1/dpu_hw_top.o \
disp/dpu1/dpu_hw_util.o \
disp/dpu1/dpu_hw_vbif.o \
- disp/dpu1/dpu_io_util.o \
disp/dpu1/dpu_kms.o \
disp/dpu1/dpu_mdss.o \
disp/dpu1/dpu_plane.o \
@@ -105,6 +104,7 @@ msm-$(CONFIG_DRM_MSM_GPU_STATE) +=
adreno/a6xx_gpu_state.o
msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_catalog.o \
+ dp/dp_clk_util.o \
dp/dp_ctrl.o \
dp/dp_display.o \
dp/dp_drm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 60fe06018581..4d184122d63e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
}
}
-static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
-{
- struct dss_clk *core_clk = kms->perf.core_clk;
-
- if (core_clk->max_rate && (rate > core_clk->max_rate))
- rate = core_clk->max_rate;
-
- core_clk->rate = rate;
- return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
-}
-
static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
{
u64 clk_rate = kms->perf.perf_tune.min_core_clk;
@@ -306,7 +295,7 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms
*kms)
dpu_cstate = to_dpu_crtc_state(crtc->state);
clk_rate = max(dpu_cstate->new_perf.core_clk_rate,
clk_rate);
- clk_rate = clk_round_rate(kms->perf.core_clk->clk,
+ clk_rate = clk_round_rate(kms->perf.core_clk,
clk_rate);
}
}
@@ -405,10 +394,11 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
- ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
+ if (clk_rate > kms->perf.max_core_clk_rate)
+ clk_rate = kms->perf.max_core_clk_rate;
+ ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
if (ret) {
- DPU_ERROR("failed to set %s clock rate %llu\n",
- kms->perf.core_clk->clk_name, clk_rate);
+ DPU_ERROR("failed to set core clock rate %llu\n",
clk_rate);
return ret;
}
@@ -529,13 +519,13 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
- struct dss_clk *core_clk)
+ struct clk *core_clk)
{
perf->dev = dev;
perf->catalog = catalog;
perf->core_clk = core_clk;
- perf->max_core_clk_rate = core_clk->max_rate;
+ perf->max_core_clk_rate = clk_get_rate(core_clk);
if (!perf->max_core_clk_rate) {
DPU_DEBUG("optional max core clk rate, use default\n");
perf->max_core_clk_rate = DPU_PERF_DEFAULT_MAX_CORE_CLK_R
[PATCH v2] phy: dphy: Correct clk_pre parameter
The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE
parameter's unit is Unit Interval(UI) and the minimum value is 8. Also,
kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy
mentions that it should be in UI. However, the dphy core driver wrongly
sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds.
And, the kernel doc of the 'clk_pre' member wrongly says the minimum value
is '8 UI', instead of 8.
So, let's fix both the dphy core driver and the kernel doc of the 'clk_pre'
member to correctly reflect the T-CLK-PRE parameter's unit and the minimum
value according to the D-PHY specification.
I'm assuming that all impacted custom drivers shall program values in
TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY
specification mentions that the frequency of TxByteClkHS is exactly 1/8
the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant
custom driver code is changed to program those values as
DIV_ROUND_UP(cfg->clk_pre, BITS_PER_BYTE), then.
Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK.
Help is needed to test with other i.MX8mq, Meson and Rockchip platforms,
as I don't have the hardwares.
Fixes: 2ed869990e14 ("phy: Add MIPI D-PHY configuration options")
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Cc: David Airlie
Cc: Daniel Vetter
Cc: Kishon Vijay Abraham I
Cc: Vinod Koul
Cc: Kevin Hilman
Cc: Jerome Brunet
Cc: Martin Blumenstingl
Cc: Heiko Stuebner
Cc: Maxime Ripard
Cc: Guido Günther
Tested-by: Liu Ying # RM67191 DSI panel on i.MX8mq EVK
Signed-off-by: Liu Ying
---
v1->v2:
* Use BITS_PER_BYTE macro. (Andrzej)
* Drop dsi argument from ui2bc() in nwl-dsi.c.
drivers/gpu/drm/bridge/nwl-dsi.c | 12 +---
drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c| 3 ++-
drivers/phy/phy-core-mipi-dphy.c | 4 ++--
drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 3 ++-
include/linux/phy/phy-mipi-dphy.h| 2 +-
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a7389a0facfb..af07eeb47ca0 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -196,12 +197,9 @@ static u32 ps2bc(struct nwl_dsi *dsi, unsigned long long
ps)
/*
* ui2bc - UI time periods to byte clock cycles
*/
-static u32 ui2bc(struct nwl_dsi *dsi, unsigned long long ui)
+static u32 ui2bc(unsigned int ui)
{
- u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
-
- return DIV64_U64_ROUND_UP(ui * dsi->lanes,
- dsi->mode.clock * 1000 * bpp);
+ return DIV_ROUND_UP(ui, BITS_PER_BYTE);
}
/*
@@ -232,12 +230,12 @@ static int nwl_dsi_config_host(struct nwl_dsi *dsi)
}
/* values in byte clock cycles */
- cycles = ui2bc(dsi, cfg->clk_pre);
+ cycles = ui2bc(cfg->clk_pre);
DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_pre: 0x%x\n", cycles);
nwl_dsi_write(dsi, NWL_DSI_CFG_T_PRE, cycles);
cycles = ps2bc(dsi, cfg->lpx + cfg->clk_prepare + cfg->clk_zero);
DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap (pre): 0x%x\n", cycles);
- cycles += ui2bc(dsi, cfg->clk_pre);
+ cycles += ui2bc(cfg->clk_pre);
DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_post: 0x%x\n", cycles);
nwl_dsi_write(dsi, NWL_DSI_CFG_T_POST, cycles);
cycles = ps2bc(dsi, cfg->hs_exit);
diff --git a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
index cd2332bf0e31..fdbd64c03e12 100644
--- a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
+++ b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -250,7 +251,7 @@ static int phy_meson_axg_mipi_dphy_power_on(struct phy *phy)
(DIV_ROUND_UP(priv->config.clk_zero, temp) << 16) |
(DIV_ROUND_UP(priv->config.clk_prepare, temp) << 24));
regmap_write(priv->regmap, MIPI_DSI_CLK_TIM1,
-DIV_ROUND_UP(priv->config.clk_pre, temp));
+DIV_ROUND_UP(priv->config.clk_pre, BITS_PER_BYTE));
regmap_write(priv->regmap, MIPI_DSI_HS_TIM,
DIV_ROUND_UP(priv->config.hs_exit, temp) |
diff --git a/drivers/phy/phy-core-mipi-dphy.c b/drivers/phy/phy-core-mipi-dphy.c
index 288c9c67aa74..ccb4045685cd 100644
--- a/drivers/phy/phy-core-mipi-dphy.c
+++ b/drivers/phy/phy-core-mipi-dphy.c
@@ -36,7 +36,7 @@ int phy_mipi_dphy_get_default_config(unsigned long
pixel_clock,
cfg->clk_miss = 0;
cfg->clk_post = 6 + 52 * ui;
- cfg->clk_pre = 8000;
+ cfg->clk_pre = 8;
cfg->clk_prepare = 38000;
cfg->clk_settle = 95000;
cf
Re: [RFC PATCH v3 2/3] drm: add support modifiers for drivers whose planes only support linear layout
On 2022/01/18 18:53, Andy Shevchenko wrote:
On Mon, Jan 17, 2022 at 02:15:48PM +0900, Esaki Tomohito wrote:
On 2022/01/14 23:16, Andy Shevchenko wrote:
On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers.
...
+ const uint64_t default_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+ Comma?
There is no mention in the coding style about adding/removing a comma to the
last element of an array. Is there a policy in drm driver?
I think the advantage of adding a comma to the last element of an array is
that diff is only one line when an element is added to the end.
However since INVALID is always the last element in the modifiers array, I
think it can be either in this case.
If there is a policy, I will match it.
Indeed, but there is a common sense. The idea behind (multi-line) definitions
that when next time somebody will add an element in the array, there are will
be:
a) no additional churn (like in case of this patch, if the item will be added
at the bottom;
b) an element that may not be added behind the terminator, which will look
weird.
That said, the question is if the element is terminator one or not, if not,
comma is better than no comma and vise versa.
Ah I see. In this case, DRM_FORMAT_MOD_INVALID is terminator, so it
should not have a comma.
Thanks
Tomohito Esaki
Re: [PATCH] drm/vmwgfx: Stop requesting the pci regions
On Tue, 2022-01-18 at 20:00 +0100, Javier Martinez Canillas wrote:
> Hello Zack,
>
> On 1/17/22 19:03, Zack Rusin wrote:
> > From: Zack Rusin
> >
> > When sysfb_simple is enabled loading vmwgfx fails because the regions
> > are held by the platform. In that case
> > remove_conflicting*_framebuffers
> > only removes the simplefb but not the regions held by sysfb.
> >
>
> Indeed, that's an issue. I wonder if we should drop the IORESOURCE_BUSY
> flag from the memory resource added to the "simple-framebuffer" device
> ?
I think this is one of those cases where it depends on what we plan to
do after that. Sementically it makes sense to have it in there - the
framebuffer memory is claimed by the "simple-framebuffer" and it's
busy, it's just that it creates issues for drivers after unloading. I
think removing it, while making things easier for drivers, would be
confusing for people reading the code later, unless there's some kind
of cleanup that would happen with it (e.g. removing IORESOURCE_BUSY
altogether and making the drm drivers properly request their
resources). At least by itself it doesn't seem to be much better
solution than having the drm drivers not call pci_request_region[s],
which apart from hyperv and cirrus (iirc bochs does it for resources
other than fb which wouldn't have been claimed by "simple-framebuffer")
is already the case.
I do think we should do one of them to make the codebase coherent:
either remove IORESOURCE_BUSY from "simple-framebuffer" or remove
pci_request_region[s] from hyperv and cirrus.
> > Like the other drm drivers we need to stop requesting all the pci
> > regions
> > to let the driver load with platform code enabled.
> > This allows vmwgfx to load correctly on systems with sysfb_simple
> > enabled.
> >
>
> I read this very interesting thread from two years ago:
>
> https://lkml.org/lkml/2020/11/5/248
>
> Maybe is worth mentioning in the commit message what Daniel said there,
> that is that only a few DRM drivers request explicitly the PCI regions
> and the only reliable approach is for bus drivers to claim these.
Ah, great point. I'll update the commit log with that.
> > Signed-off-by: Zack Rusin
> > Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64")
> > Cc: dri-devel@lists.freedesktop.org
> > Cc:
> > Reviewed-by: Martin Krastev
> > ---
>
> The patch looks good to me, thanks a lot for fixing this:
>
> Reviewed-by: Javier Martinez Canillas
Thanks for taking a look at this, I appreciate it!
z
Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs
On Tue, 2022-01-18 at 20:58 -0500, Lyude Paul wrote:
> Hey - so, the original issue here was that payloads were not always deleted
> when we expected them to be - correct?
>
> If I'm remembering that correctly, then (and I'm not 100% sure on this yet)
> I
> might already have noticed something very possibly wonky in how we handle
> payload allocations currently, that I found while working on the non-atomic
> removal branch that I linked to you in my previous response. Basically, in
> the
> step1() function it looks like that we follow this general flow with
> updating
> payloads:
>
> * Loop through proposed payloads and compare to previously programmed
> payloads
> - If a payload has a different allocation then it previously did, update
> the
> payload
> - If the payload is new, create it
> - If a payload no longer has an allocation, remove the payload
>
> At first glance this seems totally correct - but I'm not actually entirely
> convinced it is? Particularly because it seems like the order in which we do
> creation/deletion of payloads is totally arbitrary. To explain what I mean
> by
> that, consider a state transition like this:
>
> vcpi_slots=15 vcpi_slots=35 vcpi_slots=14
> > 1 | 2 ||
Ugh, sorry - email client messed this up. This was supposed to look like this:
vcpi_slots=15 vcpi_slots=35vcpi_slots=14
F|1 |2 |x|
>
> Let's say we want to increase payload #1 from 15 to 50, and disable payload
> #2
> in the same atomic commit on DRM's side. If the order we update payloads is
> entirely arbitrary, we could end up doing this:
>
> * Increase VCPI slots payload #1 from 15->50 (total VCPI slots=99,
> overflow!)
> * Decrease VCPI slots payload #2 from 35->0 (total VCPI slots=50)
>
> Notice on the first step, we've technically overflowed the available number
> of
> VCPI slots in the payload table. This is still before step 2 though, and I
> could be totally wrong here - perhaps this is entirely OK in the real world,
> and we're allowed to overflow VC slots as long as we repair the issue before
> step 2. But so far I can't seem to find anything in the DP 2.0 spec that
> explicitly states this would be OK - which makes me think we might fail some
> payload allocations if we don't always ensure we avoid overflows in between
> VC
> payload table changes. Note that avoiding overflows would be as simple as
> just
> making sure we send all VC payload table changes that free VC slots before
> sending any that take new slots.
>
> Again - I haven't actually confirmed this yet and am hoping to test stuff
> like
> this very soon as I'm pretty close finishing up the initial attempt at
> removing the non-atomic MST code in the DRM helpers now. If my theory ends
> up
> being correct here, I can fix this in my rewrite of the MST payload
> management
> code. But I figured it might be worth mentioning in the mean time in case
> you
> think it might be relevant to the problem here :).
>
> On Wed, 2022-01-12 at 16:47 -0500, Lyude Paul wrote:
> > (CC'ing this to dri-devel, since this is basically patch review)
> >
> > Alright - so first off sorry about the broken debugging patch! I thought I
> > had
> > tested that but I guess I hadn't tested it well enough, I'll get it fixed
> > asap, but feel free to try getting to it before I do.
> >
> > As for this patch… (comments below)
> >
> > On Mon, 2021-12-20 at 02:17 +, Lin, Wayne wrote:
> > > [AMD Official Use Only]
> > >
> > > Hi Lyude,
> > >
> > > No rush and thanks for your time! : )
> > > Just want to help clarify what I mean that "registering a callback
> > > function"
> > > for CSN of disconnecting
> > > stream sink device (not mst branch case). Attach below the tentative
> > > patch
> > > that I planned to do. Thanks so much!
> > >
> > > Regards,
> > > Wayne
> > > ---
> > > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 53 +++
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 16 +-
> > > include/drm/drm_dp_mst_helper.h | 1 +
> > > 3 files changed, 68 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > > index cc34a35d0bcb..d7343c64908c 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > > @@ -472,8 +472,61 @@ dm_dp_add_mst_connector(struct
> > > drm_dp_mst_topology_mgr
> > > *mgr,
> > > return connector;
> > > }
> > >
> > > +void dm_dp_notify_csn_disconnection(struct drm_connector *connector)
> > > +{
> > > + struct amdgpu_dm_connector *aconnector =
> > > + to_amdgpu_dm_connector(connector);
> > > + struct dc_sink *dc_sink = aconnector->dc_sink;
> > > + struct dc_link *dc_link = aconnector->dc_link;
> > > + struct amdgpu_device *adev = drm_to_adev(ddev);
Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs
Hey - so, the original issue here was that payloads were not always deleted
when we expected them to be - correct?
If I'm remembering that correctly, then (and I'm not 100% sure on this yet) I
might already have noticed something very possibly wonky in how we handle
payload allocations currently, that I found while working on the non-atomic
removal branch that I linked to you in my previous response. Basically, in the
step1() function it looks like that we follow this general flow with updating
payloads:
* Loop through proposed payloads and compare to previously programmed
payloads
- If a payload has a different allocation then it previously did, update the
payload
- If the payload is new, create it
- If a payload no longer has an allocation, remove the payload
At first glance this seems totally correct - but I'm not actually entirely
convinced it is? Particularly because it seems like the order in which we do
creation/deletion of payloads is totally arbitrary. To explain what I mean by
that, consider a state transition like this:
vcpi_slots=15 vcpi_slots=35 vcpi_slots=14
| 1 | 2 ||
Let's say we want to increase payload #1 from 15 to 50, and disable payload #2
in the same atomic commit on DRM's side. If the order we update payloads is
entirely arbitrary, we could end up doing this:
* Increase VCPI slots payload #1 from 15->50 (total VCPI slots=99, overflow!)
* Decrease VCPI slots payload #2 from 35->0 (total VCPI slots=50)
Notice on the first step, we've technically overflowed the available number of
VCPI slots in the payload table. This is still before step 2 though, and I
could be totally wrong here - perhaps this is entirely OK in the real world,
and we're allowed to overflow VC slots as long as we repair the issue before
step 2. But so far I can't seem to find anything in the DP 2.0 spec that
explicitly states this would be OK - which makes me think we might fail some
payload allocations if we don't always ensure we avoid overflows in between VC
payload table changes. Note that avoiding overflows would be as simple as just
making sure we send all VC payload table changes that free VC slots before
sending any that take new slots.
Again - I haven't actually confirmed this yet and am hoping to test stuff like
this very soon as I'm pretty close finishing up the initial attempt at
removing the non-atomic MST code in the DRM helpers now. If my theory ends up
being correct here, I can fix this in my rewrite of the MST payload management
code. But I figured it might be worth mentioning in the mean time in case you
think it might be relevant to the problem here :).
On Wed, 2022-01-12 at 16:47 -0500, Lyude Paul wrote:
> (CC'ing this to dri-devel, since this is basically patch review)
>
> Alright - so first off sorry about the broken debugging patch! I thought I
> had
> tested that but I guess I hadn't tested it well enough, I'll get it fixed
> asap, but feel free to try getting to it before I do.
>
> As for this patch… (comments below)
>
> On Mon, 2021-12-20 at 02:17 +, Lin, Wayne wrote:
> > [AMD Official Use Only]
> >
> > Hi Lyude,
> >
> > No rush and thanks for your time! : )
> > Just want to help clarify what I mean that "registering a callback
> > function"
> > for CSN of disconnecting
> > stream sink device (not mst branch case). Attach below the tentative patch
> > that I planned to do. Thanks so much!
> >
> > Regards,
> > Wayne
> > ---
> > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 53 +++
> > drivers/gpu/drm/drm_dp_mst_topology.c | 16 +-
> > include/drm/drm_dp_mst_helper.h | 1 +
> > 3 files changed, 68 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index cc34a35d0bcb..d7343c64908c 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -472,8 +472,61 @@ dm_dp_add_mst_connector(struct
> > drm_dp_mst_topology_mgr
> > *mgr,
> > return connector;
> > }
> >
> > +void dm_dp_notify_csn_disconnection(struct drm_connector *connector)
> > +{
> > + struct amdgpu_dm_connector *aconnector =
> > + to_amdgpu_dm_connector(connector);
> > + struct dc_sink *dc_sink = aconnector->dc_sink;
> > + struct dc_link *dc_link = aconnector->dc_link;
> > + struct amdgpu_device *adev = drm_to_adev(ddev);
> > +
> > + ASSERT(dc_link);
> > +
> > + if (dc_sink) {
> > + mutex_lock(&adev->dm.dc_lock);
> > +
> > + /*clear the remote sink of the link*/
> > + dc_link_remove_remote_sink(dc_link, dc_sink);
> > + dc_sink_release(dc_sink);
> > + aconnector->dc_sink = NULL;
> > +
> > + mutex_unlock(&adev->dm.dc_lock);
> > + }
> > +}
> > +
> > static const struct drm_dp_
[PATCH] dt-bindings: Drop unnecessary pinctrl properties
For a single pinctrl mode, it is not necessary to define pinctrl properties as the tools always allow pinctrl properties. Signed-off-by: Rob Herring --- .../display/rockchip/rockchip,rk3066-hdmi.yaml | 8 Documentation/devicetree/bindings/input/gpio-keys.yaml | 6 -- .../devicetree/bindings/pinctrl/cirrus,lochnagar.yaml | 9 - .../devicetree/bindings/pinctrl/cirrus,madera.yaml | 10 -- .../devicetree/bindings/sound/samsung-i2s.yaml | 6 -- 5 files changed, 39 deletions(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml index 008c144257cb..1a68a940d165 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml @@ -26,14 +26,6 @@ properties: clock-names: const: hclk - pinctrl-0: -maxItems: 2 - - pinctrl-names: -const: default -description: - Switch the iomux for the HPD/I2C pins to HDMI function. - power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/input/gpio-keys.yaml b/Documentation/devicetree/bindings/input/gpio-keys.yaml index dbe7ecc19ccb..7fe1966ea28a 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys.yaml +++ b/Documentation/devicetree/bindings/input/gpio-keys.yaml @@ -88,12 +88,6 @@ patternProperties: which can be disabled to suppress events from the button. type: boolean -pinctrl-0: - maxItems: 1 - -pinctrl-names: - maxItems: 1 - required: - linux,code diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml index 80020539c3bb..5cd512b7d5ba 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml @@ -51,15 +51,6 @@ properties: appropriate of the LOCHNAGARx_PIN_NUM_GPIOS define, see [3]. maxItems: 1 - pinctrl-0: -description: - A phandle to the default pinctrl state. - - pinctrl-names: -description: - A pinctrl state named "default" must be defined. -const: default - pin-settings: type: object patternProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml index e50d7ad5c229..c85f759ae5a3 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml @@ -30,16 +30,6 @@ description: | Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt properties: - pinctrl-0: -description: - A phandle to the node containing the subnodes containing default - configurations. - - pinctrl-names: -description: - A pinctrl state named "default" must be defined. -const: default - pin-settings: description: One subnode is required to contain the default settings. It diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml index 2e3628ef48df..84c4d6cba521 100644 --- a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml @@ -110,12 +110,6 @@ properties: Internal DMA register base address of the audio subsystem (used in secondary sound source). - pinctrl-0: -description: Should specify pin control groups used for this controller. - - pinctrl-names: -const: default - power-domains: maxItems: 1 -- 2.32.0
[PATCH] dt-bindings: Improve phandle-array schemas
The 'phandle-array' type is a bit ambiguous. It can be either just an array of phandles or an array of phandles plus args. Many schemas for phandle-array properties aren't clear in the schema which case applies though the description usually describes it. The array of phandles case boils down to needing: items: maxItems: 1 The phandle plus args cases should typically take this form: items: - items: - description: A phandle - description: 1st arg cell - description: 2nd arg cell With this change, some examples need updating so that the bracketing of property values matches the schema. Cc: Damien Le Moal Cc: Herbert Xu Cc: "David S. Miller" Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Laurent Pinchart Cc: Kieran Bingham Cc: Vinod Koul Cc: Georgi Djakov Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Joerg Roedel Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Pavel Machek Cc: Mauro Carvalho Chehab Cc: Krzysztof Kozlowski Cc: Jakub Kicinski Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: Andrew Lunn Cc: Vivien Didelot Cc: Florian Fainelli Cc: Vladimir Oltean Cc: Kalle Valo Cc: Viresh Kumar Cc: Stephen Boyd Cc: Kishon Vijay Abraham I Cc: Linus Walleij Cc: "Rafael J. Wysocki" Cc: Kevin Hilman Cc: Ulf Hansson Cc: Sebastian Reichel Cc: Mark Brown Cc: Mathieu Poirier Cc: Daniel Lezcano Cc: Zhang Rui Cc: Greg Kroah-Hartman Cc: Thierry Reding Cc: Jonathan Hunter Cc: Sudeep Holla Cc: Geert Uytterhoeven Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: dmaeng...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: io...@lists.linux-foundation.org Cc: linux-l...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-wirel...@vger.kernel.org Cc: linux-...@lists.infradead.org Cc: linux-g...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: linux-remotep...@vger.kernel.org Cc: alsa-de...@alsa-project.org Cc: linux-...@vger.kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/cpus.yaml | 2 + .../devicetree/bindings/arm/idle-states.yaml | 80 +-- .../devicetree/bindings/arm/pmu.yaml | 2 + .../bindings/ata/sata_highbank.yaml | 3 + .../bus/allwinner,sun50i-a64-de2.yaml | 5 +- .../bindings/crypto/intel,ixp4xx-crypto.yaml | 15 +++- .../allwinner,sun4i-a10-display-engine.yaml | 2 + .../display/mediatek/mediatek,hdmi.yaml | 5 +- .../devicetree/bindings/display/msm/gpu.yaml | 2 + .../bindings/display/renesas,du.yaml | 10 ++- .../display/rockchip/rockchip-drm.yaml| 2 + .../display/sprd/sprd,display-subsystem.yaml | 2 + .../bindings/display/ti/ti,am65x-dss.yaml | 3 +- .../devicetree/bindings/dma/dma-router.yaml | 2 + .../bindings/dma/st,stm32-dmamux.yaml | 2 +- .../bindings/dvfs/performance-domain.yaml | 1 - .../bindings/interconnect/qcom,rpmh.yaml | 2 + .../interrupt-controller/arm,gic-v3.yaml | 6 +- .../interrupt-controller/ti,sci-inta.yaml | 2 + .../bindings/iommu/mediatek,iommu.yaml| 6 +- .../bindings/iommu/renesas,ipmmu-vmsa.yaml| 6 ++ .../leds/backlight/led-backlight.yaml | 2 + .../allwinner,sun4i-a10-video-engine.yaml | 4 + .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 10 +-- .../devicetree/bindings/media/ti,cal.yaml | 4 + .../memory-controllers/mediatek,smi-larb.yaml | 2 +- .../samsung,exynos5422-dmc.yaml | 2 + .../net/allwinner,sun4i-a10-emac.yaml | 4 + .../bindings/net/can/bosch,c_can.yaml | 8 +- .../bindings/net/can/fsl,flexcan.yaml | 12 +-- .../devicetree/bindings/net/dsa/dsa-port.yaml | 2 + .../devicetree/bindings/net/fsl,fec.yaml | 8 +- .../bindings/net/intel,ixp4xx-ethernet.yaml | 15 +++- .../bindings/net/intel,ixp4xx-hss.yaml| 33 ++-- .../bindings/net/nxp,dwmac-imx.yaml | 4 + .../bindings/net/socionext,uniphier-ave4.yaml | 4 + .../devicetree/bindings/net/stm32-dwmac.yaml | 4 + .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 5 ++ .../bindings/net/wireless/mediatek,mt76.yaml | 4 + .../devicetree/bindings/opp/opp-v2-base.yaml | 2 + .../devicetree/bindings/perf/arm,dsu-pmu.yaml | 2 + .../bindings/phy/intel,combo-phy.yaml | 8 ++ .../devicetree/bindings/phy/ti,omap-usb2.yaml | 4 + .../pinctrl/aspeed,ast2500-pinctrl.yaml | 2 + .../bindings/pinctrl/canaan,k210-fpioa.yaml | 4 + .../pinctrl/mediatek,mt65xx-pinctrl.yaml | 2 + .../bindings/pinctrl/st,stm32-pinctrl.yaml| 10 ++- .../bindings/power/power-domain.yaml | 4 + .../bindings/power/renesas,apmu.yaml | 2 + .../power/rockchip,power-controller.yaml | 2 + .../bindings/power/supply/cw2015_battery.yaml | 6 +- .../bindings/power/supply/power-supply.yaml | 2 + .../bindings/regulator/regulator.yaml | 2 + .../bindings/regulato
Re: [PATCH 3/3] drm/i915/guc: Flush G2H handler during a GT reset
On 1/18/2022 13:43, Matthew Brost wrote:
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which is turn depends on resets) we
s/is/in/
With that fixed:
Reviewed-by: John Harrison
John.
can safely flush the G2H handler during a GT reset. This is eliminates
corner cases where GuC generated G2H (e.g. engine resets) race with a GT
reset.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index cdd8d691251ff..1a11e8986948b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1396,8 +1396,6 @@ static void guc_flush_destroyed_contexts(struct intel_guc
*guc);
void intel_guc_submission_reset_prepare(struct intel_guc *guc)
{
- int i;
-
if (unlikely(!guc_submission_initialized(guc))) {
/* Reset called during driver load? GuC not yet initialised! */
return;
@@ -1414,21 +1412,7 @@ void intel_guc_submission_reset_prepare(struct intel_guc
*guc)
guc_flush_submissions(guc);
guc_flush_destroyed_contexts(guc);
-
- /*
-* Handle any outstanding G2Hs before reset. Call IRQ handler directly
-* each pass as interrupt have been disabled. We always scrub for
-* outstanding G2H as it is possible for outstanding_submission_g2h to
-* be incremented after the context state update.
-*/
- for (i = 0; i < 4 && atomic_read(&guc->outstanding_submission_g2h);
++i) {
- intel_guc_to_host_event_handler(guc);
-#define wait_for_reset(guc, wait_var) \
- intel_guc_wait_for_pending_msg(guc, wait_var, false, (HZ / 20))
- do {
- wait_for_reset(guc, &guc->outstanding_submission_g2h);
- } while (!list_empty(&guc->ct.requests.incoming));
- }
+ flush_work(&guc->ct.requests.worker);
scrub_guc_desc_for_outstanding_g2h(guc);
}
Re: [PATCH 2/3] drm/i915/guc: Add work queue to trigger a GT reset
On 1/18/2022 13:43, Matthew Brost wrote:
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT when a engine reset failure is received to break this
s/a/an/
circular dependency.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 23 +++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 9d26a86fe557a..60ea8deef5392 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -119,6 +119,11 @@ struct intel_guc {
* function as it might be in an atomic context (no sleeping)
*/
struct work_struct destroyed_worker;
+ /**
+* @reset_worker: worker to trigger a GT reset after an engine
+* reset fails
+*/
+ struct work_struct reset_worker;
} submission_state;
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 23a40f10d376d..cdd8d691251ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1746,6 +1746,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
*guc)
}
static void destroyed_worker_func(struct work_struct *w);
+static void reset_worker_func(struct work_struct *w);
/*
* Set up the memory resources to be shared with the GuC (via the GGTT)
@@ -1776,6 +1777,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
INIT_LIST_HEAD(&guc->submission_state.destroyed_contexts);
INIT_WORK(&guc->submission_state.destroyed_worker,
destroyed_worker_func);
+ INIT_WORK(&guc->submission_state.reset_worker,
+ reset_worker_func);
guc->submission_state.guc_ids_bitmap =
bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
@@ -4052,6 +4055,17 @@ guc_lookup_engine(struct intel_guc *guc, u8 guc_class,
u8 instance)
return gt->engine_class[engine_class][instance];
}
+static void reset_worker_func(struct work_struct *w)
+{
+ struct intel_guc *guc = container_of(w, struct intel_guc,
+submission_state.reset_worker);
+ struct intel_gt *gt = guc_to_gt(guc);
+
+ intel_gt_handle_error(gt, ALL_ENGINES,
+ I915_ERROR_CAPTURE,
+ "GuC failed to reset a engine\n");
s/a/an/
+}
+
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len)
{
@@ -4083,10 +4097,11 @@ int intel_guc_engine_failure_process_msg(struct
intel_guc *guc,
drm_err(>->i915->drm, "GuC engine reset request failed on %d:%d (%s)
because 0x%08X",
guc_class, instance, engine->name, reason);
- intel_gt_handle_error(gt, engine->mask,
- I915_ERROR_CAPTURE,
- "GuC failed to reset %s (reason=0x%08x)\n",
- engine->name, reason);
The engine name and reason code are lost from the error capture? I guess
we still get it in the drm_err above, though. So probably not an issue.
We shouldn't be getting these from end users and any internal CI run is
only likely to give us the dmesg, not the error capture anyway! However,
still seems like it is work saving engine->mask in the submission_state
structure (ORing in, in case there are multiple resets). Clearing it
should be safe because once a GT reset has happened, we aren't getting
any more G2Hs. And we can't have multiple message handlers running
concurrently, right? So no need to protect the OR either.
John.
+ /*
+* A GT reset flushes this worker queue (G2H handler) so we must use
+* another worker to trigger a GT reset.
+*/
+ queue_work(system_unbound_wq, &guc->submission_state.reset_worker);
return 0;
}
Re: [PATCH 1/3] drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
On 1/18/2022 13:43, Matthew Brost wrote:
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL do fully decouple the error capture from fence signalling.
s/do/to/
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Does this really count as a bug fix over that patch? Isn't it more of a
changing in policy now that we do DRM fence signalling and that other
changes related to error capture behaviour have been implemented.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 67f3515f07e7a..aee42eae4729f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1516,7 +1516,7 @@ capture_engine(struct intel_engine_cs *engine,
struct i915_request *rq = NULL;
unsigned long flags;
- ee = intel_engine_coredump_alloc(engine, GFP_KERNEL);
+ ee = intel_engine_coredump_alloc(engine, ALLOW_FAIL);
This still makes me nervous that we will fail to allocate engine
captures in stress test scenarios, which are exactly the kind of
situations where we need valid error captures.
There is also still a GFP_KERNEL in __i915_error_grow(). Doesn't that
need updating as well?
John.
if (!ee)
return NULL;
Re: [PATCH] drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct
On 1/12/2022 21:59, Matthew Brost wrote:
Realized that the GuC multi-lrc fini breadcrumb emit code is very
delicate as the math this code does relies on functions it calls to emit
a certain number of DWs. Add a few GEM_BUG_ONs to assert the math is
correct.
Signed-off-by: Matthew Brost
Looks good. There was a checkpatch warning about blank lines. With that
fixed:
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 32 +++
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 3ae92260f8224..d562d85f96871 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4493,27 +4493,31 @@ static inline bool skip_handshake(struct i915_request
*rq)
return test_bit(I915_FENCE_FLAG_SKIP_PARALLEL, &rq->fence.flags);
}
+#define NON_SKIP_LEN 6
static u32 *
emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
u32 *cs)
{
struct intel_context *ce = rq->context;
+ __maybe_unused u32 *before_fini_breadcrumb_user_interrupt_cs;
+ __maybe_unused u32 *start_fini_breadcrumb_cs = cs;
GEM_BUG_ON(!intel_context_is_parent(ce));
if (unlikely(skip_handshake(rq))) {
/*
* NOP everything in
__emit_fini_breadcrumb_parent_no_preempt_mid_batch,
-* the -6 comes from the length of the emits below.
+* the NON_SKIP_LEN comes from the length of the emits below.
*/
memset(cs, 0, sizeof(u32) *
- (ce->engine->emit_fini_breadcrumb_dw - 6));
- cs += ce->engine->emit_fini_breadcrumb_dw - 6;
+ (ce->engine->emit_fini_breadcrumb_dw - NON_SKIP_LEN));
+ cs += ce->engine->emit_fini_breadcrumb_dw - NON_SKIP_LEN;
} else {
cs = __emit_fini_breadcrumb_parent_no_preempt_mid_batch(rq, cs);
}
/* Emit fini breadcrumb */
+ before_fini_breadcrumb_user_interrupt_cs = cs;
cs = gen8_emit_ggtt_write(cs,
rq->fence.seqno,
i915_request_active_timeline(rq)->hwsp_offset,
@@ -4523,6 +4527,12 @@ emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct
i915_request *rq,
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_NOOP;
+ /* Ensure our math for skip + emit is correct */
+ GEM_BUG_ON(before_fini_breadcrumb_user_interrupt_cs + NON_SKIP_LEN !=
+ cs);
+ GEM_BUG_ON(start_fini_breadcrumb_cs +
+ ce->engine->emit_fini_breadcrumb_dw != cs);
+
rq->tail = intel_ring_offset(rq, cs);
return cs;
@@ -4565,22 +4575,25 @@ emit_fini_breadcrumb_child_no_preempt_mid_batch(struct
i915_request *rq,
u32 *cs)
{
struct intel_context *ce = rq->context;
+ __maybe_unused u32 *before_fini_breadcrumb_user_interrupt_cs;
+ __maybe_unused u32 *start_fini_breadcrumb_cs = cs;
GEM_BUG_ON(!intel_context_is_child(ce));
if (unlikely(skip_handshake(rq))) {
/*
* NOP everything in
__emit_fini_breadcrumb_child_no_preempt_mid_batch,
-* the -6 comes from the length of the emits below.
+* the NON_SKIP_LEN comes from the length of the emits below.
*/
memset(cs, 0, sizeof(u32) *
- (ce->engine->emit_fini_breadcrumb_dw - 6));
- cs += ce->engine->emit_fini_breadcrumb_dw - 6;
+ (ce->engine->emit_fini_breadcrumb_dw - NON_SKIP_LEN));
+ cs += ce->engine->emit_fini_breadcrumb_dw - NON_SKIP_LEN;
} else {
cs = __emit_fini_breadcrumb_child_no_preempt_mid_batch(rq, cs);
}
/* Emit fini breadcrumb */
+ before_fini_breadcrumb_user_interrupt_cs = cs;
cs = gen8_emit_ggtt_write(cs,
rq->fence.seqno,
i915_request_active_timeline(rq)->hwsp_offset,
@@ -4590,10 +4603,17 @@ emit_fini_breadcrumb_child_no_preempt_mid_batch(struct
i915_request *rq,
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_NOOP;
+ /* Ensure our math for skip + emit is correct */
+ GEM_BUG_ON(before_fini_breadcrumb_user_interrupt_cs + NON_SKIP_LEN !=
+ cs);
+ GEM_BUG_ON(start_fini_breadcrumb_cs +
+ ce->engine->emit_fini_breadcrumb_dw != cs);
+
rq->tail = intel_ring_offset(rq, cs);
return cs;
}
+#undef NON_SKIP_LEN
static struct intel_context *
guc_create_virtual(struct intel_engine_cs **siblings, unsigned int count,
Re: [Freedreno] [PATCH v2 4/7] drm/msm/dpu: allow just single IRQ callback
one> On 2021-08-17 20:30, abhin...@codeaurora.org wrote: On 2021-06-17 15:20, Dmitry Baryshkov wrote: DPU interrupts code allows multiple callbacks per interrut. In reality /interrupt none of the interrupts is shared between blocks (and will probably never be). Drop support for registering multiple callbacks per interrupt to simplify interrupt handling code. Signed-off-by: Dmitry Baryshkov I need to check on why we had this design originally and we still do. the idx with which we are registering today can generate only one hw interrupt. But i am not sure if something for planned for future use. Will update in a day or two. meanwhile some comments and questions below. I did check internally on the original design of this and yes the plan was for other sub-modules to register for callbacks and that callback goes into the callback list. For example, lets say for some reason some other modules like the DSI want to register for the VSYNC interrupt, it can register for a callback and that will get added to the callback list. But, this never got used that way and even now there is only one callback per interrupt. We dont have a concrete use-case where we will need this in the future but like many other things, we cannot tell for certain. Since there is no concrete use-case where we might need this, if you would like to go ahead with this, please do. Once you address the other comments on this, I can ack this. --- drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 18 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 2 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 10 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 6 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 144 +++--- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 12 -- drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +- 9 files changed, 86 insertions(+), 134 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h index 90ae6c9ccc95..44ab97fb2964 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h @@ -46,10 +46,8 @@ u32 dpu_core_irq_read( * interrupt * @dpu_kms: DPU handle * @irq_idx: irq index - * @irq_cb:IRQ callback structure, containing callback function - * and argument. Passing NULL for irq_cb will unregister - * the callback for the given irq_idx - * This must exist until un-registration. + * @irq_cb:IRQ callback funcion. + * @irq_arg: IRQ callback argument. * @return:0 for success registering callback, otherwise failure * * This function supports registration of multiple callbacks for each interrupt. @@ -57,17 +55,16 @@ u32 dpu_core_irq_read( int dpu_core_irq_register_callback( struct dpu_kms *dpu_kms, int irq_idx, - struct dpu_irq_callback *irq_cb); + void (*irq_cb)(void *arg, int irq_idx), + void *irq_arg); /** * dpu_core_irq_unregister_callback - For unregistering callback function on IRQ * interrupt * @dpu_kms: DPU handle * @irq_idx: irq index - * @irq_cb:IRQ callback structure, containing callback function - * and argument. Passing NULL for irq_cb will unregister - * the callback for the given irq_idx - * This must match with registration. + * @irq_cb:IRQ callback funcion. /function this typo is there in multiple places + * @irq_arg: IRQ callback argument. * @return:0 for success registering callback, otherwise failure * * This function supports registration of multiple callbacks for each interrupt. @@ -75,7 +72,8 @@ int dpu_core_irq_register_callback( int dpu_core_irq_unregister_callback( struct dpu_kms *dpu_kms, int irq_idx, - struct dpu_irq_callback *irq_cb); + void (*irq_cb)(void *arg, int irq_idx), + void *irq_arg); /** * dpu_debugfs_core_irq_init - register core irq debugfs diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index 1c04b7cce43e..d3557b0f4db9 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -310,7 +310,7 @@ int dpu_encoder_helper_wait_for_irq(struct dpu_encoder_phys *phys_enc, phys_enc->hw_pp->idx - PINGPONG_0, atomic_read(wait_info->atomic_cnt)); local_irq_save(flags); - irq->cb.func(phys_enc, irq->irq_idx);
[PATCH] drm/edid: Support type 7 timings
Per VESA DisplayID Standard v2.0: Type VII Timing – Detailed Timing Data
Definitions were already provided as type I, but not used
Signed-off-by: Yaroslav Bolyukin
---
drivers/gpu/drm/drm_edid.c | 26 +-
include/drm/drm_displayid.h | 6 +++---
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 12893e7be..5fcefd9b5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5404,13 +5404,17 @@ u32 drm_add_display_info(struct drm_connector
*connector, const struct edid *edi
return quirks;
}
-static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device
*dev,
- struct
displayid_detailed_timings_1 *timings)
+static struct drm_display_mode *drm_mode_displayid_detailed_1_7(struct
drm_device *dev,
+ struct
displayid_detailed_timings_1_7 *timings,
+ bool type_7)
{
struct drm_display_mode *mode;
unsigned pixel_clock = (timings->pixel_clock[0] |
(timings->pixel_clock[1] << 8) |
(timings->pixel_clock[2] << 16)) + 1;
+ // type 7 allows higher precision pixel clock
+ if (!type_7)
+ pixel_clock *= 10;
unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1;
unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1;
unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8)
+ 1;
@@ -5426,7 +5430,7 @@ static struct drm_display_mode
*drm_mode_displayid_detailed(struct drm_device *d
if (!mode)
return NULL;
- mode->clock = pixel_clock * 10;
+ mode->clock = pixel_clock;
mode->hdisplay = hactive;
mode->hsync_start = mode->hdisplay + hsync;
mode->hsync_end = mode->hsync_start + hsync_width;
@@ -5449,10 +5453,12 @@ static struct drm_display_mode
*drm_mode_displayid_detailed(struct drm_device *d
return mode;
}
-static int add_displayid_detailed_1_modes(struct drm_connector *connector,
- const struct displayid_block *block)
+static int add_displayid_detailed_1_7_modes(struct drm_connector *connector,
+ const struct displayid_block *block,
+ bool type_7)
{
- struct displayid_detailed_timing_block *det = (struct
displayid_detailed_timing_block *)block;
+ struct displayid_detailed_timing_1_7_block *det =
+ (struct displayid_detailed_timing_1_7_block *)block;
int i;
int num_timings;
struct drm_display_mode *newmode;
@@ -5463,9 +5469,9 @@ static int add_displayid_detailed_1_modes(struct
drm_connector *connector,
num_timings = block->num_bytes / 20;
for (i = 0; i < num_timings; i++) {
- struct displayid_detailed_timings_1 *timings = &det->timings[i];
+ struct displayid_detailed_timings_1_7 *timings =
&det->timings[i];
- newmode = drm_mode_displayid_detailed(connector->dev, timings);
+ newmode = drm_mode_displayid_detailed_1_7(connector->dev,
timings, type_7);
if (!newmode)
continue;
@@ -5485,7 +5491,9 @@ static int add_displayid_detailed_modes(struct
drm_connector *connector,
displayid_iter_edid_begin(edid, &iter);
displayid_iter_for_each(block, &iter) {
if (block->tag == DATA_BLOCK_TYPE_1_DETAILED_TIMING)
- num_modes += add_displayid_detailed_1_modes(connector,
block);
+ num_modes +=
add_displayid_detailed_1_7_modes(connector, block, false);
+ else if (block->tag == DATA_BLOCK_2_TYPE_7_DETAILED_TIMING)
+ num_modes +=
add_displayid_detailed_1_7_modes(connector, block, true);
}
displayid_iter_end(&iter);
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
index 7ffbd9f7b..268ff5e1f 100644
--- a/include/drm/drm_displayid.h
+++ b/include/drm/drm_displayid.h
@@ -111,7 +111,7 @@ struct displayid_tiled_block {
u8 topology_id[8];
} __packed;
-struct displayid_detailed_timings_1 {
+struct displayid_detailed_timings_1_7 {
u8 pixel_clock[3];
u8 flags;
u8 hactive[2];
@@ -124,9 +124,9 @@ struct displayid_detailed_timings_1 {
u8 vsw[2];
} __packed;
-struct displayid_detailed_timing_block {
+struct displayid_detailed_timing_1_7_block {
struct displayid_block base;
- struct displayid_detailed_timings_1 timings[];
+ struct displayid_detailed_timings_1_7 timings[];
};
#define DISPLAYID_VESA_MSO_OVERLAP GENMASK(3, 0)
base-commit: 99613159ad749543621da8238acf1a12288014
[PATCH] drm/amdgpu: Add missing pm_runtime_put_autosuspend
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code, thus a matching decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Yongzhi Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 9aea1cc..4b950de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1120,8 +1120,10 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct file
*f, char __user *buf,
return -EINVAL;
r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
- if (r < 0)
+ if (r < 0) {
+ pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
return r;
+ }
while (size) {
uint32_t value;
--
2.7.4
[v3 2/3] drm/msm/dsi: Add dsi phy tuning configuration support
Add support for MSM DSI PHY tuning configuration. Current design is
to support drive strength and drive level/amplitude tuning for
10nm PHY version, but this can be extended to other PHY versions.
Signed-off-by: Rajeev Nandan
---
Changes in v2:
- New.
- Split into generic code and 10nm-specific part (Dmitry Baryshkov)
Changes in v3:
- s/ops.tuning_cfg_init/ops.parse_dt_properties
To parse phy version specific DT properties (Dmitry Baryshkov)
- Address comments for phy tuning data structure (Dmitry Baryshkov)
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 6 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 4
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8c65ef6..fcbca76 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -739,6 +739,12 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
}
}
+ if (phy->cfg->ops.parse_dt_properties) {
+ ret = phy->cfg->ops.parse_dt_properties(phy);
+ if (ret)
+ goto fail;
+ }
+
ret = dsi_phy_regulator_init(phy);
if (ret)
goto fail;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index b91303a..9e08081 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -25,6 +25,7 @@ struct msm_dsi_phy_ops {
void (*save_pll_state)(struct msm_dsi_phy *phy);
int (*restore_pll_state)(struct msm_dsi_phy *phy);
bool (*set_continuous_clock)(struct msm_dsi_phy *phy, bool enable);
+ int (*parse_dt_properties)(struct msm_dsi_phy *phy);
};
struct msm_dsi_phy_cfg {
@@ -81,6 +82,8 @@ struct msm_dsi_dphy_timing {
#define DSI_PIXEL_PLL_CLK 1
#define NUM_PROVIDED_CLKS 2
+#define DSI_LANE_MAX 5
+
struct msm_dsi_phy {
struct platform_device *pdev;
void __iomem *base;
@@ -98,6 +101,7 @@ struct msm_dsi_phy {
struct msm_dsi_dphy_timing timing;
const struct msm_dsi_phy_cfg *cfg;
+ void *tuning_cfg;
enum msm_dsi_phy_usecase usecase;
bool regulator_ldo_mode;
--
2.7.4
[v3 0/3] drm/msm/dsi: Add 10nm dsi phy tuning configuration support
This series is to add DSI PHY tuning support in Qualcomm Snapdragon SoCs with 10nm DSI PHY e.g. SC7180 In most cases the default values of DSI PHY tuning registers should be sufficient as they are fully optimized. However, in some cases (for example, where extreme board parasitics cause the eye shape to degrade), the override bits can be used to improve the signal quality. Different DSI PHY versions have different configurations to adjust the drive strength, drive level, de-emphasis, etc. The current series has only those configuration options supported by 10nm PHY, e.g. drive strength and drive level. The number of registers to configure the drive strength are different for 7nm PHY. The design can be extended to other DSI PHY versions if required, as each PHY version can have its callback to get the input from DT and prepare register values. Changes in v2: - Addressed dt-bindings comments (Stephen Boyd, Dmitry Baryshkov) - Split into generic code and 10nm-specific part (Dmitry Baryshkov) - Fix the backward compatibility (Dmitry Baryshkov) Changes in v3: - Addressed dt-bindings comments (Rob Herring, Dmitry Baryshkov) - Address comments for phy tuning data structure (Dmitry Baryshkov) - s/ops.tuning_cfg_init/ops.parse_dt_properties (Dmitry Baryshkov) Rajeev Nandan (3): dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties drm/msm/dsi: Add dsi phy tuning configuration support drm/msm/dsi: Add 10nm dsi phy tuning configuration support .../bindings/display/msm/dsi-phy-10nm.yaml | 34 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 6 ++ drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 4 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 97 -- 4 files changed, 135 insertions(+), 6 deletions(-) -- 2.7.4
[PATCH] drm/vc4: Fix deadlock on DSI device attach error
DSI device attach to DSI host will be done with host device's lock
held.
Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.
Startup Call trace:
[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8
[ 35.043048] mutex_lock_nested+0x7c/0xc8
[ 35.043060] device_del+0x4c/0x3e8
[ 35.043075] device_unregister+0x20/0x40
[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28
[ 35.043093] device_for_each_child+0x68/0xb0
[ 35.043105] mipi_dsi_host_unregister+0x40/0x90
[ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4]
[ 35.043199] mipi_dsi_attach+0x30/0x48
[ 35.043209] tc358762_probe+0x128/0x164 [tc358762]
[ 35.043225] mipi_dsi_drv_probe+0x28/0x38
[ 35.043234] really_probe+0xc0/0x318
[ 35.043244] __driver_probe_device+0x80/0xe8
[ 35.043254] driver_probe_device+0xb8/0x118
[ 35.043263] __device_attach_driver+0x98/0xe8
[ 35.043273] bus_for_each_drv+0x84/0xd8
[ 35.043281] __device_attach+0xf0/0x150
[ 35.043290] device_initial_probe+0x1c/0x28
[ 35.043300] bus_probe_device+0xa4/0xb0
[ 35.043308] deferred_probe_work_func+0xa0/0xe0
[ 35.043318] process_one_work+0x254/0x700
[ 35.043330] worker_thread+0x4c/0x448
[ 35.043339] kthread+0x19c/0x1a8
[ 35.043348] ret_from_fork+0x10/0x20
Shutdown Call trace:
[ 365.565417] Call trace:
[ 365.565423] __switch_to+0x148/0x200
[ 365.565452] __schedule+0x340/0x9c8
[ 365.565467] schedule+0x48/0x110
[ 365.565479] schedule_timeout+0x3b0/0x448
[ 365.565496] wait_for_completion+0xac/0x138
[ 365.565509] __flush_work+0x218/0x4e0
[ 365.565523] flush_work+0x1c/0x28
[ 365.565536] wait_for_device_probe+0x68/0x158
[ 365.565550] device_shutdown+0x24/0x348
[ 365.565561] kernel_restart_prepare+0x40/0x50
[ 365.565578] kernel_restart+0x20/0x70
[ 365.565591] __do_sys_reboot+0x10c/0x220
[ 365.565605] __arm64_sys_reboot+0x2c/0x38
[ 365.565619] invoke_syscall+0x4c/0x110
[ 365.565634] el0_svc_common.constprop.3+0xfc/0x120
[ 365.565648] do_el0_svc+0x2c/0x90
[ 365.565661] el0_svc+0x4c/0xf0
[ 365.565671] el0t_64_sync_handler+0x90/0xb8
[ 365.565682] el0t_64_sync+0x180/0x184
Signed-off-by: Padmanabha Srinivasaiah
---
drivers/gpu/drm/vc4/vc4_dsi.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index a229da58962a..9300d3354c51 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1262,7 +1262,6 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct vc4_dsi *dsi = host_to_dsi(host);
- int ret;
dsi->lanes = device->lanes;
dsi->channel = device->channel;
@@ -1297,18 +1296,15 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host
*host,
return 0;
}
- ret = component_add(&dsi->pdev->dev, &vc4_dsi_ops);
- if (ret) {
- mipi_dsi_host_unregister(&dsi->dsi_host);
- return ret;
- }
-
- return 0;
+ return component_add(&dsi->pdev->dev, &vc4_dsi_ops);
}
static int vc4_dsi_host_detach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
+ struct vc4_dsi *dsi = host_to_dsi(host);
+
+ component_del(&dsi->pdev->dev, &vc4_dsi_ops);
return 0;
}
@@ -1686,9 +1682,7 @@ static int vc4_dsi_dev_remove(struct platform_device
*pdev)
struct device *dev = &pdev->dev;
struct vc4_dsi *dsi = dev_get_drvdata(dev);
- component_del(&pdev->dev, &vc4_dsi_ops);
mipi_dsi_host_unregister(&dsi->dsi_host);
-
return 0;
}
--
2.17.1
[PATCH] drm/rockchip: Fix runtime PM imbalance on error
pm_runtime_get_sync() will increase the rumtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Yongzhi Liu
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 3e8d9e2..9fb83b6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1930,7 +1930,7 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}
- ret = pm_runtime_get_sync(vop->dev);
+ ret = pm_runtime_resume_get(vop->dev);
if (ret < 0) {
DRM_DEV_ERROR(vop->dev, "failed to get pm runtime: %d\n", ret);
return ret;
--
2.7.4
[v3 1/3] dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties
In most cases, the default values of DSI PHY tuning registers should be sufficient as they are fully optimized. However, in some cases where extreme board parasitics cause the eye shape to degrade, the override bits can be used to improve the signal quality. The general guidelines for DSI PHY tuning include: - High and moderate data rates may benefit from the drive strength and drive level tuning. - Drive strength tuning will affect the output impedance and may be used for matching optimization. - Drive level tuning will affect the output levels without affecting the impedance. The clock and data lanes have a calibration circuitry feature. The drive strength tuning can be done by adjusting rescode offset for hstop/hsbot, and the drive level tuning can be done by adjusting the LDO output level for the HSTX drive. Signed-off-by: Rajeev Nandan --- Changes in v2: - More details in the commit text (Stephen Boyd) - Use human understandable values (Stephen Boyd, Dmitry Baryshkov) - Do not take values that are going to be unused (Dmitry Baryshkov) Changes in v3: - Use "qcom," prefix (Dmitry Baryshkov) - Remove encoding from phy-drive-ldo-level (Dmitry Baryshkov) - Use negative values instead of two's complement (Dmitry, Rob Herring) .../bindings/display/msm/dsi-phy-10nm.yaml | 34 ++ 1 file changed, 34 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml index 4399715..e9ba57e 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -35,6 +35,36 @@ properties: Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target + qcom,phy-rescode-offset-top: +$ref: /schemas/types.yaml#/definitions/int8-array +minItems: 5 +maxItems: 5 +minimum: -32 +maximum: 31 +description: + Integer array of offset for pull-up legs rescode for all five lanes. + To offset the drive strength from the calibrated value in an increasing + manner, -32 is the weakest and +31 is the strongest. + + qcom,phy-rescode-offset-bot: +$ref: /schemas/types.yaml#/definitions/int8-array +minItems: 5 +maxItems: 5 +minimum: -32 +maximum: 31 +description: + Integer array of offset for pull-down legs rescode for all five lanes. + To offset the drive strength from the calibrated value in a decreasing + manner, -32 is the weakest and +31 is the strongest. + + qcom,phy-drive-ldo-level: +$ref: "/schemas/types.yaml#/definitions/uint32" +description: + The PHY LDO has an amplitude tuning feature to adjust the LDO output + for the HSTX drive. Use supported levels (mV) to offset the drive level + from the default value. +enum: [ 375, 400, 425, 450, 475, 500 ] + required: - compatible - reg @@ -64,5 +94,9 @@ examples: clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, <&rpmhcc RPMH_CXO_CLK>; clock-names = "iface", "ref"; + + qcom,phy-rescode-offset-top = /bits/ 8 <0 0 0 0 0>; + qcom,phy-rescode-offset-bot = /bits/ 8 <0 0 0 0 0>; + qcom,phy-drive-ldo-level = <400>; }; ... -- 2.7.4
[syzbot] WARNING in component_del
Hello, syzbot found the following issue on: HEAD commit:a33f5c380c4b Merge tag 'xfs-5.17-merge-3' of git://git.ker.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17c4eb7fb0 kernel config: https://syzkaller.appspot.com/x/.config?x=dc846445c1d2060e dashboard link: https://syzkaller.appspot.com/bug?extid=60df062e1c41940cae0f compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+60df062e1c41940ca...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 11050 at drivers/base/component.c:767 component_del+0xe2/0x480 drivers/base/component.c:765 Modules linked in: CPU: 1 PID: 11050 Comm: syz-executor.5 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:component_del+0xe2/0x480 drivers/base/component.c:767 Code: 03 fd 48 8b 6d 00 4c 39 ed 74 07 e8 88 bc b7 fc eb 86 e8 81 bc b7 fc eb 05 e8 7a bc b7 fc 48 c7 c7 20 16 29 8d e8 be b5 47 05 <0f> 0b 31 ed 48 89 ef 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d e9 RSP: 0018:c90004a97550 EFLAGS: 00010246 RAX: c095017d97055900 RBX: 888023b8b6b0 RCX: 8d291620 RDX: 0001 RSI: 0008 RDI: c90004a974c0 RBP: 8d291720 R08: dc00 R09: f52000952e99 R10: f52000952e99 R11: R12: dc00 R13: 8d291720 R14: 8b27aea0 R15: 88807ac5a008 FS: 7f5f620ee700() GS:8880b9b0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b2eb22000 CR3: 7da2d000 CR4: 003526e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: usb_hub_remove_port_device+0x1bf/0x2d0 drivers/usb/core/port.c:653 hub_disconnect+0x171/0x480 drivers/usb/core/hub.c:1737 usb_unbind_interface+0x1f2/0x860 drivers/usb/core/driver.c:458 __device_release_driver drivers/base/dd.c:1206 [inline] device_release_driver_internal+0x523/0x7b0 drivers/base/dd.c:1237 proc_ioctl+0x53c/0x640 drivers/usb/core/devio.c:2332 proc_ioctl_default drivers/usb/core/devio.c:2375 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2731 [inline] usbdev_ioctl+0x3f4a/0x6d00 drivers/usb/core/devio.c:2791 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f5f637dbfe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f5f620ee168 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7f5f638ef1d0 RCX: 7f5f637dbfe9 RDX: 2380 RSI: c0105512 RDI: 0005 RBP: 7f5f6383608d R08: R09: R10: R11: 0246 R12: R13: 7ffef2b2329f R14: 7f5f620ee300 R15: 00022000 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH] drm/etnaviv: Add missing pm_runtime_put
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, thus a matching decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Yongzhi Liu --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index 242a5fd..5e81a98 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -1714,6 +1714,9 @@ static int etnaviv_gpu_bind(struct device *dev, struct device *master, return 0; out_sched: +#ifdef CONFIG_PM + pm_runtime_put_autosuspend(gpu->dev); +#endif etnaviv_sched_fini(gpu); out_workqueue: -- 2.7.4
[v3 3/3] drm/msm/dsi: Add 10nm dsi phy tuning configuration support
The clock and data lanes of the DSI PHY have a calibration circuitry
feature. As per the MSM DSI PHY tuning guidelines, the drive strength
tuning can be done by adjusting rescode offset for hstop/hsbot, and
the drive level tuning can be done by adjusting the LDO output level
for the HSTX drive.
Signed-off-by: Rajeev Nandan
---
Changes in v2:
- Split into generic code and 10nm-specific part (Dmitry Baryshkov)
- Fix the backward compatibility (Dmitry Baryshkov)
Changes in v3:
- Address comments for phy tuning data structure (Dmitry Baryshkov)
- Make changes as per updated dt-bindings
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 97 --
1 file changed, 91 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index d8128f5..2d225fb 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -83,6 +83,18 @@ struct dsi_pll_10nm {
#define to_pll_10nm(x) container_of(x, struct dsi_pll_10nm, clk_hw)
+/**
+ * struct dsi_phy_10nm_tuning_cfg - Holds 10nm PHY tuning config parameters.
+ * @rescode_offset_top: Offset for pull-up legs rescode.
+ * @rescode_offset_bot: Offset for pull-down legs rescode.
+ * @vreg_ctrl: vreg ctrl to drive LDO level
+ */
+struct dsi_phy_10nm_tuning_cfg {
+ u8 rescode_offset_top[DSI_LANE_MAX];
+ u8 rescode_offset_bot[DSI_LANE_MAX];
+ u8 vreg_ctrl;
+};
+
/*
* Global list of private DSI PLL struct pointers. We need this for bonded DSI
* mode, where the master PLL's clk_ops needs access the slave's private data
@@ -747,6 +759,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct
msm_dsi_phy *phy)
int i;
u8 tx_dctrl[] = { 0x00, 0x00, 0x00, 0x04, 0x01 };
void __iomem *lane_base = phy->lane_base;
+ struct dsi_phy_10nm_tuning_cfg *tuning_cfg = phy->tuning_cfg;
if (phy->cfg->quirks & DSI_PHY_10NM_QUIRK_OLD_TIMINGS)
tx_dctrl[3] = 0x02;
@@ -775,10 +788,13 @@ static void dsi_phy_hw_v3_0_lane_settings(struct
msm_dsi_phy *phy)
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_CFG2(i), 0x0);
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_CFG3(i),
i == 4 ? 0x80 : 0x0);
- dsi_phy_write(lane_base +
- REG_DSI_10nm_PHY_LN_OFFSET_TOP_CTRL(i), 0x0);
- dsi_phy_write(lane_base +
- REG_DSI_10nm_PHY_LN_OFFSET_BOT_CTRL(i), 0x0);
+
+ /* platform specific dsi phy drive strength adjustment */
+ dsi_phy_write(lane_base +
REG_DSI_10nm_PHY_LN_OFFSET_TOP_CTRL(i),
+ tuning_cfg->rescode_offset_top[i]);
+ dsi_phy_write(lane_base +
REG_DSI_10nm_PHY_LN_OFFSET_BOT_CTRL(i),
+ tuning_cfg->rescode_offset_bot[i]);
+
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(i),
tx_dctrl[i]);
}
@@ -799,6 +815,7 @@ static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy,
u32 const timeout_us = 1000;
struct msm_dsi_dphy_timing *timing = &phy->timing;
void __iomem *base = phy->base;
+ struct dsi_phy_10nm_tuning_cfg *tuning_cfg = phy->tuning_cfg;
u32 data;
DBG("");
@@ -834,8 +851,9 @@ static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy,
/* Select MS1 byte-clk */
dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_GLBL_CTRL, 0x10);
- /* Enable LDO */
- dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_VREG_CTRL, 0x59);
+ /* Enable LDO with platform specific drive level/amplitude adjustment */
+ dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_VREG_CTRL,
+ tuning_cfg->vreg_ctrl);
/* Configure PHY lane swap (TODO: we need to calculate this) */
dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_LANE_CFG0, 0x21);
@@ -922,6 +940,71 @@ static void dsi_10nm_phy_disable(struct msm_dsi_phy *phy)
DBG("DSI%d PHY disabled", phy->id);
}
+static int dsi_10nm_phy_parse_dt(struct msm_dsi_phy *phy)
+{
+ struct device *dev = &phy->pdev->dev;
+ struct dsi_phy_10nm_tuning_cfg *tuning_cfg;
+ u8 offset_top[DSI_LANE_MAX] = { 0 }; /* No offset */
+ u8 offset_bot[DSI_LANE_MAX] = { 0 }; /* No offset */
+ u32 ldo_level = 400; /* 400mV */
+ u8 level;
+ int ret, i;
+
+ tuning_cfg = devm_kzalloc(dev, sizeof(*tuning_cfg), GFP_KERNEL);
+ if (!tuning_cfg)
+ return -ENOMEM;
+
+ /* Drive strength adjustment parameters */
+ ret = of_property_read_u8_array(dev->of_node,
"qcom,phy-rescode-offset-top",
+ offset_top, DSI_LANE_MAX);
+ if (ret && ret != -EINVAL)
+ DRM_DEV_ERROR(dev, "failed to parse
qcom,phy-rescode-offset-top, %d\n", ret);
+
+ for (i = 0; i < DSI_LANE_MAX; i++)
+ tu
Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
On Tuesday, 18 January 2022 17:58:58 CET Paul Cercueil wrote:
>
> Not at all. If the clock is disabled, the LCD controller is disabled,
> so all the registers read zero, this makes sense. You can only read the
> registers when the clock is enabled. On some SoCs, reading disabled
> registers can even cause a complete lockup.
My concern was that something might be accessing the registers before the
clock had been enabled. It seems unlikely, given that the clock is enabled in
the bind function, and I would have thought that nothing would invoke the
different driver operations ("funcs") until bind has been called, nor should
anything called from within bind itself be accessing registers.
> Why is this JZ_LCD_OSDC_ALPHAEN bit needed now? I remember it working
> fine last time I tried, and now I indeed get a black screen unless this
> bit is set. The PM doesn't make it obvious that the bit is required,
> but that wouldn't be surprising.
It isn't actually needed. If the DMA descriptors are set up appropriately, the
OSD alpha bit seems to be set as a consequence. In my non-Linux testing
environment I don't even set any OSD registers explicitly, but the OSD alpha
and enable flags become set when the display is active.
Paul
Re: [PATCH] drm/vmwgfx: Stop requesting the pci regions
On 1/18/22 20:00, Javier Martinez Canillas wrote: > Hello Zack, > > On 1/17/22 19:03, Zack Rusin wrote: >> From: Zack Rusin >> >> When sysfb_simple is enabled loading vmwgfx fails because the regions >> are held by the platform. In that case remove_conflicting*_framebuffers >> only removes the simplefb but not the regions held by sysfb. >> > > Indeed, that's an issue. I wonder if we should drop the IORESOURCE_BUSY > flag from the memory resource added to the "simple-framebuffer" device ? > > In fact, maybe in sysfb_create_simplefb() shouldn't even attempt to claim > a memory resource and just register the platform device with no resources ? > Answering my own question, this would mean adding that platform specific logic to the drivers matching the "simple-framebuffer" device so it should remain in sysfb_create_simplefb(). But I still wonder if dropping the IORESOURCE_BUSY flag is something that will be reasonable to prevent other drivers having the the issue reported in this patch. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
[PATCH 1/3] drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL do fully decouple the error capture from fence signalling.
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 67f3515f07e7a..aee42eae4729f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1516,7 +1516,7 @@ capture_engine(struct intel_engine_cs *engine,
struct i915_request *rq = NULL;
unsigned long flags;
- ee = intel_engine_coredump_alloc(engine, GFP_KERNEL);
+ ee = intel_engine_coredump_alloc(engine, ALLOW_FAIL);
if (!ee)
return NULL;
--
2.34.1
[PATCH 2/3] drm/i915/guc: Add work queue to trigger a GT reset
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT when a engine reset failure is received to break this
circular dependency.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 23 +++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 9d26a86fe557a..60ea8deef5392 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -119,6 +119,11 @@ struct intel_guc {
* function as it might be in an atomic context (no sleeping)
*/
struct work_struct destroyed_worker;
+ /**
+* @reset_worker: worker to trigger a GT reset after an engine
+* reset fails
+*/
+ struct work_struct reset_worker;
} submission_state;
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 23a40f10d376d..cdd8d691251ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1746,6 +1746,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
*guc)
}
static void destroyed_worker_func(struct work_struct *w);
+static void reset_worker_func(struct work_struct *w);
/*
* Set up the memory resources to be shared with the GuC (via the GGTT)
@@ -1776,6 +1777,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
INIT_LIST_HEAD(&guc->submission_state.destroyed_contexts);
INIT_WORK(&guc->submission_state.destroyed_worker,
destroyed_worker_func);
+ INIT_WORK(&guc->submission_state.reset_worker,
+ reset_worker_func);
guc->submission_state.guc_ids_bitmap =
bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
@@ -4052,6 +4055,17 @@ guc_lookup_engine(struct intel_guc *guc, u8 guc_class,
u8 instance)
return gt->engine_class[engine_class][instance];
}
+static void reset_worker_func(struct work_struct *w)
+{
+ struct intel_guc *guc = container_of(w, struct intel_guc,
+submission_state.reset_worker);
+ struct intel_gt *gt = guc_to_gt(guc);
+
+ intel_gt_handle_error(gt, ALL_ENGINES,
+ I915_ERROR_CAPTURE,
+ "GuC failed to reset a engine\n");
+}
+
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len)
{
@@ -4083,10 +4097,11 @@ int intel_guc_engine_failure_process_msg(struct
intel_guc *guc,
drm_err(>->i915->drm, "GuC engine reset request failed on %d:%d (%s)
because 0x%08X",
guc_class, instance, engine->name, reason);
- intel_gt_handle_error(gt, engine->mask,
- I915_ERROR_CAPTURE,
- "GuC failed to reset %s (reason=0x%08x)\n",
- engine->name, reason);
+ /*
+* A GT reset flushes this worker queue (G2H handler) so we must use
+* another worker to trigger a GT reset.
+*/
+ queue_work(system_unbound_wq, &guc->submission_state.reset_worker);
return 0;
}
--
2.34.1
[PATCH 3/3] drm/i915/guc: Flush G2H handler during a GT reset
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which is turn depends on resets) we
can safely flush the G2H handler during a GT reset. This is eliminates
corner cases where GuC generated G2H (e.g. engine resets) race with a GT
reset.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index cdd8d691251ff..1a11e8986948b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1396,8 +1396,6 @@ static void guc_flush_destroyed_contexts(struct intel_guc
*guc);
void intel_guc_submission_reset_prepare(struct intel_guc *guc)
{
- int i;
-
if (unlikely(!guc_submission_initialized(guc))) {
/* Reset called during driver load? GuC not yet initialised! */
return;
@@ -1414,21 +1412,7 @@ void intel_guc_submission_reset_prepare(struct intel_guc
*guc)
guc_flush_submissions(guc);
guc_flush_destroyed_contexts(guc);
-
- /*
-* Handle any outstanding G2Hs before reset. Call IRQ handler directly
-* each pass as interrupt have been disabled. We always scrub for
-* outstanding G2H as it is possible for outstanding_submission_g2h to
-* be incremented after the context state update.
-*/
- for (i = 0; i < 4 && atomic_read(&guc->outstanding_submission_g2h);
++i) {
- intel_guc_to_host_event_handler(guc);
-#define wait_for_reset(guc, wait_var) \
- intel_guc_wait_for_pending_msg(guc, wait_var, false, (HZ / 20))
- do {
- wait_for_reset(guc, &guc->outstanding_submission_g2h);
- } while (!list_empty(&guc->ct.requests.incoming));
- }
+ flush_work(&guc->ct.requests.worker);
scrub_guc_desc_for_outstanding_g2h(guc);
}
--
2.34.1
[PATCH 0/3] Flush G2H handler during a GT reset
After a small fix to error capture code, we now can flush G2H during a GT reset which simplifies code and seals some extreme corner case races. v2: (CI) - Don't trigger GT reset from G2H handler Signed-off-by: Matthew Brost Matthew Brost (3): drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL drm/i915/guc: Add work queue to trigger a GT reset drm/i915/guc: Flush G2H handler during a GT reset drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +++ .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 +-- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- 3 files changed, 26 insertions(+), 22 deletions(-) -- 2.34.1
Re: [PATCH v18 1/4] drm/msm/dp: do not initialize phy until plugin interrupt received
Quoting Kuogee Hsieh (2022-01-18 10:47:25)
> Current DP drivers have regulators, clocks, irq and phy are grouped
> together within a function and executed not in a symmetric manner.
> This increase difficulty of code maintenance and limited code scalability.
> This patch divides the driver life cycle of operation into four states,
> resume (including booting up), dongle plugin, dongle unplugged and suspend.
> Regulators, core clocks and irq are grouped together and enabled at resume
> (or booting up) so that the DP controller is armed and ready to receive HPD
> plugin interrupts. HPD plugin interrupt is generated when a dongle plugs
> into DUT (device under test). Once HPD plugin interrupt is received, DP
> controller will initialize phy so that dpcd read/write will function and
> following link training can be proceeded successfully. DP phy will be
> disabled after main link is teared down at end of unplugged HPD interrupt
> handle triggered by dongle unplugged out of DUT. Finally regulators, code
> clocks and irq are disabled at corresponding suspension.
>
> Changes in V2:
> -- removed unnecessary dp_ctrl NULL check
> -- removed unnecessary phy init_count and power_count DRM_DEBUG_DP logs
> -- remove flip parameter out of dp_ctrl_irq_enable()
> -- add fixes tag
>
> Changes in V3:
> -- call dp_display_host_phy_init() instead of dp_ctrl_phy_init() at
> dp_display_host_init() for eDP
>
> Changes in V4:
> -- rewording commit text to match this commit changes
>
> Changes in V5:
> -- rebase on top of msm-next branch
>
> Changes in V6:
> -- delete flip variable
>
> Changes in V7:
> -- dp_ctrl_irq_enable/disabe() merged into dp_ctrl_reset_irq_ctrl()
>
> Changes in V8:
> -- add more detail comment regrading dp phy at dp_display_host_init()
>
> Changes in V9:
> -- remove set phy_initialized to false when -ECONNRESET detected
>
> Changes in v10:
> -- group into one series
>
> Changes in v11:
> -- drop drm/msm/dp: dp_link_parse_sink_count() return immediately
> if aux read
>
> Changes in v12:
> -- move dp_display_host_phy_exit() after dp_display_host_deinit()
>
> Changes in v13:
> -- do not execute phy_init until plugged_in interrupt for edp, same as DP.
>
> Changes in v14:
> -- remove redundant dp->core_initialized = false form dp_pm_suspend.
>
> Changes in v15:
> -- remove core_initialized flag check at both host_init and host_deinit
>
> Changes in v16:
> -- remove dp_display_host_phy_exit core_initialized=false at dp_pm_suspend
>
> Changes in v17:
> -- remove core_initialized checking before execute attention_cb()
>
> Changes in v18:
> -- remove core_initialized checking at dp_pm_suspend
>
> Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
> Chipsets")
> Signed-off-by: Kuogee Hsieh
> ---
Reviewed-by: Stephen Boyd
Re: [PATCH] drm/dp: Remove common Post Cursor2 register handling
On Tue, Jan 18, 2022 at 01:11:48PM -0600, Gustavo A. R. Silva wrote:
>
>
> On 1/5/22 11:35, Kees Cook wrote:
> > The link_status array was not large enough to read the Adjust Request
> > Post Cursor2 register, so remove the common helper function to avoid
> > an OOB read, found with a -Warray-bounds build:
> >
> > drivers/gpu/drm/drm_dp_helper.c: In function
> > 'drm_dp_get_adjust_request_post_cursor':
> > drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside
> > array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
> > [-Werror=array-bounds]
> >59 | return link_status[r - DP_LANE0_1_STATUS];
> > |~~~^~~
> > drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing
> > 'link_status'
> > 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
> > link_status[DP_LINK_STATUS_SIZE],
> > |
> > ~^~~~
> >
> > Replace the only user of the helper with an open-coded fetch and decode,
> > similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
> >
> > Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
>
> This should be tagged for -stable:
>
> Cc: sta...@vger.kernel.org
Ah yeah, good point. Added.
>
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Kees Cook
>
> Reviewed-by: Gustavo A. R. Silva
Thanks!
-Kees
>
> Thanks
> --
> Gustavo
>
> > ---
> > This is the alternative to:
> > https://lore.kernel.org/lkml/20211203084354.3105253-1-keesc...@chromium.org/
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 10 --
> > drivers/gpu/drm/tegra/dp.c | 11 ++-
> > include/drm/drm_dp_helper.h | 2 --
> > 3 files changed, 10 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 23f9073bc473..c9528aa62c9c 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8
> > link_status[DP_LINK_STATUS_SIZE],
> > }
> > EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
> >
> > -u8 drm_dp_get_adjust_request_post_cursor(const u8
> > link_status[DP_LINK_STATUS_SIZE],
> > -unsigned int lane)
> > -{
> > - unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
> > - u8 value = dp_link_status(link_status, offset);
> > -
> > - return (value >> (lane << 1)) & 0x3;
> > -}
> > -EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
> > -
> > static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux,
> > u8 rd_interval)
> > {
> > if (rd_interval > 4)
> > diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
> > index 70dfb7d1dec5..f5535eb04c6b 100644
> > --- a/drivers/gpu/drm/tegra/dp.c
> > +++ b/drivers/gpu/drm/tegra/dp.c
> > @@ -549,6 +549,15 @@ static void drm_dp_link_get_adjustments(struct
> > drm_dp_link *link,
> > {
> > struct drm_dp_link_train_set *adjust = &link->train.adjust;
> > unsigned int i;
> > + u8 post_cursor;
> > + int err;
> > +
> > + err = drm_dp_dpcd_read(link->aux, DP_ADJUST_REQUEST_POST_CURSOR2,
> > + &post_cursor, sizeof(post_cursor));
> > + if (err < 0) {
> > + DRM_ERROR("failed to read post_cursor2: %d\n", err);
> > + post_cursor = 0;
> > + }
> >
> > for (i = 0; i < link->lanes; i++) {
> > adjust->voltage_swing[i] =
> > @@ -560,7 +569,7 @@ static void drm_dp_link_get_adjustments(struct
> > drm_dp_link *link,
> > DP_TRAIN_PRE_EMPHASIS_SHIFT;
> >
> > adjust->post_cursor[i] =
> > - drm_dp_get_adjust_request_post_cursor(status, i);
> > + (post_cursor >> (i << 1)) & 0x3;
> > }
> > }
> >
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 472dac376284..fdf3cf6ccc02 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> > link_status[DP_LINK_STATUS_SI
> > int lane);
> > u8 drm_dp_get_adjust_tx_ffe_preset(const u8
> > link_status[DP_LINK_STATUS_SIZE],
> >int lane);
> > -u8 drm_dp_get_adjust_request_post_cursor(const u8
> > link_status[DP_LINK_STATUS_SIZE],
> > -unsigned int lane);
> >
> > #define DP_BRANCH_OUI_HEADER_SIZE 0xc
> > #define DP_RECEIVER_CAP_SIZE 0xf
> >
--
Kees Cook
Re: [PATCH 2/2] drm/msm/dsi: switch to DRM_PANEL_BRIDGE
On 1/18/2022 12:01 PM, Dmitry Baryshkov wrote:
On Tue, 18 Jan 2022 at 22:41, Abhinav Kumar wrote:
On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and dropping support for
handling the panel directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 32 +---
drivers/gpu/drm/msm/dsi/dsi.h | 10 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 20 +-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 257 +++---
4 files changed, 32 insertions(+), 287 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 9670e548b3e9..b61f451a282e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,7 +208,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
struct drm_encoder *encoder)
{
struct msm_drm_private *priv;
- struct drm_bridge *ext_bridge;
+ struct drm_connector *connector;
int ret;
if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))
@@ -238,31 +238,17 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
goto fail;
}
- /*
- * check if the dsi encoder output is connected to a panel or an
- * external bridge. We create a connector only if we're connected to a
- * drm_panel device. When we're connected to an external bridge, we
- * assume that the drm_bridge driver will create the connector itself.
- */
- ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
-
- if (ext_bridge)
- msm_dsi->connector =
- msm_dsi_manager_ext_bridge_init(msm_dsi->id);
- else
- msm_dsi->connector =
- msm_dsi_manager_connector_init(msm_dsi->id);
-
- if (IS_ERR(msm_dsi->connector)) {
- ret = PTR_ERR(msm_dsi->connector);
+ connector = msm_dsi_manager_ext_bridge_init(msm_dsi->id);
+
+ if (IS_ERR(connector)) {
+ ret = PTR_ERR(connector);
DRM_DEV_ERROR(dev->dev,
"failed to create dsi connector: %d\n", ret);
- msm_dsi->connector = NULL;
goto fail;
}
Please correct my understanding if incorrect. Here you are expecting
that the existing panels/bridges have already used
drm_panel_bridge_add_typed add the bridge? Otherwise we will goto the
fail goto?
No.
@@ -727,8 +509,11 @@ struct drm_connector
*msm_dsi_manager_ext_bridge_init(u8 id)
int ret;
int_bridge = msm_dsi->bridge;
- ext_bridge = msm_dsi->external_bridge =
- msm_dsi_host_get_bridge(msm_dsi->host);
+ ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
+ if (IS_ERR(ext_bridge))
+ return ERR_PTR(PTR_ERR(ext_bridge));
+
+ msm_dsi->external_bridge = ext_bridge;
Does that mean you plan to migrate the existing msm panels/bridges to
use devm_drm_panel_bridge_add_typed?
No. panel-bridge.c/devm_drm_of_get_bridge() does that in a transparent
way. It calls devm_drm_panel_bridge_add() on it's own.
Ah okay, got it, Thanks.
Reviewed-by: Abhinav Kumar
priv->bridges[priv->num_bridges++] = msm_dsi->bridge;
- priv->connectors[priv->num_connectors++] = msm_dsi->connector;
+ priv->connectors[priv->num_connectors++] = connector;
return 0;
fail:
@@ -272,12 +258,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
msm_dsi->bridge = NULL;
}
- /* don't destroy connector if we didn't make it */
- if (msm_dsi->connector && !msm_dsi->external_bridge)
- msm_dsi->connector->funcs->destroy(msm_dsi->connector);
-
- msm_dsi->connector = NULL;
-
return ret;
}
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index f46df52c6985..7eb778070a8c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -49,8 +49,6 @@ struct msm_dsi {
struct drm_device *dev;
struct platform_device *pdev;
- /* connector managed by us when we're connected to a drm_panel */
- struct drm_connector *connector;
/* internal dsi bridge attached to MDP interface */
struct drm_bridge *bridge;
@@ -58,10 +56,8 @@ struct msm_dsi {
struct msm_dsi_phy *phy;
/*
- * panel/external_bridge connected to dsi bridge output, only one of the
- * two can be valid at a time
+ * external_bridge connected to dsi bridge output
*/
- struct drm_panel *panel;
struct drm_bridge *external_bridge;
struct device *phy_dev;
@@ -76,7 +72,6 @@ struct msm_dsi {
/* dsi manager */
struct drm_bridge *msm_ds
Re: [PATCH] amdgpu/amdgpu_psp: remove unneeded ret variable
Applied. Thanks!
Alex
On Tue, Jan 18, 2022 at 2:57 AM wrote:
>
> From: Minghao Chi
>
> Return value from amdgpu_bo_create_kernel() directly instead
> of taking this in another redundant variable.
>
> Reported-by: Zeal Robot
> Signed-off-by: Minghao Chi
> Signed-off-by: CGEL ZTE
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index dee17a0e1187..ac2b87f81ef9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -914,19 +914,15 @@ static void psp_prep_ta_load_cmd_buf(struct
> psp_gfx_cmd_resp *cmd,
> static int psp_ta_init_shared_buf(struct psp_context *psp,
> struct ta_mem_context *mem_ctx)
> {
> - int ret;
> -
> /*
> * Allocate 16k memory aligned to 4k from Frame Buffer (local
> * physical) for ta to host memory
> */
> - ret = amdgpu_bo_create_kernel(psp->adev, mem_ctx->shared_mem_size,
> + return amdgpu_bo_create_kernel(psp->adev, mem_ctx->shared_mem_size,
> PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM,
> &mem_ctx->shared_bo,
> &mem_ctx->shared_mc_addr,
> &mem_ctx->shared_buf);
> -
> - return ret;
> }
>
> static void psp_ta_free_shared_buf(struct ta_mem_context *mem_ctx)
> --
> 2.25.1
>
Re: [PATCH v2 3/3] ASoC: rk3399_gru_sound: Wire up DP jack detection
Hi Chen-Yu,
On Mon, Jan 17, 2022 at 05:01:52PM +0800, Chen-Yu Tsai wrote:
> On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote:
> >
> > Now that the cdn-dp driver supports plug-change callbacks, let's wire it
> > up.
> >
> > Signed-off-by: Brian Norris
> > ---
> >
> > (no changes since v1)
> >
> > sound/soc/rockchip/rk3399_gru_sound.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
> > b/sound/soc/rockchip/rk3399_gru_sound.c
> > index e2d52d8d0ff9..eeef3ed70037 100644
> > --- a/sound/soc/rockchip/rk3399_gru_sound.c
> > +++ b/sound/soc/rockchip/rk3399_gru_sound.c
> > @@ -164,6 +164,25 @@ static int rockchip_sound_da7219_hw_params(struct
> > snd_pcm_substream *substream,
> > return 0;
> > }
> >
> > +static struct snd_soc_jack cdn_dp_card_jack;
> > +
> > +static int rockchip_sound_cdndp_init(struct snd_soc_pcm_runtime *rtd)
> > +{
> > + struct snd_soc_component *component = asoc_rtd_to_codec(rtd,
> > 0)->component;
>
> Using snd_soc_card_get_codec_dai() might be a better choice throughout this
> driver. While it will work for the cdn_dp case, because it is the first DAI
> in |rockchip_dais[]|, all the invocations for the other codecs are likely
> returning the wrong DAI.
I'll admit, I'm not very familiar with the ASoC object model, so you may
well be correct that there's something fishy in here. But I did trace
through the objects involved here, and we *are* getting the correct DAI
for both this case and the DA7219 case (preexisting code).
It looks like we actually have a new runtime for each of our static
dai_links:
devm_snd_soc_register_card()
...
for_each_card_prelinks()
snd_soc_add_pcm_runtime()
So I think this is valid to keep as-is.
> For this particular patch it works either way, so
>
> Reviewed-by: Chen-Yu Tsai
Thanks for looking!
Brian
Re: [PATCH] drm/radeon: fix UVD suspend error
Applied. Thanks!
On Mon, Jan 17, 2022 at 3:05 PM Leo Liu wrote:
>
>
> On 2022-01-17 2:47 a.m., Qiang Ma wrote:
> > I met a bug recently and the kernel log:
> >
> > [ 330.171875] radeon :03:00.0: couldn't schedule ib
> > [ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying
> > UVD (-22)!
> >
> > In radeon drivers, using UVD suspend is as follows:
> >
> > if (rdev->has_uvd) {
> > uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > }
> >
> > In radeon_ib_schedule function, we check the 'ring->ready' state,
> > but in uvd_v1_0_fini funciton, we've cleared the ready state.
> > So, just modify the suspend code flow to fix error.
>
> It seems reasonable to me. The suspend sends the destroy message if
> there is still incomplete job, so it should be before the fini which
> stops the hardware.
>
> The series are:
>
> Reviewed-by: Leo Liu
>
>
> >
> > Signed-off-by: Qiang Ma
> > ---
> > drivers/gpu/drm/radeon/cik.c | 2 +-
> > drivers/gpu/drm/radeon/evergreen.c | 2 +-
> > drivers/gpu/drm/radeon/ni.c| 2 +-
> > drivers/gpu/drm/radeon/r600.c | 2 +-
> > drivers/gpu/drm/radeon/rv770.c | 2 +-
> > drivers/gpu/drm/radeon/si.c| 2 +-
> > 6 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> > index 81b4de7be9f2..5819737c21c6 100644
> > --- a/drivers/gpu/drm/radeon/cik.c
> > +++ b/drivers/gpu/drm/radeon/cik.c
> > @@ -8517,8 +8517,8 @@ int cik_suspend(struct radeon_device *rdev)
> > cik_cp_enable(rdev, false);
> > cik_sdma_enable(rdev, false);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > if (rdev->has_vce)
> > radeon_vce_suspend(rdev);
> > diff --git a/drivers/gpu/drm/radeon/evergreen.c
> > b/drivers/gpu/drm/radeon/evergreen.c
> > index eeb590d2dec2..455f8036aa54 100644
> > --- a/drivers/gpu/drm/radeon/evergreen.c
> > +++ b/drivers/gpu/drm/radeon/evergreen.c
> > @@ -5156,8 +5156,8 @@ int evergreen_suspend(struct radeon_device *rdev)
> > radeon_pm_suspend(rdev);
> > radeon_audio_fini(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > r700_cp_stop(rdev);
> > r600_dma_stop(rdev);
> > diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> > index 4a364ca7a1be..927e5f42e97d 100644
> > --- a/drivers/gpu/drm/radeon/ni.c
> > +++ b/drivers/gpu/drm/radeon/ni.c
> > @@ -2323,8 +2323,8 @@ int cayman_suspend(struct radeon_device *rdev)
> > cayman_cp_enable(rdev, false);
> > cayman_dma_stop(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > evergreen_irq_suspend(rdev);
> > radeon_wb_disable(rdev);
> > diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> > index ca3fcae2adb5..dd78fc499402 100644
> > --- a/drivers/gpu/drm/radeon/r600.c
> > +++ b/drivers/gpu/drm/radeon/r600.c
> > @@ -3232,8 +3232,8 @@ int r600_suspend(struct radeon_device *rdev)
> > radeon_audio_fini(rdev);
> > r600_cp_stop(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > r600_irq_suspend(rdev);
> > radeon_wb_disable(rdev);
> > diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> > index e592e57be1bb..38796af4fadd 100644
> > --- a/drivers/gpu/drm/radeon/rv770.c
> > +++ b/drivers/gpu/drm/radeon/rv770.c
> > @@ -1894,8 +1894,8 @@ int rv770_suspend(struct radeon_device *rdev)
> > radeon_pm_suspend(rdev);
> > radeon_audio_fini(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > r700_cp_stop(rdev);
> > r600_dma_stop(rdev);
> > diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> > index 013e44ed0f39..8d5e4b25609d 100644
> > --- a/drivers/gpu/drm/radeon/si.c
> > +++ b/drivers/gpu/drm/radeon/si.c
> > @@ -6800,8 +6800,8 @@ int si_suspend(struct radeon_device *rdev)
> > si_cp_enable(rdev, false);
> > cayman_dma_stop(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > if (rdev->has_vce)
> > radeon_vce_suspend(rdev);
Re: [PATCH] drm/amdgpu: Add missing pm_runtime_put_autosuspend
Applied. Strangely I can't seem to find this patch in my inbox or in
the dri-devel or amd-gfx archives.
Alex
On Tue, Jan 18, 2022 at 9:03 AM Lazar, Lijo wrote:
>
>
>
> On 1/18/2022 5:31 PM, Yongzhi Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > when it returns an error code, thus a matching decrement is needed
> > on the error handling path to keep the counter balanced.
> >
> > Signed-off-by: Yongzhi Liu
>
> Thanks!
>
> Reviewed-by: Lijo Lazar
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > index 9aea1cc..4b950de 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > @@ -1120,8 +1120,10 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct
> > file *f, char __user *buf,
> > return -EINVAL;
> >
> > r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
> > - if (r < 0)
> > + if (r < 0) {
> > + pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> > return r;
> > + }
> >
> > while (size) {
> > uint32_t value;
> >
Re: [PATCH 1/2] drm/msm/dsi: move DSI host powerup to modeset time
On Tue, 18 Jan 2022 at 22:29, Abhinav Kumar wrote:
>
>
>
> On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
> > The DSI subsystem does not fully fall into the pre-enable/enable system
> > of callbacks, since typically DSI device bridge drivers expect to be
> > able to communicate with DSI devices at the pre-enable() callback. The
> > reason is that for some DSI hosts enabling the video stream would
> > prevent other drivers from sending DSI commands. For example see the
> > panel-bridge driver, which does drm_panel_prepare() from the
> > pre_enable() callback (which would be called before our pre_enable()
> > callback, resulting in panel preparation failures as the link is not yet
> > ready).
> >
> > Therewere several attempts to solve this issue, but currently the best
> > approach is to power up the DSI link from the mode_set() callback,
> > allowing next bridge/panel to use DSI transfers in the pre_enable()
> > time. Follow this approach.
> >
> Change looks okay. As per the programming guideline, we should set the
> VIDEO_MODE_EN register in the DSI controller followed by enabling the
> timing engine which will still happen even now because we will do it in
> modeset instead of the pre_enable().
> But, this can potentially increase the delay between VIDEO_MODE_EN
> and TIMING_ENGINE_EN. I dont see anything in the programming guide
> against this but since this is a change from the original flow, I would
> like to do one test before acking this. Can you please try adding a huge
> delay like 200-300ms between VIDEO_MODE_EN and timing engine enable to
> make sure there are no issues? You can do that here:
Fine, I'll do the test as the time permits.
>
> int msm_dsi_host_enable(struct mipi_dsi_host *host)
> {
> struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
>
> dsi_op_mode_config(msm_host,
> !!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO), true);
>
> msleep(300);
> }
>
>
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/dsi/dsi_manager.c | 43 +++
> > 1 file changed, 31 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > index 681ca74fe410..497719efb9e9 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > @@ -336,13 +336,12 @@ dsi_mgr_connector_best_encoder(struct drm_connector
> > *connector)
> > return msm_dsi_get_encoder(msm_dsi);
> > }
> >
> > -static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
> > +static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
> > {
> > int id = dsi_mgr_bridge_get_id(bridge);
> > struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
> > struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
> > struct mipi_dsi_host *host = msm_dsi->host;
> > - struct drm_panel *panel = msm_dsi->panel;
> > struct msm_dsi_phy_shared_timings phy_shared_timings[DSI_MAX];
> > bool is_bonded_dsi = IS_BONDED_DSI();
> > int ret;
> > @@ -383,6 +382,34 @@ static void dsi_mgr_bridge_pre_enable(struct
> > drm_bridge *bridge)
> > if (is_bonded_dsi && msm_dsi1)
> > msm_dsi_host_enable_irq(msm_dsi1->host);
> >
> > + return;
> > +
> > +host1_on_fail:
> > + msm_dsi_host_power_off(host);
> > +host_on_fail:
> > + dsi_mgr_phy_disable(id);
> > +phy_en_fail:
> > + return;
> > +}
> > +
> > +static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
> > +{
> > + int id = dsi_mgr_bridge_get_id(bridge);
> > + struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
> > + struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
> > + struct mipi_dsi_host *host = msm_dsi->host;
> > + struct drm_panel *panel = msm_dsi->panel;
> > + bool is_bonded_dsi = IS_BONDED_DSI();
> > + int ret;
> > +
> > + DBG("id=%d", id);
> > + if (!msm_dsi_device_connected(msm_dsi))
> > + return;
> > +
> > + /* Do nothing with the host if it is slave-DSI in case of bonded DSI
> > */
> > + if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
> > + return;
> > +
> > /* Always call panel functions once, because even for dual panels,
> >* there is only one drm_panel instance.
> >*/
> > @@ -417,17 +444,7 @@ static void dsi_mgr_bridge_pre_enable(struct
> > drm_bridge *bridge)
> > if (panel)
> > drm_panel_unprepare(panel);
> > panel_prep_fail:
> > - msm_dsi_host_disable_irq(host);
> > - if (is_bonded_dsi && msm_dsi1)
> > - msm_dsi_host_disable_irq(msm_dsi1->host);
> >
> > - if (is_bonded_dsi && msm_dsi1)
> > - msm_dsi_host_power_off(msm_dsi1->host);
> > -host1_on_fail:
> > - msm_dsi_host_power_off(host);
> > -host_on_fail:
> > - dsi_mgr_phy_disable(id);
> > -phy_en_fail:
> > return;
> > }
> >
> > @@ -573,6 +590,8 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge
> > *bridge,
> >
Re: [PATCH 2/2] drm/msm/dsi: switch to DRM_PANEL_BRIDGE
On Tue, 18 Jan 2022 at 22:41, Abhinav Kumar wrote:
>
>
>
> On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
> > Currently the DSI driver has two separate paths: one if the next device
> > in a chain is a bridge and another one if the panel is connected
> > directly to the DSI host. Simplify the code path by using panel-bridge
> > driver (already selected in Kconfig) and dropping support for
> > handling the panel directly.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/dsi/dsi.c | 32 +---
> > drivers/gpu/drm/msm/dsi/dsi.h | 10 +-
> > drivers/gpu/drm/msm/dsi/dsi_host.c| 20 +-
> > drivers/gpu/drm/msm/dsi/dsi_manager.c | 257 +++---
> > 4 files changed, 32 insertions(+), 287 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> > index 9670e548b3e9..b61f451a282e 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> > @@ -208,7 +208,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
> > struct drm_device *dev,
> >struct drm_encoder *encoder)
> > {
> > struct msm_drm_private *priv;
> > - struct drm_bridge *ext_bridge;
> > + struct drm_connector *connector;
> > int ret;
> >
> > if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))
> > @@ -238,31 +238,17 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
> > struct drm_device *dev,
> > goto fail;
> > }
> >
> > - /*
> > - * check if the dsi encoder output is connected to a panel or an
> > - * external bridge. We create a connector only if we're connected to a
> > - * drm_panel device. When we're connected to an external bridge, we
> > - * assume that the drm_bridge driver will create the connector itself.
> > - */
> > - ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
> > -
> > - if (ext_bridge)
> > - msm_dsi->connector =
> > - msm_dsi_manager_ext_bridge_init(msm_dsi->id);
> > - else
> > - msm_dsi->connector =
> > - msm_dsi_manager_connector_init(msm_dsi->id);
> > -
> > - if (IS_ERR(msm_dsi->connector)) {
> > - ret = PTR_ERR(msm_dsi->connector);
> > + connector = msm_dsi_manager_ext_bridge_init(msm_dsi->id);
> > +
> > + if (IS_ERR(connector)) {
> > + ret = PTR_ERR(connector);
> > DRM_DEV_ERROR(dev->dev,
> > "failed to create dsi connector: %d\n", ret);
> > - msm_dsi->connector = NULL;
> > goto fail;
> > }
> Please correct my understanding if incorrect. Here you are expecting
> that the existing panels/bridges have already used
> drm_panel_bridge_add_typed add the bridge? Otherwise we will goto the
> fail goto?
No.
>
> @@ -727,8 +509,11 @@ struct drm_connector
> *msm_dsi_manager_ext_bridge_init(u8 id)
> int ret;
>
> int_bridge = msm_dsi->bridge;
> - ext_bridge = msm_dsi->external_bridge =
> - msm_dsi_host_get_bridge(msm_dsi->host);
> + ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
> + if (IS_ERR(ext_bridge))
> + return ERR_PTR(PTR_ERR(ext_bridge));
> +
> + msm_dsi->external_bridge = ext_bridge;
>
> Does that mean you plan to migrate the existing msm panels/bridges to
> use devm_drm_panel_bridge_add_typed?
No. panel-bridge.c/devm_drm_of_get_bridge() does that in a transparent
way. It calls devm_drm_panel_bridge_add() on it's own.
> >
> > priv->bridges[priv->num_bridges++] = msm_dsi->bridge;
> > - priv->connectors[priv->num_connectors++] = msm_dsi->connector;
> > + priv->connectors[priv->num_connectors++] = connector;
> >
> > return 0;
> > fail:
> > @@ -272,12 +258,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
> > struct drm_device *dev,
> > msm_dsi->bridge = NULL;
> > }
> >
> > - /* don't destroy connector if we didn't make it */
> > - if (msm_dsi->connector && !msm_dsi->external_bridge)
> > - msm_dsi->connector->funcs->destroy(msm_dsi->connector);
> > -
> > - msm_dsi->connector = NULL;
> > -
> > return ret;
> > }
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> > index f46df52c6985..7eb778070a8c 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi.h
> > +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> > @@ -49,8 +49,6 @@ struct msm_dsi {
> > struct drm_device *dev;
> > struct platform_device *pdev;
> >
> > - /* connector managed by us when we're connected to a drm_panel */
> > - struct drm_connector *connector;
> > /* internal dsi bridge attached to MDP interface */
> > struct drm_bridge *bridge;
> >
> > @@ -58,10 +56,8 @@ struct msm_dsi {
> > struct msm_dsi_phy *phy;
> >
> > /*
> > - * panel/external_bridge connected to dsi bridge output, only one of
> > the
> > -
Re: [Freedreno] [PATCH v2] drm/msm: reduce usage of round_pixclk callback
On 1/5/2022 11:06 PM, Dmitry Baryshkov wrote:
The round_pixclk() callback returns different rate only on MDP4 in HDMI
(DTV) case. Stop using this callback in other cases to simplify
mode_valid callbacks.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
Changes since v1:
- Rebased on top of HDMI changes
- Dropped eDP part, driver got removed
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 ---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 7 ---
drivers/gpu/drm/msm/dsi/dsi_manager.c| 22 --
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 11 +++
4 files changed, 7 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 47fe11a84a77..ebbee5f103e1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -774,12 +774,6 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
return ret;
}
-static long dpu_kms_round_pixclk(struct msm_kms *kms, unsigned long rate,
- struct drm_encoder *encoder)
-{
- return rate;
-}
-
static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
{
int i;
@@ -948,7 +942,6 @@ static const struct msm_kms_funcs kms_funcs = {
.disable_vblank = dpu_kms_disable_vblank,
.check_modified_format = dpu_format_check_modified_format,
.get_format = dpu_get_msm_format,
- .round_pixclk= dpu_kms_round_pixclk,
.destroy = dpu_kms_destroy,
.snapshot= dpu_kms_mdp_snapshot,
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 12a5f81e402b..20859fd7af4a 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -190,12 +190,6 @@ static void mdp5_complete_commit(struct msm_kms *kms,
unsigned crtc_mask)
mdp5_smp_complete_commit(mdp5_kms->smp, &global_state->smp);
}
-static long mdp5_round_pixclk(struct msm_kms *kms, unsigned long rate,
- struct drm_encoder *encoder)
-{
- return rate;
-}
-
static int mdp5_set_split_display(struct msm_kms *kms,
struct drm_encoder *encoder,
struct drm_encoder *slave_encoder,
@@ -278,7 +272,6 @@ static const struct mdp_kms_funcs kms_funcs = {
.wait_flush = mdp5_wait_flush,
.complete_commit = mdp5_complete_commit,
.get_format = mdp_get_format,
- .round_pixclk= mdp5_round_pixclk,
.set_split_display = mdp5_set_split_display,
.destroy = mdp5_kms_destroy,
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index f19bae475c96..1dbbfca163d9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -305,27 +305,6 @@ static int dsi_mgr_connector_get_modes(struct
drm_connector *connector)
return num;
}
-static enum drm_mode_status dsi_mgr_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- int id = dsi_mgr_connector_get_id(connector);
- struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
- struct drm_encoder *encoder = msm_dsi_get_encoder(msm_dsi);
- struct msm_drm_private *priv = connector->dev->dev_private;
- struct msm_kms *kms = priv->kms;
- long actual, requested;
-
- DBG("");
- requested = 1000 * mode->clock;
- actual = kms->funcs->round_pixclk(kms, requested, encoder);
-
- DBG("requested=%ld, actual=%ld", requested, actual);
- if (actual != requested)
- return MODE_CLOCK_RANGE;
-
- return MODE_OK;
-}
-
static struct drm_encoder *
dsi_mgr_connector_best_encoder(struct drm_connector *connector)
{
@@ -586,7 +565,6 @@ static const struct drm_connector_funcs
dsi_mgr_connector_funcs = {
static const struct drm_connector_helper_funcs dsi_mgr_conn_helper_funcs = {
.get_modes = dsi_mgr_connector_get_modes,
- .mode_valid = dsi_mgr_connector_mode_valid,
.best_encoder = dsi_mgr_connector_best_encoder,
};
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 68fba4bf7212..10ebe2089cb6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -282,15 +282,18 @@ static enum drm_mode_status
msm_hdmi_bridge_mode_valid(struct drm_bridge *bridge
long actual, requested;
requested = 1000 * mode->clock;
- actual = kms->funcs->round_pixclk(kms,
- requested, hdmi_bridge->hdmi->encoder);
/* for mdp5/apq8074, we manage our own pixel clk (as opposed to
* mdp4/dtv stuff where pixel clk is assigned to mdp/encoder
* instead):
*/
Re: [PATCH] drm/dp: Remove common Post Cursor2 register handling
On 1/5/22 11:35, Kees Cook wrote:
> The link_status array was not large enough to read the Adjust Request
> Post Cursor2 register, so remove the common helper function to avoid
> an OOB read, found with a -Warray-bounds build:
>
> drivers/gpu/drm/drm_dp_helper.c: In function
> 'drm_dp_get_adjust_request_post_cursor':
> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside
> array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
> [-Werror=array-bounds]
>59 | return link_status[r - DP_LANE0_1_STATUS];
> |~~~^~~
> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> |
> ~^~~~
>
> Replace the only user of the helper with an open-coded fetch and decode,
> similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
>
> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
This should be tagged for -stable:
Cc: sta...@vger.kernel.org
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Kees Cook
Reviewed-by: Gustavo A. R. Silva
Thanks
--
Gustavo
> ---
> This is the alternative to:
> https://lore.kernel.org/lkml/20211203084354.3105253-1-keesc...@chromium.org/
> ---
> drivers/gpu/drm/drm_dp_helper.c | 10 --
> drivers/gpu/drm/tegra/dp.c | 11 ++-
> include/drm/drm_dp_helper.h | 2 --
> 3 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 23f9073bc473..c9528aa62c9c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
>
> -u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane)
> -{
> - unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
> - u8 value = dp_link_status(link_status, offset);
> -
> - return (value >> (lane << 1)) & 0x3;
> -}
> -EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
> -
> static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8
> rd_interval)
> {
> if (rd_interval > 4)
> diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
> index 70dfb7d1dec5..f5535eb04c6b 100644
> --- a/drivers/gpu/drm/tegra/dp.c
> +++ b/drivers/gpu/drm/tegra/dp.c
> @@ -549,6 +549,15 @@ static void drm_dp_link_get_adjustments(struct
> drm_dp_link *link,
> {
> struct drm_dp_link_train_set *adjust = &link->train.adjust;
> unsigned int i;
> + u8 post_cursor;
> + int err;
> +
> + err = drm_dp_dpcd_read(link->aux, DP_ADJUST_REQUEST_POST_CURSOR2,
> +&post_cursor, sizeof(post_cursor));
> + if (err < 0) {
> + DRM_ERROR("failed to read post_cursor2: %d\n", err);
> + post_cursor = 0;
> + }
>
> for (i = 0; i < link->lanes; i++) {
> adjust->voltage_swing[i] =
> @@ -560,7 +569,7 @@ static void drm_dp_link_get_adjustments(struct
> drm_dp_link *link,
> DP_TRAIN_PRE_EMPHASIS_SHIFT;
>
> adjust->post_cursor[i] =
> - drm_dp_get_adjust_request_post_cursor(status, i);
> + (post_cursor >> (i << 1)) & 0x3;
> }
> }
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 472dac376284..fdf3cf6ccc02 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> int lane);
> u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane);
> -u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane);
>
> #define DP_BRANCH_OUI_HEADER_SIZE0xc
> #define DP_RECEIVER_CAP_SIZE 0xf
>
Re: [PATCH 2/2] drm/msm/dsi: switch to DRM_PANEL_BRIDGE
On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and dropping support for
handling the panel directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 32 +---
drivers/gpu/drm/msm/dsi/dsi.h | 10 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 20 +-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 257 +++---
4 files changed, 32 insertions(+), 287 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 9670e548b3e9..b61f451a282e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,7 +208,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
struct drm_encoder *encoder)
{
struct msm_drm_private *priv;
- struct drm_bridge *ext_bridge;
+ struct drm_connector *connector;
int ret;
if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))
@@ -238,31 +238,17 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
goto fail;
}
- /*
-* check if the dsi encoder output is connected to a panel or an
-* external bridge. We create a connector only if we're connected to a
-* drm_panel device. When we're connected to an external bridge, we
-* assume that the drm_bridge driver will create the connector itself.
-*/
- ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
-
- if (ext_bridge)
- msm_dsi->connector =
- msm_dsi_manager_ext_bridge_init(msm_dsi->id);
- else
- msm_dsi->connector =
- msm_dsi_manager_connector_init(msm_dsi->id);
-
- if (IS_ERR(msm_dsi->connector)) {
- ret = PTR_ERR(msm_dsi->connector);
+ connector = msm_dsi_manager_ext_bridge_init(msm_dsi->id);
+
+ if (IS_ERR(connector)) {
+ ret = PTR_ERR(connector);
DRM_DEV_ERROR(dev->dev,
"failed to create dsi connector: %d\n", ret);
- msm_dsi->connector = NULL;
goto fail;
}
Please correct my understanding if incorrect. Here you are expecting
that the existing panels/bridges have already used
drm_panel_bridge_add_typed add the bridge? Otherwise we will goto the
fail goto?
@@ -727,8 +509,11 @@ struct drm_connector
*msm_dsi_manager_ext_bridge_init(u8 id)
int ret;
int_bridge = msm_dsi->bridge;
- ext_bridge = msm_dsi->external_bridge =
- msm_dsi_host_get_bridge(msm_dsi->host);
+ ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
+ if (IS_ERR(ext_bridge))
+ return ERR_PTR(PTR_ERR(ext_bridge));
+
+ msm_dsi->external_bridge = ext_bridge;
Does that mean you plan to migrate the existing msm panels/bridges to
use devm_drm_panel_bridge_add_typed?
priv->bridges[priv->num_bridges++] = msm_dsi->bridge;
- priv->connectors[priv->num_connectors++] = msm_dsi->connector;
+ priv->connectors[priv->num_connectors++] = connector;
return 0;
fail:
@@ -272,12 +258,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
msm_dsi->bridge = NULL;
}
- /* don't destroy connector if we didn't make it */
- if (msm_dsi->connector && !msm_dsi->external_bridge)
- msm_dsi->connector->funcs->destroy(msm_dsi->connector);
-
- msm_dsi->connector = NULL;
-
return ret;
}
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index f46df52c6985..7eb778070a8c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -49,8 +49,6 @@ struct msm_dsi {
struct drm_device *dev;
struct platform_device *pdev;
- /* connector managed by us when we're connected to a drm_panel */
- struct drm_connector *connector;
/* internal dsi bridge attached to MDP interface */
struct drm_bridge *bridge;
@@ -58,10 +56,8 @@ struct msm_dsi {
struct msm_dsi_phy *phy;
/*
-* panel/external_bridge connected to dsi bridge output, only one of the
-* two can be valid at a time
+* external_bridge connected to dsi bridge output
*/
- struct drm_panel *panel;
struct drm_bridge *external_bridge;
struct device *phy_dev;
@@ -76,7 +72,6 @@ struct msm_dsi {
/* dsi manager */
struct drm_bridge *msm_dsi_manager_bridge_init(u8 id);
void msm_dsi_manager_bridge_destroy(struct drm_bridge *bridge);
-struct drm_connector *msm_dsi_manager_connector_init(u8 id);
struct drm_connector *msm_dsi_manager_ext_bridge_init(u8 id);
int msm_ds
Re: [PATCH 1/2] drm/msm/dsi: move DSI host powerup to modeset time
On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
The DSI subsystem does not fully fall into the pre-enable/enable system
of callbacks, since typically DSI device bridge drivers expect to be
able to communicate with DSI devices at the pre-enable() callback. The
reason is that for some DSI hosts enabling the video stream would
prevent other drivers from sending DSI commands. For example see the
panel-bridge driver, which does drm_panel_prepare() from the
pre_enable() callback (which would be called before our pre_enable()
callback, resulting in panel preparation failures as the link is not yet
ready).
Therewere several attempts to solve this issue, but currently the best
approach is to power up the DSI link from the mode_set() callback,
allowing next bridge/panel to use DSI transfers in the pre_enable()
time. Follow this approach.
Change looks okay. As per the programming guideline, we should set the
VIDEO_MODE_EN register in the DSI controller followed by enabling the
timing engine which will still happen even now because we will do it in
modeset instead of the pre_enable().
But, this can potentially increase the delay between VIDEO_MODE_EN
and TIMING_ENGINE_EN. I dont see anything in the programming guide
against this but since this is a change from the original flow, I would
like to do one test before acking this. Can you please try adding a huge
delay like 200-300ms between VIDEO_MODE_EN and timing engine enable to
make sure there are no issues? You can do that here:
int msm_dsi_host_enable(struct mipi_dsi_host *host)
{
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
dsi_op_mode_config(msm_host,
!!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO), true);
msleep(300);
}
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 43 +++
1 file changed, 31 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 681ca74fe410..497719efb9e9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -336,13 +336,12 @@ dsi_mgr_connector_best_encoder(struct drm_connector
*connector)
return msm_dsi_get_encoder(msm_dsi);
}
-static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
+static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
{
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
struct mipi_dsi_host *host = msm_dsi->host;
- struct drm_panel *panel = msm_dsi->panel;
struct msm_dsi_phy_shared_timings phy_shared_timings[DSI_MAX];
bool is_bonded_dsi = IS_BONDED_DSI();
int ret;
@@ -383,6 +382,34 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (is_bonded_dsi && msm_dsi1)
msm_dsi_host_enable_irq(msm_dsi1->host);
+ return;
+
+host1_on_fail:
+ msm_dsi_host_power_off(host);
+host_on_fail:
+ dsi_mgr_phy_disable(id);
+phy_en_fail:
+ return;
+}
+
+static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
+{
+ int id = dsi_mgr_bridge_get_id(bridge);
+ struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
+ struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
+ struct mipi_dsi_host *host = msm_dsi->host;
+ struct drm_panel *panel = msm_dsi->panel;
+ bool is_bonded_dsi = IS_BONDED_DSI();
+ int ret;
+
+ DBG("id=%d", id);
+ if (!msm_dsi_device_connected(msm_dsi))
+ return;
+
+ /* Do nothing with the host if it is slave-DSI in case of bonded DSI */
+ if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
+ return;
+
/* Always call panel functions once, because even for dual panels,
* there is only one drm_panel instance.
*/
@@ -417,17 +444,7 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (panel)
drm_panel_unprepare(panel);
panel_prep_fail:
- msm_dsi_host_disable_irq(host);
- if (is_bonded_dsi && msm_dsi1)
- msm_dsi_host_disable_irq(msm_dsi1->host);
- if (is_bonded_dsi && msm_dsi1)
- msm_dsi_host_power_off(msm_dsi1->host);
-host1_on_fail:
- msm_dsi_host_power_off(host);
-host_on_fail:
- dsi_mgr_phy_disable(id);
-phy_en_fail:
return;
}
@@ -573,6 +590,8 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge *bridge,
msm_dsi_host_set_display_mode(host, adjusted_mode);
if (is_bonded_dsi && other_dsi)
msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode);
+
+ dsi_mgr_bridge_power_on(bridge);
}
static const struct drm_connector_funcs dsi_mgr_connector_funcs = {
Re: [PATCH v11 03/19] dyndbg: add write-to-tracefs code
On Fri, Jan 14, 2022 at 4:46 AM Vincent Whitchurch wrote: > > On Fri, Jan 07, 2022 at 06:29:26AM +0100, Jim Cromie wrote: > > > > Enabling debug-to-tracefs is 2 steps: > > > > # event enable > > echo 1 > /sys/kernel/tracing/events/dyndbg/enable > > # callsite enable > > echo module foo +T > /proc/dynamic_debug/control > > > > This patch,~1,~2 are based upon: > > > > https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchu...@axis.com/ > > > > .. with simplification of temporarily reusing trace_console() rather > > than adding a new printk:dyndbg event. Soon, add 2 new events > > capturing the pr_debug & dev_dbg() args. > > The example above does not match the code in this patch since the > dyndbg:* events are only added in a later patch. Perhaps you could > reorder this patch stack so that you don't use trace_console() in this > patch just to replace it with the new events in the next patch? > good catch, thanks. Ive just dropped the example, it seemed the simplest fix. It seemed proper to commit your code as pristine as practical, so that subsequent mistakes receive the blame. and Ive fixed the spurious whitespace change you noted.
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
We should probably Cc: sta...@vger.kernel.org this as well, see: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for more info. As well, some useful tools for adding the appropriate Fixes: tags: https://drm.pages.freedesktop.org/maintainer-tools/dim.html At least on my end this is: Acked-by: Lyude Paul I'd very much like Thomas Zimmerman to verify that this patch is OK though with an R-b before we push anything upstream. On Fri, 2022-01-14 at 10:47 +0100, Jocelyn Falempe wrote: > On some server with MGA G200e (rev 42), booting with Legacy BIOS, > The hardware hangs when using kdump and kexec into the kdump kernel. > This happens when the uncompress code tries to write "Decompressing Linux" > to the VGA Console. > > It can be reproduced by writing to the VGA console (0xB8000) after > booting to graphic mode, it generates the following error: > > kernel:NMI: PCI system error (SERR) for reason a0 on CPU 0. > kernel:Dazed and confused, but trying to continue > > The root cause is a bad configuration of the MGA GCTL6 register > > According to the GCTL6 register documentation: > > bit 0 is gcgrmode: > 0: Enables alpha mode, and the character generator addressing system is > activated. > 1: Enables graphics mode, and the character addressing system is not > used. > > bit 1 is chainodd even: > 0: The A0 signal of the memory address bus is used during system memory > addressing. > 1: Allows A0 to be replaced by either the A16 signal of the system > address (if > memmapsl is ‘00’), or by the hpgoddev (MISC<5>, odd/even page select) > field, > described on page 3-294). > > bit 3-2 are memmapsl: > Memory map select bits 1 and 0. VGA. > These bits select where the video memory is mapped, as shown below: > 00 => Ah - Bh > 01 => Ah - Ah > 10 => Bh - B7FFFh > 11 => B8000h - Bh > > bit 7-4 are reserved. > > Current driver code set it to 0x05 => memmapsl to b01 => 0xA > but on x86, the VGA console is at 0xB8000 > arch/x86/boot/compressed/misc.c define vidmem to 0xb8000 in extract_kernel() > so it's better to configure it to b11 > Thus changing the value 0x05 to 0x0d > > Signed-off-by: Jocelyn Falempe > --- > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c > b/drivers/gpu/drm/mgag200/mgag200_mode.c > index b983541a4c53..c7f63610b278 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_mode.c > +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c > @@ -529,7 +529,7 @@ static void mgag200_set_format_regs(struct mga_device > *mdev, > WREG_GFX(3, 0x00); > WREG_GFX(4, 0x00); > WREG_GFX(5, 0x40); > - WREG_GFX(6, 0x05); > + WREG_GFX(6, 0x0d); > WREG_GFX(7, 0x0f); > WREG_GFX(8, 0x0f); > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH] drm/vmwgfx: Stop requesting the pci regions
Hello Zack,
On 1/17/22 19:03, Zack Rusin wrote:
> From: Zack Rusin
>
> When sysfb_simple is enabled loading vmwgfx fails because the regions
> are held by the platform. In that case remove_conflicting*_framebuffers
> only removes the simplefb but not the regions held by sysfb.
>
Indeed, that's an issue. I wonder if we should drop the IORESOURCE_BUSY
flag from the memory resource added to the "simple-framebuffer" device ?
In fact, maybe in sysfb_create_simplefb() shouldn't even attempt to claim
a memory resource and just register the platform device with no resources ?
> Like the other drm drivers we need to stop requesting all the pci regions
> to let the driver load with platform code enabled.
> This allows vmwgfx to load correctly on systems with sysfb_simple enabled.
>
I read this very interesting thread from two years ago:
https://lkml.org/lkml/2020/11/5/248
Maybe is worth mentioning in the commit message what Daniel said there,
that is that only a few DRM drivers request explicitly the PCI regions
and the only reliable approach is for bus drivers to claim these.
In other words, removing the pci_request_regions() seems to have merit
on its own.
> Signed-off-by: Zack Rusin
> Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64")
> Cc: dri-devel@lists.freedesktop.org
> Cc:
> Reviewed-by: Martin Krastev
> ---
The patch looks good to me, thanks a lot for fixing this:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH v3] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Tue, Jan 18, 2022 at 06:34:20PM +0200, Ville Syrjälä wrote:
> On Fri, Oct 22, 2021 at 12:51:12PM -0700, Navare, Manasi wrote:
> >
> > Hi Ville,
> >
> > Could you take a look at this, this addresses teh review comments from prev
> > version
>
> I don't think I ever got an answer to my question as to whether this
> was tested with all the interesting scenarios:
> 1) just with the master crtc added by userspace into the commit
> 2) just with the slave crtc added by userspace into the commit
> 3) both crtcs added by userspace into the commit
>
> I guess 1) has been tested since that happens all the time, but the other
> two scanarios would likely need to be done with a synthetic test to make
> sure we're actually hitting them.
>
> I think it *should* work, but I'd like to have real proof of that.
> Reviewed-by: Ville Syrjälä
Thank you for your review here Ville.
I have triggered a separate email thread to understand all the above testing
scenarios and get them tested with bigjoiner IGT.
Manasi
>
> >
> > Manasi
> >
> > On Mon, Oct 04, 2021 at 04:59:13AM -0700, Manasi Navare wrote:
> > > In case of a modeset where a mode gets split across mutiple CRTCs
> > > in the driver specific implementation (bigjoiner in i915) we wrongly count
> > > the affected CRTCs based on the drm_crtc_mask and indicate the stolen
> > > CRTC as
> > > an affected CRTC in atomic_check_only().
> > > This triggers a warning since affected CRTCs doent match requested CRTC.
> > >
> > > To fix this in such bigjoiner configurations, we should only
> > > increment affected crtcs if that CRTC is enabled in UAPI not
> > > if it is just used internally in the driver to split the mode.
> > >
> > > v3: Add the same uapi crtc_state->enable check in requested
> > > crtc calc (Ville)
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Simon Ser
> > > Cc: Pekka Paalanen
> > > Cc: Daniel Stone
> > > Cc: Daniel Vetter
> > > Cc: dri-devel@lists.freedesktop.org
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 12
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index ff1416cd609a..a1e4c7905ebb 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1310,8 +1310,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > > *state)
> > >
> > > DRM_DEBUG_ATOMIC("checking %p\n", state);
> > >
> > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > - requested_crtc |= drm_crtc_mask(crtc);
> > > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->enable)
> > > + requested_crtc |= drm_crtc_mask(crtc);
> > > + }
> > >
> > > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > > new_plane_state, i) {
> > > ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> > > @@ -1360,8 +1362,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > > *state)
> > > }
> > > }
> > >
> > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > - affected_crtc |= drm_crtc_mask(crtc);
> > > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->enable)
> > > + affected_crtc |= drm_crtc_mask(crtc);
> > > + }
> > >
> > > /*
> > >* For commits that allow modesets drivers can add other CRTCs to the
> > > --
> > > 2.19.1
> > >
>
> --
> Ville Syrjälä
> Intel
[drm-tip:drm-tip 8/10] drivers/gpu/drm/i915/i915_gem_evict.h:15:15: error: declaration of 'struct i915_gem_ww_ctx' will not be visible outside of this function
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: ceefc39c8abf37ff93eb36001f82e725756863c8 commit: e38294cfc29f789b541ecc08be2e578da746663c [8/10] Merge remote-tracking branch 'drm-intel/drm-intel-gt-next' into drm-tip config: x86_64-randconfig-a002-20220117 (https://download.01.org/0day-ci/archive/20220119/202201190210.q12rphmz-...@intel.com/config) compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project c10cbb243cafc0cf42c3e922cb2918327932) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git remote add drm-tip git://anongit.freedesktop.org/drm/drm-tip git fetch --no-tags drm-tip drm-tip git checkout e38294cfc29f789b541ecc08be2e578da746663c # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from :4: >> drivers/gpu/drm/i915/i915_gem_evict.h:15:15: error: declaration of 'struct >> i915_gem_ww_ctx' will not be visible outside of this function >> [-Werror,-Wvisibility] struct i915_gem_ww_ctx *ww, ^ drivers/gpu/drm/i915/i915_gem_evict.h:21:14: error: declaration of 'struct i915_gem_ww_ctx' will not be visible outside of this function [-Werror,-Wvisibility] struct i915_gem_ww_ctx *ww, ^ drivers/gpu/drm/i915/i915_gem_evict.h:25:16: error: declaration of 'struct i915_gem_ww_ctx' will not be visible outside of this function [-Werror,-Wvisibility] struct i915_gem_ww_ctx *ww); ^ 3 errors generated. vim +15 drivers/gpu/drm/i915/i915_gem_evict.h 13 14 int __must_check i915_gem_evict_something(struct i915_address_space *vm, > 15struct i915_gem_ww_ctx *ww, 16u64 min_size, u64 alignment, 17unsigned long color, 18u64 start, u64 end, 19unsigned flags); 20 int __must_check i915_gem_evict_for_node(struct i915_address_space *vm, 21 struct i915_gem_ww_ctx *ww, 22 struct drm_mm_node *node, 23 unsigned int flags); 24 int i915_gem_evict_vm(struct i915_address_space *vm, 25struct i915_gem_ww_ctx *ww); 26 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH v18 3/4] drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
-- change state_ctrl_bits type to u32 and pattern type to u8
Changes in V4:
-- align } else if { and } else {
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++--
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 17 -
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 6ae9b29..64f0b26 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -456,19 +456,19 @@ void dp_catalog_ctrl_config_msa(struct dp_catalog
*dp_catalog,
dp_write_p0(catalog, MMSS_DP_DSC_DTO, 0x0);
}
-int dp_catalog_ctrl_set_pattern(struct dp_catalog *dp_catalog,
- u32 pattern)
+int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog,
+ u32 state_bit)
{
int bit, ret;
u32 data;
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
- bit = BIT(pattern - 1);
- DRM_DEBUG_DP("hw: bit=%d train=%d\n", bit, pattern);
+ bit = BIT(state_bit - 1);
+ DRM_DEBUG_DP("hw: bit=%d train=%d\n", bit, state_bit);
dp_catalog_ctrl_state_ctrl(dp_catalog, bit);
- bit = BIT(pattern - 1) << DP_MAINLINK_READY_LINK_TRAINING_SHIFT;
+ bit = BIT(state_bit - 1) << DP_MAINLINK_READY_LINK_TRAINING_SHIFT;
/* Poll for mainlink ready status */
ret = readx_poll_timeout(readl, catalog->io->dp_controller.link.base +
@@ -476,7 +476,7 @@ int dp_catalog_ctrl_set_pattern(struct dp_catalog
*dp_catalog,
data, data & bit,
POLLING_SLEEP_US, POLLING_TIMEOUT_US);
if (ret < 0) {
- DRM_ERROR("set pattern for link_train=%d failed\n", pattern);
+ DRM_ERROR("set state_bit for link_train=%d failed\n",
state_bit);
return ret;
}
return 0;
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 6965afa..7dea101 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -94,7 +94,7 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32
tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
u32 stream_rate_khz, bool fixed_nvid);
-int dp_catalog_ctrl_set_pattern(struct dp_catalog *dp_catalog, u32 pattern);
+int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog, u32
pattern);
void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
bool dp_catalog_ctrl_mainlink_ready(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_enable_irq(struct dp_catalog *dp_catalog, bool enable);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 9c80b49..f98df93 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1083,7 +1083,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private
*ctrl,
*training_step = DP_TRAINING_1;
- ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, DP_TRAINING_PATTERN_1);
+ ret = dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, 1);
if (ret)
return ret;
dp_ctrl_train_pattern_set(ctrl, DP_TRAINING_PATTERN_1 |
@@ -1181,7 +1181,8 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private
*ctrl,
int *training_step)
{
int tries = 0, ret = 0;
- char pattern;
+ u8 pattern;
+ u32 state_ctrl_bit;
int const maximum_retries = 5;
u8 link_status[DP_LINK_STATUS_SIZE];
@@ -1189,12 +1190,18 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private
*ctrl,
*training_step = DP_TRAINING_2;
- if (drm_dp_tps3_supported(ctrl->panel->dpcd))
+ if (drm_dp_tps4_supported(ctrl->panel->dpcd)) {
+ pattern = DP_TRAINING_PATTERN_4;
+ state_ctrl_bit = 4;
+ } else if (drm_dp_tps3_supported(ctrl->panel->dpcd)) {
pattern = DP_TRAINING_PATTERN_3;
- else
+ state_ctrl_bit = 3;
+ } else {
pattern = DP_TRAINING_PATTERN_2;
+ state_ctrl_bit = 2;
+ }
- ret = dp_c
[PATCH v18 4/4] drm/msm/dp: stop link training after link training 2 failed
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This patch fixes link compliance
test case 4.3.1.13 (Source Device Link Training EQ Fallback Test).
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
Fixes: 2e0adc765d88 ("drm/msm/dp: do not end dp link training until video is
ready")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index f98df93..245e1b9 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1755,6 +1755,9 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
/* end with failure */
break; /* lane == 1 already */
}
+
+ /* stop link training before start re training */
+ dp_ctrl_clear_training_pattern(ctrl);
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v18 2/4] drm/msm/dp: populate connector of struct dp_panel
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
connector is stored in struct msm_dp::connector. When we run compliance
testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid
edid set in struct dp_panel::edid so we'll try to use the connectors
real_edid_checksum and hit a NULL pointer dereference error because the
connector pointer is never assigned.
Changes in V2:
-- populate panel connector at msm_dp_modeset_init() instead of at
dp_panel_read_sink_caps()
Changes in V3:
-- remove unhelpful kernel crash trace commit text
-- remove renaming dp_display parameter to dp
Changes in V4:
-- add more details to commit text
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
Fixes: 7948fe12d47 ("drm/msm/dp: return correct edid checksum after corrupted
edid checksum read")
Signee-off-by: Kuogee Hsieh
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 3059023..1d7f82e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1463,6 +1463,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
struct drm_encoder *encoder)
{
struct msm_drm_private *priv;
+ struct dp_display_private *dp_priv;
int ret;
if (WARN_ON(!encoder) || WARN_ON(!dp_display) || WARN_ON(!dev))
@@ -1471,6 +1472,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
priv = dev->dev_private;
dp_display->drm_dev = dev;
+ dp_priv = container_of(dp_display, struct dp_display_private,
dp_display);
+
ret = dp_display_request_irq(dp_display);
if (ret) {
DRM_ERROR("request_irq failed, ret=%d\n", ret);
@@ -1488,6 +1491,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
return ret;
}
+ dp_priv->panel->connector = dp_display->connector;
+
priv->connectors[priv->num_connectors++] = dp_display->connector;
dp_display->bridge = msm_dp_bridge_init(dp_display, dev, encoder);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v18 1/4] drm/msm/dp: do not initialize phy until plugin interrupt received
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume (including booting up), dongle plugin, dongle unplugged and suspend.
Regulators, core clocks and irq are grouped together and enabled at resume
(or booting up) so that the DP controller is armed and ready to receive HPD
plugin interrupts. HPD plugin interrupt is generated when a dongle plugs
into DUT (device under test). Once HPD plugin interrupt is received, DP
controller will initialize phy so that dpcd read/write will function and
following link training can be proceeded successfully. DP phy will be
disabled after main link is teared down at end of unplugged HPD interrupt
handle triggered by dongle unplugged out of DUT. Finally regulators, code
clocks and irq are disabled at corresponding suspension.
Changes in V2:
-- removed unnecessary dp_ctrl NULL check
-- removed unnecessary phy init_count and power_count DRM_DEBUG_DP logs
-- remove flip parameter out of dp_ctrl_irq_enable()
-- add fixes tag
Changes in V3:
-- call dp_display_host_phy_init() instead of dp_ctrl_phy_init() at
dp_display_host_init() for eDP
Changes in V4:
-- rewording commit text to match this commit changes
Changes in V5:
-- rebase on top of msm-next branch
Changes in V6:
-- delete flip variable
Changes in V7:
-- dp_ctrl_irq_enable/disabe() merged into dp_ctrl_reset_irq_ctrl()
Changes in V8:
-- add more detail comment regrading dp phy at dp_display_host_init()
Changes in V9:
-- remove set phy_initialized to false when -ECONNRESET detected
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately
if aux read
Changes in v12:
-- move dp_display_host_phy_exit() after dp_display_host_deinit()
Changes in v13:
-- do not execute phy_init until plugged_in interrupt for edp, same as DP.
Changes in v14:
-- remove redundant dp->core_initialized = false form dp_pm_suspend.
Changes in v15:
-- remove core_initialized flag check at both host_init and host_deinit
Changes in v16:
-- remove dp_display_host_phy_exit core_initialized=false at dp_pm_suspend
Changes in v17:
-- remove core_initialized checking before execute attention_cb()
Changes in v18:
-- remove core_initialized checking at dp_pm_suspend
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 80 ++
drivers/gpu/drm/msm/dp/dp_ctrl.h| 8 ++-
drivers/gpu/drm/msm/dp/dp_display.c | 111 ++--
3 files changed, 92 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index c724cb0..9c80b49 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1365,60 +1365,44 @@ static int dp_ctrl_enable_stream_clocks(struct
dp_ctrl_private *ctrl)
return ret;
}
-int dp_ctrl_host_init(struct dp_ctrl *dp_ctrl, bool flip, bool reset)
+void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable)
+{
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ dp_catalog_ctrl_reset(ctrl->catalog);
+
+ if (enable)
+ dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
+}
+
+void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
struct dp_io *dp_io;
struct phy *phy;
- if (!dp_ctrl) {
- DRM_ERROR("Invalid input data\n");
- return -EINVAL;
- }
-
ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
dp_io = &ctrl->parser->io;
phy = dp_io->phy;
- ctrl->dp_ctrl.orientation = flip;
-
- if (reset)
- dp_catalog_ctrl_reset(ctrl->catalog);
-
- DRM_DEBUG_DP("flip=%d\n", flip);
dp_catalog_ctrl_phy_reset(ctrl->catalog);
phy_init(phy);
- dp_catalog_ctrl_enable_irq(ctrl->catalog, true);
-
- return 0;
}
-/**
- * dp_ctrl_host_deinit() - Uninitialize DP controller
- * @dp_ctrl: Display Port Driver data
- *
- * Perform required steps to uninitialize DP controller
- * and its resources.
- */
-void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
+void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
struct dp_io *dp_io;
struct phy *phy;
- if (!dp_ctrl) {
- DRM_ERROR("Invalid input data\n");
- return;
- }
-
ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
dp_io = &ctrl->parser->io;
phy = dp_io->phy;
- dp_catalog_ctrl_enable_irq(ctrl->catalog, false);
+ dp_catalog_ctrl_phy_reset(ctrl->catalog)
[PATCH v18 0/4] group dp driver related patches into one series
Group below 4 dp driver related patches into one series. Kuogee Hsieh (4): drm/msm/dp: do not initialize phy until plugin interrupt received drm/msm/dp: populate connector of struct dp_panel drm/msm/dp: add support of tps4 (training pattern 4) for HBR3 drm/msm/dp: stop link training after link training 2 failed drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++-- drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +- drivers/gpu/drm/msm/dp/dp_ctrl.c| 100 ++- drivers/gpu/drm/msm/dp/dp_ctrl.h| 8 ++- drivers/gpu/drm/msm/dp/dp_display.c | 116 +++- 5 files changed, 119 insertions(+), 119 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 2/2] staging: fbtft: Deduplicate driver registration macros
The two macros FBTFT_REGISTER_DRIVER and FBTFT_REGISTER_SPI_DRIVER
contain quite some duplication: Both define an spi driver and an of device
table and the differences are quite subtle.
So create two new macros and use both twice.
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft/fbtft.h | 93 ++-
1 file changed, 36 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 55677efc0138..6a7545b5bcd2 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -272,21 +272,40 @@ void fbtft_write_reg8_bus9(struct fbtft_par *par, int
len, ...);
void fbtft_write_reg16_bus8(struct fbtft_par *par, int len, ...);
void fbtft_write_reg16_bus16(struct fbtft_par *par, int len, ...);
+#define FBTFT_DT_TABLE(_compatible)
\
+static const struct of_device_id dt_ids[] = {
\
+ { .compatible = _compatible },
\
+ {},
\
+};
\
+MODULE_DEVICE_TABLE(of, dt_ids);
+
+#define FBTFT_SPI_DRIVER(_name, _compatible, _display, _spi_ids)
\
+
\
+static int fbtft_driver_probe_spi(struct spi_device *spi)
\
+{
\
+ return fbtft_probe_common(_display, spi, NULL);
\
+}
\
+
\
+static int fbtft_driver_remove_spi(struct spi_device *spi)
\
+{
\
+ struct fb_info *info = spi_get_drvdata(spi);
\
+
\
+ fbtft_remove_common(&spi->dev, info);
\
+ return 0;
\
+}
\
+
\
+static struct spi_driver fbtft_driver_spi_driver = {
\
+ .driver = {
\
+ .name = _name,
\
+ .of_match_table = dt_ids,
\
+ },
\
+ .id_table = _spi_ids,
\
+ .probe = fbtft_driver_probe_spi,
\
+ .remove = fbtft_driver_remove_spi,
\
+};
+
#define FBTFT_REGISTER_DRIVER(_name, _compatible, _display)\
\
-static int fbtft_driver_probe_spi(struct spi_device *spi) \
-{ \
- return fbtft_probe_common(_display, spi, NULL);\
-} \
- \
-static int fbtft_driver_remove_spi(struct spi_device *spi) \
-{ \
- struct fb_info *info = spi_get_drvdata(spi); \
- \
- fbtft_remove_common(&spi->dev, info); \
- return 0; \
-} \
- \
static int fbtft_driver_probe_pdev(struct platform_device *pdev) \
{ \
return fbtft_probe_common(_display, NULL, pdev); \
@@ -300,22 +319,9 @@ static int fbtft_driver_remove_pdev(struct platform_device
*pdev) \
return 0; \
} \
\
-static const struct of_device_id dt_ids[] = { \
- { .compatible =
[PATCH 1/2] staging: fbtft: Fix error path in fbtft_driver_module_init()
If registering the platform driver fails, the function must not return
without undoing the spi driver registration first.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft/fbtft.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 4cdec34e23d2..55677efc0138 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -334,7 +334,10 @@ static int __init fbtft_driver_module_init(void)
\
ret = spi_register_driver(&fbtft_driver_spi_driver); \
if (ret < 0) \
return ret;\
- return platform_driver_register(&fbtft_driver_platform_driver);\
+ ret = platform_driver_register(&fbtft_driver_platform_driver); \
+ if (ret < 0) \
+ spi_unregister_driver(&fbtft_driver_spi_driver); \
+ return ret;\
} \
\
static void __exit fbtft_driver_module_exit(void) \
base-commit: 0c947b893d69231a9add855939da7c66237ab44f
--
2.34.1
Re: [PATCH 1/2] drm/msm: add support for QCM2290 MDSS
On 18/01/2022 18:47, Loic Poulain wrote:
Add compatibility for QCM2290 display subsystem, including
required entries in DPU hw catalog.
Signed-off-by: Loic Poulain
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 175 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 177 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index ce6f32a..7fa3fc7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -25,6 +25,8 @@
#define VIG_SM8250_MASK \
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
+#define VIG_QCM2290_MASK VIG_MASK
| BIT(DPU_SSPP_QOS_8LVL)
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -251,6 +253,18 @@ static const struct dpu_caps sc7280_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
+static const struct dpu_caps qcm2290_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0x4,
+ .qseed_type = DPU_SSPP_SCALER_QSEED4,
If there is no scaler, we probably shouldn't define it here too.
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2,
+ .ubwc_version = DPU_HW_UBWC_VER_20,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .max_linewidth = 2160,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -336,6 +350,19 @@ static const struct dpu_mdp_cfg sc7280_mdp[] = {
},
};
+static const struct dpu_mdp_cfg qcm2290_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .highest_bank_bit = 0x2,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+ .reg_off = 0x2AC, .bit_off = 8},
+ },
+};
+
/*
* CTL sub blocks config
*/
@@ -459,6 +486,15 @@ static const struct dpu_ctl_cfg sc7280_ctl[] = {
},
};
+static const struct dpu_ctl_cfg qcm2290_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+};
+
/*
* SSPP sub blocks config
*/
@@ -595,6 +631,30 @@ static const struct dpu_sspp_cfg sc7280_sspp[] = {
sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
};
+
+#define _QCM2290_VIG_SBLK(num, sdma_pri) \
Let's call it _VIG_SBLK_NOSCALE?
+ { \
+ .maxdwnscale = SSPP_UNITY_SCALE, \
+ .maxupscale = SSPP_UNITY_SCALE, \
+ .smart_dma_priority = sdma_pri, \
+ .src_blk = {.name = STRCAT("sspp_src_", num), \
+ .id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
No scaler for VIG SSPP?
+ .format_list = plane_formats_yuv, \
+ .num_formats = ARRAY_SIZE(plane_formats_yuv), \
+ .virt_format_list = plane_formats, \
+ .virt_num_formats = ARRAY_SIZE(plane_formats), \
+ }
+
+static const struct dpu_sspp_sub_blks qcm2290_vig_sblk_0 =
_QCM2290_VIG_SBLK("0", 2);
+static const struct dpu_sspp_sub_blks qcm2290_dma_sblk_0 = _DMA_SBLK("8", 1);
+
+static const struct dpu_sspp_cfg qcm2290_sspp[] = {
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_QCM2290_MASK,
+qcm2290_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK,
+qcm2290_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
+};
+
/*
* MIXER sub blocks config
*/
@@ -679,6 +739,21 @@ static const struct dpu_lm_cfg sc7280_lm[] = {
&sc7180_lm_sblk, PINGPONG_3, LM_2, 0),
};
+/* QCM2290 */
+
+static const struct dpu_lm_sub_blks qcm2290_lm_sblk = {
+ .maxwidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .maxblendstages = 4, /* excluding base layer */
+ .blendstage_base = { /* offsets relative to mixer base */
+ 0x20, 0x38, 0x50, 0x68
+ },
+};
+
+static const struct dpu_lm_cfg qcm2290_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
+ &qcm2290_lm_sblk, PINGPONG_0, 0, DSPP_0),
+};
+
/***
[PATCH v2 3/4] drm/i915: add gtt misalignment test
add test to check handling of misaligned offsets and sizes
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 130 ++
1 file changed, 130 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 2f3f0c01786b..76696a5e547e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
*
*/
+#include "gt/intel_gtt.h"
#include
#include
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,120 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
}
+static int misaligned_case(struct i915_address_space *vm, struct
intel_memory_region *mr,
+ u64 addr, u64 size, unsigned long flags)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int err = 0;
+ u64 expected_vma_size, expected_node_size;
+
+ obj = i915_gem_object_create_region(mr, size, 0, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_put;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, addr | flags);
+ if (err)
+ goto err_put;
+ i915_vma_unpin(vma);
+
+ if (!drm_mm_node_allocated(&vma->node)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ expected_vma_size = round_up(size, 1 <<
(ffs(vma->resource->page_sizes_gtt) - 1));
+ expected_node_size = expected_vma_size;
+
+ if (IS_DG2(vm->i915) && i915_gem_object_is_lmem(obj)) {
+ /* dg2 should expand lmem node to 2MB */
+ expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+ expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+ }
+
+ if (vma->size != expected_vma_size || vma->node.size !=
expected_node_size) {
+ err = i915_vma_unbind(vma);
+ err = -EBADSLT;
+ goto err_put;
+ }
+
+ err = i915_vma_unbind(vma);
+ if (err)
+ goto err_put;
+
+ GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
+
+err_put:
+ i915_gem_object_put(obj);
+ cleanup_freed_objects(vm->i915);
+ return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+ unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ int err = 0;
+ u64 hole_size = hole_end - hole_start;
+
+ if (i915_is_ggtt(vm))
+ flags |= PIN_GLOBAL;
+
+ for_each_memory_region(mr, vm->i915, id) {
+ u64 min_alignment = i915_vm_min_alignment(vm, id);
+ u64 size = min_alignment;
+ u64 addr = round_up(hole_start + (hole_size / 2),
min_alignment);
+
+ /* we can't test < 4k alignment due to flags being encoded in
lower bits */
+ if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+ err = misaligned_case(vm, mr, addr + (min_alignment /
2), size, flags);
+ /* misaligned should error with -EINVAL*/
+ if (!err)
+ err = -EBADSLT;
+ if (err != -EINVAL)
+ return err;
+ }
+
+ /* test for vma->size expansion to min page size */
+ err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+ if (min_alignment > hole_size) {
+ if (!err)
+ err = -EBADSLT;
+ else if (err == -ENOSPC)
+ err = 0;
+ }
+ if (err)
+ return err;
+
+ /* test for intermediate size not expanding vma->size for large
alignments */
+ err = misaligned_case(vm, mr, addr, size / 2, flags);
+ if (min_alignment > hole_size) {
+ if (!err)
+ err = -EBADSLT;
+ else if (err == -ENOSPC)
+ err = 0;
+ }
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
static int exercise_ppgtt(struct drm_i915_private *dev_priv,
int (*func)(struct i915_address_space *vm,
u64 hole_start, u64 hole_
[PATCH v2 4/4] drm/i915/uapi: document behaviour for DG2 64K support
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..486b7b96291e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* **DG2 64K min page size implications:**
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* **Special DG2 GTT address alignment requirement:**
+*
+* The GTT alignment will also need be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE(which covers a 2MB virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects GD2, this
+* id deemed to be a good compromise.
*/
__u64 size;
/**
--
2.25.1
[PATCH v2 2/4] drm/i915: support 64K GTT pages for discrete cards
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 169 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 26f997c376a2..7efa6a598b03 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return err;
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
atomic_read(&pt->used));
GEM_BUG_ON(!count || count >= atomic_read(&pt->used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
-count);
+num_ptes);
atomic_sub(count, &pt->used);
start += count;
@@ -453,6 +463,95 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
[PATCH v2 1/4] drm/i915: enforce min GTT alignment for discrete cards
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
For DG2 we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../i915/gem/selftests/i915_gem_client_blt.c | 23 +++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 14 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 9 ++
drivers/gpu/drm/i915/i915_vma.c | 14 +++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ---
5 files changed, 115 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c08f766e6e15..7fee95a65414 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+ u64 align;
u32 width;
u32 height;
};
@@ -410,14 +411,21 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_free;
}
- hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+ t->align = I915_GTT_PAGE_SIZE_2M; /* XXX worst case, derive from vm! */
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL));
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+ hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
- hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+ hole_size += 2 * t->align; /* padding on either side */
mutex_lock(&t->ce->vm->mutex);
memset(&hole, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(&t->ce->vm->mm, &hole,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
0, U64_MAX,
DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +436,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_put;
}
- t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+ t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +463,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
static int tiled_blits_prepare(struct tiled_blits *t,
struct rnd_state *prng)
{
- u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+ u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +494,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
{
- u64 offset =
- round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+ u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +507,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct
rnd_state *prng)
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
-&t->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+&t->buffers[2], t->hole + t->align,
&t->buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..7c92b25c0f26 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,20 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
GEM_BUG_ON(!vm->total);
drm_mm_init(&vm->mm, 0, vm->total);
+
+ memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+ARRAY_SIZE(vm->min_alignment));
+
+ if (HAS_64K_PAGES(vm->i915)) {
+ if (IS_DG2(vm->i915)) {
+ vm->min_alignment[INTEL_MEMORY_LOCAL] =
I915_GTT_PAGE_SIZE_2M;
+ vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] =
I915_GTT_PAGE_SIZE_2M;
+ } else
[PATCH v2 0/4] discsrete card 64K page support
This series continues support for 64K pages for discrete cards. It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4 Changes since that series: - set min alignment for DG2 to 2MB in i915_address_space_init - replace coloring with simpler 2MB VA alignment for lmem buffers - enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert - expand vma reservation to round up to 2MB on DG2 in i915_vma_insert - add alignment test v2: rebase and fix for async vma that landed Matthew Auld (3): drm/i915: enforce min GTT alignment for discrete cards drm/i915: support 64K GTT pages for discrete cards drm/i915/uapi: document behaviour for DG2 64K support Robert Beckett (1): drm/i915: add gtt misalignment test .../gpu/drm/i915/gem/selftests/huge_pages.c | 60 + .../i915/gem/selftests/i915_gem_client_blt.c | 23 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 - drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++ drivers/gpu/drm/i915/gt/intel_gtt.h | 12 + drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 + drivers/gpu/drm/i915/i915_vma.c | 14 ++ drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 226 +++--- include/uapi/drm/i915_drm.h | 44 +++- 9 files changed, 453 insertions(+), 49 deletions(-) -- 2.25.1
Re: [RE]: [PATCH v3 10/10] vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the mdev
On Mon, 2022-01-17 at 11:35 -0400, Jason Gunthorpe wrote: > On Fri, Jan 14, 2022 at 11:30:36AM -0500, Eric Farman wrote: > > On Fri, 2022-01-14 at 20:28 +0800, Liu Yi L wrote: > > > Hi Eric, > > > > > > Hope you are back from new year holiday.:-) Have you got chane to > > > consider > > > this patch? > > > > Hi Yi Liu, > > > > It's coming up the list, but it's not there yet. Haven't forgotten. > > :) > > Liu would like to see ccw use a normal lifecycle for the vfio_device > backing memory, is there a shorter path to achieve that then what I > came up with? Getting through your proposal is the task on our plate. Just not enough hours in the day at the moment, sorry. Eric > > Jason
Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul, > Am 18.01.2022 um 17:58 schrieb Paul Cercueil : > > Hi Nikolaus, > > Le mar., janv. 18 2022 at 15:50:01 +0100, H. Nikolaus Schaller > a écrit : >> Hi Paul, >> any insights on the JZ_REG_LCD_OSDC issue below? > > Sorry, I missed your previous email. I blame the holidays ;) No problem... We all had deserved them. > >> There is a second, unrelated issue with the introduction of >> "drm/bridge: display-connector: implement bus fmts callbacks" >> which breaks bus format negotiations. >> These are the two last unsolved issues to submit a fully working driver. >>> Am 22.12.2021 um 15:03 schrieb H. Nikolaus Schaller : Am 08.11.2021 um 10:37 schrieb Paul Cercueil : Hi Nikolaus, Le dim., nov. 7 2021 at 21:25:38 +0100, H. Nikolaus Schaller a écrit : > Hi Paul, > @@ -1274,7 +1319,7 @@ static int ingenic_drm_bind(struct device *dev, > bool has_components) > /* Enable OSD if available */ > if (soc_info->has_osd) > - regmap_write(priv->map, JZ_REG_LCD_OSDC, > JZ_LCD_OSDC_OSDEN); > + regmap_set_bits(priv->map, JZ_REG_LCD_OSDC, > JZ_LCD_OSDC_OSDEN); This change is unrelated to this patch, and I'm not even sure it's a valid change. The driver shouldn't rely on previous register values. >>> I think I already commented that I think the driver should also not >>> reset >>> previous register values to zero. >> You did comment this, yes, but I don't agree. The driver *should* reset >> the registers to zero. It should *not* have to rely on whatever was >> configured before. >> Even if I did agree, this is a functional change unrelated to JZ4780 >> support, so it would have to be splitted to its own patch. > Well it is in preparation of setting more bits that are only available > for the jz4780. > But it will be splitted into its own patch for other reasons - if we ever > make osd working... >>> If I counted correctly this register has 18 bits which seem to include >>> some interrupt masks (which could be initialized somewhere else) and we >>> write a constant 0x1. >>> Of course most other bits are clearly OSD related (alpha blending), >>> i.e. they can have any value (incl. 0) if OSD is disabled. But here we >>> enable it. I think there may be missing some setting for the other bits. >>> So are you sure, that we can unconditionally reset *all* bits >>> except JZ_LCD_OSDC_OSDEN for the jz4780? >>> Well I have no experience with OSD being enabled at all. I.e. I have no >>> test scenario. >>> It turns out that the line >>> ret = clk_prepare_enable(priv->lcd_clk); >>> initializes JZ_REG_LCD_OSDC to 0x00010005 (i.e. printk tells 0x0 before). >> more detailled test shows that it is the underlying >> clk_enable(priv->lcd_clk) >> (i.e. not the prepare). >>> and writing >>> regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); >>> overwrites it with 0x0001. >>> This makes the HDMI monitor go/stay black until I write manually 0x5 to >>> JZ_REG_LCD_OSDC. >>> This means that JZ_LCD_OSDC_ALPHAEN must be enabled on jz4780 as well. >>> Hence overwriting just with JZ_LCD_OSDC_OSDEN breaks it. >>> Now the questions: >>> a) 0x5 is understandable that it sets JZ_LCD_OSDC_ALPHAEN - but why is it >>> needed? >>> Is this a not well documented difference between jz4740/60/70/80? >>> b) how can clk_prepare_enable() write 0x00010005 to JZ_REG_LCD_OSDC? Bug or >>> feature? >>> Something in cgu driver going wrong? >> I now suspect that it is an undocumented SoC feature. > > Not at all. If the clock is disabled, the LCD controller is disabled, so all > the registers read zero, this makes sense. You can only read the registers > when the clock is enabled. On some SoCs, reading disabled registers can even > cause a complete lockup. This is the right answer to the wrong question :) The question is why the register becomes 0x10005 as soon as the clock is enabled. Without writing to it. And contrary to the documented reset state. Or are you aware that u-boot initialized the lcdc and clocks get disabled when/during starting the kernel (I am using the good old v2013.10)? That could be an explanation that we read 0 before the clock is enabled and 0x10005 after. > Why is this JZ_LCD_OSDC_ALPHAEN bit needed now? I remember it working fine > last time I tried, and now I indeed get a black screen unless this bit is > set. The PM doesn't make it obvious that the bit is required, exactly. > but that wouldn't be surprising. > > Anyway, feel free to send a patch to fix it (with a Fixes: tag). Ideally > something like this: > > u32 osdc = 0; > ... > if (soc_info->has_osd) > osdc |= JZ_LCD_OSDC_OSDEN; > if (soc_info->has_alpha) > osdc |= JZ_LCD_OSDC_ALPHAEN; > regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc); Looks good to me. I'll give it a try. > > T
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
On 18/01/2022 18:17, Javier Martinez Canillas wrote: On 1/18/22 17:52, Jocelyn Falempe wrote: On 18/01/2022 17:38, Javier Martinez Canillas wrote: Hello Jocelyn, On 1/14/22 10:47, Jocelyn Falempe wrote: My worry is if this could cause other issues so I would only do this change if (is_kdump_kernel()), to make it as non intrusive as possible. And also add a verbose comment about why this is needed. This change must be done in the "first" kernel, so that when kdump starts, it doesn't hang the machine by writing to the VGA interface, in the early boot code. Ah, got it. The patch then makes sense to me as is in that case. My comment about documenting why this is needed still applies though. Yes, I will fix the commit message, and add a comment in the code. I didn't know 0xA was the graphic mode, so I though the configuration was a mistake. But it turns out, the current configuration is good, but as the driver don't use this address, and kdump fails if this address is not VGA text mode on some hardware, it's better to set it to 0xb8000. Best regards, Thanks,
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
On 1/18/22 17:52, Jocelyn Falempe wrote: > On 18/01/2022 17:38, Javier Martinez Canillas wrote: >> Hello Jocelyn, >> >> On 1/14/22 10:47, Jocelyn Falempe wrote: > >> >> My worry is if this could cause other issues so I would only do this change >> if (is_kdump_kernel()), to make it as non intrusive as possible. And also >> add a verbose comment about why this is needed. > > This change must be done in the "first" kernel, so that when kdump > starts, it doesn't hang the machine by writing to the VGA interface, in > the early boot code. > Ah, got it. The patch then makes sense to me as is in that case. My comment about documenting why this is needed still applies though. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Nikolaus, Le mar., janv. 18 2022 at 15:50:01 +0100, H. Nikolaus Schaller a écrit : Hi Paul, any insights on the JZ_REG_LCD_OSDC issue below? Sorry, I missed your previous email. I blame the holidays ;) There is a second, unrelated issue with the introduction of "drm/bridge: display-connector: implement bus fmts callbacks" which breaks bus format negotiations. These are the two last unsolved issues to submit a fully working driver. Am 22.12.2021 um 15:03 schrieb H. Nikolaus Schaller : Am 08.11.2021 um 10:37 schrieb Paul Cercueil : Hi Nikolaus, Le dim., nov. 7 2021 at 21:25:38 +0100, H. Nikolaus Schaller a écrit : Hi Paul, @@ -1274,7 +1319,7 @@ static int ingenic_drm_bind(struct device *dev, bool has_components) /* Enable OSD if available */ if (soc_info->has_osd) - regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); + regmap_set_bits(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); This change is unrelated to this patch, and I'm not even sure it's a valid change. The driver shouldn't rely on previous register values. I think I already commented that I think the driver should also not reset previous register values to zero. You did comment this, yes, but I don't agree. The driver *should* reset the registers to zero. It should *not* have to rely on whatever was configured before. Even if I did agree, this is a functional change unrelated to JZ4780 support, so it would have to be splitted to its own patch. Well it is in preparation of setting more bits that are only available for the jz4780. But it will be splitted into its own patch for other reasons - if we ever make osd working... If I counted correctly this register has 18 bits which seem to include some interrupt masks (which could be initialized somewhere else) and we write a constant 0x1. Of course most other bits are clearly OSD related (alpha blending), i.e. they can have any value (incl. 0) if OSD is disabled. But here we enable it. I think there may be missing some setting for the other bits. So are you sure, that we can unconditionally reset *all* bits except JZ_LCD_OSDC_OSDEN for the jz4780? Well I have no experience with OSD being enabled at all. I.e. I have no test scenario. It turns out that the line ret = clk_prepare_enable(priv->lcd_clk); initializes JZ_REG_LCD_OSDC to 0x00010005 (i.e. printk tells 0x0 before). more detailled test shows that it is the underlying clk_enable(priv->lcd_clk) (i.e. not the prepare). and writing regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); overwrites it with 0x0001. This makes the HDMI monitor go/stay black until I write manually 0x5 to JZ_REG_LCD_OSDC. This means that JZ_LCD_OSDC_ALPHAEN must be enabled on jz4780 as well. Hence overwriting just with JZ_LCD_OSDC_OSDEN breaks it. Now the questions: a) 0x5 is understandable that it sets JZ_LCD_OSDC_ALPHAEN - but why is it needed? Is this a not well documented difference between jz4740/60/70/80? b) how can clk_prepare_enable() write 0x00010005 to JZ_REG_LCD_OSDC? Bug or feature? Something in cgu driver going wrong? I now suspect that it is an undocumented SoC feature. Not at all. If the clock is disabled, the LCD controller is disabled, so all the registers read zero, this makes sense. You can only read the registers when the clock is enabled. On some SoCs, reading disabled registers can even cause a complete lockup. Why is this JZ_LCD_OSDC_ALPHAEN bit needed now? I remember it working fine last time I tried, and now I indeed get a black screen unless this bit is set. The PM doesn't make it obvious that the bit is required, but that wouldn't be surprising. Anyway, feel free to send a patch to fix it (with a Fixes: tag). Ideally something like this: u32 osdc = 0; ... if (soc_info->has_osd) osdc |= JZ_LCD_OSDC_OSDEN; if (soc_info->has_alpha) osdc |= JZ_LCD_OSDC_ALPHAEN; regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc); This also ensures that the OSDC register is properly initialized in the !has_osd case. The driver shouldn't rely on pre-boot values in the registers. Cheers, -Paul c) what do your SoC or panels do if you write 0x5 to JZ_REG_LCD_OSDC? d) 0x00010005 also has bit 16 set which is undocumented... But this is a don't care according to jz4780 PM. BR and thanks, Nikolaus
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
On 18/01/2022 17:38, Javier Martinez Canillas wrote: Hello Jocelyn, On 1/14/22 10:47, Jocelyn Falempe wrote: My worry is if this could cause other issues so I would only do this change if (is_kdump_kernel()), to make it as non intrusive as possible. And also add a verbose comment about why this is needed. This change must be done in the "first" kernel, so that when kdump starts, it doesn't hang the machine by writing to the VGA interface, in the early boot code. To make this change less intrusive, we can do it only on problematic hardware (G200_SE rev 42), but Thomas said it was probably not needed. If you make those changes, feel free to add: Reviewed-by: Javier Martinez Canillas Best regards,
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
Hello Jocelyn, On 1/14/22 10:47, Jocelyn Falempe wrote: > On some server with MGA G200e (rev 42), booting with Legacy BIOS, > The hardware hangs when using kdump and kexec into the kdump kernel. > This happens when the uncompress code tries to write "Decompressing Linux" > to the VGA Console. > > It can be reproduced by writing to the VGA console (0xB8000) after > booting to graphic mode, it generates the following error: > > kernel:NMI: PCI system error (SERR) for reason a0 on CPU 0. > kernel:Dazed and confused, but trying to continue > > The root cause is a bad configuration of the MGA GCTL6 register > > According to the GCTL6 register documentation: > > bit 0 is gcgrmode: > 0: Enables alpha mode, and the character generator addressing system is > activated. > 1: Enables graphics mode, and the character addressing system is not used. > > bit 1 is chainodd even: > 0: The A0 signal of the memory address bus is used during system memory > addressing. > 1: Allows A0 to be replaced by either the A16 signal of the system > address (if > memmapsl is ‘00’), or by the hpgoddev (MISC<5>, odd/even page select) > field, > described on page 3-294). > > bit 3-2 are memmapsl: > Memory map select bits 1 and 0. VGA. > These bits select where the video memory is mapped, as shown below: > 00 => Ah - Bh > 01 => Ah - Ah > 10 => Bh - B7FFFh > 11 => B8000h - Bh > > bit 7-4 are reserved. > > Current driver code set it to 0x05 => memmapsl to b01 => 0xA > but on x86, the VGA console is at 0xB8000 I think this need some rewording after imirkin's explanation that 0xA is the address of the VGA video memory and 0xB8000 the address of the VGA text buffer. > arch/x86/boot/compressed/misc.c define vidmem to 0xb8000 in extract_kernel() > so it's better to configure it to b11 > Thus changing the value 0x05 to 0x0d > > Signed-off-by: Jocelyn Falempe > --- > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c > b/drivers/gpu/drm/mgag200/mgag200_mode.c > index b983541a4c53..c7f63610b278 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_mode.c > +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c > @@ -529,7 +529,7 @@ static void mgag200_set_format_regs(struct mga_device > *mdev, > WREG_GFX(3, 0x00); > WREG_GFX(4, 0x00); > WREG_GFX(5, 0x40); > - WREG_GFX(6, 0x05); > + WREG_GFX(6, 0x0d); My worry is if this could cause other issues so I would only do this change if (is_kdump_kernel()), to make it as non intrusive as possible. And also add a verbose comment about why this is needed. If you make those changes, feel free to add: Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v3] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Fri, Oct 22, 2021 at 12:51:12PM -0700, Navare, Manasi wrote:
>
> Hi Ville,
>
> Could you take a look at this, this addresses teh review comments from prev
> version
I don't think I ever got an answer to my question as to whether this
was tested with all the interesting scenarios:
1) just with the master crtc added by userspace into the commit
2) just with the slave crtc added by userspace into the commit
3) both crtcs added by userspace into the commit
I guess 1) has been tested since that happens all the time, but the other
two scanarios would likely need to be done with a synthetic test to make
sure we're actually hitting them.
I think it *should* work, but I'd like to have real proof of that.
Reviewed-by: Ville Syrjälä
>
> Manasi
>
> On Mon, Oct 04, 2021 at 04:59:13AM -0700, Manasi Navare wrote:
> > In case of a modeset where a mode gets split across mutiple CRTCs
> > in the driver specific implementation (bigjoiner in i915) we wrongly count
> > the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC
> > as
> > an affected CRTC in atomic_check_only().
> > This triggers a warning since affected CRTCs doent match requested CRTC.
> >
> > To fix this in such bigjoiner configurations, we should only
> > increment affected crtcs if that CRTC is enabled in UAPI not
> > if it is just used internally in the driver to split the mode.
> >
> > v3: Add the same uapi crtc_state->enable check in requested
> > crtc calc (Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Simon Ser
> > Cc: Pekka Paalanen
> > Cc: Daniel Stone
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/drm_atomic.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index ff1416cd609a..a1e4c7905ebb 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1310,8 +1310,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> >
> > DRM_DEBUG_ATOMIC("checking %p\n", state);
> >
> > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > - requested_crtc |= drm_crtc_mask(crtc);
> > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > + if (new_crtc_state->enable)
> > + requested_crtc |= drm_crtc_mask(crtc);
> > + }
> >
> > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > new_plane_state, i) {
> > ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> > @@ -1360,8 +1362,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > }
> > }
> >
> > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > - affected_crtc |= drm_crtc_mask(crtc);
> > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > + if (new_crtc_state->enable)
> > + affected_crtc |= drm_crtc_mask(crtc);
> > + }
> >
> > /*
> > * For commits that allow modesets drivers can add other CRTCs to the
> > --
> > 2.19.1
> >
--
Ville Syrjälä
Intel
[PATCH] drm/msm: Fix include statements for DisplayPort
Update the include statements for DisplayPort helpers. The header
files are in the dp/ subdirectory.
Signed-off-by: Thomas Zimmermann
Fixes: 5b529e8d9c38 ("drm/dp: Move public DisplayPort headers into dp/")
Reported-by: kernel test robot
Cc: Lyude Paul
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/msm/edp/edp.h | 2 +-
drivers/gpu/drm/msm/edp/edp_ctrl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp.h b/drivers/gpu/drm/msm/edp/edp.h
index 8590f2ce274d..1a82d7a4af9f 100644
--- a/drivers/gpu/drm/msm/edp/edp.h
+++ b/drivers/gpu/drm/msm/edp/edp.h
@@ -10,9 +10,9 @@
#include
#include
#include
+#include
#include
#include
-#include
#include "msm_drv.h"
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index a68a4a1867c1..9f537b1fd849 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -6,8 +6,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#include "edp.h"
--
2.34.1
[PATCH] drm/selftests: Select DRM_DP_HELPER
Resolve warnings about non-existing symbols by selecting DRM_DP_HELPER.
Signed-off-by: Thomas Zimmermann
Fixes: adb9d5a2cc77 ("drm/dp: Move DisplayPort helpers into separate helper
module")
Reported-by: kernel test robot
Cc: Lyude Paul
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 91f54aeb0b7c..6589d931 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -68,6 +68,7 @@ config DRM_DEBUG_SELFTEST
depends on DRM
depends on DEBUG_KERNEL
select PRIME_NUMBERS
+ select DRM_DP_HELPER
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
select DRM_EXPORT_FOR_TESTS if m
--
2.34.1
[PATCH 2/2] dt-bindings: msm: disp: add yaml schemas for QCM2290 DPU bindings
QCM2290 MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema for DPU device
tree bindings
Signed-off-by: Loic Poulain
---
.../bindings/display/msm/dpu-qcm2290.yaml | 214 +
1 file changed, 214 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
new file mode 100644
index ..8766b13
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
@@ -0,0 +1,214 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dpu-qcm2290.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU dt properties for QCM2290 target
+
+maintainers:
+ - Loic Poulain
+
+description: |
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS
+ and DPU are mentioned for QCM2290 target.
+
+properties:
+ compatible:
+items:
+ - const: qcom,qcm2290-mdss
+
+ reg:
+maxItems: 1
+
+ reg-names:
+const: mdss
+
+ power-domains:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Display AHB clock from gcc
+ - description: Display AXI clock
+ - description: Display core clock
+
+ clock-names:
+items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ interrupts:
+maxItems: 1
+
+ interrupt-controller: true
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+ "#interrupt-cells":
+const: 1
+
+ iommus:
+items:
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail
port0
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail
port1
+
+ ranges: true
+
+ interconnects:
+items:
+ - description: Interconnect path specifying the port ids for data bus
+
+ interconnect-names:
+const: mdp0-mem
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+description: Node containing the properties of DPU.
+
+properties:
+ compatible:
+items:
+ - const: qcom,qcm2290-dpu
+
+ reg:
+items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+items:
+ - description: Display AXI clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock from dispcc
+ - description: Display lut clock from dispcc
+ - description: Display vsync clock from dispcc
+
+ clock-names:
+items:
+ - const: bus
+ - const: iface
+ - const: core
+ - const: lut
+ - const: vsync
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ operating-points-v2: true
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ Contains the list of output ports from DPU device. These ports
+ connect to interfaces that are external to the DPU hardware,
+ such as DSI. Each output port contains an endpoint that
+ describes how it is connected to an external interface.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: DPU_INTF1 (DSI1)
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - interrupts
+ - power-domains
+ - operating-points-v2
+ - ports
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - interrupts
+ - interrupt-controller
+ - iommus
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+mdss: mdss@5e0 {
+#address-cells = <1>;
+#size-cells = <1>;
+compatible = "qcom,qcm2290-mdss", "qcom,mdss";
+reg = <0x05e0 0x1000>;
+reg-names = "mdss";
+power-domains = <&dispcc MDSS_GDSC>;
+clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+clock-names = "iface", "bus", "core";
+
+interrupts = ;
+interrupt-controller;
+#interrupt-cells = <1>;
+
+interconnects = <&mmrt_virt MASTER_MDP0 &bimc SLAVE_EBI1>;
+interconnect-names = "mdp0-mem";
+
+iommus = <&apps_smmu 0x420 0x2>,
+ <&apps_smmu 0x421 0x0>;
+ranges;
+
+mdss_mdp: mdp@5e01000 {
+
[PATCH 1/2] drm/msm: add support for QCM2290 MDSS
Add compatibility for QCM2290 display subsystem, including
required entries in DPU hw catalog.
Signed-off-by: Loic Poulain
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 175 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 177 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index ce6f32a..7fa3fc7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -25,6 +25,8 @@
#define VIG_SM8250_MASK \
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
+#define VIG_QCM2290_MASK VIG_MASK
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -251,6 +253,18 @@ static const struct dpu_caps sc7280_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
+static const struct dpu_caps qcm2290_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0x4,
+ .qseed_type = DPU_SSPP_SCALER_QSEED4,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2,
+ .ubwc_version = DPU_HW_UBWC_VER_20,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .max_linewidth = 2160,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -336,6 +350,19 @@ static const struct dpu_mdp_cfg sc7280_mdp[] = {
},
};
+static const struct dpu_mdp_cfg qcm2290_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .highest_bank_bit = 0x2,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+ .reg_off = 0x2AC, .bit_off = 8},
+ },
+};
+
/*
* CTL sub blocks config
*/
@@ -459,6 +486,15 @@ static const struct dpu_ctl_cfg sc7280_ctl[] = {
},
};
+static const struct dpu_ctl_cfg qcm2290_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+};
+
/*
* SSPP sub blocks config
*/
@@ -595,6 +631,30 @@ static const struct dpu_sspp_cfg sc7280_sspp[] = {
sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
};
+
+#define _QCM2290_VIG_SBLK(num, sdma_pri) \
+ { \
+ .maxdwnscale = SSPP_UNITY_SCALE, \
+ .maxupscale = SSPP_UNITY_SCALE, \
+ .smart_dma_priority = sdma_pri, \
+ .src_blk = {.name = STRCAT("sspp_src_", num), \
+ .id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
+ .format_list = plane_formats_yuv, \
+ .num_formats = ARRAY_SIZE(plane_formats_yuv), \
+ .virt_format_list = plane_formats, \
+ .virt_num_formats = ARRAY_SIZE(plane_formats), \
+ }
+
+static const struct dpu_sspp_sub_blks qcm2290_vig_sblk_0 =
_QCM2290_VIG_SBLK("0", 2);
+static const struct dpu_sspp_sub_blks qcm2290_dma_sblk_0 = _DMA_SBLK("8", 1);
+
+static const struct dpu_sspp_cfg qcm2290_sspp[] = {
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_QCM2290_MASK,
+qcm2290_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK,
+qcm2290_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
+};
+
/*
* MIXER sub blocks config
*/
@@ -679,6 +739,21 @@ static const struct dpu_lm_cfg sc7280_lm[] = {
&sc7180_lm_sblk, PINGPONG_3, LM_2, 0),
};
+/* QCM2290 */
+
+static const struct dpu_lm_sub_blks qcm2290_lm_sblk = {
+ .maxwidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .maxblendstages = 4, /* excluding base layer */
+ .blendstage_base = { /* offsets relative to mixer base */
+ 0x20, 0x38, 0x50, 0x68
+ },
+};
+
+static const struct dpu_lm_cfg qcm2290_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
+ &qcm2290_lm_sblk, PINGPONG_0, 0, DSPP_0),
+};
+
/*
* DSPP sub blocks config
*/
@@ -692,6 +767,11 @@ static const struct dpu_dspp_sub_blks sm8150_dspp_sblk = {
.len
Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul, any insights on the JZ_REG_LCD_OSDC issue below? There is a second, unrelated issue with the introduction of "drm/bridge: display-connector: implement bus fmts callbacks" which breaks bus format negotiations. These are the two last unsolved issues to submit a fully working driver. > Am 22.12.2021 um 15:03 schrieb H. Nikolaus Schaller : > >> Am 08.11.2021 um 10:37 schrieb Paul Cercueil : >> >> Hi Nikolaus, >> >> Le dim., nov. 7 2021 at 21:25:38 +0100, H. Nikolaus Schaller >> a écrit : >>> Hi Paul, >>> >>> @@ -1274,7 +1319,7 @@ static int ingenic_drm_bind(struct device *dev, >>> bool has_components) >>> /* Enable OSD if available */ >>> if (soc_info->has_osd) >>> - regmap_write(priv->map, JZ_REG_LCD_OSDC, >>> JZ_LCD_OSDC_OSDEN); >>> + regmap_set_bits(priv->map, JZ_REG_LCD_OSDC, >>> JZ_LCD_OSDC_OSDEN); >> This change is unrelated to this patch, and I'm not even sure it's a >> valid change. The driver shouldn't rely on previous register values. > I think I already commented that I think the driver should also not reset > previous register values to zero. You did comment this, yes, but I don't agree. The driver *should* reset the registers to zero. It should *not* have to rely on whatever was configured before. Even if I did agree, this is a functional change unrelated to JZ4780 support, so it would have to be splitted to its own patch. >>> Well it is in preparation of setting more bits that are only available for >>> the jz4780. >>> But it will be splitted into its own patch for other reasons - if we ever >>> make osd working... > If I counted correctly this register has 18 bits which seem to include > some interrupt masks (which could be initialized somewhere else) and we > write a constant 0x1. > Of course most other bits are clearly OSD related (alpha blending), > i.e. they can have any value (incl. 0) if OSD is disabled. But here we > enable it. I think there may be missing some setting for the other bits. > So are you sure, that we can unconditionally reset *all* bits > except JZ_LCD_OSDC_OSDEN for the jz4780? > Well I have no experience with OSD being enabled at all. I.e. I have no > test scenario. > > It turns out that the line > > ret = clk_prepare_enable(priv->lcd_clk); > > initializes JZ_REG_LCD_OSDC to 0x00010005 (i.e. printk tells 0x0 before). more detailled test shows that it is the underlying clk_enable(priv->lcd_clk) (i.e. not the prepare). > > and writing > > regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); > > overwrites it with 0x0001. > > This makes the HDMI monitor go/stay black until I write manually 0x5 to > JZ_REG_LCD_OSDC. > > This means that JZ_LCD_OSDC_ALPHAEN must be enabled on jz4780 as well. > Hence overwriting just with JZ_LCD_OSDC_OSDEN breaks it. > > Now the questions: > a) 0x5 is understandable that it sets JZ_LCD_OSDC_ALPHAEN - but why is it > needed? > Is this a not well documented difference between jz4740/60/70/80? > b) how can clk_prepare_enable() write 0x00010005 to JZ_REG_LCD_OSDC? Bug or > feature? > Something in cgu driver going wrong? I now suspect that it is an undocumented SoC feature. > c) what do your SoC or panels do if you write 0x5 to JZ_REG_LCD_OSDC? > d) 0x00010005 also has bit 16 set which is undocumented... But this is a > don't care > according to jz4780 PM. BR and thanks, Nikolaus
Re: [PATCH] drm/i915: Add locking to i915_gem_evict_vm(), v3.
Op 17-01-2022 om 15:08 schreef Thomas Hellström: > > On 1/17/22 08:56, Maarten Lankhorst wrote: >> i915_gem_evict_vm will need to be able to evict objects that are >> locked by the current ctx. By testing if the current context already >> locked the object, we can do this correctly. This allows us to >> evict the entire vm even if we already hold some objects' locks. >> >> Previously, this was spread over several commits, but it makes >> more sense to commit the changes to i915_gem_evict_vm separately >> from the changes to i915_gem_evict_something() and >> i915_gem_evict_for_node(). >> >> Changes since v1: >> - Handle evicting dead objects better. >> Changes since v2: >> - Use for_i915_gem_ww in igt_evict_vm. (Thomas) >> >> Signed-off-by: Maarten Lankhorst > > Reviewed-by: Thomas Hellström > > (Please note the series checkpatch- and DOC warnings before commiting!) > > Thanks, > > Thomas > > Fixed and pushed. :) ~Maarten
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tuesday, January 18th, 2022 at 15:23, Thomas Zimmermann wrote: > Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven: > > Hi Gerd, > > > > On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann wrote: > >> Also note that using a shadow framebuffer allows to decouple fbcon > >> updates and scanout framebuffer updates. Can be used to speed up > >> things without depending on the 2d blitter. > > > > Assuming accesses to the shadow frame buffer are faster than accesses > > to the scanout frame buffer. While this is true on modern hardware, > > this is not the case on all hardware. Especially if the shadow frame > > buffer has a higher depth (XRGB) than the scanout frame buffer > > (e.g. Cn)... > > > > The funny thing is that the systems we are interested in, once used > > to be known for their graphics capabilities and/or performance... > > What I still don't understand: why are you so keen on maintaining an > interface that only serves the console? Nothing else uses fbdev these > days. Why not improve DRM/userspace to the point where it fits your > requirements? Long-term, the latter would make a lot more sense. +1 If you need any help with adapting user-space, feel free to ping me. I'd be interested in discussing, providing feedback and potentially user-space patches.
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi
Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven:
Hi Gerd,
On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann wrote:
Also note that using a shadow framebuffer allows to decouple fbcon
updates and scanout framebuffer updates. Can be used to speed up
things without depending on the 2d blitter.
Assuming accesses to the shadow frame buffer are faster than accesses
to the scanout frame buffer. While this is true on modern hardware,
this is not the case on all hardware. Especially if the shadow frame
buffer has a higher depth (XRGB) than the scanout frame buffer
(e.g. Cn)...
The funny thing is that the systems we are interested in, once used
to be known for their graphics capabilities and/or performance...
What I still don't understand: why are you so keen on maintaining an
interface that only serves the console? Nothing else uses fbdev these
days. Why not improve DRM/userspace to the point where it fits your
requirements? Long-term, the latter would make a lot more sense.
Best regards
Thomas
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Am 17.01.22 um 17:21 schrieb Helge Deller: On 1/17/22 16:58, Thomas Zimmermann wrote: Hi Am 17.01.22 um 16:42 schrieb Helge Deller: [...] c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, either when run on native hardware or in an emulator. d) not break DRM development Especially regarding c) I complained in [1] and got no feedback. I really would like to understand where the actual problems were and what's necessary to fix them. Helge [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723...@gmx.de Seems like few people read linux-fbdev these days. I suggest to partly revert the patch to the point were performance gets better again. If you want that, you should send a patch. Best regards Thomas Yes, *please*! That would solve my biggest concern. As far as I can see that's only 2 commits to be reverted: b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next I think both were not related to any 0-day bug reports (but again, I might be wrong). Helge -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Am 17.01.22 um 19:47 schrieb Sven Schnelle: Hi Thomas, Thomas Zimmermann writes: Hi Am 14.01.22 um 19:11 schrieb Helge Deller: The fbdev layer is orphaned, but seems to need some care. So I'd like to step up as new maintainer. Signed-off-by: Helge Deller First of all, thank you for stepping up to maintain the fbdev codebase. It really needs someone actively looking after it. And now comes the BUT. I want to second everything said by Danial and Javier. In addition to purely organizational topics (trees, PRs, etc), there are a number of inherit problems with fbdev. * It's 90s technology. Neither does it fit today's userspace, not hardware. If you have more than just the most trivial of graphical output fbdev isn't for you. * There's no new development in fbdev and there are no new drivers. Everyone works on DRM, which is better in most regards. The consequence is that userspace is slowly loosing the ability to use fbdev. That might be caused by the fact that no new drivers are accepted for And that is caused by the fact that fbdev is nowhere up to todays requirements. fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last year which was rejected for inclusion into fbdev[1]. Yep, I was hoping for a reply. Based on your recommendation i re-wrote the whole thing in DRM. This works but has several drawbacks: - no modesetting. With fbdev, i can nicely switch resolutions with fbset. That doesn't work, and i've been told that this is not supported[2] I didn't say that we're not going to support it at all. It's just not supported at the momont. vmwgfx has modesetting code that can serve as starting point. - It is *much* slower than fbset with hardware blitting. I would have to dig out the numbers, but it's in the ratio of 1:15. The nice thing with fbdev blitting is that i get an array of pixels and the foreground/background colors all of these these pixels should have. With the help of the hardware blitting, i can write 32 pixels at once with every 32-bit transfer. For comparison, how fast is fbdev with plain memcpy() and memset()? With DRM, the closest i could find was DRM_FORMAT_C8, which means one byte per pixel. So i can put 4 pixels into one 32-bit transfer. IIRC the hardware only supported 8-bit palette colors, so C8 was the correct choice. Otherwise, you can add new formats and add them to the console. fbdev also clears the lines with hardware blitting, which is much faster than clearing it with memcpy. Based on your recommendation i also verified that pci coalescing is enabled. These numbers are with DRM's unnatural scrolling behaviour - it seems to scroll several (text)lines at once if it takes to much time. I guess if DRM would scroll line by line it would be even slower. If DRM would add those things - hardware clearing of memory regions, hw blitting for text with a FG/BG color and modesetting i wouldn't care about fbdev at all. But right now, it's working way faster for me. I admit that your hardware is at the edge of what DRM currently supports. But I've used some of the DRM stuff on Athlon XPs with PCI graphics. While the performance wasn't good, it was far from unusable. I guess you used GEM SHMEM for memory buffers. fbdev and mmap with shmem pages use some of the same bits in struct page, so shmem cannot mmap it's pages directly. We have to use an additional shadow buffer. Any display update goes from the shadow buffer into the shmem buffer and into the videoram. That's two memcpys. This can be reduced to one memcpy, but we never had the requirement to do so. There's also potential for reducing the amount of page mappings/unmappings with gem shmem. And DRM supports shadow buffers, virtual screen sizes and damage handling in DRM. A sophisticated driver might be able to use shadow buffering, damage handling and hardware panning to reduce the amount of screen updates to a minimum. Until these things are fixed, adding hardware blitting doesn't really make sense IMHO. As with other things, we didn't have a requirement for all these optimizations so far. A usually good approach to improve the sitution is to get a basic driver merged and then address the problems one by one. Best regards Thomas I also tested the speed on my Thinkpad X1 with Intel graphics, and there a dmesg with 919 lines one the text console took about 2s to display. In x11, i measure 22ms. This might be unfair because encoding might be different, but i cannot confirm the 'memcpy' is faster than hardware blitting' point. I think if that would be the case, no-one would care about 2D acceleration. Don't get me wrong, i'm not saying there's no reason for DRM. I fully understand why it exists and think it's a good way to go. But for system where a (fast) local console is required without X11, fbdev might be the better choice at the moment. Regards Sven [1] htt
Re: [PATCH] drm/amdgpu: Add missing pm_runtime_put_autosuspend
On 1/18/2022 5:31 PM, Yongzhi Liu wrote:
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code, thus a matching decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Yongzhi Liu
Thanks!
Reviewed-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 9aea1cc..4b950de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1120,8 +1120,10 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct file
*f, char __user *buf,
return -EINVAL;
r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
- if (r < 0)
+ if (r < 0) {
+ pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
return r;
+ }
while (size) {
uint32_t value;
[PATCH 2/2] drm: mediatek: mtk_drm_crtc: Use kmalloc in mtk_drm_crtc_duplicate_state
Optimize mtk_drm_crtc_duplicate_state() by switching from kzalloc() to
kmalloc(): the only variable of this struct that gets checked in other
functions is `pending_config`, but if that's set to false, then all of
the remaining variables will only ever be set, but not read - so, also
set `pending_config` to false.
This saves us some small overhead.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 09fc9ad02c7a..f536a0a927e4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -185,7 +185,7 @@ static struct drm_crtc_state
*mtk_drm_crtc_duplicate_state(struct drm_crtc *crtc
{
struct mtk_crtc_state *state;
- state = kzalloc(sizeof(*state), GFP_KERNEL);
+ state = kmalloc(sizeof(*state), GFP_KERNEL);
if (!state)
return NULL;
@@ -193,6 +193,7 @@ static struct drm_crtc_state
*mtk_drm_crtc_duplicate_state(struct drm_crtc *crtc
WARN_ON(state->base.crtc != crtc);
state->base.crtc = crtc;
+ state->pending_config = false;
return &state->base;
}
--
2.33.1
[PATCH 1/2] drm: mediatek: mtk_drm_plane: Use kmalloc in mtk_plane_duplicate_state
There is no need to zero out the newly allocated memory because we are duplicating all members of struct mtk_plane_state: switch to kmalloc to save some overhead. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index c74cb94e445e..39cb9a80d976 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -57,7 +57,7 @@ static struct drm_plane_state *mtk_plane_duplicate_state(struct drm_plane *plane struct mtk_plane_state *old_state = to_mtk_plane_state(plane->state); struct mtk_plane_state *state; - state = kzalloc(sizeof(*state), GFP_KERNEL); + state = kmalloc(sizeof(*state), GFP_KERNEL); if (!state) return NULL; -- 2.33.1
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/gt: make a gt sysfs group and move power management files
Hi Tvrtko, > > +bool is_object_gt(struct kobject *kobj) > > Not sure if you will need it exported in a later patch but for now it seems > only users are local to this file. it is actually used by sysfs_gt.c and sysfs_gt_pm.c. Thank you, Andi PS. in this v4 I forgot to replace many drm_err() with drm_warn(), will do it properly in the next version.
