Re: [PATCH] drm/bridge: lt9611uxc: Fix an error handling path in lt9611uxc_probe()
On Sat, 16 Mar 2024 at 21:51, Christophe JAILLET
wrote:
>
> If lt9611uxc_audio_init() fails, some resources still need to be released
> before returning the error code.
>
> Use the existing error handling path.
>
> Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
> Signed-off-by: Christophe JAILLET
> ---
> Compile tested only.
> ---
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
[drm-misc:topic/rust-drm 14/18] error[E0606]: casting `` as `*const u8` is invalid
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm head: 42abbd1bc1f3362a9adee3d05e54518de90f2205 commit: 6c0514c3f46ec15b72726e2a930262a0225e7942 [14/18] rust: Add `container_of` and `offset_of` macros config: x86_64-randconfig-r113-20240315 (https://download.01.org/0day-ci/archive/20240317/202403170956.7rqbdsvn-...@intel.com/config) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240317/202403170956.7rqbdsvn-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202403170956.7rqbdsvn-...@intel.com/ All errors (new ones prefixed by >>): >> error[E0606]: casting `` as `*const u8` is invalid --> rust/doctests_kernel_generated.rs:1725:18 | 1725 | let test_alias = container_of!(b_ptr, Test, b); | ^ | = note: this error originates in the macro `container_of` (in Nightly builds, run with -Z macro-backtrace for more info) -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[PATCH] drm/panfrost: Only display fdinfo's engine and cycle tags when profiling is on
If job accounting is disabled, then both fdinfo's drm-engine and drm-cycle
key values will remain immutable. In that case, it makes more sense not to
display them at all to avoid confusing user space profiling tools.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index eec250114114..ef9f6c0716d5 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -550,10 +550,12 @@ static void panfrost_gpu_show_fdinfo(struct
panfrost_device *pfdev,
BUILD_BUG_ON(ARRAY_SIZE(engine_names) != NUM_JOB_SLOTS);
for (i = 0; i < NUM_JOB_SLOTS - 1; i++) {
- drm_printf(p, "drm-engine-%s:\t%llu ns\n",
- engine_names[i],
panfrost_priv->engine_usage.elapsed_ns[i]);
- drm_printf(p, "drm-cycles-%s:\t%llu\n",
- engine_names[i],
panfrost_priv->engine_usage.cycles[i]);
+ if (pfdev->profile_mode) {
+ drm_printf(p, "drm-engine-%s:\t%llu ns\n",
+ engine_names[i],
panfrost_priv->engine_usage.elapsed_ns[i]);
+ drm_printf(p, "drm-cycles-%s:\t%llu\n",
+ engine_names[i],
panfrost_priv->engine_usage.cycles[i]);
+ }
drm_printf(p, "drm-maxfreq-%s:\t%lu Hz\n",
engine_names[i], pfdev->pfdevfreq.fast_rate);
drm_printf(p, "drm-curfreq-%s:\t%lu Hz\n",
base-commit: 97252d0a4bfbb07079503d059f7522d305fe0f7a
--
2.43.0
[PATCH] drm/bridge: lt9611uxc: Fix an error handling path in lt9611uxc_probe()
If lt9611uxc_audio_init() fails, some resources still need to be released
before returning the error code.
Use the existing error handling path.
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
Signed-off-by: Christophe JAILLET
---
Compile tested only.
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index f4f593ad8f79..d0c77630a2f9 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -965,7 +965,11 @@ static int lt9611uxc_probe(struct i2c_client *client)
}
}
- return lt9611uxc_audio_init(dev, lt9611uxc);
+ ret = lt9611uxc_audio_init(dev, lt9611uxc);
+ if (ret)
+ goto err_remove_bridge;
+
+ return 0;
err_remove_bridge:
free_irq(client->irq, lt9611uxc);
--
2.44.0
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
On Sat, 16 Mar 2024 at 01:09, Sean Anderson wrote:
>
> Add a debugfs interface for exercising the various test modes supported
> by the DisplayPort controller. This allows performing compliance
> testing, or performing signal integrity measurements on a failing link.
> At the moment, we do not support sink-driven link quality testing,
> although such support would be fairly easy to add.
Could you please point out how this is used for compliance testing? We
have been using the msm_dp_compliance tool [1].
I think it would be nice to rework our drivers towards a common
debugfs interface used for DP connectors, maybe defining generic
internal interface/helpers like Maxime is implementing for HDMI
connectors.
[1]
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tools/msm_dp_compliance.c?ref_type=heads
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 591 ++-
> 1 file changed, 590 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 040f7b88ee51..57032186e1ca 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -18,7 +18,9 @@
> #include
> #include
>
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -50,6 +52,7 @@ MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in
> msec (default: 4)");
> #define ZYNQMP_DP_LANE_COUNT_SET 0x4
> #define ZYNQMP_DP_ENHANCED_FRAME_EN0x8
> #define ZYNQMP_DP_TRAINING_PATTERN_SET 0xc
> +#define ZYNQMP_DP_LINK_QUAL_PATTERN_SET0x10
> #define ZYNQMP_DP_SCRAMBLING_DISABLE 0x14
> #define ZYNQMP_DP_DOWNSPREAD_CTL 0x18
> #define ZYNQMP_DP_SOFTWARE_RESET 0x1c
> @@ -63,6 +66,9 @@ MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in
> msec (default: 4)");
>
> ZYNQMP_DP_SOFTWARE_RESET_STREAM3 | \
>
> ZYNQMP_DP_SOFTWARE_RESET_STREAM4 | \
>
> ZYNQMP_DP_SOFTWARE_RESET_AUX)
> +#define ZYNQMP_DP_COMP_PATTERN_80BIT_1 0x20
> +#define ZYNQMP_DP_COMP_PATTERN_80BIT_2 0x24
> +#define ZYNQMP_DP_COMP_PATTERN_80BIT_3 0x28
>
> /* Core enable registers */
> #define ZYNQMP_DP_TRANSMITTER_ENABLE 0x80
> @@ -206,6 +212,7 @@ MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in
> msec (default: 4)");
> #define ZYNQMP_DP_TX_PHY_POWER_DOWN_LANE_2 BIT(2)
> #define ZYNQMP_DP_TX_PHY_POWER_DOWN_LANE_3 BIT(3)
> #define ZYNQMP_DP_TX_PHY_POWER_DOWN_ALL0xf
> +#define ZYNQMP_DP_TRANSMIT_PRBS7 0x230
> #define ZYNQMP_DP_PHY_PRECURSOR_LANE_0 0x23c
> #define ZYNQMP_DP_PHY_PRECURSOR_LANE_1 0x240
> #define ZYNQMP_DP_PHY_PRECURSOR_LANE_2 0x244
> @@ -273,6 +280,69 @@ struct zynqmp_dp_config {
> u8 bpp;
> };
>
> +/**
> + * enum test_pattern - Test patterns for test testing
> + * TEST_VIDEO: Use regular video input
> + * TEST_SYMBOL_ERROR: Symbol error measurement pattern
> + * TEST_PRBS7: Output of the PRBS7 (x^7 + x^6 + 1) polynomial
> + * TEST_80BIT_CUSTOM: A custom 80-bit pattern
> + * TEST_CP2520: HBR2 compliance eye pattern
> + * TEST_TPS1: Link training symbol pattern TPS1 (/D10.2/)
> + * TEST_TPS2: Link training symbol pattern TPS2
> + * TEST_TPS3: Link training symbol pattern TPS3 (for HBR2)
> + */
> +enum test_pattern {
> + TEST_VIDEO,
> + TEST_TPS1,
> + TEST_TPS2,
> + TEST_TPS3,
> + TEST_SYMBOL_ERROR,
> + TEST_PRBS7,
> + TEST_80BIT_CUSTOM,
> + TEST_CP2520,
> +};
> +
> +static const char *const test_pattern_str[] = {
> + [TEST_VIDEO] = "video",
> + [TEST_TPS1] = "tps1",
> + [TEST_TPS2] = "tps2",
> + [TEST_TPS3] = "tps3",
> + [TEST_SYMBOL_ERROR] = "symbol-error",
> + [TEST_PRBS7] = "prbs7",
> + [TEST_80BIT_CUSTOM] = "80bit-custom",
> + [TEST_CP2520] = "cp2520",
> +};
> +
> +/**
> + * struct zynqmp_dp_test - Configuration for test mode
> + * @pattern: The test pattern
> + * @enhanced: Use enhanced framing
> + * @downspread: Use SSC
> + * @active: Whether test mode is active
> + * @custom: Custom pattern for %TEST_80BIT_CUSTOM
> + * @train_set: Voltage/preemphasis settings
> + * @bw_code: Bandwidth code for the link
> + * @link_cnt: Number of lanes
> + */
> +struct zynqmp_dp_test {
> + enum test_pattern pattern;
> + bool enhanced, downspread, active;
> + u8 custom[10];
> + u8 train_set[ZYNQMP_DP_MAX_LANES];
> + u8 bw_code;
> + u8 link_cnt;
> +};
> +
> +/**
> + * struct zynqmp_dp_train_set_priv - Private data for train_set debugfs files
> + *
Re: [PATCH] drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()
On Sat, 16 Mar 2024 at 19:28, Sui Jingfeng wrote: > > To reduce boilerplate, use of_graph_get_remote_node() helper instead of > the hand-rolling code. > > Signed-off-by: Sui Jingfeng > --- > drivers/gpu/drm/bridge/thc63lvd1024.c | 24 +++- > 1 file changed, 3 insertions(+), 21 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH] drm/bridge: it66121: Remove a duplicated invoke of of_device_is_available()
On Sat, 16 Mar 2024 at 19:44, Sui Jingfeng wrote: > > The calling of of_device_is_available() in it66121_probe() is duplicated, > as the of_graph_get_remote_node() has already do the check for us. There > is no need to call it again, thus delete the later one. > > Signed-off-by: Sui Jingfeng > --- > drivers/gpu/drm/bridge/ite-it66121.c | 6 -- > 1 file changed, 6 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH] drm: bridge: dw_hdmi: Switch to of_graph_get_remote_node()
On Sat, 16 Mar 2024 at 19:05, Sui Jingfeng wrote: > > To reduce boilerplate, use of_graph_get_remote_node() helper instead of > the hand-rolling code. > > Signed-off-by: Sui Jingfeng > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 31 +++ > 1 file changed, 4 insertions(+), 27 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH] drm/bridge: it66121: Remove a duplicated invoke of of_device_is_available()
The calling of of_device_is_available() in it66121_probe() is duplicated,
as the of_graph_get_remote_node() has already do the check for us. There
is no need to call it again, thus delete the later one.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/drm/bridge/ite-it66121.c
index 052884058644..925e42f46cd8 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -1540,12 +1540,6 @@ static int it66121_probe(struct i2c_client *client)
return -EINVAL;
}
- if (!of_device_is_available(ep)) {
- of_node_put(ep);
- dev_err(ctx->dev, "The remote device is disabled\n");
- return -ENODEV;
- }
-
ctx->next_bridge = of_drm_find_bridge(ep);
of_node_put(ep);
if (!ctx->next_bridge) {
--
2.34.1
Re: [PATCH] drm/bridge: ite66121: Register HPD interrupt handler only when 'client->irq > 0'
On Sat, 16 Mar 2024 at 18:05, Sui Jingfeng wrote: > > If a specific design doesn't wire IT66121's interrupt signal output pin up > to the display controller side, then we should not register the interrupt > handler. Such a decision is valid usage, as we can fall back to polling > mode. So, don't make the assumption that a specific board always supports > HPD. Carry out a sanity check on 'client->irq' before using it, fall back > to polling mode if client->irq < 0 is true. Such a design increases the > overall flexibility. > > Signed-off-by: Sui Jingfeng > --- > drivers/gpu/drm/bridge/ite-it66121.c | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH] drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()
To reduce boilerplate, use of_graph_get_remote_node() helper instead of
the hand-rolling code.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index d4c1a601bbb5..5f99f9724081 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -123,28 +123,10 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
struct device_node *endpoint;
struct device_node *remote;
- endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
-THC63_RGB_OUT0, -1);
- if (!endpoint) {
- dev_err(thc63->dev, "Missing endpoint in port@%u\n",
- THC63_RGB_OUT0);
- return -ENODEV;
- }
-
- remote = of_graph_get_remote_port_parent(endpoint);
- of_node_put(endpoint);
- if (!remote) {
- dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
- THC63_RGB_OUT0);
+ remote = of_graph_get_remote_node(thc63->dev->of_node,
+ THC63_RGB_OUT0, -1);
+ if (!remote)
return -ENODEV;
- }
-
- if (!of_device_is_available(remote)) {
- dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
- THC63_RGB_OUT0);
- of_node_put(remote);
- return -ENODEV;
- }
thc63->next = of_drm_find_bridge(remote);
of_node_put(remote);
--
2.34.1
[PATCH] drm: bridge: dw_hdmi: Switch to of_graph_get_remote_node()
To reduce boilerplate, use of_graph_get_remote_node() helper instead of
the hand-rolling code.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 31 +++
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index cceb5aab6c83..9f2bc932c371 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3291,40 +3291,17 @@ static void dw_hdmi_init_hw(struct dw_hdmi *hdmi)
static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
{
- struct device_node *endpoint;
struct device_node *remote;
if (!hdmi->plat_data->output_port)
return 0;
- endpoint = of_graph_get_endpoint_by_regs(hdmi->dev->of_node,
-hdmi->plat_data->output_port,
--1);
- if (!endpoint) {
- /*
-* On platforms whose bindings don't make the output port
-* mandatory (such as Rockchip) the plat_data->output_port
-* field isn't set, so it's safe to make this a fatal error.
-*/
- dev_err(hdmi->dev, "Missing endpoint in port@%u\n",
- hdmi->plat_data->output_port);
- return -ENODEV;
- }
- remote = of_graph_get_remote_port_parent(endpoint);
- of_node_put(endpoint);
- if (!remote) {
- dev_err(hdmi->dev, "Endpoint in port@%u unconnected\n",
- hdmi->plat_data->output_port);
+ remote = of_graph_get_remote_node(hdmi->dev->of_node,
+ hdmi->plat_data->output_port,
+ -1);
+ if (!remote)
return -ENODEV;
- }
-
- if (!of_device_is_available(remote)) {
- dev_err(hdmi->dev, "port@%u remote device is disabled\n",
- hdmi->plat_data->output_port);
- of_node_put(remote);
- return -ENODEV;
- }
hdmi->next_bridge = of_drm_find_bridge(remote);
of_node_put(remote);
--
2.34.1
Reporting (or not reporting) drm test build failures
Hi, recently there was a suggestion that drm build tests on architectures such as xtensa should not happen or not be reported. The current mainline kernel experiences a number of drm related build failures. Building csky:allmodconfig ... failed -- Error log: ERROR: modpost: "__udivdi3" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined! make[3]: [scripts/Makefile.modpost:145: Module.symvers] Error 1 (ignored) [ also seen with xtensa] Building mips:allmodconfig ... failed -- Error log: drivers/gpu/drm/xe/xe_lrc.c:100: error: "END" redefined I really don't want to waste people's time if reporting such problems is considered noise/nuisance. Is there some guidance available explaining which architectures and/or platforms are "fair game" for drm build tests, or, better, which platforms/architectures should explicitly _not_ build test the drm subsystem ? Thanks, Guenter
[PATCH v2] drm: Fix drm_fixp2int_round() making it add 0.5
As well noted by Pekka[1], the rounding of drm_fixp2int_round is wrong.
To round a number, you need to add 0.5 to the number and floor that,
drm_fixp2int_round() is adding 0.076. Make it add 0.5.
[1]:
https://lore.kernel.org/all/20240301135327.22efe0dd.pekka.paala...@collabora.com/
Fixes: 8b25320887d7 ("drm: Add fixed-point helper to get rounded integer
values")
Suggested-by: Pekka Paalanen
Reviewed-by: Harry Wentland
Signed-off-by: Arthur Grillo
---
Changes in v2:
- Add Fixes tag (Melissa Wen)
- Remove DRM_FIXED_POINT_HALF (Melissa Wen)
- Link to v1:
https://lore.kernel.org/all/20240306-louis-vkms-conv-v1-1-5bfe7d129...@riseup.net/
---
include/drm/drm_fixed.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 0c9f917a4d4b..81572d32db0c 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -71,7 +71,6 @@ static inline u32 dfixed_div(fixed20_12 A, fixed20_12 B)
}
#define DRM_FIXED_POINT32
-#define DRM_FIXED_POINT_HALF 16
#define DRM_FIXED_ONE (1ULL << DRM_FIXED_POINT)
#define DRM_FIXED_DECIMAL_MASK (DRM_FIXED_ONE - 1)
#define DRM_FIXED_DIGITS_MASK (~DRM_FIXED_DECIMAL_MASK)
@@ -90,7 +89,7 @@ static inline int drm_fixp2int(s64 a)
static inline int drm_fixp2int_round(s64 a)
{
- return drm_fixp2int(a + (1 << (DRM_FIXED_POINT_HALF - 1)));
+ return drm_fixp2int(a + DRM_FIXED_ONE / 2);
}
static inline int drm_fixp2int_ceil(s64 a)
---
base-commit: f89632a9e5fa6c4787c14458cd42a9ef42025434
change-id: 20240315-drm_fixed-c680ba078ecb
Best regards,
--
Arthur Grillo
Re: [PATCH 00/14] Add support for suppressing warning backtraces
On 3/14/24 07:37, Guenter Roeck wrote: On 3/14/24 06:36, Geert Uytterhoeven wrote: Hi Günter, On Tue, Mar 12, 2024 at 6:03 PM Guenter Roeck wrote: Some unit tests intentionally trigger warning backtraces by passing bad parameters to kernel API functions. Such unit tests typically check the return value from such calls, not the existence of the warning backtrace. Such intentionally generated warning backtraces are neither desirable nor useful for a number of reasons. - They can result in overlooked real problems. - A warning that suddenly starts to show up in unit tests needs to be investigated and has to be marked to be ignored, for example by adjusting filter scripts. Such filters are ad-hoc because there is no real standard format for warnings. On top of that, such filter scripts would require constant maintenance. One option to address problem would be to add messages such as "expected warning backtraces start / end here" to the kernel log. However, that would again require filter scripts, it might result in missing real problematic warning backtraces triggered while the test is running, and the irrelevant backtrace(s) would still clog the kernel log. Solve the problem by providing a means to identify and suppress specific warning backtraces while executing test code. Support suppressing multiple backtraces while at the same time limiting changes to generic code to the absolute minimum. Architecture specific changes are kept at minimum by retaining function names only if both CONFIG_DEBUG_BUGVERBOSE and CONFIG_KUNIT are enabled. The first patch of the series introduces the necessary infrastructure. The second patch introduces support for counting suppressed backtraces. This capability is used in patch three to implement unit tests. Patch four documents the new API. The next two patches add support for suppressing backtraces in drm_rect and dev_addr_lists unit tests. These patches are intended to serve as examples for the use of the functionality introduced with this series. The remaining patches implement the necessary changes for all architectures with GENERIC_BUG support. Thanks for your series! I gave it a try on m68k, just running backtrace-suppression-test, and that seems to work fine. Design note: Function pointers are only added to the __bug_table section if both CONFIG_KUNIT and CONFIG_DEBUG_BUGVERBOSE are enabled to avoid image size increases if CONFIG_KUNIT=n. There would be some benefits to adding those pointers all the time (reduced complexity, ability to display function names in BUG/WARNING messages). That change, if desired, can be made later. Unfortunately this also increases kernel size in the CONFIG_KUNIT=m case (ca. 80 KiB for atari_defconfig), making it less attractive to have kunit and all tests enabled as modules in my standard kernel. Good point. Indeed, it does. I wanted to avoid adding a configuration option, but maybe I should add it after all. How about something like this ? +config KUNIT_SUPPRESS_BACKTRACE + bool "KUnit - Enable backtrace suppression" + default y + help + Enable backtrace suppression for KUnit. If enabled, backtraces + generated intentionally by KUnit tests can be suppressed. Disable + to reduce kernel image size if image size is more important than + suppression of backtraces generated by KUnit tests. + Any more comments / feedback on this ? Otherwise I'll introduce the above configuration option in v2 of the series. In this context, any suggestions if it should be enabled or disabled by default ? I personally think it would be more important to be able to suppress backtraces, but I understand that others may not be willing to accept a ~1% image size increase with CONFIG_KUNIT=m unless KUNIT_SUPPRESS_BACKTRACE is explicitly disabled. Thanks, Guenter
[PATCH] drm/bridge: ite66121: Register HPD interrupt handler only when 'client->irq > 0'
If a specific design doesn't wire IT66121's interrupt signal output pin up
to the display controller side, then we should not register the interrupt
handler. Such a decision is valid usage, as we can fall back to polling
mode. So, don't make the assumption that a specific board always supports
HPD. Carry out a sanity check on 'client->irq' before using it, fall back
to polling mode if client->irq < 0 is true. Such a design increases the
overall flexibility.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/drm/bridge/ite-it66121.c
index 1c3433b5e366..052884058644 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -1586,13 +1586,18 @@ static int it66121_probe(struct i2c_client *client)
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
ctx->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
- ctx->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
DRM_BRIDGE_OP_HPD;
-
- ret = devm_request_threaded_irq(dev, client->irq, NULL,
it66121_irq_threaded_handler,
- IRQF_ONESHOT, dev_name(dev), ctx);
- if (ret < 0) {
- dev_err(dev, "Failed to request irq %d:%d\n", client->irq, ret);
- return ret;
+ ctx->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID;
+ if (client->irq > 0) {
+ ctx->bridge.ops |= DRM_BRIDGE_OP_HPD;
+
+ ret = devm_request_threaded_irq(dev, client->irq, NULL,
+ it66121_irq_threaded_handler,
+ IRQF_ONESHOT, dev_name(dev),
+ ctx);
+ if (ret < 0) {
+ dev_err(dev, "Failed to request irq %d:%d\n",
client->irq, ret);
+ return ret;
+ }
}
it66121_audio_codec_init(ctx, dev);
--
2.34.1
Re: [PATCH 1/7] drm: Fix drm_fixp2int_round() making it add 0.5
On 16/03/2024 08:59, Arthur Grillo wrote:
On 12/03/24 15:27, Melissa Wen wrote:
On 03/06, Arthur Grillo wrote:
As well noted by Pekka[1], the rounding of drm_fixp2int_round is wrong.
To round a number, you need to add 0.5 to the number and floor that,
drm_fixp2int_round() is adding 0.076. Make it add 0.5.
[1]:
https://lore.kernel.org/all/20240301135327.22efe0dd.pekka.paala...@collabora.com/
Hi Arthur,
thanks for addressing this issue.
Please, add a fix tag to the commit that you are fixing, so we can
easily backport. Might be this commit:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vkms?id=ab87f558dcfb2562c3497e89600dec798a446665
Wouldn't be this commit instead?
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8b25320887d7feac98875546ea0f521628b745bb
Yes, you're right!
Melissa
Best Regards,
~Arthur Grillo
Suggested-by: Pekka Paalanen
Signed-off-by: Arthur Grillo
---
include/drm/drm_fixed.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 0c9f917a4d4b..de3a79909ac9 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -90,7 +90,7 @@ static inline int drm_fixp2int(s64 a)
static inline int drm_fixp2int_round(s64 a)
{
- return drm_fixp2int(a + (1 << (DRM_FIXED_POINT_HALF - 1)));
Also, this is the only usage of DRM_FIXED_POINT_HALF. Can you also
remove it as it won't be used anymore?
+ return drm_fixp2int(a + DRM_FIXED_ONE / 2);
Would this division be equivalent to just shifting 1ULL by 31 instead of
32 as done in DRM_FIXED_ONE?
Melissa
}
static inline int drm_fixp2int_ceil(s64 a)
--
2.43.0
[PATCH v4] Fix divide-by-zero regression on DP MST unplug with nouveau
Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP DisplayPort 1.2 MST hub (the same regression does not appear when using a Cable Matters DisplayPort 1.4 MST hub). Trace: divide error: [#1] PREEMPT SMP PTI CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744 Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018 RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31 RSP: 0018:b2c5c211fa30 EFLAGS: 00010206 RAX: RBX: RCX: 00f59b00 RDX: RSI: RDI: RBP: b2c5c211fa48 R08: 0001 R09: 0020 R10: 0004 R11: R12: 00023b4a R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010 FS: 7f4a1ca3fa80() GS:91d6edbc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 559491d49000 CR3: 00011d180002 CR4: 003706f0 Call Trace: ? show_regs+0x6d/0x80 ? die+0x37/0xa0 ? do_trap+0xd4/0xf0 ? do_error_trap+0x71/0xb0 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? exc_divide_error+0x3a/0x70 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? asm_exc_divide_error+0x1b/0x20 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper] nv50_msto_atomic_check+0xda/0x120 [nouveau] drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper] drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper] nv50_disp_atomic_check+0x13f/0x2f0 [nouveau] drm_atomic_check_only+0x668/0xb20 [drm] ? drm_connector_list_iter_next+0x86/0xc0 [drm] drm_atomic_commit+0x58/0xd0 [drm] ? __pfx___drm_printfn_info+0x10/0x10 [drm] drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] drm_connector_property_set_ioctl+0x3b/0x60 [drm] drm_ioctl_kernel+0xb9/0x120 [drm] drm_ioctl+0x2d0/0x550 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] nouveau_drm_ioctl+0x61/0xc0 [nouveau] __x64_sys_ioctl+0xa0/0xf0 do_syscall_64+0x76/0x140 ? do_syscall_64+0x85/0x140 ? do_syscall_64+0x85/0x140 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f4a1cd1a94f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f RBP: c01064ab R08: 56347932deb8 R09: 56347a7d99c0 R10: R11: 0246 R12: 56347938a220 R13: 000f R14: 563479d9f3f0 R15: Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic uvcvideo libarc4 snd_hda_intel snd_intel_dspcfg snd_hda_codec iwlwifi videobuf2_vmalloc videobuf2_memops uvc irqbypass btusb videobuf2_v4l2 snd_seq_midi crct10dif_pclmul hid_multitouch crc32_pclmul snd_seq_midi_event btrtl snd_hwdep videodev polyval_clmulni polyval_generic snd_rawmidi ghash_clmulni_intel aesni_intel btintel crypto_simd snd_hda_core cryptd snd_seq btbcm ee1004 8250_dw videobuf2_common btmtk rapl nls_iso8859_1 mei_hdcp thunderbolt bluetooth intel_cstate wmi_bmof intel_wmi_thunderbolt cfg80211 snd_pcm mc snd_seq_device i2c_i801 r8169 ecdh_generic snd_timer i2c_smbus ecc snd mei_me intel_lpss_pci mei ahci intel_lpss soundcore realtek libahci idma64 intel_pch_thermal i2c_hid_acpi i2c_hid acpi_pad sch_fq_codel msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 dm_crypt raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 joydev input_leds hid_generic usbhid hid nouveau i915 drm_ttm_helper gpu_sched drm_gpuvm drm_exec i2c_algo_bit drm_buddy ttm drm_display_helper drm_kms_helper cec rc_core drm nvme
[drm-misc:topic/rust-drm 10/18] error[E0425]: cannot find function `my_get_param_handler` in this scope
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head: 42abbd1bc1f3362a9adee3d05e54518de90f2205
commit: 6f60fd0a4eca6108d590543d3ce3707706dedaa2 [10/18] rust: drm: ioctl: Add
DRM ioctl abstraction
config: x86_64-randconfig-r113-20240315
(https://download.01.org/0day-ci/archive/20240316/202403161916.baunmini-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240316/202403161916.baunmini-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202403161916.baunmini-...@intel.com/
All errors (new ones prefixed by >>):
>> error: expected one of `->`, `where`, or `{`, found `}`
--> rust/doctests_kernel_generated.rs:352:1
|
348 | fn foo(device: ::drm::device::Device,
|--- while parsing this `fn`
...
351 | )
| - expected one of `->`, `where`, or `{`
352 | } _doctest_main__kbuild_src_consumer_rust_kernel_drm_ioctl_rs_81_0() }
| ^ unexpected token
--
>> error: free function without a body
--> rust/doctests_kernel_generated.rs:348:1
|
348 | / fn foo(device: ::drm::device::Device,
349 | |data: bindings::argument_type,
350 | |file: ::drm::file::File,
351 | | )
| | ^- help: provide a definition for the function: `{ }`
| |_|
|
--
>> error[E0425]: cannot find function `my_get_param_handler` in this scope
--> rust/doctests_kernel_generated.rs:400:61
|
400 | (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW,
my_get_param_handler),
|
not found in this scope
--
>> error[E0599]: no method named `to_errno` found for type `u32` in the current
>> scope
--> rust/doctests_kernel_generated.rs:399:1
|
399 | / kernel::declare_drm_ioctls! {
400 | | (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW,
my_get_param_handler),
401 | | }
| |_^ method not found in `u32`
|
= note: this error originates in the macro `kernel::declare_drm_ioctls` (in
Nightly builds, run with -Z macro-backtrace for more info)
--
>> error[E0433]: failed to resolve: use of undeclared crate or module `bindings`
--> rust/doctests_kernel_generated.rs:349:19
|
349 |data: bindings::argument_type,
| use of undeclared crate or module `bindings`
--
>> error[E0433]: failed to resolve: `Self` is only available in impls, traits,
>> and type definitions
--> rust/doctests_kernel_generated.rs:350:39
|
350 |file: ::drm::file::File,
| `Self` is only available in
impls, traits, and type definitions
--
>> error[E0411]: cannot find type `Self` in this scope
--> rust/doctests_kernel_generated.rs:348:45
|
348 | fn foo(device: ::drm::device::Device,
|--- `Self` not allowed in a function `Self` is only available
in impls, traits, and type definitions
--
>> error[E0425]: cannot find value `DRM_IOCTL_FOO_GET_PARAM` in this scope
--> rust/doctests_kernel_generated.rs:400:6
|
400 | (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW,
my_get_param_handler),
| ^ not found in this scope
--
>> error[E0412]: cannot find type `drm_foo_get_param` in crate `$crate::uapi`
--> rust/doctests_kernel_generated.rs:400:21
|
400 | (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW,
my_get_param_handler),
| ^ not found in `$crate::uapi`
--
>> error[E0433]: failed to resolve: use of undeclared crate or module `ioctl`
--> rust/doctests_kernel_generated.rs:400:40
|
400 | (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW,
my_get_param_handler),
|^ use of undeclared crate or
module `ioctl`
|
help: consider importing this module
|
3 + use kernel::drm::ioctl;
|
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH 1/7] drm: Fix drm_fixp2int_round() making it add 0.5
On 12/03/24 15:27, Melissa Wen wrote:
> On 03/06, Arthur Grillo wrote:
>> As well noted by Pekka[1], the rounding of drm_fixp2int_round is wrong.
>> To round a number, you need to add 0.5 to the number and floor that,
>> drm_fixp2int_round() is adding 0.076. Make it add 0.5.
>>
>> [1]:
>> https://lore.kernel.org/all/20240301135327.22efe0dd.pekka.paala...@collabora.com/
>>
> Hi Arthur,
>
> thanks for addressing this issue.
>
> Please, add a fix tag to the commit that you are fixing, so we can
> easily backport. Might be this commit:
> https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vkms?id=ab87f558dcfb2562c3497e89600dec798a446665
Wouldn't be this commit instead?
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8b25320887d7feac98875546ea0f521628b745bb
Best Regards,
~Arthur Grillo
>> Suggested-by: Pekka Paalanen
>> Signed-off-by: Arthur Grillo
>> ---
>> include/drm/drm_fixed.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
>> index 0c9f917a4d4b..de3a79909ac9 100644
>> --- a/include/drm/drm_fixed.h
>> +++ b/include/drm/drm_fixed.h
>> @@ -90,7 +90,7 @@ static inline int drm_fixp2int(s64 a)
>>
>> static inline int drm_fixp2int_round(s64 a)
>> {
>> -return drm_fixp2int(a + (1 << (DRM_FIXED_POINT_HALF - 1)));
> Also, this is the only usage of DRM_FIXED_POINT_HALF. Can you also
> remove it as it won't be used anymore?
>
>> +return drm_fixp2int(a + DRM_FIXED_ONE / 2);
> Would this division be equivalent to just shifting 1ULL by 31 instead of
> 32 as done in DRM_FIXED_ONE?
>
> Melissa
>
>> }
>>
>> static inline int drm_fixp2int_ceil(s64 a)
>>
>> --
>> 2.43.0
>>
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
Hi Sean, kernel test robot noticed the following build errors: [auto build test ERROR on v6.8] [cannot apply to drm-misc/drm-misc-next linus/master next-20240315] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208 base: v6.8 patch link: https://lore.kernel.org/r/20240315230916.1759060-7-sean.anderson%40linux.dev patch subject: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20240316/202403161837.76okcezn-...@intel.com/config) compiler: m68k-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240316/202403161837.76okcezn-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202403161837.76okcezn-...@intel.com/ All errors (new ones prefixed by >>): m68k-linux-ld: drivers/gpu/drm/xlnx/zynqmp_dp.o: in function `zynqmp_dp_rate_set': >> zynqmp_dp.c:(.text+0x1a7a): undefined reference to `__udivdi3' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH stable-6.7] soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
On Fri, Mar 08, 2024 at 10:03:57AM +0100, Johan Hovold wrote:
commit b979f2d50a099f3402418d7ff5f26c3952fb08bb upstream.
A recent DRM series purporting to simplify support for "transparent
bridges" and handling of probe deferrals ironically exposed a
use-after-free issue on pmic_glink_altmode probe deferral.
This has manifested itself as the display subsystem occasionally failing
to initialise and NULL-pointer dereferences during boot of machines like
the Lenovo ThinkPad X13s.
Specifically, the dp-hpd bridge is currently registered before all
resources have been acquired which means that it can also be
deregistered on probe deferrals.
In the meantime there is a race window where the new aux bridge driver
(or PHY driver previously) may have looked up the dp-hpd bridge and
stored a (non-reference-counted) pointer to the bridge which is about to
be deallocated.
When the display controller is later initialised, this triggers a
use-after-free when attaching the bridges:
dp -> aux -> dp-hpd (freed)
which may, for example, result in the freed bridge failing to attach:
[drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge
/soc@0/phy@88eb000 to encoder TMDS-31: -16
or a NULL-pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address
...
Call trace:
drm_bridge_attach+0x70/0x1a8 [drm]
drm_aux_bridge_attach+0x24/0x38 [aux_bridge]
drm_bridge_attach+0x80/0x1a8 [drm]
dp_bridge_init+0xa8/0x15c [msm]
msm_dp_modeset_init+0x28/0xc4 [msm]
The DRM bridge implementation is clearly fragile and implicitly built on
the assumption that bridges may never go away. In this case, the fix is
to move the bridge registration in the pmic_glink_altmode driver to
after all resources have been looked up.
Incidentally, with the new dp-hpd bridge implementation, which registers
child devices, this is also a requirement due to a long-standing issue
in driver core that can otherwise lead to a probe deferral loop (see
commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).
[DB: slightly fixed commit message by adding the word 'commit']
Fixes: 080b4e24852b ("soc: qcom: pmic_glink: Introduce altmode support")
Fixes: 2bcca96abfbf ("soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE")
Cc: # 6.3
Cc: Bjorn Andersson
Cc: Dmitry Baryshkov
Signed-off-by: Johan Hovold
Reviewed-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
Link:
https://patchwork.freedesktop.org/patch/msgid/20240217150228.5788-4-johan+lin...@kernel.org
[ johan: backport to 6.7 which does not have DRM aux bridge ]
Signed-off-by: Johan Hovold
Queued up, thanks!
--
Thanks,
Sasha
Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
Hi Sean,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.8]
[cannot apply to drm-misc/drm-misc-next linus/master next-20240315]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208
base: v6.8
patch link:
https://lore.kernel.org/r/20240315230916.1759060-7-sean.anderson%40linux.dev
patch subject: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance
testing
config: microblaze-allmodconfig
(https://download.01.org/0day-ci/archive/20240316/202403161704.achjdsjg-...@intel.com/config)
compiler: microblaze-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240316/202403161704.achjdsjg-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202403161704.achjdsjg-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpu/drm/xlnx/zynqmp_dp.c: In function
'zynqmp_dp_bridge_debugfs_init':
>> drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:31: warning: 'sprintf' may write a
>> terminating nul past the end of the destination [-Wformat-overflow=]
2168 | sprintf(name, fmt, i);
| ^~~
drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:17: note: 'sprintf' output between 18
and 20 bytes into a destination of size 19
2168 | sprintf(name, fmt, i);
| ^
vim +/sprintf +2168 drivers/gpu/drm/xlnx/zynqmp_dp.c
2136
2137 DEFINE_DEBUGFS_ATTRIBUTE(fops_zynqmp_dp_rate, zynqmp_dp_rate_get,
2138 zynqmp_dp_rate_set, "%llu\n");
2139
2140 static void zynqmp_dp_bridge_debugfs_init(struct drm_bridge *bridge,
2141struct dentry *root)
2142 {
2143 struct zynqmp_dp *dp = bridge_to_dp(bridge);
2144 struct dentry *test;
2145 int i;
2146
2147 dp->test.bw_code = DP_LINK_BW_5_4;
2148 dp->test.link_cnt = dp->num_lanes;
2149
2150 test = debugfs_create_dir("test", root);
2151 #define CREATE_FILE(name) \
2152 debugfs_create_file(#name, 0600, test, dp,
_zynqmp_dp_##name)
2153 CREATE_FILE(pattern);
2154 CREATE_FILE(enhanced);
2155 CREATE_FILE(downspread);
2156 CREATE_FILE(active);
2157 CREATE_FILE(custom);
2158 CREATE_FILE(rate);
2159 CREATE_FILE(lanes);
2160
2161 for (i = 0; i < dp->num_lanes; i++) {
2162 static const char fmt[] = "lane%d_preemphasis";
2163 char name[sizeof(fmt)];
2164
2165 dp->debugfs_train_set[i].dp = dp;
2166 dp->debugfs_train_set[i].lane = i;
2167
> 2168 sprintf(name, fmt, i);
2169 debugfs_create_file(name, 0600, test,
2170 >debugfs_train_set[i],
2171 _zynqmp_dp_preemphasis);
2172
2173 sprintf(name, "lane%d_swing", i);
2174 debugfs_create_file(name, 0600, test,
2175 >debugfs_train_set[i],
2176 _zynqmp_dp_swing);
2177 }
2178 }
2179
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH 3/6] drm: zynqmp_dp: Add locking
Hi Sean,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.8]
[also build test WARNING on linus/master next-20240315]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208
base: v6.8
patch link:
https://lore.kernel.org/r/20240315230916.1759060-4-sean.anderson%40linux.dev
patch subject: [PATCH 3/6] drm: zynqmp_dp: Add locking
config: alpha-allyesconfig
(https://download.01.org/0day-ci/archive/20240316/202403161747.trmfawhm-...@intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240316/202403161747.trmfawhm-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202403161747.trmfawhm-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/xlnx/zynqmp_dp.c:321: warning: Function parameter or struct
>> member 'hpd_irq_work' not described in 'zynqmp_dp'
vim +321 drivers/gpu/drm/xlnx/zynqmp_dp.c
d76271d22694e8 Hyun Kwon2018-07-07 275
d76271d22694e8 Hyun Kwon2018-07-07 276 /**
d76271d22694e8 Hyun Kwon2018-07-07 277 * struct zynqmp_dp - Xilinx
DisplayPort core
d76271d22694e8 Hyun Kwon2018-07-07 278 * @dev: device structure
d76271d22694e8 Hyun Kwon2018-07-07 279 * @dpsub: Display subsystem
d76271d22694e8 Hyun Kwon2018-07-07 280 * @iomem: device I/O memory
for register access
d76271d22694e8 Hyun Kwon2018-07-07 281 * @reset: reset controller
8ce380e6568015 Sean Anderson2024-03-15 282 * @lock: Mutex protecting
this struct and register access (but not AUX)
d76271d22694e8 Hyun Kwon2018-07-07 283 * @irq: irq
47e801bd0749f0 Laurent Pinchart 2021-08-04 284 * @bridge: DRM bridge for the
DP encoder
bd68b9b3cb2e0d Laurent Pinchart 2021-08-04 285 * @next_bridge: The
downstream bridge
d76271d22694e8 Hyun Kwon2018-07-07 286 * @config: IP core
configuration from DTS
d76271d22694e8 Hyun Kwon2018-07-07 287 * @aux: aux channel
d76271d22694e8 Hyun Kwon2018-07-07 288 * @phy: PHY handles for DP
lanes
d76271d22694e8 Hyun Kwon2018-07-07 289 * @num_lanes: number of
enabled phy lanes
d76271d22694e8 Hyun Kwon2018-07-07 290 * @hpd_work: hot plug
detection worker
d76271d22694e8 Hyun Kwon2018-07-07 291 * @status: connection status
d76271d22694e8 Hyun Kwon2018-07-07 292 * @enabled: flag to indicate
if the device is enabled
d76271d22694e8 Hyun Kwon2018-07-07 293 * @dpcd: DP configuration
data from currently connected sink device
d76271d22694e8 Hyun Kwon2018-07-07 294 * @link_config: common link
configuration between IP core and sink device
d76271d22694e8 Hyun Kwon2018-07-07 295 * @mode: current mode between
IP core and sink device
d76271d22694e8 Hyun Kwon2018-07-07 296 * @train_set: set of training
data
d76271d22694e8 Hyun Kwon2018-07-07 297 */
d76271d22694e8 Hyun Kwon2018-07-07 298 struct zynqmp_dp {
d76271d22694e8 Hyun Kwon2018-07-07 299 struct device *dev;
d76271d22694e8 Hyun Kwon2018-07-07 300 struct zynqmp_dpsub
*dpsub;
d76271d22694e8 Hyun Kwon2018-07-07 301 void __iomem *iomem;
d76271d22694e8 Hyun Kwon2018-07-07 302 struct reset_control
*reset;
8ce380e6568015 Sean Anderson2024-03-15 303 struct mutex lock;
d76271d22694e8 Hyun Kwon2018-07-07 304 int irq;
d76271d22694e8 Hyun Kwon2018-07-07 305
47e801bd0749f0 Laurent Pinchart 2021-08-04 306 struct drm_bridge
bridge;
bd68b9b3cb2e0d Laurent Pinchart 2021-08-04 307 struct drm_bridge
*next_bridge;
47e801bd0749f0 Laurent Pinchart 2021-08-04 308
d76271d22694e8 Hyun Kwon2018-07-07 309 struct zynqmp_dp_config
config;
d76271d22694e8 Hyun Kwon2018-07-07 310 struct drm_dp_aux aux;
d76271d22694e8 Hyun Kwon2018-07-07 311 struct phy
*phy[ZYNQMP_DP_MAX_LANES];
d76271d22694e8 Hyun Kwon2018-07-07 312 u8 num_lanes;
8ce380e6568015 Sean Anderson2024-03-15 313 struct delayed_work
hpd_work, hpd_irq_work;
d76271d22694e8 Hyun Kwon2018-07-07 314 enum
drm_connector_status status;
d76271d22694e8 Hyun Kwon2018-07-07 315 bool enabled;
d76271d22694e8 Hyun Kwon2018-07-07 316
d76271d22694e8 Hyun Kwon2018-07-07 31
[PATCH] backlight: mp3309c: fix signedness bug in mp3309c_parse_fwnode()
The "num_levels" variable is used to store error codes from
device_property_count_u32() so it needs to be signed. This doesn't
cause an issue at runtime because devm_kcalloc() won't allocate negative
sizes. However, it's still worth fixing.
Fixes: b54c828bdba9 ("backlight: mp3309c: Make use of device properties")
Signed-off-by: Dan Carpenter
---
drivers/video/backlight/mp3309c.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/mp3309c.c
b/drivers/video/backlight/mp3309c.c
index c80a1481e742..4e98e60417d2 100644
--- a/drivers/video/backlight/mp3309c.c
+++ b/drivers/video/backlight/mp3309c.c
@@ -205,8 +205,9 @@ static int mp3309c_parse_fwnode(struct mp3309c_chip *chip,
struct mp3309c_platform_data *pdata)
{
int ret, i;
- unsigned int num_levels, tmp_value;
+ unsigned int tmp_value;
struct device *dev = chip->dev;
+ int num_levels;
if (!dev_fwnode(dev))
return dev_err_probe(dev, -ENODEV, "failed to get firmware
node\n");
--
2.43.0
[PATCH] drm/amd/display: delete unnecessary check in dcn35_set_long_vblank()
"timing" is "_ctx[i]->stream->timing" where ->timing is not the
first struct member of ->stream. So it's the address which points into
the middle of a struct. It can't be NULL so delete the NULL check.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c
b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c
index 2e8ec58a16eb..87cfd9f1cec9 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c
@@ -1411,10 +1411,7 @@ void dcn35_set_long_vblank(struct pipe_ctx **pipe_ctx,
if (pipe_ctx[i]->stream) {
struct dc_crtc_timing *timing =
_ctx[i]->stream->timing;
- if (timing)
- params.vertical_blank_start = timing->v_total -
timing->v_front_porch;
- else
- params.vertical_blank_start = 0;
+ params.vertical_blank_start = timing->v_total -
timing->v_front_porch;
if ((pipe_ctx[i]->stream_res.tg != NULL) &&
pipe_ctx[i]->stream_res.tg->funcs &&
pipe_ctx[i]->stream_res.tg->funcs->set_long_vtotal)
--
2.43.0
Re: [PATCH v10 9/9] drm/ast: Add drm_panic support
Hi, On 2024/3/15 23:11, Jocelyn Falempe wrote: Add support for the drm_panic module, which displays a message to the screen when a kernel panic occurs. v7 * Use drm_for_each_primary_visible_plane() v8: * Replace get_scanout_buffer() logic with drm_panic_set_buffer() (Thomas Zimmermann) v9: * Revert to using get_scanout_buffer() (Sima) * move get_scanout_buffer() to plane helper functions Signed-off-by: Jocelyn Falempe Acked-by: Sui Jingfeng -- Best regards, Sui
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8 next-20240315]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/sunpeng-li-amd-com/drm-amd-display-Introduce-overlay-cursor-mode/20240316-011404
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240315170959.165505-2-sunpeng.li%40amd.com
patch subject: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
config: loongarch-defconfig
(https://download.01.org/0day-ci/archive/20240316/202403161600.6kspdesj-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240316/202403161600.6kspdesj-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202403161600.6kspdesj-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:10639: warning:
>> This comment starts with '/**', but isn't a kernel-doc comment. Refer
>> Documentation/doc-guide/kernel-doc.rst
* Set whether the cursor should be enabled in native mode, or overlay mode,
on
vim +10639 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c
10637
10638 /**
10639 * Set whether the cursor should be enabled in native mode, or overlay
mode, on
10640 * the dm_crtc_state.
10641 *
10642 * The cursor should be enabled in overlay mode if the immediate
underlying
10643 * plane contains a video format.
10644 *
10645 * Since zpos info is required, drm_atomic_normalize_zpos must be
called before
10646 * calling this function.
10647 */
10648 static int dm_crtc_set_cursor_mode(struct drm_atomic_state *state,
10649 struct dm_crtc_state *dm_crtc_state)
10650 {
10651 struct drm_plane_state *plane_state, *old_plane_state,
*target_plane_state;
10652 struct drm_crtc_state *crtc_state = _crtc_state->base;
10653 struct drm_plane *plane;
10654 bool consider_mode_change = false;
10655 bool cursor_changed = false;
10656 unsigned int target_zpos;
10657 unsigned int cursor_zpos;
10658 int i;
10659
10660 /*
10661 * Cursor mode can change if a plane's format changes, is
10662 * enabled/disabled, or z-order changes.
10663 */
10664 for_each_oldnew_plane_in_state(state, plane, old_plane_state,
plane_state, i) {
10665
10666 /* Only care about planes on this CRTC */
10667 if ((drm_plane_mask(plane) & crtc_state->plane_mask) ==
0)
10668 continue;
10669
10670 if (plane->type == DRM_PLANE_TYPE_CURSOR)
10671 cursor_changed = true;
10672
10673 if (drm_atomic_plane_enabling(old_plane_state,
plane_state) ||
10674 drm_atomic_plane_disabling(old_plane_state,
plane_state) ||
10675 old_plane_state->fb->format !=
plane_state->fb->format) {
10676 consider_mode_change = true;
10677 break;
10678 }
10679 }
10680
10681 if (!consider_mode_change && !crtc_state->zpos_changed) {
10682 return 0;
10683 }
10684
10685 /*
10686 * If no cursor change on this CRTC, and not enabled on this
CRTC, then
10687 * no need to set cursor mode. This avoids needlessly locking
the cursor
10688 * state.
10689 */
10690 if (!cursor_changed &&
10691 !(drm_plane_mask(crtc_state->crtc->cursor) &
crtc_state->plane_mask)) {
10692 return 0;
10693 }
10694
10695 plane_state = drm_atomic_get_plane_state(state,
10696
crtc_state->crtc->cursor);
10697 if (IS_ERR(plane_state))
10698 return PTR_ERR(plane_state);
10699
10700 /* Cursor is disabled */
10701 if (!plane_state->fb)
10702 return 0;
10703
10704 cursor_zpos = plane_state->normalized_zpos;
10705
10706 /* Get enabled plane immediatel
Re: [PATCHv2] fbcon: Increase maximum font width x height to 64 x 128
On 3/16/24 01:10, Samuel Thibault wrote:
By using bitmaps we actually support whatever size we would want, but the
console currently limits fonts to 64x128 (which gives 60x16 text on 4k
screens), so we don't need more for now, and we can easily increase later.
Signed-off-by: Samuel Thibault
I cleaned up the tabs & spaces in your patch, fixed the missing
get_default_font() change in sticore.c and applied it to the fbdev git tree.
Let's keep it for a few days in for-next...
Thanks!
Helge
---
Difference from v1:
- use a bitmap rather than just extending the integer size
- add missing updates in drivers
---
drivers/firmware/efi/earlycon.c| 2 +-
drivers/video/fbdev/arkfb.c| 15 +++
drivers/video/fbdev/core/fbcon.c | 16 +---
drivers/video/fbdev/core/fbmem.c | 12 ++--
drivers/video/fbdev/core/svgalib.c | 15 +++
drivers/video/fbdev/s3fb.c | 15 +++
drivers/video/fbdev/vga16fb.c | 6 +-
drivers/video/fbdev/vt8623fb.c | 15 +++
include/linux/fb.h | 18 --
include/linux/font.h | 3 ++-
lib/fonts/fonts.c | 15 +--
11 files changed, 88 insertions(+), 44 deletions(-)
diff --git a/drivers/firmware/efi/earlycon.c b/drivers/firmware/efi/earlycon.c
index f80a9af3d16e..d18a1a5de144 100644
--- a/drivers/firmware/efi/earlycon.c
+++ b/drivers/firmware/efi/earlycon.c
@@ -252,7 +252,7 @@ static int __init efi_earlycon_setup(struct earlycon_device
*device,
if (si->lfb_depth != 32)
return -ENODEV;
- font = get_default_font(xres, yres, -1, -1);
+ font = get_default_font(xres, yres, NULL, NULL);
if (!font)
return -ENODEV;
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index dca9c0325b3f..082501feceb9 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -622,8 +622,13 @@ static int arkfb_set_par(struct fb_info *info)
info->tileops = NULL;
/* in 4bpp supports 8p wide tiles only, any tiles otherwise */
- info->pixmap.blit_x = (bpp == 4) ? (1 << (8 - 1)) : (~(u32)0);
- info->pixmap.blit_y = ~(u32)0;
+ if (bpp == 4) {
+ bitmap_zero(info->pixmap.blit_x, FB_MAX_BLIT_WIDTH);
+ set_bit(8 - 1, info->pixmap.blit_x);
+ } else {
+ bitmap_fill(info->pixmap.blit_x, FB_MAX_BLIT_WIDTH);
+ }
+ bitmap_fill(info->pixmap.blit_y, FB_MAX_BLIT_HEIGHT);
offset_value = (info->var.xres_virtual * bpp) / 64;
screen_size = info->var.yres_virtual * info->fix.line_length;
@@ -635,8 +640,10 @@ static int arkfb_set_par(struct fb_info *info)
info->tileops = _tile_ops;
/* supports 8x16 tiles only */
- info->pixmap.blit_x = 1 << (8 - 1);
- info->pixmap.blit_y = 1 << (16 - 1);
+ bitmap_zero(info->pixmap.blit_x, FB_MAX_BLIT_WIDTH);
+ set_bit(8 - 1, info->pixmap.blit_x);
+ bitmap_zero(info->pixmap.blit_y, FB_MAX_BLIT_HEIGHT);
+ set_bit(16 - 1, info->pixmap.blit_y);
offset_value = info->var.xres_virtual / 16;
screen_size = (info->var.xres_virtual * info->var.yres_virtual)
/ 64;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 46823c2e2ba1..72ff3147a3bf 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2483,12 +2483,12 @@ static int fbcon_set_font(struct vc_data *vc, struct
console_font *font,
h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
return -EINVAL;
- if (font->width > 32 || font->height > 32)
+ if (font->width > FB_MAX_BLIT_WIDTH || font->height >
FB_MAX_BLIT_HEIGHT)
return -EINVAL;
/* Make sure drawing engine can handle the font */
- if (!(info->pixmap.blit_x & BIT(font->width - 1)) ||
- !(info->pixmap.blit_y & BIT(font->height - 1)))
+ if (!test_bit(font->width - 1, info->pixmap.blit_x) ||
+ !test_bit(font->height - 1, info->pixmap.blit_y))
return -EINVAL;
/* Make sure driver can handle the font length */
@@ -3082,8 +3082,8 @@ void fbcon_get_requirement(struct fb_info *info,
vc = vc_cons[i].d;
if (vc && vc->vc_mode == KD_TEXT &&
info->node == con2fb_map[i]) {
- caps->x |= 1 << (vc->vc_font.width - 1);
- caps->y |= 1 << (vc->vc_font.height - 1);
+ set_bit(vc->vc_font.width - 1, caps->x);
+ set_bit(vc->vc_font.height - 1, caps->y);
charcnt =
