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 `&u32` 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 `&u32` 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 > + * @dp
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 = &it66121_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 nvm
[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: &kernel::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: &kernel::drm::device::Device, 349 | |data: &mut bindings::argument_type, 350 | |file: &kernel::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: &mut 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: &kernel::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: &kernel::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, &fops_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 &dp->debugfs_train_set[i], 2171 &fops_zynqmp_dp_preemphasis); 2172 2173 sprintf(name, "lane%d_swing", i); 2174 debugfs_create_file(name, 0600, test, 2175 &dp->debugfs_train_set[i], 2176 &fops_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 H
[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 "&pipe_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 = &pipe_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 = &dm_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
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 = &arkfb_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 = vc->