[PATCH v1 2/2] drm/panel: starry: add new panel driver
The starry panel is based on ER88577 controller. Add a driver for it. Signed-off-by: Zhaoxiong Lv --- drivers/gpu/drm/panel/panel-starry-er88577.c | 444 +++ 1 file changed, 444 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-starry-er88577.c diff --git a/drivers/gpu/drm/panel/panel-starry-er88577.c b/drivers/gpu/drm/panel/panel-starry-er88577.c new file mode 100644 index ..dfeae549adc5 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-starry-er88577.c @@ -0,0 +1,444 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Panels based on the ER88577B display controller. + * Author: Zhaoxiong Lv + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +struct panel_desc { + const struct drm_display_mode *modes; + unsigned int bpc; + + /** +* @width_mm: width of the panel's active display area +* @height_mm: height of the panel's active display area +*/ + struct { + unsigned int width_mm; + unsigned int height_mm; + } size; + + unsigned long mode_flags; + enum mipi_dsi_pixel_format format; + const struct panel_init_cmd *init_cmds; + unsigned int lanes; + bool discharge_on_disable; + bool lp11_before_reset; +}; + +struct starry_panel { + struct drm_panel base; + struct mipi_dsi_device *dsi; + + const struct panel_desc *desc; + + enum drm_panel_orientation orientation; + struct regulator *pp3300; + struct gpio_desc *enable_gpio; +}; + +enum dsi_cmd_type { + INIT_DCS_CMD, + DELAY_CMD, +}; + +struct panel_init_cmd { + enum dsi_cmd_type type; + size_t len; + const char *data; +}; + +#define _INIT_DCS_CMD(...) { \ + .type = INIT_DCS_CMD, \ + .len = sizeof((char[]){__VA_ARGS__}), \ + .data = (char[]){__VA_ARGS__} } + +#define _INIT_DELAY_CMD(...) { \ + .type = DELAY_CMD,\ + .len = sizeof((char[]){__VA_ARGS__}), \ + .data = (char[]){__VA_ARGS__} } + +static const struct panel_init_cmd starry_er88577_init_cmd[] = { + _INIT_DELAY_CMD(120), + _INIT_DCS_CMD(0xE0, 0xAB, 0xBA), + _INIT_DCS_CMD(0xE1, 0xBA, 0xAB), + _INIT_DCS_CMD(0xB1, 0x10, 0x01, 0x47, 0xFF), + _INIT_DCS_CMD(0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14), + _INIT_DCS_CMD(0xB3, 0x56, 0x53, 0x00), + _INIT_DCS_CMD(0xB4, 0x33, 0x30, 0x04), + _INIT_DCS_CMD(0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10, 0x00), + _INIT_DCS_CMD(0xB8, 0x05, 0x12, 0x29, 0x49, 0x40), + _INIT_DCS_CMD(0xB9, 0x7C, 0x61, 0x4F, 0x42, 0x3E, 0x2D, 0x31, 0x1A, 0x33, 0x33, 0x33, 0x52, 0x40, 0x47, 0x38, 0x34, 0x26, 0x0E, 0x06, 0x7C, 0x61, 0x4F, 0x42, 0x3E, 0x2D, 0x31, 0x1A, 0x33, 0x33, 0x33, 0x52, 0x40, 0x47, 0x38, 0x34, 0x26, 0x0E, 0x06), + _INIT_DCS_CMD(0xC0, 0xCC, 0x76, 0x12, 0x34, 0x44, 0x44, 0x44, 0x44, 0x98, 0x04, 0x98, 0x04, 0x0F, 0x00, 0x00, 0xC1), + _INIT_DCS_CMD(0xC1, 0x54, 0x94, 0x02, 0x85, 0x9F, 0x00, 0x6F, 0x00, 0x54, 0x00), + _INIT_DCS_CMD(0xC2, 0x17, 0x09, 0x08, 0x89, 0x08, 0x11, 0x22, 0x20, 0x44, 0xFF, 0x18, 0x00), + _INIT_DCS_CMD(0xC3, 0x87, 0x47, 0x05, 0x05, 0x1C, 0x1C, 0x1D, 0x1D, 0x02, 0x1E, 0x1E, 0x1F, 0x1F, 0x0F, 0x0F, 0x0D, 0x0D, 0x13, 0x13, 0x11, 0x11, 0x24), + _INIT_DCS_CMD(0xC4, 0x06, 0x06, 0x04, 0x04, 0x1C, 0x1C, 0x1D, 0x1D, 0x02, 0x1E, 0x1E, 0x1F, 0x1F, 0x0E, 0x0E, 0x0C, 0x0C, 0x12, 0x12, 0x10, 0x10, 0x24), + + _INIT_DCS_CMD(0xC8, 0x21, 0x00, 0x31, 0x42, 0x34, 0x16), + _INIT_DCS_CMD(0xCA, 0xCB, 0x43), + _INIT_DCS_CMD(0xCD, 0x0E, 0x4B, 0x4B, 0x20, 0x19, 0x6B, 0x06, 0xB3), + _INIT_DCS_CMD(0xD2, 0xE3, 0x2B, 0x38, 0x08), + _INIT_DCS_CMD(0xD4, 0x00, 0x01, 0x00, 0x0E, 0x04, 0x44, 0x08, 0x10, 0x00, 0x00, 0x00), + _INIT_DCS_CMD(0xE6, 0x80, 0x09, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF), + _INIT_DCS_CMD(0xF0, 0x12, 0x03, 0x20, 0x00, 0xFF), + _INIT_DCS_CMD(0xF3, 0x00), + + _INIT_DCS_CMD(0X11), + _INIT_DELAY_CMD(120), + _INIT_DCS_CMD(0X29), + _INIT_DELAY_CMD(20), + {}, +}; + +static inline struct starry_panel *to_starry_panel(struct drm_panel *panel) +{ + return container_of(panel, struct starry_panel, base); +} + +static int starry_panel_init_dcs_cmd(struct starry_panel *starry) +{ + struct mipi_dsi_device *dsi = starry->dsi; + struct drm_panel *panel = &starry->base; + int i, err = 0; + + if (starry->desc->init_cmds) { + const struct panel_init_cmd *init_cmds = starry->desc->init_cmds; + + for (i = 0; init_cmds[i].len != 0; i++) { + const struct panel_init_cmd *cmd = &init_cmds[i]; + + switch (cmd->type) { + case DELAY_CMD: + msleep(cmd->data[0]); + err = 0; + break; + +
[PATCH v1 1/2] dt-bindings: display: panel: Add Starry-er88577 support
Create a new dt-scheam for the Starry-er88577. Signed-off-by: Zhaoxiong Lv --- .../display/panel/starry,er88577.yaml | 59 +++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/starry,er88577.yaml diff --git a/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml b/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml new file mode 100644 index ..6686beaf0f16 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/starry,er88577.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/starry,er88577.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Starry Display ER88577 based MIPI-DSI panels + +description: | + -This binding is for display panels using an ER88577 controller + +maintainers: + - Zhaoxiong Lv + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +const: starry,er88577 + + pp3300-supply: true + reg: true + +required: + - compatible + - reg + - enable-gpios + - pp3300-supply + - backlight + - port + +unevaluatedProperties: false + +examples: + - | +#include + +dsi { +#address-cells = <1>; +#size-cells = <0>; +panel: panel@0 { +compatible = "starry,er88577"; +reg = <0>; +enable-gpios = <&pio 98 0>; +pinctrl-names = "default"; +pinctrl-0 = <&panel_pins_default>; +pp3300-supply = <&en_pp6000_mipi_disp>; +backlight = <&backlight_lcd0>; +rotation = <90>; +port { +panel_in: endpoint { +remote-endpoint = <&dsi_out>; +}; +}; +}; +}; + +... -- 2.17.1
[PATCH v1 0/2] Add starry bindings and driver
Add bindings and driver for starry. Zhaoxiong Lv (2): dt-bindings: display: panel: Add Starry-er88577 support drm/panel: starry: add new panel driver .../display/panel/starry,er88577.yaml | 59 +++ drivers/gpu/drm/panel/panel-starry-er88577.c | 444 ++ 2 files changed, 503 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/starry,er88577.yaml create mode 100644 drivers/gpu/drm/panel/panel-starry-er88577.c -- 2.17.1
Re: [PATCH v1 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili2900
hi all Sorry, there is a problem with this patch, please ignore this email. On Thu, May 9, 2024 at 2:43 PM Zhaoxiong Lv < lvzhaoxi...@huaqin.corp-partner.google.com> wrote: > From: lvzhaoxiong > > The ili2900 touch screen chip same as ilitek ili9882t controller > has a reset gpio. > > Signed-off-by: lvzhaoxiong > --- > Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml > b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml > index c5d9e0e919f9..5063ea2c8375 100644 > --- a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml > +++ b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml > @@ -19,6 +19,7 @@ allOf: > properties: >compatible: > const: ilitek,ili9882t > +const: ilitek,ili2900 > >reg: > const: 0x41 > -- > 2.17.1 > >
[PATCH v1 2/2] HID: i2c-hid: elan: Add ili2900 timing
From: lvzhaoxiong ILI2900 requires reset to pull down time greater than 10ms, so the configuration post_power_delay_ms is 10, and the chipset initial time is required to be greater than 100ms, so the post_gpio_reset_on_delay_ms is set to 100. Signed-off-by: lvzhaoxiong --- drivers/hid/i2c-hid/i2c-hid-of-elan.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/hid/i2c-hid/i2c-hid-of-elan.c b/drivers/hid/i2c-hid/i2c-hid-of-elan.c index 5b91fb106cfc..3073620b2dec 100644 --- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c +++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c @@ -137,10 +137,18 @@ static const struct elan_i2c_hid_chip_data ilitek_ili2901_chip_data = { .main_supply_name = "vcc33", }; +static const struct elan_i2c_hid_chip_data ilitek_ili2900_chip_data = { + .post_power_delay_ms = 10, + .post_gpio_reset_on_delay_ms = 100, + .hid_descriptor_address = 0x0001, + .main_supply_name = NULL, +}; + static const struct of_device_id elan_i2c_hid_of_match[] = { { .compatible = "elan,ekth6915", .data = &elan_ekth6915_chip_data }, { .compatible = "ilitek,ili9882t", .data = &ilitek_ili9882t_chip_data }, { .compatible = "ilitek,ili2901", .data = &ilitek_ili2901_chip_data }, + { .compatible = "ilitek,ili2900", .data = &ilitek_ili2900_chip_data }, { } }; MODULE_DEVICE_TABLE(of, elan_i2c_hid_of_match); -- 2.17.1
[PATCH v1 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili2900
From: lvzhaoxiong The ili2900 touch screen chip same as ilitek ili9882t controller has a reset gpio. Signed-off-by: lvzhaoxiong --- Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml index c5d9e0e919f9..5063ea2c8375 100644 --- a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml +++ b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml @@ -19,6 +19,7 @@ allOf: properties: compatible: const: ilitek,ili9882t +const: ilitek,ili2900 reg: const: 0x41 -- 2.17.1
Re: [PATCH 0/6] drm/v3d: Improve Performance Counters handling
Hi Maíra, I made a couple of minor comments, with those addressed the series is: Reviewed-by: Iago Toral Quiroga Thanks a lot for this!, Iago El mié, 08-05-2024 a las 11:30 -0300, Maíra Canal escribió: > This series has the intention to address two issues with Performance > Counters > on V3D: > > 1. Update the number of Performance Counters for V3D 7.1 > > V3D 7.1 has 93 performance counters, while V3D 4.2 has only 87. > Although the > series [1] enabled support for V3D 7.1, it didn’t replace the maximum > number of > performance counters. This led to errors in user space as the Vulkan > driver > updated the maximum number of performance counters, but the kernel > didn’t. > > Currently, the user space can request values for performance counters > that > are greater than 87 and the kernel will return an error instead of > the values. > That’s why `dEQP-VK.query_pool.performance_query.*` currently fails > on Mesa > CI [2]. This series intends to fix the `dEQP- > VK.query_pool.performance_query.*` > fail. > > 2. Make the kernel able to provide the Performance Counter > descriptions > > Although all the management of the Performance Monitors is done > through IOCTLs, > which means that the code is in the kernel, the performance counter > descriptions > are in Mesa. This means two things: (#1) only Mesa has access to the > descriptions > and (#2) we can have inconsistencies between the information provided > by Mesa > and the kernel, as seen in the first issue addressed by this series. > > To minimize the risk of inconsistencies, this series proposes to use > the kernel > as a “single source of truth”. Therefore, if there are any changes to > the > performance monitors, all the changes must be done only in the > kernel. This > means that all information about the maximum number of performance > counters and > all the descriptions will now be retrieved from the kernel. > > This series is coupled with a Mesa series [3] that enabled the use of > the new > IOCTL. I appreciate any feedback from both the kernel and Mesa > implementations. > > [1] > https://lore.kernel.org/dri-devel/20231031073859.25298-1-ito...@igalia.com/ > [2] > https://gitlab.freedesktop.org/mesa/mesa/-/commit/ea1f09a5f21839f4f3b93610b58507c4bd9b9b81 > [3] > https://gitlab.freedesktop.org/mairacanal/mesa/-/tree/v3dv/fix-perfcnt > > Best Regards, > - Maíra Canal > > Maíra Canal (6): > drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1 > drm/v3d: Different V3D versions can have different number of > perfcnt > drm/v3d: Create a new V3D parameter for the maximum number of > perfcnt > drm/v3d: Create new IOCTL to expose performance counters > information > drm/v3d: Use V3D_MAX_COUNTERS instead of V3D_PERFCNT_NUM > drm/v3d: Deprecate the use of the Performance Counters enum > > drivers/gpu/drm/v3d/v3d_drv.c | 11 + > drivers/gpu/drm/v3d/v3d_drv.h | 14 +- > drivers/gpu/drm/v3d/v3d_perfmon.c | 36 ++- > .../gpu/drm/v3d/v3d_performance_counters.h | 208 > ++ > drivers/gpu/drm/v3d/v3d_sched.c | 2 +- > include/uapi/drm/v3d_drm.h | 44 > 6 files changed, 312 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/v3d/v3d_performance_counters.h >
Re: [PATCH 6/6] drm/v3d: Deprecate the use of the Performance Counters enum
El mié, 08-05-2024 a las 11:30 -0300, Maíra Canal escribió: > The Performance Counters enum used to identify the index of each > performance counter and provide the total number of performance > counters (V3D_PERFCNT_NUM). But, this enum is only valid for V3D 4.2, > not for V3D 7.1. > > As we implemented a new flexible structure to retrieve performance > counters information, we can deprecate this enum. > > Signed-off-by: Maíra Canal > --- > include/uapi/drm/v3d_drm.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h > index 0860ddb3d0b6..706b4dea1c45 100644 > --- a/include/uapi/drm/v3d_drm.h > +++ b/include/uapi/drm/v3d_drm.h > @@ -603,6 +603,12 @@ struct drm_v3d_submit_cpu { > __u64 extensions; > }; > > +/* The performance counters index represented by this enum are > deprecated and > + * must no longer be used. These counters are only valid for V3D > 4.2. > + * > + * In order to check for performance counter information, > + * use DRM_IOCTL_V3D_PERFMON_GET_COUNTER. We should probably also include a reference to the new DRM_V3D_PARAM_MAX_PERF_COUNTERS param here as well to retrieve the total number of counters available. Iago > + */ > enum { > V3D_PERFCNT_FEP_VALID_PRIMTS_NO_PIXELS, > V3D_PERFCNT_FEP_VALID_PRIMS,
Re: [PATCH 5/6] drm/v3d: Use V3D_MAX_COUNTERS instead of V3D_PERFCNT_NUM
El mié, 08-05-2024 a las 11:30 -0300, Maíra Canal escribió: > V3D_PERFCNT_NUM represents the maximum number of performance counters > for V3D 4.2, but not for V3D 7.1. This means that, if we use > V3D_PERFCNT_NUM, we might go out-of-bounds on V3D 7.1. > > Therefore, use the number of performance counters on V3D 7.1 as the > maximum number of counters. This will allow us to create arrays on > the > stack with reasonable size. Note that userspace must use the value > provided by DRM_V3D_PARAM_V3D_MAX_PERF_COUNTERS. This should be DRM_V3D_PARAM_MAX_PERF_COUNTERS. Iago
[PATCH v4 4/6] drm/i915/alpm: Add compute config for lobf
Link Off Between Active Frames, is a new feature for eDP that allows the panel to go to lower power state after transmission of data. This is a feature on top of ALPM, AS SDP. Add compute config during atomic-check phase. v1: RFC version. v2: Add separate flag for auxless-alpm. [Jani] v3: - intel_dp->lobf_supported replaced with crtc_state->has_lobf. [Jouni] - Add DISPLAY_VER() check. [Jouni] - Modify function name of get_aux_less_status. [Jani] v4: Add enum alpm_mode to hold the aux-wake/less capability. Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/display/intel_alpm.c | 58 +++ drivers/gpu/drm/i915/display/intel_alpm.h | 5 ++ .../drm/i915/display/intel_display_types.h| 11 drivers/gpu/drm/i915/display/intel_dp.c | 4 ++ 4 files changed, 78 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c index ee6c2a959f09..5979eab1f2e0 100644 --- a/drivers/gpu/drm/i915/display/intel_alpm.c +++ b/drivers/gpu/drm/i915/display/intel_alpm.c @@ -11,6 +11,23 @@ #include "intel_dp_aux.h" #include "intel_psr_regs.h" +enum alpm_mode intel_alpm_get_capability(struct intel_dp *intel_dp) +{ + u8 alpm_caps = 0; + + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_RECEIVER_ALPM_CAP, + &alpm_caps) != 1) + return ALPM_INVALID; + + if (alpm_caps & DP_ALPM_CAP) + return ALPM_AUX_WAKE; + + if (alpm_caps & DP_ALPM_AUX_LESS_CAP) + return ALPM_AUX_LESS; + + return ALPM_NOT_SUPPORTED; +} + /* * See Bspec: 71632 for the table * @@ -242,6 +259,47 @@ bool intel_alpm_compute_params(struct intel_dp *intel_dp, return true; } +void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp, + struct intel_crtc_state *crtc_state, + struct drm_connector_state *conn_state) +{ + struct drm_i915_private *i915 = dp_to_i915(intel_dp); + struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode; + int waketime_in_lines, first_sdp_position; + int context_latency, guardband; + + if (!intel_dp_is_edp(intel_dp)) + return; + + if (DISPLAY_VER(i915) < 20) + return; + + if (!intel_dp_as_sdp_supported(intel_dp)) + return; + + if (crtc_state->has_psr) + return; + + if (intel_dp->alpm_parameters.mode == ALPM_INVALID || + intel_dp->alpm_parameters.mode == ALPM_NOT_SUPPORTED) + return; + + if (!intel_alpm_compute_params(intel_dp, crtc_state)) + return; + + context_latency = adjusted_mode->crtc_vblank_start - adjusted_mode->crtc_vdisplay; + guardband = adjusted_mode->crtc_vtotal - + adjusted_mode->crtc_vdisplay - context_latency; + first_sdp_position = adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vsync_start; + if (intel_dp->alpm_parameters.mode == ALPM_AUX_LESS) + waketime_in_lines = intel_dp->alpm_parameters.io_wake_lines; + else + waketime_in_lines = intel_dp->alpm_parameters.fast_wake_lines; + + crtc_state->has_lobf = (context_latency + guardband) > + (first_sdp_position + waketime_in_lines); +} + static void lnl_alpm_configure(struct intel_dp *intel_dp) { struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); diff --git a/drivers/gpu/drm/i915/display/intel_alpm.h b/drivers/gpu/drm/i915/display/intel_alpm.h index c45d078e5a6b..80c8a66b34af 100644 --- a/drivers/gpu/drm/i915/display/intel_alpm.h +++ b/drivers/gpu/drm/i915/display/intel_alpm.h @@ -10,9 +10,14 @@ struct intel_dp; struct intel_crtc_state; +struct drm_connector_state; +enum alpm_mode intel_alpm_get_capability(struct intel_dp *intel_dp); bool intel_alpm_compute_params(struct intel_dp *intel_dp, struct intel_crtc_state *crtc_state); +void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp, + struct intel_crtc_state *crtc_state, + struct drm_connector_state *conn_state); void intel_alpm_configure(struct intel_dp *intel_dp); #endif diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index e81fd71ce57b..79e9e543020b 100644 --- a/drivers/gpu/drm/i915/display/intel_display_types.h +++ b/drivers/gpu/drm/i915/display/intel_display_types.h @@ -1405,6 +1405,9 @@ struct intel_crtc_state { /* for loading single buffered registers during vblank */ struct drm_vblank_work vblank_work; + + /* LOBF flag */ + bool has_lobf; }; enum intel_pipe_crc_source { @@ -1715,6 +1718,13 @@ struct intel_psr { u8 entry_setup_frames; }; +enum alpm_mode { + ALPM_INVALID, + ALPM_AUX_WAKE, + ALPM_AUX_LESS, + ALPM_NOT_SUPPORT
[PATCH v4 6/6] drm/i915/alpm: Add debugfs for LOBF
For validation purpose add debugfs for LOBF. v1: Initial version. v2: Add aux-wake/less info along with lobf status. [Jouni] Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/display/intel_alpm.c | 49 +++ drivers/gpu/drm/i915/display/intel_alpm.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 2 + 3 files changed, 53 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c index c8eddc910cc5..b5b4c212de88 100644 --- a/drivers/gpu/drm/i915/display/intel_alpm.c +++ b/drivers/gpu/drm/i915/display/intel_alpm.c @@ -354,3 +354,52 @@ void intel_alpm_configure(struct intel_dp *intel_dp, { lnl_alpm_configure(intel_dp, crtc_state); } + +static int i915_edp_lobf_info_show(struct seq_file *m, void *data) +{ + struct intel_connector *connector = m->private; + struct drm_i915_private *dev_priv = to_i915(connector->base.dev); + struct drm_crtc *crtc; + struct intel_crtc_state *crtc_state; + enum transcoder cpu_transcoder; + u32 alpm_ctl; + int ret; + + ret = drm_modeset_lock_single_interruptible(&dev_priv->drm.mode_config.connection_mutex); + if (ret) + return ret; + + crtc = connector->base.state->crtc; + if (connector->base.status != connector_status_connected || !crtc) { + ret = -ENODEV; + goto out; + } + + crtc_state = to_intel_crtc_state(crtc->state); + cpu_transcoder = crtc_state->cpu_transcoder; + alpm_ctl = intel_de_read(dev_priv, ALPM_CTL(dev_priv, cpu_transcoder)); + seq_printf(m, "LOBF status: %s\n", str_enabled_disabled(alpm_ctl & ALPM_CTL_LOBF_ENABLE)); + seq_printf(m, "Aux-wake alpm status: %s\n", + str_enabled_disabled(!(alpm_ctl & ALPM_CTL_ALPM_AUX_LESS_ENABLE))); + seq_printf(m, "Aux-less alpm status: %s\n", + str_enabled_disabled(alpm_ctl & ALPM_CTL_ALPM_AUX_LESS_ENABLE)); +out: + drm_modeset_unlock(&dev_priv->drm.mode_config.connection_mutex); + + return ret; +} + +DEFINE_SHOW_ATTRIBUTE(i915_edp_lobf_info); + +void intel_alpm_lobf_debugfs_add(struct intel_connector *connector) +{ + struct drm_i915_private *i915 = to_i915(connector->base.dev); + struct dentry *root = connector->base.debugfs_entry; + + if (DISPLAY_VER(i915) < 20 || + connector->base.connector_type != DRM_MODE_CONNECTOR_eDP) + return; + + debugfs_create_file("i915_edp_lobf_info", 0444, root, + connector, &i915_edp_lobf_info_fops); +} diff --git a/drivers/gpu/drm/i915/display/intel_alpm.h b/drivers/gpu/drm/i915/display/intel_alpm.h index c0c085c1e5b0..8e1e0bbd44a3 100644 --- a/drivers/gpu/drm/i915/display/intel_alpm.h +++ b/drivers/gpu/drm/i915/display/intel_alpm.h @@ -11,6 +11,7 @@ struct intel_dp; struct intel_crtc_state; struct drm_connector_state; +struct intel_connector; enum alpm_mode intel_alpm_get_capability(struct intel_dp *intel_dp); bool intel_alpm_compute_params(struct intel_dp *intel_dp, @@ -20,4 +21,5 @@ void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp, struct drm_connector_state *conn_state); void intel_alpm_configure(struct intel_dp *intel_dp, const struct intel_crtc_state *crtc_state); +void intel_alpm_lobf_debugfs_add(struct intel_connector *connector); #endif diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index 35f9f86ef70f..86d9900c40af 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -13,6 +13,7 @@ #include "i915_debugfs.h" #include "i915_irq.h" #include "i915_reg.h" +#include "intel_alpm.h" #include "intel_crtc.h" #include "intel_de.h" #include "intel_crtc_state_dump.h" @@ -1515,6 +1516,7 @@ void intel_connector_debugfs_add(struct intel_connector *connector) intel_drrs_connector_debugfs_add(connector); intel_pps_connector_debugfs_add(connector); intel_psr_connector_debugfs_add(connector); + intel_alpm_lobf_debugfs_add(connector); if (connector_type == DRM_MODE_CONNECTOR_DisplayPort || connector_type == DRM_MODE_CONNECTOR_HDMIA || -- 2.29.0
[PATCH v4 5/6] drm/i915/alpm: Enable lobf from source in ALPM_CTL
Set the Link Off Between Frames Enable bit in ALPM_CTL register. Note: Lobf need to be enabled adaptive sync fixed refresh mode where vmin = vmax = flipline, which will arise after cmmr feature enablement. Will add enabling sequence in a separate patch. v1: Initial version. v2: Condition check modified in alpm_configure(). [Jouni] Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/display/intel_alpm.c | 16 +++- drivers/gpu/drm/i915/display/intel_alpm.h | 4 ++-- drivers/gpu/drm/i915/display/intel_psr.c | 2 +- 3 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c index 5979eab1f2e0..c8eddc910cc5 100644 --- a/drivers/gpu/drm/i915/display/intel_alpm.c +++ b/drivers/gpu/drm/i915/display/intel_alpm.c @@ -300,10 +300,11 @@ void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp, (first_sdp_position + waketime_in_lines); } -static void lnl_alpm_configure(struct intel_dp *intel_dp) +static void lnl_alpm_configure(struct intel_dp *intel_dp, + const struct intel_crtc_state *crtc_state) { struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); - enum transcoder cpu_transcoder = intel_dp->psr.transcoder; + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder; u32 alpm_ctl; if (DISPLAY_VER(dev_priv) < 20 || (!intel_dp->psr.psr2_enabled && @@ -314,7 +315,8 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp) * Panel Replay on eDP is always using ALPM aux less. I.e. no need to * check panel support at this point. */ - if (intel_dp->psr.panel_replay_enabled && intel_dp_is_edp(intel_dp)) { + if ((intel_dp->psr.panel_replay_enabled && intel_dp_is_edp(intel_dp)) || + (crtc_state->has_lobf && intel_dp->alpm_parameters.mode == ALPM_AUX_LESS)) { alpm_ctl = ALPM_CTL_ALPM_ENABLE | ALPM_CTL_ALPM_AUX_LESS_ENABLE | ALPM_CTL_AUX_LESS_SLEEP_HOLD_TIME_50_SYMBOLS; @@ -339,12 +341,16 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp) ALPM_CTL_EXTENDED_FAST_WAKE_TIME(intel_dp->alpm_parameters.fast_wake_lines); } + if (crtc_state->has_lobf) + alpm_ctl |= ALPM_CTL_LOBF_ENABLE; + alpm_ctl |= ALPM_CTL_ALPM_ENTRY_CHECK(intel_dp->alpm_parameters.check_entry_lines); intel_de_write(dev_priv, ALPM_CTL(dev_priv, cpu_transcoder), alpm_ctl); } -void intel_alpm_configure(struct intel_dp *intel_dp) +void intel_alpm_configure(struct intel_dp *intel_dp, + const struct intel_crtc_state *crtc_state) { - lnl_alpm_configure(intel_dp); + lnl_alpm_configure(intel_dp, crtc_state); } diff --git a/drivers/gpu/drm/i915/display/intel_alpm.h b/drivers/gpu/drm/i915/display/intel_alpm.h index 80c8a66b34af..c0c085c1e5b0 100644 --- a/drivers/gpu/drm/i915/display/intel_alpm.h +++ b/drivers/gpu/drm/i915/display/intel_alpm.h @@ -18,6 +18,6 @@ bool intel_alpm_compute_params(struct intel_dp *intel_dp, void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp, struct intel_crtc_state *crtc_state, struct drm_connector_state *conn_state); -void intel_alpm_configure(struct intel_dp *intel_dp); - +void intel_alpm_configure(struct intel_dp *intel_dp, + const struct intel_crtc_state *crtc_state); #endif diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 9e89844e6418..cd1afc82aefc 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -1620,7 +1620,7 @@ static void intel_psr_enable_source(struct intel_dp *intel_dp, IGNORE_PSR2_HW_TRACKING : 0); if (intel_dp_is_edp(intel_dp)) - intel_alpm_configure(intel_dp); + intel_alpm_configure(intel_dp, crtc_state); /* * Wa_16013835468 -- 2.29.0
[PATCH v4 3/6] drm/display: Add missing aux less alpm wake related bits
From: Jouni Högander eDP1.5 adds some more bits into DP_RECEIVER_ALPM_CAP and DP_RECEIVER_ALPM_CONFIG registers. Add definitions for these. Signed-off-by: Jouni Högander --- include/drm/display/drm_dp.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index 0b032faa8cf2..ad0cb0a1de87 100644 --- a/include/drm/display/drm_dp.h +++ b/include/drm/display/drm_dp.h @@ -232,6 +232,8 @@ #define DP_RECEIVER_ALPM_CAP 0x02e /* eDP 1.4 */ # define DP_ALPM_CAP (1 << 0) +# define DP_ALPM_PM_STATE_2A_SUPPORT (1 << 1) /* eDP 1.5 */ +# define DP_ALPM_AUX_LESS_CAP (1 << 2) /* eDP 1.5 */ #define DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP 0x02f /* eDP 1.4 */ # define DP_AUX_FRAME_SYNC_CAP (1 << 0) @@ -677,7 +679,8 @@ #define DP_RECEIVER_ALPM_CONFIG0x116 /* eDP 1.4 */ # define DP_ALPM_ENABLE(1 << 0) -# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE (1 << 1) +# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE (1 << 1) /* eDP 1.5 */ +# define DP_ALPM_MODE_AUX_LESS (1 << 2) /* eDP 1.5 */ #define DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF 0x117 /* eDP 1.4 */ # define DP_AUX_FRAME_SYNC_ENABLE (1 << 0) -- 2.29.0
[PATCH v4 2/6] drm/i915/alpm: Move alpm related code to a new file
Move ALPM feature related code as it will be used for non-psr panel also thorugh LOBF feature. v1: Initial version. v2: Correct ordering in makefile. [Jani] Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_alpm.c | 292 ++ drivers/gpu/drm/i915/display/intel_alpm.h | 18 ++ drivers/gpu/drm/i915/display/intel_psr.c | 282 + drivers/gpu/drm/xe/Makefile | 1 + 5 files changed, 315 insertions(+), 279 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_alpm.c create mode 100644 drivers/gpu/drm/i915/display/intel_alpm.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 7cad944b825c..9a3f910ce4fd 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -243,6 +243,7 @@ i915-y += \ display/hsw_ips.o \ display/i9xx_plane.o \ display/i9xx_wm.o \ + display/intel_alpm.o \ display/intel_atomic.o \ display/intel_atomic_plane.o \ display/intel_audio.o \ diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c new file mode 100644 index ..ee6c2a959f09 --- /dev/null +++ b/drivers/gpu/drm/i915/display/intel_alpm.c @@ -0,0 +1,292 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright 2024, Intel Corporation. + */ + +#include "intel_alpm.h" +#include "intel_crtc.h" +#include "intel_de.h" +#include "intel_display_types.h" +#include "intel_dp.h" +#include "intel_dp_aux.h" +#include "intel_psr_regs.h" + +/* + * See Bspec: 71632 for the table + * + * Silence_period = tSilence,Min + ((tSilence,Max - tSilence,Min) / 2) + * + * Half cycle duration: + * + * Link rates 1.62 - 4.32 and tLFPS_Cycle = 70 ns + * FLOOR( (Link Rate * tLFPS_Cycle) / (2 * 10) ) + * + * Link rates 5.4 - 8.1 + * PORT_ALPM_LFPS_CTL[ LFPS Cycle Count ] = 10 + * LFPS Period chosen is the mid-point of the min:max values from the table + * FLOOR( LFPS Period in Symbol clocks / + * (2 * PORT_ALPM_LFPS_CTL[ LFPS Cycle Count ]) ) + */ +static bool _lnl_get_silence_period_and_lfps_half_cycle(int link_rate, + int *silence_period, + int *lfps_half_cycle) +{ + switch (link_rate) { + case 162000: + *silence_period = 20; + *lfps_half_cycle = 5; + break; + case 216000: + *silence_period = 27; + *lfps_half_cycle = 7; + break; + case 243000: + *silence_period = 31; + *lfps_half_cycle = 8; + break; + case 27: + *silence_period = 34; + *lfps_half_cycle = 9; + break; + case 324000: + *silence_period = 41; + *lfps_half_cycle = 11; + break; + case 432000: + *silence_period = 56; + *lfps_half_cycle = 15; + break; + case 54: + *silence_period = 69; + *lfps_half_cycle = 12; + break; + case 648000: + *silence_period = 84; + *lfps_half_cycle = 15; + break; + case 675000: + *silence_period = 87; + *lfps_half_cycle = 15; + break; + case 81: + *silence_period = 104; + *lfps_half_cycle = 19; + break; + default: + *silence_period = *lfps_half_cycle = -1; + return false; + } + return true; +} + +/* + * AUX-Less Wake Time = CEILING( ((PHY P2 to P0) + tLFPS_Period, Max+ + * tSilence, Max+ tPHY Establishment + tCDS) / tline) + * For the "PHY P2 to P0" latency see the PHY Power Control page + * (PHY P2 to P0) : https://gfxspecs.intel.com/Predator/Home/Index/68965 + * : 12 us + * The tLFPS_Period, Max term is 800ns + * The tSilence, Max term is 180ns + * The tPHY Establishment (a.k.a. t1) term is 50us + * The tCDS term is 1 or 2 times t2 + * t2 = Number ML_PHY_LOCK * tML_PHY_LOCK + * Number ML_PHY_LOCK = ( 7 + CEILING( 6.5us / tML_PHY_LOCK ) + 1) + * Rounding up the 6.5us padding to the next ML_PHY_LOCK boundary and + * adding the "+ 1" term ensures all ML_PHY_LOCK sequences that start + * within the CDS period complete within the CDS period regardless of + * entry into the period + * tML_PHY_LOCK = TPS4 Length * ( 10 / (Link Rate in MHz) ) + * TPS4 Length = 252 Symbols + */ +static int _lnl_compute_aux_less_wake_time(int port_clock) +{ + int tphy2_p2_to_p0 = 12 * 1000; + int tlfps_period_max = 800; + int tsilence_max = 180; + int t1 = 50 * 1000; + int tps4 = 252; + int tml_phy_lock = 1000 * 1000 * tps4 * 10 / port_clock; + int num_ml_phy_lock = 7 + DIV_ROUND_UP(6500, tml_phy_lock) + 1; + int t2 = num_ml_
[PATCH v4 1/6] drm/i915/alpm: Move alpm parameters from intel_psr
ALPM can be enabled for non psr panel and currenly aplm-params are encapsulated under intel_psr struct, so moving out to intel_dp struct. Signed-off-by: Animesh Manna --- .../drm/i915/display/intel_display_types.h| 21 + drivers/gpu/drm/i915/display/intel_psr.c | 43 +-- 2 files changed, 31 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index 00eba3fbcdc6..e81fd71ce57b 100644 --- a/drivers/gpu/drm/i915/display/intel_display_types.h +++ b/drivers/gpu/drm/i915/display/intel_display_types.h @@ -1700,17 +1700,6 @@ struct intel_psr { bool psr2_sel_fetch_cff_enabled; bool req_psr2_sdp_prior_scanline; u8 sink_sync_latency; - - struct { - u8 io_wake_lines; - u8 fast_wake_lines; - - /* LNL and beyond */ - u8 check_entry_lines; - u8 silence_period_sym_clocks; - u8 lfps_half_cycle_num_of_syms; - } alpm_parameters; - ktime_t last_entry_attempt; ktime_t last_exit; bool sink_not_reliable; @@ -1840,6 +1829,16 @@ struct intel_dp { unsigned long last_oui_write; bool colorimetry_support; + + struct { + u8 io_wake_lines; + u8 fast_wake_lines; + + /* LNL and beyond */ + u8 check_entry_lines; + u8 silence_period_sym_clocks; + u8 lfps_half_cycle_num_of_syms; + } alpm_parameters; }; enum lspcon_vendor { diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 595eb1b3b6c6..13c0f44f48b9 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -816,8 +816,8 @@ static u32 intel_psr2_get_tp_time(struct intel_dp *intel_dp) static int psr2_block_count_lines(struct intel_dp *intel_dp) { - return intel_dp->psr.alpm_parameters.io_wake_lines < 9 && - intel_dp->psr.alpm_parameters.fast_wake_lines < 9 ? 8 : 12; + return intel_dp->alpm_parameters.io_wake_lines < 9 && + intel_dp->alpm_parameters.fast_wake_lines < 9 ? 8 : 12; } static int psr2_block_count(struct intel_dp *intel_dp) @@ -855,7 +855,6 @@ static void dg2_activate_panel_replay(struct intel_dp *intel_dp) static void hsw_activate_psr2(struct intel_dp *intel_dp) { struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); - struct intel_psr *psr = &intel_dp->psr; enum transcoder cpu_transcoder = intel_dp->psr.transcoder; u32 val = EDP_PSR2_ENABLE; u32 psr_val = 0; @@ -897,18 +896,19 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp) */ int tmp; - tmp = map[psr->alpm_parameters.io_wake_lines - + tmp = map[intel_dp->alpm_parameters.io_wake_lines - TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES]; val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(tmp + TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES); - tmp = map[psr->alpm_parameters.fast_wake_lines - TGL_EDP_PSR2_FAST_WAKE_MIN_LINES]; + tmp = map[intel_dp->alpm_parameters.fast_wake_lines - + TGL_EDP_PSR2_FAST_WAKE_MIN_LINES]; val |= TGL_EDP_PSR2_FAST_WAKE(tmp + TGL_EDP_PSR2_FAST_WAKE_MIN_LINES); } else if (DISPLAY_VER(dev_priv) >= 12) { - val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(psr->alpm_parameters.io_wake_lines); - val |= TGL_EDP_PSR2_FAST_WAKE(psr->alpm_parameters.fast_wake_lines); + val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(intel_dp->alpm_parameters.io_wake_lines); + val |= TGL_EDP_PSR2_FAST_WAKE(intel_dp->alpm_parameters.fast_wake_lines); } else if (DISPLAY_VER(dev_priv) >= 9) { - val |= EDP_PSR2_IO_BUFFER_WAKE(psr->alpm_parameters.io_wake_lines); - val |= EDP_PSR2_FAST_WAKE(psr->alpm_parameters.fast_wake_lines); + val |= EDP_PSR2_IO_BUFFER_WAKE(intel_dp->alpm_parameters.io_wake_lines); + val |= EDP_PSR2_FAST_WAKE(intel_dp->alpm_parameters.fast_wake_lines); } if (intel_dp->psr.req_psr2_sdp_prior_scanline) @@ -1294,9 +1294,9 @@ static int _lnl_compute_aux_less_alpm_params(struct intel_dp *intel_dp, if (i915->display.params.psr_safest_params) aux_less_wake_lines = ALPM_CTL_AUX_LESS_WAKE_TIME_MASK; - intel_dp->psr.alpm_parameters.fast_wake_lines = aux_less_wake_lines; - intel_dp->psr.alpm_parameters.silence_period_sym_clocks = silence_period; - intel_dp->psr.alpm_parameters.lfps_half_cycle_num_of_syms = lfps_half_cycle; + intel_dp->alpm_parameters.fast_wake_lines = aux_less_wake_lines; + intel_dp->alpm_parameters.silence_period_sym_clocks = silence_period; + intel_dp->alpm_parameters.lfps_half_cycle_num_of_syms =
[PATCH v4 0/6] Link off between frames for edp
Link Off Between Active Frames (LOBF) allows an eDP link to be turned Off and On durning long VBLANK durations without enabling any of the PSR/PSR2/PR modes of operation. Bspec: 71477 Note: Lobf need to be enabled adaptive sync fixed refresh mode where vmin = vmax = flipline, which will arise after cmmr feature enablement. Currently existing code refactored and make compute-config() and enabling function ready. Will add enabling sequence in a separate patch. Signed-off-by: Animesh Manna Animesh Manna (5): drm/i915/alpm: Move alpm parameters from intel_psr drm/i915/alpm: Move alpm related code to a new file drm/i915/alpm: Add compute config for lobf drm/i915/alpm: Enable lobf from source in ALPM_CTL drm/i915/alpm: Add debugfs for LOBF Jouni Högander (1): drm/display: Add missing aux less alpm wake related bits drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_alpm.c | 405 ++ drivers/gpu/drm/i915/display/intel_alpm.h | 25 ++ .../drm/i915/display/intel_display_debugfs.c | 2 + .../drm/i915/display/intel_display_types.h| 32 +- drivers/gpu/drm/i915/display/intel_dp.c | 4 + drivers/gpu/drm/i915/display/intel_psr.c | 301 + drivers/gpu/drm/xe/Makefile | 1 + include/drm/display/drm_dp.h | 5 +- 9 files changed, 475 insertions(+), 301 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_alpm.c create mode 100644 drivers/gpu/drm/i915/display/intel_alpm.h -- 2.29.0
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Re: [PATCH] drm/xe: Fix UBSAN shift-out-of-bounds failure
On Tue, May 07, 2024 at 01:04:11PM GMT, Shuicheng Lin wrote: Here is the failure stack: [ 12.988209] [ cut here ] [ 12.988216] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 12.988232] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 12.988235] CPU: 4 PID: 1310 Comm: gnome-shell Tainted: G U 6.9.0-rc6+prerelease1158+ #19 [ 12.988237] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.3301.A02.2208050712 08/05/2022 [ 12.988239] Call Trace: [ 12.988240] [ 12.988242] dump_stack_lvl+0xd7/0xf0 [ 12.988248] dump_stack+0x10/0x20 [ 12.988250] ubsan_epilogue+0x9/0x40 [ 12.988253] __ubsan_handle_shift_out_of_bounds+0x10e/0x170 [ 12.988260] dma_resv_reserve_fences.cold+0x2b/0x48 [ 12.988262] ? ww_mutex_lock_interruptible+0x3c/0x110 [ 12.988267] drm_exec_prepare_obj+0x45/0x60 [drm_exec] [ 12.988271] ? vm_bind_ioctl_ops_execute+0x5b/0x740 [xe] [ 12.988345] vm_bind_ioctl_ops_execute+0x78/0x740 [xe] It is caused by the value 0 of parameter num_fences in function drm_exec_prepare_obj. And lead to in function __rounddown_pow_of_two, "0 - 1" causes the shift-out-of-bounds. ok For num_fences == 0 case, drm_exec_prepare_obj is the same as drm_exec_lock_obj in function, so call drm_exec_lock_obj instead to solve it. this is not true and per discussion in this thread it's not going to change. drm_exec_prepare_obj() should not be called with num_fences == 0. So I'd reworded with something like below so we have all breadcrumbs for anyone trying to understand the changes later: By design drm_exec_prepare_obj() should be called only when there are fences to be reserved. If num_fences is 0, calling drm_exec_lock_obj() is sufficient as was done in commit 9377de4cb3e8 ("drm/xe/vm: Avoid reserving zero fences") Cc: Nirmoy Das Cc: Matthew Brost Signed-off-by: Shuicheng Lin with the reword, Reviewed-by: Lucas De Marchi And also add: Link: https://lore.kernel.org/all/24d4a9a9-c622-4f56-8672-21f4c6785...@amd.com Could you also submit a patch to add the warning like mentioned by Christian? thanks Lucas De Marchi --- drivers/gpu/drm/xe/xe_vm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index d17192c8b7de..c5b1694b292f 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -2692,7 +2692,7 @@ static int vma_lock_and_validate(struct drm_exec *exec, struct xe_vma *vma, if (bo) { if (!bo->vm) - err = drm_exec_prepare_obj(exec, &bo->ttm.base, 0); + err = drm_exec_lock_obj(exec, &bo->ttm.base); if (!err && validate) err = xe_bo_validate(bo, xe_vma_vm(vma), true); } @@ -2777,7 +2777,7 @@ static int vm_bind_ioctl_ops_lock_and_prep(struct drm_exec *exec, struct xe_vma_op *op; int err; - err = drm_exec_prepare_obj(exec, xe_vm_obj(vm), 0); + err = drm_exec_lock_obj(exec, xe_vm_obj(vm)); if (err) return err; -- 2.25.1
Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm
On Thu, May 9, 2024 at 9:28 AM Doug Anderson wrote: > > Hi, > > On Tue, May 7, 2024 at 4:05 PM Abhinav Kumar wrote: > > > > Since commit 5acf49119630 ("drm/msm: import gen_header.py script from > > Mesa"), > > compilation is broken on machines having python versions older than 3.9 > > due to dependency on argparse.BooleanOptionalAction. > > > > Switch to use simple bool for the validate flag to remove the dependency. > > > > Fixes: 5acf49119630 ("drm/msm: import gen_header.py script from Mesa") > > Signed-off-by: Abhinav Kumar > > --- > > drivers/gpu/drm/msm/registers/gen_header.py | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > No idea if we're supposed to allow python as a build dependency. That > being said, I can confirm that this fixes the problem for me since I > ran into it too [1]. > > Tested-by: Douglas Anderson > > [1] > https://lore.kernel.org/r/CAD=FV=XnpS-=cookkxzfm8og9wcsemxfesmftyh811438qg...@mail.gmail.com > I do not like Perl. IMHO, Python should be OK if Perl is OK. I agree that the required version should be documented changes.rst, at least. -- Best Regards Masahiro Yamada
[PATCH v5 7/7] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller which fits in nicely with the existing panel-himax-hx83102 driver. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang --- Chage since V5: - Adjust inital cmds indentation and check accum_err before calling mdelay in init(). - Adjust somes inital cmds to Optimize gamma. V4: https://lore.kernel.org/all/20240507135234.1356855-8-yangco...@huaqin.corp-partner.google.com Chage since V4: - inital cmds use lowercasehex. V3: https://lore.kernel.org/all/20240424023010.2099949-8-yangco...@huaqin.corp-partner.google.com Chage since V3: - Depend Dous'series [1]. [1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org V2: https://lore.kernel.org/all/20240422090310.3311429-8-yangco...@huaqin.corp-partner.google.com --- drivers/gpu/drm/panel/panel-himax-hx83102.c | 131 1 file changed, 131 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c b/drivers/gpu/drm/panel/panel-himax-hx83102.c index f1273e1c92d2..03a82e48da11 100644 --- a/drivers/gpu/drm/panel/panel-himax-hx83102.c +++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c @@ -293,6 +293,112 @@ static int boe_nv110wum_init(struct hx83102 *ctx) return 0; }; +static int ivo_t109nw41_init(struct hx83102 *ctx) +{ + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi }; + + msleep(60); + + hx83102_enable_extended_cmds(&dsi_ctx, true); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPOWER, 0x2c, 0xed, 0xed, 0x0f, 0xcf, 0x42, +0xf5, 0x39, 0x36, 0x36, 0x36, 0x36, 0x32, 0x8b, 0x11, 0x65, 0x00, 0x88, +0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 0xd6, 0x33); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETDISP, 0x00, 0x47, 0xb0, 0x80, 0x00, 0x12, +0x71, 0x3c, 0xa3, 0x22, 0x20, 0x00, 0x00, 0x88, 0x01); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETCYC, 0x35, 0x35, 0x43, 0x43, 0x35, 0x35, +0x30, 0x7a, 0x30, 0x7a, 0x01, 0x9d); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xcd); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETMIPI, 0x84); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETVDC, 0x1b, 0x04); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_UNKNOWN_BE, 0x20); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPTBA, 0xfc, 0xc4); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSTBA, 0x34, 0x34, 0x22, 0x11, 0x22, 0xa0, +0x31, 0x08, 0xf5, 0x03); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xcc); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETTCON, 0x80); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xd3); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETTCON, 0x22); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xc6); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETRAMDMY, 0x97); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPWM, 0x00, 0x1e, 0x13, 0x88, 0x01); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETCLOCK, 0x08, 0x13, 0x07, 0x00, 0x0f, 0x34); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPANEL, 0x02, 0x03, 0x44); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xc4); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETCASCADE, 0x03); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPCTRL, 0x07, 0x06, 0x00, 0x02, 0x04, 0x2c, +0xff); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETGIP0, 0x06, 0x00, 0x00, 0x00, 0x00, 0x08, +0x08, 0x08, 0x08, 0x37, 0x07, 0x64, 0x7c, 0x11, 0x11, 0x03, 0x03, 0x32, +0x10, 0x0e, 0x00, 0x0e, 0x32, 0x17, 0x97, 0x07, 0x97, 0x32, 0x00, 0x02, +0x00, 0x02, 0x00, 0x00); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETGIP1, 0x25, 0x24, 0x25, 0x24, 0x18, 0x18, +0x18, 0x18, 0x07, 0x06, 0x07, 0x06, 0x05, 0x04, 0x05, 0x04, 0x03, 0x02, +0x03, 0x02, 0x01, 0x00, 0x01, 0x00, 0x1e, 0x1e, 0x1e, 0x1e, 0x1f, 0x1f, +0x1f, 0x1f, 0x21, 0x20, 0x21, 0x20, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, +0x18, 0x18); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX831
[PATCH v5 6/7] dt-bindings: display: panel: Add compatible for IVO t109nw41
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102 controller. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang Acked-by: Conor Dooley --- Chage since V5: - No change. V4: https://lore.kernel.org/all/20240507135234.1356855-7-yangco...@huaqin.corp-partner.google.com Chage since V4: - No change. V3: https://lore.kernel.org/all/20240424023010.2099949-7-yangco...@huaqin.corp-partner.google.com Chage since V3: - Update commit message. V2: https://lore.kernel.org/all/20240422090310.3311429-7-yangco...@huaqin.corp-partner.google.com/ --- .../devicetree/bindings/display/panel/himax,hx83102.yaml| 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml index baf8b053e375..c649fb085833 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml @@ -18,6 +18,8 @@ properties: - enum: # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel - boe,nv110wum-l60 + # IVO t109nw41 11.0" WUXGA TFT LCD panel + - ivo,t109nw41 # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel - starry,himax83102-j02 - const: himax,hx83102 -- 2.25.1
[PATCH v5 5/7] drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller which fits in nicely with the existing panel-himax-hx83102 driver. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang --- Chage since V5: - Adjust inital cmds indentation and check accum_err before calling mdelay in init().. V4: https://lore.kernel.org/all/20240507135234.1356855-6-yangco...@huaqin.corp-partner.google.com Chage since V4: - Depend Dous'series [1]. [1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org V3: https://lore.kernel.org/all/20240424023010.2099949-6-yangco...@huaqin.corp-partner.google.com Chage since V3: - inital cmds use lowercasehex. V2: https://lore.kernel.org/all/20240422090310.3311429-6-yangco...@huaqin.corp-partner.google.com --- drivers/gpu/drm/panel/panel-himax-hx83102.c | 133 1 file changed, 133 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c b/drivers/gpu/drm/panel/panel-himax-hx83102.c index 76558b1091a8..f1273e1c92d2 100644 --- a/drivers/gpu/drm/panel/panel-himax-hx83102.c +++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c @@ -44,6 +44,7 @@ #define HX83102_SETGIP20xd6 #define HX83102_SETGIP30xd8 #define HX83102_SETGMA 0xe0 +#define HX83102_UNKNOWN_E1 0xe1 #define HX83102_SETTP1 0xe7 #define HX83102_SETSPCCMD 0xe9 @@ -185,6 +186,113 @@ static int starry_himax83102_j02_init(struct hx83102 *ctx) return dsi_ctx.accum_err; }; +static int boe_nv110wum_init(struct hx83102 *ctx) +{ + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi }; + + msleep(60); + + hx83102_enable_extended_cmds(&dsi_ctx, true); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPOWER, 0x2c, 0xaf, 0xaf, 0x2b, 0xeb, 0x42, +0xe1, 0x4d, 0x36, 0x36, 0x36, 0x36, 0x1a, 0x8b, 0x11, 0x65, 0x00, +0x88, 0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 0x9a, 0x33); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETDISP, 0x00, 0x47, 0xb0, 0x80, 0x00, 0x12, +0x71, 0x3c, 0xa3, 0x11, 0x00, 0x00, 0x00, 0x88, 0xf5, 0x22, 0x8f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETCYC, 0x49, 0x49, 0x32, 0x32, 0x14, 0x32, +0x84, 0x6e, 0x84, 0x6e, 0x01, 0x9c); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xcd); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETMIPI, 0x84); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETVDC, 0x1b, 0x04); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_UNKNOWN_BE, 0x20); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPTBA, 0xfc, 0x84); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSTBA, 0x36, 0x36, 0x22, 0x00, 0x00, 0xa0, +0x61, 0x08, 0xf5, 0x03); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xcc); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETTCON, 0x80); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xc6); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETRAMDMY, 0x97); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPWM, 0x00, 0x1e, 0x30, 0xd4, 0x01); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETCLOCK, 0x08, 0x13, 0x07, 0x00, 0x0f, 0x34); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPANEL, 0x02, 0x03, 0x44); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0xc4); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETCASCADE, 0x03); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETSPCCMD, 0x3f); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPCTRL, 0x37, 0x06, 0x00, 0x02, 0x04, 0x0c, 0xff); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_UNKNOWN_D2, 0x1f, 0x11, 0x1f, 0x11); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETGIP0, 0x06, 0x00, 0x00, 0x00, 0x00, 0x04, +0x08, 0x04, 0x08, 0x37, 0x37, 0x64, 0x4b, 0x11, 0x11, 0x03, 0x03, 0x32, +0x10, 0x0e, 0x00, 0x0e, 0x32, 0x10, 0x0a, 0x00, 0x0a, 0x32, 0x17, 0x98, +0x07, 0x98, 0x00, 0x00); + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETGIP1, 0x18, 0x18, 0x18, 0x18, 0x1e, 0x1e, +0x1e, 0x1e, 0x1f, 0x1f, 0x1f, 0x1f, 0x24, 0x24, 0x24, 0x24, 0x07, 0x06, +0x07, 0x06, 0x05, 0x04, 0x05, 0x04, 0x03, 0x02, 0x03, 0x02, 0x01, 0x00, +0x01, 0x00, 0x21, 0x20, 0x21, 0x20, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, +
[PATCH v5 4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102 controller. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang Acked-by: Conor Dooley --- Chage since V5: - No change. V4: https://lore.kernel.org/all/20240507135234.1356855-5-yangco...@huaqin.corp-partner.google.com Chage since V4: - No change. V3: https://lore.kernel.org/all/20240424023010.2099949-5-yangco...@huaqin.corp-partner.google.com Chage since V3: - Update commit message. V2: https://lore.kernel.org/all/20240422090310.3311429-5-yangco...@huaqin.corp-partner.google.com --- .../devicetree/bindings/display/panel/himax,hx83102.yaml| 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml index fc584b5088ff..baf8b053e375 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml @@ -16,6 +16,8 @@ properties: compatible: items: - enum: + # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel + - boe,nv110wum-l60 # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel - starry,himax83102-j02 - const: himax,hx83102 -- 2.25.1
[PATCH v5 3/7] arm64: defconfig: Enable HIMAX_HX83102 panel
DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6. Since the arm64 defconfig had the BOE panel driver enabled, let's also enable the himax driver. Signed-off-by: Cong Yang Reviewed-by: Douglas Anderson --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2c30d617e180..687c86ddaece 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -864,6 +864,7 @@ CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m CONFIG_DRM_PANEL_LVDS=m CONFIG_DRM_PANEL_SIMPLE=m CONFIG_DRM_PANEL_EDP=m +CONFIG_DRM_PANEL_HIMAX_HX83102=m CONFIG_DRM_PANEL_ILITEK_ILI9882T=m CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m CONFIG_DRM_PANEL_RAYDIUM_RM67191=m -- 2.25.1
[PATCH v5 2/7] drm/panel: himax-hx83102: Break out as separate driver
The Starry HX83102 based mipi panel should never have been part of the boe tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a separate driver to enable the hx83102 controller. In hx83102 driver, add DSI commands as macros. So it can add some panels with same control model in the future. In the old boe-tv101wum-nl6 driver inital cmds was invoked at the end of prepare() function , and call 0x11 and 0x29 at end of inital. For himax-hx83102 driver, we move 0x11 and 0x29 cmds invoked at enable() function. For panel timing, I think there is no much difference. Note:0x11 is mipi_dsi_dcs_exit_sleep_mode 0x29 is mipi_dsi_dcs_set_display_on [1]: https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com Signed-off-by: Cong Yang --- Chage since V5: - Modify hx83102_enable_extended_cmds function and adjust inital cmds indentation.update commit message. - Move the ->init() call to be made at the end of prepare() instead of the beginning of enable(). V4: https://lore.kernel.org/all/20240507135234.1356855-3-yangco...@huaqin.corp-partner.google.com Chage since V4: - Add hx83102_enable_extended_cmds function, rename UNKNOWN CMDS and depend Dous'series [1]. [1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org V3: https://lore.kernel.org/all/20240424023010.2099949-3-yangco...@huaqin.corp-partner.google.com Chage since V3: - Drop excess flags and function, inital cmds use lowercasehex. V2: https://lore.kernel.org/all/20240422090310.3311429-3-yangco...@huaqin.corp-partner.google.com --- drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 133 - drivers/gpu/drm/panel/panel-himax-hx83102.c | 477 ++ 4 files changed, 487 insertions(+), 133 deletions(-) create mode 100644 drivers/gpu/drm/panel/panel-himax-hx83102.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index d037b3b8b999..acd3d09b5a05 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -145,6 +145,15 @@ config DRM_PANEL_LVDS handling of power supplies or control signals. It implements automatic backlight handling if the panel is attached to a backlight controller. +config DRM_PANEL_HIMAX_HX83102 + tristate "Himax HX83102-based panels" + depends on OF + depends on DRM_MIPI_DSI + depends on BACKLIGHT_CLASS_DEVICE + help + Say Y if you want to enable support for panels based on the + Himax HX83102 controller. + config DRM_PANEL_HIMAX_HX83112A tristate "Himax HX83112A-based DSI panel" depends on OF diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index f156d7fa0bcc..8fa9e38382f6 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += panel-feiyang-fy07024di26a30d.o +obj-$(CONFIG_DRM_PANEL_HIMAX_HX83102) += panel-himax-hx83102.o obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c index aab60cec0603..4b4b125a6c6b 100644 --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c @@ -1399,108 +1399,6 @@ static int starry_qfh032011_53g_init(struct boe_panel *boe) return 0; }; -static int starry_himax83102_j02_init(struct boe_panel *boe) -{ - struct mipi_dsi_multi_context ctx = { .dsi = boe->dsi }; - - mipi_dsi_dcs_write_seq_multi(&ctx, 0xb9, 0x83, 0x10, 0x21, 0x55, 0x00); - mipi_dsi_dcs_write_seq_multi(&ctx, 0xb1, 0x2c, 0xb5, 0xb5, 0x31, 0xf1, 0x31, 0xd7, 0x2f, -0x36, 0x36, 0x36, 0x36, 0x1a, 0x8b, 0x11, 0x65, 0x00, 0x88, -0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 0x74, 0x33); - mipi_dsi_dcs_write_seq_multi(&ctx, 0xb2, 0x00, 0x47, 0xb0, 0x80, 0x00, 0x12, 0x72, 0x3c, -0xa3, 0x03, 0x03, 0x00, 0x00, 0x88, 0xf5); - mipi_dsi_dcs_write_seq_multi(&ctx, 0xb4, 0x76, 0x76, 0x76, 0x76, 0x76, 0x76, 0x63, 0x5c, -0x63, 0x5c, 0x01, 0x9e); - mipi_dsi_dcs_write_seq_multi(&ctx, 0xe9, 0xcd); - mipi_dsi_dcs_write_seq_multi(&ctx, 0xba, 0x84); - mipi_dsi_dcs_write_seq_multi(&ctx, 0xe9, 0x3f); - mipi_dsi_dcs_write_seq_multi(&ctx, 0xbc, 0x1b, 0x04); - mipi_dsi_dcs_write_seq_multi(&ctx, 0xbe, 0x20); -
[PATCH v5 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
In V1, discussed with Doug and Linus [1], we need break out as separate driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02" and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same controller, they have some common CMDS. So add new documentation for this panels. For himax83102-j02 controller, no need 3v3 supply, so remove it. [1]: https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com Signed-off-by: Cong Yang --- Chage since V5: - Modify compatible format. V4: https://lore.kernel.org/all/20240507135234.1356855-2-yangco...@huaqin.corp-partner.google.com Chage since V4: - Update commit message and add fallback compatible. V3: https://lore.kernel.org/all/20240424023010.2099949-2-yangco...@huaqin.corp-partner.google.com Chage since V3: - Update commit message. V2: https://lore.kernel.org/all/20240422090310.3311429-2-yangco...@huaqin.corp-partner.google.com --- .../display/panel/boe,tv101wum-nl6.yaml | 2 - .../bindings/display/panel/himax,hx83102.yaml | 73 +++ 2 files changed, 73 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index 906ef62709b8..53fb35f5c9de 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -32,8 +32,6 @@ properties: - innolux,hj110iz-01a # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel - starry,2081101qfh032011-53g -# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel - - starry,himax83102-j02 # STARRY ili9882t 10.51" WUXGA TFT LCD panel - starry,ili9882t diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml new file mode 100644 index ..fc584b5088ff --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/himax,hx83102.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Himax HX83102 MIPI-DSI LCD panel controller + +maintainers: + - Cong Yang + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +items: + - enum: + # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel + - starry,himax83102-j02 + - const: himax,hx83102 + + reg: +description: the virtual channel number of a DSI peripheral + + enable-gpios: +description: a GPIO spec for the enable pin + + pp1800-supply: +description: core voltage supply + + avdd-supply: +description: phandle of the regulator that provides positive voltage + + avee-supply: +description: phandle of the regulator that provides negative voltage + + backlight: true + port: true + rotation: true + +required: + - compatible + - reg + - enable-gpios + - pp1800-supply + - avdd-supply + - avee-supply + +additionalProperties: false + +examples: + - | +dsi { +#address-cells = <1>; +#size-cells = <0>; +panel@0 { +compatible = "starry,himax83102-j02", "himax,hx83102"; +reg = <0>; +enable-gpios = <&pio 45 0>; +avdd-supply = <&ppvarn_lcd>; +avee-supply = <&ppvarp_lcd>; +pp1800-supply = <&pp1800_lcd>; +backlight = <&backlight_lcd0>; +port { +panel_in: endpoint { +remote-endpoint = <&dsi_out>; +}; +}; +}; +}; + +... -- 2.25.1
[PATCH v5 0/7] Break out as separate driver and add BOE nv110wum-l60 IVO t109nw41 MIPI-DSI panel
Discussion with Doug and Linus in V1, we need a separate driver to enable the hx83102 controller. So this series this series mainly Break out as separate driver for Starry-himax83102-j02 panels from boe tv101wum driver. Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver. Add compatible for BOE nv110wum-l60 and IVO t109nw41 in dt-bindings Note:this series depend Dous'series [1] [1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org/ Changes in v5: - PATCH 1/7: Modify compatible format. - PATCH 2/7: Modify hx83102_enable_extended_cmds function and adjust inital cmds indentation.update commit message. - PATCH 3/7: No change. - PATCH 4/7: No change. - PATCH 5/7: Adjust inital cmds indentation and check accum_err before calling mdelay in init(). - PATCH 6/7: No change. - PATCH 7/7: Adjust inital cmds indentation and check accum_err before calling mdelay in init(). - Link to v4:https://lore.kernel.org/all/20240507135234.1356855-1-yangco...@huaqin.corp-partner.google.com Changes in v4: - PATCH 1/7: Update commit message and add fallback compatible. - PATCH 2/7: Add hx83102_enable_extended_cmds function, rename UNKNOWN CMDS and depend Dous'series [1]. - PATCH 3/7: No change. - PATCH 4/7: No change. - PATCH 5/7: Depend Dous'series [1]. - PATCH 6/7: No change. - PATCH 7/7: Depend Dous'series [1]. - Link to v3:https://lore.kernel.org/all/20240424023010.2099949-1-yangco...@huaqin.corp-partner.google.com/ Changes in v3: - PATCH 1/7: Update commit message. - PATCH 2/7: Drop excess flags and function, inital cmds use lowercasehex. - PATCH 4/7: Update commit message. - PATCH 5/7: inital cmds use lowercasehex. - PATCH 6/7: Update commit message. - PATCH 7/7: inital cmds use lowercasehex.. - Link to v2: https://lore.kernel.org/all/20240422090310.3311429-1-yangco...@huaqin.corp-partner.google.com/ Changes in v2: - PATCH 1/7: Delete Starry-himax83102-j02 from boe,tv101wum-nl6.yaml, add a new bindings file. - PATCH 2/7: Break out as separate driver with Starry-himax83102-j02 panels. - PATCH 3/7: Enable HIMAX_HX83102 panel. - PATCH 4/7: Add compatible for BOE nv110wum-l60 in dt-bindings. - PATCH 5/7: Support for BOE nv110wum-l60 MIPI-DSI panel. - PATCH 6/7: Add compatible for IVO t109nw41 in dt-bindings.. - PATCH 7/7: Support for IVO t109nw41 MIPI-DSI panel. - Link to v1: https://lore.kernel.org/all/20240410071439.2152588-1-yangco...@huaqin.corp-partner.google.com/ Cong Yang (7): dt-bindings: display: panel: Add himax hx83102 panel bindings drm/panel: himax-hx83102: Break out as separate driver arm64: defconfig: Enable HIMAX_HX83102 panel dt-bindings: display: panel: Add compatible for BOE nv110wum-l60 drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel dt-bindings: display: panel: Add compatible for IVO t109nw41 drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel .../display/panel/boe,tv101wum-nl6.yaml | 2 - .../bindings/display/panel/himax,hx83102.yaml | 77 ++ arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 133 drivers/gpu/drm/panel/panel-himax-hx83102.c | 741 ++ 7 files changed, 829 insertions(+), 135 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml create mode 100644 drivers/gpu/drm/panel/panel-himax-hx83102.c -- 2.25.1
[PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf to virtqueue. However, when the vbuf fails to upload and virtqueue_add_sgs returns -EIO or -ENOMEM, the vbuf will not be able to be free by virtio_gpu_dequeue_*_func, resulting in a continuous increase in memory allocated to vgdev ->vbufs. Therefore, make virtio_gpu_queue_ctrl_sgs and virtio_gpu_queue_cursor free vbuf directly after virtqueue_add_sgs returns -EIO or -ENOMEM. Signed-off-by: Weishi Li --- drivers/gpu/drm/virtio/virtgpu_vq.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index b1a00c0c25a7..6701ce9d0ee8 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -356,12 +356,14 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev, ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC); WARN_ON(ret); + if (ret < 0 && ret != -ENOSPC) { + free_vbuf(vgdev, vbuf); + } else { + vbuf->seqno = ++vgdev->ctrlq.seqno; + trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno); - vbuf->seqno = ++vgdev->ctrlq.seqno; - trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno); - - atomic_inc(&vgdev->pending_commands); - + atomic_inc(&vgdev->pending_commands); + } spin_unlock(&vgdev->ctrlq.qlock); drm_dev_exit(idx); @@ -469,6 +471,9 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev, wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt); spin_lock(&vgdev->cursorq.qlock); goto retry; + } else if (ret < 0) { + free_vbuf(vgdev, vbuf); + notify = false; } else { vbuf->seqno = ++vgdev->cursorq.seqno; trace_virtio_gpu_cmd_queue(vq, -- 2.25.1
Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm
Hi, On Tue, May 7, 2024 at 4:05 PM Abhinav Kumar wrote: > > Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"), > compilation is broken on machines having python versions older than 3.9 > due to dependency on argparse.BooleanOptionalAction. > > Switch to use simple bool for the validate flag to remove the dependency. > > Fixes: 5acf49119630 ("drm/msm: import gen_header.py script from Mesa") > Signed-off-by: Abhinav Kumar > --- > drivers/gpu/drm/msm/registers/gen_header.py | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) No idea if we're supposed to allow python as a build dependency. That being said, I can confirm that this fixes the problem for me since I ran into it too [1]. Tested-by: Douglas Anderson [1] https://lore.kernel.org/r/CAD=FV=XnpS-=cookkxzfm8og9wcsemxfesmftyh811438qg...@mail.gmail.com
Re: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
Hi Weishi, 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 linus/master v6.9-rc7 next-20240508] [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/Weishi-Li/drm-virtio-fix-memory-leak-of-vbuf/20240507-114452 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240507033814.57906-1-liweishi%40kylinos.cn patch subject: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf config: i386-buildonly-randconfig-001-20240508 (https://download.01.org/0day-ci/archive/20240509/202405090747.y8ofue7r-...@intel.com/config) compiler: clang version 18.1.4 (https://github.com/llvm/llvm-project e6c3289804a67ea0bb6a86fadbe454dd93b8d855) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240509/202405090747.y8ofue7r-...@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/202405090747.y8ofue7r-...@intel.com/ All warnings (new ones prefixed by >>): >> drivers/gpu/drm/virtio/virtgpu_vq.c:474:13: warning: variable 'notify' is >> used uninitialized whenever 'if' condition is true >> [-Wsometimes-uninitialized] 474 | } else if (ret < 0) { |^~~ drivers/gpu/drm/virtio/virtgpu_vq.c:487:6: note: uninitialized use occurs here 487 | if (notify) | ^~ drivers/gpu/drm/virtio/virtgpu_vq.c:474:9: note: remove the 'if' if its condition is always false 474 | } else if (ret < 0) { |^~ 475 | free_vbuf(vgdev, vbuf); | ~~~ 476 | } else { | ~~ drivers/gpu/drm/virtio/virtgpu_vq.c:455:13: note: initialize the variable 'notify' to silence this warning 455 | bool notify; |^ | = 0 1 warning generated. vim +474 drivers/gpu/drm/virtio/virtgpu_vq.c 448 449 static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev, 450 struct virtio_gpu_vbuffer *vbuf) 451 { 452 struct virtqueue *vq = vgdev->cursorq.vq; 453 struct scatterlist *sgs[1], ccmd; 454 int idx, ret, outcnt; 455 bool notify; 456 457 if (!drm_dev_enter(vgdev->ddev, &idx)) { 458 free_vbuf(vgdev, vbuf); 459 return; 460 } 461 462 sg_init_one(&ccmd, vbuf->buf, vbuf->size); 463 sgs[0] = &ccmd; 464 outcnt = 1; 465 466 spin_lock(&vgdev->cursorq.qlock); 467 retry: 468 ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC); 469 if (ret == -ENOSPC) { 470 spin_unlock(&vgdev->cursorq.qlock); 471 wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt); 472 spin_lock(&vgdev->cursorq.qlock); 473 goto retry; > 474 } else if (ret < 0) { 475 free_vbuf(vgdev, vbuf); 476 } else { 477 vbuf->seqno = ++vgdev->cursorq.seqno; 478 trace_virtio_gpu_cmd_queue(vq, 479 virtio_gpu_vbuf_ctrl_hdr(vbuf), 480 vbuf->seqno); 481 482 notify = virtqueue_kick_prepare(vq); 483 } 484 485 spin_unlock(&vgdev->cursorq.qlock); 486 487 if (notify) 488 virtqueue_notify(vq); 489 490 drm_dev_exit(idx); 491 } 492 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[PATCH v3 6/6] fbdev/viafb: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Compile tested, no functionality changes intended Acked-by: Thomas Zimmermann Signed-off-by: Easwar Hariharan --- drivers/video/fbdev/via/chip.h| 8 drivers/video/fbdev/via/dvi.c | 24 drivers/video/fbdev/via/lcd.c | 6 +++--- drivers/video/fbdev/via/via_aux.h | 2 +- drivers/video/fbdev/via/via_i2c.c | 12 ++-- drivers/video/fbdev/via/vt1636.c | 6 +++--- 6 files changed, 29 insertions(+), 29 deletions(-) diff --git a/drivers/video/fbdev/via/chip.h b/drivers/video/fbdev/via/chip.h index f0a19cbcb9e5d..f81af13630e28 100644 --- a/drivers/video/fbdev/via/chip.h +++ b/drivers/video/fbdev/via/chip.h @@ -69,7 +69,7 @@ #define VT1632_TMDS 0x01 #define INTEGRATED_TMDS 0x42 -/* Definition TMDS Trasmitter I2C Slave Address */ +/* Definition TMDS Trasmitter I2C Target Address */ #define VT1632_TMDS_I2C_ADDR0x10 /**/ @@ -88,21 +88,21 @@ #define TX_DATA_DDR_MODE0x04 #define TX_DATA_SDR_MODE0x08 -/* Definition LVDS Trasmitter I2C Slave Address */ +/* Definition LVDS Trasmitter I2C Target Address */ #define VT1631_LVDS_I2C_ADDR0x70 #define VT3271_LVDS_I2C_ADDR0x80 #define VT1636_LVDS_I2C_ADDR0x80 struct tmds_chip_information { int tmds_chip_name; - int tmds_chip_slave_addr; + int tmds_chip_target_addr; int output_interface; int i2c_port; }; struct lvds_chip_information { int lvds_chip_name; - int lvds_chip_slave_addr; + int lvds_chip_target_addr; int output_interface; int i2c_port; }; diff --git a/drivers/video/fbdev/via/dvi.c b/drivers/video/fbdev/via/dvi.c index 13147e3066ebf..27990a73bfa39 100644 --- a/drivers/video/fbdev/via/dvi.c +++ b/drivers/video/fbdev/via/dvi.c @@ -70,7 +70,7 @@ bool viafb_tmds_trasmitter_identify(void) /* Check for VT1632: */ viaparinfo->chip_info->tmds_chip_info.tmds_chip_name = VT1632_TMDS; viaparinfo->chip_info-> - tmds_chip_info.tmds_chip_slave_addr = VT1632_TMDS_I2C_ADDR; + tmds_chip_info.tmds_chip_target_addr = VT1632_TMDS_I2C_ADDR; viaparinfo->chip_info->tmds_chip_info.i2c_port = VIA_PORT_31; if (check_tmds_chip(VT1632_DEVICE_ID_REG, VT1632_DEVICE_ID)) { /* @@ -128,14 +128,14 @@ bool viafb_tmds_trasmitter_identify(void) viaparinfo->chip_info-> tmds_chip_info.tmds_chip_name = NON_TMDS_TRANSMITTER; viaparinfo->chip_info->tmds_chip_info. - tmds_chip_slave_addr = VT1632_TMDS_I2C_ADDR; + tmds_chip_target_addr = VT1632_TMDS_I2C_ADDR; return false; } static void tmds_register_write(int index, u8 data) { viafb_i2c_writebyte(viaparinfo->chip_info->tmds_chip_info.i2c_port, - viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr, + viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr, index, data); } @@ -144,7 +144,7 @@ static int tmds_register_read(int index) u8 data; viafb_i2c_readbyte(viaparinfo->chip_info->tmds_chip_info.i2c_port, - (u8) viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr, + (u8) viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr, (u8) index, &data); return data; } @@ -152,7 +152,7 @@ static int tmds_register_read(int index) static int tmds_register_read_bytes(int index, u8 *buff, int buff_len) { viafb_i2c_readbytes(viaparinfo->chip_info->tmds_chip_info.i2c_port, - (u8) viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr, + (u8) viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr, (u8) index, buff, buff_len); return 0; } @@ -256,14 +256,14 @@ static int viafb_dvi_query_EDID(void) DEBUG_MSG(KERN_INFO "viafb_dvi_query_EDID!!\n"); - restore = viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr; - viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr = 0xA0; + restore = viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr; + viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr = 0xA0; data0 = (u8) tmds_register_read(0x00); data1 = (u8) tmds_register_read(0x01); if ((data0 == 0) && (data1 == 0xFF)) { viaparinfo->chip_info-> - tmds_chip_info.tmds_chip_slave_addr = restore; + tmds_chi
[PATCH v3 4/6] sfc: falcon: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Compile tested, no functionality changes intended Reviewed-by: Martin Habets Reviewed-by: Simon Horman Signed-off-by: Easwar Hariharan --- drivers/net/ethernet/sfc/falcon/falcon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/sfc/falcon/falcon.c b/drivers/net/ethernet/sfc/falcon/falcon.c index 7a1c9337081b5..36114ce88034c 100644 --- a/drivers/net/ethernet/sfc/falcon/falcon.c +++ b/drivers/net/ethernet/sfc/falcon/falcon.c @@ -367,7 +367,7 @@ static const struct i2c_algo_bit_data falcon_i2c_bit_operations = { .getsda = falcon_getsda, .getscl = falcon_getscl, .udelay = 5, - /* Wait up to 50 ms for slave to let us pull SCL high */ + /* Wait up to 50 ms for target to let us pull SCL high */ .timeout= DIV_ROUND_UP(HZ, 20), }; -- 2.34.1
[PATCH v3 5/6] fbdev/smscufx: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Compile tested, no functionality changes intended Acked-by: Thomas Zimmermann Signed-off-by: Easwar Hariharan --- drivers/video/fbdev/smscufx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c index 35d682b110c42..5f0dd01fd8349 100644 --- a/drivers/video/fbdev/smscufx.c +++ b/drivers/video/fbdev/smscufx.c @@ -1292,7 +1292,7 @@ static int ufx_realloc_framebuffer(struct ufx_data *dev, struct fb_info *info) return 0; } -/* sets up I2C Controller for 100 Kbps, std. speed, 7-bit addr, master, +/* sets up DDC channel for 100 Kbps, std. speed, 7-bit addr, controller mode, * restart enabled, but no start byte, enable controller */ static int ufx_i2c_init(struct ufx_data *dev) { @@ -1321,7 +1321,7 @@ static int ufx_i2c_init(struct ufx_data *dev) /* 7-bit (not 10-bit) addressing */ tmp &= ~(0x10); - /* enable restart conditions and master mode */ + /* enable restart conditions and controller mode */ tmp |= 0x21; status = ufx_reg_write(dev, 0x1000, tmp); -- 2.34.1
[PATCH v3 3/6] drm/i915: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Compile tested, no functionality changes intended Reviewed-by: Rodrigo Vivi Acked-by: Rodrigo Vivi Acked-by: Zhi Wang Signed-off-by: Easwar Hariharan --- drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 - drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +-- drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +- drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +-- drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +-- drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +-- drivers/gpu/drm/i915/display/intel_bios.c | 22 +++--- .../gpu/drm/i915/display/intel_display_core.h | 2 +- drivers/gpu/drm/i915/display/intel_dsi.h | 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--- drivers/gpu/drm/i915/display/intel_dvo.c | 14 - drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +-- drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +-- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +-- drivers/gpu/drm/i915/gvt/edid.c | 28 - drivers/gpu/drm/i915/gvt/edid.h | 4 +-- drivers/gpu/drm/i915/gvt/opregion.c | 2 +- 18 files changed, 118 insertions(+), 118 deletions(-) diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c b/drivers/gpu/drm/i915/display/dvo_ch7017.c index d0c3880d7f80f..493e730c685b8 100644 --- a/drivers/gpu/drm/i915/display/dvo_ch7017.c +++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c @@ -170,13 +170,13 @@ static bool ch7017_read(struct intel_dvo_device *dvo, u8 addr, u8 *val) { struct i2c_msg msgs[] = { { - .addr = dvo->slave_addr, + .addr = dvo->target_addr, .flags = 0, .len = 1, .buf = &addr, }, { - .addr = dvo->slave_addr, + .addr = dvo->target_addr, .flags = I2C_M_RD, .len = 1, .buf = val, @@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8 addr, u8 val) { u8 buf[2] = { addr, val }; struct i2c_msg msg = { - .addr = dvo->slave_addr, + .addr = dvo->target_addr, .flags = 0, .len = 2, .buf = buf, @@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8 addr, u8 val) return i2c_transfer(dvo->i2c_bus, &msg, 1) == 1; } -/** Probes for a CH7017 on the given bus and slave address. */ +/** Probes for a CH7017 on the given bus and target address. */ static bool ch7017_init(struct intel_dvo_device *dvo, struct i2c_adapter *adapter) { @@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device *dvo, break; default: DRM_DEBUG_KMS("ch701x not detected, got %d: from %s " - "slave %d.\n", - val, adapter->name, dvo->slave_addr); + "target %d.\n", + val, adapter->name, dvo->target_addr); goto fail; } DRM_DEBUG_KMS("%s detected on %s, addr %d\n", - str, adapter->name, dvo->slave_addr); + str, adapter->name, dvo->target_addr); return true; fail: diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c index 2e8e85da5a409..534b8544e0a41 100644 --- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c +++ b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c @@ -153,13 +153,13 @@ static bool ch7xxx_readb(struct intel_dvo_device *dvo, int addr, u8 *ch) struct i2c_msg msgs[] = { { - .addr = dvo->slave_addr, + .addr = dvo->target_addr, .flags = 0, .len = 1, .buf = out_buf, }, { - .addr = dvo->slave_addr, + .addr = dvo->target_addr, .flags = I2C_M_RD, .len = 1, .buf = in_buf, @@ -176,7 +176,7 @@ static bool ch7xxx_readb(struct intel_dvo_device *dvo, int addr, u8 *ch) if (!ch7xxx->quiet) { DRM_DEBUG_KMS("Unable to read register 0x%02x from %s:%02x.\n", - addr, adapter->name, dvo->slave_addr); + addr, adapter->name, dvo
[PATCH v3 2/6] drm/gma500: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Compile tested, no functionality changes intended Acked-by: Thomas Zimmermann Signed-off-by: Easwar Hariharan --- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/intel_bios.c | 22 ++--- drivers/gpu/drm/gma500/intel_bios.h | 4 ++-- drivers/gpu/drm/gma500/intel_gmbus.c| 2 +- drivers/gpu/drm/gma500/psb_drv.h| 2 +- drivers/gpu/drm/gma500/psb_intel_drv.h | 2 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 4 ++-- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 26 - 8 files changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c b/drivers/gpu/drm/gma500/cdv_intel_lvds.c index f08a6803dc184..c7652a02b42ec 100644 --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c @@ -565,7 +565,7 @@ void cdv_intel_lvds_init(struct drm_device *dev, dev->dev, "I2C bus registration failed.\n"); goto err_encoder_cleanup; } - gma_encoder->i2c_bus->slave_addr = 0x2C; + gma_encoder->i2c_bus->target_addr = 0x2C; dev_priv->lvds_i2c_bus = gma_encoder->i2c_bus; /* diff --git a/drivers/gpu/drm/gma500/intel_bios.c b/drivers/gpu/drm/gma500/intel_bios.c index 8245b5603d2c0..d5924ca3ed050 100644 --- a/drivers/gpu/drm/gma500/intel_bios.c +++ b/drivers/gpu/drm/gma500/intel_bios.c @@ -14,8 +14,8 @@ #include "psb_intel_drv.h" #include "psb_intel_reg.h" -#defineSLAVE_ADDR1 0x70 -#defineSLAVE_ADDR2 0x72 +#defineTARGET_ADDR10x70 +#defineTARGET_ADDR20x72 static void *find_section(struct bdb_header *bdb, int section_id) { @@ -357,10 +357,10 @@ parse_sdvo_device_mapping(struct drm_psb_private *dev_priv, /* skip the device block if device type is invalid */ continue; } - if (p_child->slave_addr != SLAVE_ADDR1 && - p_child->slave_addr != SLAVE_ADDR2) { + if (p_child->target_addr != TARGET_ADDR1 && + p_child->target_addr != TARGET_ADDR2) { /* -* If the slave address is neither 0x70 nor 0x72, +* If the target address is neither 0x70 nor 0x72, * it is not a SDVO device. Skip it. */ continue; @@ -371,22 +371,22 @@ parse_sdvo_device_mapping(struct drm_psb_private *dev_priv, DRM_DEBUG_KMS("Incorrect SDVO port. Skip it\n"); continue; } - DRM_DEBUG_KMS("the SDVO device with slave addr %2x is found on" + DRM_DEBUG_KMS("the SDVO device with target addr %2x is found on" " %s port\n", - p_child->slave_addr, + p_child->target_addr, (p_child->dvo_port == DEVICE_PORT_DVOB) ? "SDVOB" : "SDVOC"); p_mapping = &(dev_priv->sdvo_mappings[p_child->dvo_port - 1]); if (!p_mapping->initialized) { p_mapping->dvo_port = p_child->dvo_port; - p_mapping->slave_addr = p_child->slave_addr; + p_mapping->target_addr = p_child->target_addr; p_mapping->dvo_wiring = p_child->dvo_wiring; p_mapping->ddc_pin = p_child->ddc_pin; p_mapping->i2c_pin = p_child->i2c_pin; p_mapping->initialized = 1; DRM_DEBUG_KMS("SDVO device: dvo=%x, addr=%x, wiring=%d, ddc_pin=%d, i2c_pin=%d\n", p_mapping->dvo_port, - p_mapping->slave_addr, + p_mapping->target_addr, p_mapping->dvo_wiring, p_mapping->ddc_pin, p_mapping->i2c_pin); @@ -394,10 +394,10 @@ parse_sdvo_device_mapping(struct drm_psb_private *dev_priv, DRM_DEBUG_KMS("Maybe one SDVO port is shared by " "two SDVO device.\n"); } - if (p_child->slave2_addr) { + if (p_child->target2_addr) { /* Maybe this is a SDVO device with multiple inputs */ /* And the mapping info is not added */ - DRM_DEBUG_KMS("there exists the slave2_addr. Maybe this"
[PATCH v3 1/6] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Compile tested, no functionality changes intended Acked-by: Alex Deucher Signed-off-by: Easwar Hariharan --- .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 8 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 10 +++ drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 8 +++--- drivers/gpu/drm/amd/amdgpu/atombios_i2c.h | 2 +- drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++--- .../gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +- .../drm/amd/display/dc/bios/bios_parser2.c| 2 +- .../drm/amd/display/dc/core/dc_link_exports.c | 4 +-- drivers/gpu/drm/amd/display/dc/dc.h | 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c | 4 +-- .../display/include/grph_object_ctrl_defs.h | 2 +- drivers/gpu/drm/amd/include/atombios.h| 2 +- drivers/gpu/drm/amd/include/atomfirmware.h| 26 - .../powerplay/hwmgr/vega20_processpptables.c | 4 +-- .../amd/pm/powerplay/inc/smu11_driver_if.h| 2 +- .../inc/pmfw_if/smu11_driver_if_arcturus.h| 2 +- .../inc/pmfw_if/smu11_driver_if_navi10.h | 2 +- .../pmfw_if/smu11_driver_if_sienna_cichlid.h | 2 +- .../inc/pmfw_if/smu13_driver_if_aldebaran.h | 2 +- .../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 2 +- .../inc/pmfw_if/smu13_driver_if_v13_0_7.h | 2 +- .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 4 +-- .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 8 +++--- drivers/gpu/drm/radeon/atombios.h | 16 +-- drivers/gpu/drm/radeon/atombios_i2c.c | 4 +-- drivers/gpu/drm/radeon/radeon_combios.c | 28 +-- drivers/gpu/drm/radeon/radeon_i2c.c | 10 +++ drivers/gpu/drm/radeon/radeon_mode.h | 6 ++-- 28 files changed, 93 insertions(+), 93 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c index 6857c586ded71..37f50fc5d4961 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c @@ -614,7 +614,7 @@ bool amdgpu_atomfirmware_ras_rom_addr(struct amdgpu_device *adev, if ((frev == 3 && crev >= 4) || (frev > 3)) { firmware_info = (union firmware_info *) (mode_info->atom_context->bios + data_offset); - /* The ras_rom_i2c_slave_addr should ideally + /* The ras_rom_i2c_target_addr should ideally * be a 19-bit EEPROM address, which would be * used as is by the driver; see top of * amdgpu_eeprom.c. @@ -625,13 +625,13 @@ bool amdgpu_atomfirmware_ras_rom_addr(struct amdgpu_device *adev, * leave the check for the pointer. * * The reason this works right now is because -* ras_rom_i2c_slave_addr contains the EEPROM +* ras_rom_i2c_target_addr contains the EEPROM * device type qualifier 1010b in the top 4 * bits. */ - if (firmware_info->v34.ras_rom_i2c_slave_addr) { + if (firmware_info->v34.ras_rom_i2c_target_addr) { if (i2c_address) - *i2c_address = firmware_info->v34.ras_rom_i2c_slave_addr; + *i2c_address = firmware_info->v34.ras_rom_i2c_target_addr; return true; } } diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c index d79cb13e1aa83..070049c92e2b4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c @@ -280,7 +280,7 @@ amdgpu_i2c_lookup(struct amdgpu_device *adev, } static void amdgpu_i2c_get_byte(struct amdgpu_i2c_chan *i2c_bus, -u8 slave_addr, +u8 target_addr, u8 addr, u8 *val) { @@ -288,13 +288,13 @@ static void amdgpu_i2c_get_byte(struct amdgpu_i2c_chan *i2c_bus, u8 in_buf[2]; struct i2c_msg msgs[] = { { - .addr = slave_addr, + .addr = target_addr, .flags = 0, .len = 1, .buf = out_buf, }, { - .addr = slave_addr, + .addr = target_addr,
[PATCH v3 0/6] Make I2C terminology more inclusive for I2C Algobit and consumers
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by and following on to Wolfram's series to fix drivers/i2c/[1], fix the terminology for users of the I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Compile tested, no functionality changes intended Please chime in with your opinions and suggestions. This series is based on v6.9-rc7 [1]: https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ changelog: v2->v3: - v2 link: https://lore.kernel.org/all/20240503181333.2336999-1-eahar...@linux.microsoft.com/ - Drop drivers/media patches [Mauro] - Pick up Acked-by Alex (modulo typo correction, hope you don't mind) [amdgpu, radeon] - Pick up Acked-by Thomas [smscufx, viafb] - Revert eDP change in drm/i915 [Jani, Rodrigo, Andi] v1->v2: - v1 link: https://lore.kernel.org/all/20240430173812.1423757-1-eahar...@linux.microsoft.com/ - Switch to specification verbiage master->controller, slave->target, drop usage of host/client [Thomas] - Pick up Reviewed-bys and Acked-bys from Rodrigo, Zhi, and Thomas [gma500, i915] - Fix up some straggler master/slave terms in amdgpu, cx25821, ivtv, cx23885 v0->v1: - v0 link: https://lore.kernel.org/all/20240329170038.3863998-1-eahar...@linux.microsoft.com/ - Drop drivers/infiniband patches [Leon, Dennis] - Switch to specification verbiage master->controller, slave->target, drop usage of client [Andi, Ville, Jani, Christian] - Add I3C specification version in commit messages [Andi] - Pick up Reviewed-bys from Martin and Simon [sfc] - Drop i2c/treewide patch to make this series independent from Wolfram's ([1]) [Wolfram] - Split away drm/nouveau patch to allow expansion into non-I2C non-inclusive terms Easwar Hariharan (6): drm/amdgpu, drm/radeon: Make I2C terminology more inclusive drm/gma500: Make I2C terminology more inclusive drm/i915: Make I2C terminology more inclusive sfc: falcon: Make I2C terminology more inclusive fbdev/smscufx: Make I2C terminology more inclusive fbdev/viafb: Make I2C terminology more inclusive .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 8 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 10 +++ drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 8 ++--- drivers/gpu/drm/amd/amdgpu/atombios_i2c.h | 2 +- drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++--- .../gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +- .../drm/amd/display/dc/bios/bios_parser2.c| 2 +- .../drm/amd/display/dc/core/dc_link_exports.c | 4 +-- drivers/gpu/drm/amd/display/dc/dc.h | 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c | 4 +-- .../display/include/grph_object_ctrl_defs.h | 2 +- drivers/gpu/drm/amd/include/atombios.h| 2 +- drivers/gpu/drm/amd/include/atomfirmware.h| 26 .../powerplay/hwmgr/vega20_processpptables.c | 4 +-- .../amd/pm/powerplay/inc/smu11_driver_if.h| 2 +- .../inc/pmfw_if/smu11_driver_if_arcturus.h| 2 +- .../inc/pmfw_if/smu11_driver_if_navi10.h | 2 +- .../pmfw_if/smu11_driver_if_sienna_cichlid.h | 2 +- .../inc/pmfw_if/smu13_driver_if_aldebaran.h | 2 +- .../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 2 +- .../inc/pmfw_if/smu13_driver_if_v13_0_7.h | 2 +- .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 4 +-- .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 8 ++--- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/intel_bios.c | 22 +++--- drivers/gpu/drm/gma500/intel_bios.h | 4 +-- drivers/gpu/drm/gma500/intel_gmbus.c | 2 +- drivers/gpu/drm/gma500/psb_drv.h | 2 +- drivers/gpu/drm/gma500/psb_intel_drv.h| 2 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 4 +-- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 26 drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 - drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +-- drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +- drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +-- drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +-- drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +-- drivers/gpu/drm/i915/display/intel_bios.c | 22 +++--- .../gpu/drm/i915/display/intel_display_core.h | 2 +- drivers/gpu/drm/i915/display/intel_dsi.h | 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--- drivers/gpu/drm/i915/display/intel_dvo.c | 14 - drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +-- drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +-- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +-- drivers/gpu/drm/i915/gvt/edid.c | 28 - drivers/gpu/drm/i915/gvt/edid.h | 4 +-- drivers/g
Re: [PATCH v2 1/2] drm/msm/gen_header: allow skipping the validation
On 5/8/2024 3:41 PM, Doug Anderson wrote: Hi, On Fri, May 3, 2024 at 11:15 AM Dmitry Baryshkov wrote: @@ -941,6 +948,7 @@ def main(): parser = argparse.ArgumentParser() parser.add_argument('--rnn', type=str, required=True) parser.add_argument('--xml', type=str, required=True) + parser.add_argument('--validate', action=argparse.BooleanOptionalAction) FWIW, the above (argparse.BooleanOptionalAction) appears to be a python 3.9 thing. My own build environment happens to have python3 default to python 3.8 and thus I get a build error related to this. I have no idea what the kernel usually assumes for a baseline, but others might get build errors too. I don't even see python listed in: https://docs.kernel.org/process/changes.html ...in any case, if it's easy to change this to not require python3.9 that would at least help for my build environment. :-P Yes, I had posted this y'day as I also ran into this https://patchwork.freedesktop.org/patch/593057/ -Doug
Re: [PATCH v3] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
On Wed, May 8, 2024 at 6:06 PM Mohamed Ahmed < mohamedahmedegypt2...@gmail.com> wrote: > Allows PTE kind and tile mode on BO create with VM_BIND, > and adds a GETPARAM to indicate this change. This is needed to support > modifiers in NVK and ensure correctness when dealing with the nouveau > GL driver. > > The userspace modifiers implementation this is for can be found here: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28843 > > Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") > Signed-off-by: Mohamed Ahmed > --- > drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 ++ > drivers/gpu/drm/nouveau/nouveau_bo.c| 45 +++-- > include/uapi/drm/nouveau_drm.h | 7 > 3 files changed, 30 insertions(+), 25 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c > b/drivers/gpu/drm/nouveau/nouveau_abi16.c > index 80f74ee0f..47e53e17b 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c > +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c > @@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS) > getparam->value = > (u64)ttm_resource_manager_usage(vram_mgr); > break; > } > + case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE: > + getparam->value = 1; > + break; > default: > NV_PRINTK(dbg, cli, "unknown parameter %lld\n", > getparam->param); > return -EINVAL; > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c > b/drivers/gpu/drm/nouveau/nouveau_bo.c > index db8cbf615..583c962ef 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c > @@ -241,28 +241,29 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, > int *align, u32 domain, > } > > nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG); > - if (!nouveau_cli_uvmm(cli) || internal) { > - /* for BO noVM allocs, don't assign kinds */ > - if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) { > - nvbo->kind = (tile_flags & 0xff00) >> 8; > - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { > - kfree(nvbo); > - return ERR_PTR(-EINVAL); > - } > > - nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind; > - } else if (cli->device.info.family >= > NV_DEVICE_INFO_V0_TESLA) { > - nvbo->kind = (tile_flags & 0x7f00) >> 8; > - nvbo->comp = (tile_flags & 0x0003) >> 16; > - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { > - kfree(nvbo); > - return ERR_PTR(-EINVAL); > - } > - } else { > - nvbo->zeta = (tile_flags & 0x0007); > + /* for BO allocs, don't assign kinds */ > I think this comment is stale. We're now assigning them in both cases. > + if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) { > + nvbo->kind = (tile_flags & 0xff00) >> 8; > + if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { > + kfree(nvbo); > + return ERR_PTR(-EINVAL); > + } > + > + nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind; > + } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) { > + nvbo->kind = (tile_flags & 0x7f00) >> 8; > + nvbo->comp = (tile_flags & 0x0003) >> 16; > + if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { > + kfree(nvbo); > + return ERR_PTR(-EINVAL); > } > - nvbo->mode = tile_mode; > + } else { > + nvbo->zeta = (tile_flags & 0x0007); > + } > + nvbo->mode = tile_mode; > > + if (!nouveau_cli_uvmm(cli) || internal) { > /* Determine the desirable target GPU page size for the > buffer. */ > for (i = 0; i < vmm->page_nr; i++) { > /* Because we cannot currently allow VMM maps to > fail > @@ -304,12 +305,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, > int *align, u32 domain, > } > nvbo->page = vmm->page[pi].shift; > } else { > - /* reject other tile flags when in VM mode. */ > - if (tile_mode) > - return ERR_PTR(-EINVAL); > - if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG) > - return ERR_PTR(-EINVAL); > - > /* Determine the desirable target GPU page size for the > buffer. */ > for (i = 0; i < vmm->page_nr; i++) { > /* Because we cannot currently allow VMM maps to > fail > diff --git a/include/uapi/drm/nouveau_drm.h > b/include/uapi
[PATCH v3] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
Allows PTE kind and tile mode on BO create with VM_BIND, and adds a GETPARAM to indicate this change. This is needed to support modifiers in NVK and ensure correctness when dealing with the nouveau GL driver. The userspace modifiers implementation this is for can be found here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28843 Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Signed-off-by: Mohamed Ahmed --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 ++ drivers/gpu/drm/nouveau/nouveau_bo.c| 45 +++-- include/uapi/drm/nouveau_drm.h | 7 3 files changed, 30 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c index 80f74ee0f..47e53e17b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c @@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS) getparam->value = (u64)ttm_resource_manager_usage(vram_mgr); break; } + case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE: + getparam->value = 1; + break; default: NV_PRINTK(dbg, cli, "unknown parameter %lld\n", getparam->param); return -EINVAL; diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index db8cbf615..583c962ef 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -241,28 +241,29 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 domain, } nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG); - if (!nouveau_cli_uvmm(cli) || internal) { - /* for BO noVM allocs, don't assign kinds */ - if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) { - nvbo->kind = (tile_flags & 0xff00) >> 8; - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { - kfree(nvbo); - return ERR_PTR(-EINVAL); - } - nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind; - } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) { - nvbo->kind = (tile_flags & 0x7f00) >> 8; - nvbo->comp = (tile_flags & 0x0003) >> 16; - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { - kfree(nvbo); - return ERR_PTR(-EINVAL); - } - } else { - nvbo->zeta = (tile_flags & 0x0007); + /* for BO allocs, don't assign kinds */ + if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) { + nvbo->kind = (tile_flags & 0xff00) >> 8; + if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { + kfree(nvbo); + return ERR_PTR(-EINVAL); + } + + nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind; + } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) { + nvbo->kind = (tile_flags & 0x7f00) >> 8; + nvbo->comp = (tile_flags & 0x0003) >> 16; + if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { + kfree(nvbo); + return ERR_PTR(-EINVAL); } - nvbo->mode = tile_mode; + } else { + nvbo->zeta = (tile_flags & 0x0007); + } + nvbo->mode = tile_mode; + if (!nouveau_cli_uvmm(cli) || internal) { /* Determine the desirable target GPU page size for the buffer. */ for (i = 0; i < vmm->page_nr; i++) { /* Because we cannot currently allow VMM maps to fail @@ -304,12 +305,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 domain, } nvbo->page = vmm->page[pi].shift; } else { - /* reject other tile flags when in VM mode. */ - if (tile_mode) - return ERR_PTR(-EINVAL); - if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG) - return ERR_PTR(-EINVAL); - /* Determine the desirable target GPU page size for the buffer. */ for (i = 0; i < vmm->page_nr; i++) { /* Because we cannot currently allow VMM maps to fail diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h index cd84227f1..5402f77ee 100644 --- a/include/uapi/drm/nouveau_drm.h +++ b/include/uapi/drm/nouveau_drm.h @@ -68,6 +68,13 @@ extern "C" { */ #define NOUVEAU_GETPARAM_VRAM_USED 19 +/* + * NOUVEAU_GETPARAM_HAS_VMA_TILEMODE + * + * Query whether tile mode and PTE kind are accepted with VM allocs or not. + */ +#define NOUVEAU_GETPARAM_HAS_VMA
[pull] amdgpu, amdkfd drm-fixes-6.9
Hi Dave, Sima, Fixes for 6.9. The following changes since commit dd5a440a31fae6e459c0d627162825505361: Linux 6.9-rc7 (2024-05-05 14:06:01 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.9-2024-05-08 for you to fetch changes up to 3d09248a06d285397e7b873415505d299202e1c6: drm/amdgpu: Fix comparison in amdgpu_res_cpu_visible (2024-05-08 18:47:52 -0400) amd-drm-fixes-6.9-2024-05-08: amdgpu: - DCN 3.5 fix - MST DSC fixes - S0i3 fix - S4 fix - Warning fix - HDP MMIO mapping fix - Fix a regression in visible vram handling amdkfd: - Spatial partition fix Agustin Gutierrez (2): drm/amd/display: Fix DSC-re-computing drm/amd/display: MST DSC check for older devices Alex Deucher (1): drm/amdkfd: don't allow mapping the MMIO HDP page with large pages Lijo Lazar (2): Revert "drm/amdkfd: Add partition id field to location_id" drm/amd/amdxcp: Fix warnings Mario Limonciello (1): dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11 users Michel Dänzer (1): drm/amdgpu: Fix comparison in amdgpu_res_cpu_visible Nicholas Kazlauskas (1): drm/amd/display: Fix idle optimization checks for multi-display and dual eDP Nicholas Susanto (1): drm/amd/display: Enable urgent latency adjustments for DCN35 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 2 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 7 +++-- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 5 ++-- drivers/gpu/drm/amd/amdxcp/amdgpu_xcp_drv.c| 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 16 +-- .../gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c | 4 +-- .../drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c| 33 ++ .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 2 +- 8 files changed, 52 insertions(+), 19 deletions(-)
Re: [PATCH v2 1/2] drm/msm/gen_header: allow skipping the validation
Hi, On Fri, May 3, 2024 at 11:15 AM Dmitry Baryshkov wrote: > > @@ -941,6 +948,7 @@ def main(): > parser = argparse.ArgumentParser() > parser.add_argument('--rnn', type=str, required=True) > parser.add_argument('--xml', type=str, required=True) > + parser.add_argument('--validate', > action=argparse.BooleanOptionalAction) FWIW, the above (argparse.BooleanOptionalAction) appears to be a python 3.9 thing. My own build environment happens to have python3 default to python 3.8 and thus I get a build error related to this. I have no idea what the kernel usually assumes for a baseline, but others might get build errors too. I don't even see python listed in: https://docs.kernel.org/process/changes.html ...in any case, if it's easy to change this to not require python3.9 that would at least help for my build environment. :-P -Doug
Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm
Quoting Jani Nikula (2024-05-08 01:43:56) > On Tue, 07 May 2024, Abhinav Kumar wrote: > > Since commit 5acf49119630 ("drm/msm: import gen_header.py script from > > Mesa"), > > compilation is broken on machines having python versions older than 3.9 > > due to dependency on argparse.BooleanOptionalAction. > > Is it now okay to require Python for the build? Not listed in > Documentation/process/changes.rst. > I doubt it is ok. Perl scripts have been replaced with shell scripts in the past to speed up the build process. See commit e0e2fa4b515c ("headers_install.pl: convert to headers_install.sh") as an example.
Don't forget, freedesktop.org offers free CoC training for inquiring projects
Hey everyone! This is just a general reminder that if you're interested in receiving professional Code of Conduct enforcement training for your project - freedesktop.org is happy to cover the costs for doing such training through the wonderful services of https://otter.technology/ . All that's needed is to send an email to the board, and we can handle setting up scheduling :). And of course as always, the Code of Conduct team is always looking for new volunteers. -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
On Wed, May 08, 2024 at 10:39:58AM +0200, Daniel Vetter wrote: > On Tue, May 07, 2024 at 10:59:42PM +0300, Dmitry Baryshkov wrote: > > On Tue, 7 May 2024 at 21:40, Laurent Pinchart wrote: > > > On Tue, May 07, 2024 at 06:19:18PM +0300, Dmitry Baryshkov wrote: > > > > On Tue, 7 May 2024 at 18:15, Bryan O'Donoghue wrote: > > > > > On 07/05/2024 16:09, Dmitry Baryshkov wrote: > > > > > > Ah, I see. Then why do you require the DMA-ble buffer at all? If > > > > > > you are > > > > > > providing data to VPU or DRM, then you should be able to get the > > > > > > buffer > > > > > > from the data-consuming device. > > > > > > > > > > Because we don't necessarily know what the consuming device is, if > > > > > any. > > > > > > > > > > Could be VPU, could be Zoom/Hangouts via pipewire, could for argument > > > > > sake be GPU or DSP. > > > > > > > > > > Also if we introduce a dependency on another device to allocate the > > > > > output buffers - say always taking the output buffer from the GPU, > > > > > then > > > > > we've added another dependency which is more difficult to guarantee > > > > > across different arches. > > > > > > > > Yes. And it should be expected. It's a consumer who knows the > > > > restrictions on the buffer. As I wrote, Zoom/Hangouts should not > > > > require a DMA buffer at all. > > > > > > Why not ? If you want to capture to a buffer that you then compose on > > > the screen without copying data, dma-buf is the way to go. That's the > > > Linux solution for buffer sharing. > > > > Yes. But it should be allocated by the DRM driver. As Sima wrote, > > there is no guarantee that the buffer allocated from dma-heaps is > > accessible to the GPU. > > > > > > > > > Applications should be able to allocate > > > > the buffer out of the generic memory. > > > > > > If applications really want to copy data and degrade performance, they > > > are free to shoot themselves in the foot of course. Applications (or > > > compositors) need to support copying as a fallback in the worst case, > > > but all components should at least aim for the zero-copy case. > > > > I'd say that they should aim for the optimal case. It might include > > both zero-copying access from another DMA master or simple software > > processing of some kind. > > > > > > GPUs might also have different > > > > requirements. Consider GPUs with VRAM. It might be beneficial to > > > > allocate a buffer out of VRAM rather than generic DMA mem. > > > > > > Absolutely. For that we need a centralized device memory allocator in > > > userspace. An effort was started by James Jones in 2016, see [1]. It has > > > unfortunately stalled. If I didn't have a camera framework to develop, I > > > would try to tackle that issue :-) > > > > I'll review the talk. However the fact that the effort has stalled > > most likely means that 'one fits them all' approach didn't really fly > > well. We have too many usecases. > > I think there's two reasons: > > - It's a really hard problem with many aspects. Where you need to allocate > the buffer is just one of the myriad of issues a common allocator needs > to solve. The other large problem is picking up an optimal pixel format. I wonder if that could be decoupled from the allocation. That could help moving forward. > - Every linux-based os has their own solution for these, and the one that > suffers most has an entirely different one from everyone else: Android > uses binder services to allow apps to make these allocations, keep track > of them and make sure there's no abuse. And if there is, it can just > nuke the app. -- Regards, Laurent Pinchart
Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
On Thu, May 09, 2024 at 12:51:08AM +0300, Laurent Pinchart wrote: > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote: > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote: > > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit : > > > > Shorter term, we have a problem to solve, and the best option we have > > > > found so far is to rely on dma-buf heaps as a backend for the frame > > > > buffer allocatro helper in libcamera for the use case described above. > > > > This won't work in 100% of the cases, clearly. It's a stop-gap measure > > > > until we can do better. > > > > > > Considering the security concerned raised on this thread with dmabuf heap > > > allocation not be restricted by quotas, you'd get what you want quickly > > > with > > > memfd + udmabuf instead (which is accounted already). > > > > > > It was raised that distro don't enable udmabuf, but as stated there by > > > Hans, in > > > any cases distro needs to take action to make the softISP works. This > > > alternative is easy and does not interfere in anyway with your future > > > plan or > > > the libcamera API. You could even have both dmabuf heap (for Raspbian) > > > and the > > > safer memfd+udmabuf for the distro with security concerns. > > > > > > And for the long term plan, we can certainly get closer by fixing that > > > issue > > > with accounting. This issue also applied to v4l2 io-ops, so it would be > > > nice to > > > find common set of helpers to fix these exporters. > > > > Yeah if this is just for softisp, then memfd + udmabuf is also what I was > > about to suggest. Not just as a stopgap, but as the real official thing. > > Long term I still want a centralized memory allocator, at which point > libcamera should stop allocating buffers at all. And to be clear, udmabuf could be fine for the time being. At least as long as we don't find any shortcoming while testing it :-) > > udmabuf does kinda allow you to pin memory, but we can easily fix that by > > adding the right accounting and then either let mlock rlimits or cgroups > > kernel memory limits enforce good behavior. -- Regards, Laurent Pinchart
Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote: > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote: > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit : > > > Shorter term, we have a problem to solve, and the best option we have > > > found so far is to rely on dma-buf heaps as a backend for the frame > > > buffer allocatro helper in libcamera for the use case described above. > > > This won't work in 100% of the cases, clearly. It's a stop-gap measure > > > until we can do better. > > > > Considering the security concerned raised on this thread with dmabuf heap > > allocation not be restricted by quotas, you'd get what you want quickly with > > memfd + udmabuf instead (which is accounted already). > > > > It was raised that distro don't enable udmabuf, but as stated there by > > Hans, in > > any cases distro needs to take action to make the softISP works. This > > alternative is easy and does not interfere in anyway with your future plan > > or > > the libcamera API. You could even have both dmabuf heap (for Raspbian) and > > the > > safer memfd+udmabuf for the distro with security concerns. > > > > And for the long term plan, we can certainly get closer by fixing that issue > > with accounting. This issue also applied to v4l2 io-ops, so it would be > > nice to > > find common set of helpers to fix these exporters. > > Yeah if this is just for softisp, then memfd + udmabuf is also what I was > about to suggest. Not just as a stopgap, but as the real official thing. Long term I still want a centralized memory allocator, at which point libcamera should stop allocating buffers at all. > udmabuf does kinda allow you to pin memory, but we can easily fix that by > adding the right accounting and then either let mlock rlimits or cgroups > kernel memory limits enforce good behavior. -- Regards, Laurent Pinchart
[PATCH v2] drm/amd/display: Enable colorspace property for MST connectors
MST colorspace property support was disabled due to a series of warnings that came up when the device was plugged in since the properties weren't made at device creation. Create the properties in advance instead. Suggested-by: Ville Syrjälä Fixes: 69a959610229 ("drm/amd/display: Temporary Disable MST DP Colorspace Property"). Reported-and-tested-by: Tyler Schneider Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353 Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index 941e96f100f4..12b036d511d0 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -613,6 +613,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr, &connector->base, dev->mode_config.tile_property, 0); + connector->colorspace_property = master->base.colorspace_property; + if (connector->colorspace_property) + drm_connector_attach_colorspace_property(connector); drm_connector_set_path_property(connector, pathprop); -- 2.43.0
Re: [RFT PATCH v2 00/48] drm/panel: Remove most store/double-check of prepared/enabled state
Hi, On Sun, May 5, 2024 at 11:52 PM Linus Walleij wrote: > > On Fri, May 3, 2024 at 11:36 PM Douglas Anderson > wrote: > > > As talked about in commit d2aacaf07395 ("drm/panel: Check for already > > prepared/enabled in drm_panel"), we want to remove needless code from > > panel drivers that was storing and double-checking the > > prepared/enabled state. Even if someone was relying on the > > double-check before, that double-check is now in the core and not > > needed in individual drivers. > > > > This series attempts to do just that. While the original grep, AKA: > > git grep 'if.*>prepared' -- drivers/gpu/drm/panel > > git grep 'if.*>enabled' -- drivers/gpu/drm/panel > > ...still produces a few hits after my series, they are _mostly_ all > > gone. The ones that are left are less trivial to fix. > > > > One of the main reasons that many panels probably needed to store and > > double-check their prepared/enabled appears to have been to handle > > shutdown and/or remove. Panels drivers often wanted to force the power > > off for panels in these cases and this was a good reason for the > > double-check. > > > > In response to my V1 series [1] we had much discussion of what to > > do. The conclusion was that as long as DRM modeset drivers properly > > called drm_atomic_helper_shutdown() that we should be able to remove > > the explicit shutdown/remove handling in the panel drivers. Most of > > the patches to improve DRM modeset drivers [2] [3] [4] have now > > landed. > > > > In contrast to my V1 series, I broke the V2 series up a lot > > more. Since a few of the panel drivers in V1 already landed, we had > > fewer total drivers and so we could devote a patch to each panel. > > Also, since we were now relying on DRM modeset drivers I felt like we > > should split the patches for each panel into two: one that's > > definitely safe and one that could be reverted if we found a > > problematic DRM modeset driver that we couldn't fix. > > > > Sorry for the large number of patches. I've set things to mostly just > > CC people on the cover letter and the patches that are relevant to > > them. I've tried to CC people on the whole series that have shown > > interest in this TODO item. > > > > As patches in this series are reviewed and/or tested they could be > > landed. There's really no ordering requirement for the series unless > > patches touch the same driver. > > > > NOTE: this touches _a lot_ of drivers, is repetitive, and is not > > really possible to generate automatically. That means it's entirely > > possible that my eyes glazed over and I did something wrong. Please > > double-check me and don't assume that I got everything perfect, though > > I did my best. I have at least confirmed that "allmodconfig" for arm64 > > doesn't fall on its face with this series. I haven't done a ton of > > other testing. > > > > [1] > > https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid > > [2] https://lore.kernel.org/r/20230901234015.566018-1-diand...@chromium.org > > [3] https://lore.kernel.org/r/20230901234202.566951-1-diand...@chromium.org > > [4] https://lore.kernel.org/r/20230921192749.1542462-1-diand...@chromium.org > > This is the right thing to do, thanks for looking into this! > > As for the behaviour of .remove() I doubt whether in many cases > the original driver authors have even tested this themselves. Yeah, I'd tend to agree. > I would say we should just apply the series as soon as it's non-RFC It's not actually RFC now, but "RFT" (request for testing). I don't _think_ there's any need to send a version without the RFT tag before landing unless someone really feels strongly about it. > after the next merge window With drm-misc there's not really any specific reason to wait for the merge window to open/close as we can land in drm-misc-next at any time regardless of the merge window. drm-misc-next will simply stop feeding linuxnext for a while. That all being said, I'm happy to delay landing this until after the next -rc1 comes out if people would prefer that. If I don't hear anything, I guess I'll just wait until -rc1 before landing any of these. > and see what happens. I doubt it > will cause much trouble. I can land the whole series if that's what everyone agrees on. As I mentioned above, I'm at least slightly worried that I did something stupid _somewhere_ in this series since no automation was possible and with repetitive tasks like this it's super easy to flub something up. It's _probably_ fine, but I guess I still have the worry in the back of my mind. If folks think I should just apply the whole series then I'm happy to do that. If folks think I should just land parts of the series as they are reviewed/tested I can do that as well. Let me know. If I don't hear anything I'd tend to just land patches that are reviewed/tested. Then after a month or so (hopefully) I'd send out a v2 with anything left. > The series: > Acked-by: Linus Walleij
Re: [PATCH v2 01/12] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive
On Wed, May 8, 2024 at 4:12 PM Easwar Hariharan wrote: > > On 5/8/2024 7:53 AM, Alex Deucher wrote: > > On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan > > wrote: > >> > >> On 5/3/2024 11:13 AM, Easwar Hariharan wrote: > >>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced > >>> "master/slave" > >>> with more appropriate terms. Inspired by and following on to Wolfram's > >>> series to fix drivers/i2c/[1], fix the terminology for users of > >>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > >>> in the specification. > >>> > >>> Compile tested, no functionality changes intended > >>> > >>> [1]: > >>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ > >>> > >>> Signed-off-by: Easwar Hariharan > >>> --- > >>> .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 8 +++--- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 10 +++ > >>> drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 8 +++--- > >>> drivers/gpu/drm/amd/amdgpu/atombios_i2c.h | 2 +- > >>> drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++--- > >>> .../gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +- > >>> .../drm/amd/display/dc/bios/bios_parser2.c| 2 +- > >>> .../drm/amd/display/dc/core/dc_link_exports.c | 4 +-- > >>> drivers/gpu/drm/amd/display/dc/dc.h | 2 +- > >>> drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c | 4 +-- > >>> .../display/include/grph_object_ctrl_defs.h | 2 +- > >>> drivers/gpu/drm/amd/include/atombios.h| 2 +- > >>> drivers/gpu/drm/amd/include/atomfirmware.h| 26 - > >>> .../powerplay/hwmgr/vega20_processpptables.c | 4 +-- > >>> .../amd/pm/powerplay/inc/smu11_driver_if.h| 2 +- > >>> .../inc/pmfw_if/smu11_driver_if_arcturus.h| 2 +- > >>> .../inc/pmfw_if/smu11_driver_if_navi10.h | 2 +- > >>> .../pmfw_if/smu11_driver_if_sienna_cichlid.h | 2 +- > >>> .../inc/pmfw_if/smu13_driver_if_aldebaran.h | 2 +- > >>> .../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 2 +- > >>> .../inc/pmfw_if/smu13_driver_if_v13_0_7.h | 2 +- > >>> .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 4 +-- > >>> .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 8 +++--- > >>> drivers/gpu/drm/radeon/atombios.h | 16 +-- > >>> drivers/gpu/drm/radeon/atombios_i2c.c | 4 +-- > >>> drivers/gpu/drm/radeon/radeon_combios.c | 28 +-- > >>> drivers/gpu/drm/radeon/radeon_i2c.c | 10 +++ > >>> drivers/gpu/drm/radeon/radeon_mode.h | 6 ++-- > >>> 28 files changed, 93 insertions(+), 93 deletions(-) > >>> > >> > >> > >> > >> Hello Christian, Daniel, David, others, > >> > >> Could you re-review v2 since the feedback provided in v0 [1] has now been > >> addressed? I can send v3 with > >> all other feedback and signoffs from the other maintainers incorporated > >> when I have something for amdgpu > >> and radeon. > > > > This seems like a lot of churn. Additionally, a bunch of these > > headers are shared with other OSes, so it's possible some of the > > changes may end up getting reverted accidently when we sync up or we > > may add new headers in new code with the old nomenclature and then > > we'd need to make sure to adjust it to make sure everything was > > aligned again. I would just as soon leave things as is, but I'm open > > to acking them if there is a strong desire to update things. > > > > Alex > > The way I see it, this is a small downpayment on the debt we have built up so > far. Internship > programs like LF Outreachy to get more underrepresented groups involved in > open source are trying to > change the open source community culture to be more inclusive, but > simultaneously rely on the culture > being welcoming enough as well. > > I do see the challenge involved in preserving the changes and ensuring no new > code is added with > outdated nomenclature (but see [1]), but culture changes one person at a > time, and I'd encourage the community > to do the work needed so we can move past our (mostly) inadvertent role in > perpetuating it. > > That's my 2c (or your sub-unit currency of choice). Fair enough. Acked-by: Aex Deucher > > Easwar > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb
Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate
On Wed, May 8, 2024, at 22:36, Sam Ravnborg wrote: >> >> I think if you want to do a new version, that is likely to run >> into new problems, given that this part of fbdev is particularly >> fragile and partly wrong. On the other hand, it would be nice to >> have a patch to limit the use of the notifiers to the smallest >> set of kernel configs that actually need it, and leave it turned >> off for everything else. >> >> These are the ones I could find: >> >> - CONFIG_GUMSTIX_AM200EPD (FB_EVENT_FB_REGISTERED) > > I was surprised to see this driver is still around as many other old > drivers was nuked as part of the pxa cleanup. > It is the only user of FB_EVENT_FB_REGISTERED - so a potential cleanup > if the driver is no longer relevant. We kept gumstix at the time to give a chance to do a DT conversion using the qemu model, but so far nobody has worked on this. My feeling is that we'll end up removing it at some point in the future along with the other legacy PXA board files. Even if someone wants to keep working on gumstix DT support for qemu, I agree that we can probably remove AM200EPD, AM300EPD and metronomefb, since those are not even modeled by qemu. Arnd
Re: [PATCH v2 6/6] drm/xe/client: Print runtime to fdinfo
On Wed, May 08, 2024 at 09:23:17AM GMT, Tvrtko Ursulin wrote: On 07/05/2024 22:35, Lucas De Marchi wrote: On Fri, Apr 26, 2024 at 11:47:37AM GMT, Tvrtko Ursulin wrote: On 24/04/2024 00:56, Lucas De Marchi wrote: Print the accumulated runtime for client when printing fdinfo. Each time a query is done it first does 2 things: 1) loop through all the exec queues for the current client and accumulate the runtime, per engine class. CTX_TIMESTAMP is used for that, being read from the context image. 2) Read a "GPU timestamp" that can be used for considering "how much GPU time has passed" and that has the same unit/refclock as the one recording the runtime. RING_TIMESTAMP is used for that via MMIO. Since for all current platforms RING_TIMESTAMP follows the same refclock, just read it once, using any first engine. This is exported to userspace as 2 numbers in fdinfo: drm-cycles-: drm-total-cycles-: Userspace is expected to collect at least 2 samples, which allows to know the client engine busyness as per: RUNTIME1 - RUNTIME0 busyness = - T1 - T0 Another thing to point out is that it's expected that userspace will read any 2 samples every few seconds. Given the update frequency of the counters involved and that CTX_TIMESTAMP is 32-bits, the counter for each exec_queue can wrap around (assuming 100% utilization) after ~200s. The wraparound is not perceived by userspace since it's just accumulated for all the exec_queues in a 64-bit counter), but the measurement will not be accurate if the samples are too far apart. This could be mitigated by adding a workqueue to accumulate the counters every so often, but it's additional complexity for something that is done already by userspace every few seconds in tools like gputop (from igt), htop, nvtop, etc with none of them really defaulting to 1 sample per minute or more. Signed-off-by: Lucas De Marchi --- Documentation/gpu/drm-usage-stats.rst | 16 ++- Documentation/gpu/xe/index.rst | 1 + Documentation/gpu/xe/xe-drm-usage-stats.rst | 10 ++ drivers/gpu/drm/xe/xe_drm_client.c | 138 +++- 4 files changed, 162 insertions(+), 3 deletions(-) create mode 100644 Documentation/gpu/xe/xe-drm-usage-stats.rst diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 6dc299343b48..421766289b78 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -112,6 +112,17 @@ larger value within a reasonable period. Upon observing a value lower than what was previously read, userspace is expected to stay with that larger previous value until a monotonic update is seen. +- drm-total-cycles-: + +Engine identifier string must be the same as the one specified in the +drm-cycles- tag and shall contain the total number cycles for the given +engine. + +This is a timestamp in GPU unspecified unit that matches the update rate +of drm-cycles-. For drivers that implement this interface, the engine +utilization can be calculated entirely on the GPU clock domain, without +considering the CPU sleep time between 2 samples. Two opens. 1) Do we need to explicity document that drm-total-cycles and drm-maxfreq are mutually exclusive? so userspace has a fallback mechanism to calculate utilization depending on what keys are available? No, to document all three at once do not make sense. Or at least are not expected. Or you envisage someone might legitimately emit all three? I don't see what would be the semantics. When we have cycles+maxfreq the latter is in Hz. And when we have cycles+total then it is unitless. All three? I don't follow what you mean here. *cycles* is actually a unit. The engine spent 10 cycles running this context (drm-cycles). In the same period there were 100 cycles available (drm-total-cycles). Current frequency is X MHz. Max frequency is Y MHz. For me all of them make sense if one wants to mix them together. For xe it doesn't make sense because the counter backing drm-cycles and drm-total-cycles is unrelated to the engine frequency. I can add something in the doc that we do not expected to see all of them together until we see a usecase. Each driver may implement a subset. 2) Should drm-total-cycles for now be documents as driver specific? you mean to call it xe-total-cycles? Yes but it is not an ask, just an open. Ok, my opinion is that we shouldn't. Just like we have drm-cycles today implemented by some drivers, but not all. I'd consider the drm-curfreq, not documented in the drm layer as something to be fixed or migrated to a driver-only interface (probably not possible anymore as it'd break the uapi). Problem I see with turning it into xe-total-cycles, is that the moment another driver decide to implement they will either have to use xe- prefix or xe will need to start publishing both keys. As said above, I can document that it's no
[PATCH v4 8/9] drm/panel: ili9882t: Don't use a table for initting panels
Consensus on the mailing lists is that panels shouldn't use a table of init commands but should instead use init functions. With the recently introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy but also saves space. Measuring before/after this change: $ scripts/bloat-o-meter \ .../before/panel-ilitek-ili9882t.ko \ .../after/panel-ilitek-ili9882t.ko add/remove: 3/2 grow/shrink: 0/2 up/down: 6834/-8177 (-1343) Function old new delta starry_ili9882t_init -6152 +6152 starry_ili9882t_init.d - 678+678 ili9882t_disable.d - 4 +4 ili9882t_disable 260 228 -32 ili9882t_prepare 540 396-144 .compoundliteral 681 --681 starry_ili9882t_init_cmd7320 - -7320 Total: Before=11928, After=10585, chg -11.26% Let's do the conversion. Since we're touching all the tables, let's also convert hex numbers to lower case as per kernel conventions. Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson --- (no changes since v3) Changes in v3: - New drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 794 -- 1 file changed, 368 insertions(+), 426 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c index 267a5307041c..58fc1d799371 100644 --- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c @@ -15,6 +15,8 @@ #include +struct ili9882t; + /* * Use this descriptor struct to describe different panels using the * Ilitek ILI9882T display controller. @@ -34,7 +36,7 @@ struct panel_desc { unsigned long mode_flags; enum mipi_dsi_pixel_format format; - const struct panel_init_cmd *init_cmds; + int (*init)(struct ili9882t *boe); unsigned int lanes; }; @@ -52,433 +54,372 @@ struct ili9882t { struct gpio_desc *enable_gpio; }; -enum dsi_cmd_type { - INIT_DCS_CMD, - DELAY_CMD, -}; - -struct panel_init_cmd { - enum dsi_cmd_type type; - size_t len; - const char *data; -}; - -#define _INIT_DCS_CMD(...) { \ - .type = INIT_DCS_CMD, \ - .len = sizeof((char[]){__VA_ARGS__}), \ - .data = (char[]){__VA_ARGS__} } - -#define _INIT_DELAY_CMD(...) { \ - .type = DELAY_CMD,\ - .len = sizeof((char[]){__VA_ARGS__}), \ - .data = (char[]){__VA_ARGS__} } - /* ILI9882-specific commands, add new commands as you decode them */ #define ILI9882T_DCS_SWITCH_PAGE 0xFF -#define _INIT_SWITCH_PAGE_CMD(page) \ - _INIT_DCS_CMD(ILI9882T_DCS_SWITCH_PAGE, 0x98, 0x82, (page)) - -static const struct panel_init_cmd starry_ili9882t_init_cmd[] = { - _INIT_DELAY_CMD(5), - _INIT_SWITCH_PAGE_CMD(0x01), - _INIT_DCS_CMD(0x00, 0x42), - _INIT_DCS_CMD(0x01, 0x11), - _INIT_DCS_CMD(0x02, 0x00), - _INIT_DCS_CMD(0x03, 0x00), - - _INIT_DCS_CMD(0x04, 0x01), - _INIT_DCS_CMD(0x05, 0x11), - _INIT_DCS_CMD(0x06, 0x00), - _INIT_DCS_CMD(0x07, 0x00), - - _INIT_DCS_CMD(0x08, 0x80), - _INIT_DCS_CMD(0x09, 0x81), - _INIT_DCS_CMD(0x0A, 0x71), - _INIT_DCS_CMD(0x0B, 0x00), - - _INIT_DCS_CMD(0x0C, 0x00), - _INIT_DCS_CMD(0x0E, 0x1A), - - _INIT_DCS_CMD(0x24, 0x00), - _INIT_DCS_CMD(0x25, 0x00), - _INIT_DCS_CMD(0x26, 0x00), - _INIT_DCS_CMD(0x27, 0x00), - - _INIT_DCS_CMD(0x2C, 0xD4), - _INIT_DCS_CMD(0xB9, 0x40), - - _INIT_DCS_CMD(0xB0, 0x11), - - _INIT_DCS_CMD(0xE6, 0x32), - _INIT_DCS_CMD(0xD1, 0x30), - - _INIT_DCS_CMD(0xD6, 0x55), - - _INIT_DCS_CMD(0xD0, 0x01), - _INIT_DCS_CMD(0xE3, 0x93), - _INIT_DCS_CMD(0xE4, 0x00), - _INIT_DCS_CMD(0xE5, 0x80), - - _INIT_DCS_CMD(0x31, 0x07), - _INIT_DCS_CMD(0x32, 0x07), - _INIT_DCS_CMD(0x33, 0x07), - _INIT_DCS_CMD(0x34, 0x07), - _INIT_DCS_CMD(0x35, 0x07), - _INIT_DCS_CMD(0x36, 0x01), - _INIT_DCS_CMD(0x37, 0x00), - _INIT_DCS_CMD(0x38, 0x28), - _INIT_DCS_CMD(0x39, 0x29), - _INIT_DCS_CMD(0x3A, 0x11), - _INIT_DCS_CMD(0x3B, 0x13), - _INIT_DCS_CMD(0x3C, 0x15), - _INIT_DCS_CMD(0x3D, 0x17), - _INIT_DCS_CMD(0x3E, 0x09), - _INIT_DCS_CMD(0x3F, 0x0D), - _INIT_DCS_CMD(0x40, 0x02), - _INIT_DCS_CMD(0x41, 0x02), - _INIT_DCS_CMD(0x42, 0x02), - _INIT_DCS_CMD(0x43, 0x02), - _INIT_DCS_CMD(0x44, 0x02), - _INIT_DCS_CMD(0x45, 0x02), - _INIT_DCS_CMD(0x46, 0x02), - - _INIT_DCS_CMD(0x47, 0x07), - _INIT_DCS_CMD(0x48, 0x07), - _INIT_DCS_CMD(0x49, 0x07), - _INIT_DCS_CMD(0x4A, 0x07), - _INIT_DCS_CMD(0x4B, 0x07), - _INIT_DCS_CMD(0x4C, 0x01), - _INIT_DCS_CMD(0x4D, 0x00), - _INIT_DCS_CM
[PATCH v4 9/9] drm/panel: innolux-p079zca: Don't use a table for initting panels
Consensus on the mailing lists is that panels shouldn't use a table of init commands but should instead use init functions. We'll use the same concepts as the recently introduced mipi_dsi_generic_write_seq_multi() to make this clean/easy and also not bloat the driver too much. Measuring before/after this change: $ scripts/bloat-o-meter \ .../before/panel-innolux-p079zca.ko \ .../after/panel-innolux-p079zca.ko add/remove: 3/2 grow/shrink: 0/1 up/down: 2356/-1944 (412) Function old new delta innolux_p097pfg_init -1772 +1772 innolux_p097pfg_init.d - 480+480 innolux_panel_write_multi - 104+104 innolux_panel_prepare412 308-104 .compoundliteral 480 --480 innolux_p097pfg_init_cmds 1360 - -1360 Total: Before=5802, After=6214, chg +7.10% Note that, unlike some other drivers, we actually make this panel driver _bigger_ by using the new functions. This is because the innolux-p079zca panel driver didn't have as complex of a table and thus the old table was more efficient than the code. The bloat is still not giant (only 412 bytes). Also note that we can't direclty use mipi_dsi_generic_write_seq_multi() here because we need to deal with the crazy "nop" that this driver sends after all commands. This means that we have to write code that is "inspired" by the new macros. Since we're touching all the tables, let's also convert hex numbers to lower case as per kernel conventions. Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson --- Changes in v4: - Test to see if init is non-NULL before using it. Changes in v3: - New drivers/gpu/drm/panel/panel-innolux-p079zca.c | 284 +- 1 file changed, 140 insertions(+), 144 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c b/drivers/gpu/drm/panel/panel-innolux-p079zca.c index 485178a99910..ade8bf7491ee 100644 --- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c +++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c @@ -17,14 +17,7 @@ #include #include -struct panel_init_cmd { - size_t len; - const char *data; -}; - -#define _INIT_CMD(...) { \ - .len = sizeof((char[]){__VA_ARGS__}), \ - .data = (char[]){__VA_ARGS__} } +struct innolux_panel; struct panel_desc { const struct drm_display_mode *mode; @@ -36,7 +29,7 @@ struct panel_desc { unsigned long flags; enum mipi_dsi_pixel_format format; - const struct panel_init_cmd *init_cmds; + int (*init)(struct innolux_panel *innolux); unsigned int lanes; const char * const *supply_names; unsigned int num_supplies; @@ -132,32 +125,10 @@ static int innolux_panel_prepare(struct drm_panel *panel) /* p079zca: t4, p097pfg: t5 */ usleep_range(2, 21000); - if (innolux->desc->init_cmds) { - const struct panel_init_cmd *cmds = - innolux->desc->init_cmds; - unsigned int i; - - for (i = 0; cmds[i].len != 0; i++) { - const struct panel_init_cmd *cmd = &cmds[i]; - - err = mipi_dsi_generic_write(innolux->link, cmd->data, -cmd->len); - if (err < 0) { - dev_err(panel->dev, "failed to write command %u\n", i); - goto poweroff; - } - - /* -* Included by random guessing, because without this -* (or at least, some delay), the panel sometimes -* didn't appear to pick up the command sequence. -*/ - err = mipi_dsi_dcs_nop(innolux->link); - if (err < 0) { - dev_err(panel->dev, "failed to send DCS nop: %d\n", err); - goto poweroff; - } - } + if (innolux->desc->init) { + err = innolux->desc->init(innolux); + if (err < 0) + goto poweroff; } err = mipi_dsi_dcs_exit_sleep_mode(innolux->link); @@ -250,119 +221,144 @@ static const struct drm_display_mode innolux_p097pfg_mode = { .vtotal = 2048 + 100 + 2 + 18, }; +static void innolux_panel_write_multi(struct mipi_dsi_multi_context *ctx, + const void *payload, size_t size) +{ + struct mipi_dsi_device *dsi = ctx->dsi; + struct device *dev = &dsi->dev; + + mipi_dsi_generic_write_multi(ctx, payload, size); + if (ctx->accum_err) + return; + + /* +* Included by random guessing, because without this +* (or at least, some d
[PATCH v4 7/9] drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels
Consensus on the mailing lists is that panels shouldn't use a table of init commands but should instead use init functions. With the recently introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy but also saves space. Measuring before/after this change: $ scripts/bloat-o-meter \ .../before/panel-boe-tv101wum-nl6.ko \ .../after/panel-boe-tv101wum-nl6.ko add/remove: 14/8 grow/shrink: 0/1 up/down: 27062/-31433 (-4371) Function old new delta inx_hj110iz_init -7040 +7040 boe_tv110c9m_init -6440 +6440 boe_init -5916 +5916 starry_qfh032011_53g_init -1944 +1944 starry_himax83102_j02_init -1228 +1228 inx_hj110iz_init.d -1040 +1040 boe_tv110c9m_init.d- 982+982 auo_b101uan08_3_init - 944+944 boe_init.d - 580+580 starry_himax83102_j02_init.d - 512+512 starry_qfh032011_53g_init.d- 180+180 auo_kd101n80_45na_init - 172+172 auo_b101uan08_3_init.d - 82 +82 auo_kd101n80_45na_init.d - 2 +2 auo_kd101n80_45na_init_cmd 144 --144 boe_panel_prepare592 440-152 auo_b101uan08_3_init_cmd1056 - -1056 starry_himax83102_j02_init_cmd 1392 - -1392 starry_qfh032011_53g_init_cmd 2256 - -2256 .compoundliteral3393 - -3393 boe_init_cmd7008 - -7008 boe_tv110c9m_init_cmd 7656 - -7656 inx_hj110iz_init_cmd8376 - -8376 Total: Before=37297, After=32926, chg -11.72% Let's do the conversion. Since we're touching all the tables, let's also convert hex numbers to lower case as per kernel conventions. Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson --- (no changes since v3) Changes in v3: - Fix spacing of init function. - Remove an unneeded error print. - Squash boe-tv101wum-nl6 lowercase patch into main patch Changes in v2: - New .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 2792 + 1 file changed, 1442 insertions(+), 1350 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c index 0ffe8f8c01de..aab60cec0603 100644 --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c @@ -17,6 +17,8 @@ #include +struct boe_panel; + struct panel_desc { const struct drm_display_mode *modes; unsigned int bpc; @@ -32,7 +34,7 @@ struct panel_desc { unsigned long mode_flags; enum mipi_dsi_pixel_format format; - const struct panel_init_cmd *init_cmds; + int (*init)(struct boe_panel *boe); unsigned int lanes; bool discharge_on_disable; bool lp11_before_reset; @@ -54,1318 +56,1449 @@ struct boe_panel { bool prepared; }; -enum dsi_cmd_type { - INIT_DCS_CMD, - DELAY_CMD, -}; +static int boe_tv110c9m_init(struct boe_panel *boe) +{ + struct mipi_dsi_multi_context ctx = { .dsi = boe->dsi }; + + mipi_dsi_dcs_write_seq_multi(&ctx, 0xff, 0x20); + mipi_dsi_dcs_write_seq_multi(&ctx, 0xfb, 0x01); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x05, 0xd9); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x07, 0x78); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x08, 0x5a); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x0d, 0x63); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x0e, 0x91); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x0f, 0x73); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x95, 0xe6); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x96, 0xf0); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x30, 0x00); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x6d, 0x66); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x75, 0xa2); + mipi_dsi_dcs_write_seq_multi(&ctx, 0x77, 0x3b); + + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb0, 0x00, 0x08, 0x00, 0x23, 0x00, 0x4d, 0x00, 0x6d, +0x00, 0x89, 0x00, 0xa1, 0x00, 0xb6, 0x00, 0xc9); + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb1, 0x00, 0xda, 0x01, 0x13, 0x01, 0x3c, 0x01, 0x7e, +0x01, 0xab, 0x01, 0xf7, 0x02, 0x2f, 0x02, 0x31); + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb2, 0x02, 0x67, 0x02, 0xa6, 0x02, 0xd1, 0x03, 0x08, +0x03, 0x2e, 0x03, 0x5b, 0x03, 0x6b, 0x03, 0x7b); + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb3, 0x03, 0x8e, 0x03, 0xa2, 0x03, 0xb7, 0x03, 0xe7, +
[PATCH v4 6/9] drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
This is a mechanical conversion of the novatek-nt36672e driver to use the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for clients to understand and using it also causes smaller code to be generated. Specifically: $ scripts/bloat-o-meter \ ...after/panel-novatek-nt36672e.ko \ ...ctx/panel-novatek-nt36672e.ko add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988) Function old new delta nt36672e_1080x2408_60hz_init62365248-988 Total: Before=10651, After=9663, chg -9.28% Cc: Ritesh Kumar Signed-off-by: Douglas Anderson --- This change is only compile tested. I don't use this panel myself but arbitrarily picked it as an example to look at when working on the MIPI DSI macros. NOTE: as of the posting of v4 this change still has no tags. Without any tags (Reviewed-by/Tested-by/Acked-by) I won't actually land this change even if the rest of the series lands. (no changes since v3) Changes in v3: - Fix spacing of init function. Changes in v2: - New .../gpu/drm/panel/panel-novatek-nt36672e.c| 576 +- 1 file changed, 289 insertions(+), 287 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c index 20b7bfe4aa12..9ce8df455232 100644 --- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c +++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c @@ -51,293 +51,295 @@ static inline struct nt36672e_panel *to_nt36672e_panel(struct drm_panel *panel) static int nt36672e_1080x2408_60hz_init(struct mipi_dsi_device *dsi) { - mipi_dsi_dcs_write_seq(dsi, 0xff, 0x10); - mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01); - mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00); - mipi_dsi_dcs_write_seq(dsi, 0xc0, 0x00); - mipi_dsi_dcs_write_seq(dsi, 0xc1, 0x89, 0x28, 0x00, 0x08, 0x00, 0xaa, 0x02, - 0x0e, 0x00, 0x2b, 0x00, 0x07, 0x0d, 0xb7, 0x0c, 0xb7); - - mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x1b, 0xa0); - mipi_dsi_dcs_write_seq(dsi, 0xff, 0x20); - mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01); - mipi_dsi_dcs_write_seq(dsi, 0x01, 0x66); - mipi_dsi_dcs_write_seq(dsi, 0x06, 0x40); - mipi_dsi_dcs_write_seq(dsi, 0x07, 0x38); - mipi_dsi_dcs_write_seq(dsi, 0x2f, 0x83); - mipi_dsi_dcs_write_seq(dsi, 0x69, 0x91); - mipi_dsi_dcs_write_seq(dsi, 0x95, 0xd1); - mipi_dsi_dcs_write_seq(dsi, 0x96, 0xd1); - mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x64); - mipi_dsi_dcs_write_seq(dsi, 0xf3, 0x54); - mipi_dsi_dcs_write_seq(dsi, 0xf4, 0x64); - mipi_dsi_dcs_write_seq(dsi, 0xf5, 0x54); - mipi_dsi_dcs_write_seq(dsi, 0xf6, 0x64); - mipi_dsi_dcs_write_seq(dsi, 0xf7, 0x54); - mipi_dsi_dcs_write_seq(dsi, 0xf8, 0x64); - mipi_dsi_dcs_write_seq(dsi, 0xf9, 0x54); - mipi_dsi_dcs_write_seq(dsi, 0xff, 0x24); - mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01); - mipi_dsi_dcs_write_seq(dsi, 0x01, 0x0f); - mipi_dsi_dcs_write_seq(dsi, 0x03, 0x0c); - mipi_dsi_dcs_write_seq(dsi, 0x05, 0x1d); - mipi_dsi_dcs_write_seq(dsi, 0x08, 0x2f); - mipi_dsi_dcs_write_seq(dsi, 0x09, 0x2e); - mipi_dsi_dcs_write_seq(dsi, 0x0a, 0x2d); - mipi_dsi_dcs_write_seq(dsi, 0x0b, 0x2c); - mipi_dsi_dcs_write_seq(dsi, 0x11, 0x17); - mipi_dsi_dcs_write_seq(dsi, 0x12, 0x13); - mipi_dsi_dcs_write_seq(dsi, 0x13, 0x15); - mipi_dsi_dcs_write_seq(dsi, 0x15, 0x14); - mipi_dsi_dcs_write_seq(dsi, 0x16, 0x16); - mipi_dsi_dcs_write_seq(dsi, 0x17, 0x18); - mipi_dsi_dcs_write_seq(dsi, 0x1b, 0x01); - mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1d); - mipi_dsi_dcs_write_seq(dsi, 0x20, 0x2f); - mipi_dsi_dcs_write_seq(dsi, 0x21, 0x2e); - mipi_dsi_dcs_write_seq(dsi, 0x22, 0x2d); - mipi_dsi_dcs_write_seq(dsi, 0x23, 0x2c); - mipi_dsi_dcs_write_seq(dsi, 0x29, 0x17); - mipi_dsi_dcs_write_seq(dsi, 0x2a, 0x13); - mipi_dsi_dcs_write_seq(dsi, 0x2b, 0x15); - mipi_dsi_dcs_write_seq(dsi, 0x2f, 0x14); - mipi_dsi_dcs_write_seq(dsi, 0x30, 0x16); - mipi_dsi_dcs_write_seq(dsi, 0x31, 0x18); - mipi_dsi_dcs_write_seq(dsi, 0x32, 0x04); - mipi_dsi_dcs_write_seq(dsi, 0x34, 0x10); - mipi_dsi_dcs_write_seq(dsi, 0x35, 0x1f); - mipi_dsi_dcs_write_seq(dsi, 0x36, 0x1f); - mipi_dsi_dcs_write_seq(dsi, 0x4d, 0x14); - mipi_dsi_dcs_write_seq(dsi, 0x4e, 0x36); - mipi_dsi_dcs_write_seq(dsi, 0x4f, 0x36); - mipi_dsi_dcs_write_seq(dsi, 0x53, 0x36); - mipi_dsi_dcs_write_seq(dsi, 0x71, 0x30); - mipi_dsi_dcs_write_seq(dsi, 0x79, 0x11); - mipi_dsi_dcs_write_seq(dsi, 0x7a, 0x82); - mipi_dsi_dcs_write_seq(dsi, 0x7b, 0x8f); - mipi_dsi_dcs_write_seq(dsi, 0x7d, 0x04); - mipi_dsi_dcs_write_seq(dsi, 0x80, 0x04); - mipi_dsi_dcs_write_seq(dsi, 0x81, 0x04); - mipi_dsi_dcs_write_seq(dsi, 0x82, 0x13); - mipi_dsi_dcs_w
[PATCH v4 5/9] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
The current mipi_dsi_*_write_seq() macros are non-intutitive because they contain a hidden "return" statement that will return out of the _caller_ of the macro. Let's mark them as deprecated and instead introduce some new macros that are more intuitive. These new macros are less optimal when an error occurs but should behave more optimally when there is no error. Specifically these new macros cause smaller code to get generated and the code size savings (less to fetch from RAM, less cache space used, less RAM used) are important. Since the error case isn't something we need to optimize for and these new macros are easier to understand and more flexible, they should be used. After converting to use these new functions, one example shows some nice savings while also being easier to understand. $ scripts/bloat-o-meter \ ...after/panel-novatek-nt36672e.ko \ ...ctx/panel-novatek-nt36672e.ko add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988) Function old new delta nt36672e_1080x2408_60hz_init62365248-988 Total: Before=10651, After=9663, chg -9.28% Reviewed-by: Neil Armstrong Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson --- Right now this patch introduces two new functions in drm_mipi_dsi.c. Alternatively we could have changed the prototype of the "chatty" functions and made the deprecated macros adapt to the new prototype. While this sounds nice, it bloated callers of the deprecated functioin a bit because it caused the compiler to emit less optimal code. It doesn't seem terrible to add two more functions, so I went that way. There may be cases where callers who aren't writing many sequences prefer to use the "chatty" versions anyway. (no changes since v3) Changes in v3: - Add a TODO item for cleaning up the deprecated macros/functions. - Inline kerneldoc comments for struct mipi_dsi_multi_context. Changes in v2: - New Documentation/gpu/todo.rst | 18 ++ drivers/gpu/drm/drm_mipi_dsi.c | 56 ++ include/drm/drm_mipi_dsi.h | 62 ++ 3 files changed, 136 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index e2a0585915b3..2734b8a34541 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -494,6 +494,24 @@ Contact: Douglas Anderson Level: Starter/Intermediate +Transition away from using mipi_dsi_*_write_seq() +- + +The macros mipi_dsi_generic_write_seq() and mipi_dsi_dcs_write_seq() are +non-intuitive because, if there are errors, they return out of the *caller's* +function. We should move all callers to use mipi_dsi_generic_write_seq_multi() +and mipi_dsi_dcs_write_seq_multi() macros instead. + +Once all callers are transitioned, the macros and the functions that they call, +mipi_dsi_generic_write_chatty() and mipi_dsi_dcs_write_buffer_chatty(), can +probably be removed. Alternatively, if people feel like the _multi() variants +are overkill for some use cases, we could keep the mipi_dsi_*_write_seq() +variants but change them not to return out of the caller. + +Contact: Douglas Anderson + +Level: Starter + Core refactorings = diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index 8593d9ed5891..d2957cb692d3 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -792,6 +792,34 @@ int mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi, } EXPORT_SYMBOL(mipi_dsi_generic_write_chatty); +/** + * mipi_dsi_generic_write_multi() - mipi_dsi_generic_write_chatty() w/ accum_err + * @ctx: Context for multiple DSI transactions + * @payload: buffer containing the payload + * @size: size of payload buffer + * + * Like mipi_dsi_generic_write_chatty() but deals with errors in a way that + * makes it convenient to make several calls in a row. + */ +void mipi_dsi_generic_write_multi(struct mipi_dsi_multi_context *ctx, + const void *payload, size_t size) +{ + struct mipi_dsi_device *dsi = ctx->dsi; + struct device *dev = &dsi->dev; + ssize_t ret; + + if (ctx->accum_err) + return; + + ret = mipi_dsi_generic_write(dsi, payload, size); + if (ret < 0) { + ctx->accum_err = ret; + dev_err(dev, "sending generic data %*ph failed: %d\n", + (int)size, payload, ctx->accum_err); + } +} +EXPORT_SYMBOL(mipi_dsi_generic_write_multi); + /** * mipi_dsi_generic_read() - receive data using a generic read packet * @dsi: DSI peripheral device @@ -908,6 +936,34 @@ int mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi, } EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer_chatty); +/** + * mipi_dsi_dcs_write_buffer_multi - mipi_dsi_dcs_write_buffer_chatty() w/ accum_err + * @ctx: Context for multiple DSI transactions + * @data: buffer containin
[PATCH v4 4/9] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
Through a cooperative effort between Hsin-Yi Wang and Dmitry Baryshkov, we have realized the dev_err() in the mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty" version of the functions that includes the print. While doing this, add a bit more comments to these macros making it clear that they print errors and also that they return out of _the caller's_ function. Without any changes to clients this gives a nice savings. Specifically the macro was inlined and thus the error report call was inlined into every call to mipi_dsi_dcs_write_seq() and mipi_dsi_generic_write_seq(). By using a call to a "chatty" function, the usage is reduced to one call in the chatty function and a function call at the invoking site. Building with my build system shows one example: $ scripts/bloat-o-meter \ .../before/panel-novatek-nt36672e.ko \ .../after/panel-novatek-nt36672e.ko add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-4404 (-4404) Function old new delta nt36672e_1080x2408_60hz_init 106406236 -4404 Total: Before=15055, After=10651, chg -29.25% Note that given the change in location of the print it's harder to include the "cmd" in the printout for mipi_dsi_dcs_write_seq() since, theoretically, someone could call the new chatty function with a zero-size array and it would be illegal to dereference data[0]. There's a printk format to print the whole buffer and this is probably more useful for debugging anyway. Given that we're doing this for mipi_dsi_dcs_write_seq(), let's also print the buffer for mipi_dsi_generic_write_seq() in the error case. It should be noted that the current consensus of DRM folks is that the mipi_dsi_*_write_seq() should be deprecated due to the non-intuitive return behavior. A future patch will formally mark them as deprecated and provide an alternative. Reviewed-by: Dmitry Baryshkov Reviewed-by: Neil Armstrong Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson --- Changes in v4: - Update wording as per Linus W. Changes in v3: - Rebased upon patch to remove ratelimit of prints. Changes in v2: - Add some comments to the macros about printing and returning. - Change the way err value is handled in prep for next patch. - Modify commit message now that this is part of a series. - Rebased upon patches to avoid theoretical int overflow. drivers/gpu/drm/drm_mipi_dsi.c | 56 ++ include/drm/drm_mipi_dsi.h | 47 +++- 2 files changed, 82 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index 795001bb7ff1..8593d9ed5891 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -764,6 +764,34 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device *dsi, const void *payload, } EXPORT_SYMBOL(mipi_dsi_generic_write); +/** + * mipi_dsi_generic_write_chatty() - mipi_dsi_generic_write() w/ an error log + * @dsi: DSI peripheral device + * @payload: buffer containing the payload + * @size: size of payload buffer + * + * Like mipi_dsi_generic_write() but includes a dev_err_ratelimited() + * call for you and returns 0 upon success, not the number of bytes sent. + * + * Return: 0 on success or a negative error code on failure. + */ +int mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi, + const void *payload, size_t size) +{ + struct device *dev = &dsi->dev; + ssize_t ret; + + ret = mipi_dsi_generic_write(dsi, payload, size); + if (ret < 0) { + dev_err(dev, "sending generic data %*ph failed: %zd\n", + (int)size, payload, ret); + return ret; + } + + return 0; +} +EXPORT_SYMBOL(mipi_dsi_generic_write_chatty); + /** * mipi_dsi_generic_read() - receive data using a generic read packet * @dsi: DSI peripheral device @@ -852,6 +880,34 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device *dsi, } EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer); +/** + * mipi_dsi_dcs_write_buffer_chatty - mipi_dsi_dcs_write_buffer() w/ an error log + * @dsi: DSI peripheral device + * @data: buffer containing data to be transmitted + * @len: size of transmission buffer + * + * Like mipi_dsi_dcs_write_buffer() but includes a dev_err_ratelimited() + * call for you and returns 0 upon success, not the number of bytes sent. + * + * Return: 0 on success or a negative error code on failure. + */ +int mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi, +const void *data, size_t len) +{ + struct device *dev = &dsi->dev; + ssize_t ret; + + ret = mipi_dsi_dcs_write_buffer(dsi, data, len); + if (ret < 0) { + dev_err(dev, "sending dcs data %*ph failed: %zd\n", + (int)len, data, ret); + return
[PATCH v4 3/9] drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints
We really don't expect these errors to be printed over and over again. When a driver hits the error it should bail out. Just use a normal error print. This gives a nice space savings for users of these functions: $ scripts/bloat-o-meter \ .../before/panel-novatek-nt36672e.ko \ .../after/panel-novatek-nt36672e.ko add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-16760 (-16760) Function old new delta nt36672e_1080x2408_60hz_init 17080 10640 -6440 nt36672e_1080x2408_60hz_init._rs 10320 - -10320 Total: Before=31815, After=15055, chg -52.68% Reviewed-by: Neil Armstrong Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson --- (no changes since v3) Changes in v3: - ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier. Changes in v2: - New include/drm/drm_mipi_dsi.h | 24 +++- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h index e0f56564bf97..67967be48dbd 100644 --- a/include/drm/drm_mipi_dsi.h +++ b/include/drm/drm_mipi_dsi.h @@ -314,17 +314,16 @@ int mipi_dsi_dcs_get_display_brightness_large(struct mipi_dsi_device *dsi, * @dsi: DSI peripheral device * @seq: buffer containing the payload */ -#define mipi_dsi_generic_write_seq(dsi, seq...) \ - do { \ - static const u8 d[] = { seq }; \ - struct device *dev = &dsi->dev; \ - ssize_t ret; \ - ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d)); \ - if (ret < 0) { \ - dev_err_ratelimited(dev, "transmit data failed: %zd\n", \ - ret); \ - return ret; \ - } \ +#define mipi_dsi_generic_write_seq(dsi, seq...) \ + do { \ + static const u8 d[] = { seq };\ + struct device *dev = &dsi->dev; \ + ssize_t ret; \ + ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d)); \ + if (ret < 0) {\ + dev_err(dev, "transmit data failed: %zd\n", ret); \ + return ret; \ + } \ } while (0) /** @@ -340,8 +339,7 @@ int mipi_dsi_dcs_get_display_brightness_large(struct mipi_dsi_device *dsi, ssize_t ret;\ ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \ if (ret < 0) { \ - dev_err_ratelimited(\ - dev, "sending command %#02x failed: %zd\n", \ + dev_err(dev, "sending command %#02x failed: %zd\n", \ cmd, ret); \ return ret; \ } \ -- 2.45.0.rc1.225.g2a3ae87e7f-goog
[PATCH v4 2/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()
The mipi_dsi_generic_write_seq() macro makes a call to mipi_dsi_generic_write() which returns a type ssize_t. The macro then stores it in an int and checks to see if it's negative. This could theoretically be a problem if "ssize_t" is larger than "int". To see the issue, imagine that "ssize_t" is 32-bits and "int" is 16-bits, you could see a problem if there was some code out there that looked like: mipi_dsi_generic_write_seq(dsi, <32768 bytes as arguments>); ...since we'd get back that 32768 bytes were transferred and 32768 stored in a 16-bit int would look negative. Though there are no callsites where we'd actually hit this (even if "int" was only 16-bit), it's cleaner to make the types match so let's fix it. Fixes: a9015ce59320 ("drm/mipi-dsi: Add a mipi_dsi_dcs_write_seq() macro") Reviewed-by: Neil Armstrong Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson --- (no changes since v3) Changes in v3: - Use %zd in print instead of casting errors to int. Changes in v2: - New include/drm/drm_mipi_dsi.h | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h index 70ce0b8cbc68..e0f56564bf97 100644 --- a/include/drm/drm_mipi_dsi.h +++ b/include/drm/drm_mipi_dsi.h @@ -314,17 +314,17 @@ int mipi_dsi_dcs_get_display_brightness_large(struct mipi_dsi_device *dsi, * @dsi: DSI peripheral device * @seq: buffer containing the payload */ -#define mipi_dsi_generic_write_seq(dsi, seq...) \ - do { \ - static const u8 d[] = { seq }; \ - struct device *dev = &dsi->dev;\ - int ret; \ - ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d)); \ - if (ret < 0) { \ - dev_err_ratelimited(dev, "transmit data failed: %d\n", \ - ret); \ - return ret;\ - } \ +#define mipi_dsi_generic_write_seq(dsi, seq...) \ + do { \ + static const u8 d[] = { seq }; \ + struct device *dev = &dsi->dev; \ + ssize_t ret; \ + ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d)); \ + if (ret < 0) { \ + dev_err_ratelimited(dev, "transmit data failed: %zd\n", \ + ret); \ + return ret; \ + } \ } while (0) /** -- 2.45.0.rc1.225.g2a3ae87e7f-goog
[PATCH v4 1/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
The mipi_dsi_dcs_write_seq() macro makes a call to mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro then stores it in an int and checks to see if it's negative. This could theoretically be a problem if "ssize_t" is larger than "int". To see the issue, imagine that "ssize_t" is 32-bits and "int" is 16-bits, you could see a problem if there was some code out there that looked like: mipi_dsi_dcs_write_seq(dsi, cmd, <32767 bytes as arguments>); ...since we'd get back that 32768 bytes were transferred and 32768 stored in a 16-bit int would look negative. Though there are no callsites where we'd actually hit this (even if "int" was only 16-bit), it's cleaner to make the types match so let's fix it. Fixes: 2a9e9daf7523 ("drm/mipi-dsi: Introduce mipi_dsi_dcs_write_seq macro") Reviewed-by: Neil Armstrong Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson --- (no changes since v3) Changes in v3: - Use %zd in print instead of casting errors to int. Changes in v2: - New include/drm/drm_mipi_dsi.h | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h index 82b1cc434ea3..70ce0b8cbc68 100644 --- a/include/drm/drm_mipi_dsi.h +++ b/include/drm/drm_mipi_dsi.h @@ -333,18 +333,18 @@ int mipi_dsi_dcs_get_display_brightness_large(struct mipi_dsi_device *dsi, * @cmd: Command * @seq: buffer containing data to be transmitted */ -#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...) \ - do { \ - static const u8 d[] = { cmd, seq };\ - struct device *dev = &dsi->dev;\ - int ret; \ - ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d));\ - if (ret < 0) { \ - dev_err_ratelimited( \ - dev, "sending command %#02x failed: %d\n", \ - cmd, ret); \ - return ret;\ - } \ +#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)\ + do {\ + static const u8 d[] = { cmd, seq }; \ + struct device *dev = &dsi->dev; \ + ssize_t ret;\ + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \ + if (ret < 0) { \ + dev_err_ratelimited(\ + dev, "sending command %#02x failed: %zd\n", \ + cmd, ret); \ + return ret; \ + } \ } while (0) /** -- 2.45.0.rc1.225.g2a3ae87e7f-goog
[PATCH v4 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs
The consensus of many DRM folks is that we want to move away from DSI drivers defining tables of init commands. Instead, we want to move to init functions that can use common DRM functions. The issue thus far has been that using the macros mipi_dsi_generic_write_seq() and mipi_dsi_dcs_write_seq() bloats the driver using them. While trying to solve bloat, we realized that the majority of the it was easy to solve. This series solves the bloat for existing drivers by moving the printout outside of the macro. During discussion of my v1 patch to fix the bloat [1], we also decided that we really want to change the way that drivers deal with init sequences to make it clearer. In addition to being cleaner, a side effect of moving drivers to the new style reduces bloat _even more_. This series also contains a few minor fixes / cleanups that I found along the way. This series converts four drivers over to the new mipi_dsi_dcs_write_seq_multi() function. Not all conversions have been tested, but hopefully they are straightforward enough. I'd appreciate testing. NOTE: In v3 I tried to incorporate the feedback from v2. I also converted the other two panels I could find that used table-based initialization. v4 just has a tiny bugfix and collects tags. Assuming no other problems are found the plan is to land this series sometime roughly around May 16 [2]. Note that unless I get a review/Ack for the patch ("drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()") then I'll land the series without that patch. [1] https://lore.kernel.org/r/20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid [2] https://lore.kernel.org/r/35b899d2-fb47-403a-83d2-204c0800d...@linaro.org Changes in v4: - Test to see if init is non-NULL before using it. - Update wording as per Linus W. Changes in v3: - ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier. - Add a TODO item for cleaning up the deprecated macros/functions. - Fix spacing of init function. - Inline kerneldoc comments for struct mipi_dsi_multi_context. - Rebased upon patch to remove ratelimit of prints. - Remove an unneeded error print. - Squash boe-tv101wum-nl6 lowercase patch into main patch - Use %zd in print instead of casting errors to int. - drm/panel: ili9882t: Don't use a table for initting panels - drm/panel: innolux-p079zca: Don't use a table for initting panels Changes in v2: - Add some comments to the macros about printing and returning. - Change the way err value is handled in prep for next patch. - Modify commit message now that this is part of a series. - Rebased upon patches to avoid theoretical int overflow. - drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq() - drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq() - drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi() - drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints - drm/panel: boe-tv101wum-nl6: Convert hex to lowercase - drm/panel: boe-tv101wum-nl6: Don't use a table for initting commands - drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi() Douglas Anderson (9): drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq() drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq() drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq() drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi() drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi() drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels drm/panel: ili9882t: Don't use a table for initting panels drm/panel: innolux-p079zca: Don't use a table for initting panels Documentation/gpu/todo.rst| 18 + drivers/gpu/drm/drm_mipi_dsi.c| 112 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 2792 + drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 794 +++-- drivers/gpu/drm/panel/panel-innolux-p079zca.c | 284 +- .../gpu/drm/panel/panel-novatek-nt36672e.c| 576 ++-- include/drm/drm_mipi_dsi.h| 101 +- 7 files changed, 2452 insertions(+), 2225 deletions(-) -- 2.45.0.rc1.225.g2a3ae87e7f-goog
Re: [PATCH] drm/msm: Fix gen_header.py for python earlier than v3.9
On 08/05/2024 17:46, Abhinav Kumar wrote: On 5/8/2024 2:17 AM, Jon Hunter wrote: Building the kernel with python3 versions earlier than v3.9 fails with ... Traceback (most recent call last): File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in main() File "drivers/gpu/drm/msm/registers/gen_header.py", line 951, in main parser.add_argument('--validate', action=argparse.BooleanOptionalAction) AttributeError: module 'argparse' has no attribute 'BooleanOptionalAction' The argparse attribute 'BooleanOptionalAction' is only supported for python v3.9 and later. Fix support for earlier python3 versions by explicitly defining '--validate' and '--no-validate' arguments. Signed-off-by: Jon Hunter --- drivers/gpu/drm/msm/registers/gen_header.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Thanks for your patch, I had sent something similar y'day. If you are alright with https://patchwork.freedesktop.org/patch/593057/, we can use that one. Yes that's fine with me. Thanks Jon -- nvpublic
Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate
Hi Arnd, > > I think if you want to do a new version, that is likely to run > into new problems, given that this part of fbdev is particularly > fragile and partly wrong. On the other hand, it would be nice to > have a patch to limit the use of the notifiers to the smallest > set of kernel configs that actually need it, and leave it turned > off for everything else. > > These are the ones I could find: > > - CONFIG_GUMSTIX_AM200EPD (FB_EVENT_FB_REGISTERED) I was surprised to see this driver is still around as many other old drivers was nuked as part of the pxa cleanup. It is the only user of FB_EVENT_FB_REGISTERED - so a potential cleanup if the driver is no longer relevant. Just a drive-by comment, this should not stop a v2 of the patchset. Sam
Re: [PATCH v2] mailbox: mtk-cmdq: Fix sleeping function called from invalid context
On 08/05/2024 11:51, Jason-JH.Lin wrote: > When we run kernel with lockdebug option, we will get the BUG below: > [ 106.692124] BUG: sleeping function called from invalid context at > drivers/base/power/runtime.c:1164 > [ 106.692190] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 3616, > name: kworker/u17:3 Trim logs from irrelevant context. timestamps are useless his. Registers as well. Addresses of stacktrace as well and better just decode it. > [ 106.692226] preempt_count: 1, expected: 0 > [ 106.692254] RCU nest depth: 0, expected: 0 > [ 106.692282] INFO: lockdep is turned off. > [ 106.692306] irq event stamp: 0 > [ 106.692331] hardirqs last enabled at (0): [<>] 0x0 > [ 106.692376] hardirqs last disabled at (0): [] > copy_process+0xc90/0x2ac0 > [ 106.692429] softirqs last enabled at (0): [] > copy_process+0xcb4/0x2ac0 > [ 106.692473] softirqs last disabled at (0): [<>] 0x0 > [ 106.692513] CPU: 1 PID: 3616 Comm: kworker/u17:3 Not tainted > 6.1.87-lockdep-14133-g26e933aca785 #1 6839942e1cf34914b0a366137843dd2366f52aa9 > [ 106.692556] Hardware name: Google Ciri sku0/unprovisioned board (DT) > [ 106.692586] Workqueue: imgsys_runner imgsys_runner_func > [ 106.692638] Call trace: > [ 106.692662] dump_backtrace+0x100/0x120 > [ 106.692702] show_stack+0x20/0x2c > [ 106.692737] dump_stack_lvl+0x84/0xb4 > [ 106.692775] dump_stack+0x18/0x48 > [ 106.692809] __might_resched+0x354/0x4c0 > [ 106.692847] __might_sleep+0x98/0xe4 > [ 106.692883] __pm_runtime_resume+0x70/0x124 > [ 106.692921] cmdq_mbox_send_data+0xe4/0xb1c > [ 106.692964] msg_submit+0x194/0x2dc > [ 106.693003] mbox_send_message+0x190/0x330 > [ 106.693043] imgsys_cmdq_sendtask+0x1618/0x2224 > [ 106.693082] imgsys_runner_func+0xac/0x11c > [ 106.693118] process_one_work+0x638/0xf84 > [ 106.693158] worker_thread+0x808/0xcd0 > [ 106.693196] kthread+0x24c/0x324 > [ 106.693231] ret_from_fork+0x10/0x20 > > We found that there is a spin_lock_irqsave protection in msg_submit() > of mailbox.c and it is in the atomic context. > So when cmdq driver calls pm_runtime_get_sync() in cmdq_mbox_send_data(), > it will get this BUG report. > > 1. Change pm_runtime_get_sync() to pm_runtime_get() to avoid using sleep >in atomic context. > 2. Move clk_bulk_enable() outside cmdq_runtime_resume() to ensure GCE >clocks are enabled before configuring GCE register. > 3. Add used_count to avoid cmdq_runtime_suspend() being called before >calling cmdq_runtime_resume(). > > Fixes: 8afe816b0c99 ("mailbox: mtk-cmdq-mailbox: Implement Runtime PM with > autosuspend") > Signed-off-by: Jason-JH.Lin > --- > drivers/mailbox/mtk-cmdq-mailbox.c | 24 +++- > 1 file changed, 15 insertions(+), 9 deletions(-) > > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c > b/drivers/mailbox/mtk-cmdq-mailbox.c > index 033aff11f87c..b50f42e69aab 100644 > --- a/drivers/mailbox/mtk-cmdq-mailbox.c > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c > @@ -82,6 +82,7 @@ struct cmdq { > const struct gce_plat *pdata; > struct cmdq_thread *thread; > struct clk_bulk_dataclocks[CMDQ_GCE_NUM_MAX]; > + atomic_tused_count; > boolsuspended; > }; > > @@ -317,14 +318,21 @@ static int cmdq_runtime_resume(struct device *dev) > { > struct cmdq *cmdq = dev_get_drvdata(dev); > > - return clk_bulk_enable(cmdq->pdata->gce_num, cmdq->clocks); > + atomic_inc(&cmdq->used_count); Do not implement own runtime PM counter... > + return 0; > } > > static int cmdq_runtime_suspend(struct device *dev) > { > struct cmdq *cmdq = dev_get_drvdata(dev); > > + if (atomic_read(&cmdq->used_count) == 0) { > + dev_warn(dev, "%s when used_count is 0!", __func__); > + return -EINVAL; > + } > + > clk_bulk_disable(cmdq->pdata->gce_num, cmdq->clocks); > + atomic_dec(&cmdq->used_count); > return 0; > } > > @@ -392,9 +400,8 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan, > void *data) > /* Client should not flush new tasks if suspended. */ > WARN_ON(cmdq->suspended); > > - ret = pm_runtime_get_sync(cmdq->mbox.dev); > - if (ret < 0) > - return ret; > + WARN_ON(pm_runtime_get(cmdq->mbox.dev) < 0); > + WARN_ON(clk_bulk_enable(cmdq->pdata->gce_num, cmdq->clocks)); That's a no... First, you remove error handling. Second, you add WARN and code should not have WARNs for error handling. All this looks like terrible hacky workaround just to make warning go away, without actually addressing real problem. Best regards, Krzysztof
Re: [PATCH v2 01/12] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive
On 5/8/2024 7:53 AM, Alex Deucher wrote: > On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan > wrote: >> >> On 5/3/2024 11:13 AM, Easwar Hariharan wrote: >>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" >>> with more appropriate terms. Inspired by and following on to Wolfram's >>> series to fix drivers/i2c/[1], fix the terminology for users of >>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists >>> in the specification. >>> >>> Compile tested, no functionality changes intended >>> >>> [1]: >>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ >>> >>> Signed-off-by: Easwar Hariharan >>> --- >>> .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 8 +++--- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 10 +++ >>> drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 8 +++--- >>> drivers/gpu/drm/amd/amdgpu/atombios_i2c.h | 2 +- >>> drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++--- >>> .../gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +- >>> .../drm/amd/display/dc/bios/bios_parser2.c| 2 +- >>> .../drm/amd/display/dc/core/dc_link_exports.c | 4 +-- >>> drivers/gpu/drm/amd/display/dc/dc.h | 2 +- >>> drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c | 4 +-- >>> .../display/include/grph_object_ctrl_defs.h | 2 +- >>> drivers/gpu/drm/amd/include/atombios.h| 2 +- >>> drivers/gpu/drm/amd/include/atomfirmware.h| 26 - >>> .../powerplay/hwmgr/vega20_processpptables.c | 4 +-- >>> .../amd/pm/powerplay/inc/smu11_driver_if.h| 2 +- >>> .../inc/pmfw_if/smu11_driver_if_arcturus.h| 2 +- >>> .../inc/pmfw_if/smu11_driver_if_navi10.h | 2 +- >>> .../pmfw_if/smu11_driver_if_sienna_cichlid.h | 2 +- >>> .../inc/pmfw_if/smu13_driver_if_aldebaran.h | 2 +- >>> .../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 2 +- >>> .../inc/pmfw_if/smu13_driver_if_v13_0_7.h | 2 +- >>> .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 4 +-- >>> .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 8 +++--- >>> drivers/gpu/drm/radeon/atombios.h | 16 +-- >>> drivers/gpu/drm/radeon/atombios_i2c.c | 4 +-- >>> drivers/gpu/drm/radeon/radeon_combios.c | 28 +-- >>> drivers/gpu/drm/radeon/radeon_i2c.c | 10 +++ >>> drivers/gpu/drm/radeon/radeon_mode.h | 6 ++-- >>> 28 files changed, 93 insertions(+), 93 deletions(-) >>> >> >> >> >> Hello Christian, Daniel, David, others, >> >> Could you re-review v2 since the feedback provided in v0 [1] has now been >> addressed? I can send v3 with >> all other feedback and signoffs from the other maintainers incorporated when >> I have something for amdgpu >> and radeon. > > This seems like a lot of churn. Additionally, a bunch of these > headers are shared with other OSes, so it's possible some of the > changes may end up getting reverted accidently when we sync up or we > may add new headers in new code with the old nomenclature and then > we'd need to make sure to adjust it to make sure everything was > aligned again. I would just as soon leave things as is, but I'm open > to acking them if there is a strong desire to update things. > > Alex The way I see it, this is a small downpayment on the debt we have built up so far. Internship programs like LF Outreachy to get more underrepresented groups involved in open source are trying to change the open source community culture to be more inclusive, but simultaneously rely on the culture being welcoming enough as well. I do see the challenge involved in preserving the changes and ensuring no new code is added with outdated nomenclature (but see [1]), but culture changes one person at a time, and I'd encourage the community to do the work needed so we can move past our (mostly) inadvertent role in perpetuating it. That's my 2c (or your sub-unit currency of choice). Easwar [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb
Re: [PATCH 1/2] drm: Allow mode object properties to be added after a device is registered
On Wed, May 08, 2024 at 02:43:07PM -0500, Mario Limonciello wrote: > When the colorspace property is registered on MST devices there is > no `obj_free_cb` callback for it in drm_mode_object_add(). > > Don't show a warning trace for __drm_mode_object_add() calls for > DRM_MODE_OBJECT_PROPERTY. You need to create the property ahead of time. See eg. commit 1b9bd09630d4 ("drm/i915: Do not create a new max_bpc prop for MST connectors") > > Reported-and-tested-by: Tyler Schneider > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353 > Signed-off-by: Mario Limonciello > --- > drivers/gpu/drm/drm_mode_object.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_mode_object.c > b/drivers/gpu/drm/drm_mode_object.c > index 0e8355063eee..b077547a2db4 100644 > --- a/drivers/gpu/drm/drm_mode_object.c > +++ b/drivers/gpu/drm/drm_mode_object.c > @@ -42,7 +42,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct > drm_mode_object *obj, > { > int ret; > > - WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb); > + WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb && > obj_type != DRM_MODE_OBJECT_PROPERTY); > > mutex_lock(&dev->mode_config.idr_mutex); > ret = idr_alloc(&dev->mode_config.object_idr, register_obj ? obj : NULL, > -- > 2.43.0 -- Ville Syrjälä Intel
[PATCH 2/2] Revert "drm/amd/display: Temporary Disable MST DP Colorspace Property"
MST colorspace property support was disabled due to a series of warnings that came up when the device was plugged in. As those warnings are fixed, revert commit 69a959610229 ("drm/amd/display: Temporary Disable MST DP Colorspace Property"). Reported-and-tested-by: Tyler Schneider Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353 Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3054bf79fc99..93e2030f4c17 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7695,7 +7695,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm, if (connector_type == DRM_MODE_CONNECTOR_HDMIA) { if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces)) drm_connector_attach_colorspace_property(&aconnector->base); - } else if ((connector_type == DRM_MODE_CONNECTOR_DisplayPort && !aconnector->mst_root) || + } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort || connector_type == DRM_MODE_CONNECTOR_eDP) { if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces)) drm_connector_attach_colorspace_property(&aconnector->base); -- 2.43.0
[PATCH 1/2] drm: Allow mode object properties to be added after a device is registered
When the colorspace property is registered on MST devices there is no `obj_free_cb` callback for it in drm_mode_object_add(). Don't show a warning trace for __drm_mode_object_add() calls for DRM_MODE_OBJECT_PROPERTY. Reported-and-tested-by: Tyler Schneider Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353 Signed-off-by: Mario Limonciello --- drivers/gpu/drm/drm_mode_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c index 0e8355063eee..b077547a2db4 100644 --- a/drivers/gpu/drm/drm_mode_object.c +++ b/drivers/gpu/drm/drm_mode_object.c @@ -42,7 +42,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj, { int ret; - WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb); + WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb && obj_type != DRM_MODE_OBJECT_PROPERTY); mutex_lock(&dev->mode_config.idr_mutex); ret = idr_alloc(&dev->mode_config.object_idr, register_obj ? obj : NULL, -- 2.43.0
Re: [PATCH 00/21] drm: Increase COMPILE_TEST=y coverage
On Mon, Apr 08, 2024 at 08:04:05PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > I got fed up having to build multiple architectures when > doing subsystem wide refactoring. So I decided to attack > the low hanging COMPILE_TEST=y fruit. Here are the > results. All of these drivers now build with COMPILE_TEST=y > on x86/x86_64 > > Ville Syrjälä (21): > drm/hisilicon/kirin: Include linux/io.h for readl()/writel() > drm/hisilicon/kirin: Fix 64bit divisions > drm/hisilicon/kirin: Fix MASK(32) on 32bit architectures > drm/hisilicon/kirin: Allow build with COMPILE_TEST=y > drm/omap: Open code phys_to_page() > drm/omap: Allow build with COMPILE_TEST=y > drm/atmel-hlcdc: Allow build with COMPILE_TEST=y > drm/rcar-du: Allow build with COMPILE_TEST=y > drm/stm: Allow build with COMPILE_TEST=y ^ pushed to drm-misc-next. Thanks for the reviews. > drm/armada: Fix printk arguments > drm/armada: Fix armada_debugfs_crtc_reg_write() return type > drm/armada: Allow build with COMPILE_TEST=y > drm/imx/dcss: Fix 64bit divisions > drm/imx/dcss: Allow build with COMPILE_TEST=y > drm/sti: Include linux/io.h for devm_ioremap() > drm/sti: Allow build with COMPILE_TEST=y > drm/fsl-dcu: Allow build with COMPILE_TEST=y > drm/mediatek: Allow build with COMPILE_TEST=y > drm/meson: Allow build with COMPILE_TEST=y ^ are all still without comments. > drm/tilcdc: Allow build without __iowmb() > drm/tilcdc: Allow build with COMPILE_TEST=y ^ I need to respin. -- Ville Syrjälä Intel
2024 X.Org Developers Conference - October 9-11, Montréal, Canada
Hello! We're delighted to announce that the 2024 X.Org Developers Conference (XDC) will be taking place on October 9 to 11 in Montréal, Canada, co- located with the GStreamer Conference & Hackfest 2024 which will be running from October 7 to 10. Join us for a freedesktop week in Montréal! XDC is the event for developers working on all things Open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.). New this year: XDC 2024 will feature two full days of talks followed by a day dedicated to workshops, meetings & hacking. XDC 2024 website: https://indico.freedesktop.org/event/6/ The in-person venue is the Concordia University Conference Centre, located within the John Molson School of Business. Concordia University Conference Centre 1450 Guy St., Montreal, Quebec, Canada, H3H 0A1 https://goo.gl/maps/9nDyTvKtf7X1JuJc9 As usual, XDC will be free of charge and open to the general public. Registration & Call for Proposals will be opening soon, stay tuned! Best regards, Mark Filion, on behalf of X.org
Re: /sys/kernel/debug/vgaswitcheroo directory missing
On 08/05/2024 16:54, Daniel Vetter wrote: > On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote: >> Hi, >> >> I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is >> dccb07f2914cdab2ac3a5b6c98406f765acab803.) >> >> As I say in $SUBJECT, the directory /sys/kernel/debug/vgaswitcheroo is >> missing in this release. Perhaps more importantly >> unless it is configured to simply blank the screen, when xscreensaver kicks >> in an error message flashes rapidly on and >> off complaining that no GL graphics are available. Moreover, if I start >> scribus from qterminal, I see the message >> "Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). >> Using: 0". >> >> This same userspace works fine with kernels 6.6.30 and 6.8.9 >> >> lsmod shows that the nouveau module is loaded and lsof shows that >> libdrm_nouveau is loaded for Xorg and a few desktop >> applications. However, inspecting the nouveau-related output from dmesg >> reveals: >> >> [Wed May 8 08:20:07 2024] nouveau: detected PR support, will not use DSM >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: enabling device (0006 -> >> 0007) >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: NVIDIA TU117 (167000a1) >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: bios: version 90.17.42.00.36 >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: pmu: firmware unavailable >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: fb: 4096 MiB GDDR6 >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: sec2(acr): mbox 0007 >> >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: sec2(acr):AHESASC: boot >> failed: -5 >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: acr: init failed, -5 >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: init failed with -5 >> [Wed May 8 08:20:07 2024] nouveau: DRM-master::0080: init >> failed with -5 >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: DRM-master: Device >> allocation failed: -5 >> [Wed May 8 08:20:07 2024] nouveau :01:00.0: probe with driver nouveau >> failed with error -5 >> >> With kernel 6.8.9 the equivalent output is : >> >> Wed May 8 08:51:07 2024] nouveau: detected PR support, will not use DSM >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: enabling device (0006 -> >> 0007) >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: NVIDIA TU117 (167000a1) >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: bios: version 90.17.42.00.36 >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: pmu: firmware unavailable >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: fb: 4096 MiB GDDR6 >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: VRAM: 4096 MiB >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: GART: 536870912 MiB >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: BIT table 'A' not found >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: BIT table 'L' not found >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: TMDS table version 2.0 >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: MM: using COPY for >> buffer copies >> [Wed May 8 08:51:07 2024] [drm] Initialized nouveau 1.4.0 20120801 for >> :01:00.0 on minor 1 >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: [drm] No compatible format >> found >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: [drm] Cannot find any crtc >> or sizes >> [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: Disabling PCI power >> management to avoid bug >> >> I've attached the complete dmesg output from 6.9.8-rc7+. > > I'm assuming that the working kernel's dmesg shows that the proprietary > nvidia driver is loaded, which provides all the services and gl. And now > that somehow the nouveau driver loads (but doesn't work correctly for some > reason, maybe because the userspace is missing) stuff is on fire. > > If this assumption is correct you need to reinstall your nvidia driver > stack and bother nvidia with any issues, not upstream. > -Sima > Oh, I'm terribly sorry to have bothered you! What and attitude to take to someone who is reporting a problem in an effort to help. Your assumption is wrong. I've been using linux long enough to know not to report a problem if you've got a proprietary driver installed. But never mind, I've blacklisted the nouveau driver. I'll try it again somwetime when I can be bothered because clearly I'm just a nuisance to you. >> >> Please cc me on any reply as I'm not subscribed. >> >> Chris >> > >> [Wed May 8 08:20:04 2024] Linux version 6.9.0-rc7+ (chris@laptop) (gcc14 >> (GCC) 14.0.1 20240503 (prerelease), GNU ld (GNU Binutils) 2.42) #283 SMP >> PREEMPT_DYNAMIC Tue May 7 06:58:55 BST 2024 >> [Wed May 8 08:20:04 2024] Command line: BOOT_IMAGE=/boot/vmlinuz-6.9.0-rc7+ >> ro root=PARTUUID=f927883a-e95c-4cdd-b64e-a0a778216b9f >> resume=PARTUUID=70ccedc5-d788-42bc-9f13-81e2beb61338 rootfstype=ext4 >> net.ifnames=0 video=1920x1080@60 >> [Wed May 8 08:20:04 2024] BIOS-provided physical RAM map: >> [Wed
Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate
On Wed, May 8, 2024, at 20:37, Florian Fainelli wrote: > On 5/7/24 04:44, Arnd Bergmann wrote: >> On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote: >>> On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote: >> Right, let's wait for Florian to reply. From what he said earlier >> though, the only reason that the notifiers are getting in the >> way is the link error you get from trying to load a separately >> built fb.ko module on a kernel that was built with FB=n / FB_CORE=n, >> so I don't think he even cares about notifiers, only about >> allowing the recovery application to mmap() the framebuffer. > > Right, we do not really care about notifiers AFAICT. Based upon this > discussion there has been an action on our side to stop making use of > the FB subsystem for recovery and use the full blow DRM driver instead. Ok, sounds good. > While we get there, though I still see some value into this patch (or a > v2, that is). I have a v2 ready if you think there is some value in > pursuing that route, if not, we can stop there. I think if you want to do a new version, that is likely to run into new problems, given that this part of fbdev is particularly fragile and partly wrong. On the other hand, it would be nice to have a patch to limit the use of the notifiers to the smallest set of kernel configs that actually need it, and leave it turned off for everything else. These are the ones I could find: - CONFIG_GUMSTIX_AM200EPD (FB_EVENT_FB_REGISTERED) - CONFIG_LCD_CORGI, CONFIG_LCD_TDO24M (FB_EVENT_MODE_CHANGE) - CONFIG_LEDS_TRIGGER_BACKLIGHT (FB_EVENT_BLANK) - CONFIG_FB_OLPC_DCON (FB_EVENT_BLANK/BL_CORE_FBBLANK) - CONFIG_FB_SH_MOBILE_LCDC, CONFIG_BACKLIGHT_PCF50633, CONFIG_BACKLIGHT_PANDORA, CONFIG_BACKLIGHT_LP855X (BL_CORE_FBBLANK) - CONFIG_FB_CLPS711X, CONFIG_FB_IMX, CONFIG_MACH_AMS_DELTA (lcd BL_CORE_FBBLANK) - CONFIG_LCD_AMS369FG06, CONFIG_LCD_CORGI, CONFIG_LCD_HX8357, CONFIG_LCD_ILI922X, CONFIG_LCD_ILI9320, CONFIG_LCD_HP700, CONFIG_LCD_L4F00242T03, CONFIG_LCD_LMS283GF05, CONFIG_LCD_LMS501KF03 CONFIG_LCD_LTV350QV, CONFIG_LCD_OTM3225A, CONFIG_LCD_PLATFORM, CONFIG_LCD_TDO24M (lcd BL_CORE_FBBLANK) Almost all of these are exclusive to ancient ARMv5 boards or similar, so if we make the notifiers depend on the whole list, this would leave it disabled even for most configurations that enable CONFIG_FB=y. This could be done with a 'select', but I'd prefer the 'default y; depends on LCD_FOO || LCD_BAR || ...' variant because that makes it easier to spot if someone tries to add another one. Arnd
Re: [PATCH v8 00/35] fix CONFIG_DRM_USE_DYNAMIC_DEBUG=y regression
On Mon, Apr 29, 2024 at 1:32 PM Jim Cromie wrote: > > hi Greg, Jason, DRM-folk, > > This patchset fixes the CONFIG_DRM_USE_DYNAMIC_DEBUG=y regression, > Fixes: bb2ff6c27bc9 ("drm: Disable dynamic debug as broken") > > this is v8. > Its also here: > https://github.com/jimc/linux/tree/dd-classmap-fix-8a > This patchset didnt get picked up by drm patchwork maybe its tired my stochastic renaming, sorry about that https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated 125063fix DRM_USE_DYNAMIC_DEBUG=y regressionwarningNew23jim.cromie@gmail.comNone2023-11-01 123572fix DRM_USE_DYNAMIC_DEBUG regressionfailureNew22jim.cromie@gmail.comNone2023-09-11 113363fix DRM_USE_DYNAMIC_DEBUG regressionwarningIn progress 22jim.cromie@gmail.comNone2023-08-01 111651DRM_USE_DYNAMIC_DEBUG regressionfailureNew20jim.cromie@gmail.comNone2023-01-13 111631DRM - avoid regression in -rc, fix comment is there something missing for a DRM patchwork run ? does it kick out because theres non-drm subsystem stuff in there ? thanks > v7 had at least 2 problems: > > https://lore.kernel.org/lkml/20231101002609.3533731-1-jim.cro...@gmail.com/ > https://patchwork.freedesktop.org/series/125066/ > > 1. missing __align(8) in METATDATA macro, giving too much placement > freedom to linker, caused weird segvs following non-ptr vals, but for > builtin modules only. found by lkp-test. > > 2. the main patch changed both the dyndbg API, and the drm/drivers. > This was a flag-day annoyance, and not practical. Fix by preserving > old API macro until "later", and splitting the patch and set into 2 > sequential subsets. removal can wait. > > What was broken ? > > Booting a modular kernel with drm.debug=0x1ff, this enabled pr_debugs > only in drm itself, not the yet-to-be loaded driver + helpers. I had > tested with scripts doing lots of modprobes with dyndbg=<> options > permuting. I didn't notice that I didn't really test without them. > > The deeper cause was my design error, a violation of the K&R rule: > "define once, refer many times". > > DECLARE_DYNDBG_CLASSMAP defined the classmap, and was used everywhere, > re-declaring the same static classmap repeatedly. Jani Nikula actually > picked up on this at the time, but didn't scream loudly enough for > anyone to notice, I know I didn't get it then. One patchset across 2 > trees didn't help either. > > The revised classmap API "splits" it to def & ref. > > DYNDBG_CLASSMAP_DEFINE fixes & updates the busted macro, EXPORTing the > classmap instead. It gets invoked once per subsystem, by the > parent/builtin, drm.ko for DRM. > > DYNDBG_CLASSMAP_USE in drivers and helpers refer to the classmap by > name, which links the 2 modules (like __drm_debug already does). > > These 2 tell dyndbg to map "class FOO" to the defined FOO_ID, which > allows it to make those changes via >control. > > DYNDBG_CLASSMAP_PARAM*, defines the controlling kparam, and binds it > to both the _var, and the _DEFINEd classmap. So drm uses this to bind > the classmap to __drm_debug. > > It provides the common control-point for the sub-system; it is applied > to the classmaps during modprobe of both _DEFINEr and USErs. It also > enforces the relative nature of LEVEL classmaps, ie V3>V2. > > DECLARE_DYNDBG_CLASSMAP is preserved to decouple the DRM patches. > > A new struct and elf section contain the _USEs; on modprobe, these are > scanned similarly to the _DEFINEs, but follow the references to their > defining modules, find the kparam wired to the classmap, and apply its > classmap settings to the USEr. This action is what V1 missed, which > is why drivers failed to enable debug during modprobe. > > In order to recapitulate the regression scenario without involving > DRM, the patchset (v6 I think) adds test_dynamic_debug_submod, which > is a duplicate of its parent; _submod.c #defines _SUBMOD, and then > includes parent. > > This puts _DEFINE and _USE close together in the same file, for > obviousness. It also guarantees that the submod always has the same > complement of debug()s, giving consistent output from both when > classmaps are working properly, as tested when changing callsites via > both param and >control. > > To provide a turn-key selftest, the patchset also adds > ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh, pilfered > from a debug-to-trace patchset I and Lukasz Bartozik have been working > out. It starts with basic_tests, then to test 2 new parsing > delimiters, which simplify testing of the classmap functionality. > > It works nicely from virtme-ng: > > [jimc@frodo vx]$ vrun_ -- > ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh > doing: vng --verbose --name v6.9-rc5-34-g2f1ace6e1c68 \ >--user root --cwd ../.. \ >-a dynamic_debug.verbose=2 -p 4 \ >-- ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh > virtme: waiting for virtiofsd to start > ... > [3.546739] ip (260) used greatest stack depth: 12368 bytes left > [3.60
[PULL] drm-intel-fixes
Hi Dave and Sima, Here goes our last fixes for v6.9. drm-intel-fixes-2024-05-08: - Automate CCS Mode setting during engine resets (Andi) - Fix audio time stamp programming for DP (Chaitanya) - Fix parsing backlight BDB data (Karthikeyan) The following changes since commit dd5a440a31fae6e459c0d627162825505361: Linux 6.9-rc7 (2024-05-05 14:06:01 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-05-08 for you to fetch changes up to 43b26bdd2ee5cfca80939be910d5b23a50cd7f9d: drm/i915/bios: Fix parsing backlight BDB data (2024-05-07 09:42:27 -0400) - Automate CCS Mode setting during engine resets (Andi) - Fix audio time stamp programming for DP (Chaitanya) - Fix parsing backlight BDB data (Karthikeyan) Andi Shyti (1): drm/i915/gt: Automate CCS Mode setting during engine resets Chaitanya Kumar Borah (1): drm/i915/audio: Fix audio time stamp programming for DP Karthikeyan Ramasubramanian (1): drm/i915/bios: Fix parsing backlight BDB data drivers/gpu/drm/i915/display/intel_audio.c| 113 ++ drivers/gpu/drm/i915/display/intel_bios.c | 19 + drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 -- drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 6 +- drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 +- 6 files changed, 19 insertions(+), 130 deletions(-)
Re: [RFC 1/5] drm/amdgpu: Fix migration rate limiting accounting
On 08.05.24 20:09, Tvrtko Ursulin wrote: From: Tvrtko Ursulin The logic assumed any migration attempt worked and therefore would over- account the amount of data migrated during buffer re-validation. As a consequence client can be unfairly penalised by incorrectly considering its migration budget spent. If the migration failed but data was still moved (which I think could be the case when we try evicting everything but it still doesn't work?), shouldn't the eviction movements count towards the ratelimit too? Fix it by looking at the before and after buffer object backing store and only account if there was a change. FIXME: I think this needs a better solution to account for migrations between VRAM visible and non-visible portions. FWIW, I have some WIP patches (not posted on any MLs yet though) that attempt to solve this issue (+actually enforcing ratelimits) by moving the ratelimit accounting/enforcement to TTM entirely. By moving the accounting to TTM we can count moved bytes when we move them, and don't have to rely on comparing resources to determine whether moving actually happened. This should address your FIXME as well. Regards, Friedrich Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Friedrich Vock --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index ec888fc6ead8..22708954ae68 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -784,12 +784,15 @@ static int amdgpu_cs_bo_validate(void *param, struct amdgpu_bo *bo) .no_wait_gpu = false, .resv = bo->tbo.base.resv }; + struct ttm_resource *old_res; uint32_t domain; int r; if (bo->tbo.pin_count) return 0; + old_res = bo->tbo.resource; + /* Don't move this buffer if we have depleted our allowance * to move it. Don't move anything if the threshold is zero. */ @@ -817,16 +820,29 @@ static int amdgpu_cs_bo_validate(void *param, struct amdgpu_bo *bo) amdgpu_bo_placement_from_domain(bo, domain); r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx); - p->bytes_moved += ctx.bytes_moved; - if (!amdgpu_gmc_vram_full_visible(&adev->gmc) && - amdgpu_res_cpu_visible(adev, bo->tbo.resource)) - p->bytes_moved_vis += ctx.bytes_moved; - if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) { domain = bo->allowed_domains; goto retry; } + if (!r) { + struct ttm_resource *new_res = bo->tbo.resource; + bool moved = true; + + if (old_res == new_res) + moved = false; + else if (old_res && new_res && +old_res->mem_type == new_res->mem_type) + moved = false; + + if (moved) { + p->bytes_moved += ctx.bytes_moved; + if (!amdgpu_gmc_vram_full_visible(&adev->gmc) && + amdgpu_res_cpu_visible(adev, bo->tbo.resource)) + p->bytes_moved_vis += ctx.bytes_moved; + } + } + return r; }
Re: drm scheduler and wq flavours
On Tue, May 07, 2024 at 10:09:18AM +0100, Tvrtko Ursulin wrote: > > On 07/05/2024 00:23, Matthew Brost wrote: > > On Thu, May 02, 2024 at 03:33:50PM +0100, Tvrtko Ursulin wrote: > > > > > > Hi all, > > > > > > Continuing after the brief IRC discussion yesterday regarding work queues > > > being prone to deadlocks or not, I had a browse around the code base and > > > ended up a bit confused. > > > > > > When drm_sched_init documents and allocates an *ordered* wq, if no custom > > > one was provided, could someone remind me was the ordered property > > > fundamental for something to work correctly? Like run_job vs free_job > > > ordering? > > > > > > > Before the work queue (kthread design), run_job & free_job were ordered. > > It was decided to not break this existing behavior. > > Simply for extra paranoia or you remember if there was a reason identified? > Not to break existing behavior. Can dig the entire thread if for reference if needed. > > > I ask because it appears different drivers to different things and at the > > > moment it looks we have all possible combos or ordered/unordered, bound > > > and > > > unbound, shared or not shared with the timeout wq, or even unbound for the > > > timeout wq. > > > > > > The drivers worth looking at in this respect are probably nouveau, > > > panthor, > > > pvr and xe. > > > > > > Nouveau also talks about a depency betwen run_job and free_job and goes to > > > create two unordered wqs. > > > > > > Then xe looks a bit funky with the workaround/hack for lockep where it > > > creates 512 work queues and hands them over to user queues in round-robin > > > fashion. (Instead of default 1:1.) Which I suspect is a problem which > > > should > > > be applicable for any 1:1 driver given a thorough enough test suite. > > > > > > > I think lockdep ran out of chains or something when executing some wild > > IGT with 1:1. Yes, any driver with a wild enough test would likely hit > > this lockdep splat too. Using a pool probably is not bad idea either. > > I wonder what is different between that and having a single shared unbound > queue and let kernel manage the concurrency? Both this.. > Each action (run_job, free_job, and Xe specific process msg) has its own work item on the DRM scheduler work queue. In Xe, these options must be ordered, or strictly speaking, not executed in parallel within the DRM sched entity/scheduler. With a single shared unbound queue, this breaks. > > > So anyway.. ordered vs unordered - drm sched dictated or at driver's > > > choice? > > > > > > > Default ordered, driver can override with unordered. > > .. and this, go back to my original question - whether the default queue > must be ordered or not, or under which circustmances can drivers choose > unordered. I think in drm_sched_init, where kerneldoc says it will create an > ordered queue, it would be good to document the rules. > Sure. Let me write something up. Matt > Regards, > > Tvrtko
Re: [PATCH 3/5] drm/i915: Use drm_crtc_vblank_crtc()
On Wed, May 08, 2024 at 12:12:32PM +0300, Jani Nikula wrote: > On Mon, 08 Apr 2024, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Replace the open coded drm_crtc_vblank_crtc() with the real > > thing. > > > > Cc: intel-...@lists.freedesktop.org > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Jani Nikula Ta. Pushed this one to to drm-intel-next since drm_crtc_vblank_crtc() made it there in the meantime. -- Ville Syrjälä Intel
Re: [PATCH 2/5] drm/amdgpu: Use drm_crtc_vblank_crtc()
On Wed, May 08, 2024 at 09:47:50AM -0400, Alex Deucher wrote: > On Mon, Apr 8, 2024 at 3:06 PM Ville Syrjala > wrote: > > > > From: Ville Syrjälä > > > > Replace the open coded drm_crtc_vblank_crtc() with the real > > thing. > > > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: "Pan, Xinhui" > > Cc: amd-...@lists.freedesktop.org > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Alex Deucher Thanks. Pushed to drm-misc-next. -- Ville Syrjälä Intel
Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate
On 5/7/24 04:44, Arnd Bergmann wrote: On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote: On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote: On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote: On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote: On 5/3/24 12:45, Arnd Bergmann wrote: This is the current Android GKI config: https://android.googlesource.com/kernel/common.git/+/refs/heads/android-mainline/arch/arm64/configs/gki_defconfig where I can see that CONFIG_DRM is built-in, but DRM_FBDEV_EMULATION CONFIG_VT, CONFIG_FRAMEBUFFER_CONSOLE, CONFIG_FB_DEVICE and CONFIG_FB_CORE are all disabled. So the console won't work at all,I think this means that there is no way to get the console working, but building a fb.ko module allows using /dev/fb with simplefb.ko (or any other one) happens to almost work, but only by dumb luck rather than by design. So using /dev/fb chardev without fbcon is very much a real idea. This way you should be able to run old userspace that uses fbdev directly for drawing, but your console needs are served by a userspace console running on top of drm. vt switching gets a bit more entertaining, but I thought logind has all the glue already to make that happen. Worst case you need a tiny launcher tool to get your userspace console out of the way while you launch a fbdev using application, but I think correctly implement the vt ioctls to switch to graphics mode /should/ work automatically. I do agree that this is only really a good idea with drm drivers, since those do not rely on any of the fbdev infrastructure like the notifier under discussion. I'm pretty sure what Florian is looking for has no dependency on VT, fbcon or logind, but I'm only guessing based on the information I see in the public Android source trees. My understanding is that the Android recovery application is a graphical tool that accesses the framebuffer directly and is controlled using the volume and power buttons on a phone. I suppose making CONFIG_FB_NOTIFIER optional for FB (on by default if any of the consumers of the notification are turned on) would not be a bad direction to go in general and also address Florian's link error, but that doesn't solve the more general concern about a third-party fb.ko module on a kernel that was explicitly built with FB disabled. The GKI defconfig was initially done at a time where one could not have CONFIG_FBDEV_EMULATION and CONFIG_FB_DEVICE without pulling in the entire fbdev module, but now that is possible. Maybe that is something that Android could now include? Alternatively, I wonder if that recovery image could be changed to access the screen through the /dev/dri/ interfaces? I have no experience in using those without Xorg or Wayland, is that a sensible thing to do? Uh ... I think I'm confused about the requirements. Does android's recovery image need fbdev (meaning /dev/fb chardevs), or does it need fbcon? Note that fbcon runs (or well, should run) totally fine on top of drm drivers without the fb notifier. This wasn't the case a few years ago (because fbcon also used that notifier), but nowadays fb notifiers are only needed for legacy fbdev drivers. So could it be that this "need fb notifier" requirement is a leftover from rather old kernel versions and not actually needed anymore? I think we should nail the actual requirements here first before jumping to solutions ... Right, let's wait for Florian to reply. From what he said earlier though, the only reason that the notifiers are getting in the way is the link error you get from trying to load a separately built fb.ko module on a kernel that was built with FB=n / FB_CORE=n, so I don't think he even cares about notifiers, only about allowing the recovery application to mmap() the framebuffer. Right, we do not really care about notifiers AFAICT. Based upon this discussion there has been an action on our side to stop making use of the FB subsystem for recovery and use the full blow DRM driver instead. While we get there, though I still see some value into this patch (or a v2, that is). I have a v2 ready if you think there is some value in pursuing that route, if not, we can stop there. -- Florian smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!
Hi everyone, I wasn't aware of these patches, but I'm really glad they are getting some attention, thanks a lot for your review Sima. Given that it's been a while since the patches were emailed, I'm not sure if the original authors of the patches could implement your comments. If not, I can work on it. Please let me know. I'm working on a Mutter feature that'd greatly benefit from this uapi and I'm sure other compositors would find it useful. I'll start working on a new version in a few days if nobody else is already working on it. Best wishes, José Expósito
[RFC 1/5] drm/amdgpu: Fix migration rate limiting accounting
From: Tvrtko Ursulin The logic assumed any migration attempt worked and therefore would over- account the amount of data migrated during buffer re-validation. As a consequence client can be unfairly penalised by incorrectly considering its migration budget spent. Fix it by looking at the before and after buffer object backing store and only account if there was a change. FIXME: I think this needs a better solution to account for migrations between VRAM visible and non-visible portions. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Friedrich Vock --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index ec888fc6ead8..22708954ae68 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -784,12 +784,15 @@ static int amdgpu_cs_bo_validate(void *param, struct amdgpu_bo *bo) .no_wait_gpu = false, .resv = bo->tbo.base.resv }; + struct ttm_resource *old_res; uint32_t domain; int r; if (bo->tbo.pin_count) return 0; + old_res = bo->tbo.resource; + /* Don't move this buffer if we have depleted our allowance * to move it. Don't move anything if the threshold is zero. */ @@ -817,16 +820,29 @@ static int amdgpu_cs_bo_validate(void *param, struct amdgpu_bo *bo) amdgpu_bo_placement_from_domain(bo, domain); r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx); - p->bytes_moved += ctx.bytes_moved; - if (!amdgpu_gmc_vram_full_visible(&adev->gmc) && - amdgpu_res_cpu_visible(adev, bo->tbo.resource)) - p->bytes_moved_vis += ctx.bytes_moved; - if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) { domain = bo->allowed_domains; goto retry; } + if (!r) { + struct ttm_resource *new_res = bo->tbo.resource; + bool moved = true; + + if (old_res == new_res) + moved = false; + else if (old_res && new_res && +old_res->mem_type == new_res->mem_type) + moved = false; + + if (moved) { + p->bytes_moved += ctx.bytes_moved; + if (!amdgpu_gmc_vram_full_visible(&adev->gmc) && + amdgpu_res_cpu_visible(adev, bo->tbo.resource)) + p->bytes_moved_vis += ctx.bytes_moved; + } + } + return r; } -- 2.44.0
[RFC 2/5] drm/amdgpu: Actually respect buffer migration budget
From: Tvrtko Ursulin Current code appears to live in a misconception that playing with buffer allowed and preferred placements can control the decision on whether backing store migration will be attempted or not. Both from code inspection and from empirical experiments I see that not being true, and that both allowed and preferred placement are typically set to the same bitmask. As such, when the code decides to throttle the migration for a client, it is in fact not achieving anything. Buffers can still be either migrated or not migrated based on the external (to this function and facility) logic. Fix it by not changing the buffer object placements if the migration budget has been spent. FIXME: Is it still required to call validate is the question.. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Friedrich Vock --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 22708954ae68..d07a1dd7c880 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -784,6 +784,7 @@ static int amdgpu_cs_bo_validate(void *param, struct amdgpu_bo *bo) .no_wait_gpu = false, .resv = bo->tbo.base.resv }; + bool migration_allowed = true; struct ttm_resource *old_res; uint32_t domain; int r; @@ -805,19 +806,24 @@ static int amdgpu_cs_bo_validate(void *param, struct amdgpu_bo *bo) * visible VRAM if we've depleted our allowance to do * that. */ - if (p->bytes_moved_vis < p->bytes_moved_vis_threshold) + if (p->bytes_moved_vis < p->bytes_moved_vis_threshold) { domain = bo->preferred_domains; - else + } else { domain = bo->allowed_domains; + migration_allowed = false; + } } else { domain = bo->preferred_domains; } } else { domain = bo->allowed_domains; + migration_allowed = false; } retry: - amdgpu_bo_placement_from_domain(bo, domain); + if (migration_allowed) + amdgpu_bo_placement_from_domain(bo, domain); + r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx); if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) { -- 2.44.0
[RFC 0/5] Discussion around eviction improvements
From: Tvrtko Ursulin Last few days I was looking at the situation with VRAM over subscription, what happens versus what perhaps should happen. Browsing through the driver and running some simple experiments. I ended up with this patch series which, as a disclaimer, may be completely wrong but as I found some suspicious things, to me at least, I thought it was a good point to stop and request some comments. To perhaps summarise what are the main issues I think I found: * Migration rate limiting does not bother knowing if actual migration happened and so can over-account and unfairly penalise. * Migration rate limiting does not even work, at least not for the common case where userspace configures VRAM+GTT. It thinks it can stop migration attempts by playing with bo->allowed_domains vs bo->preferred domains but, both from the code, and from empirical experiments, I see that not working at all. Both masks are identical so fiddling with them achieves nothing. * Idea of the fallback placement only works when VRAM has free space. As soon as it does not, ttm_resource_compatible is happy to leave the buffers in the secondary placement forever. * Driver thinks it will be re-validating evicted buffers on the next submission but it does not for the very common case of VRAM+GTT because it only checks if current placement is *none* of the preferred placements. All those problems are addressed in individual patches. End result of this series appears to be driver which will try harder to move buffers back into VRAM, but will be (more) correctly throttled in doing so by the existing rate limiting logic. I have run a quick benchmark of Cyberpunk 2077 and cannot say that I saw a change but that could be a good thing too. At least I did not break anything, perhaps.. On one occassion I did see the rate limiting logic get confused while for a period of few minutes it went to a mode where it was constantly giving a high migration budget. But that recovered itself when I switched clients and did not come back so I don't know. If there is something wrong there I don't think it would be caused by any patches in this series. Series is probably rough but should be good enough for dicsussion. I am curious to hear if I identified at least something correctly as a real problem. It would also be good to hear what are the suggested games to check and see whether there is any improvement. Cc: Christian König Cc: Friedrich Vock Tvrtko Ursulin (5): drm/amdgpu: Fix migration rate limiting accounting drm/amdgpu: Actually respect buffer migration budget drm/ttm: Add preferred placement flag drm/amdgpu: Use preferred placement for VRAM+GTT drm/amdgpu: Re-validate evicted buffers drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 38 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 21 ++-- drivers/gpu/drm/ttm/ttm_resource.c | 13 +--- include/drm/ttm/ttm_placement.h| 3 ++ 5 files changed, 65 insertions(+), 18 deletions(-) -- 2.44.0
[RFC 5/5] drm/amdgpu: Re-validate evicted buffers
From: Tvrtko Ursulin Currently the driver appears to be thinking that it will be attempting to re-validate the evicted buffers on the next submission if they are not in their preferred placement. That however appears not to be true for the very common case of buffers with allowed placements of VRAM+GTT. Simply because the check can only detect if the current placement is *none* of the preferred ones, happily leaving VRAM+GTT buffers in the GTT placement "forever". Fix it by extending the VRAM+GTT special case to the re-validation logic. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Friedrich Vock --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 6bddd43604bc..e53ff914b62e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -1248,10 +1248,25 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev, struct amdgpu_bo_va *bo_va, * next command submission. */ if (amdgpu_vm_is_bo_always_valid(vm, bo)) { - uint32_t mem_type = bo->tbo.resource->mem_type; + unsigned current_domain = + amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type); + bool move_to_evict = false; - if (!(bo->preferred_domains & - amdgpu_mem_type_to_domain(mem_type))) + if (!(bo->preferred_domains & current_domain)) { + move_to_evict = true; + } else if ((bo->preferred_domains & AMDGPU_GEM_DOMAIN_MASK) == + (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT) && + current_domain != AMDGPU_GEM_DOMAIN_VRAM) { + /* +* If userspace has provided a list of possible +* placements equal to VRAM+GTT, we assume VRAM is *the* +* preferred placement and so try to move it back there +* on the next submission. +*/ + move_to_evict = true; + } + + if (move_to_evict) amdgpu_vm_bo_evicted(&bo_va->base); else amdgpu_vm_bo_idle(&bo_va->base); -- 2.44.0
[RFC 3/5] drm/ttm: Add preferred placement flag
From: Tvrtko Ursulin Currently the fallback placement flag can achieve a hint that buffer should be migrated back to the non-fallback placement, however that only works while there is no memory pressure. As soon as we reach full VRAM utilisation, or worse overcommit, the logic is happy to leave buffers in the fallback placement. Consequence of this is that once buffers are evicted they never get considered to be migrated back until the memory pressure subsides, leaving a potentially active client not able to bring its buffers back in. Add a "preferred" placement flag which drivers can set when they want some extra effort to be attempted for bringing a buffer back in. QQQ: Is the current "desired" flag unfortunately named perhaps? I ended up understanding it as more like "would be nice if possible but absolutely don't bother under memory pressure". Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Friedrich Vock --- drivers/gpu/drm/ttm/ttm_resource.c | 13 + include/drm/ttm/ttm_placement.h| 3 +++ 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_resource.c b/drivers/gpu/drm/ttm/ttm_resource.c index 4a66b851b67d..59f3d1bcc11f 100644 --- a/drivers/gpu/drm/ttm/ttm_resource.c +++ b/drivers/gpu/drm/ttm/ttm_resource.c @@ -305,6 +305,8 @@ bool ttm_resource_compatible(struct ttm_resource *res, struct ttm_placement *placement, bool evicting) { + const u32 incompatible_flag = evicting ? TTM_PL_FLAG_DESIRED : +TTM_PL_FLAG_FALLBACK; struct ttm_buffer_object *bo = res->bo; struct ttm_device *bdev = bo->bdev; unsigned i; @@ -316,11 +318,14 @@ bool ttm_resource_compatible(struct ttm_resource *res, const struct ttm_place *place = &placement->placement[i]; struct ttm_resource_manager *man; - if (res->mem_type != place->mem_type) - continue; + if (res->mem_type != place->mem_type) { + if (place->flags & TTM_PL_FLAG_PREFERRED) + return false; + else + continue; + } - if (place->flags & (evicting ? TTM_PL_FLAG_DESIRED : - TTM_PL_FLAG_FALLBACK)) + if (place->flags & incompatible_flag) continue; if (place->flags & TTM_PL_FLAG_CONTIGUOUS && diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h index b510a4812609..8ea0865e9cc8 100644 --- a/include/drm/ttm/ttm_placement.h +++ b/include/drm/ttm/ttm_placement.h @@ -70,6 +70,9 @@ /* Placement is only used during eviction */ #define TTM_PL_FLAG_FALLBACK (1 << 4) +/* Placement is only used during eviction */ +#define TTM_PL_FLAG_PREFERRED (1 << 5) + /** * struct ttm_place * -- 2.44.0
[RFC 4/5] drm/amdgpu: Use preferred placement for VRAM+GTT
From: Tvrtko Ursulin Now that TTM has the preferred placement flag, extend the current workaround which assumes the GTT placement as fallback in the presence of the additional VRAM placement. By marking the VRAM placement as preferred we will make the buffer re- validation phase actually attempt to migrate them back to VRAM. Without it, TTM core logic is happy to leave them in GTT placement "forever". Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Friedrich Vock --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 50b7e7c0ce50..9be767357e86 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -128,8 +128,8 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev); struct ttm_placement *placement = &abo->placement; struct ttm_place *places = abo->placements; + int c = 0, vram_index = -1; u64 flags = abo->flags; - u32 c = 0; if (domain & AMDGPU_GEM_DOMAIN_VRAM) { unsigned int visible_pfn = adev->gmc.visible_vram_size >> PAGE_SHIFT; @@ -158,7 +158,7 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS) places[c].flags |= TTM_PL_FLAG_CONTIGUOUS; - c++; + vram_index = c++; } if (domain & AMDGPU_GEM_DOMAIN_DOORBELL) { @@ -180,8 +180,10 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) * When GTT is just an alternative to VRAM make sure that we * only use it as fallback and still try to fill up VRAM first. */ - if (domain & abo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM) + if (vram_index >= 0) { places[c].flags |= TTM_PL_FLAG_FALLBACK; + places[vram_index].flags |= TTM_PL_FLAG_PREFERRED; + } c++; } -- 2.44.0
[PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers
Memory barriers help ensure instruction ordering, NOT time and order of actual write arrival at other observers (e.g. memory-mapped IP). On architectures employing weak memory ordering, the latter can be a giant pain point, and it has been as part of this driver. Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of readl/writel, which include r/w (respectively) barriers. Replace the barriers with a readback that ensures the previous writes have exited the write buffer (as the CPU must flush the write to the register it's trying to read back) and subsequently remove the hack introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init"). Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init") Signed-off-by: Konrad Dybcio --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 5 ++--- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 -- 2 files changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index 0e3dfd4c2bc8..4135a53b55a7 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu) int ret; u32 val; - gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1); - /* Wait for the register to finish posting */ - wmb(); + gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1)); + gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ); ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val, val & (1 << 1), 100, 1); diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 973872ad0474..0acbc38b8e70 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu) } /* Clear GBIF halt in case GX domain was not collapsed */ + gpu_write(gpu, REG_A6XX_GBIF_HALT, 0); + gpu_read(gpu, REG_A6XX_GBIF_HALT); if (adreno_is_a619_holi(adreno_gpu)) { - gpu_write(gpu, REG_A6XX_GBIF_HALT, 0); gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0); - /* Let's make extra sure that the GPU can access the memory.. */ - mb(); + gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL); } else if (a6xx_has_gbif(adreno_gpu)) { - gpu_write(gpu, REG_A6XX_GBIF_HALT, 0); gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0); - /* Let's make extra sure that the GPU can access the memory.. */ - mb(); + gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT); } - /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */ - if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu)) - spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK)); - gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0); if (adreno_is_a619_holi(adreno_gpu)) --- base-commit: 93a39e4766083050ca0ecd6a3548093a3b9eb60c change-id: 20240508-topic-adreno-a2d199cd4152 Best regards, -- Konrad Dybcio
Re: [PATCH v4 2/7] drm/panel: himax-hx83102: Break out as separate driver
Hi, On Wed, May 8, 2024 at 4:52 AM cong yang wrote: > > > > +static int starry_himax83102_j02_init(struct hx83102 *ctx) > > > +{ > > > + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi }; > > > + > > > + hx83102_enable_extended_cmds(ctx, true); > > > + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83102_SETPOWER, 0x2c, > > > 0xb5, 0xb5, 0x31, 0xf1, > > > +0x31, 0xd7, 0x2f, 0x36, 0x36, > > > 0x36, 0x36, 0x1a, 0x8b, 0x11, > > > +0x65, 0x00, 0x88, 0xfa, 0xff, > > > 0xff, 0x8f, 0xff, 0x08, 0x74, > > > +0x33); > > > > The indentation is still off here. You have 5 tabs followed by a > > space. To make things line up with the opening brace I think it should > > be 4 tabs followed by 5 spaces. > > Sorry, my editor 'Visual Studio Code' It seems that the correct indentation > is not recognized. I have checked it through the 'vim' editor in the V4 > version. > Thanks. FWIW, I use VS Code and it looks fine to me. Maybe check your VS Code settings? Tab size should be 8. > > > +static int hx83102_enable(struct drm_panel *panel) > > > +{ > > > + struct hx83102 *ctx = panel_to_hx83102(panel); > > > + struct mipi_dsi_device *dsi = ctx->dsi; > > > + struct device *dev = &dsi->dev; > > > + int ret; > > > + > > > + ret = ctx->desc->init(ctx); > > > + if (ret) > > > + return ret; > > > > You're still changing behavior here. In the old boe-tv101wum-nl6 > > driver the init() function was invoked at the end of prepare(). Now > > you've got it at the beginning of enable(). If this change is > > important it should be in a separate commit and explained. > > > > > > > + ret = mipi_dsi_dcs_exit_sleep_mode(dsi); > > > + if (ret) { > > > + dev_err(dev, "Failed to exit sleep mode: %d\n", ret); > > > + return ret; > > > + } > > > + > > > + msleep(120); > > > + > > > + ret = mipi_dsi_dcs_set_display_on(dsi); > > > + if (ret) { > > > + dev_err(dev, "Failed to turn on the display: %d\n", ret); > > > + } > > > > The old boe-tv101wum-nl6 driver didn't call > > mipi_dsi_dcs_exit_sleep_mode() nor mipi_dsi_dcs_set_display_on() in > > its enable routine, did it? If this change is important please put it > > in a separate change and justify it. > > In the old boe-tv101wum-nl6 driver inital cmds was invoked at the end of > prepare() function , and call 0x11 and 0x29 at end of inital. For > himax-hx83102 driver, we move inital cmds invoked at enable() function. > For panel timing, I think there is no much difference. They are > all initial cmds executed after meeting the power-on sequence. > I will update these in the v4 commit message. Ah, I see! So the mipi_dsi_dcs_exit_sleep_mode() was the 0x11 in the old code and the mipi_dsi_dcs_set_display_on() was the 0x29 in the old code. OK, I agree that it's better like you've done it where those functions are moved out of the "->init()" function and into the caller, so please keep that as you have it. The only thing I would request is to keep the ->init() call to be made at the end of prepare() instead of the beginning of enable(). It may not matter too much, but in that case I'd rather keep it how it was or make it an explicit change and not an implicit part of the refactor. -Doug
Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
On Wed, 8 May 2024 at 09:19, Linus Torvalds wrote: > > So since we already have two versions of F_DUPFD (the other being > F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend > on that existing naming pattern, and called it F_DUPFD_QUERY instead. > > I'm not married to the name, so if somebody hates it, feel free to > argue otherwise. Side note: with this patch, doing ret = fcntl(fd1, F_DUPFD_QUERY, fd2); will result in: -1 (EBADF): 'fd1' is not a valid file descriptor -1 (EINVAL): old kernel that doesn't support F_DUPFD_QUERY 0: fd2 does not refer to the same file as fd1 1: fd2 is the same 'struct file' as fd1 and it might be worth noting a couple of things here: (a) fd2 being an invalid file descriptor does not cause EBADF, it just causes "does not match". (b) we *could* use more bits for more equality IOW, it would possibly make sense to extend the 0/1 result to be - bit #0: same file pointer - bit #1: same path - bit #2: same dentry - bit #3: same inode which are all different levels of "sameness". Does anybody care? Do we want to extend on this "sameness"? I'm not convinced, but it might be a good idea to document this as a possibly future extension, ie *if* what you care about is "same file pointer", maybe you should make sure to only look at bit #0. Linus
Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers
On 5/8/24 16:51, Christoph Hellwig wrote: On Wed, May 08, 2024 at 12:35:52PM +0100, Pavel Begunkov wrote: all these, because e.g. ttm internally does have a page pool because depending upon allocator, that's indeed beneficial. Other drm drivers have more buffer-based concepts for opportunistically memory around, usually by marking buffers that are just kept as cache as purgeable (which is a concept that goes all the way to opengl/vulkan). Because in this case it solves nothing and helps with nothing, quite the opposite. Just as well we can ask why NVMe doesn't wrap user pages into a dmabuf while doing IO. You seem to confused totally unrelated things. For short-term pins, that is pin_user_pages without FOLL_LONGTERM there would never be any point in using a dmabuf as the pin is transient. For long-term pin dmabufs in the block layer absolutely make sense, and I Well, the example fell flat, but you don't use dmabuf when there are no upsides from using it. For instance, when you already have pinned pages, you're going to use pages, and there are no other refcounting concerns. Unless there is an advantage of dmabufs over FOLL_LONGTERM that I don't know about when used with normal user pages. wish io_uring would have just implemented them from the start instead of the current fixed buffers that are not quite as useful by not pre-mapping DMA and not supporting P2P. fdget(dmabuf) would be horrible, I assume that's not the suggestion. But then it's really about kernel internals, and theoretically can be patched to wrap user pages into a dmabuf and pass it in. The tricky part is how that "pass it in" should looks like. Keith tried to cover both pre-mapping and p2p by registering dmabuf and passing the mapped addresses in an iter IIRC. Anyway, this discussion should better move from to block/fs lists, if there is any interest. -- Pavel Begunkov
Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm
On 5/8/2024 1:43 AM, Jani Nikula wrote: On Tue, 07 May 2024, Abhinav Kumar wrote: Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"), compilation is broken on machines having python versions older than 3.9 due to dependency on argparse.BooleanOptionalAction. Is it now okay to require Python for the build? Not listed in Documentation/process/changes.rst. BR, Jani. The change to move gen_header.py to kernel is already part of the v6.10 pull request. This change only fixes the version dependency. But, I agree we should update the changes.rst (better late than never). Dmitry, can you pls suggest which version we want to list there? I am hoping that after this change there are no further dependencies on python versions, so anything > EOL should be fine. I am leaning towards v3.8 Switch to use simple bool for the validate flag to remove the dependency. Fixes: 5acf49119630 ("drm/msm: import gen_header.py script from Mesa") Signed-off-by: Abhinav Kumar --- drivers/gpu/drm/msm/registers/gen_header.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/registers/gen_header.py b/drivers/gpu/drm/msm/registers/gen_header.py index fc3bfdc991d2..3926485bb197 100644 --- a/drivers/gpu/drm/msm/registers/gen_header.py +++ b/drivers/gpu/drm/msm/registers/gen_header.py @@ -538,7 +538,7 @@ class Parser(object): self.variants.add(reg.domain) def do_validate(self, schemafile): - if self.validate == False: + if not self.validate: return try: @@ -948,7 +948,8 @@ def main(): parser = argparse.ArgumentParser() parser.add_argument('--rnn', type=str, required=True) parser.add_argument('--xml', type=str, required=True) - parser.add_argument('--validate', action=argparse.BooleanOptionalAction) + parser.add_argument('--validate', default=False, action='store_true') + parser.add_argument('--no-validate', dest='validate', action='store_false') subparsers = parser.add_subparsers() subparsers.required = True
Re: [PATCH] drm/msm: Fix gen_header.py for python earlier than v3.9
On 5/8/2024 2:17 AM, Jon Hunter wrote: Building the kernel with python3 versions earlier than v3.9 fails with ... Traceback (most recent call last): File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in main() File "drivers/gpu/drm/msm/registers/gen_header.py", line 951, in main parser.add_argument('--validate', action=argparse.BooleanOptionalAction) AttributeError: module 'argparse' has no attribute 'BooleanOptionalAction' The argparse attribute 'BooleanOptionalAction' is only supported for python v3.9 and later. Fix support for earlier python3 versions by explicitly defining '--validate' and '--no-validate' arguments. Signed-off-by: Jon Hunter --- drivers/gpu/drm/msm/registers/gen_header.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Thanks for your patch, I had sent something similar y'day. If you are alright with https://patchwork.freedesktop.org/patch/593057/, we can use that one. diff --git a/drivers/gpu/drm/msm/registers/gen_header.py b/drivers/gpu/drm/msm/registers/gen_header.py index fc3bfdc991d2..64f67d2e3f1c 100644 --- a/drivers/gpu/drm/msm/registers/gen_header.py +++ b/drivers/gpu/drm/msm/registers/gen_header.py @@ -948,7 +948,8 @@ def main(): parser = argparse.ArgumentParser() parser.add_argument('--rnn', type=str, required=True) parser.add_argument('--xml', type=str, required=True) - parser.add_argument('--validate', action=argparse.BooleanOptionalAction) + parser.add_argument('--validate', dest='validate', action='store_true') + parser.add_argument('--no-validate', dest='validate', action='store_false') subparsers = parser.add_subparsers() subparsers.required = True
Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
On Tue, 7 May 2024 at 12:07, Linus Torvalds wrote: > > That example thing shows that we shouldn't make it a FISAME ioctl - we > should make it a fcntl() instead, and it would just be a companion to > F_DUPFD. > > Doesn't that strike everybody as a *much* cleaner interface? I think > F_ISDUP would work very naturally indeed with F_DUPFD. So since we already have two versions of F_DUPFD (the other being F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend on that existing naming pattern, and called it F_DUPFD_QUERY instead. I'm not married to the name, so if somebody hates it, feel free to argue otherwise. But with that, the suggested patch would end up looking something like the attached (I also re-ordered the existing "F_LINUX_SPECIFIC_BASE" users, since one of them was out of numerical order). This really feels like a very natural thing, and yes, the 'same_fd()' function in systemd that Christian also pointed at could use this very naturally. Also note that I obviously haven't tested this. Because obviously this is trivially correct and cannot possibly have any bugs. Right? RIGHT? And yes, I did check - despite the odd jump in numbers, we've never had anything between F_NOTIFY (+2) and F_CANCELLK (+5). We added F_SETLEASE (+0) , F_GETLEASE (+1) and F_NOTIFY (+2) in 2.4.0-test9 (roughly October 2000, I didn't dig deeper). And then back in 2007 we suddenly jumped to F_CANCELLK (+5) in commit 9b9d2ab4154a ("locks: add lock cancel command"). I don't know why 3/4 were shunned. After that we had 22d2b35b200f ("F_DUPFD_CLOEXEC implementation") add F_DUPFD_CLOEXEC (+6). I'd have loved to put F_DUPFD_QUERY next to it, but +5 and +7 are both used. Linus fs/fcntl.c | 23 +++ include/uapi/linux/fcntl.h | 14 -- 2 files changed, 31 insertions(+), 6 deletions(-) diff --git a/fs/fcntl.c b/fs/fcntl.c index 54cc85d3338e..1ddb63f70445 100644 --- a/fs/fcntl.c +++ b/fs/fcntl.c @@ -327,6 +327,25 @@ static long fcntl_set_rw_hint(struct file *file, unsigned int cmd, return 0; } +/* + * Is the file descriptor a dup of the file? + */ +static long f_dupfd_query(int fd, struct file *filp) +{ + struct fd f = fdget_raw(fd); + + /* + * We can do the 'fdput()' immediately, as the only thing that + * matters is the pointer value which isn't changed by the fdput. + * + * Technically we didn't need a ref at all, and 'fdget()' was + * overkill, but given our lockless file pointer lookup, the + * alternatives are complicated. + */ + fdput(f); + return f.file == filp; +} + static long do_fcntl(int fd, unsigned int cmd, unsigned long arg, struct file *filp) { @@ -342,6 +361,9 @@ static long do_fcntl(int fd, unsigned int cmd, unsigned long arg, case F_DUPFD_CLOEXEC: err = f_dupfd(argi, filp, O_CLOEXEC); break; + case F_DUPFD_QUERY: + err = f_dupfd_query(argi, filp); + break; case F_GETFD: err = get_close_on_exec(fd) ? FD_CLOEXEC : 0; break; @@ -446,6 +468,7 @@ static int check_fcntl_cmd(unsigned cmd) switch (cmd) { case F_DUPFD: case F_DUPFD_CLOEXEC: + case F_DUPFD_QUERY: case F_GETFD: case F_SETFD: case F_GETFL: diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h index 282e90aeb163..c0bcc185fa48 100644 --- a/include/uapi/linux/fcntl.h +++ b/include/uapi/linux/fcntl.h @@ -8,6 +8,14 @@ #define F_SETLEASE (F_LINUX_SPECIFIC_BASE + 0) #define F_GETLEASE (F_LINUX_SPECIFIC_BASE + 1) +/* + * Request nofications on a directory. + * See below for events that may be notified. + */ +#define F_NOTIFY (F_LINUX_SPECIFIC_BASE + 2) + +#define F_DUPFD_QUERY (F_LINUX_SPECIFIC_BASE + 3) + /* * Cancel a blocking posix lock; internal use only until we expose an * asynchronous lock api to userspace: @@ -17,12 +25,6 @@ /* Create a file descriptor with FD_CLOEXEC set. */ #define F_DUPFD_CLOEXEC (F_LINUX_SPECIFIC_BASE + 6) -/* - * Request nofications on a directory. - * See below for events that may be notified. - */ -#define F_NOTIFY (F_LINUX_SPECIFIC_BASE+2) - /* * Set and get of pipe page size array */
Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers
On 5/8/24 16:58, Jason Gunthorpe wrote: On Wed, May 08, 2024 at 04:44:32PM +0100, Pavel Begunkov wrote: like a weird and indirect way to get there. Why can't io_uring just be the entity that does the final free and not mess with the logic allocator? Then the user has to do a syscall (e.g. via io_uring) to return pages, and there we'd need to care how to put the pages efficiently, i.e. hitting the page pool's fast path, e.g. by hoping napi is scheduled and scheduled for the CPU we're running on, or maybe transferring the pages to the right CPU first. Compare it with userspace putting pages into a ring, and the allocator taking from there when needed without any extra synchronisation and hassle just because it's a sole consumer. Wow, that sounds a bit terrifying for security, but I guess I can see your point. Mind elaborating about security? "No synchronisation" is for grabbing from the ring, it's napi exclusive, but it does refcounting to make sure there are no previous net users left and the userspace doesn't try anything funny like returning a page twice. And it's not even a page but rather a separately refcounted buffer represented by an offset from the userspace POV. It doesn't even have to be page sized, hw benefits from smaller chunks. You are replacing the whole allocator logic if you are effectively putting the free list in userspace memory. Jason -- Pavel Begunkov
Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers
On Wed, May 08, 2024 at 04:44:32PM +0100, Pavel Begunkov wrote: > > like a weird and indirect way to get there. Why can't io_uring just be > > the entity that does the final free and not mess with the logic > > allocator? > > Then the user has to do a syscall (e.g. via io_uring) to return pages, > and there we'd need to care how to put the pages efficiently, i.e. > hitting the page pool's fast path, e.g. by hoping napi is scheduled and > scheduled for the CPU we're running on, or maybe transferring the pages > to the right CPU first. > > Compare it with userspace putting pages into a ring, and the allocator > taking from there when needed without any extra synchronisation and > hassle just because it's a sole consumer. Wow, that sounds a bit terrifying for security, but I guess I can see your point. You are replacing the whole allocator logic if you are effectively putting the free list in userspace memory. Jason
Re: /sys/kernel/debug/vgaswitcheroo directory missing
On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote: > Hi, > > I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is > dccb07f2914cdab2ac3a5b6c98406f765acab803.) > > As I say in $SUBJECT, the directory /sys/kernel/debug/vgaswitcheroo is > missing in this release. Perhaps more importantly > unless it is configured to simply blank the screen, when xscreensaver kicks > in an error message flashes rapidly on and > off complaining that no GL graphics are available. Moreover, if I start > scribus from qterminal, I see the message > "Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). > Using: 0". > > This same userspace works fine with kernels 6.6.30 and 6.8.9 > > lsmod shows that the nouveau module is loaded and lsof shows that > libdrm_nouveau is loaded for Xorg and a few desktop > applications. However, inspecting the nouveau-related output from dmesg > reveals: > > [Wed May 8 08:20:07 2024] nouveau: detected PR support, will not use DSM > [Wed May 8 08:20:07 2024] nouveau :01:00.0: enabling device (0006 -> > 0007) > [Wed May 8 08:20:07 2024] nouveau :01:00.0: NVIDIA TU117 (167000a1) > [Wed May 8 08:20:07 2024] nouveau :01:00.0: bios: version 90.17.42.00.36 > [Wed May 8 08:20:07 2024] nouveau :01:00.0: pmu: firmware unavailable > [Wed May 8 08:20:07 2024] nouveau :01:00.0: fb: 4096 MiB GDDR6 > [Wed May 8 08:20:07 2024] nouveau :01:00.0: sec2(acr): mbox 0007 > > [Wed May 8 08:20:07 2024] nouveau :01:00.0: sec2(acr):AHESASC: boot > failed: -5 > [Wed May 8 08:20:07 2024] nouveau :01:00.0: acr: init failed, -5 > [Wed May 8 08:20:07 2024] nouveau :01:00.0: init failed with -5 > [Wed May 8 08:20:07 2024] nouveau: DRM-master::0080: init failed > with -5 > [Wed May 8 08:20:07 2024] nouveau :01:00.0: DRM-master: Device > allocation failed: -5 > [Wed May 8 08:20:07 2024] nouveau :01:00.0: probe with driver nouveau > failed with error -5 > > With kernel 6.8.9 the equivalent output is : > > Wed May 8 08:51:07 2024] nouveau: detected PR support, will not use DSM > [Wed May 8 08:51:07 2024] nouveau :01:00.0: enabling device (0006 -> > 0007) > [Wed May 8 08:51:07 2024] nouveau :01:00.0: NVIDIA TU117 (167000a1) > [Wed May 8 08:51:07 2024] nouveau :01:00.0: bios: version 90.17.42.00.36 > [Wed May 8 08:51:07 2024] nouveau :01:00.0: pmu: firmware unavailable > [Wed May 8 08:51:07 2024] nouveau :01:00.0: fb: 4096 MiB GDDR6 > [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: VRAM: 4096 MiB > [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: GART: 536870912 MiB > [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: BIT table 'A' not found > [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: BIT table 'L' not found > [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: TMDS table version 2.0 > [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: MM: using COPY for > buffer copies > [Wed May 8 08:51:07 2024] [drm] Initialized nouveau 1.4.0 20120801 for > :01:00.0 on minor 1 > [Wed May 8 08:51:07 2024] nouveau :01:00.0: [drm] No compatible format > found > [Wed May 8 08:51:07 2024] nouveau :01:00.0: [drm] Cannot find any crtc > or sizes > [Wed May 8 08:51:07 2024] nouveau :01:00.0: DRM: Disabling PCI power > management to avoid bug > > I've attached the complete dmesg output from 6.9.8-rc7+. I'm assuming that the working kernel's dmesg shows that the proprietary nvidia driver is loaded, which provides all the services and gl. And now that somehow the nouveau driver loads (but doesn't work correctly for some reason, maybe because the userspace is missing) stuff is on fire. If this assumption is correct you need to reinstall your nvidia driver stack and bother nvidia with any issues, not upstream. -Sima > > Please cc me on any reply as I'm not subscribed. > > Chris > > [Wed May 8 08:20:04 2024] Linux version 6.9.0-rc7+ (chris@laptop) (gcc14 > (GCC) 14.0.1 20240503 (prerelease), GNU ld (GNU Binutils) 2.42) #283 SMP > PREEMPT_DYNAMIC Tue May 7 06:58:55 BST 2024 > [Wed May 8 08:20:04 2024] Command line: BOOT_IMAGE=/boot/vmlinuz-6.9.0-rc7+ > ro root=PARTUUID=f927883a-e95c-4cdd-b64e-a0a778216b9f > resume=PARTUUID=70ccedc5-d788-42bc-9f13-81e2beb61338 rootfstype=ext4 > net.ifnames=0 video=1920x1080@60 > [Wed May 8 08:20:04 2024] BIOS-provided physical RAM map: > [Wed May 8 08:20:04 2024] BIOS-e820: [mem > 0x-0x0009efff] usable > [Wed May 8 08:20:04 2024] BIOS-e820: [mem > 0x0009f000-0x000f] reserved > [Wed May 8 08:20:04 2024] BIOS-e820: [mem > 0x0010-0x7e1d8fff] usable > [Wed May 8 08:20:04 2024] BIOS-e820: [mem > 0x7e1d9000-0x7ead8fff] reserved > [Wed May 8 08:20:04 2024] BIOS-e820: [mem > 0x7ead9000-0x8cceefff] usable > [Wed May 8 08:20:04 2024] BIOS-e820: [mem > 0x8ccef000-0x8eedefff] reserved >
Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote: > On Wed, 8 May 2024 at 09:33, Daniel Vetter wrote: > > On Wed, May 08, 2024 at 06:46:53AM +0100, Daniel Stone wrote: > > > That would have the unfortunate side effect of making sandboxed apps > > > less efficient on some platforms, since they wouldn't be able to do > > > direct scanout anymore ... > > > > I was assuming that everyone goes through pipewire, and ideally that is > > the only one that can even get at these special chardev. > > > > If pipewire is only for sandboxed apps then yeah this aint great :-/ > > No, PipeWire is fine, I mean graphical apps. > > Right now, if your platform requires CMA for display, then the app > needs access to the GPU render node and the display node too, in order > to allocate buffers which the compositor can scan out directly. If it > only has access to the render nodes and not the display node, it won't > be able to allocate correctly, so its content will need a composition > pass, i.e. performance penalty for sandboxing. But if it can allocate > correctly, then hey, it can exhaust CMA just like heaps can. > > Personally I think we'd be better off just allowing access and > figuring out cgroups later. It's not like the OOM story is great > generally, and hey, you can get there with just render nodes ... Imo the right fix is to ask the compositor to allocate the buffers in this case, and then maybe have some kind of revoke/purge behaviour on these buffers. Compositor has an actual idea of who's a candidate for direct scanout after all, not the app. Or well at least force migrate the memory from cma to shmem. If you only whack cgroups on this issue you're still stuck in the world where either all apps together can ddos the display or no one can realistically direct scanout. So yeah on the display side the problem isn't solved either, but we knew that already. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
On Wed, May 08, 2024 at 12:08:57PM +0200, Christian Brauner wrote: > On Mon, May 06, 2024 at 04:29:44PM +0200, Christian König wrote: > > Am 04.05.24 um 20:20 schrieb Linus Torvalds: > > > On Sat, 4 May 2024 at 08:32, Linus Torvalds > > > wrote: > > > > Lookie here, the fundamental issue is that epoll can call '->poll()' > > > > on a file descriptor that is being closed concurrently. > > > Thinking some more about this, and replying to myself... > > > > > > Actually, I wonder if we could *really* fix this by simply moving the > > > eventpoll_release() to where it really belongs. > > > > > > If we did it in file_close_fd_locked(), it would actually make a > > > *lot* more sense. Particularly since eventpoll actually uses this: > > > > > > struct epoll_filefd { > > > struct file *file; > > > int fd; > > > } __packed; > > > > > > ie it doesn't just use the 'struct file *', it uses the 'fd' itself > > > (for ep_find()). > > > > > > (Strictly speaking, it should also have a pointer to the 'struct > > > files_struct' to make the 'int fd' be meaningful). > > > > While I completely agree on this I unfortunately have to ruin the idea. > > > > Before we had KCMP some people relied on the strange behavior of eventpoll > > to compare struct files when the fd is the same. > > > > I just recently suggested that solution to somebody at AMD as a workaround > > when KCMP is disabled because of security hardening and I'm pretty sure I've > > seen it somewhere else as well. > > > > So when we change that it would break (undocumented?) UAPI behavior. > > I've worked on that a bit yesterday and I learned new things about epoll > and ran into some limitations. > > Like, what happens if process P1 has a file descriptor registered in an > epoll instance and now P1 forks and creates P2. So every file that P1 > maintains gets copied into a new file descriptor table for P2. And the > same file descriptors refer to the same files for both P1 and P2. So this is pretty similar to any other struct file that has resources hanging off the struct file instead of the underlying inode. Like drm chardev files, where all the buffers, gpu contexts and everything else hangs off the file and there's no other way to get at them (except when exporting to some explicitly meant-for-sharing file like dma-buf). If you fork() that it's utter hilarity, which is why absolutely everyone should set O_CLOEXEC on these. Or EPOLL_CLOEXEC for epoll_create. For the uapi issue you describe below my take would be that we should just try, and hope that everyone's been dutifully using O_CLOEXEC. But maybe I'm biased from the gpu world, where we've been hammering it in that "O_CLOEXEC or bust" mantra since well over a decade. Really the only valid use-case is something like systemd handing open files to a service, where it drops priviledges even well before the exec() call. But we can't switch around the defaults for any of these special open files with anything more than just a current seek position as state, since that breaks uapi. -Sima > > So there's two interesting cases here: > > (1) P2 explicitly removes the file descriptor from the epoll instance > via epoll_ctl(EPOLL_CTL_DEL). That removal affects both P1 and P2 > since the pair is only registered once and it isn't > marked whether it belongs to P1 and P2 fdtable. > > So effectively fork()ing with epoll creates a weird shared state > where removal of file descriptors that were registered before the > fork() affects both child and parent. > > I found that surprising even though I've worked with epoll quite > extensively in low-level userspace. > > (2) P2 doesn't close it's file descriptors. It just exits. Since removal > of the file descriptor from the epoll instance isn't done during > close() but during last fput() P1's epoll state remains unaffected > by P2's sloppy exit because P1 still holds references to all files > in its fdtable. > > (Sidenote, if one ends up adding every more duped-fds into epoll > instance that one doesn't explicitly close and all of them refer to > the same file wouldn't one just be allocating new epitems that > are kept around for a really long time?) > > So if the removal of the fd would now be done during close() or during > exit_files() when we call close_files() and since there's currently no > way of differentiating whether P1 or P2 own that fd it would mean that > (2) collapses into (1) and we'd always alter (1)'s epoll state. That > would be a UAPI break. > > So say we record the fdtable to get ownership of that file descriptor so > P2 doesn't close anything in (2) that really belongs to P1 to fix that > problem. > > But afaict, that would break another possible use-case. Namely, where P1 > creates an epoll instance and registeres fds and then fork()s to create > P2. Now P1 can exit and P2 takes over the epoll loop of P1. This > wouldn't work anymore becaus
Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers
On 5/8/24 15:25, Jason Gunthorpe wrote: On Wed, May 08, 2024 at 12:30:07PM +0100, Pavel Begunkov wrote: I'm not going to pretend to know about page pool details, but dmabuf is the way to get the bulk of pages into a pool within the net stack's allocator and keep that bulk properly refcounted while.> An object like dmabuf is needed for the general case because there are not going to be per-page references or otherwise available. They are already pinned, memory is owned by the provider, io_uring in this case, and it should not be freed circumventing io_uring, and at this stage calling release_pages() is not such a hassle, especially comparing to introducing an additional object. Something needs to co-ordinate when the net stack's allocator is done with the bulk of pages and when io_uring and do the final put_user_page() to free it. DMABUF is not an unreasonable choice for this. When a page pool dies notifies io_uring via the ->destroy callback. Vise versa, when io_uring wants to terminate zerocopy, it releases the interface queue, which kills the page pool, ending in ->destroy again. topic to me, and honestly hacking into the allocator free function seems a bit weird.. Do you also think that DMA_BUF_IOCTL_SYNC is a weird hack, because it "delays free" by pinning the dmabuf object and letting the user read memory instead of copying it? I can find many examples It seems to me the flow you want is for the driver to allocate a page, put it on a rx ring, process it through the netstack, and deliver it to io_uring. io_uring would then sit on the allocation until userspace it done and return it back to the netstack allocator. That's right, with a note that "driver allocating a page" is not a alloc_page() but grabbing a user page/frag the user registered beforehand. Hooking the free of the netstack allocator and then defering it seems FWIW, it's not about page pool's ->release_page, it's a slow path and in an ideal world wouldn't be called outside of tear down. like a weird and indirect way to get there. Why can't io_uring just be the entity that does the final free and not mess with the logic allocator? Then the user has to do a syscall (e.g. via io_uring) to return pages, and there we'd need to care how to put the pages efficiently, i.e. hitting the page pool's fast path, e.g. by hoping napi is scheduled and scheduled for the CPU we're running on, or maybe transferring the pages to the right CPU first. Compare it with userspace putting pages into a ring, and the allocator taking from there when needed without any extra synchronisation and hassle just because it's a sole consumer. -- Pavel Begunkov