[Bug 216625] [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 --- Comment #3 from Pierre Ossman (pierre-bugzi...@ossman.eu) --- This is wrong, I checked the wrong lines in dnf's history: > Last working system: > > kernel-5.13.8-100.fc33.x86_64 The last working kernel is actually 5.17.12-100.fc34.x86_64. So if it's the kernel it's likely 5.18 or 5.19 that regressed. I'll give 5.18.1 a spin. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216625] [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 --- Comment #2 from Pierre Ossman (pierre-bugzi...@ossman.eu) --- A bisect will be difficult, given that I can't reproduce it. :/ Any clues from the dmesg that could tell how to provoke it? Or some settings that could provide more information? I can try a few version and see if I'm able to narrow it down somewhat. It's difficult to know when to assume it's a good version as in some cases it has gone weeks without a lookup... -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v5 1/2] dt-bindings: it6505: add properties to restrict output bandwidth
Hi Allen, On Tue, Oct 25, 2022 at 12:37 AM Rob Herring wrote: > > On Wed, Oct 19, 2022 at 05:32:13PM +0800, allen wrote: > > From: allen chen > > > > Add properties to restrict dp output data-lanes and clock. > > > > Signed-off-by: Pin-Yen Lin > > Signed-off-by: Allen Chen > > --- > > .../bindings/display/bridge/ite,it6505.yaml | 89 +-- > > 1 file changed, 83 insertions(+), 6 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > > b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > > index 833d11b2303a7..8e607b6929fc9 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > > @@ -52,9 +52,70 @@ properties: > > maxItems: 1 > > description: extcon specifier for the Power Delivery > > > > - port: > > -$ref: /schemas/graph.yaml#/properties/port > > -description: A port node pointing to DPI host port node > > No existing users you are breaking? The commit msg should explain. > > > + ports: > > +$ref: /schemas/graph.yaml#/properties/ports > > + > > +properties: > > + port@0: > > +$ref: /schemas/graph.yaml#/$defs/port-base > > +unevaluatedProperties: false > > +description: A port node pointing to DPI host port node > > + > > +properties: > > + endpoint: > > +$ref: /schemas/graph.yaml#/$defs/endpoint-base > > +unevaluatedProperties: false > > + > > +properties: > > + link-frequencies: > > +minItems: 1 > > +maxItems: 1 > > +description: Allowed max link frequencies in Hz > > + > > + port@1: > > +$ref: /schemas/graph.yaml#/$defs/port-base > > +unevaluatedProperties: false > > +description: Video port for DP output > > + > > +properties: > > + endpoint: > > +$ref: /schemas/graph.yaml#/$defs/endpoint-base > > +unevaluatedProperties: false > > + > > +properties: > > + data-lanes: > > +oneOf: > > + - minItems: 1 > > +maxItems: 1 > > +uniqueItems: true > > +items: > > + enum: > > +- 0 > > +- 1 > > +description: For one lane operation. > > + > > + - minItems: 2 > > +maxItems: 2 > > +uniqueItems: true > > +items: > > + enum: > > +- 0 > > +- 1 > > +description: For two lanes operation. > > + > > + - minItems: 4 > > +maxItems: 4 > > +uniqueItems: true > > +items: > > + enum: > > +- 0 > > +- 1 > > +- 2 > > +- 3 > > +description: For four lanes operation. > > I would do just: > > data-lanes: > minItems: 1 > items: > - enum: [ 0, 1 ] > - const: 1 > - const: 2 > - const: 3 I believe we also want a `uniqueItems: true` to prevent duplicate items like `<1 1>`. Regards, Pin-yen > > It does allow 3 lanes, but I don't think that's a big deal. What it does > doesn't allow is any order and yours does. > > Rob
[PATCH v3 12/12] arm64: dts: qcom: sa8295-adp: Enable DP instances
From: Bjorn Andersson
The SA8295P ADP has, among other interfaces, six MiniDP connectors which
are connected to MDSS0 DP2 and DP3, and MDSS1 DP0 through DP3.
Enable Display Clock controllers, MDSS instanced, MDPs, DP controllers,
DP PHYs and link them all together.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch on list
arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 244 ++-
1 file changed, 242 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
index 2c62ba6a49c5..f35345115c85 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
@@ -23,6 +23,90 @@ aliases {
chosen {
stdout-path = "serial0:115200n8";
};
+
+ dp2-connector {
+ compatible = "dp-connector";
+ label = "DP2";
+ type = "mini";
+
+ hpd-gpios = < 20 GPIO_ACTIVE_HIGH>;
+
+ port {
+ dp2_connector_in: endpoint {
+ remote-endpoint = <_dp0_phy_out>;
+ };
+ };
+ };
+
+ dp3-connector {
+ compatible = "dp-connector";
+ label = "DP3";
+ type = "mini";
+
+ hpd-gpios = < 45 GPIO_ACTIVE_HIGH>;
+
+ port {
+ dp3_connector_in: endpoint {
+ remote-endpoint = <_dp1_phy_out>;
+ };
+ };
+ };
+
+ edp0-connector {
+ compatible = "dp-connector";
+ label = "EDP0";
+ type = "mini";
+
+ hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;
+
+ port {
+ edp0_connector_in: endpoint {
+ remote-endpoint = <_dp2_phy_out>;
+ };
+ };
+ };
+
+ edp1-connector {
+ compatible = "dp-connector";
+ label = "EDP1";
+ type = "mini";
+
+ hpd-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+ port {
+ edp1_connector_in: endpoint {
+ remote-endpoint = <_dp3_phy_out>;
+ };
+ };
+ };
+
+ edp2-connector {
+ compatible = "dp-connector";
+ label = "EDP2";
+ type = "mini";
+
+ hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
+
+ port {
+ edp2_connector_in: endpoint {
+ remote-endpoint = <_dp2_phy_out>;
+ };
+ };
+ };
+
+ edp3-connector {
+ compatible = "dp-connector";
+ label = "EDP3";
+ type = "mini";
+
+ hpd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ edp3_connector_in: endpoint {
+ remote-endpoint = <_dp3_phy_out>;
+ };
+ };
+ };
};
_rsc {
@@ -156,13 +240,169 @@ vreg_l7g: ldo7 {
vreg_l8g: ldo8 {
regulator-name = "vreg_l8g";
- regulator-min-microvolt = <88>;
- regulator-max-microvolt = <88>;
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = ;
+ regulator-allow-set-load;
+ };
+
+ vreg_l11g: ldo11 {
+ regulator-name = "vreg_l11g";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <912000>;
regulator-initial-mode = ;
};
};
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_dp2 {
+ status = "okay";
+
+ data-lanes = <0 1 2 3>;
+
+ ports {
+ port@1 {
+ reg = <1>;
+ mdss0_dp2_phy_out: endpoint {
+ remote-endpoint = <_connector_in>;
+ };
+ };
+ };
+};
+
+_dp2_phy {
+ status = "okay";
+
+ vdda-phy-supply = <_l8g>;
+ vdda-pll-supply = <_l3g>;
+};
+
+_dp3 {
+ status = "okay";
+
+ data-lanes = <0 1 2 3>;
+
+ ports {
+ port@1 {
+ reg = <1>;
+ mdss0_dp3_phy_out: endpoint {
+ remote-endpoint = <_connector_in>;
+ };
+ };
+ };
+};
+
+_dp3_phy {
+ status = "okay";
+
+ vdda-phy-supply = <_l8g>;
+ vdda-pll-supply = <_l3g>;
+};
+
+ {
+ status = "okay";
+};
[PATCH v3 07/12] drm/msm/dp: Implement hpd_notify()
From: Bjorn Andersson
The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
physical signal on a GPIO pin into the controller. This is not always
possible, either because there aren't dedicated GPIOs available or
because the hot-plug signal is a virtual notification, in cases such as
USB Type-C.
For these cases, by implementing the hpd_notify() callback for the
DisplayPort controller's drm_bridge, a downstream drm_bridge
(next_bridge) can be used to track and signal the connection status
changes.
This makes it possible to use downstream drm_bridges such as
display-connector or any virtual mechanism, as long as they are
implemented as a drm_bridge.
Signed-off-by: Bjorn Andersson
[bjorn: Drop connector->fwnode assignment and dev from struct msm_dp]
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Fixed spelling of "on a GPIO" in commit message
drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
drivers/gpu/drm/msm/dp/dp_drm.c | 1 +
drivers/gpu/drm/msm/dp/dp_drm.h | 2 ++
3 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 699f28f2251e..a4563a0753b0 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1765,3 +1765,25 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
dp_display->dp_mode.h_active_low =
!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
}
+
+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status)
+{
+ struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
+ struct msm_dp *dp_display = dp_bridge->dp_display;
+ struct dp_display_private *dp = container_of(dp_display, struct
dp_display_private, dp_display);
+
+ /* Without next_bridge interrupts are handled by the DP core directly */
+ if (!dp_display->next_bridge)
+ return;
+
+ if (!dp->core_initialized) {
+ drm_dbg_dp(dp->drm_dev, "not initialized\n");
+ return;
+ }
+
+ if (!dp_display->is_connected && status == connector_status_connected)
+ dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
+ else if (dp_display->is_connected && status ==
connector_status_disconnected)
+ dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
+}
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 6df25f7662e7..1a02ec029fdd 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -68,6 +68,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
.mode_valid = dp_bridge_mode_valid,
.get_modes= dp_bridge_get_modes,
.detect = dp_bridge_detect,
+ .hpd_notify = dp_bridge_hpd_notify,
};
struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device
*dev,
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
index 82035dbb0578..79e6b2cf2d25 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -32,5 +32,7 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge
*bridge,
void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
const struct drm_display_mode *mode,
const struct drm_display_mode *adjusted_mode);
+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status);
#endif /* _DP_DRM_H_ */
--
2.37.3
[PATCH v3 11/12] arm64: dts: qcom: sc8280xp-crd: Enable EDP
From: Bjorn Andersson
The SC8280XP CRD has a EDP display on MDSS0 DP3, enable relevant nodes
and link it together with the backlight control.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch on list
arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 49 ++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
index 07e80dfe575d..bc906bcb26a4 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
@@ -20,7 +20,7 @@ aliases {
serial0 = _uart17;
};
- backlight {
+ backlight: backlight {
compatible = "pwm-backlight";
pwms = <_lpg 3 100>;
enable-gpios = <_1_gpios 8 GPIO_ACTIVE_HIGH>;
@@ -184,6 +184,53 @@ vreg_l9d: ldo9 {
};
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_dp3 {
+ compatible = "qcom,sc8280xp-edp";
+ status = "okay";
+
+ data-lanes = <0 1 2 3>;
+
+ aux-bus {
+ panel {
+ compatible = "edp-panel";
+
+ backlight = <>;
+
+ ports {
+ port {
+ edp_panel_in: endpoint {
+ remote-endpoint =
<_dp3_out>;
+ };
+ };
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ reg = <1>;
+ mdss0_dp3_out: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
+};
+
+_dp3_phy {
+ status = "okay";
+
+ vdda-phy-supply = <_l6b>;
+ vdda-pll-supply = <_l3b>;
+};
+
_lpg {
status = "okay";
};
--
2.37.3
[PATCH v3 03/12] dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles
From: Bjorn Andersson Add compatibles for the DisplayPort and Embedded DisplayPort blocks in Qualcomm SDM845 and SC8280XP platforms. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Acked-by: Krzysztof Kozlowski --- Changes since v2: - None .../devicetree/bindings/display/msm/dp-controller.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index f2515af8256f..a1dc3a13e1cf 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -21,6 +21,9 @@ properties: - qcom,sc7280-edp - qcom,sc8180x-dp - qcom,sc8180x-edp + - qcom,sc8280xp-dp + - qcom,sc8280xp-edp + - qcom,sdm845-dp - qcom,sm8350-dp reg: -- 2.37.3
[PATCH v3 08/12] drm/msm/dp: Don't enable HPD interrupts for edp
From: Bjorn Andersson Most instances where HPD interrupts are masked and unmasked are guareded by the presence of an EDP panel being connected, but not all. Extend this to cover the last few places, as HPD interrupt handling is not used for the EDP case. Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Signed-off-by: Bjorn Andersson --- Changes since v2: - None drivers/gpu/drm/msm/dp/dp_display.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index a4563a0753b0..3d365950de0f 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -610,8 +610,10 @@ static int dp_hpd_plug_handle(struct dp_display_private *dp, u32 data) } /* enable HDP irq_hpd/replug interrupt */ - dp_catalog_hpd_config_intr(dp->catalog, - DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true); + if (!dp->dp_display.is_edp) + dp_catalog_hpd_config_intr(dp->catalog, + DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, + true); drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n", dp->dp_display.connector_type, state); @@ -651,8 +653,10 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) dp->dp_display.connector_type, state); /* disable irq_hpd/replug interrupts */ - dp_catalog_hpd_config_intr(dp->catalog, - DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false); + if (!dp->dp_display.is_edp) + dp_catalog_hpd_config_intr(dp->catalog, + DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, + false); /* unplugged, no more irq_hpd handle */ dp_del_event(dp, EV_IRQ_HPD_INT); @@ -678,7 +682,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) } /* disable HPD plug interrupts */ - dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false); + if (!dp->dp_display.is_edp) + dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false); /* * We don't need separate work for disconnect as -- 2.37.3
[PATCH v3 09/12] drm/msm/dp: HPD handling relates to next_bridge
From: Bjorn Andersson The DisplayPort controller's internal HPD interrupt handling is used for cases where the HPD signal is connected to a GPIO which is pinmuxed into the DisplayPort controller. Most of the logic for enabling and disabling the HPD-related interrupts is conditioned on the presence of an EDP panel, but more generically designs that has a downstream drm_bridge (next_bridge) could use this to handle the HPD interrupts, instead of the internal mechanism. So replace the current is_edp-based guards with a check for the presence of next_bridge. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson --- Changes since v2: - None drivers/gpu/drm/msm/dp/dp_display.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 3d365950de0f..224ae3aa07c4 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -610,7 +610,7 @@ static int dp_hpd_plug_handle(struct dp_display_private *dp, u32 data) } /* enable HDP irq_hpd/replug interrupt */ - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true); @@ -653,7 +653,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) dp->dp_display.connector_type, state); /* disable irq_hpd/replug interrupts */ - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false); @@ -682,7 +682,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) } /* disable HPD plug interrupts */ - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false); /* @@ -701,7 +701,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) dp_display_handle_plugged_change(>dp_display, false); /* enable HDP plug interrupt to prepare for next plugin */ - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, true); drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n", @@ -1086,8 +1086,8 @@ static void dp_display_config_hpd(struct dp_display_private *dp) dp_display_host_init(dp); dp_catalog_ctrl_hpd_config(dp->catalog); - /* Enable plug and unplug interrupts only for external DisplayPort */ - if (!dp->dp_display.is_edp) + /* Enable plug and unplug interrupts only if not handled by next_bridge */ + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK | DP_DP_HPD_UNPLUG_INT_MASK, @@ -1379,8 +1379,7 @@ static int dp_pm_resume(struct device *dev) dp_catalog_ctrl_hpd_config(dp->catalog); - - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK | DP_DP_HPD_UNPLUG_INT_MASK, -- 2.37.3
[PATCH v3 02/12] drm/msm/dpu: Introduce SC8280XP
From: Bjorn Andersson
The Qualcomm SC8280XP platform contains DPU version 8.0.0, has 9
interfaces, 2 DSI controllers and 4 DisplayPort controllers. Extend the
necessary definitions and describe the DPU in the SC8280XP.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Change since v2:
- Dropped flag for hole in TOP
- Wrapped some lines to make checkpatch happier
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 217 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
drivers/gpu/drm/msm/msm_mdss.c| 2 +
8 files changed, 245 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 27f029fdc682..9964814be27a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -79,6 +79,8 @@
#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
+#define INTF_SC8280XP_MASK BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE) |
BIT(DPU_DATA_HCTL_EN)
+
#define IRQ_SDM845_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
BIT(MDP_SSPP_TOP0_INTR2) | \
BIT(MDP_SSPP_TOP0_HIST_INTR) | \
@@ -124,6 +126,19 @@
BIT(MDP_AD4_0_INTR) | \
BIT(MDP_AD4_1_INTR))
+#define IRQ_SC8280XP_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
+ BIT(MDP_SSPP_TOP0_INTR2) | \
+ BIT(MDP_SSPP_TOP0_HIST_INTR) | \
+ BIT(MDP_INTF0_7xxx_INTR) | \
+ BIT(MDP_INTF1_7xxx_INTR) | \
+ BIT(MDP_INTF2_7xxx_INTR) | \
+ BIT(MDP_INTF3_7xxx_INTR) | \
+ BIT(MDP_INTF4_7xxx_INTR) | \
+ BIT(MDP_INTF5_7xxx_INTR) | \
+ BIT(MDP_INTF6_7xxx_INTR) | \
+ BIT(MDP_INTF7_7xxx_INTR) | \
+ BIT(MDP_INTF8_7xxx_INTR))
+
#define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
BIT(DPU_WB_UBWC) | \
BIT(DPU_WB_YUV_CONFIG) | \
@@ -350,6 +365,20 @@ static const struct dpu_caps sc8180x_dpu_caps = {
.max_vdeci_exp = MAX_VERT_DECIMATION,
};
+static const struct dpu_caps sc8280xp_dpu_caps = {
+ .max_mixer_width = 2560,
+ .max_mixer_blendstages = 11,
+ .qseed_type = DPU_SSPP_SCALER_QSEED3LITE,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
+ .ubwc_version = DPU_HW_UBWC_VER_40,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 5120,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_caps sm8250_dpu_caps = {
.max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.max_mixer_blendstages = 0xb,
@@ -472,6 +501,24 @@ static const struct dpu_mdp_cfg sc8180x_mdp[] = {
},
};
+static const struct dpu_mdp_cfg sc8280xp_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = { .reg_off = 0x2bc, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = { .reg_off = 0x2c4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20},
+ },
+};
+
static const struct dpu_mdp_cfg sm8250_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -620,6 +667,45 @@ static const struct dpu_ctl_cfg sc7180_ctl[] = {
},
};
+static const struct dpu_ctl_cfg sc8280xp_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x15000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x16000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ },
+ {
+ .name = "ctl_2", .id = CTL_2,
[PATCH v3 10/12] arm64: dts: qcom: sc8280xp: Define some of the display blocks
From: Bjorn Andersson
Define the display clock controllers, the MDSS instances, the DP phys
and connect these together.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch on list
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 838 +
1 file changed, 838 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index ed806a6e20f6..8526ed74b7be 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -4,6 +4,7 @@
* Copyright (c) 2022, Linaro Limited
*/
+#include
#include
#include
#include
@@ -1245,6 +1246,44 @@ usb_1_ssphy: usb3-phy@8903400 {
};
};
+ mdss1_dp0_phy: phy@8909a00 {
+ compatible = "qcom,sc8280xp-dp-phy";
+ reg = <0 0x08909a00 0 0x19c>,
+ <0 0x08909200 0 0xec>,
+ <0 0x08909600 0 0xec>,
+ <0 0x08909000 0 0x1c8>;
+
+ clocks = < DISP_CC_MDSS_DPTX0_AUX_CLK>,
+< DISP_CC_MDSS_AHB_CLK>;
+ clock-names = "aux", "cfg_ahb";
+
+ power-domains = < SC8280XP_MX>;
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ mdss1_dp1_phy: phy@890ca00 {
+ compatible = "qcom,sc8280xp-dp-phy";
+ reg = <0 0x0890ca00 0 0x19c>,
+ <0 0x0890c200 0 0xec>,
+ <0 0x0890c600 0 0xec>,
+ <0 0x0890c000 0 0x1c8>;
+
+ clocks = < DISP_CC_MDSS_DPTX1_AUX_CLK>,
+< DISP_CC_MDSS_AHB_CLK>;
+ clock-names = "aux", "cfg_ahb";
+
+ power-domains = < SC8280XP_MX>;
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
system-cache-controller@920 {
compatible = "qcom,sc8280xp-llcc";
reg = <0 0x0920 0 0x58000>, <0 0x0960 0
0x58000>;
@@ -1360,6 +1399,326 @@ usb_1_dwc3: usb@a80 {
};
};
+ mdss0: display-subsystem@ae0 {
+ compatible = "qcom,sc8280xp-mdss";
+ reg = <0 0x0ae0 0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < GCC_DISP_AHB_CLK>,
+< DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "ahb",
+ "core";
+
+ resets = < DISP_CC_MDSS_CORE_BCR>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <_noc MASTER_MDP0 0 _virt
SLAVE_EBI1 0>,
+ <_noc MASTER_MDP1 0 _virt
SLAVE_EBI1 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ iommus = <_smmu 0x1000 0x402>;
+
+ status = "disabled";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ mdss0_mdp: display-controller@ae01000 {
+ compatible = "qcom,sc8280xp-dpu";
+ reg = <0 0x0ae01000 0 0x8f000>,
+ <0 0x0aeb 0 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = < GCC_DISP_HF_AXI_CLK>,
+< GCC_DISP_SF_AXI_CLK>,
+< DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_MDP_LUT_CLK>,
+< DISP_CC_MDSS_MDP_CLK>,
+< DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <
DISP_CC_MDSS_MDP_CLK>,
+ <
DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <46000>,
+
[PATCH v3 06/12] drm/msm/dp: Add SDM845 DisplayPort instance
From: Bjorn Andersson
The Qualcomm SDM845 platform has a single DisplayPort controller, with
the same design as SC7180, so add support for this by reusing the SC7180
definition.
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
drivers/gpu/drm/msm/dp/dp_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e4a83c2cd972..699f28f2251e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -178,6 +178,7 @@ static const struct of_device_id dp_dt_match[] = {
{ .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
{ .compatible = "qcom,sc8280xp-dp", .data = _dp_descs },
{ .compatible = "qcom,sc8280xp-edp", .data = _edp_descs },
+ { .compatible = "qcom,sdm845-dp", .data = _dp_descs },
{ .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
--
2.37.3
[PATCH v3 05/12] drm/msm/dp: Add DP and EDP compatibles for SC8280XP
From: Bjorn Andersson
The SC8280XP platform has four DisplayPort controllers, per MDSS
instance, all with widebus support.
The first two are defined to be DisplayPort only, while the latter pair
(of each instance) can be either DisplayPort or Embedded DisplayPort.
The two sets are tied to the possible compatibels.
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 2d9bbc335786..e4a83c2cd972 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -145,6 +145,26 @@ static const struct msm_dp_desc sc8180x_dp_descs[] = {
{}
};
+static const struct msm_dp_desc sc8280xp_dp_descs[] = {
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x2209, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x22098000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ {}
+};
+
+static const struct msm_dp_desc sc8280xp_edp_descs[] = {
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ {}
+};
+
static const struct msm_dp_desc sm8350_dp_descs[] = {
{ .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
{}
@@ -156,6 +176,8 @@ static const struct of_device_id dp_dt_match[] = {
{ .compatible = "qcom,sc7280-edp", .data = _dp_descs },
{ .compatible = "qcom,sc8180x-dp", .data = _dp_descs },
{ .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
+ { .compatible = "qcom,sc8280xp-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc8280xp-edp", .data = _edp_descs },
{ .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
--
2.37.3
[PATCH v3 00/12] drm/msm: Add SC8280XP support
This introduces support for the SC8280XP platform in the MDSS, DPU and DP driver. It reworks the HDP handling in the DP driver to support external HPD sources - such as the dp-connector, or USB Type-C altmode. It then introduces the display clock controllers, mdss, dpu and displayport controllers and link everything together, for both the MDSS instances on the platform, and lastly enables EDP on the compute reference device and 6 of the MiniDP outputs on the automotive development platform. The patches was previously sent separately, but submitting them together here as they (except dts addition) goes in the same tree. Bjorn Andersson (12): dt-bindings: display/msm: Add binding for SC8280XP MDSS drm/msm/dpu: Introduce SC8280XP dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles drm/msm/dp: Stop using DP id as index in desc drm/msm/dp: Add DP and EDP compatibles for SC8280XP drm/msm/dp: Add SDM845 DisplayPort instance drm/msm/dp: Implement hpd_notify() drm/msm/dp: Don't enable HPD interrupts for edp drm/msm/dp: HPD handling relates to next_bridge arm64: dts: qcom: sc8280xp: Define some of the display blocks arm64: dts: qcom: sc8280xp-crd: Enable EDP arm64: dts: qcom: sa8295-adp: Enable DP instances .../bindings/display/msm/dp-controller.yaml | 3 + .../bindings/display/msm/dpu-sc8280xp.yaml| 287 ++ arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 244 - arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 49 +- arch/arm64/boot/dts/qcom/sc8280xp.dtsi| 838 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 217 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 + .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 + .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 3 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 + drivers/gpu/drm/msm/dp/dp_display.c | 135 +-- drivers/gpu/drm/msm/dp/dp_drm.c | 1 + drivers/gpu/drm/msm/dp/dp_drm.h | 2 + drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_mdss.c| 2 + 16 files changed, 1747 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml -- 2.37.3
[PATCH v3 04/12] drm/msm/dp: Stop using DP id as index in desc
From: Bjorn Andersson
In the SC8280XP platform there are two identical MDSS instances, each
with the same set of DisplayPort instances, at different addresses.
By not relying on the index to define the instance id it's possible to
describe them both in the same table and hence have a single compatible.
While at it, flatten the cfg/desc structure so that the match data is
just an array of descs.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
drivers/gpu/drm/msm/dp/dp_display.c | 72 ++---
1 file changed, 25 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aeff3f0d..2d9bbc335786 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -122,61 +122,41 @@ struct dp_display_private {
struct msm_dp_desc {
phys_addr_t io_start;
+ unsigned int id;
unsigned int connector_type;
bool wide_bus_en;
};
-struct msm_dp_config {
- const struct msm_dp_desc *descs;
- size_t num_descs;
-};
-
static const struct msm_dp_desc sc7180_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
-};
-
-static const struct msm_dp_config sc7180_dp_cfg = {
- .descs = sc7180_dp_descs,
- .num_descs = ARRAY_SIZE(sc7180_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ {}
};
static const struct msm_dp_desc sc7280_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- [MSM_DP_CONTROLLER_1] = { .io_start = 0x0aea, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
-};
-
-static const struct msm_dp_config sc7280_dp_cfg = {
- .descs = sc7280_dp_descs,
- .num_descs = ARRAY_SIZE(sc7280_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ {}
};
static const struct msm_dp_desc sc8180x_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
- [MSM_DP_CONTROLLER_1] = { .io_start = 0x0ae98000, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
- [MSM_DP_CONTROLLER_2] = { .io_start = 0x0ae9a000, .connector_type =
DRM_MODE_CONNECTOR_eDP },
-};
-
-static const struct msm_dp_config sc8180x_dp_cfg = {
- .descs = sc8180x_dp_descs,
- .num_descs = ARRAY_SIZE(sc8180x_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP },
+ {}
};
static const struct msm_dp_desc sm8350_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
-};
-
-static const struct msm_dp_config sm8350_dp_cfg = {
- .descs = sm8350_dp_descs,
- .num_descs = ARRAY_SIZE(sm8350_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ {}
};
static const struct of_device_id dp_dt_match[] = {
- { .compatible = "qcom,sc7180-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc7280-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc7280-edp", .data = _dp_cfg },
- { .compatible = "qcom,sc8180x-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc8180x-edp", .data = _dp_cfg },
- { .compatible = "qcom,sm8350-dp", .data = _dp_cfg },
+ { .compatible = "qcom,sc7180-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc7280-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc7280-edp", .data = _dp_descs },
+ { .compatible = "qcom,sc8180x-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
+ { .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
@@ -1262,10 +1242,9 @@ int dp_display_request_irq(struct msm_dp *dp_display)
return 0;
}
-static const struct msm_dp_desc *dp_display_get_desc(struct platform_device
*pdev,
-unsigned int *id)
+static const struct msm_dp_desc *dp_display_get_desc(struct platform_device
*pdev)
{
- const struct msm_dp_config *cfg = of_device_get_match_data(>dev);
+ const struct msm_dp_desc *descs = of_device_get_match_data(>dev);
struct resource *res;
int i;
@@ -1273,11
[PATCH v3 01/12] dt-bindings: display/msm: Add binding for SC8280XP MDSS
From: Bjorn Andersson
Add binding for the display subsystem and display processing unit in the
Qualcomm SC8280XP platform.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Cleaned up description and interconnect definitions
- Added opp-table
.../bindings/display/msm/dpu-sc8280xp.yaml| 287 ++
1 file changed, 287 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
new file mode 100644
index ..24e7a1562fe7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
@@ -0,0 +1,287 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dpu-sc8280xp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Processing Unit for SC8280XP
+
+maintainers:
+ - Bjorn Andersson
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem (MDSS) that
encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc.
+
+properties:
+ compatible:
+const: qcom,sc8280xp-mdss
+
+ reg:
+maxItems: 1
+
+ reg-names:
+const: mdss
+
+ power-domains:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock
+
+ clock-names:
+items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ interrupts:
+maxItems: 1
+
+ interrupt-controller: true
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+ "#interrupt-cells":
+const: 1
+
+ iommus:
+items:
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail
port0
+
+ ranges: true
+
+ interconnects:
+items:
+ - description: Interconnect path for first data bus
+ - description: Interconnect path for second data bus
+
+ interconnect-names:
+items:
+ - const: mdp0-mem
+ - const: mdp1-mem
+
+ resets:
+items:
+ - description: MDSS_CORE reset
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+description: Node containing the properties of DPU.
+additionalProperties: false
+
+properties:
+ compatible:
+const: qcom,sc8280xp-dpu
+
+ reg:
+items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+items:
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display ahb clock
+ - description: Display lut clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+items:
+ - const: bus
+ - const: nrt_bus
+ - const: iface
+ - const: lut
+ - const: core
+ - const: vsync
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ operating-points-v2: true
+ opp-table:
+type: object
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ Contains the list of output ports from DPU device. These ports
+ connect to interfaces that are external to the DPU hardware,
+ such as DSI, DP etc. Each output port contains an endpoint that
+ describes how it is connected to an external interface.
+
+patternProperties:
+ '^port@[0-8]$':
+$ref: /schemas/graph.yaml#/properties/port
+description: DPU interfaces
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - interrupts
+ - power-domains
+ - operating-points-v2
+ - ports
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - interrupts
+ - interrupt-controller
+ - iommus
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+display-subsystem@ae0 {
+ compatible = "qcom,sc8280xp-mdss";
+ reg = <0x0ae0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < GCC_DISP_AHB_CLK>,
+ < DISP_CC_MDSS_AHB_CLK>,
+ < DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+"ahb",
+"core";
+
+ assigned-clocks = < DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <46000>;
+
+ resets = < DISP_CC_MDSS_CORE_BCR>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+
[PATCH 2/2] drm/vmwgfx: Cleanup the cursor snooping code
From: Zack Rusin
Cursor snooping depended on implicit size and format which made debugging
quite difficult. Make the code easier to following by making everything
explicit and instead of using magic numbers predefine all the
parameters the code depends on.
Also fixes incorrectly computed pitches for non-aligned cursor snoops.
Fix which has no practical effect because non-aligned cursor snoops
are not used by the X11 driver and Wayland cursors will go through
mob cursors, instead of surface dma's.
Signed-off-by: Zack Rusin
Reviewed-by: Michael Banack
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 29 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 14 +++-
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 4eb7339dd121..b062b020b378 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -98,6 +98,10 @@
#define VMW_RES_SHADER ttm_driver_type4
#define VMW_RES_HT_ORDER 12
+#define VMW_CURSOR_SNOOP_FORMAT SVGA3D_A8R8G8B8
+#define VMW_CURSOR_SNOOP_WIDTH 64
+#define VMW_CURSOR_SNOOP_HEIGHT 64
+
#define MKSSTAT_CAPACITY_LOG2 5U
#define MKSSTAT_CAPACITY (1U << MKSSTAT_CAPACITY_LOG2)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index d434b6ae1092..257f090071f1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -25,6 +25,9 @@
*
**/
+#include "vmwgfx_kms.h"
+#include "vmw_surface_cache.h"
+
#include
#include
#include
@@ -32,8 +35,6 @@
#include
#include
-#include "vmwgfx_kms.h"
-
void vmw_du_cleanup(struct vmw_display_unit *du)
{
struct vmw_private *dev_priv = vmw_priv(du->primary.dev);
@@ -351,7 +352,6 @@ static void vmw_cursor_update_position(struct vmw_private
*dev_priv,
spin_unlock(_priv->cursor_lock);
}
-
void vmw_kms_cursor_snoop(struct vmw_surface *srf,
struct ttm_object_file *tfile,
struct ttm_buffer_object *bo,
@@ -369,6 +369,9 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
SVGA3dCmdSurfaceDMA dma;
} *cmd;
int i, ret;
+ const struct SVGA3dSurfaceDesc *desc =
+ vmw_surface_get_desc(VMW_CURSOR_SNOOP_FORMAT);
+ const u32 image_pitch = VMW_CURSOR_SNOOP_WIDTH *
desc->pitchBytesPerBlock;
cmd = container_of(header, struct vmw_dma_cmd, header);
@@ -394,7 +397,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
box->x != 0|| box->y != 0|| box->z != 0||
box->srcx != 0 || box->srcy != 0 || box->srcz != 0 ||
box->d != 1|| box_count != 1 ||
- box->w > 64 || box->h > 64) {
+ box->w > VMW_CURSOR_SNOOP_WIDTH || box->h >
VMW_CURSOR_SNOOP_HEIGHT) {
/* TODO handle none page aligned offsets */
/* TODO handle more dst & src != 0 */
/* TODO handle more then one copy */
@@ -408,7 +411,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
}
kmap_offset = cmd->dma.guest.ptr.offset >> PAGE_SHIFT;
- kmap_num = (64*64*4) >> PAGE_SHIFT;
+ kmap_num = (VMW_CURSOR_SNOOP_HEIGHT*image_pitch) >> PAGE_SHIFT;
ret = ttm_bo_reserve(bo, true, false, NULL);
if (unlikely(ret != 0)) {
@@ -422,14 +425,15 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
virtual = ttm_kmap_obj_virtual(, );
- if (box->w == 64 && cmd->dma.guest.pitch == 64*4) {
- memcpy(srf->snooper.image, virtual, 64*64*4);
+ if (box->w == VMW_CURSOR_SNOOP_WIDTH && cmd->dma.guest.pitch ==
image_pitch) {
+ memcpy(srf->snooper.image, virtual,
+ VMW_CURSOR_SNOOP_HEIGHT*image_pitch);
} else {
/* Image is unsigned pointer. */
for (i = 0; i < box->h; i++)
- memcpy(srf->snooper.image + i * 64,
+ memcpy(srf->snooper.image + i * image_pitch,
virtual + i * cmd->dma.guest.pitch,
- box->w * 4);
+ box->w * desc->pitchBytesPerBlock);
}
srf->snooper.age++;
@@ -480,7 +484,8 @@ void vmw_kms_cursor_post_execbuf(struct vmw_private
*dev_priv)
du->cursor_age = du->cursor_surface->snooper.age;
vmw_send_define_cursor_cmd(dev_priv,
du->cursor_surface->snooper.image,
- 64, 64,
+ VMW_CURSOR_SNOOP_WIDTH,
+ VMW_CURSOR_SNOOP_HEIGHT,
du->hotspot_x + du->core_hotspot_x,
[PATCH 1/2] drm/vmwgfx: Validate the box size for the snooped cursor
From: Zack Rusin
Invalid userspace dma surface copies could potentially overflow
the memcpy from the surface to the snooped image leading to crashes.
To fix it the dimensions of the copybox have to be validated
against the expected size of the snooped cursor.
Signed-off-by: Zack Rusin
Fixes: 2ac863719e51 ("vmwgfx: Snoop DMA transfers with non-covering sizes")
Cc: # v3.2+
Reviewed-by: Michael Banack
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 0342efdf9063..d434b6ae1092 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -393,7 +393,8 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
if (cmd->dma.guest.ptr.offset % PAGE_SIZE ||
box->x != 0|| box->y != 0|| box->z != 0||
box->srcx != 0 || box->srcy != 0 || box->srcz != 0 ||
- box->d != 1|| box_count != 1) {
+ box->d != 1|| box_count != 1 ||
+ box->w > 64 || box->h > 64) {
/* TODO handle none page aligned offsets */
/* TODO handle more dst & src != 0 */
/* TODO handle more then one copy */
--
2.34.1
Re: [PATCH v2 0/8] Fix several device private page reference counting issues
"Vlastimil Babka (SUSE)" writes: > On 9/28/22 14:01, Alistair Popple wrote: >> This series aims to fix a number of page reference counting issues in >> drivers dealing with device private ZONE_DEVICE pages. These result in >> use-after-free type bugs, either from accessing a struct page which no >> longer exists because it has been removed or accessing fields within the >> struct page which are no longer valid because the page has been freed. >> >> During normal usage it is unlikely these will cause any problems. However >> without these fixes it is possible to crash the kernel from userspace. >> These crashes can be triggered either by unloading the kernel module or >> unbinding the device from the driver prior to a userspace task exiting. In >> modules such as Nouveau it is also possible to trigger some of these issues >> by explicitly closing the device file-descriptor prior to the task exiting >> and then accessing device private memory. > > Hi, as this series was noticed to create a CVE [1], do you think a stable > backport is warranted? I think the "It is possible to launch the attack > remotely." in [1] is incorrect though, right? Right, I don't see how this could be exploited remotely. And I'm pretty sure you need root as well because in practice the pgmap needs to be freed, and for Nouveau at least that only happens on device removal. > It looks to me that patch 1 would be needed since the CONFIG_DEVICE_PRIVATE > introduction, while the following few only to kernels with 27674ef6c73f > (probably not so critical as that includes no LTS)? Patch 3 already has a fixes tag for 27674ef6c73f. Patch 1 would need to go back to CONFIG_DEVICE_PRIVATE introduction. I think patches 4-8 would also need to go back to introduction of CONFIG_DEVICE_PRIVATE, but there isn't as much impact there and they would be harder to backport I think. Without them device removal can loop indefinitely in kernel mode (if patch 3 is present or the kernel is older than 27674ef6c73f). - Alistair > Thanks, > Vlastimil > > [1] https://nvd.nist.gov/vuln/detail/CVE-2022-3523 > >> This involves some minor changes to both PowerPC and AMD GPU code. >> Unfortunately I lack hardware to test either of those so any help there >> would be appreciated. The changes mimic what is done in for both Nouveau >> and hmm-tests though so I doubt they will cause problems. >> >> To: Andrew Morton >> To: linux...@kvack.org >> Cc: linux-ker...@vger.kernel.org >> Cc: amd-...@lists.freedesktop.org >> Cc: nouv...@lists.freedesktop.org >> Cc: dri-devel@lists.freedesktop.org >> >> Alistair Popple (8): >> mm/memory.c: Fix race when faulting a device private page >> mm: Free device private pages have zero refcount >> mm/memremap.c: Take a pgmap reference on page allocation >> mm/migrate_device.c: Refactor migrate_vma and >> migrate_deivce_coherent_page() >> mm/migrate_device.c: Add migrate_device_range() >> nouveau/dmem: Refactor nouveau_dmem_fault_copy_one() >> nouveau/dmem: Evict device private memory during release >> hmm-tests: Add test for migrate_device_range() >> >> arch/powerpc/kvm/book3s_hv_uvmem.c | 17 +- >> drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 19 +- >> drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 2 +- >> drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 11 +- >> drivers/gpu/drm/nouveau/nouveau_dmem.c | 108 +++ >> include/linux/memremap.h | 1 +- >> include/linux/migrate.h | 15 ++- >> lib/test_hmm.c | 129 ++--- >> lib/test_hmm_uapi.h | 1 +- >> mm/memory.c | 16 +- >> mm/memremap.c| 30 ++- >> mm/migrate.c | 34 +-- >> mm/migrate_device.c | 239 +--- >> mm/page_alloc.c | 8 +- >> tools/testing/selftests/vm/hmm-tests.c | 49 +- >> 15 files changed, 516 insertions(+), 163 deletions(-) >> >> base-commit: 088b8aa537c2c767765f1c19b555f21ffe555786
[PATCH -next] drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()
./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but
dereferenced.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2549
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
change in v2:
According to Felix's suggestion, move the pr_debug up before the
kfd_unref_process
call.
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 20d6b2578927..b9c8d29d95aa 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -978,12 +978,10 @@ static vm_fault_t svm_migrate_to_ram(struct vm_fault *vmf)
out_unlock_svms:
mutex_unlock(>svms.lock);
out_unref_process:
+ pr_debug("CPU fault svms 0x%p address 0x%lx done\n", >svms, addr);
kfd_unref_process(p);
out_mmput:
mmput(mm);
-
- pr_debug("CPU fault svms 0x%p address 0x%lx done\n", >svms, addr);
-
return r ? VM_FAULT_SIGBUS : 0;
}
--
2.20.1.7.g153144c
Re: [PATCH] drm/i915/mtl: Handle wopcm per-GT and limit calculations.
On 10/24/2022 15:26, Daniele Ceraolo Spurio wrote:
From: Aravind Iddamsetty
With MTL standalone media architecture the wopcm layout has changed,
with separate partitioning in WOPCM for the root GT GuC and the media
GT GuC. The size of WOPCM is 4MB with the lower 2MB reserved for the
media GT and the upper 2MB for the root GT.
Given that MTL has GuC deprivilege, the WOPCM registers are pre-locked
by the bios. Therefore, we can skip all the math for the partitioning
and just limit ourselves to sanity-checking the values.
v2: fix makefile file ordering (Jani)
v3: drop XELPM_SAMEDIA_WOPCM_SIZE, check huc instead of VDBOX (John)
v4: further clarify commit message, remove blank line (John)
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: John Harrison
Cc: Alan Previn
Cc: Jani Nikula
Reviewed-by: John Harrison
---
Documentation/gpu/i915.rst | 2 +-
drivers/gpu/drm/i915/Makefile | 5 ++-
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c | 43 ++---
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h | 0
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 14 ---
drivers/gpu/drm/i915/i915_driver.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 3 --
drivers/gpu/drm/i915/i915_gem.c | 5 ++-
12 files changed, 51 insertions(+), 32 deletions(-)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c (87%)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h (100%)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 4e59db1cfb00..60ea21734902 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -494,7 +494,7 @@ WOPCM
WOPCM Layout
-.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_wopcm.c
:doc: WOPCM Layout
GuC
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2535593ab379..cf3a96b3cd58 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -127,9 +127,11 @@ gt-y += \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
+ gt/intel_wopcm.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
+
# x86 intel-gtt module support
gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
# autogenerated null render state
@@ -183,8 +185,7 @@ i915-y += \
i915_trace_points.o \
i915_ttm_buddy_manager.o \
i915_vma.o \
- i915_vma_resource.o \
- intel_wopcm.o
+ i915_vma_resource.o
# general-purpose microcontroller (GuC) support
i915-y += gt/uc/intel_uc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 6b58c95ad6a0..9263f10ecd28 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -560,7 +560,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* why.
*/
ggtt->pin_bias = max_t(u32, I915_GTT_PAGE_SIZE,
- intel_wopcm_guc_size(>vm.i915->wopcm));
+ intel_wopcm_guc_size(>vm.gt->wopcm));
ret = intel_vgt_balloon(ggtt);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 27dbb9e4bd6c..8c751314df3d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -56,6 +56,7 @@ void intel_gt_common_init_early(struct intel_gt *gt)
seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
intel_gt_pm_init_early(gt);
+ intel_wopcm_init_early(>wopcm);
intel_uc_init_early(>uc);
intel_rps_init_early(>rps);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 64aa2ba624fc..2d18fd9ab11f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -30,6 +30,7 @@
#include "intel_migrate_types.h"
#include "intel_wakeref.h"
#include "pxp/intel_pxp_types.h"
+#include "intel_wopcm.h"
struct drm_i915_private;
struct i915_ggtt;
@@ -100,6 +101,7 @@ struct intel_gt {
struct intel_uc uc;
struct intel_gsc gsc;
+ struct intel_wopcm wopcm;
struct {
/* Serialize global tlb invalidations */
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/gt/intel_wopcm.c
similarity index 87%
rename from drivers/gpu/drm/i915/intel_wopcm.c
rename to drivers/gpu/drm/i915/gt/intel_wopcm.c
index 322fb9eeb880..7ebbcc191c2d 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/gt/intel_wopcm.c
@@ -64,9 +64,9 @@
#define GEN9_GUC_FW_RESERVED SZ_128K
Re: [PATCH v3 2/7] drm/ivpu: Add Intel VPU MMU support
On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote:
VPU Memory Management Unit is based on ARM MMU-600.
It allows to create multiple virtual address spaces for the device and
"It allows the creation of"?
map noncontinuous host memory (there is no dedicated memory on the VPU).
Address space is implemented as a struct ivpu_mmu_context, it has an ID,
drm_mm allocator for VPU addresses and struct ivpu_mmu_pgtable that holds
actual 3-level, 4KB page table.
Context with ID 0 (global context) is created upon driver initialization
and it's mainly used for mapping memory required to execute
the firmware.
Contexts with non-zero IDs are user contexts allocated each time
the devices is open()-ed and they map command buffers and other
workload-related memory.
Workloads executing in a given contexts have access only
to the memory mapped in this context.
This patch is has to main files:
- ivpu_mmu_context.c handles MMU page tables and memory mapping
- ivpu_mmu.c implements a driver that programs the MMU device
Signed-off-by: Karol Wachowski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
So, this doesn't look valid. This indicates that Karol wrote this
patch, then it was handed off to Krystian, and then to you. However, if
that were the case, then the patch should be from Karol (which is then
the author in git). It is not. It is from you.
What I suspect is happening is that the three of you all co-authroed
this change. In that case, there should probably be Co-developed-by
tags in addition to SOB to make that clear.
Also, I missed this on the first patch I reviewed eariler, but it looks
to have the same issue.
---
drivers/gpu/drm/ivpu/Makefile | 4 +-
drivers/gpu/drm/ivpu/ivpu_drv.c | 59 +-
drivers/gpu/drm/ivpu/ivpu_drv.h | 7 +
drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 10 +
drivers/gpu/drm/ivpu/ivpu_mmu.c | 883
drivers/gpu/drm/ivpu/ivpu_mmu.h | 53 ++
drivers/gpu/drm/ivpu/ivpu_mmu_context.c | 419 +++
drivers/gpu/drm/ivpu/ivpu_mmu_context.h | 49 ++
include/uapi/drm/ivpu_drm.h | 4 +
9 files changed, 1485 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu.h
create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu_context.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu_context.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index e59dc65abe6a..95bb04f26296 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -3,6 +3,8 @@
intel_vpu-y := \
ivpu_drv.o \
- ivpu_hw_mtl.o
+ ivpu_hw_mtl.o \
+ ivpu_mmu.o \
+ ivpu_mmu_context.o
obj-$(CONFIG_DRM_IVPU) += intel_vpu.o
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index a01c7244f6e5..cbeb9a801a31 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -14,6 +14,8 @@
#include "ivpu_drv.h"
#include "ivpu_hw.h"
+#include "ivpu_mmu.h"
+#include "ivpu_mmu_context.h"
#ifndef DRIVER_VERSION_STR
#define DRIVER_VERSION_STR __stringify(DRM_IVPU_DRIVER_MAJOR) "." \
@@ -50,6 +52,11 @@ char *ivpu_platform_to_str(u32 platform)
void ivpu_file_priv_get(struct ivpu_file_priv *file_priv, struct ivpu_file_priv **link)
{
+ struct ivpu_device *vdev = file_priv->vdev;
+
+ ivpu_dbg(KREF, "file_priv get: ctx %u refcount %u\n",
+file_priv->ctx.id, kref_read(_priv->ref));
+
kref_get(_priv->ref);
*link = file_priv;
}
This hunk doesn't appear related to $SUBJECT. It looks like it would
fit better as part of patch 1.
@@ -57,6 +64,12 @@ void ivpu_file_priv_get(struct ivpu_file_priv *file_priv,
struct ivpu_file_priv
static void file_priv_release(struct kref *ref)
{
struct ivpu_file_priv *file_priv = container_of(ref, struct
ivpu_file_priv, ref);
+ struct ivpu_device *vdev = file_priv->vdev;
Why do we need this? It doesn't appear to be used at this time. If it
is needed later in the series, add it then.
+
+ ivpu_dbg(FILE, "file_priv release: ctx %u\n", file_priv->ctx.id);
+
+ if (file_priv->ctx.id)
+ ivpu_mmu_user_context_fini(file_priv);
kfree(file_priv);
}
@@ -64,6 +77,10 @@ static void file_priv_release(struct kref *ref)
void ivpu_file_priv_put(struct ivpu_file_priv **link)
{
struct ivpu_file_priv *file_priv = *link;
+ struct ivpu_device *vdev = file_priv->vdev;
+
+ ivpu_dbg(KREF, "file_priv put: ctx %u refcount %u\n",
+file_priv->ctx.id, kref_read(_priv->ref));
vdev doesn't appear to be used, and the log message doesn't appear
related to $SUBJECT
*link = NULL;
kref_put(_priv->ref, file_priv_release);
@@ -75,7 +92,11 @@ static int ivpu_get_param_ioctl(struct drm_device *dev, void
*data, struct drm_f
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote:
> this code should actually set the ACPI_VIDEO_BACKLIGHT flag:
> drivers/acpi/scan.c:
>
> static acpi_status
> acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
> void **return_value)
> {
> long *cap = context;
>
> if (acpi_has_method(handle, "_BCM") &&
> acpi_has_method(handle, "_BCL")) {
> acpi_handle_debug(handle, "Found generic backlight
> support\n");
> *cap |= ACPI_VIDEO_BACKLIGHT;
> /* We have backlight support, no need to scan further */
> return AE_CTRL_TERMINATE;
> }
> return 0;
> }
Ah, yeah, my local tree no longer matches the upstream behaviour because
I've hacked the EC firmware to remove the backlight trigger because it
had an extremely poor brightness curve and also automatically changed it
on AC events - as a result I removed the backlight code from the DSDT
and just fell back to the native control. Like I said I'm a long way
from the normal setup, but this did previously work.
The "right" logic here seems pretty simple: if ACPI backlight control is
expected to work, use it. If it isn't, but there's a vendor interface,
use it. If there's no vendor interface, use the native interface. The
problem you're dealing with is that the knowledge of whether or not
there's a vendor interface isn't something the core kernel code knows
about. What you're proposing here is effectively for us to expose
additional information about whether or not there's a vendor interface
in the system firmware, but since we're talking in some cases about
hardware that's almost 20 years old, we're not realistically going to
get those old machines fixed. So, it feels like there's two choices:
1) Make a default policy decision, but then allow that decision to be
altered later on (eg, when a vendor-specific platform driver has been
loaded) - you've said this poses additional complexities.
2) Move the knowledge of whether or not there's a vendor interface into
the core code. Basically take every platform driver that exposes a
vendor interface, and move the detection code into the core.
I think any other approach is going to result in machines that
previously worked no longer working (and you can't just make the
vendor/native split dependent on the Coreboot DMI BIOS string, because
there are some Coreboot platforms that implement the vendor interface
for compatibility, and you also can't ask all Coreboot users to update
their firmware to fix things)
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi,
On 10/25/22 22:40, Matthew Garrett wrote:
> On Tue, Oct 25, 2022 at 10:25:33PM +0200, Hans de Goede wrote:
>
>> Having the native driver come and then go and be replaced
>> with the vendor driver would also be quite inconvenient
>> for these planned changes.
>
> I understand that it would be inconvenient, but you've broken existing
> working setups.
I fully acknowledge that I have broken existing working setups
and I definitely want to see this fixed before say 6.1-rc6!
I'm not convinced (at all) that any solutions which re-introduce
acpi_video_get_backlight_type() return-s value changing
half way the boot, with some backlight interface getting
registered and then unregistered again later because
it turns out to be the wrong one is a good fix here.
The whole goal of the refactor was to leave these sorts
of shenanigans behind us.
>> Can you perhaps explain a bit in what way your laptop
>> is weird ?
>
> It's a Chinese replacement motherboard for a Thinkpad X201, running my
> own port of Coreboot. Its DMI strings look like an actual Thinkpad in
> order to ensure that thinkpad_acpi can bind for hotkey suport, so it's
> hard to quirk. It'll actually be fixed by your proposed patch to fall
> back to native rather than vendor, but that patch will break any older
> machines that offer a vendor interface and don't have the native control
> hooked up (pretty sure at least the Thinkpad X40 falls into that
> category).
So looking at:
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/mainboard/51nb/x210/acpi/graphics.asl
this code should actually set the ACPI_VIDEO_BACKLIGHT flag:
drivers/acpi/scan.c:
static acpi_status
acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
void **return_value)
{
long *cap = context;
if (acpi_has_method(handle, "_BCM") &&
acpi_has_method(handle, "_BCL")) {
acpi_handle_debug(handle, "Found generic backlight support\n");
*cap |= ACPI_VIDEO_BACKLIGHT;
/* We have backlight support, no need to scan further */
return AE_CTRL_TERMINATE;
}
return 0;
}
What does seem to be missing compared to a "normal" DSDT
is a call to _OSI("Windows 2012") so I would expect this code
in acpi_video_get_backlight_type():
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
* Windows 8 and newer no longer use the ACPI video interface,
* so it often does not work. If the ACPI tables are written
* for win8 and native brightness ctl is available, use that.
*
* The native check deliberately is inside the if acpi-video
* block on older devices without acpi-video support native
* is usually not the best choice.
*/
if (acpi_osi_is_win8() && native_available)
return acpi_backlight_native;
else
return acpi_backlight_video;
}
To enter the "return acpi_backlight_video" path since acpi_osi_is_win8()
will return false.
And then the ACPI backlight methods from:
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/mainboard/51nb/x210/acpi/graphics.asl
should get called when changing the backlight brightness,
so assuming that those methods work then things should work fine.
What does "ls /sys/class/backlight" output on the X210 / NB51 board
with a 6.0 kernel? And what does it output with the 6.1-rc? kernels?
IOW which backlight device / control method is being selected
and which one do you want / which one(s) do actually work?
I have been thinking about maybe doing something with
a dmi_get_bios_year() check (see below), but that will cause
native to get prefered over vendor on old ThinkPads with
coreboot (and thus a new enough year in DMI_BIOS_DATE), which
will likely break backlight control there (if i915 offers
backlight control on those that is).
Also I wonder if it would be possible to set DMI_BIOS_VENDOR
to "Coreboot" so that we can use that? Note that thinkpad_acpi
does not care about the DMI_BIOS_VENDOR value, at least
not on models which start their DMI_PRODUCT_VERSION with
either "ThinkPad" or "Lenovo".
###
Looking more at this I notice that coreboot has a
drivers_intel_gma_displays_ssdt_generate() which seems to
at least always generate ACPI video bus ASL including
backlight control bits.
So the only reason why the current heurstics are not
returning native is the acpi_osi_is_win8() check.
So maybe that beeds to become:
if ((acpi_osi_is_win8() || dmi_get_bios_year() >= 2018) &&
native_available)
return acpi_backlight_native;
else
return acpi_backlight_video;
Although I think that will result
Re: [PATCH v2 0/8] agp: Convert to generic power management
On Tue, Oct 25, 2022 at 03:38:44PM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > Vaibhav converted several AGP drivers from legacy PCI power management to > generic power management [1]. This series converts the rest of them. > > v1 posted at [2]. > > Changes from v1 to v2: > - Convert from SIMPLE_DEV_PM_OPS() (which is deprecated) to > DEFINE_SIMPLE_DEV_PM_OPS() and remove __maybe_unused annotations. > > [1] > https://lore.kernel.org/all/20210112080924.1038907-1-vaibhavgupt...@gmail.com/#t > [2] https://lore.kernel.org/all/20220607034340.307318-1-helg...@kernel.org/ > > Bjorn Helgaas (8): > agp/efficeon: Convert to generic power management > agp/intel: Convert to generic power management > agp/amd-k7: Convert to generic power management > agp/ati: Convert to generic power management > agp/nvidia: Convert to generic power management > agp/amd64: Update to DEFINE_SIMPLE_DEV_PM_OPS() > agp/sis: Update to DEFINE_SIMPLE_DEV_PM_OPS() > agp/via: Update to DEFINE_SIMPLE_DEV_PM_OPS() > > drivers/char/agp/amd-k7-agp.c | 24 > drivers/char/agp/amd64-agp.c| 6 ++ > drivers/char/agp/ati-agp.c | 22 -- > drivers/char/agp/efficeon-agp.c | 16 > drivers/char/agp/intel-agp.c| 11 +-- > drivers/char/agp/nvidia-agp.c | 24 > drivers/char/agp/sis-agp.c | 7 ++- > drivers/char/agp/via-agp.c | 6 ++ > 8 files changed, 27 insertions(+), 89 deletions(-) Applied with Dave's ack to pci/pm-agp for v6.2.
Re: [PATCH v2 0/8] agp: Convert to generic power management
On Wed, Oct 26, 2022 at 08:17:47AM +1000, Dave Airlie wrote: > On Wed, 26 Oct 2022 at 06:39, Bjorn Helgaas wrote: > > > > From: Bjorn Helgaas > > > > Vaibhav converted several AGP drivers from legacy PCI power management to > > generic power management [1]. This series converts the rest of them. > > Do you want to merge through the PCI tree? > > Acked-by: Dave Airlie Sure, will be happy to. Thanks! > > v1 posted at [2]. > > > > Changes from v1 to v2: > > - Convert from SIMPLE_DEV_PM_OPS() (which is deprecated) to > > DEFINE_SIMPLE_DEV_PM_OPS() and remove __maybe_unused annotations. > > > > [1] > > https://lore.kernel.org/all/20210112080924.1038907-1-vaibhavgupt...@gmail.com/#t > > [2] https://lore.kernel.org/all/20220607034340.307318-1-helg...@kernel.org/ > > > > Bjorn Helgaas (8): > > agp/efficeon: Convert to generic power management > > agp/intel: Convert to generic power management > > agp/amd-k7: Convert to generic power management > > agp/ati: Convert to generic power management > > agp/nvidia: Convert to generic power management > > agp/amd64: Update to DEFINE_SIMPLE_DEV_PM_OPS() > > agp/sis: Update to DEFINE_SIMPLE_DEV_PM_OPS() > > agp/via: Update to DEFINE_SIMPLE_DEV_PM_OPS() > > > > drivers/char/agp/amd-k7-agp.c | 24 > > drivers/char/agp/amd64-agp.c| 6 ++ > > drivers/char/agp/ati-agp.c | 22 -- > > drivers/char/agp/efficeon-agp.c | 16 > > drivers/char/agp/intel-agp.c| 11 +-- > > drivers/char/agp/nvidia-agp.c | 24 > > drivers/char/agp/sis-agp.c | 7 ++- > > drivers/char/agp/via-agp.c | 6 ++ > > 8 files changed, 27 insertions(+), 89 deletions(-) > > > > -- > > 2.25.1 > >
Re: [PATCH v2 0/8] agp: Convert to generic power management
On Wed, 26 Oct 2022 at 06:39, Bjorn Helgaas wrote: > > From: Bjorn Helgaas > > Vaibhav converted several AGP drivers from legacy PCI power management to > generic power management [1]. This series converts the rest of them. Do you want to merge through the PCI tree? Acked-by: Dave Airlie Dave. > > v1 posted at [2]. > > Changes from v1 to v2: > - Convert from SIMPLE_DEV_PM_OPS() (which is deprecated) to > DEFINE_SIMPLE_DEV_PM_OPS() and remove __maybe_unused annotations. > > [1] > https://lore.kernel.org/all/20210112080924.1038907-1-vaibhavgupt...@gmail.com/#t > [2] https://lore.kernel.org/all/20220607034340.307318-1-helg...@kernel.org/ > > Bjorn Helgaas (8): > agp/efficeon: Convert to generic power management > agp/intel: Convert to generic power management > agp/amd-k7: Convert to generic power management > agp/ati: Convert to generic power management > agp/nvidia: Convert to generic power management > agp/amd64: Update to DEFINE_SIMPLE_DEV_PM_OPS() > agp/sis: Update to DEFINE_SIMPLE_DEV_PM_OPS() > agp/via: Update to DEFINE_SIMPLE_DEV_PM_OPS() > > drivers/char/agp/amd-k7-agp.c | 24 > drivers/char/agp/amd64-agp.c| 6 ++ > drivers/char/agp/ati-agp.c | 22 -- > drivers/char/agp/efficeon-agp.c | 16 > drivers/char/agp/intel-agp.c| 11 +-- > drivers/char/agp/nvidia-agp.c | 24 > drivers/char/agp/sis-agp.c | 7 ++- > drivers/char/agp/via-agp.c | 6 ++ > 8 files changed, 27 insertions(+), 89 deletions(-) > > -- > 2.25.1 >
Re: [PATCH] drm/edid: Dump the EDID when drm_edid_get_panel_id() has an error
Hi Doug On 10/24/2022 1:28 PM, Doug Anderson wrote: Hi, On Fri, Oct 21, 2022 at 2:18 PM Abhinav Kumar wrote: Hi Doug On 10/21/2022 1:07 PM, Douglas Anderson wrote: If we fail to get a valid panel ID in drm_edid_get_panel_id() we'd like to see the EDID that was read so we have a chance of understanding what's wrong. There's already a function for that, so let's call it in the error case. NOTE: edid_block_read() has a retry loop in it, so actually we'll only print the block read back from the final attempt. This still seems better than nothing. Signed-off-by: Douglas Anderson Instead of checkinf for edid_block_status_valid() on the base_block, do you want to use drm_edid_block_valid() instead? That way you get the edid_block_dump() for free if it was invalid. I can... ...but it feels a bit awkward and maybe not quite how the functions were intended to work together? One thing I notice is that if I call drm_edid_block_valid() I'm doing a bunch of duplicate work that already happened in edid_block_read(), which already calls edid_block_check() and handles fixing headers. I guess also if I call drm_edid_block_valid() then I should ignore the "status" return value of edid_block_read() because we don't need to pass it anywhere (because the work is re-done in drm_edid_block_valid()). So I guess I'm happy to do a v2 like that if everyone likes it better, but to me it feels a little weird. -Doug Alright, agreed. There is some duplication of code happening if we use drm_edid_block_valid(). I had suggested that because it has inherent support for dumping the bad EDID. In that case, this change LGTM, because in principle you are doing the same thing as _drm_do_get_edid() (with the only difference being here we read only the base block as opposed to the full EDID there). Hence, Reviewed-by: Abhinav Kumar
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On Tue, Oct 25, 2022 at 10:25:33PM +0200, Hans de Goede wrote: > Having the native driver come and then go and be replaced > with the vendor driver would also be quite inconvenient > for these planned changes. I understand that it would be inconvenient, but you've broken existing working setups. > Can you perhaps explain a bit in what way your laptop > is weird ? It's a Chinese replacement motherboard for a Thinkpad X201, running my own port of Coreboot. Its DMI strings look like an actual Thinkpad in order to ensure that thinkpad_acpi can bind for hotkey suport, so it's hard to quirk. It'll actually be fixed by your proposed patch to fall back to native rather than vendor, but that patch will break any older machines that offer a vendor interface and don't have the native control hooked up (pretty sure at least the Thinkpad X40 falls into that category).
[PATCH v2 4/8] agp/ati: Convert to generic power management
From: Bjorn Helgaas
Convert agpgart-ati from legacy PCI power management to the generic power
management framework.
Previously agpgart-ati used legacy PCI power management, and
agp_ati_suspend() and agp_ati_resume() were responsible for both
device-specific things and generic PCI things like saving and restoring
config space and managing power state:
agp_ati_suspend
pci_save_state <-- generic PCI
pci_set_power_state(PCI_D3hot) <-- generic PCI
agp_ati_resume
pci_set_power_state(PCI_D0)<-- generic PCI
pci_restore_state <-- generic PCI
ati_configure <-- device-specific
With generic power management, the PCI bus PM methods do the generic PCI
things, and the driver needs only the device-specific part, i.e.,
suspend_devices_and_enter
dpm_suspend_start(PMSG_SUSPEND)
pci_pm_suspend # PCI bus .suspend() method
agp_ati_suspend<-- not needed at all; removed
suspend_enter
dpm_suspend_noirq(PMSG_SUSPEND)
pci_pm_suspend_noirq # PCI bus .suspend_noirq() method
pci_save_state <-- generic PCI
pci_prepare_to_sleep <-- generic PCI
pci_set_power_state
...
dpm_resume_end(PMSG_RESUME)
pci_pm_resume# PCI bus .resume() method
pci_restore_standard_config
pci_set_power_state(PCI_D0) <-- generic PCI
pci_restore_state<-- generic PCI
agp_ati_resume # driver->pm->resume
ati_configure<-- device-specific
Based on 0aeddbd0cb07 ("via-agp: convert to generic power management") by
Vaibhav Gupta .
Signed-off-by: Bjorn Helgaas
---
drivers/char/agp/ati-agp.c | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/char/agp/ati-agp.c b/drivers/char/agp/ati-agp.c
index 6f5530482d83..3c1fce48aabe 100644
--- a/drivers/char/agp/ati-agp.c
+++ b/drivers/char/agp/ati-agp.c
@@ -238,23 +238,10 @@ static int ati_configure(void)
}
-#ifdef CONFIG_PM
-static int agp_ati_suspend(struct pci_dev *dev, pm_message_t state)
+static int agp_ati_resume(struct device *dev)
{
- pci_save_state(dev);
- pci_set_power_state(dev, PCI_D3hot);
-
- return 0;
-}
-
-static int agp_ati_resume(struct pci_dev *dev)
-{
- pci_set_power_state(dev, PCI_D0);
- pci_restore_state(dev);
-
return ati_configure();
}
-#endif
/*
*Since we don't need contiguous memory we just try
@@ -559,15 +546,14 @@ static const struct pci_device_id agp_ati_pci_table[] = {
MODULE_DEVICE_TABLE(pci, agp_ati_pci_table);
+static DEFINE_SIMPLE_DEV_PM_OPS(agp_ati_pm_ops, NULL, agp_ati_resume);
+
static struct pci_driver agp_ati_pci_driver = {
.name = "agpgart-ati",
.id_table = agp_ati_pci_table,
.probe = agp_ati_probe,
.remove = agp_ati_remove,
-#ifdef CONFIG_PM
- .suspend= agp_ati_suspend,
- .resume = agp_ati_resume,
-#endif
+ .driver.pm = _ati_pm_ops,
};
static int __init agp_ati_init(void)
--
2.25.1
[PATCH v2 8/8] agp/via: Update to DEFINE_SIMPLE_DEV_PM_OPS()
From: Bjorn Helgaas
As of 1a3c7bb08826 ("PM: core: Add new *_PM_OPS macros, deprecate old
ones"), SIMPLE_DEV_PM_OPS() is deprecated in favor of
DEFINE_SIMPLE_DEV_PM_OPS(), which has the advantage that the PM callbacks
don't need to be wrapped with #ifdef CONFIG_PM or tagged with
__maybe_unused.
Convert to DEFINE_SIMPLE_DEV_PM_OPS(). No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/char/agp/via-agp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/char/agp/via-agp.c b/drivers/char/agp/via-agp.c
index b2f484f527fb..bc5140af2dcb 100644
--- a/drivers/char/agp/via-agp.c
+++ b/drivers/char/agp/via-agp.c
@@ -489,9 +489,7 @@ static void agp_via_remove(struct pci_dev *pdev)
agp_put_bridge(bridge);
}
-#define agp_via_suspend NULL
-
-static int __maybe_unused agp_via_resume(struct device *dev)
+static int agp_via_resume(struct device *dev)
{
struct agp_bridge_data *bridge = dev_get_drvdata(dev);
@@ -551,7 +549,7 @@ static const struct pci_device_id agp_via_pci_table[] = {
MODULE_DEVICE_TABLE(pci, agp_via_pci_table);
-static SIMPLE_DEV_PM_OPS(agp_via_pm_ops, agp_via_suspend, agp_via_resume);
+static DEFINE_SIMPLE_DEV_PM_OPS(agp_via_pm_ops, NULL, agp_via_resume);
static struct pci_driver agp_via_pci_driver = {
.name = "agpgart-via",
--
2.25.1
[PATCH v2 6/8] agp/amd64: Update to DEFINE_SIMPLE_DEV_PM_OPS()
From: Bjorn Helgaas
As of 1a3c7bb08826 ("PM: core: Add new *_PM_OPS macros, deprecate old
ones"), SIMPLE_DEV_PM_OPS() is deprecated in favor of
DEFINE_SIMPLE_DEV_PM_OPS(), which has the advantage that the PM callbacks
don't need to be wrapped with #ifdef CONFIG_PM or tagged with
__maybe_unused.
Convert to DEFINE_SIMPLE_DEV_PM_OPS(). No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/char/agp/amd64-agp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index 84a4aa9312cf..ce8651436609 100644
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -588,9 +588,7 @@ static void agp_amd64_remove(struct pci_dev *pdev)
agp_bridges_found--;
}
-#define agp_amd64_suspend NULL
-
-static int __maybe_unused agp_amd64_resume(struct device *dev)
+static int agp_amd64_resume(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -727,7 +725,7 @@ static const struct pci_device_id
agp_amd64_pci_promisc_table[] = {
{ }
};
-static SIMPLE_DEV_PM_OPS(agp_amd64_pm_ops, agp_amd64_suspend,
agp_amd64_resume);
+static DEFINE_SIMPLE_DEV_PM_OPS(agp_amd64_pm_ops, NULL, agp_amd64_resume);
static struct pci_driver agp_amd64_pci_driver = {
.name = "agpgart-amd64",
--
2.25.1
[PATCH v2 2/8] agp/intel: Convert to generic power management
From: Bjorn Helgaas
Convert agpgart-intel from legacy PCI power management to the generic power
management framework.
Previously agpgart-intel used legacy PCI power management, and
agp_intel_resume() was responsible for both device-specific things and
generic PCI things like saving and restoring config space and managing
power state.
In this case, agp_intel_suspend() was empty, and agp_intel_resume()
already did only device-specific things, so simply convert it to take a
struct device * instead of a struct pci_dev *.
Based on 0aeddbd0cb07 ("via-agp: convert to generic power management") by
Vaibhav Gupta .
Signed-off-by: Bjorn Helgaas
---
drivers/char/agp/intel-agp.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 9e4f27a6cb5a..c518b3a9db04 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -817,16 +817,15 @@ static void agp_intel_remove(struct pci_dev *pdev)
agp_put_bridge(bridge);
}
-#ifdef CONFIG_PM
-static int agp_intel_resume(struct pci_dev *pdev)
+static int agp_intel_resume(struct device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
bridge->driver->configure();
return 0;
}
-#endif
static const struct pci_device_id agp_intel_pci_table[] = {
#define ID(x) \
@@ -895,14 +894,14 @@ static const struct pci_device_id agp_intel_pci_table[] =
{
MODULE_DEVICE_TABLE(pci, agp_intel_pci_table);
+static DEFINE_SIMPLE_DEV_PM_OPS(agp_intel_pm_ops, NULL, agp_intel_resume);
+
static struct pci_driver agp_intel_pci_driver = {
.name = "agpgart-intel",
.id_table = agp_intel_pci_table,
.probe = agp_intel_probe,
.remove = agp_intel_remove,
-#ifdef CONFIG_PM
- .resume = agp_intel_resume,
-#endif
+ .driver.pm = _intel_pm_ops,
};
static int __init agp_intel_init(void)
--
2.25.1
[PATCH v2 0/8] agp: Convert to generic power management
From: Bjorn Helgaas Vaibhav converted several AGP drivers from legacy PCI power management to generic power management [1]. This series converts the rest of them. v1 posted at [2]. Changes from v1 to v2: - Convert from SIMPLE_DEV_PM_OPS() (which is deprecated) to DEFINE_SIMPLE_DEV_PM_OPS() and remove __maybe_unused annotations. [1] https://lore.kernel.org/all/20210112080924.1038907-1-vaibhavgupt...@gmail.com/#t [2] https://lore.kernel.org/all/20220607034340.307318-1-helg...@kernel.org/ Bjorn Helgaas (8): agp/efficeon: Convert to generic power management agp/intel: Convert to generic power management agp/amd-k7: Convert to generic power management agp/ati: Convert to generic power management agp/nvidia: Convert to generic power management agp/amd64: Update to DEFINE_SIMPLE_DEV_PM_OPS() agp/sis: Update to DEFINE_SIMPLE_DEV_PM_OPS() agp/via: Update to DEFINE_SIMPLE_DEV_PM_OPS() drivers/char/agp/amd-k7-agp.c | 24 drivers/char/agp/amd64-agp.c| 6 ++ drivers/char/agp/ati-agp.c | 22 -- drivers/char/agp/efficeon-agp.c | 16 drivers/char/agp/intel-agp.c| 11 +-- drivers/char/agp/nvidia-agp.c | 24 drivers/char/agp/sis-agp.c | 7 ++- drivers/char/agp/via-agp.c | 6 ++ 8 files changed, 27 insertions(+), 89 deletions(-) -- 2.25.1
[PATCH v2 7/8] agp/sis: Update to DEFINE_SIMPLE_DEV_PM_OPS()
From: Bjorn Helgaas
As of 1a3c7bb08826 ("PM: core: Add new *_PM_OPS macros, deprecate old
ones"), SIMPLE_DEV_PM_OPS() is deprecated in favor of
DEFINE_SIMPLE_DEV_PM_OPS(), which has the advantage that the PM callbacks
don't need to be wrapped with #ifdef CONFIG_PM or tagged with
__maybe_unused.
Convert to DEFINE_SIMPLE_DEV_PM_OPS(). No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/char/agp/sis-agp.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/char/agp/sis-agp.c b/drivers/char/agp/sis-agp.c
index f8a02f4bef1b..484bb101c53b 100644
--- a/drivers/char/agp/sis-agp.c
+++ b/drivers/char/agp/sis-agp.c
@@ -217,10 +217,7 @@ static void agp_sis_remove(struct pci_dev *pdev)
agp_put_bridge(bridge);
}
-#define agp_sis_suspend NULL
-
-static int __maybe_unused agp_sis_resume(
- __attribute__((unused)) struct device *dev)
+static int agp_sis_resume(__attribute__((unused)) struct device *dev)
{
return sis_driver.configure();
}
@@ -407,7 +404,7 @@ static const struct pci_device_id agp_sis_pci_table[] = {
MODULE_DEVICE_TABLE(pci, agp_sis_pci_table);
-static SIMPLE_DEV_PM_OPS(agp_sis_pm_ops, agp_sis_suspend, agp_sis_resume);
+static DEFINE_SIMPLE_DEV_PM_OPS(agp_sis_pm_ops, NULL, agp_sis_resume);
static struct pci_driver agp_sis_pci_driver = {
.name = "agpgart-sis",
--
2.25.1
[PATCH v2 5/8] agp/nvidia: Convert to generic power management
From: Bjorn Helgaas
Convert agpgart-nvidia from legacy PCI power management to the generic
power management framework.
Previously agpgart-nvidia used legacy PCI power management, and
agp_nvidia_suspend() and agp_nvidia_resume() were responsible for both
device-specific things and generic PCI things:
agp_nvidia_suspend
pci_save_state <-- generic PCI
pci_set_power_state(PCI_D3hot) <-- generic PCI
agp_nvidia_resume
pci_set_power_state(PCI_D0)<-- generic PCI
pci_restore_state <-- generic PCI
nvidia_configure <-- device-specific
Convert to generic power management where the PCI bus PM methods do the
generic PCI things, and the driver needs only the device-specific part,
i.e.,
suspend_devices_and_enter
dpm_suspend_start(PMSG_SUSPEND)
pci_pm_suspend # PCI bus .suspend() method
agp_nvidia_suspend <-- not needed at all; removed
suspend_enter
dpm_suspend_noirq(PMSG_SUSPEND)
pci_pm_suspend_noirq # PCI bus .suspend_noirq() method
pci_save_state <-- generic PCI
pci_prepare_to_sleep <-- generic PCI
pci_set_power_state
...
dpm_resume_end(PMSG_RESUME)
pci_pm_resume# PCI bus .resume() method
pci_restore_standard_config
pci_set_power_state(PCI_D0) <-- generic PCI
pci_restore_state<-- generic PCI
agp_nvidia_resume # driver->pm->resume
nvidia_configure <-- device-specific
Based on 0aeddbd0cb07 ("via-agp: convert to generic power management") by
Vaibhav Gupta .
Signed-off-by: Bjorn Helgaas
---
drivers/char/agp/nvidia-agp.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.c
index 826dbd06f6bb..dbcbc06cc202 100644
--- a/drivers/char/agp/nvidia-agp.c
+++ b/drivers/char/agp/nvidia-agp.c
@@ -404,28 +404,13 @@ static void agp_nvidia_remove(struct pci_dev *pdev)
agp_put_bridge(bridge);
}
-#ifdef CONFIG_PM
-static int agp_nvidia_suspend(struct pci_dev *pdev, pm_message_t state)
+static int agp_nvidia_resume(struct device *dev)
{
- pci_save_state(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
-
- return 0;
-}
-
-static int agp_nvidia_resume(struct pci_dev *pdev)
-{
- /* set power state 0 and restore PCI space */
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
-
/* reconfigure AGP hardware again */
nvidia_configure();
return 0;
}
-#endif
-
static const struct pci_device_id agp_nvidia_pci_table[] = {
{
@@ -449,15 +434,14 @@ static const struct pci_device_id agp_nvidia_pci_table[]
= {
MODULE_DEVICE_TABLE(pci, agp_nvidia_pci_table);
+static DEFINE_SIMPLE_DEV_PM_OPS(agp_nvidia_pm_ops, NULL, agp_nvidia_resume);
+
static struct pci_driver agp_nvidia_pci_driver = {
.name = "agpgart-nvidia",
.id_table = agp_nvidia_pci_table,
.probe = agp_nvidia_probe,
.remove = agp_nvidia_remove,
-#ifdef CONFIG_PM
- .suspend= agp_nvidia_suspend,
- .resume = agp_nvidia_resume,
-#endif
+ .driver.pm = _nvidia_pm_ops,
};
static int __init agp_nvidia_init(void)
--
2.25.1
[PATCH v2 3/8] agp/amd-k7: Convert to generic power management
From: Bjorn Helgaas
Convert agpgart-amdk7 from legacy PCI power management to the generic power
management framework.
Previously agpgart-amdk7 used legacy PCI power management, and
agp_amdk7_suspend() and agp_amdk7_resume() were responsible for both
device-specific things and generic PCI things like saving and restoring
config space and managing power state:
agp_amdk7_suspend
pci_save_state <-- generic PCI
pci_set_power_state<-- generic PCI
agp_amdk7_resume
pci_set_power_state(PCI_D0)<-- generic PCI
pci_restore_state <-- generic PCI
amd_irongate_driver.configure <-- device-specific
Convert to generic power management where the PCI bus PM methods do the
generic PCI things, and the driver needs only the device-specific part,
i.e.,
suspend_devices_and_enter
dpm_suspend_start(PMSG_SUSPEND)
pci_pm_suspend # PCI bus .suspend() method
agp_amdk7_suspend <-- not needed at all; removed
suspend_enter
dpm_suspend_noirq(PMSG_SUSPEND)
pci_pm_suspend_noirq # PCI bus .suspend_noirq() method
pci_save_state <-- generic PCI
pci_prepare_to_sleep <-- generic PCI
pci_set_power_state
...
dpm_resume_end(PMSG_RESUME)
pci_pm_resume# PCI bus .resume() method
pci_restore_standard_config
pci_set_power_state(PCI_D0) <-- generic PCI
pci_restore_state<-- generic PCI
agp_amdk7_resume # driver->pm->resume
amd_irongate_driver.configure<-- device-specific
Based on 0aeddbd0cb07 ("via-agp: convert to generic power management") by
Vaibhav Gupta .
Signed-off-by: Bjorn Helgaas
---
drivers/char/agp/amd-k7-agp.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index 2b2095542816..55397ba765d2 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -488,26 +488,11 @@ static void agp_amdk7_remove(struct pci_dev *pdev)
agp_put_bridge(bridge);
}
-#ifdef CONFIG_PM
-
-static int agp_amdk7_suspend(struct pci_dev *pdev, pm_message_t state)
+static int agp_amdk7_resume(struct device *dev)
{
- pci_save_state(pdev);
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
-
- return 0;
-}
-
-static int agp_amdk7_resume(struct pci_dev *pdev)
-{
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
-
return amd_irongate_driver.configure();
}
-#endif /* CONFIG_PM */
-
/* must be the same order as name table above */
static const struct pci_device_id agp_amdk7_pci_table[] = {
{
@@ -539,15 +524,14 @@ static const struct pci_device_id agp_amdk7_pci_table[] =
{
MODULE_DEVICE_TABLE(pci, agp_amdk7_pci_table);
+static DEFINE_SIMPLE_DEV_PM_OPS(agp_amdk7_pm_ops, NULL, agp_amdk7_resume);
+
static struct pci_driver agp_amdk7_pci_driver = {
.name = "agpgart-amdk7",
.id_table = agp_amdk7_pci_table,
.probe = agp_amdk7_probe,
.remove = agp_amdk7_remove,
-#ifdef CONFIG_PM
- .suspend= agp_amdk7_suspend,
- .resume = agp_amdk7_resume,
-#endif
+ .driver.pm = _amdk7_pm_ops,
};
static int __init agp_amdk7_init(void)
--
2.25.1
[PATCH v2 1/8] agp/efficeon: Convert to generic power management
From: Bjorn Helgaas
Convert agpgart-efficeon from legacy PCI power management to the generic
power management framework.
Previously agpgart-efficeon used legacy PCI power management, which means
agp_efficeon_suspend() and agp_efficeon_resume() were responsible for both
device-specific things and generic PCI things like saving and restoring
config space and managing power state.
In this case, agp_efficeon_suspend() was empty, and agp_efficeon_resume()
already did only device-specific things, so simply convert it to take a
struct device * instead of a struct pci_dev *.
Based on 0aeddbd0cb07 ("via-agp: convert to generic power management") by
Vaibhav Gupta .
Signed-off-by: Bjorn Helgaas
---
drivers/char/agp/efficeon-agp.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/char/agp/efficeon-agp.c b/drivers/char/agp/efficeon-agp.c
index c53f0f9ef5b0..f28d42319269 100644
--- a/drivers/char/agp/efficeon-agp.c
+++ b/drivers/char/agp/efficeon-agp.c
@@ -412,18 +412,11 @@ static void agp_efficeon_remove(struct pci_dev *pdev)
agp_put_bridge(bridge);
}
-#ifdef CONFIG_PM
-static int agp_efficeon_suspend(struct pci_dev *dev, pm_message_t state)
-{
- return 0;
-}
-
-static int agp_efficeon_resume(struct pci_dev *pdev)
+static int agp_efficeon_resume(struct device *dev)
{
printk(KERN_DEBUG PFX "agp_efficeon_resume()\n");
return efficeon_configure();
}
-#endif
static const struct pci_device_id agp_efficeon_pci_table[] = {
{
@@ -437,6 +430,8 @@ static const struct pci_device_id agp_efficeon_pci_table[]
= {
{ }
};
+static DEFINE_SIMPLE_DEV_PM_OPS(agp_efficeon_pm_ops, NULL,
agp_efficeon_resume);
+
MODULE_DEVICE_TABLE(pci, agp_efficeon_pci_table);
static struct pci_driver agp_efficeon_pci_driver = {
@@ -444,10 +439,7 @@ static struct pci_driver agp_efficeon_pci_driver = {
.id_table = agp_efficeon_pci_table,
.probe = agp_efficeon_probe,
.remove = agp_efficeon_remove,
-#ifdef CONFIG_PM
- .suspend= agp_efficeon_suspend,
- .resume = agp_efficeon_resume,
-#endif
+ .driver.pm = _efficeon_pm_ops,
};
static int __init agp_efficeon_init(void)
--
2.25.1
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi (again), On 10/25/22 22:25, Hans de Goede wrote: > Hi Matthew, > > On 10/25/22 21:32, Matthew Garrett wrote: >> On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: >> >>> That is a valid point, but keep in mind that this is only used on ACPI >>> platforms and then only on devices with a builtin LCD panel and then >>> only by GPU drivers which actually call acpi_video_get_backlight_type(), >>> so e.g. not by all the ARM specific display drivers. >>> >>> So I believe that Chromebooks quite likely are the only devices with >>> this issue. >> >> My laptop is, uh, weird, but it falls into this category. >> I think for this to work correctly you need to have the infrastructure be aware of whether or not a vendor interface exists, which means having to handle cleanup if a vendor-specific module gets loaded later. >>> >>> Getting rid of the whole ping-ponging of which backlight drivers >>> get loaded during boot was actually one of the goals of the rework >>> which landed in 6.1 this actually allowed us to remove some quirks >>> because some hw/firmware did not like us changing our mind and >>> switching backlight interfaces after first poking another one. >>> So we definitely don't want to go back to the ping-pong thing. >> >> Defaulting to native but then having a vendor driver be able to disable >> native drivers seems easiest? It shouldn't be a regression over the >> previous state of affairs since both drivers were being loaded already. > > Part of the reason for the ACPI backlight detect refactor is > because of a planned new backlight uAPI where the brightness > control becomes a property on the drm connector object, for a > RFC including the rationale behind this planned uAPI change see: > https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/ > > These plans require that there is only 1 backlight device > registered (per panel). > > Having the native driver come and then go and be replaced > with the vendor driver would also be quite inconvenient > for these planned changes. > > As such I would rather find a solution for your "weird" > laptop so that acpi_video_get_backlight_type() just always > returns vendor there. I just realized that your have vendor driver unregister the native one is suggested as an alternative for the new behavior where the i915 driver no longer registers its native backlight in cases where acpi_video_get_backlight_type() does not return native, and that you probably actually want the native backlight device, right ? So the above should read: "so that acpi_video_get_backlight_type() just always returns native there." > Note that drivers/acpi/video_detect.c already has a DMI > quirk tables for models where the heuristics from > acpi_video_get_backlight_type() don't work. In general > we (mostly me) try to make it so that the heuristics > work on most models, to avoid needing to add every model > under the sun to the DMI quirk table, but if your laptop > is somehow special then adding a DMI quirk for it should > be fine ? > > Can you perhaps explain a bit in what way your laptop > is weird ? I guess it is weird in that it does not have the ACPI video, or at least does not offer ACPI video bus backlight control in its ACPI tables? Can you perhaps email me an acpidump of the laptop ? > Note that technically if the native backlight does not work, > then the GPU driver really should not even try to register > it. But sometimes the video-bios-tables claim the backlight > pwm input is attached to the GPU while it is not and things > have evolved in such a way that the DMI quirks for that > live in acpi/video_detect.c rather then in the GPU driver. And this bit can be ignored then because it certainly is not relevant if you actually want the native driver. Regards, Hans
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On 10/25/2022 15:25, Hans de Goede wrote: Hi Matthew, On 10/25/22 21:32, Matthew Garrett wrote: On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: That is a valid point, but keep in mind that this is only used on ACPI platforms and then only on devices with a builtin LCD panel and then only by GPU drivers which actually call acpi_video_get_backlight_type(), so e.g. not by all the ARM specific display drivers. So I believe that Chromebooks quite likely are the only devices with this issue. My laptop is, uh, weird, but it falls into this category. I think for this to work correctly you need to have the infrastructure be aware of whether or not a vendor interface exists, which means having to handle cleanup if a vendor-specific module gets loaded later. Getting rid of the whole ping-ponging of which backlight drivers get loaded during boot was actually one of the goals of the rework which landed in 6.1 this actually allowed us to remove some quirks because some hw/firmware did not like us changing our mind and switching backlight interfaces after first poking another one. So we definitely don't want to go back to the ping-pong thing. Defaulting to native but then having a vendor driver be able to disable native drivers seems easiest? It shouldn't be a regression over the previous state of affairs since both drivers were being loaded already. Part of the reason for the ACPI backlight detect refactor is because of a planned new backlight uAPI where the brightness control becomes a property on the drm connector object, for a RFC including the rationale behind this planned uAPI change see: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2Fb61d3eeb-6213-afac-2e70-7b9791c86d2e%40redhat.com%2Fdata=05%7C01%7Cmario.limonciello%40amd.com%7C6380e44c87e447eedc3f08dab6c7180a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023263541559113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=K4oMmVl51kT9V%2B4GAdx%2FS7tXWHPKyFe5WXZzC3CPeOU%3Dreserved=0 These plans require that there is only 1 backlight device registered (per panel). Having the native driver come and then go and be replaced with the vendor driver would also be quite inconvenient for these planned changes. As such I would rather find a solution for your "weird" laptop so that acpi_video_get_backlight_type() just always returns vendor there. What exactly is this "weird" laptop? Is it something running coreboot that doesn't "normally" ship with coreboot perhaps? If that's the category it falls in, I think what we really need is something to land in coreboot source for indicating how it should behave and then also a change in the kernel to react to that. That's a similar approach to what was used fore the chromebook laptops that run coreboot. Note that drivers/acpi/video_detect.c already has a DMI quirk tables for models where the heuristics from acpi_video_get_backlight_type() don't work. In general we (mostly me) try to make it so that the heuristics work on most models, to avoid needing to add every model under the sun to the DMI quirk table, but if your laptop is somehow special then adding a DMI quirk for it should be fine ? Can you perhaps explain a bit in what way your laptop is weird ? Note that technically if the native backlight does not work, then the GPU driver really should not even try to register it. But sometimes the video-bios-tables claim the backlight pwm input is attached to the GPU while it is not and things have evolved in such a way that the DMI quirks for that live in acpi/video_detect.c rather then in the GPU driver. Regards, Hans
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi Matthew, On 10/25/22 21:32, Matthew Garrett wrote: > On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: > >> That is a valid point, but keep in mind that this is only used on ACPI >> platforms and then only on devices with a builtin LCD panel and then >> only by GPU drivers which actually call acpi_video_get_backlight_type(), >> so e.g. not by all the ARM specific display drivers. >> >> So I believe that Chromebooks quite likely are the only devices with >> this issue. > > My laptop is, uh, weird, but it falls into this category. > >>> I think for this to work correctly you need to have >>> the infrastructure be aware of whether or not a vendor interface exists, >>> which means having to handle cleanup if a vendor-specific module gets >>> loaded later. >> >> Getting rid of the whole ping-ponging of which backlight drivers >> get loaded during boot was actually one of the goals of the rework >> which landed in 6.1 this actually allowed us to remove some quirks >> because some hw/firmware did not like us changing our mind and >> switching backlight interfaces after first poking another one. >> So we definitely don't want to go back to the ping-pong thing. > > Defaulting to native but then having a vendor driver be able to disable > native drivers seems easiest? It shouldn't be a regression over the > previous state of affairs since both drivers were being loaded already. Part of the reason for the ACPI backlight detect refactor is because of a planned new backlight uAPI where the brightness control becomes a property on the drm connector object, for a RFC including the rationale behind this planned uAPI change see: https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/ These plans require that there is only 1 backlight device registered (per panel). Having the native driver come and then go and be replaced with the vendor driver would also be quite inconvenient for these planned changes. As such I would rather find a solution for your "weird" laptop so that acpi_video_get_backlight_type() just always returns vendor there. Note that drivers/acpi/video_detect.c already has a DMI quirk tables for models where the heuristics from acpi_video_get_backlight_type() don't work. In general we (mostly me) try to make it so that the heuristics work on most models, to avoid needing to add every model under the sun to the DMI quirk table, but if your laptop is somehow special then adding a DMI quirk for it should be fine ? Can you perhaps explain a bit in what way your laptop is weird ? Note that technically if the native backlight does not work, then the GPU driver really should not even try to register it. But sometimes the video-bios-tables claim the backlight pwm input is attached to the GPU while it is not and things have evolved in such a way that the DMI quirks for that live in acpi/video_detect.c rather then in the GPU driver. Regards, Hans
[PATCH v3 2/2] drm/msm: remove duplicated code from a6xx_create_address_space
The function a6xx_create_address_space() is mostly a copy of
adreno_iommu_create_address_space() with added quirk setting. Rework
these two functions to be a thin wrappers around a common helper.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 29 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 12 --
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 7 +-
6 files changed, 20 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 2c8b9899625b..948785ed07bb 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -500,7 +500,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
+ .create_address_space = adreno_create_address_space,
.get_rptr = a3xx_get_rptr,
},
};
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 7cb8d9849c07..2fb32d5552c4 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -635,7 +635,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
+ .create_address_space = adreno_create_address_space,
.get_rptr = a4xx_get_rptr,
},
.get_timestamp = a4xx_get_timestamp,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 3dcec7acb384..3c537c0016fa 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1705,7 +1705,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_busy = a5xx_gpu_busy,
.gpu_state_get = a5xx_gpu_state_get,
.gpu_state_put = a5xx_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
+ .create_address_space = adreno_create_address_space,
.get_rptr = a5xx_get_rptr,
},
.get_timestamp = a5xx_get_timestamp,
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 7a1b4397b842..2daba2029db1 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1784,38 +1784,11 @@ static void a6xx_gpu_set_freq(struct msm_gpu *gpu,
struct dev_pm_opp *opp,
static struct msm_gem_address_space *
a6xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
{
- struct msm_mmu *mmu;
- struct msm_gem_address_space *aspace;
- struct iommu_domain_geometry *geometry;
- u64 start, size;
-
/*
* This allows GPU to set the bus attributes required to use system
* cache on behalf of the iommu page table walker.
*/
- mmu = msm_iommu_new(>dev, IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
- if (IS_ERR_OR_NULL(mmu))
- return ERR_CAST(mmu);
-
- geometry = msm_iommu_get_geometry(mmu);
- if (IS_ERR(geometry))
- return ERR_CAST(geometry);
-
- /*
-* Use the aperture start or SZ_16M, whichever is greater. This will
-* ensure that we align with the allocated pagetable range while still
-* allowing room in the lower 32 bits for GMEM and whatnot
-*/
- start = max_t(u64, SZ_16M, geometry->aperture_start);
- size = geometry->aperture_end - start + 1;
-
- aspace = msm_gem_address_space_create(mmu, "gpu",
- start & GENMASK_ULL(48, 0), size);
-
- if (IS_ERR(aspace) && !IS_ERR(mmu))
- mmu->funcs->destroy(mmu);
-
- return aspace;
+ return adreno_iommu_create_address_space(gpu, pdev,
IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
}
static struct msm_gem_address_space *
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 5808911899c7..822a60c5b6b1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -191,16 +191,24 @@ int adreno_zap_shader_load(struct msm_gpu *gpu, u32 pasid)
return zap_shader_load_mdt(gpu, adreno_gpu->info->zapfw, pasid);
}
+struct msm_gem_address_space *
+adreno_create_address_space(struct msm_gpu *gpu,
+ struct platform_device *pdev)
+{
+ return adreno_iommu_create_address_space(gpu, pdev, 0);
+}
+
struct msm_gem_address_space *
adreno_iommu_create_address_space(struct msm_gpu *gpu,
- struct
[PATCH v3 1/2] drm/msm: move domain allocation into msm_iommu_new()
After the msm_iommu instance is created, the IOMMU domain is completely
handled inside the msm_iommu code. Move the iommu_domain_alloc() call
into the msm_iommu_new() to simplify callers code.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c| 12 +---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c| 25 +---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 25 +---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 19 +-
drivers/gpu/drm/msm/msm_drv.c| 18 -
drivers/gpu/drm/msm/msm_iommu.c | 20 ---
drivers/gpu/drm/msm/msm_mmu.h| 3 ++-
8 files changed, 60 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index e033d6a67a20..6484b97c5344 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1213,19 +1213,17 @@ static int a6xx_gmu_memory_alloc(struct a6xx_gmu *gmu,
struct a6xx_gmu_bo *bo,
static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu)
{
- struct iommu_domain *domain;
struct msm_mmu *mmu;
- domain = iommu_domain_alloc(_bus_type);
- if (!domain)
+ mmu = msm_iommu_new(gmu->dev, 0);
+ if (!mmu)
return -ENODEV;
+ if (IS_ERR(mmu))
+ return PTR_ERR(mmu);
- mmu = msm_iommu_new(gmu->dev, domain);
gmu->aspace = msm_gem_address_space_create(mmu, "gmu", 0x0, 0x8000);
- if (IS_ERR(gmu->aspace)) {
- iommu_domain_free(domain);
+ if (IS_ERR(gmu->aspace))
return PTR_ERR(gmu->aspace);
- }
return 0;
}
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index fdc578016e0b..7a1b4397b842 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1784,37 +1784,30 @@ static void a6xx_gpu_set_freq(struct msm_gpu *gpu,
struct dev_pm_opp *opp,
static struct msm_gem_address_space *
a6xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
{
- struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
- struct iommu_domain *iommu;
struct msm_mmu *mmu;
struct msm_gem_address_space *aspace;
+ struct iommu_domain_geometry *geometry;
u64 start, size;
- iommu = iommu_domain_alloc(_bus_type);
- if (!iommu)
- return NULL;
-
/*
* This allows GPU to set the bus attributes required to use system
* cache on behalf of the iommu page table walker.
*/
- if (!IS_ERR_OR_NULL(a6xx_gpu->htw_llc_slice))
- adreno_set_llc_attributes(iommu);
-
- mmu = msm_iommu_new(>dev, iommu);
- if (IS_ERR(mmu)) {
- iommu_domain_free(iommu);
+ mmu = msm_iommu_new(>dev, IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
+ if (IS_ERR_OR_NULL(mmu))
return ERR_CAST(mmu);
- }
+
+ geometry = msm_iommu_get_geometry(mmu);
+ if (IS_ERR(geometry))
+ return ERR_CAST(geometry);
/*
* Use the aperture start or SZ_16M, whichever is greater. This will
* ensure that we align with the allocated pagetable range while still
* allowing room in the lower 32 bits for GMEM and whatnot
*/
- start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
- size = iommu->geometry.aperture_end - start + 1;
+ start = max_t(u64, SZ_16M, geometry->aperture_start);
+ size = geometry->aperture_end - start + 1;
aspace = msm_gem_address_space_create(mmu, "gpu",
start & GENMASK_ULL(48, 0), size);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 382fb7f9e497..5808911899c7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -191,37 +191,30 @@ int adreno_zap_shader_load(struct msm_gpu *gpu, u32 pasid)
return zap_shader_load_mdt(gpu, adreno_gpu->info->zapfw, pasid);
}
-void adreno_set_llc_attributes(struct iommu_domain *iommu)
-{
- iommu_set_pgtable_quirks(iommu, IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
-}
-
struct msm_gem_address_space *
adreno_iommu_create_address_space(struct msm_gpu *gpu,
struct platform_device *pdev)
{
- struct iommu_domain *iommu;
struct msm_mmu *mmu;
struct msm_gem_address_space *aspace;
+ struct iommu_domain_geometry *geometry;
u64 start, size;
- iommu = iommu_domain_alloc(_bus_type);
- if (!iommu)
- return NULL;
-
- mmu = msm_iommu_new(>dev, iommu);
- if (IS_ERR(mmu)) {
- iommu_domain_free(iommu);
+ mmu = msm_iommu_new(>dev,
[PATCH v3 0/2] drm/msm: rework msm_iommu_new() and .create_address_space cb
Simplify the MSM IOMMU code a bit. This moves iommu_domain_alloc() and iommu_set_pgtable_quirks() calls to msm_iommu_new() to get rid of the disbalance, when the iommu domain is allocated by the caller of msm_iommu_new() and then it is freed by the msm_iommu code itself. Changes since v2: - Reorder the patches. - Move iommu_set_pgtable_quirks() to the msm_iommu_new() too. It will not work if it's called after attaching the device. Changes since v1: - Fixed the uninitialized variable usage in a6xx_gmu_memory_probe() (reported by lkp) Dmitry Baryshkov (2): drm/msm: move domain allocation into msm_iommu_new() drm/msm: remove duplicated code from a6xx_create_address_space drivers/gpu/drm/msm/adreno/a3xx_gpu.c| 2 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c| 2 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 2 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c| 12 drivers/gpu/drm/msm/adreno/a6xx_gpu.c| 36 +--- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 29 ++- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 9 -- drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 19 +++-- drivers/gpu/drm/msm/msm_drv.c| 18 ++-- drivers/gpu/drm/msm/msm_iommu.c | 20 +++-- drivers/gpu/drm/msm/msm_mmu.h| 3 +- 11 files changed, 67 insertions(+), 85 deletions(-) -- 2.35.1
[PATCH v3] drm/i915: Fix CFI violations in gt_sysfs
From: Nathan Chancellor
When booting with CONFIG_CFI_CLANG, there are numerous violations when
accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
$ grep . *
id:0
punit_req_freq_mhz:350
rc6_enable:1
rc6_residency_ms:214934
rps_act_freq_mhz:1300
rps_boost_freq_mhz:1300
rps_cur_freq_mhz:350
rps_max_freq_mhz:1300
rps_min_freq_mhz:350
rps_RP0_freq_mhz:1300
rps_RP1_freq_mhz:350
rps_RPn_freq_mhz:350
throttle_reason_pl1:0
throttle_reason_pl2:0
throttle_reason_pl4:0
throttle_reason_prochot:0
throttle_reason_ratl:0
throttle_reason_status:0
throttle_reason_thermal:0
throttle_reason_vr_tdc:0
throttle_reason_vr_thermalert:0
$ sudo dmesg &| grep "CFI failure at"
[ 214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target:
id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
[ 214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target:
punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
[ 214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target:
act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target:
boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target:
cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target:
max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target:
min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target:
RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
With kCFI, indirect calls are validated against their expected type
versus actual type and failures occur when the two types do not match.
The ultimate issue is that these sysfs functions are expecting to be
called via dev_attr_show() but they may also be called via
kobj_attr_show(), as certain files are created under two different
kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
hence the warnings above. When accessing the gt_ files under
/sys/devices/pci:00/:00:02.0/drm/card0, which are using the same
sysfs functions, there are no violations, meaning the functions are
being called with the proper type.
To make everything work properly, adjust certain functions to match the
type of the ->show() and ->store() members in 'struct kobj_attribute'.
Add a macro to generate functions for that can be called via both
dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
called through both kobject locations without violating kCFI and adjust
the attribute groups to account for this.
Link: https://github.com/ClangBuiltLinux/linux/issues/1716
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
Reviewed-by: Kees Cook
Signed-off-by: Nathan Chancellor
Signed-off-by: Andi Shyti
Link:
https://patchwork.freedesktop.org/patch/msgid/20221013205909.1282545-1-nat...@kernel.org
---
Hi,
just respinning this patch as we got a failure from CI and I wanted to
be
Re: [PATCH] [next] amdkfd: remove unused kfd_pm4_headers_diq header file
Am 2022-10-25 um 05:12 schrieb Paulo Miguel Almeida:
kfd_pm4_headers_diq.h header is a leftover from the old H/W debugger
module support added on commit . That implementation
was removed after a while and the last file that included that header
was removed on commit <5bdd3eb253544b1>.
This patch removes the unused header file kfd_pm4_headers_diq.h
Signed-off-by: Paulo Miguel Almeida
Thank you for this patch and the one that removes struct cdit_header. I
am applying both to our amd-staging-drm-next branch. I'm also fixing up
the prefix of the commit headline to match our usual convention:
drm/amdkfd: ...
Both patches are
Reviewed-by: Felix Kuehling
---
.../gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h | 291 --
1 file changed, 291 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h
b/drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h
deleted file mode 100644
index f9cd28690151..
--- a/drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h
+++ /dev/null
@@ -1,291 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 OR MIT */
-/*
- * Copyright 2014-2022 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- */
-
-#ifndef KFD_PM4_HEADERS_DIQ_H_
-#define KFD_PM4_HEADERS_DIQ_H_
-
-/*_INDIRECT_BUFFER */
-
-#ifndef _PM4__INDIRECT_BUFFER_DEFINED
-#define _PM4__INDIRECT_BUFFER_DEFINED
-enum _INDIRECT_BUFFER_cache_policy_enum {
- cache_policy___indirect_buffer__lru = 0,
- cache_policy___indirect_buffer__stream = 1,
- cache_policy___indirect_buffer__bypass = 2
-};
-
-enum {
- IT_INDIRECT_BUFFER_PASID = 0x5C
-};
-
-struct pm4__indirect_buffer_pasid {
- union {
- union PM4_MES_TYPE_3_HEADER header; /* header */
- unsigned int ordinal1;
- };
-
- union {
- struct {
- unsigned int reserved1:2;
- unsigned int ib_base_lo:30;
- } bitfields2;
- unsigned int ordinal2;
- };
-
- union {
- struct {
- unsigned int ib_base_hi:16;
- unsigned int reserved2:16;
- } bitfields3;
- unsigned int ordinal3;
- };
-
- union {
- unsigned int control;
- unsigned int ordinal4;
- };
-
- union {
- struct {
- unsigned int pasid:10;
- unsigned int reserved4:22;
- } bitfields5;
- unsigned int ordinal5;
- };
-
-};
-
-#endif
-
-/*_RELEASE_MEM */
-
-#ifndef _PM4__RELEASE_MEM_DEFINED
-#define _PM4__RELEASE_MEM_DEFINED
-enum _RELEASE_MEM_event_index_enum {
- event_index___release_mem__end_of_pipe = 5,
- event_index___release_mem__shader_done = 6
-};
-
-enum _RELEASE_MEM_cache_policy_enum {
- cache_policy___release_mem__lru = 0,
- cache_policy___release_mem__stream = 1,
- cache_policy___release_mem__bypass = 2
-};
-
-enum _RELEASE_MEM_dst_sel_enum {
- dst_sel___release_mem__memory_controller = 0,
- dst_sel___release_mem__tc_l2 = 1,
- dst_sel___release_mem__queue_write_pointer_register = 2,
- dst_sel___release_mem__queue_write_pointer_poll_mask_bit = 3
-};
-
-enum _RELEASE_MEM_int_sel_enum {
- int_sel___release_mem__none = 0,
- int_sel___release_mem__send_interrupt_only = 1,
- int_sel___release_mem__send_interrupt_after_write_confirm = 2,
- int_sel___release_mem__send_data_after_write_confirm = 3
-};
-
-enum _RELEASE_MEM_data_sel_enum {
- data_sel___release_mem__none = 0,
- data_sel___release_mem__send_32_bit_low = 1,
- data_sel___release_mem__send_64_bit_data = 2,
-
Re: [PATCH -next] drm/amdkfd: clean up some inconsistent indentings
Am 2022-10-25 um 02:09 schrieb Yang Li: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:331 svm_migrate_copy_to_vram() warn: inconsistent indenting Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2537 Reported-by: Abaci Robot Signed-off-by: Yang Li This patch doesn't apply to our amd-staging-drm-next, nor to the kernel.org master branch. Which branch is this against? Thanks, Felix --- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c index 20d6b2578927..cddf259875c0 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c @@ -328,8 +328,7 @@ svm_migrate_copy_to_vram(struct amdgpu_device *adev, struct svm_range *prange, dst[i] = cursor.start + (j << PAGE_SHIFT); migrate->dst[i] = svm_migrate_addr_to_pfn(adev, dst[i]); - svm_migrate_get_vram_page(>pgmap, prange, - migrate->dst[i]); + svm_migrate_get_vram_page(>pgmap, prange, migrate->dst[i]); migrate->dst[i] = migrate_pfn(migrate->dst[i]); spage = migrate_pfn_to_page(migrate->src[i]);
Re: [PATCH -next] drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()
Am 2022-10-25 um 03:28 schrieb Yang Li:
./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but
dereferenced.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2549
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index cddf259875c0..405dd51521dc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -981,7 +981,8 @@ static vm_fault_t svm_migrate_to_ram(struct vm_fault *vmf)
out_mmput:
mmput(mm);
- pr_debug("CPU fault svms 0x%p address 0x%lx done\n", >svms, addr);
+ if (p)
+ pr_debug("CPU fault svms 0x%p address 0x%lx done\n", >svms,
addr);
Thank you for catching and reporting this problem. I think the correct
solution would be to move the pr_debug up before the kfd_unref_process
call. That way you're sure that the pointer is initialized and that it
represents a valid reference to the kfd_process structure.
Regards,
Felix
return r ? VM_FAULT_SIGBUS : 0;
}
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: > That is a valid point, but keep in mind that this is only used on ACPI > platforms and then only on devices with a builtin LCD panel and then > only by GPU drivers which actually call acpi_video_get_backlight_type(), > so e.g. not by all the ARM specific display drivers. > > So I believe that Chromebooks quite likely are the only devices with > this issue. My laptop is, uh, weird, but it falls into this category. > > I think for this to work correctly you need to have > > the infrastructure be aware of whether or not a vendor interface exists, > > which means having to handle cleanup if a vendor-specific module gets > > loaded later. > > Getting rid of the whole ping-ponging of which backlight drivers > get loaded during boot was actually one of the goals of the rework > which landed in 6.1 this actually allowed us to remove some quirks > because some hw/firmware did not like us changing our mind and > switching backlight interfaces after first poking another one. > So we definitely don't want to go back to the ping-pong thing. Defaulting to native but then having a vendor driver be able to disable native drivers seems easiest? It shouldn't be a regression over the previous state of affairs since both drivers were being loaded already.
[PATCH 09/10] vfio: Make vfio_container optionally compiled
Add a kconfig CONFIG_VFIO_CONTAINER that controls compiling the container
code. If 'n' then only iommufd will provide the container service. All the
support for vfio iommu drivers, including type1, will not be built.
This allows a compilation check that no inappropriate dependencies between
the device/group and container have been created.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/Kconfig | 37
drivers/vfio/Makefile | 4 +--
drivers/vfio/vfio.h | 65 +++
3 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 1118d322eec97d..d384419d151dda 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -3,8 +3,8 @@ menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
select IOMMU_API
depends on IOMMUFD || !IOMMUFD
- select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
select INTERVAL_TREE
+ select VFIO_CONTAINER if IOMMUFD=n
help
VFIO provides a framework for secure userspace device drivers.
See Documentation/driver-api/vfio.rst for more details.
@@ -12,25 +12,27 @@ menuconfig VFIO
If you don't know what to do here, say N.
if VFIO
+config VFIO_CONTAINER
+ bool "Support for the VFIO container /dev/vfio/vfio"
+ select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
+ default y
+ help
+ The VFIO container is the classic interface to VFIO for establishing
+ mappings. If N is selected here then IOMMUFD must be used the manage
+ the mappings.
+
+ Unless testing IOMMUFD say Y here.
+
+if VFIO_CONTAINER
config VFIO_IOMMU_TYPE1
tristate
- default n
+ default MMU && (X86 || S390 || ARM || ARM64)
config VFIO_IOMMU_SPAPR_TCE
tristate
depends on SPAPR_TCE_IOMMU
default VFIO
-config VFIO_SPAPR_EEH
- tristate
- depends on EEH && VFIO_IOMMU_SPAPR_TCE
- default VFIO
-
-config VFIO_VIRQFD
- tristate
- select EVENTFD
- default n
-
config VFIO_NOIOMMU
bool "VFIO No-IOMMU support"
help
@@ -44,6 +46,17 @@ config VFIO_NOIOMMU
this mode since there is no IOMMU to provide DMA translation.
If you don't know what to do here, say N.
+endif
+
+config VFIO_SPAPR_EEH
+ tristate
+ depends on EEH && VFIO_IOMMU_SPAPR_TCE
+ default VFIO
+
+config VFIO_VIRQFD
+ tristate
+ select EVENTFD
+ default n
source "drivers/vfio/pci/Kconfig"
source "drivers/vfio/platform/Kconfig"
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 3863922529ef20..b953517dc70f99 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -4,9 +4,9 @@ vfio_virqfd-y := virqfd.o
obj-$(CONFIG_VFIO) += vfio.o
vfio-y += vfio_main.o \
- iova_bitmap.o \
- container.o
+ iova_bitmap.o
vfio-$(CONFIG_IOMMUFD) += iommufd.o
+vfio-$(CONFIG_VFIO_CONTAINER) += container.o
obj-$(CONFIG_VFIO_VIRQFD) += vfio_virqfd.o
obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index d57a08afb5cf5c..3378714a746274 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -55,7 +55,9 @@ struct vfio_group {
struct list_headdevice_list;
struct mutexdevice_lock;
struct list_headvfio_next;
+#if IS_ENABLED(CONFIG_VFIO_CONTAINER)
struct list_headcontainer_next;
+#endif
enum vfio_group_typetype;
struct mutexgroup_lock;
struct kvm *kvm;
@@ -64,6 +66,7 @@ struct vfio_group {
struct iommufd_ctx *iommufd;
};
+#if IS_ENABLED(CONFIG_VFIO_CONTAINER)
/* events for the backend driver notify callback */
enum vfio_iommu_notify_type {
VFIO_IOMMU_CONTAINER_CLOSE = 0,
@@ -129,6 +132,68 @@ int vfio_container_dma_rw(struct vfio_container
*container, dma_addr_t iova,
int __init vfio_container_init(void);
void vfio_container_cleanup(void);
+#else
+static inline struct vfio_container *
+vfio_container_from_file(struct file *filep)
+{
+ return NULL;
+}
+
+static inline int vfio_group_use_container(struct vfio_group *group)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline void vfio_group_unuse_container(struct vfio_group *group)
+{
+}
+
+static inline int vfio_container_attach_group(struct vfio_container *container,
+ struct vfio_group *group)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline void vfio_group_detach_container(struct vfio_group *group)
+{
+}
+
+static inline void vfio_device_container_register(struct vfio_device *device)
+{
+}
+
+static inline void vfio_device_container_unregister(struct vfio_device *device)
+{
+}
+
+static inline int
[PATCH 07/10] vfio-iommufd: Support iommufd for physical VFIO devices
This creates the iommufd_device for the physical VFIO drivers. These are
all the drivers that are calling vfio_register_group_dev() and expect the
type1 code to setup a real iommu_domain against their parent struct
device.
The design gives the driver a choice in how it gets connected to iommufd
by providing bind_iommufd/unbind_iommufd/attach_ioas callbacks to
implement as required. The core code provides three default callbacks for
physical mode using a real iommu_domain. This is suitable for drivers
using vfio_register_group_dev()
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/Makefile | 1 +
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 3 +
drivers/vfio/iommufd.c| 104 ++
.../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 6 +
drivers/vfio/pci/mlx5/main.c | 3 +
drivers/vfio/pci/vfio_pci.c | 3 +
drivers/vfio/platform/vfio_amba.c | 3 +
drivers/vfio/platform/vfio_platform.c | 3 +
drivers/vfio/vfio.h | 15 +++
drivers/vfio/vfio_main.c | 13 ++-
include/linux/vfio.h | 25 +
11 files changed, 177 insertions(+), 2 deletions(-)
create mode 100644 drivers/vfio/iommufd.c
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index b693a1169286f8..3863922529ef20 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_VFIO) += vfio.o
vfio-y += vfio_main.o \
iova_bitmap.o \
container.o
+vfio-$(CONFIG_IOMMUFD) += iommufd.o
obj-$(CONFIG_VFIO_VIRQFD) += vfio_virqfd.o
obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
index b16874e913e4f5..5cd4bb47644039 100644
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -592,6 +592,9 @@ static const struct vfio_device_ops vfio_fsl_mc_ops = {
.read = vfio_fsl_mc_read,
.write = vfio_fsl_mc_write,
.mmap = vfio_fsl_mc_mmap,
+ .bind_iommufd = vfio_iommufd_physical_bind,
+ .unbind_iommufd = vfio_iommufd_physical_unbind,
+ .attach_ioas= vfio_iommufd_physical_attach_ioas,
};
static struct fsl_mc_driver vfio_fsl_mc_driver = {
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
new file mode 100644
index 00..8280bb32ee677c
--- /dev/null
+++ b/drivers/vfio/iommufd.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021-2022, NVIDIA CORPORATION & AFFILIATES
+ */
+#include
+#include
+
+#include "vfio.h"
+
+MODULE_IMPORT_NS(IOMMUFD);
+MODULE_IMPORT_NS(IOMMUFD_VFIO);
+
+int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
+{
+ u32 ioas_id;
+ u32 device_id;
+ int ret;
+
+ lockdep_assert_held(>dev_set->lock);
+
+ /*
+* If the driver doesn't provide this op then it means the device does
+* not do DMA at all. So nothing to do.
+*/
+ if (!vdev->ops->bind_iommufd)
+ return 0;
+
+ ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
+ if (ret)
+ return ret;
+
+ if (vdev->ops->attach_ioas) {
+ ret = iommufd_vfio_compat_ioas_id(ictx, _id);
+ if (ret)
+ goto err_unbind;
+ ret = vdev->ops->attach_ioas(vdev, _id);
+ if (ret)
+ goto err_unbind;
+ vdev->iommufd_attached = true;
+ }
+
+ /*
+* The legacy path has no way to return the device id or the selected
+* pt_id
+*/
+ return 0;
+
+err_unbind:
+ if (vdev->ops->unbind_iommufd)
+ vdev->ops->unbind_iommufd(vdev);
+ return ret;
+}
+
+void vfio_iommufd_unbind(struct vfio_device *vdev)
+{
+ lockdep_assert_held(>dev_set->lock);
+
+ if (!vdev->iommufd_device)
+ return;
+
+ if (vdev->ops->unbind_iommufd)
+ vdev->ops->unbind_iommufd(vdev);
+}
+
+/*
+ * The physical standard ops mean that the iommufd_device is bound to the
+ * physical device vdev->dev that was provided to vfio_init_group_dev().
Drivers
+ * using this ops set should call vfio_register_group_dev()
+ */
+int vfio_iommufd_physical_bind(struct vfio_device *vdev,
+ struct iommufd_ctx *ictx, u32 *out_device_id)
+{
+ struct iommufd_device *idev;
+
+ idev = iommufd_device_bind(ictx, vdev->dev, out_device_id);
+ if (IS_ERR(idev))
+ return PTR_ERR(idev);
+ vdev->iommufd_device = idev;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_iommufd_physical_bind);
+
+void vfio_iommufd_physical_unbind(struct vfio_device *vdev)
+{
+ lockdep_assert_held(>dev_set->lock);
+
+ if (vdev->iommufd_attached) {
+ iommufd_device_detach(vdev->iommufd_device);
+
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi,
On 10/24/22 22:30, Matthew Garrett wrote:
> On Tue, Sep 27, 2022 at 01:04:52PM +0200, Hans de Goede wrote:
>
>> So to fix this we need to make acpi_video_get_backlight_type()
>> return native on the Acer Chromebook Spin 713.
>
> Isn't the issue broader than that? Unless the platform is Windows 8 or
> later, we'll *always* (outside of some corner cases) return
> acpi_backlight_vendor if there's no ACPI video interface. This is broken
> for any platform that implements ACPI but relies on native video
> control, which is going to include a range of Coreboot platforms, not
> just Chromebooks.
That is a valid point, but keep in mind that this is only used on ACPI
platforms and then only on devices with a builtin LCD panel and then
only by GPU drivers which actually call acpi_video_get_backlight_type(),
so e.g. not by all the ARM specific display drivers.
So I believe that Chromebooks quite likely are the only devices with
this issue.
We could do something like the patch which I have pasted at the end
of this email, but as its commit message notes there is a real
good chance this will cause regressions on some laptops.
So if we ever decide to go with something like the patch below,
I think we should at a minimum wait for the next cycle with that,
because 6.1 already significantly reworks the ACPI backlight
detect handling and I don't want to throw this into the mix
on top of those changes.
> I think for this to work correctly you need to have
> the infrastructure be aware of whether or not a vendor interface exists,
> which means having to handle cleanup if a vendor-specific module gets
> loaded later.
Getting rid of the whole ping-ponging of which backlight drivers
get loaded during boot was actually one of the goals of the rework
which landed in 6.1 this actually allowed us to remove some quirks
because some hw/firmware did not like us changing our mind and
switching backlight interfaces after first poking another one.
So we definitely don't want to go back to the ping-pong thing.
Regards,
Hans
>From 67ee5d7163e33e65dca06887befd0639b0345883 Mon Sep 17 00:00:00 2001
From: Hans de Goede
Date: Tue, 25 Oct 2022 20:38:56 +0200
Subject: [PATCH] ACPI: video: Simplify __acpi_video_get_backlight_type()
Simplify __acpi_video_get_backlight_type() removing a nested if which
makes the flow harder to follow.
Note this will cause a behavior change on devices which do not have
ACPI video support but do have both a vendor and native backlight
driver available. This change will cause these devices to switch
from vendor to native.
This may not be desirable in all cases, this is likely to happen
on significantly older laptops, where there very well might be
cases where the native driver does not work because the backlight is
controlled by the EC.
This removes the need for the special handling of Chromebooks,
these will now hit the if (native_available) return acpi_backlight_native;
path.
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 36 +++-
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 9cd8797d12bb..9bd85b159e02 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -668,11 +668,6 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
{ },
};
-static bool google_cros_ec_present(void)
-{
- return acpi_dev_found("GOOG0004");
-}
-
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
@@ -718,30 +713,21 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
if (apple_gmux_present())
return acpi_backlight_apple_gmux;
- /* On systems with ACPI video use either native or ACPI video. */
- if (video_caps & ACPI_VIDEO_BACKLIGHT) {
- /*
-* Windows 8 and newer no longer use the ACPI video interface,
-* so it often does not work. If the ACPI tables are written
-* for win8 and native brightness ctl is available, use that.
-*
-* The native check deliberately is inside the if acpi-video
-* block on older devices without acpi-video support native
-* is usually not the best choice.
-*/
- if (acpi_osi_is_win8() && native_available)
- return acpi_backlight_native;
- else
- return acpi_backlight_video;
- }
-
/*
-* Chromebooks that don't have backlight handle in ACPI table
-* are supposed to use native backlight if it's available.
+* Pre Windows 8, Windows uses ACPI video, so prefer that over native
+* on pre-win8 systems (Windows 8+ no longer uses ACPI video).
*/
- if (google_cros_ec_present() && native_available)
+
[PATCH 06/10] vfio-iommufd: Allow iommufd to be used in place of a container fd
This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD and an
iommufd.
In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will
not be attached to any groups.
>From a VFIO perspective this means that the VFIO_GROUP_GET_STATUS and
VFIO_GROUP_FLAGS_VIABLE works subtly differently. With the container FD
the iommu_group_claim_dma_owner() is done during SET_CONTAINER but for
IOMMFD this is done during VFIO_GROUP_GET_DEVICE_FD. Meaning that
VFIO_GROUP_FLAGS_VIABLE could be set but GET_DEVICE_FD will fail due to
viability.
As GET_DEVICE_FD can fail for many reasons already this is not expected to
be a meaningful difference.
Reorganize the tests for if the group has an assigned container or iommu
into a vfio_group_has_iommu() function and consolidate all the duplicated
WARN_ON's etc related to this.
Call container functions only if a container is actually present on the
group.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/container.c | 7 ++--
drivers/vfio/vfio.h | 2 ++
drivers/vfio/vfio_main.c | 76
4 files changed, 69 insertions(+), 17 deletions(-)
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 86c381ceb9a1e9..1118d322eec97d 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -2,6 +2,7 @@
menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
select IOMMU_API
+ depends on IOMMUFD || !IOMMUFD
select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
select INTERVAL_TREE
help
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index d97747dfb05d02..8772dad6808539 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -516,8 +516,11 @@ int vfio_group_use_container(struct vfio_group *group)
{
lockdep_assert_held(>group_lock);
- if (!group->container || !group->container->iommu_driver ||
- WARN_ON(!group->container_users))
+ /*
+* The container fd has been assigned with VFIO_GROUP_SET_CONTAINER but
+* VFIO_SET_IOMMU hasn't been done yet.
+*/
+ if (!group->container->iommu_driver)
return -EINVAL;
if (group->type == VFIO_NO_IOMMU && !capable(CAP_SYS_RAWIO))
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 247590334e14b0..985e13d52989ca 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -10,6 +10,7 @@
#include
#include
+struct iommufd_ctx;
struct iommu_group;
struct vfio_device;
struct vfio_container;
@@ -60,6 +61,7 @@ struct vfio_group {
struct kvm *kvm;
struct file *opened_file;
struct blocking_notifier_head notifier;
+ struct iommufd_ctx *iommufd;
};
/* events for the backend driver notify callback */
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index a8d1fbfcc3ddad..cf0ea744de931e 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "vfio.h"
#define DRIVER_VERSION "0.3"
@@ -665,6 +666,16 @@ EXPORT_SYMBOL_GPL(vfio_unregister_group_dev);
/*
* VFIO Group fd, /dev/vfio/$GROUP
*/
+static bool vfio_group_has_iommu(struct vfio_group *group)
+{
+ lockdep_assert_held(>group_lock);
+ if (!group->container)
+ WARN_ON(group->container_users);
+ else
+ WARN_ON(!group->container_users);
+ return group->container || group->iommufd;
+}
+
/*
* VFIO_GROUP_UNSET_CONTAINER should fail if there are other users or
* if there was no container to unset. Since the ioctl is called on
@@ -676,15 +687,21 @@ static int vfio_group_ioctl_unset_container(struct
vfio_group *group)
int ret = 0;
mutex_lock(>group_lock);
- if (!group->container) {
+ if (!vfio_group_has_iommu(group)) {
ret = -EINVAL;
goto out_unlock;
}
- if (group->container_users != 1) {
- ret = -EBUSY;
- goto out_unlock;
+ if (group->container) {
+ if (group->container_users != 1) {
+ ret = -EBUSY;
+ goto out_unlock;
+ }
+ vfio_group_detach_container(group);
+ }
+ if (group->iommufd) {
+ iommufd_ctx_put(group->iommufd);
+ group->iommufd = NULL;
}
- vfio_group_detach_container(group);
out_unlock:
mutex_unlock(>group_lock);
@@ -695,6 +712,7 @@ static int vfio_group_ioctl_set_container(struct vfio_group
*group,
int __user *arg)
{
struct vfio_container *container;
+ struct iommufd_ctx *iommufd;
struct fd f;
int ret;
int fd;
@@ -707,7 +725,7 @@ static int vfio_group_ioctl_set_container(struct vfio_group
*group,
[PATCH 08/10] vfio-iommufd: Support iommufd for emulated VFIO devices
Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
consist of all the mdev drivers.
Like the physical drivers, support for iommufd is provided by the driver
supplying the correct correct standard ops. Provide ops from the core that
duplicate what vfio_register_emulated_iommu_dev() does.
Emulated drivers are where it is more likely to see variation in the
iommfd support ops. For instance IDXD will probably need to setup both a
iommfd_device context linked to a PASID and an iommufd_access context to
support all their mdev operations.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +
drivers/s390/cio/vfio_ccw_ops.c | 3 +
drivers/s390/crypto/vfio_ap_ops.c | 3 +
drivers/vfio/container.c | 108 ++---
drivers/vfio/iommufd.c| 57
drivers/vfio/vfio.h | 10 ++-
drivers/vfio/vfio_main.c | 110 +-
include/linux/vfio.h | 14
8 files changed, 217 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 7a45e5360caf2d..579b230a0f58d9 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1474,6 +1474,9 @@ static const struct vfio_device_ops intel_vgpu_dev_ops = {
.mmap = intel_vgpu_mmap,
.ioctl = intel_vgpu_ioctl,
.dma_unmap = intel_vgpu_dma_unmap,
+ .bind_iommufd = vfio_iommufd_emulated_bind,
+ .unbind_iommufd = vfio_iommufd_emulated_unbind,
+ .attach_ioas= vfio_iommufd_emulated_attach_ioas,
};
static int intel_vgpu_probe(struct mdev_device *mdev)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 6ae4d012d80084..560453d99c24fc 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -588,6 +588,9 @@ static const struct vfio_device_ops vfio_ccw_dev_ops = {
.ioctl = vfio_ccw_mdev_ioctl,
.request = vfio_ccw_mdev_request,
.dma_unmap = vfio_ccw_dma_unmap,
+ .bind_iommufd = vfio_iommufd_emulated_bind,
+ .unbind_iommufd = vfio_iommufd_emulated_unbind,
+ .attach_ioas = vfio_iommufd_emulated_attach_ioas,
};
struct mdev_driver vfio_ccw_mdev_driver = {
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 0b4cc8c597ae67..bb7776d207924f 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1789,6 +1789,9 @@ static const struct vfio_device_ops
vfio_ap_matrix_dev_ops = {
.close_device = vfio_ap_mdev_close_device,
.ioctl = vfio_ap_mdev_ioctl,
.dma_unmap = vfio_ap_mdev_dma_unmap,
+ .bind_iommufd = vfio_iommufd_emulated_bind,
+ .unbind_iommufd = vfio_iommufd_emulated_unbind,
+ .attach_ioas = vfio_iommufd_emulated_attach_ioas,
};
static struct mdev_driver vfio_ap_matrix_driver = {
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index 8772dad6808539..0388f2e33447eb 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -540,113 +540,45 @@ void vfio_group_unuse_container(struct vfio_group *group)
fput(group->opened_file);
}
-/*
- * Pin contiguous user pages and return their associated host pages for local
- * domain only.
- * @device [in] : device
- * @iova [in]: starting IOVA of user pages to be pinned.
- * @npage [in] : count of pages to be pinned. This count should not
- *be greater than VFIO_PIN_PAGES_MAX_ENTRIES.
- * @prot [in]: protection flags
- * @pages[out] : array of host pages
- * Return error or number of pages pinned.
- *
- * A driver may only call this function if the vfio_device was created
- * by vfio_register_emulated_iommu_dev().
- */
-int vfio_pin_pages(struct vfio_device *device, dma_addr_t iova,
- int npage, int prot, struct page **pages)
+int vfio_container_pin_pages(struct vfio_container *container,
+struct iommu_group *iommu_group, dma_addr_t iova,
+int npage, int prot, struct page **pages)
{
- struct vfio_container *container;
- struct vfio_group *group = device->group;
- struct vfio_iommu_driver *driver;
- int ret;
-
- if (!pages || !npage || !vfio_assert_device_open(device))
- return -EINVAL;
+ /* group->container cannot change while a vfio device is open */
+ struct vfio_iommu_driver *driver = container->iommu_driver;
if (npage > VFIO_PIN_PAGES_MAX_ENTRIES)
return -E2BIG;
/* group->container cannot change while a vfio device is open */
- container = group->container;
driver = container->iommu_driver;
- if (likely(driver && driver->ops->pin_pages))
- ret = driver->ops->pin_pages(container->iommu_data,
-
[PATCH 10/10] iommufd: Allow iommufd to supply /dev/vfio/vfio
If the VFIO container is compiled out, give a kconfig option for iommufd
to provide the miscdev node with the same name and permissions as vfio
uses.
The compatibility node supports the same ioctls as VFIO and automatically
enables the VFIO compatible pinned page accounting mode.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommufd/Kconfig | 12
drivers/iommu/iommufd/main.c | 35 ---
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iommufd/Kconfig b/drivers/iommu/iommufd/Kconfig
index f0a2012234fa09..afc83b7575cce6 100644
--- a/drivers/iommu/iommufd/Kconfig
+++ b/drivers/iommu/iommufd/Kconfig
@@ -14,6 +14,18 @@ config IOMMUFD
If you don't know what to do here, say N.
if IOMMUFD
+config IOMMUFD_VFIO_CONTAINER
+ bool "IOMMUFD provides the VFIO container /dev/vfio/vfio"
+ depends on VFIO && !VFIO_CONTAINER
+ default VFIO && !VFIO_CONTAINER
+ help
+ IOMMUFD will provide /dev/vfio/vfio instead of VFIO. This relies on
+ IOMMUFD providing compatibility emulation to give the same ioctls.
+ It provides an option to build a kernel with legacy VFIO components
+ removed.
+
+ Unless testing IOMMUFD say N here.
+
config IOMMUFD_TEST
bool "IOMMU Userspace API Test support"
depends on RUNTIME_TESTING_MENU
diff --git a/drivers/iommu/iommufd/main.c b/drivers/iommu/iommufd/main.c
index 8a31c1a14cdd53..19db81fbf7f08f 100644
--- a/drivers/iommu/iommufd/main.c
+++ b/drivers/iommu/iommufd/main.c
@@ -24,6 +24,7 @@
#include
#include
+#include "io_pagetable.h"
#include "iommufd_private.h"
#include "iommufd_test.h"
@@ -31,6 +32,7 @@ struct iommufd_object_ops {
void (*destroy)(struct iommufd_object *obj);
};
static struct iommufd_object_ops iommufd_object_ops[];
+static struct miscdevice vfio_misc_dev;
struct iommufd_object *_iommufd_object_alloc(struct iommufd_ctx *ictx,
size_t size,
@@ -167,6 +169,13 @@ static int iommufd_fops_open(struct inode *inode, struct
file *filp)
if (!ictx)
return -ENOMEM;
+ /*
+* For compatibility with VFIO when /dev/vfio/vfio is opened we default
+* to the same rlimit accounting as vfio uses.
+*/
+ if (filp->private_data == _misc_dev)
+ ictx->account_mode = IOPT_PAGES_ACCOUNT_MM;
+
xa_init_flags(>objects, XA_FLAGS_ALLOC1 | XA_FLAGS_ACCOUNT);
ictx->file = filp;
filp->private_data = ictx;
@@ -392,26 +401,46 @@ static struct miscdevice iommu_misc_dev = {
.mode = 0660,
};
+
+static struct miscdevice vfio_misc_dev = {
+ .minor = VFIO_MINOR,
+ .name = "vfio",
+ .fops = _fops,
+ .nodename = "vfio/vfio",
+ .mode = 0666,
+};
+
static int __init iommufd_init(void)
{
int ret;
ret = misc_register(_misc_dev);
- if (ret) {
- pr_err("Failed to register misc device\n");
+ if (ret)
return ret;
- }
+ if (IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER)) {
+ ret = misc_register(_misc_dev);
+ if (ret)
+ goto err_misc;
+ }
return 0;
+err_misc:
+ misc_deregister(_misc_dev);
+ return ret;
}
static void __exit iommufd_exit(void)
{
+ if (IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER))
+ misc_deregister(_misc_dev);
misc_deregister(_misc_dev);
}
module_init(iommufd_init);
module_exit(iommufd_exit);
+#if IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER)
+MODULE_ALIAS_MISCDEV(VFIO_MINOR);
+#endif
MODULE_DESCRIPTION("I/O Address Space Management for passthrough devices");
MODULE_LICENSE("GPL");
--
2.38.0
[PATCH 01/10] vfio: Move vfio_device driver open/close code to a function
This error unwind is getting complicated. Move all the code into two
pair'd function. The functions should be called when the open_count == 1
after incrementing/before decrementing.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio_main.c | 95 ++--
1 file changed, 53 insertions(+), 42 deletions(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 2d168793d4e1ce..d043383fc3ba2b 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -734,6 +734,51 @@ bool vfio_assert_device_open(struct vfio_device *device)
return !WARN_ON_ONCE(!READ_ONCE(device->open_count));
}
+static int vfio_device_first_open(struct vfio_device *device)
+{
+ int ret;
+
+ lockdep_assert_held(>dev_set->lock);
+
+ if (!try_module_get(device->dev->driver->owner))
+ return -ENODEV;
+
+ /*
+* Here we pass the KVM pointer with the group under the read lock. If
+* the device driver will use it, it must obtain a reference and release
+* it during close_device.
+*/
+ mutex_lock(>group->group_lock);
+ device->kvm = device->group->kvm;
+ if (device->ops->open_device) {
+ ret = device->ops->open_device(device);
+ if (ret)
+ goto err_module_put;
+ }
+ vfio_device_container_register(device);
+ mutex_unlock(>group->group_lock);
+ return 0;
+
+err_module_put:
+ device->kvm = NULL;
+ mutex_unlock(>group->group_lock);
+ module_put(device->dev->driver->owner);
+ return ret;
+}
+
+static void vfio_device_last_close(struct vfio_device *device)
+{
+ lockdep_assert_held(>dev_set->lock);
+
+ mutex_lock(>group->group_lock);
+ vfio_device_container_unregister(device);
+ if (device->ops->close_device)
+ device->ops->close_device(device);
+ device->kvm = NULL;
+ mutex_unlock(>group->group_lock);
+ module_put(device->dev->driver->owner);
+}
+
static struct file *vfio_device_open(struct vfio_device *device)
{
struct file *filep;
@@ -745,29 +790,12 @@ static struct file *vfio_device_open(struct vfio_device
*device)
if (ret)
return ERR_PTR(ret);
- if (!try_module_get(device->dev->driver->owner)) {
- ret = -ENODEV;
- goto err_unassign_container;
- }
-
mutex_lock(>dev_set->lock);
device->open_count++;
if (device->open_count == 1) {
- /*
-* Here we pass the KVM pointer with the group under the read
-* lock. If the device driver will use it, it must obtain a
-* reference and release it during close_device.
-*/
- mutex_lock(>group->group_lock);
- device->kvm = device->group->kvm;
-
- if (device->ops->open_device) {
- ret = device->ops->open_device(device);
- if (ret)
- goto err_undo_count;
- }
- vfio_device_container_register(device);
- mutex_unlock(>group->group_lock);
+ ret = vfio_device_first_open(device);
+ if (ret)
+ goto err_unassign_container;
}
mutex_unlock(>dev_set->lock);
@@ -800,20 +828,11 @@ static struct file *vfio_device_open(struct vfio_device
*device)
err_close_device:
mutex_lock(>dev_set->lock);
- mutex_lock(>group->group_lock);
- if (device->open_count == 1 && device->ops->close_device) {
- device->ops->close_device(device);
-
- vfio_device_container_unregister(device);
- }
-err_undo_count:
- mutex_unlock(>group->group_lock);
+ if (device->open_count == 1)
+ vfio_device_last_close(device);
+err_unassign_container:
device->open_count--;
- if (device->open_count == 0 && device->kvm)
- device->kvm = NULL;
mutex_unlock(>dev_set->lock);
- module_put(device->dev->driver->owner);
-err_unassign_container:
vfio_device_unassign_container(device);
return ERR_PTR(ret);
}
@@ -1016,19 +1035,11 @@ static int vfio_device_fops_release(struct inode
*inode, struct file *filep)
mutex_lock(>dev_set->lock);
vfio_assert_device_open(device);
- mutex_lock(>group->group_lock);
- if (device->open_count == 1 && device->ops->close_device)
- device->ops->close_device(device);
-
- vfio_device_container_unregister(device);
- mutex_unlock(>group->group_lock);
+ if (device->open_count == 1)
+ vfio_device_last_close(device);
device->open_count--;
- if (device->open_count == 0)
- device->kvm = NULL;
mutex_unlock(>dev_set->lock);
- module_put(device->dev->driver->owner);
-
[PATCH 02/10] vfio: Move vfio_device_assign_container() into vfio_device_first_open()
The only thing this function does is assert the group has an assigned
container and incrs refcounts.
The overall model we have is that once a conatiner_users refcount is
incremented it cannot be de-assigned from the group -
vfio_group_ioctl_unset_container() will fail and the group FD cannot be
closed.
Thus we do not need to check this on evey device FD open, just the
first. Reorganize the code so that only the first open and last close
manages the container.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/container.c | 4 ++--
drivers/vfio/vfio_main.c | 18 --
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index d74164abbf401d..dd79a66ec62cad 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -531,11 +531,11 @@ int vfio_device_assign_container(struct vfio_device
*device)
void vfio_device_unassign_container(struct vfio_device *device)
{
- mutex_lock(>group->group_lock);
+ lockdep_assert_held_write(>group->group_lock);
+
WARN_ON(device->group->container_users <= 1);
device->group->container_users--;
fput(device->group->opened_file);
- mutex_unlock(>group->group_lock);
}
/*
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index d043383fc3ba2b..204443ba3b3cd9 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -749,16 +749,22 @@ static int vfio_device_first_open(struct vfio_device
*device)
* it during close_device.
*/
mutex_lock(>group->group_lock);
+ ret = vfio_device_assign_container(device);
+ if (ret)
+ goto err_module_put;
+
device->kvm = device->group->kvm;
if (device->ops->open_device) {
ret = device->ops->open_device(device);
if (ret)
- goto err_module_put;
+ goto err_container;
}
vfio_device_container_register(device);
mutex_unlock(>group->group_lock);
return 0;
+err_container:
+ vfio_device_unassign_container(device);
err_module_put:
device->kvm = NULL;
mutex_unlock(>group->group_lock);
@@ -775,6 +781,7 @@ static void vfio_device_last_close(struct vfio_device
*device)
if (device->ops->close_device)
device->ops->close_device(device);
device->kvm = NULL;
+ vfio_device_unassign_container(device);
mutex_unlock(>group->group_lock);
module_put(device->dev->driver->owner);
}
@@ -784,12 +791,6 @@ static struct file *vfio_device_open(struct vfio_device
*device)
struct file *filep;
int ret;
- mutex_lock(>group->group_lock);
- ret = vfio_device_assign_container(device);
- mutex_unlock(>group->group_lock);
- if (ret)
- return ERR_PTR(ret);
-
mutex_lock(>dev_set->lock);
device->open_count++;
if (device->open_count == 1) {
@@ -833,7 +834,6 @@ static struct file *vfio_device_open(struct vfio_device
*device)
err_unassign_container:
device->open_count--;
mutex_unlock(>dev_set->lock);
- vfio_device_unassign_container(device);
return ERR_PTR(ret);
}
@@ -1040,8 +1040,6 @@ static int vfio_device_fops_release(struct inode *inode,
struct file *filep)
device->open_count--;
mutex_unlock(>dev_set->lock);
- vfio_device_unassign_container(device);
-
vfio_device_put_registration(device);
return 0;
--
2.38.0
[PATCH 05/10] vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for vfio_file_enforced_coherent()
iommufd doesn't establish the iommu_domains until after the device FD is
opened, even if the container has been set. This design is part of moving
away from the group centric iommu APIs.
This is fine, except that the normal sequence of establishing the kvm
wbindv won't work:
group = open("/dev/vfio/XX")
ioctl(group, VFIO_GROUP_SET_CONTAINER)
ioctl(kvm, KVM_DEV_VFIO_GROUP_ADD)
ioctl(group, VFIO_GROUP_GET_DEVICE_FD)
As the domains don't start existing until GET_DEVICE_FD. Further,
GET_DEVICE_FD requires that KVM_DEV_VFIO_GROUP_ADD already be done as that
is what sets the group->kvm and thus device->kvm for the driver to use
during open.
Now that we have device centric cap ops and the new
IOMMU_CAP_ENFORCE_CACHE_COHERENCY we know what the iommu_domain will be
capable of without having to create it. Use this to compute
vfio_file_enforced_coherent() and resolve the ordering problems.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/container.c | 5 +++--
drivers/vfio/vfio.h | 2 --
drivers/vfio/vfio_main.c | 27 ++-
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index 499777930b08fa..d97747dfb05d02 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -188,8 +188,9 @@ void vfio_device_container_unregister(struct vfio_device
*device)
device->group->container->iommu_data, device);
}
-long vfio_container_ioctl_check_extension(struct vfio_container *container,
- unsigned long arg)
+static long
+vfio_container_ioctl_check_extension(struct vfio_container *container,
+unsigned long arg)
{
struct vfio_iommu_driver *driver;
long ret = 0;
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 54e5a8e0834ccb..247590334e14b0 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -119,8 +119,6 @@ int vfio_container_attach_group(struct vfio_container
*container,
void vfio_group_detach_container(struct vfio_group *group);
void vfio_device_container_register(struct vfio_device *device);
void vfio_device_container_unregister(struct vfio_device *device);
-long vfio_container_ioctl_check_extension(struct vfio_container *container,
- unsigned long arg);
int __init vfio_container_init(void);
void vfio_container_cleanup(void);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 1e414b2c48a511..a8d1fbfcc3ddad 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -1625,24 +1625,25 @@ EXPORT_SYMBOL_GPL(vfio_file_is_group);
bool vfio_file_enforced_coherent(struct file *file)
{
struct vfio_group *group = file->private_data;
- bool ret;
+ struct vfio_device *device;
+ bool ret = true;
if (!vfio_file_is_group(file))
return true;
- mutex_lock(>group_lock);
- if (group->container) {
- ret = vfio_container_ioctl_check_extension(group->container,
- VFIO_DMA_CC_IOMMU);
- } else {
- /*
-* Since the coherency state is determined only once a container
-* is attached the user must do so before they can prove they
-* have permission.
-*/
- ret = true;
+ /*
+* If the device does not have IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
+* any domain later attached to it will also not support it.
+*/
+ mutex_lock(>device_lock);
+ list_for_each_entry(device, >device_list, group_next) {
+ if (!device_iommu_capable(device->dev,
+ IOMMU_CAP_ENFORCE_CACHE_COHERENCY)) {
+ ret = false;
+ break;
+ }
}
- mutex_unlock(>group_lock);
+ mutex_unlock(>device_lock);
return ret;
}
EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
--
2.38.0
[PATCH 00/10] Connect VFIO to IOMMUFD
This series provides an alternative container layer for VFIO implemented using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will not be compiled in. At this point iommufd can be injected by passing in a iommfd FD to VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer in iommufd to obtain the compat IOAS and then connect up all the VFIO drivers as appropriate. This is temporary stopping point, a following series will provide a way to directly open a VFIO device FD and directly connect it to IOMMUFD using native ioctls that can expose the IOMMUFD features like hwpt, future vPASID and dynamic attachment. This series, in compat mode, has passed all the qemu tests we have available, including the test suites for the Intel GVT mdev. Aside from the temporary limitation with P2P memory this is belived to be fully compatible with VFIO. This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd It requires the iommufd series: https://lore.kernel.org/r/0-v3-402a7d6459de+24b-iommufd_...@nvidia.com Jason Gunthorpe (10): vfio: Move vfio_device driver open/close code to a function vfio: Move vfio_device_assign_container() into vfio_device_first_open() vfio: Rename vfio_device_assign/unassign_container() vfio: Move storage of allow_unsafe_interrupts to vfio_main.c vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for vfio_file_enforced_coherent() vfio-iommufd: Allow iommufd to be used in place of a container fd vfio-iommufd: Support iommufd for physical VFIO devices vfio-iommufd: Support iommufd for emulated VFIO devices vfio: Make vfio_container optionally compiled iommufd: Allow iommufd to supply /dev/vfio/vfio drivers/gpu/drm/i915/gvt/kvmgt.c | 3 + drivers/iommu/iommufd/Kconfig | 12 + drivers/iommu/iommufd/main.c | 35 +- drivers/s390/cio/vfio_ccw_ops.c | 3 + drivers/s390/crypto/vfio_ap_ops.c | 3 + drivers/vfio/Kconfig | 38 ++- drivers/vfio/Makefile | 5 +- drivers/vfio/container.c | 136 ++-- drivers/vfio/fsl-mc/vfio_fsl_mc.c | 3 + drivers/vfio/iommufd.c| 161 + .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 6 + drivers/vfio/pci/mlx5/main.c | 3 + drivers/vfio/pci/vfio_pci.c | 3 + drivers/vfio/platform/vfio_amba.c | 3 + drivers/vfio/platform/vfio_platform.c | 3 + drivers/vfio/vfio.h | 100 +- drivers/vfio/vfio_iommu_type1.c | 5 +- drivers/vfio/vfio_main.c | 318 ++ include/linux/vfio.h | 39 +++ 19 files changed, 681 insertions(+), 198 deletions(-) create mode 100644 drivers/vfio/iommufd.c base-commit: 3bec937e94942a6aee8854be1c1f5cc2b92d15e2 -- 2.38.0
[PATCH 03/10] vfio: Rename vfio_device_assign/unassign_container()
These functions don't really assign anything anymore, they just increment
some refcounts and do a sanity check. Call them
vfio_group_[un]use_container()
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/container.c | 14 ++
drivers/vfio/vfio.h | 4 ++--
drivers/vfio/vfio_main.c | 6 +++---
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index dd79a66ec62cad..499777930b08fa 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -511,10 +511,8 @@ void vfio_group_detach_container(struct vfio_group *group)
vfio_container_put(container);
}
-int vfio_device_assign_container(struct vfio_device *device)
+int vfio_group_use_container(struct vfio_group *group)
{
- struct vfio_group *group = device->group;
-
lockdep_assert_held(>group_lock);
if (!group->container || !group->container->iommu_driver ||
@@ -529,13 +527,13 @@ int vfio_device_assign_container(struct vfio_device
*device)
return 0;
}
-void vfio_device_unassign_container(struct vfio_device *device)
+void vfio_group_unuse_container(struct vfio_group *group)
{
- lockdep_assert_held_write(>group->group_lock);
+ lockdep_assert_held(>group_lock);
- WARN_ON(device->group->container_users <= 1);
- device->group->container_users--;
- fput(device->group->opened_file);
+ WARN_ON(group->container_users <= 1);
+ group->container_users--;
+ fput(group->opened_file);
}
/*
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index bcad54bbab08c4..f95f4925b83bbd 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -112,8 +112,8 @@ void vfio_unregister_iommu_driver(const struct
vfio_iommu_driver_ops *ops);
bool vfio_assert_device_open(struct vfio_device *device);
struct vfio_container *vfio_container_from_file(struct file *filep);
-int vfio_device_assign_container(struct vfio_device *device);
-void vfio_device_unassign_container(struct vfio_device *device);
+int vfio_group_use_container(struct vfio_group *group);
+void vfio_group_unuse_container(struct vfio_group *group);
int vfio_container_attach_group(struct vfio_container *container,
struct vfio_group *group);
void vfio_group_detach_container(struct vfio_group *group);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 204443ba3b3cd9..8d809ecd982b39 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -749,7 +749,7 @@ static int vfio_device_first_open(struct vfio_device
*device)
* it during close_device.
*/
mutex_lock(>group->group_lock);
- ret = vfio_device_assign_container(device);
+ ret = vfio_group_use_container(device->group);
if (ret)
goto err_module_put;
@@ -764,7 +764,7 @@ static int vfio_device_first_open(struct vfio_device
*device)
return 0;
err_container:
- vfio_device_unassign_container(device);
+ vfio_group_unuse_container(device->group);
err_module_put:
device->kvm = NULL;
mutex_unlock(>group->group_lock);
@@ -781,7 +781,7 @@ static void vfio_device_last_close(struct vfio_device
*device)
if (device->ops->close_device)
device->ops->close_device(device);
device->kvm = NULL;
- vfio_device_unassign_container(device);
+ vfio_group_unuse_container(device->group);
mutex_unlock(>group->group_lock);
module_put(device->dev->driver->owner);
}
--
2.38.0
[PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
This legacy module knob has become uAPI, when set on the vfio_iommu_type1
it disables some security protections in the iommu drivers. Move the
storage for this knob to vfio_main.c so that iommufd can access it too.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.h | 2 ++
drivers/vfio/vfio_iommu_type1.c | 5 ++---
drivers/vfio/vfio_main.c| 3 +++
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index f95f4925b83bbd..54e5a8e0834ccb 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -130,4 +130,6 @@ extern bool vfio_noiommu __read_mostly;
enum { vfio_noiommu = false };
#endif
+extern bool vfio_allow_unsafe_interrupts;
+
#endif
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 23c24fe98c00d4..186e33a006d314 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -44,9 +44,8 @@
#define DRIVER_AUTHOR "Alex Williamson "
#define DRIVER_DESC "Type1 IOMMU driver for VFIO"
-static bool allow_unsafe_interrupts;
module_param_named(allow_unsafe_interrupts,
- allow_unsafe_interrupts, bool, S_IRUGO | S_IWUSR);
+ vfio_allow_unsafe_interrupts, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(allow_unsafe_interrupts,
"Enable VFIO IOMMU support for on platforms without interrupt
remapping support.");
@@ -2282,7 +2281,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
iommu_group_for_each_dev(iommu_group, (void
*)IOMMU_CAP_INTR_REMAP,
vfio_iommu_device_capable);
- if (!allow_unsafe_interrupts && !msi_remap) {
+ if (!vfio_allow_unsafe_interrupts && !msi_remap) {
pr_warn("%s: No interrupt remapping support. Use the module
param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this
platform\n",
__func__);
ret = -EPERM;
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 8d809ecd982b39..1e414b2c48a511 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -51,6 +51,9 @@ static struct vfio {
struct ida device_ida;
} vfio;
+bool vfio_allow_unsafe_interrupts;
+EXPORT_SYMBOL_GPL(vfio_allow_unsafe_interrupts);
+
static DEFINE_XARRAY(vfio_device_set_xa);
static const struct file_operations vfio_group_fops;
--
2.38.0
Re: [PATCH] drm/scheduler: set current_entity to next when remove from rq
Looking... Regards, Luben On 2022-10-25 09:35, Alex Deucher wrote: > + Luben > > On Tue, Oct 25, 2022 at 2:55 AM brolerliew wrote: >> >> When entity move from one rq to another, current_entity will be set to NULL >> if it is the moving entity. This make entities close to rq head got >> selected more frequently, especially when doing load balance between >> multiple drm_gpu_scheduler. >> >> Make current_entity to next when removing from rq. >> >> Signed-off-by: brolerliew >> --- >> drivers/gpu/drm/scheduler/sched_main.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_main.c >> b/drivers/gpu/drm/scheduler/sched_main.c >> index 2fab218d7082..00b22cc50f08 100644 >> --- a/drivers/gpu/drm/scheduler/sched_main.c >> +++ b/drivers/gpu/drm/scheduler/sched_main.c >> @@ -168,10 +168,11 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq >> *rq, >> spin_lock(>lock); >> >> atomic_dec(rq->sched->score); >> - list_del_init(>list); >> >> if (rq->current_entity == entity) >> - rq->current_entity = NULL; >> + rq->current_entity = list_next_entry(entity, list); >> + >> + list_del_init(>list); >> >> if (drm_sched_policy == DRM_SCHED_POLICY_FIFO) >> drm_sched_rq_remove_fifo_locked(entity); >> -- >> 2.34.1 >>
Re: [Intel-gfx] [PATCH v2] drm/ttm: rework on ttm_resource to use size_t type
On Tue, 25 Oct 2022 at 16:51, Somalapuram Amaranath wrote: > > Change ttm_resource structure from num_pages to size_t size in bytes. > v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages > v1 -> v2: change bo->resource->size to bo->base.size at some places > v1 -> v2: remove the local variable > v1 -> v2: cleanup cmp_size_smaller_first() > > Signed-off-by: Somalapuram Amaranath > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++-- > drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 > drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +- > drivers/gpu/drm/i915/i915_scatterlist.c| 4 ++-- > drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++-- > drivers/gpu/drm/i915/intel_region_ttm.c| 2 +- > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++--- > drivers/gpu/drm/nouveau/nouveau_mem.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- > drivers/gpu/drm/radeon/radeon_cs.c | 7 +-- > drivers/gpu/drm/radeon/radeon_object.c | 4 ++-- > drivers/gpu/drm/radeon/radeon_trace.h | 2 +- > drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++-- > drivers/gpu/drm/ttm/ttm_bo.c | 3 --- > drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++--- > drivers/gpu/drm/ttm/ttm_bo_vm.c| 4 ++-- > drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +- > drivers/gpu/drm/ttm/ttm_resource.c | 14 ++ > drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++-- > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 6 +++--- > drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++--- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 6 +++--- > include/drm/ttm/ttm_resource.h | 4 ++-- > 38 files changed, 79 insertions(+), 81 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c > index 38119311284d..f86dc92965bb 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c > @@ -217,7 +217,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf, > page_last = vma_pages(vma) + vma->vm_pgoff - > drm_vma_node_start(>base.vma_node); > > - if (unlikely(page_offset >= bo->resource->num_pages)) > + if (unlikely(page_offset >= bo->base.size)) At a glance it looks like we are missing PFN_UP(bo->base.size) for this one?
Re: [PATCH v2] drm/ttm: rework on ttm_resource to use size_t type
Am 25.10.22 um 17:50 schrieb Somalapuram Amaranath:
Change ttm_resource structure from num_pages to size_t size in bytes.
v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages
v1 -> v2: change bo->resource->size to bo->base.size at some places
v1 -> v2: remove the local variable
v1 -> v2: cleanup cmp_size_smaller_first()
Of hand that looks good to me now.
It would be nice if we keep the separation of one patch for each driver.
But that would mean we need something like adding the size field first,
patch all drivers and then remove num_pages which isn't a good approach
either.
But please make sure that the Intel CI systems are happy with that.
Signed-off-by: Somalapuram Amaranath
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/i915/i915_scatterlist.c| 4 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
drivers/gpu/drm/i915/intel_region_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_mem.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 7 +--
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 6 +++---
include/drm/ttm/ttm_resource.h | 4 ++--
38 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
- node->mm_nodes[0].size = node->base.num_pages;
+ node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 2e8f6cd7a729..974e85d8b6cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
- r = ttm_bo_kmap(>tbo, 0, bo->tbo.resource->num_pages, >kmap);
+ r = ttm_bo_kmap(>tbo, 0, PFN_UP(bo->tbo.base.size), >kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
[Bug 216625] [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Any chance you could bisect? There have been very few changes to the radeon kernel driver over the last few years. I could also be a mesa regression. Does upgrading or downgrading mesa help? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: IMX6 etnaviv issue
On Sat, Oct 22, 2022 at 7:06 PM Chris Healy wrote: > > I can't speak to why you are experiencing issues when using the GPU, > but in the examples you gave, the example that is working is using a > SW based GL implementation instead of the real GPU. This can be > determined by looking at the GL_RENDERER string to see if it mentions > a Vivante GPU or something else (like LLVMPIPE). It's quite likely > that if you were using the real GPU with etnaviv in Mesa with the > older config you would also experience similar issues. As such, we > shouldn't consider this a regression between the two Ubuntu versions. Chris, Thanks for this insight. I was curious about the meaning of the GL_RENDERER string which is why I included that. I'm not clear how to configure what renderer is used? Best Regards, Tim > > One thing you may want to try doing is run with Mesa 22.2.1 and TOT to > see if either of these address any of the issues you are experiencing. > > On Thu, Oct 20, 2022 at 1:44 PM Tim Harvey wrote: > > > > Greetings, > > > > I use a standard Ubuntu 20.04 focal rootfs with a mainline kernel on > > an IMX6Q based board and have had no issues using things like gnome > > desktop, glxgears, glmark2 however recently I updated the rootfs to > > Ubuntu 22.04 jammy using the same mainline kernel and now I see some > > issues. I've replicated the issue with several kernel versions > > including 5.4, 5.10, 5.15 and 6.0 so I would say this is not a kernel > > regression but something related to the graphics stack being used > > which I'm not very familiar with. > > > > The issues I see can be described as: > > - mouse cursor is incorrect (looks like a hatched square) > > - glxgears shows some sort of sync/jitter issue and has a fairly low > > framerate > > - glmark2 shows a some sync issues then after a few seconds results in > > a GPU hang > > > > My ubuntu focal image that appears to work fine has the following: > > gnome 3.36.5-0 > > xserver-xorg 1:7.7+19 > > xserver-xorg-core 2:1.20.13-1 > > xwayland 2:1.20.13-1 > > glmark2 2021.02 > > mesa-utils 8.4.0-1 > > GL_VENDOR: Mesa/X.org > > GL_RENDERER: llvmpipe (LLVM 12.0.0, 128 bits) > > GL_VERSION: 3.1 Mesa 21.2.6 > > > > My ubuntu jammy image that has the issues has the following: > > gnome-41.7-0 > > xserver-xorg 1:7.7+23 > > xserver-xorg-core 2:21.1.3-2 > > xwayland 2:22.1.1-1 > > glmark2 2021.02-0 > > mesa-utils 8.4.0-1 > > GL_VENDOR: etnaviv > > GL_RENDERER: Vivantte GC2000 rev 5108 > > GL_VERSION: 2.1 Mesa 22.0.5 > > > > Does anyone have any ideas on what might be going on here? I apologize > > for my lack of knowledge regarding the software layers on top of the > > etnaviv kernel driver being used here. > > > > Best Regards, > > > > Tim
Re: [PATCH 1/2] drm: remove DRM_MINOR_CONTROL
Am 25.10.22 um 15:59 schrieb Michał Winiarski:
On Tue, Oct 11, 2022 at 01:55:01PM +0200, Christian König wrote:
Am 11.10.22 um 13:39 schrieb Simon Ser:
On Tuesday, October 11th, 2022 at 13:04, Christian König
wrote:
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -54,7 +54,6 @@ struct file;
*/
enum drm_minor_type {
DRM_MINOR_PRIMARY,
- DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
};
This makes me uncomfortable: this enum no longer matches DRM_NODE_* in
libdrm.
Ah! There it was! I was remembering in the back of my head that we had
somehow used this in libdrm as well, but couldn't really get where exactly.
But I don't really see a problem here. The control nodes are identified by
name and we don't expose them for quite some time now without any negative
impact.
Even the minor number distribution stays the same. So what bad can come from
this?
Thanks,
Christian.
I proposed something similar in:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20220817230600.272790-1-michal.winiarski%40intel.com%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C085831b6e1b647ca1dbd08dab6911b4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023031607291573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=56FxZ4UThGlbJ0ut8biicsYtIvtTZ8RGHISJqe%2BXixY%3Dreserved=0
except acompanied by expanding the minor pool to accomodate more than
128 devices:
And after receiving similar feedback, that eventually evolved into
leaving the "legacy minors" alone, and changing the rules only for cases
where we have more than 64 devices (when we run out of the "legacy
minors").
Perhaps something like this:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20220911211443.581481-1-michal.winiarski%40intel.com%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C085831b6e1b647ca1dbd08dab6911b4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023031607291573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=dFRTx0%2Fi7a4aps57JWGtEJ6GoW5IfI5CQjFkig4KFnA%3Dreserved=0
Would work for your usecase as well?
We don't desperately need the additional minor numbers, this was merely
just a cleanup to remove an unused define.
Christian.
-Michał
[Bug 216625] [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 Pierre Ossman (pierre-bugzi...@ossman.eu) changed: What|Removed |Added Tree|Mainline|Fedora -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216625] New: [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 Bug ID: 216625 Summary: [regression] GPU lockup on Radeon R7 Kaveri Product: Drivers Version: 2.5 Kernel Version: 5.19.16-100.fc35.x86_64 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: pierre-bugzi...@ossman.eu Regression: No Created attachment 303084 --> https://bugzilla.kernel.org/attachment.cgi?id=303084=edit dmesg since problems began Ever since I upgraded from Fedora 34 to Fedora 35 I've gotten random GPU lockups. This machine has otherwise been stable for years. I don't really know what triggers the issue. I *think* it happens in some cases when I try to play a video in Firefox, but I'm not completely sure. Reported here, but Fedora generally don't give any attention to GPU driver issues: https://bugzilla.redhat.com/show_bug.cgi?id=2131923 Last working system: kernel-5.13.8-100.fc33.x86_64 libglvnd-1:1.3.3-1.fc34.x86_64 mesa-libGL-21.1.8-3.fc34.x86_64 libdrm-2.4.109-1.fc34.x86_64 xorg-x11-server-Xorg-1.20.14-3.fc34.x86_64 First broken system: kernel-5.19.8-100.fc35.x86_64 libglvnd-1:1.3.4-2.fc35.x86_64 mesa-libGL-21.3.9-1.fc35.x86_64 libdrm-2.4.110-1.fc35.x86_64 xorg-x11-server-Xorg-1.20.14-7.fc35.x86_64 Attached is all kernel logs since the issue started happening. It also includes a fresh boot from the last good kernel, and a good run with the new kernel. I think that first run with the new kernel was just a fluke, though. The only package upgraded after the system upgrade and before the lockups started is annobin. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2] drm/ttm: rework on ttm_resource to use size_t type
Change ttm_resource structure from num_pages to size_t size in bytes.
v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages
v1 -> v2: change bo->resource->size to bo->base.size at some places
v1 -> v2: remove the local variable
v1 -> v2: cleanup cmp_size_smaller_first()
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/i915/i915_scatterlist.c| 4 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
drivers/gpu/drm/i915/intel_region_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_mem.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 7 +--
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 6 +++---
include/drm/ttm/ttm_resource.h | 4 ++--
38 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
- node->mm_nodes[0].size = node->base.num_pages;
+ node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 2e8f6cd7a729..974e85d8b6cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
- r = ttm_bo_kmap(>tbo, 0, bo->tbo.resource->num_pages, >kmap);
+ r = ttm_bo_kmap(>tbo, 0, PFN_UP(bo->tbo.base.size), >kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
goto fallback;
- BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
+ BUG_ON(start + size > res->size);
cur->mem_type = res->mem_type;
@@ -110,7 +110,7 @@ static inline void amdgpu_res_first(struct ttm_resource
*res,
cur->size = size;
cur->remaining = size;
cur->node = NULL;
- WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
+ WARN_ON(res && start + size > res->size);
return;
[PATCH] drm/panel: khadas-ts050: update timings to achieve 60Hz refresh rate
From: Neil Armstrong
This updates the panel timings to achieve a clean 60Hz refresh rate.
Signed-off-by: Neil Armstrong
---
To: Sam Ravnborg
To: David Airlie
To: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/panel/panel-khadas-ts050.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c
b/drivers/gpu/drm/panel/panel-khadas-ts050.c
index 1ab1ebe30882..e0cebfa14b36 100644
--- a/drivers/gpu/drm/panel/panel-khadas-ts050.c
+++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
@@ -568,7 +568,7 @@ static const struct khadas_ts050_panel_cmd init_code[] = {
{0xfb, 0x01},
/* Select CMD1 */
{0xff, 0x00},
- {0xd3, 0x05}, /* RGBMIPICTRL: VSYNC back porch = 5 */
+ {0xd3, 0x22}, /* RGBMIPICTRL: VSYNC back porch = 34 */
{0xd4, 0x04}, /* RGBMIPICTRL: VSYNC front porch = 4 */
};
@@ -717,15 +717,15 @@ static int khadas_ts050_panel_disable(struct drm_panel
*panel)
}
static const struct drm_display_mode default_mode = {
- .clock = 12,
- .hdisplay = 1088,
- .hsync_start = 1088 + 104,
- .hsync_end = 1088 + 104 + 4,
- .htotal = 1088 + 104 + 4 + 127,
+ .clock = 16,
+ .hdisplay = 1080,
+ .hsync_start = 1080 + 117,
+ .hsync_end = 1080 + 117 + 5,
+ .htotal = 1080 + 117 + 5 + 160,
.vdisplay = 1920,
- .vsync_start = 1920 + 4,
- .vsync_end = 1920 + 4 + 2,
- .vtotal = 1920 + 4 + 2 + 3,
+ .vsync_start = 1920 + 4 ,
+ .vsync_end = 1920 + 4 + 3,
+ .vtotal = 1920 + 4 + 3 + 31 ,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
---
base-commit: 247f34f7b80357943234f93f247a1ae6b6c3a740
change-id: 20221025-ts050-timings-2fb4b034a268
Best regards,
--
Neil Armstrong
[PATCH v2 4/4] arm64: dts: smaug: Add display panel node
The Google Pixel C has a JDI LPM102A188A display panel. Add a
DT node for it. Tested on Pixel C.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- renamed backlight node to a generic name
- removed underscores
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 70 +++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
index 84ec4d8b7f10..5db0b25c8d58 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
@@ -31,6 +31,37 @@ memory {
};
host1x@5000 {
+ dc@5420 {
+ status = "okay";
+ };
+
+ dsia: dsi@5430 {
+ avdd-dsi-csi-supply = <_dsi_csi>;
+ status = "okay";
+
+ link2: panel@0 {
+ compatible = "jdi,lpm102a188a";
+ reg = <0>;
+ };
+ };
+
+ dsib: dsi@5440 {
+ avdd-dsi-csi-supply = <_dsi_csi>;
+ nvidia,ganged-mode = <>;
+ status = "okay";
+
+ link1: panel@0 {
+ compatible = "jdi,lpm102a188a";
+ reg = <0>;
+ power-supply = <_vdd>;
+ ddi-supply = <_lcdio>;
+ enable-gpios = < TEGRA_GPIO(V, 1)
GPIO_ACTIVE_HIGH>;
+ reset-gpios = < TEGRA_GPIO(V, 2)
GPIO_ACTIVE_LOW>;
+ link2 = <>;
+ backlight = <>;
+ };
+ };
+
dpaux: dpaux@545c {
status = "okay";
};
@@ -1627,6 +1658,37 @@ nau8825@1a {
status = "okay";
};
+ backlight: backlight@2c {
+ compatible = "ti,lp8557";
+ reg = <0x2c>;
+ power-supply = <_vdd>;
+ enable-supply = <_lcdio>;
+ bl-name = "lp8557-backlight";
+ dev-ctrl = /bits/ 8 <0x01>;
+ init-brt = /bits/ 8 <0x80>;
+
+ /* Full scale current, 20mA */
+ rom-11h {
+ rom-addr = /bits/ 8 <0x11>;
+ rom-val = /bits/ 8 <0x05>;
+ };
+ /* Frequency = 4.9kHz, magic undocumented val */
+ rom-12h {
+ rom-addr = /bits/ 8 <0x12>;
+ rom-val = /bits/ 8 <0x29>;
+ };
+ /* Boost freq = 1MHz, BComp option = 1 */
+ rom-13h {
+ rom-addr = /bits/ 8 <0x13>;
+ rom-val = /bits/ 8 <0x03>;
+ };
+ /* 4V OV, 6 output LED string enabled */
+ rom-14h {
+ rom-addr = /bits/ 8 <0x14>;
+ rom-val = /bits/ 8 <0xbf>;
+ };
+ };
+
audio-codec@2d {
compatible = "realtek,rt5677";
reg = <0x2d>;
@@ -1908,4 +1970,12 @@ usbc_vbus: regulator-usbc-vbus {
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ vdd_dsi_csi: regulator-vdd-dsi-csi {
+ compatible = "regulator-fixed";
+ regulator-name = "AVDD_DSI_CSI_1V2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ vin-supply = <_avdd>;
+ };
};
--
2.38.1
[PATCH v2 3/4] drm/panel: Add driver for JDI LPM102A188A
The JDI LPM102A188A is a 2560x1800 IPS panel found in the Google Pixel C.
This driver is based on the downstream GPLv2 driver released by Google
written by Sean Paul [1], which was then adapted to the newer kernel APIs.
[1]:
https://android.googlesource.com/kernel/tegra/+/refs/heads/android-tegra-dragon-3.18-oreo/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
Signed-off-by: Diogo Ivo
---
Changes in v2:
- tuned backlight delays
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c | 509 ++
3 files changed, 521 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a582ddd583c2..80eda8f6bee0 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -214,6 +214,17 @@ config DRM_PANEL_JDI_LT070ME05000
The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
24 bit per pixel.
+config DRM_PANEL_JDI_LPM102A188A
+ tristate "JDI LPM102A188A DSI panel"
+ depends on OF && GPIOLIB
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for JDI LPM102A188A DSI
+ control mode panel as found in Google Pixel C devices.
+ The panel has a 2560×1800 resolution. It provides a MIPI DSI interface
+ to the host.
+
config DRM_PANEL_JDI_R63452
tristate "JDI R63452 Full HD DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 34e717382dbb..2870cba96d14 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_EJ030NA) += panel-innolux-ej030na.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
+obj-$(CONFIG_DRM_PANEL_JDI_LPM102A188A) += panel-jdi-lpm102a188a.o
obj-$(CONFIG_DRM_PANEL_JDI_R63452) += panel-jdi-fhd-r63452.o
obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
b/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
new file mode 100644
index ..980af82ad6d6
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
@@ -0,0 +1,509 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * Copyright (C) 2022 Diogo Ivo
+ *
+ * Adapted from the downstream Pixel C driver written by Sean Paul
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+struct jdi_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link1;
+ struct mipi_dsi_device *link2;
+
+ struct regulator *supply;
+ struct regulator *ddi_supply;
+ struct backlight_device *backlight;
+
+ struct gpio_desc *enable_gpio;
+ struct gpio_desc *reset_gpio;
+
+ const struct drm_display_mode *mode;
+
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct jdi_panel *to_panel_jdi(struct drm_panel *panel)
+{
+ return container_of(panel, struct jdi_panel, base);
+}
+
+static void jdi_wait_frames(struct jdi_panel *jdi, unsigned int frames)
+{
+ unsigned int refresh = drm_mode_vrefresh(jdi->mode);
+
+ if (WARN_ON(frames > refresh))
+ return;
+
+ msleep(1000 / (refresh / frames));
+}
+
+static int jdi_panel_disable(struct drm_panel *panel)
+{
+ struct jdi_panel *jdi = to_panel_jdi(panel);
+
+ if (!jdi->enabled)
+ return 0;
+
+ backlight_disable(jdi->backlight);
+
+ jdi_wait_frames(jdi, 2);
+
+ jdi->enabled = false;
+
+ return 0;
+}
+
+static int jdi_panel_unprepare(struct drm_panel *panel)
+{
+ struct jdi_panel *jdi = to_panel_jdi(panel);
+ int ret;
+
+ if (!jdi->prepared)
+ return 0;
+
+ ret = mipi_dsi_dcs_set_display_off(jdi->link1);
+ if (ret < 0)
+ dev_err(panel->dev, "failed to set display off: %d\n", ret);
+ ret = mipi_dsi_dcs_set_display_off(jdi->link2);
+ if (ret < 0)
+ dev_err(panel->dev, "failed to set display off: %d\n", ret);
+
+ /* Specified by JDI @ 50ms, subject to change */
+ msleep(50);
+
+ ret = mipi_dsi_dcs_enter_sleep_mode(jdi->link1);
+ if (ret < 0)
+ dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
+ ret = mipi_dsi_dcs_enter_sleep_mode(jdi->link2);
+ if (ret < 0)
+ dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
+
+ /* Specified by JDI @ 150ms, subject to change */
+
[PATCH v2 2/4] drm/tegra: dsi: Clear enable register if powered by bootloader
In cases where the DSI module is left on by the bootloader
some panels may fail to initialize if the enable register is not cleared
before the panel's initialization sequence is sent, so clear it if that
is the case.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- detect if the DSI module is on based on the register value,
instead of a DT property.
- remove Display Controller clear, since it is redundant.
drivers/gpu/drm/tegra/dsi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index de1333dc0d86..5954676a7ab1 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -912,6 +912,15 @@ static void tegra_dsi_encoder_enable(struct drm_encoder
*encoder)
u32 value;
int err;
+ /* If the bootloader enabled DSI it needs to be disabled
+* in order for the panel initialization commands to be
+* properly sent.
+*/
+ value = tegra_dsi_readl(dsi, DSI_POWER_CONTROL);
+
+ if (value & DSI_POWER_CONTROL_ENABLE)
+ tegra_dsi_disable(dsi);
+
err = tegra_dsi_prepare(dsi);
if (err < 0) {
dev_err(dsi->dev, "failed to prepare: %d\n", err);
--
2.38.1
[PATCH v2 1/4] dt-bindings: display: Add bindings for JDI LPM102A188A
The LPM102A188A is a 10.2" 2560x1800 IPS panel found in
the Google Pixel C.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- removed the touch screen property
.../display/panel/jdi,lpm102a188a.yaml| 94 +++
1 file changed, 94 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
b/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
new file mode 100644
index ..2f4d27a309a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/jdi,lpm102a188a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: JDI LPM102A188A 2560x1800 10.2" DSI Panel
+
+maintainers:
+ - Diogo Ivo
+
+description: |
+ This panel requires a dual-channel DSI host to operate. It supports two
modes:
+ - left-right: each channel drives the left or right half of the screen
+ - even-odd: each channel drives the even or odd lines of the screen
+
+ Each of the DSI channels controls a separate DSI peripheral. The peripheral
+ driven by the first link (DSI-LINK1) is considered the primary peripheral
+ and controls the device. The 'link2' property contains a phandle to the
+ peripheral driven by the second link (DSI-LINK2).
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: jdi,lpm102a188a
+
+ reg: true
+ enable-gpios: true
+ reset-gpios: true
+ power-supply: true
+ backlight: true
+
+ ddi-supply:
+description: The regulator that provides IOVCC (1.8V).
+
+ link2:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+ phandle to the DSI peripheral on the secondary link. Note that the
+ presence of this property marks the containing node as DSI-LINK1.
+
+required:
+ - compatible
+ - reg
+
+if:
+ required:
+- link2
+then:
+ required:
+- power-supply
+- ddi-supply
+- enable-gpios
+- reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+dsia: dsi@5430 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x0 0x5430 0x0 0x0004>;
+
+link2: panel@0 {
+compatible = "jdi,lpm102a188a";
+reg = <0>;
+};
+};
+
+dsib: dsi@5440{
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x0 0x5440 0x0 0x0004>;
+nvidia,ganged-mode = <>;
+
+link1: panel@0 {
+compatible = "jdi,lpm102a188a";
+reg = <0>;
+power-supply = <_vdd>;
+ddi-supply = <_lcdio>;
+enable-gpios = < TEGRA_GPIO(V, 1) GPIO_ACTIVE_HIGH>;
+reset-gpios = < TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>;
+link2 = <>;
+backlight = <>;
+};
+};
+
+...
--
2.38.1
[PATCH v2 0/4] Add JDI LPM102A188A display panel support
Hello, These patches add support for the JDI LPM102A188A display panel, found in the Google Pixel C. Patch 1 adds the DT bindings for the panel. Patch 2 adds a register clear to the Tegra DSI driver, needed for the panel initialization commands to be properly sent. Patch 3 adds the panel driver, which is based on the downstream kernel driver published by Google and developed by Sean Paul. Patch 4 adds the DT node for the Google Pixel C. The first version of this patch series can be found at: https://lore.kernel.org/all/20220929170502.1034040-1-diogo@tecnico.ulisboa.pt/ Changes in v2: - Patch 1: remove touchscreen reset gpio property - Patch 2: clear register based on its value rather than a DT property - Patch 3: tune backlight delay values - Patch 4: add generic node names, remove underscores Thank you. Diogo Ivo (4): dt-bindings: display: Add bindings for JDI LPM102A188A drm/tegra: dsi: Clear enable register if powered by bootloader drm/panel: Add driver for JDI LPM102A188A arm64: dts: smaug: Add display panel node .../display/panel/jdi,lpm102a188a.yaml| 94 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 70 +++ drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c | 509 ++ drivers/gpu/drm/tegra/dsi.c | 9 + 6 files changed, 694 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml create mode 100644 drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c -- 2.38.1
Re: [Intel-gfx] [PATCH v4] drm/i915/slpc: Use platform limits for min/max frequency
On Mon, 24 Oct 2022 15:54:53 -0700, Vinay Belgaumkar wrote:
>
> GuC will set the min/max frequencies to theoretical max on
> ATS-M. This will break kernel ABI, so limit min/max frequency
> to RP0(platform max) instead.
>
> Also modify the SLPC selftest to update the min frequency
> when we have a server part so that we can iterate between
> platform min and max.
>
> v2: Check softlimits instead of platform limits (Riana)
> v3: More review comments (Ashutosh)
> v4: No need to use saved_min_freq and other comments (Ashutosh)
OK, much better now overall.
> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7030
>
> +static void update_server_min_softlimit(struct intel_guc_slpc *slpc)
> +{
> + /* For server parts, SLPC min will be at RPMax.
> + * Use min softlimit to clamp it to RP0 instead.
> + */
> + if (!slpc->min_freq_softlimit &&
> + is_slpc_min_freq_rpmax(slpc)) {
> + slpc->min_is_rpmax = true;
The only remaining issue is slpc->min_is_rpmax is now set but never used so
it can possibly be removed, or retained for debuggability (I think it's a
fair reason to retain it). Though I am not sure if we will hit a "variable
set but never used" error from these clever compilers.
> + slpc->min_freq_softlimit = slpc->rp0_freq;
> + (slpc_to_gt(slpc))->defaults.min_freq =
> slpc->min_freq_softlimit;
> + }
> +}
In any case, this is now:
Reviewed-by: Ashutosh Dixit
Re: [PATCH v8] drm: Add initial ci/ subdirectory
Hi all, On Tue, 25 Oct 2022 at 08:32, Daniel Vetter wrote: > On Fri, 9 Sept 2022 at 19:18, Daniel Stone wrote: > > But equally - and sorry for not jumping on the IRC (?) discussion as I was > > in the middle of other stuff when it came up - I'm don't think this is the > > right plan. > > > > Mesa having all its CI in-tree makes sense, because merges happen rapidly > > to a single canonical tree. If the scripts need to be changed for whatever > > reason, we can merge something in under an hour and everyone immediately > > gets it. DRM is quite different though, given the forest of trees we have > > and the long merge paths between them. I worry that merging the CI scripts > > in-tree - especially for our initial attempt at it, when we're likely to > > need to make quite a lot of changes before it settles down to become a > > stable system that works for everyone - is shooting ourselves in the foot > > by limiting our flexibility. > > So the entire "we have multiple trees" is why I want at least the > gitlab-ci.yaml in tree, to force people to collaborate more on one > thing instead of everyone rolling their own fun and hacking stuff up. > And there's still tons of stuff outside in the separate repo, like the > lab status so Linus doesn't get a silly history of lab flapping. > > Also wrt "developers don't get the update right away due to > backmerge/pull delays", that's why integration trees like drm-tip or > linux-next exist. So maybe initially we should make sure the ci > patches go in through drm-misc, to maximize how many people see it. > And even for mesa it's not fully automatic, you still have the rebase > your branch if you picked a bad one for development (but yeah marge > does that if the MR is ready). If you're doing kernel development on a > linear tree instead of an integration tree, you're doing it very > wrong. > > What I think everyone agrees on is that we probably get the split > wrong and need to shuffle some files back, and that's something > we need to warn Linus about I guess. But somewhere we do need a split > between internal and external stuff, and personally I'd like if at > least the pure sw testing (build and virtual stuff) could be all in > upstream. > > > Given that it's currently very dependent on fd.o infrastructure (published > > ci-templates, the registry, the specific-tag runners for Collabora/CrOS > > DUTs, etc), there isn't much of a portability gain in bringing the scripts > > into the tree either. It's a good goal, but not where we are today. > > I don't think there's huge chances for any non-fdo gitlab anytime > soon. Once we get there we might need to figure out how to standardize > the hw lab interfacing, and if we have all the sw targets in upstream > that should help with shuffling stuff around for a hypothetical LF > gitlab CI (or whatever it is). Yep, having talked through things on IRC, I'm happy with where we are; let's give it a go and find out. Acked-by: Daniel Stone Cheers, Daniel
Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
On Tue, Oct 25, 2022 at 10:34 AM Jason Gunthorpe wrote: > > On Tue, Oct 25, 2022 at 10:21:34AM -0400, Alex Deucher wrote: > > > E.g., the kfd node provides platform level compute > > topology information; e.g., the NUMA details for connected GPUs and > > CPUs, non-GPU compute node information, cache level topologies, etc. > > See, this is exactly what I'm talking about. What on earth does any of > this have to do with DRM? At least for the GPU information it seems relevant. What value are acceleration device cache topologies outside of the subsytsem that uses them? > > We alread have places in the kernel that own and expose these kinds of > information, drivers need to use them. Not re-invent them. I don't disagree, but I'm not sure where the best place for these should be. Probably a lack of knowledge of where this should actually live and indifference from the maintainers of those areas since this use case doesn't match existing ones. Alex
Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
On Tue, Oct 25, 2022 at 10:21:34AM -0400, Alex Deucher wrote: > E.g., the kfd node provides platform level compute > topology information; e.g., the NUMA details for connected GPUs and > CPUs, non-GPU compute node information, cache level topologies, etc. See, this is exactly what I'm talking about. What on earth does any of this have to do with DRM? We alread have places in the kernel that own and expose these kinds of information, drivers need to use them. Not re-invent them. Jason
Re: [PATCH 3/3] Revert "drm/amd/display: Limit max DSC target bpp for specific monitors"
@Daniel Vetter
, @Dave Airlie
Any objections taking this through the AMD tree or would you rather it
landed via drm-misc?
Thanks,
Alex
On Tue, Oct 25, 2022 at 10:21 AM Harry Wentland wrote:
>
> Series is
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> On 2022-10-24 15:22, Hamza Mahfooz wrote:
> > This reverts commit 55eea8ef98641f6e1e1c202bd3a49a57c1dd4059.
> >
> > This quirk is now handled in the DRM core, so we can drop all of
> > the internal code that was added to handle it.
> >
> > Signed-off-by: Hamza Mahfooz
> > ---
> > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 35 ---
> > 1 file changed, 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index 4956a0118215..a21e2ba77ddb 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -41,39 +41,6 @@
> > #include "dm_helpers.h"
> > #include "ddc_service_types.h"
> >
> > -struct monitor_patch_info {
> > - unsigned int manufacturer_id;
> > - unsigned int product_id;
> > - void (*patch_func)(struct dc_edid_caps *edid_caps, unsigned int
> > param);
> > - unsigned int patch_param;
> > -};
> > -static void set_max_dsc_bpp_limit(struct dc_edid_caps *edid_caps, unsigned
> > int param);
> > -
> > -static const struct monitor_patch_info monitor_patch_table[] = {
> > -{0x6D1E, 0x5BBF, set_max_dsc_bpp_limit, 15},
> > -{0x6D1E, 0x5B9A, set_max_dsc_bpp_limit, 15},
> > -};
> > -
> > -static void set_max_dsc_bpp_limit(struct dc_edid_caps *edid_caps, unsigned
> > int param)
> > -{
> > - if (edid_caps)
> > - edid_caps->panel_patch.max_dsc_target_bpp_limit = param;
> > -}
> > -
> > -static int amdgpu_dm_patch_edid_caps(struct dc_edid_caps *edid_caps)
> > -{
> > - int i, ret = 0;
> > -
> > - for (i = 0; i < ARRAY_SIZE(monitor_patch_table); i++)
> > - if ((edid_caps->manufacturer_id ==
> > monitor_patch_table[i].manufacturer_id)
> > - && (edid_caps->product_id ==
> > monitor_patch_table[i].product_id)) {
> > - monitor_patch_table[i].patch_func(edid_caps,
> > monitor_patch_table[i].patch_param);
> > - ret++;
> > - }
> > -
> > - return ret;
> > -}
> > -
> > /* dm_helpers_parse_edid_caps
> > *
> > * Parse edid caps
> > @@ -148,8 +115,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
> > kfree(sads);
> > kfree(sadb);
> >
> > - amdgpu_dm_patch_edid_caps(edid_caps);
> > -
> > return result;
> > }
> >
>
Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
On Tue, Oct 25, 2022 at 7:15 AM Jason Gunthorpe wrote: > > On Tue, Oct 25, 2022 at 12:27:11PM +1000, Dave Airlie wrote: > > > The userspace for those is normally bespoke like ROCm, which uses > > amdkfd, and amdkfd doesn't operate like most device files from what I > > know, so I'm not sure we'd want it to operate as an accel device. > > I intensely dislike this direction that drivers will create their own > char devs buried inside their device driver with no support or > supervision. > > We've been here before with RDMA and it is just a complete mess. > > Whatever special non-drm stuff amdkfd need to do should be supported > through the new subsystem, in a proper maintainable way. We plan to eventually move ROCm over the drm interfaces once we get user mode queues working on non-compute queues which is already in progress. ROCm already uses the existing drm nodes and libdrm for a number of things today (buffer sharing, media and compute command submission in certain cases, etc.). I don't see much value in the accel nodes for AMD products at this time. Even when we transition, there are still a bunch of things that we'd need to think about, so the current kfd node may stick around until we figure out a plan for those areas. E.g., the kfd node provides platform level compute topology information; e.g., the NUMA details for connected GPUs and CPUs, non-GPU compute node information, cache level topologies, etc. Alex > > Jason
Re: [PATCH 3/3] Revert "drm/amd/display: Limit max DSC target bpp for specific monitors"
Series is
Reviewed-by: Harry Wentland
Harry
On 2022-10-24 15:22, Hamza Mahfooz wrote:
> This reverts commit 55eea8ef98641f6e1e1c202bd3a49a57c1dd4059.
>
> This quirk is now handled in the DRM core, so we can drop all of
> the internal code that was added to handle it.
>
> Signed-off-by: Hamza Mahfooz
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 35 ---
> 1 file changed, 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 4956a0118215..a21e2ba77ddb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -41,39 +41,6 @@
> #include "dm_helpers.h"
> #include "ddc_service_types.h"
>
> -struct monitor_patch_info {
> - unsigned int manufacturer_id;
> - unsigned int product_id;
> - void (*patch_func)(struct dc_edid_caps *edid_caps, unsigned int param);
> - unsigned int patch_param;
> -};
> -static void set_max_dsc_bpp_limit(struct dc_edid_caps *edid_caps, unsigned
> int param);
> -
> -static const struct monitor_patch_info monitor_patch_table[] = {
> -{0x6D1E, 0x5BBF, set_max_dsc_bpp_limit, 15},
> -{0x6D1E, 0x5B9A, set_max_dsc_bpp_limit, 15},
> -};
> -
> -static void set_max_dsc_bpp_limit(struct dc_edid_caps *edid_caps, unsigned
> int param)
> -{
> - if (edid_caps)
> - edid_caps->panel_patch.max_dsc_target_bpp_limit = param;
> -}
> -
> -static int amdgpu_dm_patch_edid_caps(struct dc_edid_caps *edid_caps)
> -{
> - int i, ret = 0;
> -
> - for (i = 0; i < ARRAY_SIZE(monitor_patch_table); i++)
> - if ((edid_caps->manufacturer_id ==
> monitor_patch_table[i].manufacturer_id)
> - && (edid_caps->product_id ==
> monitor_patch_table[i].product_id)) {
> - monitor_patch_table[i].patch_func(edid_caps,
> monitor_patch_table[i].patch_param);
> - ret++;
> - }
> -
> - return ret;
> -}
> -
> /* dm_helpers_parse_edid_caps
> *
> * Parse edid caps
> @@ -148,8 +115,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
> kfree(sads);
> kfree(sadb);
>
> - amdgpu_dm_patch_edid_caps(edid_caps);
> -
> return result;
> }
>
Re: [PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
On 10/25/2022 5:42 AM, Jacek Lawrynowicz wrote: Hi, thanks for detailed review. My responses inline. On 10/25/2022 1:00 AM, Jeffrey Hugo wrote: On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote: VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following componensts: Just noticed this. "components" - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/gpu/drm/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Signed-off-by: Krystian Pradzynski Signed-off-by: Jacek Lawrynowicz --- MAINTAINERS|8 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivpu/Kconfig | 12 + drivers/gpu/drm/ivpu/Makefile |8 + drivers/gpu/drm/ivpu/TODO |7 + drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + drivers/gpu/drm/ivpu/ivpu_drv.h| 153 drivers/gpu/drm/ivpu/ivpu_hw.h | 169 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ include/uapi/drm/ivpu_drm.h| 95 +++ 13 files changed, 2451 insertions(+) create mode 100644 drivers/gpu/drm/ivpu/Kconfig create mode 100644 drivers/gpu/drm/ivpu/Makefile create mode 100644 drivers/gpu/drm/ivpu/TODO create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h create mode 100644 include/uapi/drm/ivpu_drm.h diff --git a/MAINTAINERS b/MAINTAINERS index 9475aa701a3f..d72ceef107e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7046,6 +7046,14 @@ F: Documentation/devicetree/bindings/gpu/vivante,gc.yaml F:drivers/gpu/drm/etnaviv/ F:include/uapi/drm/etnaviv_drm.h +DRM DRIVERS FOR VPU +M:Jacek Lawrynowicz +M:Stanislaw Gruszka +S:Supported +T:git git://anongit.freedesktop.org/drm/drm-misc +F:drivers/gpu/drm/ivpu/ +F:include/uapi/drm/ivpu_drm.h No mail list? OK, I will add a link to dri-devel. + DRM DRIVERS FOR XEN M:Oleksandr Andrushchenko L:dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 198ba846d34b..0aaac0e5366f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" +source "drivers/gpu/drm/ivpu/Kconfig" + Why here of all places? Just randomly in the middle of the list of sourced Kconfigs? I'll move it to the end. source "drivers/gpu/drm/etnaviv/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 25d0ba310509..1bfd7415c2d0 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ +obj-$(CONFIG_DRM_IVPU) += ivpu/ Again, why here? I'll move it to the end. diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile new file mode 100644 index ..e59dc65abe6a --- /dev/null +++ b/drivers/gpu/drm/ivpu/Makefile @@ -0,0 +1,8 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Copyright © 2022 Intel Corporation I'm pretty sure (C) is preferred. Looks like you do this in multiple places. I'm only going to mention it here. OK, I'll use (C) everywhere. +int ivpu_dbg_mask; +module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644); +MODULE_PARM_DESC(dbg_mask, "Driver debug mask. See IVPU_DBG_* macros."); Shouldn't this be unnecessary with the DRM_DEBUG levels, or making the things tracepoints? drm logging doesn't provide the
Re: [PATCH 1/2] drm: remove DRM_MINOR_CONTROL
On Tue, Oct 11, 2022 at 01:55:01PM +0200, Christian König wrote:
> Am 11.10.22 um 13:39 schrieb Simon Ser:
> > On Tuesday, October 11th, 2022 at 13:04, Christian König
> > wrote:
> >
> > > --- a/include/drm/drm_file.h
> > > +++ b/include/drm/drm_file.h
> > > @@ -54,7 +54,6 @@ struct file;
> > >*/
> > > enum drm_minor_type {
> > > DRM_MINOR_PRIMARY,
> > > - DRM_MINOR_CONTROL,
> > > DRM_MINOR_RENDER,
> > > };
> > This makes me uncomfortable: this enum no longer matches DRM_NODE_* in
> > libdrm.
>
> Ah! There it was! I was remembering in the back of my head that we had
> somehow used this in libdrm as well, but couldn't really get where exactly.
>
> But I don't really see a problem here. The control nodes are identified by
> name and we don't expose them for quite some time now without any negative
> impact.
>
> Even the minor number distribution stays the same. So what bad can come from
> this?
>
> Thanks,
> Christian.
>
I proposed something similar in:
https://lore.kernel.org/dri-devel/20220817230600.272790-1-michal.winiar...@intel.com/
except acompanied by expanding the minor pool to accomodate more than
128 devices:
And after receiving similar feedback, that eventually evolved into
leaving the "legacy minors" alone, and changing the rules only for cases
where we have more than 64 devices (when we run out of the "legacy
minors").
Perhaps something like this:
https://lore.kernel.org/dri-devel/20220911211443.581481-1-michal.winiar...@intel.com/
Would work for your usecase as well?
-Michał
Re: [PATCH v5 1/3] drm: Use XArray instead of IDR for minors
On 9/11/2022 3:14 PM, Michał Winiarski wrote: IDR is deprecated, and since XArray manages its own state with internal locking, it simplifies the locking on DRM side. Additionally, don't use the IRQ-safe variant, since operating on drm minor is not done in IRQ context. Signed-off-by: Michał Winiarski Suggested-by: Matthew Wilcox --- Reviewed-by: Jeffrey Hugo
Re: [PATCH printk v2 24/38] xen: fbfront: use srcu console list iterator
On Wed 2022-10-19 17:01:46, John Ogness wrote:
> Since the console_lock is not being used for anything other than
> safe console list traversal, use srcu console list iteration instead.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
> ---
> drivers/video/fbdev/xen-fbfront.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/xen-fbfront.c
> b/drivers/video/fbdev/xen-fbfront.c
> index 4d2694d904aa..2552c853c6c2 100644
> --- a/drivers/video/fbdev/xen-fbfront.c
> +++ b/drivers/video/fbdev/xen-fbfront.c
> @@ -500,16 +500,18 @@ static int xenfb_probe(struct xenbus_device *dev,
> static void xenfb_make_preferred_console(void)
Just for record. This function is a dirty hack how to associate "ttyX"
console with /dev/console.
A clean solution would be to just reshuffle console_drivers list. I
have a patch for this in my bottom drawer. It is part of a bigger
clean up that it not ready for upstreaming yet.
Best Regards,
Petr
> {
> struct console *c;
> + int cookie;
>
> if (console_set_on_cmdline)
> return;
>
> - console_lock();
> - for_each_console(c) {
> + cookie = console_srcu_read_lock();
> + for_each_console_srcu(c) {
> if (!strcmp(c->name, "tty") && c->index == 0)
> break;
> }
> - console_unlock();
> + console_srcu_read_unlock(cookie);
> +
> if (c) {
> unregister_console(c);
> c->flags |= CON_CONSDEV;
> --
> 2.30.2
Re: [PATCH] drm/scheduler: set current_entity to next when remove from rq
+ Luben On Tue, Oct 25, 2022 at 2:55 AM brolerliew wrote: > > When entity move from one rq to another, current_entity will be set to NULL > if it is the moving entity. This make entities close to rq head got > selected more frequently, especially when doing load balance between > multiple drm_gpu_scheduler. > > Make current_entity to next when removing from rq. > > Signed-off-by: brolerliew > --- > drivers/gpu/drm/scheduler/sched_main.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c > b/drivers/gpu/drm/scheduler/sched_main.c > index 2fab218d7082..00b22cc50f08 100644 > --- a/drivers/gpu/drm/scheduler/sched_main.c > +++ b/drivers/gpu/drm/scheduler/sched_main.c > @@ -168,10 +168,11 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq *rq, > spin_lock(>lock); > > atomic_dec(rq->sched->score); > - list_del_init(>list); > > if (rq->current_entity == entity) > - rq->current_entity = NULL; > + rq->current_entity = list_next_entry(entity, list); > + > + list_del_init(>list); > > if (drm_sched_policy == DRM_SCHED_POLICY_FIFO) > drm_sched_rq_remove_fifo_locked(entity); > -- > 2.34.1 >
Re: [RFC PATCH 3/3] drm: add dedicated minor for accelerator devices
On Mon, Oct 24, 2022 at 08:43:58PM +0300, Oded Gabbay wrote:
> On Mon, Oct 24, 2022 at 6:21 PM Jeffrey Hugo wrote:
> >
> > On 10/22/2022 3:46 PM, Oded Gabbay wrote:
> > > The accelerator devices are exposed to user-space using a dedicated
> > > major. In addition, they are represented in /dev with new, dedicated
> > > device char names: /dev/accel/accel*. This is done to make sure any
> > > user-space software that tries to open a graphic card won't open
> > > the accelerator device by mistake.
> > >
> > > The above implies that the minor numbering should be separated from
> > > the rest of the drm devices. However, to avoid code duplication, we
> > > want the drm_minor structure to be able to represent the accelerator
> > > device.
> > >
> > > To achieve this, we add a new drm_minor* to drm_device that represents
> > > the accelerator device. This pointer is initialized for drivers that
> > > declare they handle compute accelerator, using a new driver feature
> > > flag called DRIVER_COMPUTE_ACCEL. It is important to note that this
> > > driver feature is mutually exclusive with DRIVER_RENDER. Devices that
> > > want to expose both graphics and compute device char files should be
> > > handled by two drivers that are connected using the auxiliary bus
> > > framework.
> > >
> > > In addition, we define a different idr to handle the accelerators
> > > minors. This is done to make the minor's index be identical to the
> > > device index in /dev/. In most places, this is hidden inside the drm
> > > core functions except when calling drm_minor_acquire(), where I had to
> > > add an extra parameter to specify the idr to use (because the
> > > accelerators minors index and the drm primary minor index both begin
> > > at 0).
> > >
> > > Signed-off-by: Oded Gabbay
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 171 +
> > > drivers/gpu/drm/drm_file.c | 69 +
> > > drivers/gpu/drm/drm_internal.h | 2 +-
> > > drivers/gpu/drm/drm_sysfs.c| 29 --
> > > include/drm/drm_device.h | 3 +
> > > include/drm/drm_drv.h | 8 ++
> > > include/drm/drm_file.h | 21 +++-
> > > 7 files changed, 235 insertions(+), 68 deletions(-)
> >
> > Can we please add something to Documentation? I know this leverages DRM
> > a lot, but I believe that a new subsystem should not be introduced
> > without documentation. A lot of the info in the commit message is very
> > good, but should not be buried in the git log.
> >
> > Besides, imagine this has been in mainline for N years, and someone
> > completely new to the kernel wants to write an accel driver. They
> > should be able to get started with something from Documentation that
> > at-least gives that person some insight into what to grep the code for.
> Agreed. The only reason I haven't done it at this stage was because I
> wanted to get an initial reaction to the code itself, see if the
> direction is accepted.
> I didn't want to write documentation and then completely re-write it.
> So I will do it for the next patch-set, once I collect everyone's
> feedback and I see there is a majority agreement.
> >
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index b58ffb1433d6..c13701a8d4be 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -56,6 +56,9 @@ MODULE_LICENSE("GPL and additional rights");
> > > static DEFINE_SPINLOCK(drm_minor_lock);
> > > static struct idr drm_minors_idr;
> > >
> > > +static DEFINE_SPINLOCK(accel_minor_lock);
> > > +static struct idr accel_minors_idr;
> >
> > IDR is deprecated. XArray is the preferred mechanism.
> > Yes, there already is IDR here, but I believe we should not be adding
> > new uses. Maybe at some point, the current IDR will be converted. Also
> > with XArray, I think you don't need the spinlock since XArray has
> > internal locking already.
> ok, I wasn't aware. I don't have any problem replacing the idr to xarray.
The conversion is sitting on the mailinglist for a while now
(unfortunately, without much interest).
Perhaps you could help with reviewing it?
https://lore.kernel.org/dri-devel/20220911211443.581481-2-michal.winiar...@intel.com/
-Michał
>
> Thanks,
> Oded
>
Re: [PATCH] video: fbdev: sis: use explicitly signed char
On 10/25/22 14:55, Jason A. Donenfeld wrote: On Mon, Oct 24, 2022 at 8:29 PM Helge Deller wrote: On 10/24/22 18:29, Jason A. Donenfeld wrote: With char becoming unsigned by default, and with `char` alone being ambiguous and based on architecture, signed chars need to be marked explicitly as such. This fixes warnings like: drivers/video/fbdev/sis/init301.c:3549 SiS_GetCRT2Data301() warn: 'SiS_Pr->SiS_EModeIDTable[ModeIdIndex]->ROMMODEIDX661' is unsigned Cc: Thomas Winischhofer Cc: Greg Kroah-Hartman Cc: Helge Deller Cc: linux-...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jason A. Donenfeld Applied to linux-fbdev git tree. For 6.1 as a fix, right? Since this is already broken on, e.g., ARM. Yes. Helge
Re: [PATCH] video: fbdev: sis: use explicitly signed char
On Mon, Oct 24, 2022 at 8:29 PM Helge Deller wrote: > > On 10/24/22 18:29, Jason A. Donenfeld wrote: > > With char becoming unsigned by default, and with `char` alone being > > ambiguous and based on architecture, signed chars need to be marked > > explicitly as such. This fixes warnings like: > > > > drivers/video/fbdev/sis/init301.c:3549 SiS_GetCRT2Data301() warn: > > 'SiS_Pr->SiS_EModeIDTable[ModeIdIndex]->ROMMODEIDX661' is unsigned > > > > Cc: Thomas Winischhofer > > Cc: Greg Kroah-Hartman > > Cc: Helge Deller > > Cc: linux-...@vger.kernel.org > > Cc: linux-fb...@vger.kernel.org > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Jason A. Donenfeld > > Applied to linux-fbdev git tree. For 6.1 as a fix, right? Since this is already broken on, e.g., ARM. Jason
Re: [PATCH v3 3/7] drm/ivpu: Add GEM buffer object management
Hi
Am 24.09.22 um 17:11 schrieb Jacek Lawrynowicz:
Adds four types of GEM-based BOs for the VPU:
- shmem
- userptr
- internal
- prime
All types are implemented as struct ivpu_bo, based on
struct drm_gem_object. VPU address is allocated when buffer is created
except for imported prime buffers that allocate it in BO_INFO IOCTL due
to missing file_priv arg in gem_prime_import callback.
Internal buffers are pinned on creation, the rest of buffers types
can be pinned on demand (in SUBMIT IOCTL).
Buffer VPU address, allocated pages and mappings are relased when the
buffer is destroyed.
Eviction mechism is planned for future versions.
Add three new IOCTLs: BO_CREATE, BO_INFO, BO_USERPTR
I feels like TTM already does all you need. (?) Why not build upon TTM?
Best regards
Thomas
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 1 +
drivers/gpu/drm/ivpu/ivpu_drv.c | 9 +
drivers/gpu/drm/ivpu/ivpu_gem.c | 823
drivers/gpu/drm/ivpu/ivpu_gem.h | 128 +
include/uapi/drm/ivpu_drm.h | 127 +
5 files changed, 1088 insertions(+)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_gem.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_gem.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index 95bb04f26296..4053fe341d56 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -3,6 +3,7 @@
intel_vpu-y := \
ivpu_drv.o \
+ ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index cbeb9a801a31..b0442e2a4960 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -11,8 +11,10 @@
#include
#include
#include
+#include
#include "ivpu_drv.h"
+#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -187,6 +189,9 @@ static void ivpu_postclose(struct drm_device *dev, struct
drm_file *file)
static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_GET_PARAM, ivpu_get_param_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(IVPU_SET_PARAM, ivpu_set_param_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_USERPTR, ivpu_bo_userptr_ioctl,
DRM_RENDER_ALLOW),
};
DEFINE_DRM_GEM_FOPS(ivpu_fops);
@@ -210,6 +215,10 @@ static const struct drm_driver driver = {
.open = ivpu_open,
.postclose = ivpu_postclose,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_import = ivpu_gem_prime_import,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.ioctls = ivpu_drm_ioctls,
.num_ioctls = ARRAY_SIZE(ivpu_drm_ioctls),
diff --git a/drivers/gpu/drm/ivpu/ivpu_gem.c b/drivers/gpu/drm/ivpu/ivpu_gem.c
new file mode 100644
index ..54319a25c18e
--- /dev/null
+++ b/drivers/gpu/drm/ivpu/ivpu_gem.c
@@ -0,0 +1,823 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2020-2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "ivpu_drv.h"
+#include "ivpu_gem.h"
+#include "ivpu_hw.h"
+#include "ivpu_mmu.h"
+#include "ivpu_mmu_context.h"
+
+MODULE_IMPORT_NS(DMA_BUF);
+
+static const struct drm_gem_object_funcs ivpu_gem_funcs;
+
+static int __must_check prime_alloc_pages_locked(struct ivpu_bo *bo)
+{
+ /* Pages are managed by the underlying dma-buf */
+ return 0;
+}
+
+static void prime_free_pages_locked(struct ivpu_bo *bo)
+{
+ /* Pages are managed by the underlying dma-buf */
+}
+
+static int prime_map_pages_locked(struct ivpu_bo *bo)
+{
+ struct ivpu_device *vdev = ivpu_bo_to_vdev(bo);
+ struct sg_table *sgt;
+
+ WARN_ON(!bo->base.import_attach);
+
+ sgt = dma_buf_map_attachment(bo->base.import_attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt)) {
+ ivpu_err(vdev, "Failed to map attachment: %ld\n", PTR_ERR(sgt));
+ return PTR_ERR(sgt);
+ }
+
+ bo->sgt = sgt;
+ return 0;
+}
+
+static void prime_unmap_pages_locked(struct ivpu_bo *bo)
+{
+ WARN_ON(!bo->base.import_attach);
+
+ dma_buf_unmap_attachment(bo->base.import_attach, bo->sgt,
DMA_BIDIRECTIONAL);
+ bo->sgt = NULL;
+}
+
+static const struct ivpu_bo_ops prime_ops = {
+ .type = IVPU_BO_TYPE_PRIME,
+ .name = "prime",
+ .alloc_pages = prime_alloc_pages_locked,
+ .free_pages = prime_free_pages_locked,
+ .map_pages = prime_map_pages_locked,
+ .unmap_pages = prime_unmap_pages_locked,
+};
+
+static int __must_check shmem_alloc_pages_locked(struct ivpu_bo *bo)
+{
+ int npages =
Re: [PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
Hi, please find some review comments below. Am 24.09.22 um 17:11 schrieb Jacek Lawrynowicz: VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following componensts: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/gpu/drm/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Signed-off-by: Krystian Pradzynski Signed-off-by: Jacek Lawrynowicz --- MAINTAINERS|8 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivpu/Kconfig | 12 + drivers/gpu/drm/ivpu/Makefile |8 + drivers/gpu/drm/ivpu/TODO |7 + drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + drivers/gpu/drm/ivpu/ivpu_drv.h| 153 drivers/gpu/drm/ivpu/ivpu_hw.h | 169 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ include/uapi/drm/ivpu_drm.h| 95 +++ 13 files changed, 2451 insertions(+) create mode 100644 drivers/gpu/drm/ivpu/Kconfig create mode 100644 drivers/gpu/drm/ivpu/Makefile create mode 100644 drivers/gpu/drm/ivpu/TODO create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h create mode 100644 include/uapi/drm/ivpu_drm.h diff --git a/MAINTAINERS b/MAINTAINERS index 9475aa701a3f..d72ceef107e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7046,6 +7046,14 @@ F: Documentation/devicetree/bindings/gpu/vivante,gc.yaml F:drivers/gpu/drm/etnaviv/ F:include/uapi/drm/etnaviv_drm.h +DRM DRIVERS FOR VPU +M: Jacek Lawrynowicz +M: Stanislaw Gruszka +S: Supported +T: git git://anongit.freedesktop.org/drm/drm-misc +F: drivers/gpu/drm/ivpu/ +F: include/uapi/drm/ivpu_drm.h + DRM DRIVERS FOR XEN M:Oleksandr Andrushchenko L:dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 198ba846d34b..0aaac0e5366f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" +source "drivers/gpu/drm/ivpu/Kconfig" + source "drivers/gpu/drm/etnaviv/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 25d0ba310509..1bfd7415c2d0 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ +obj-$(CONFIG_DRM_IVPU) += ivpu/ obj-$(CONFIG_DRM_SIS) += sis/ obj-$(CONFIG_DRM_SAVAGE)+= savage/ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ diff --git a/drivers/gpu/drm/ivpu/Kconfig b/drivers/gpu/drm/ivpu/Kconfig new file mode 100644 index ..30af359c52f2 --- /dev/null +++ b/drivers/gpu/drm/ivpu/Kconfig @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0-only +config DRM_IVPU + tristate "Intel VPU for Meteor Lake and newer" + depends on DRM + depends on X86_64 && PCI + select SHMEM + help + Choose this option if you have a system that has an 14th generation Intel CPU + or newer. VPU stands for Versatile Processing Unit and it's a CPU-integrated + inference accelerator for Computer Vision and Deep Learning applications. + + If "M" is selected, the module will be called intel_vpu. diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile new file mode 100644 index ..e59dc65abe6a --- /dev/null +++ b/drivers/gpu/drm/ivpu/Makefile @@ -0,0 +1,8 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Copyright © 2022 Intel
[airlied:01.01-gsp-rm 173/180] drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c:640:71: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type
tree: git://people.freedesktop.org/~airlied/linux.git 01.01-gsp-rm
head: 6be95d5e52818808565790c5ee3fd5569263bd36
commit: 2428d9aef24a6a497b8740afadbb028c17b5e697 [173/180]
drm/nouveau/gsp/tu102-: add support for booting GSP-RM
config: microblaze-randconfig-r001-20221023 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add airlied git://people.freedesktop.org/~airlied/linux.git
git fetch --no-tags airlied 01.01-gsp-rm
git checkout 2428d9aef24a6a497b8740afadbb028c17b5e697
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=microblaze SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c: In function
'nvkm_gsp_mem_ctor':
>> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c:640:71: error: passing
>> argument 3 of 'dma_alloc_coherent' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
640 | mem->data = dma_alloc_coherent(gsp->subdev.device->dev,
size, >addr, GFP_KERNEL);
|
^~
|
|
|
u64 * {aka long long unsigned int *}
In file included from arch/microblaze/include/asm/pci.h:14,
from include/linux/pci.h:1910,
from drivers/gpu/drm/nouveau/include/nvif/os.h:8,
from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4,
from drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3,
from drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4,
from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:4,
from drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h:4,
from drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h:4,
from drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c:22:
include/linux/dma-mapping.h:426:29: note: expected 'dma_addr_t *' {aka
'unsigned int *'} but argument is of type 'u64 *' {aka 'long long unsigned int
*'}
426 | dma_addr_t *dma_handle, gfp_t gfp)
| ^~
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c: In function 'r515_gsp_load':
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c:1141:58: error: passing
argument 3 of 'dma_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
1141 |
>radix3[i].addr, GFP_KERNEL);
|
^~~~
| |
| u64 * {aka
long long unsigned int *}
include/linux/dma-mapping.h:426:29: note: expected 'dma_addr_t *' {aka
'unsigned int *'} but argument is of type 'u64 *' {aka 'long long unsigned int
*'}
426 | dma_addr_t *dma_handle, gfp_t gfp)
| ^~
cc1: some warnings being treated as errors
vim +/dma_alloc_coherent +640 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c
635
636 static int
637 nvkm_gsp_mem_ctor(struct nvkm_gsp *gsp, u32 size, struct nvkm_gsp_mem
*mem)
638 {
639 mem->size = size;
> 640 mem->data = dma_alloc_coherent(gsp->subdev.device->dev, size,
> >addr, GFP_KERNEL);
641 if (WARN_ON(!mem->data))
642 return -ENOMEM;
643
644 return 0;
645 }
646
--
0-DAY CI Kernel Test Service
https://01.org/lkp
.config.gz
Description: application/gzip
Re: [Intel-gfx] [PATCH v5 05/19] drm/i915/vm_bind: Implement bind and unbind of object
Hi Niranjana, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] url: https://github.com/intel-lab-lkp/linux/commits/Niranjana-Vishwanathapura/drm-i915-vm_bind-Add-VM_BIND-functionality/20221025-150246 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip patch link: https://lore.kernel.org/r/20221025065905.13325-6-niranjana.vishwanathapura%40intel.com patch subject: [Intel-gfx] [PATCH v5 05/19] drm/i915/vm_bind: Implement bind and unbind of object config: i386-randconfig-a003-20221024 (attached as .config) compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/493d35709c7a1fafd30f53c539e36cec9a1f9fb8 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Niranjana-Vishwanathapura/drm-i915-vm_bind-Add-VM_BIND-functionality/20221025-150246 git checkout 493d35709c7a1fafd30f53c539e36cec9a1f9fb8 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot All errors (new ones prefixed by >>): >> drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c:18:1: error: unused >> function 'i915_vm_bind_it_iter_next' [-Werror,-Wunused-function] INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last, ^ include/linux/interval_tree_generic.h:151:33: note: expanded from macro 'INTERVAL_TREE_DEFINE' ITSTATIC ITSTRUCT * \ ^ :88:1: note: expanded from here i915_vm_bind_it_iter_next ^ 1 error generated. vim +/i915_vm_bind_it_iter_next +18 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 17 > 18 INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last, 19 START, LAST, static inline, i915_vm_bind_it) 20 -- 0-DAY CI Kernel Test Service https://01.org/lkp .config.gz Description: application/gzip
Re: [PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
Hi Am 25.10.22 um 13:42 schrieb Jacek Lawrynowicz: Hi, thanks for detailed review. My responses inline. On 10/25/2022 1:00 AM, Jeffrey Hugo wrote: On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote: VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following componensts: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/gpu/drm/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Signed-off-by: Krystian Pradzynski Signed-off-by: Jacek Lawrynowicz --- MAINTAINERS|8 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivpu/Kconfig | 12 + drivers/gpu/drm/ivpu/Makefile |8 + drivers/gpu/drm/ivpu/TODO |7 + drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + drivers/gpu/drm/ivpu/ivpu_drv.h| 153 drivers/gpu/drm/ivpu/ivpu_hw.h | 169 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ include/uapi/drm/ivpu_drm.h| 95 +++ 13 files changed, 2451 insertions(+) create mode 100644 drivers/gpu/drm/ivpu/Kconfig create mode 100644 drivers/gpu/drm/ivpu/Makefile create mode 100644 drivers/gpu/drm/ivpu/TODO create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h create mode 100644 include/uapi/drm/ivpu_drm.h diff --git a/MAINTAINERS b/MAINTAINERS index 9475aa701a3f..d72ceef107e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7046,6 +7046,14 @@ F: Documentation/devicetree/bindings/gpu/vivante,gc.yaml F:drivers/gpu/drm/etnaviv/ F:include/uapi/drm/etnaviv_drm.h +DRM DRIVERS FOR VPU +M:Jacek Lawrynowicz +M:Stanislaw Gruszka +S:Supported +T:git git://anongit.freedesktop.org/drm/drm-misc +F:drivers/gpu/drm/ivpu/ +F:include/uapi/drm/ivpu_drm.h No mail list? OK, I will add a link to dri-devel. + DRM DRIVERS FOR XEN M:Oleksandr Andrushchenko L:dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 198ba846d34b..0aaac0e5366f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" +source "drivers/gpu/drm/ivpu/Kconfig" + Why here of all places? Just randomly in the middle of the list of sourced Kconfigs? I'll move it to the end. I known that the Kconfigs and Makefiles are chaotic. But if you can, try to sort it alphabetically. source "drivers/gpu/drm/etnaviv/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 25d0ba310509..1bfd7415c2d0 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ +obj-$(CONFIG_DRM_IVPU) += ivpu/ Again, why here? I'll move it to the end. Same. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [bug report] dma-buf: Move dma_buf_attach() to dynamic locking specification
On 10/25/22 14:41, Dan Carpenter wrote:
> Hello Dmitry Osipenko,
>
> The patch 809d9c72c2f8: "dma-buf: Move dma_buf_attach() to dynamic
> locking specification" from Oct 17, 2022, leads to the following
> Smatch static checker warning:
>
> drivers/dma-buf/dma-buf.c:957 dma_buf_dynamic_attach()
> error: double unlocked 'dmabuf->resv' (orig line 915)
>
> drivers/dma-buf/dma-buf.c
>987 /**
>988 * dma_buf_detach - Remove the given attachment from dmabuf's
> attachments list
>989 * @dmabuf: [in]buffer to detach from.
>990 * @attach: [in]attachment to be detached; is free'd after
> this call.
>991 *
>992 * Clean up a device attachment obtained by calling dma_buf_attach().
>993 *
>994 * Optionally this calls _buf_ops.detach for device-specific
> detach.
>995 */
>996 void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment
> *attach)
>997 {
>998 if (WARN_ON(!dmabuf || !attach))
>999 return;
> 1000
> 1001 dma_resv_lock(attach->dmabuf->resv, NULL);
>
> In the original code used to take this both the "attach->dmabuf->resv"
> and "dmabuf->resv" locks and unlock them both. But now it takes one
> lock and unlocks the other. Seems sus.
It will be the same lock. Apparently I copied the part of code from
other function, that's why lock/unlock aren't consistent there. The
dma_buf_detach() doesn't really need the `dmabuf` argument, perhaps it
was more useful in the past.
I'll prepare the patch to clean up the locking pointer. Thank you for
the report!
--
Best regards,
Dmitry
[bug report] drm/bridge: it6505: Adapt runtime power management framework
Hello Pin-yen Lin,
The patch 1051d302: "drm/bridge: it6505: Adapt runtime power
management framework" from Oct 4, 2022, leads to the following Smatch
static checker warning:
drivers/gpu/drm/bridge/ite-it6505.c:2712 it6505_extcon_work()
warn: pm_runtime_get_sync() also returns 1 on success
drivers/gpu/drm/bridge/ite-it6505.c
2685 static void it6505_extcon_work(struct work_struct *work)
2686 {
2687 struct it6505 *it6505 = container_of(work, struct it6505,
extcon_wq);
2688 struct device *dev = >client->dev;
2689 int state, ret;
2690
2691 if (it6505->enable_drv_hold)
2692 return;
2693
2694 mutex_lock(>extcon_lock);
2695
2696 state = extcon_get_state(it6505->extcon, EXTCON_DISP_DP);
2697 DRM_DEV_DEBUG_DRIVER(dev, "EXTCON_DISP_DP = 0x%02x", state);
2698
2699 if (state == it6505->extcon_state || unlikely(state < 0))
2700 goto unlock;
2701 it6505->extcon_state = state;
2702 if (state) {
2703 DRM_DEV_DEBUG_DRIVER(dev, "start to power on");
2704 msleep(100);
2705 ret = pm_runtime_get_sync(dev);
2706
2707 /*
2708 * On system resume, extcon_work can be triggered
before
2709 * pm_runtime_force_resume re-enables runtime power
management.
2710 * Handling the error here to make sure the bridge is
powered on.
2711 */
--> 2712 if (ret)
2713 it6505_poweron(it6505);
pm_runtime_get_sync() returns 1 on success. Consider using
pm_runtime_resume_and_get() instead.
2714 } else {
2715 DRM_DEV_DEBUG_DRIVER(dev, "start to power off");
2716 pm_runtime_put_sync(dev);
2717
2718 drm_helper_hpd_irq_event(it6505->bridge.dev);
2719 memset(it6505->dpcd, 0, sizeof(it6505->dpcd));
2720 DRM_DEV_DEBUG_DRIVER(dev, "power off it6505 success!");
2721 }
2722
2723 unlock:
2724 mutex_unlock(>extcon_lock);
2725 }
regards,
dan carpenter
Re: [PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
Hi, thanks for detailed review. My responses inline. On 10/25/2022 1:00 AM, Jeffrey Hugo wrote: > On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote: >> VPU stands for Versatile Processing Unit and it's a CPU-integrated >> inference accelerator for Computer Vision and Deep Learning >> applications. >> >> The VPU device consist of following componensts: >>- Buttress - provides CPU to VPU integration, interrupt, frequency and >> power management. >>- Memory Management Unit (based on ARM MMU-600) - translates VPU to >> host DMA addresses, isolates user workloads. >>- RISC based microcontroller - executes firmware that provides job >> execution API for the kernel-mode driver >>- Neural Compute Subsystem (NCS) - does the actual work, provides >> Compute and Copy engines. >>- Network on Chip (NoC) - network fabric connecting all the components >> >> This driver supports VPU IP v2.7 integrated into Intel Meteor Lake >> client CPUs (14th generation). >> >> Module sources are at drivers/gpu/drm/ivpu and module name is >> "intel_vpu.ko". >> >> This patch includes only very besic functionality: >>- module, PCI device and IRQ initialization >>- register definitions and low level register manipulation functions >>- SET/GET_PARAM ioctls >>- power up without firmware >> >> Signed-off-by: Krystian Pradzynski >> Signed-off-by: Jacek Lawrynowicz >> --- >> MAINTAINERS|8 + >> drivers/gpu/drm/Kconfig|2 + >> drivers/gpu/drm/Makefile |1 + >> drivers/gpu/drm/ivpu/Kconfig | 12 + >> drivers/gpu/drm/ivpu/Makefile |8 + >> drivers/gpu/drm/ivpu/TODO |7 + >> drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + >> drivers/gpu/drm/ivpu/ivpu_drv.h| 153 >> drivers/gpu/drm/ivpu/ivpu_hw.h | 169 >> drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 >> drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ >> drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ >> include/uapi/drm/ivpu_drm.h| 95 +++ >> 13 files changed, 2451 insertions(+) >> create mode 100644 drivers/gpu/drm/ivpu/Kconfig >> create mode 100644 drivers/gpu/drm/ivpu/Makefile >> create mode 100644 drivers/gpu/drm/ivpu/TODO >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h >> create mode 100644 include/uapi/drm/ivpu_drm.h >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 9475aa701a3f..d72ceef107e6 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -7046,6 +7046,14 @@ F: >> Documentation/devicetree/bindings/gpu/vivante,gc.yaml >> F:drivers/gpu/drm/etnaviv/ >> F:include/uapi/drm/etnaviv_drm.h >> +DRM DRIVERS FOR VPU >> +M:Jacek Lawrynowicz >> +M:Stanislaw Gruszka >> +S:Supported >> +T:git git://anongit.freedesktop.org/drm/drm-misc >> +F:drivers/gpu/drm/ivpu/ >> +F:include/uapi/drm/ivpu_drm.h > > No mail list? OK, I will add a link to dri-devel. >> + >> DRM DRIVERS FOR XEN >> M:Oleksandr Andrushchenko >> L:dri-devel@lists.freedesktop.org >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 198ba846d34b..0aaac0e5366f 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" >> source "drivers/gpu/drm/vc4/Kconfig" >> +source "drivers/gpu/drm/ivpu/Kconfig" >> + > > Why here of all places? Just randomly in the middle of the list of sourced > Kconfigs? I'll move it to the end. >> source "drivers/gpu/drm/etnaviv/Kconfig" >> source "drivers/gpu/drm/hisilicon/Kconfig" >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index 25d0ba310509..1bfd7415c2d0 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ >> obj-$(CONFIG_DRM_MGAG200) += mgag200/ >> obj-$(CONFIG_DRM_V3D) += v3d/ >> obj-$(CONFIG_DRM_VC4) += vc4/ >> +obj-$(CONFIG_DRM_IVPU) += ivpu/ > > Again, why here? I'll move it to the end. >> diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile >> new file mode 100644 >> index ..e59dc65abe6a >> --- /dev/null >> +++ b/drivers/gpu/drm/ivpu/Makefile >> @@ -0,0 +1,8 @@ >> +# SPDX-License-Identifier: GPL-2.0-only >> +# Copyright © 2022 Intel Corporation > > I'm pretty sure (C) is preferred. Looks like you do this in multiple places. > I'm only going to mention it here. OK, I'll use (C) everywhere. >> +int ivpu_dbg_mask; >> +module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644); >> +MODULE_PARM_DESC(dbg_mask,
[bug report] dma-buf: Move dma_buf_attach() to dynamic locking specification
Hello Dmitry Osipenko,
The patch 809d9c72c2f8: "dma-buf: Move dma_buf_attach() to dynamic
locking specification" from Oct 17, 2022, leads to the following
Smatch static checker warning:
drivers/dma-buf/dma-buf.c:957 dma_buf_dynamic_attach()
error: double unlocked 'dmabuf->resv' (orig line 915)
drivers/dma-buf/dma-buf.c
987 /**
988 * dma_buf_detach - Remove the given attachment from dmabuf's
attachments list
989 * @dmabuf: [in]buffer to detach from.
990 * @attach: [in]attachment to be detached; is free'd after this
call.
991 *
992 * Clean up a device attachment obtained by calling dma_buf_attach().
993 *
994 * Optionally this calls _buf_ops.detach for device-specific detach.
995 */
996 void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment
*attach)
997 {
998 if (WARN_ON(!dmabuf || !attach))
999 return;
1000
1001 dma_resv_lock(attach->dmabuf->resv, NULL);
In the original code used to take this both the "attach->dmabuf->resv"
and "dmabuf->resv" locks and unlock them both. But now it takes one
lock and unlocks the other. Seems sus.
1002
1003 if (attach->sgt) {
1004
1005 __unmap_dma_buf(attach, attach->sgt, attach->dir);
1006
1007 if (dma_buf_is_dynamic(attach->dmabuf))
1008 dmabuf->ops->unpin(attach);
1009 }
1010 list_del(>node);
1011
1012 dma_resv_unlock(dmabuf->resv);
1013
1014 if (dmabuf->ops->detach)
1015 dmabuf->ops->detach(dmabuf, attach);
1016
1017 kfree(attach);
1018 }
regards,
dan carpenter
