Re: [PATCH v2 5/7] drm/msm/dp: Implement hpd_notify()
On 9/16/2022 1:00 PM, Bjorn Andersson wrote: From: Bjorn Andersson The DisplayPort controller's hot-plug mechanism is based on pinmuxing a physical signal no a GPIO pin into the controller. This is not always nit: s/ no / on /? 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.
[PATCH v2 6/7] 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 --- 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.17.1
[PATCH] Updated the orientation quirks to support the many variations of ONEXPLAYER and AokZoe devices.
Signed-off-by: Matthew Anderson
---
.../gpu/drm/drm_panel_orientation_quirks.c| 86 ++-
1 file changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index fc1728d46ac2..15203c134717 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -115,6 +115,18 @@ static const struct drm_dmi_panel_orientation_data
lcd1280x1920_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data lcd800x1280_leftside_up = {
+ .width = 800,
+ .height = 1280,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data lcd1200x1920_leftside_up = {
+ .width = 1200,
+ .height = 1920,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data lcd1600x2560_leftside_up = {
.width = 1600,
.height = 2560,
@@ -128,6 +140,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
},
.driver_data = (void *)_rightside_up,
+ }, {/* AOKZOE A1 AR07 */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "AOKZOE"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "AOKZOE A1 AR07"),
+ },
+ .driver_data = (void *)_leftside_up,
}, {/* Asus T100HA */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
@@ -308,12 +326,78 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"),
},
.driver_data = (void *)_pro,
- }, {/* OneXPlayer */
+ }, {/* OneXPlayer 800P Original DMI Values */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK TECHNOLOGY CO.,
LTD."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONE XPLAYER"),
+ },
+ .driver_data = (void *)_leftside_up,
+ }, {/* OneXPlayer 1200P Original DMI Values */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK TECHNOLOGY CO.,
LTD."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONE XPLAYER"),
+ },
+ .driver_data = (void *)_leftside_up,
+ }, {/* OneXPlayer 1600P Original DMI Values */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK TECHNOLOGY CO.,
LTD."),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONE XPLAYER"),
},
.driver_data = (void *)_leftside_up,
+ }, {/* OneXPlayer Gundam Edition Bios Updated */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONEXPLAYER GUNDAM GA72"),
+ },
+ .driver_data = (void *)_leftside_up,
+ }, {/* ONEXPLAYER mini A07 800P Bios Updated */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONEXPLAYER mini A07"),
+ },
+ .driver_data = (void *)_leftside_up,
+ }, {/* ONEXPLAYER mini A07 1200P Bios Updated*/
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONEXPLAYER mini A07"),
+ },
+ .driver_data = (void *)_leftside_up,
+ }, {/* ONEXPLAYER mini GA72 800P Bios Updated*/
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONEXPLAYER mini GA72"),
+ },
+ .driver_data = (void *)_leftside_up,
+ }, {/* ONEXPLAYER mini GA72 1200P Bios Updated*/
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONEXPLAYER mini GA72"),
+ },
+ .driver_data = (void *)_leftside_up,
+ }, {/* ONEXPLAYER mini GT72 800P Bios Updated*/
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONEXPLAYER mini GT72"),
+ },
+ .driver_data = (void *)_leftside_up,
+ }, {/* ONEXPLAYER mini GT72 1200P Bios Updated*/
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONEXPLAYER mini GT72"),
+ },
+
[PATCH v2 2/7] 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
---
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 +1252,9 @@ static const struct
[PATCH v2 7/7] 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 --- 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.17.1
[PATCH v2 3/7] 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
---
drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
drivers/gpu/drm/msm/msm_drv.h | 1 +
2 files changed, 23 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 },
{}
};
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b2ea262296a4..2dd342e49de6 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -61,6 +61,7 @@ enum msm_dp_controller {
MSM_DP_CONTROLLER_0,
MSM_DP_CONTROLLER_1,
MSM_DP_CONTROLLER_2,
+ MSM_DP_CONTROLLER_3,
MSM_DP_CONTROLLER_COUNT,
};
--
2.17.1
Re: [PATCH v5 0/2] Fix TLB invalidate issues with Broadwell [preempt-rt regression]
[[PATCH v5 0/2] Fix TLB invalidate issues with Broadwell] On 12/07/2022 (Tue
16:21) Mauro Carvalho Chehab wrote:
> i915 selftest hangcheck is causing the i915 driver timeouts, as reported
> by Intel CI bot:
>
> http://gfx-ci.fi.intel.com/cibuglog-ng/issuefilterassoc/24297?query_key=42a999f48fa6ecce068bc8126c069be7c31153b4
[...]
> After that, the machine just silently hangs.
>
> Bisecting the issue, the patch that introduced the regression is:
>
> 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
>
> Reverting it fix the issues, but introduce other problems, as TLB
> won't be invalidated anymore. So, instead, let's fix the root cause.
>
> It turns that the TLB flush logic ends conflicting with i915 reset,
> which is called during selftest hangcheck. So, the TLB cache should
> be serialized together with i915 reset.
>
> Tested on an Intel NUC5i7RYB with an i7-5557U Broadwell CPU.
It turns out that this breaks PM-suspend operations on preempt-rt, on
multiple versions, due to all the linux-stable backports. This happens
because the uncore->lock is now used in atomic contexts.
As the uncore->lock is widely used, conversion to a raw lock seems
inappropriate at 1st glance, and hence some alternate solution will
likely be required.
Below is an example of the regression on v5.15-rt, with backport:
commit 0ee5874dad61d2b154a9e3db196fc33e8208ce1b
Author: Chris Wilson
Date: Tue Jul 12 16:21:32 2022 +0100
drm/i915/gt: Serialize GRDOM access between multiple engine resets
[ Upstream commit b24dcf1dc507f69ed3b5c66c2b6a0209ae80d4d4 ]
Reverting the engine reset serialization change avoids the PM-suspend
regression and is a temporary workaround for -rt users, but of course
leaves this original TLB issue exposed.
BUG: sleeping function called from invalid context at
kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 45092, name:
kworker/u8:4
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
Preemption disabled at:
[] __intel_gt_reset+0x92/0x100 [i915]
CPU: 3 PID: 45092 Comm: kworker/u8:4 Tainted: GW O
5.15.59-rt48-preempt-rt #1
Hardware name: Intel(R) Client Systems NUC7i5DNKE/NUC7i5DNB, BIOS
DNKBLi5v.86A.0064.2019.0523.1933 05/23/2019
Workqueue: events_unbound async_run_entry_fn
Call Trace:
show_stack+0x52/0x5c
dump_stack_lvl+0x5b/0x86
dump_stack+0x10/0x16
__might_resched.cold+0xf7/0x12f
? __gen6_reset_engines.constprop.0+0x80/0x80 [i915]
rt_spin_lock+0x4e/0xf0
? gen8_reset_engines+0x2e/0x1e0 [i915]
gen8_reset_engines+0x2e/0x1e0 [i915]
? __gen6_reset_engines.constprop.0+0x80/0x80 [i915]
__intel_gt_reset+0x9d/0x100 [i915]
gt_sanitize+0x16c/0x190 [i915]
intel_gt_suspend_late+0x3d/0xc0 [i915]
i915_gem_suspend_late+0x57/0x130 [i915]
i915_drm_suspend_late+0x38/0x110 [i915]
i915_pm_suspend_late+0x1d/0x30 [i915]
pm_generic_suspend_late+0x28/0x40
pci_pm_suspend_late+0x37/0x50
? pci_pm_poweroff_late+0x50/0x50
dpm_run_callback.cold+0x3c/0xa8
__device_suspend_late+0xa4/0x1e0
async_suspend_late+0x20/0xa0
async_run_entry_fn+0x28/0xc0
process_one_work+0x239/0x6c0
worker_thread+0x58/0x3e0
kthread+0x1a9/0x1d0
? process_one_work+0x6c0/0x6c0
? set_kthread_struct+0x50/0x50
ret_from_fork+0x1f/0x30
PM: late suspend of devices complete after 26.497 msecs
Paul.
--
>
> v5:
> - Added a missing SoB on patch 2.
> - No other changes.
>
> v4:
> - No functional changes. All changes are at the patch descriptions:
> - collected acked-by/reviewed-by;
> - use the same e-mail on Author and SoB on patch 1.
>
> v3:
> - Removed the logic that would check if the engine is awake before doing
> TLB flush invalidation as backporting PM logic up to Kernel 4.x could be
> too painful. After getting this one merged, I'll submit a separate patch
> with the PM awake logic.
>
> v2:
>
> - Reduced to bare minimum fixes, as this shoud be backported deeply
> into stable.
>
> Chris Wilson (2):
> drm/i915/gt: Serialize GRDOM access between multiple engine resets
> drm/i915/gt: Serialize TLB invalidates with GT resets
>
> drivers/gpu/drm/i915/gt/intel_gt.c| 15 ++-
> drivers/gpu/drm/i915/gt/intel_reset.c | 37 ---
> 2 files changed, 42 insertions(+), 10 deletions(-)
>
> --
> 2.36.1
>
>
[PATCH v2 5/7] drm/msm/dp: Implement hpd_notify()
From: Bjorn Andersson
The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
physical signal no 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
---
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.17.1
[PATCH v2 1/7] 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 --- .../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.17.1
[PATCH v2 4/7] 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
---
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.17.1
[PATCH v2 0/7] drm/msm/dp: Support for external displays
Introduce support for DisplayPort on SDM845 and SC8280XP, followed by introduction of drm_bridge based HPD handling. The version of these patches are restarted, as the previous drm_connector_oob_hotplug_event()-based approach was abandoned and this only barely resembles that effort. In this effort the HPD handling is based on the reliance of the hpd_notify() being invoked by a downstream (next_bridge) drm_bridge implementation, such as the standard display-connector, or a something like an USB Type-C controller implementation. Bjorn Andersson (7): 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 .../bindings/display/msm/dp-controller.yaml | 3 + 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 + 5 files changed, 88 insertions(+), 54 deletions(-) -- 2.17.1
Re: [PATCH 1/2] drm/amd/display: Reduce number of arguments of dml314's CalculateWatermarksAndDRAMSpeedChangeSupport()
On Fri, Sep 16, 2022 at 03:04:53PM -0700, Tom Rix wrote:
>
> On 9/16/22 2:06 PM, Nathan Chancellor wrote:
> > Most of the arguments are identical between the two call sites and they
> > can be accessed through the 'struct vba_vars_st' pointer. This reduces
> > the total amount of stack space that
> > dml314_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with
> > LLVM 16 (2216 -> 1976), helping clear up the following clang warning:
> >
> >
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:4020:6:
> > error: stack frame size (2216) exceeds limit (2048) in
> > 'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
> >void dml314_ModeSupportAndSystemConfigurationFull(struct
> > display_mode_lib *mode_lib)
> > ^
> >1 error generated.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1710
> > Reported-by: "kernelci.org bot"
> > Signed-off-by: Nathan Chancellor
>
> Nathan,
>
> I like this change but I don't think it goes far enough.
>
> There are many similar functions in this file and there other
> display_node_vba_*.c files that pass too many vba_vars_st elements.
>
> I think most/all of the static functions should be refactored to pass
> vba_vars_st * or vba_vars_st **
>
> fwiw, i found the calling function
> DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation,
> hilariously long :)
>
> I'll do the change if you want to pass this to me, I promise not to add to
> the above function name.
Right, there is definitely more that could be done here; I just picked
the couple of functions that would appear to make the most impact, as I
am only concerned with keeping the code warning free with clang so that
-Werror does not break us. I think it makes sense to take this series to
fix the warnings right now (especially since this patch has technically
already been accepted, as it was applied to dcn31) then follow up with
refactoring, which I am more than happy to let you do if you so desire
:)
Thank you for the input as always!
Cheers,
Nathan
> > ---
> >
> > This is just commit ab2ac59c32db ("drm/amd/display: Reduce number of
> > arguments of dml31's CalculateWatermarksAndDRAMSpeedChangeSupport()")
> > applied to dml314.
> >
> > .../dc/dml/dcn314/display_mode_vba_314.c | 248 --
> > 1 file changed, 52 insertions(+), 196 deletions(-)
> >
> > diff --git
> > a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
> > b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
> > index 2829f179f982..32ceb72f7a14 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
> > @@ -325,64 +325,28 @@ static void
> > CalculateVupdateAndDynamicMetadataParameters(
> > static void CalculateWatermarksAndDRAMSpeedChangeSupport(
> > struct display_mode_lib *mode_lib,
> > unsigned int PrefetchMode,
> > - unsigned int NumberOfActivePlanes,
> > - unsigned int MaxLineBufferLines,
> > - unsigned int LineBufferSize,
> > - unsigned int WritebackInterfaceBufferSize,
> > double DCFCLK,
> > double ReturnBW,
> > - bool SynchronizedVBlank,
> > - unsigned int dpte_group_bytes[],
> > - unsigned int MetaChunkSize,
> > double UrgentLatency,
> > double ExtraLatency,
> > - double WritebackLatency,
> > - double WritebackChunkSize,
> > double SOCCLK,
> > - double DRAMClockChangeLatency,
> > - double SRExitTime,
> > - double SREnterPlusExitTime,
> > - double SRExitZ8Time,
> > - double SREnterPlusExitZ8Time,
> > double DCFCLKDeepSleep,
> > unsigned int DETBufferSizeY[],
> > unsigned int DETBufferSizeC[],
> > unsigned int SwathHeightY[],
> > unsigned int SwathHeightC[],
> > - unsigned int LBBitPerPixel[],
> > double SwathWidthY[],
> > double SwathWidthC[],
> > - double HRatio[],
> > - double HRatioChroma[],
> > - unsigned int vtaps[],
> > - unsigned int VTAPsChroma[],
> > - double VRatio[],
> > - double VRatioChroma[],
> > - unsigned int HTotal[],
> > - double PixelClock[],
> > - unsigned int BlendingAndTiming[],
> > unsigned int DPPPerPlane[],
> > double BytePerPixelDETY[],
> > double BytePerPixelDETC[],
> > - double DSTXAfterScaler[],
> > - double DSTYAfterScaler[],
> > - bool WritebackEnable[],
> > - enum source_format_class WritebackPixelFormat[],
> > - double WritebackDestinationWidth[],
> > - double WritebackDestinationHeight[],
> > - double
Re: [PATCH 1/2] drm/amd/display: Reduce number of arguments of dml314's CalculateWatermarksAndDRAMSpeedChangeSupport()
On 9/16/22 2:06 PM, Nathan Chancellor wrote:
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
dml314_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with
LLVM 16 (2216 -> 1976), helping clear up the following clang warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:4020:6:
error: stack frame size (2216) exceeds limit (2048) in
'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml314_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
^
1 error generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/1710
Reported-by: "kernelci.org bot"
Signed-off-by: Nathan Chancellor
Nathan,
I like this change but I don't think it goes far enough.
There are many similar functions in this file and there other
display_node_vba_*.c files that pass too many vba_vars_st elements.
I think most/all of the static functions should be refactored to pass
vba_vars_st * or vba_vars_st **
fwiw, i found the calling function
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation,
hilariously long :)
I'll do the change if you want to pass this to me, I promise not to add
to the above function name.
Tom
---
This is just commit ab2ac59c32db ("drm/amd/display: Reduce number of
arguments of dml31's CalculateWatermarksAndDRAMSpeedChangeSupport()")
applied to dml314.
.../dc/dml/dcn314/display_mode_vba_314.c | 248 --
1 file changed, 52 insertions(+), 196 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
index 2829f179f982..32ceb72f7a14 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
@@ -325,64 +325,28 @@ static void CalculateVupdateAndDynamicMetadataParameters(
static void CalculateWatermarksAndDRAMSpeedChangeSupport(
struct display_mode_lib *mode_lib,
unsigned int PrefetchMode,
- unsigned int NumberOfActivePlanes,
- unsigned int MaxLineBufferLines,
- unsigned int LineBufferSize,
- unsigned int WritebackInterfaceBufferSize,
double DCFCLK,
double ReturnBW,
- bool SynchronizedVBlank,
- unsigned int dpte_group_bytes[],
- unsigned int MetaChunkSize,
double UrgentLatency,
double ExtraLatency,
- double WritebackLatency,
- double WritebackChunkSize,
double SOCCLK,
- double DRAMClockChangeLatency,
- double SRExitTime,
- double SREnterPlusExitTime,
- double SRExitZ8Time,
- double SREnterPlusExitZ8Time,
double DCFCLKDeepSleep,
unsigned int DETBufferSizeY[],
unsigned int DETBufferSizeC[],
unsigned int SwathHeightY[],
unsigned int SwathHeightC[],
- unsigned int LBBitPerPixel[],
double SwathWidthY[],
double SwathWidthC[],
- double HRatio[],
- double HRatioChroma[],
- unsigned int vtaps[],
- unsigned int VTAPsChroma[],
- double VRatio[],
- double VRatioChroma[],
- unsigned int HTotal[],
- double PixelClock[],
- unsigned int BlendingAndTiming[],
unsigned int DPPPerPlane[],
double BytePerPixelDETY[],
double BytePerPixelDETC[],
- double DSTXAfterScaler[],
- double DSTYAfterScaler[],
- bool WritebackEnable[],
- enum source_format_class WritebackPixelFormat[],
- double WritebackDestinationWidth[],
- double WritebackDestinationHeight[],
- double WritebackSourceHeight[],
bool UnboundedRequestEnabled,
unsigned int CompressedBufferSizeInkByte,
enum clock_change_support *DRAMClockChangeSupport,
- double *UrgentWatermark,
- double *WritebackUrgentWatermark,
- double *DRAMClockChangeWatermark,
- double *WritebackDRAMClockChangeWatermark,
double *StutterExitWatermark,
double *StutterEnterPlusExitWatermark,
double *Z8StutterExitWatermark,
- double *Z8StutterEnterPlusExitWatermark,
- double *MinActiveDRAMClockChangeLatencySupported);
+ double *Z8StutterEnterPlusExitWatermark);
static void CalculateDCFCLKDeepSleep(
struct
Re: [PATCH v3] drm/plane-helper: Add a drm_plane_helper_atomic_check() helper
On 9/13/22 18:23, Javier Martinez Canillas wrote: > Provides a default plane state check handler for primary planes that are a > fullscreen scanout buffer and whose state scale and position can't change. > > There are some drivers that duplicate this logic in their helpers, such as > simpledrm and ssd130x. Factor out this common code into a plane helper and > make drivers use it. > > Suggested-by: Thomas Zimmermann > Signed-off-by: Javier Martinez Canillas > Reviewed-by: Thomas Zimmermann > --- > Pushed this to drm-misc (drm-misc-next). Thanks! -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
[PATCH 2/2] drm/amd/display: Reduce number of arguments of dml314's CalculateFlipSchedule()
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
dml314_ModeSupportAndSystemConfigurationFull() uses by 112 bytes with
LLVM 16 (1976 -> 1864), helping clear up the following clang warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:4020:6:
error: stack frame size (2216) exceeds limit (2048) in
'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml314_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
^
1 error generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/1710
Reported-by: "kernelci.org bot"
Signed-off-by: Nathan Chancellor
---
This is just commit 1dbec5b4b0ef ("drm/amd/display: Reduce number of
arguments of dml31's CalculateFlipSchedule()") applied to dml314.
.../dc/dml/dcn314/display_mode_vba_314.c | 172 +-
1 file changed, 47 insertions(+), 125 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
index 32ceb72f7a14..e4dfa714207a 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
@@ -265,33 +265,13 @@ static void CalculateRowBandwidth(
static void CalculateFlipSchedule(
struct display_mode_lib *mode_lib,
+ unsigned int k,
double HostVMInefficiencyFactor,
double UrgentExtraLatency,
double UrgentLatency,
- unsigned int GPUVMMaxPageTableLevels,
- bool HostVMEnable,
- unsigned int HostVMMaxNonCachedPageTableLevels,
- bool GPUVMEnable,
- double HostVMMinPageSize,
double PDEAndMetaPTEBytesPerFrame,
double MetaRowBytes,
- double DPTEBytesPerRow,
- double BandwidthAvailableForImmediateFlip,
- unsigned int TotImmediateFlipBytes,
- enum source_format_class SourcePixelFormat,
- double LineTime,
- double VRatio,
- double VRatioChroma,
- double Tno_bw,
- bool DCCEnable,
- unsigned int dpte_row_height,
- unsigned int meta_row_height,
- unsigned int dpte_row_height_chroma,
- unsigned int meta_row_height_chroma,
- double *DestinationLinesToRequestVMInImmediateFlip,
- double *DestinationLinesToRequestRowInImmediateFlip,
- double *final_flip_bw,
- bool *ImmediateFlipSupportedForPipe);
+ double DPTEBytesPerRow);
static double CalculateWriteBackDelay(
enum source_format_class WritebackPixelFormat,
double WritebackHRatio,
@@ -2892,33 +2872,13 @@ static void
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
for (k = 0; k < v->NumberOfActivePlanes; ++k) {
CalculateFlipSchedule(
mode_lib,
+ k,
HostVMInefficiencyFactor,
v->UrgentExtraLatency,
v->UrgentLatency,
- v->GPUVMMaxPageTableLevels,
- v->HostVMEnable,
-
v->HostVMMaxNonCachedPageTableLevels,
- v->GPUVMEnable,
- v->HostVMMinPageSize,
v->PDEAndMetaPTEBytesFrame[k],
v->MetaRowByte[k],
- v->PixelPTEBytesPerRow[k],
-
v->BandwidthAvailableForImmediateFlip,
- v->TotImmediateFlipBytes,
- v->SourcePixelFormat[k],
- v->HTotal[k] / v->PixelClock[k],
- v->VRatio[k],
- v->VRatioChroma[k],
- v->Tno_bw[k],
- v->DCCEnable[k],
- v->dpte_row_height[k],
- v->meta_row_height[k],
- v->dpte_row_height_chroma[k],
- v->meta_row_height_chroma[k],
[PATCH 1/2] drm/amd/display: Reduce number of arguments of dml314's CalculateWatermarksAndDRAMSpeedChangeSupport()
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
dml314_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with
LLVM 16 (2216 -> 1976), helping clear up the following clang warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:4020:6:
error: stack frame size (2216) exceeds limit (2048) in
'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml314_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
^
1 error generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/1710
Reported-by: "kernelci.org bot"
Signed-off-by: Nathan Chancellor
---
This is just commit ab2ac59c32db ("drm/amd/display: Reduce number of
arguments of dml31's CalculateWatermarksAndDRAMSpeedChangeSupport()")
applied to dml314.
.../dc/dml/dcn314/display_mode_vba_314.c | 248 --
1 file changed, 52 insertions(+), 196 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
index 2829f179f982..32ceb72f7a14 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
@@ -325,64 +325,28 @@ static void CalculateVupdateAndDynamicMetadataParameters(
static void CalculateWatermarksAndDRAMSpeedChangeSupport(
struct display_mode_lib *mode_lib,
unsigned int PrefetchMode,
- unsigned int NumberOfActivePlanes,
- unsigned int MaxLineBufferLines,
- unsigned int LineBufferSize,
- unsigned int WritebackInterfaceBufferSize,
double DCFCLK,
double ReturnBW,
- bool SynchronizedVBlank,
- unsigned int dpte_group_bytes[],
- unsigned int MetaChunkSize,
double UrgentLatency,
double ExtraLatency,
- double WritebackLatency,
- double WritebackChunkSize,
double SOCCLK,
- double DRAMClockChangeLatency,
- double SRExitTime,
- double SREnterPlusExitTime,
- double SRExitZ8Time,
- double SREnterPlusExitZ8Time,
double DCFCLKDeepSleep,
unsigned int DETBufferSizeY[],
unsigned int DETBufferSizeC[],
unsigned int SwathHeightY[],
unsigned int SwathHeightC[],
- unsigned int LBBitPerPixel[],
double SwathWidthY[],
double SwathWidthC[],
- double HRatio[],
- double HRatioChroma[],
- unsigned int vtaps[],
- unsigned int VTAPsChroma[],
- double VRatio[],
- double VRatioChroma[],
- unsigned int HTotal[],
- double PixelClock[],
- unsigned int BlendingAndTiming[],
unsigned int DPPPerPlane[],
double BytePerPixelDETY[],
double BytePerPixelDETC[],
- double DSTXAfterScaler[],
- double DSTYAfterScaler[],
- bool WritebackEnable[],
- enum source_format_class WritebackPixelFormat[],
- double WritebackDestinationWidth[],
- double WritebackDestinationHeight[],
- double WritebackSourceHeight[],
bool UnboundedRequestEnabled,
unsigned int CompressedBufferSizeInkByte,
enum clock_change_support *DRAMClockChangeSupport,
- double *UrgentWatermark,
- double *WritebackUrgentWatermark,
- double *DRAMClockChangeWatermark,
- double *WritebackDRAMClockChangeWatermark,
double *StutterExitWatermark,
double *StutterEnterPlusExitWatermark,
double *Z8StutterExitWatermark,
- double *Z8StutterEnterPlusExitWatermark,
- double *MinActiveDRAMClockChangeLatencySupported);
+ double *Z8StutterEnterPlusExitWatermark);
static void CalculateDCFCLKDeepSleep(
struct display_mode_lib *mode_lib,
@@ -3041,64 +3005,28 @@ static void
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
CalculateWatermarksAndDRAMSpeedChangeSupport(
mode_lib,
PrefetchMode,
- v->NumberOfActivePlanes,
- v->MaxLineBufferLines,
- v->LineBufferSize,
- v->WritebackInterfaceBufferSize,
v->DCFCLK,
v->ReturnBW,
-
[PATCH] drm/i915/gt: Bump the reset-failure timeout to 60s
From: Chris Wilson
If attempting to perform a GT reset takes long than 5 seconds (including
resetting the display for gen3/4), then we declare all hope lost and
discard all user work and wedge the device to prevent further
misbehaviour. 5 seconds is too short a time for such drastic action, as
we may be stuck on other timeouts and watchdogs. If we allow a little
bit longer before hitting the big red button, we should at the very
least capture other hung task indicators pointing towards the reason why
the reset was hanging; and allow more marginal cases the extra headroom
to complete the reset without further collateral damage.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/6448
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index b36674356986..3159df6cdd49 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1278,7 +1278,7 @@ static void intel_gt_reset_global(struct intel_gt *gt,
kobject_uevent_env(kobj, KOBJ_CHANGE, reset_event);
/* Use a watchdog to ensure that our reset completes */
- intel_wedge_on_timeout(, gt, 5 * HZ) {
+ intel_wedge_on_timeout(, gt, 60 * HZ) {
intel_display_prepare_reset(gt->i915);
intel_gt_reset(gt, engine_mask, reason);
--
2.34.1
[PATCH] drm/vmwgfx: Fix memory leak in vmw_mksstat_add_ioctl()
If the copy of the description string from userspace fails, then the page
for the instance descriptor doesn't get freed before returning -EFAULT,
which leads to a memleak.
Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce VMware mks-guest-stats")
Signed-off-by: Rafael Mendonca
---
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 2aceac7856e2..089046fa21be 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -1076,6 +1076,7 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void
*data,
if (desc_len < 0) {
atomic_set(_priv->mksstat_user_pids[slot], 0);
+ __free_page(page);
return -EFAULT;
}
--
2.34.1
[PATCH] drm/i915/gt: Bump the reset-failure timeout to 60s
From: Chris Wilson
If attempting to perform a GT reset takes long than 5 seconds (including
resetting the display for gen3/4), then we declare all hope lost and
discard all user work and wedge the device to prevent further
misbehaviour. 5 seconds is too short a time for such drastic action, as
we may be stuck on other timeouts and watchdogs. If we allow a little
bit longer before hitting the big red button, we should at the very
least capture other hung task indicators pointing towards the reason why
the reset was hanging; and allow more marginal cases the extra headroom
to complete the reset without further collateral damage.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index b36674356986..3159df6cdd49 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1278,7 +1278,7 @@ static void intel_gt_reset_global(struct intel_gt *gt,
kobject_uevent_env(kobj, KOBJ_CHANGE, reset_event);
/* Use a watchdog to ensure that our reset completes */
- intel_wedge_on_timeout(, gt, 5 * HZ) {
+ intel_wedge_on_timeout(, gt, 60 * HZ) {
intel_display_prepare_reset(gt->i915);
intel_gt_reset(gt, engine_mask, reason);
--
2.34.1
[linux-next:master] BUILD REGRESSION d5538ab91d3a9a237805be6f8c6c272af2987995
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: d5538ab91d3a9a237805be6f8c6c272af2987995 Add linux-next specific files for 20220916 Error/Warning reports: https://lore.kernel.org/linux-media/202209162214.lzfxhn2b-...@intel.com https://lore.kernel.org/linux-mm/202209150141.wgbakqmx-...@intel.com https://lore.kernel.org/linux-mm/202209150959.hewcnjxh-...@intel.com https://lore.kernel.org/linux-mm/202209160607.se3qvgty-...@intel.com https://lore.kernel.org/linux-mm/202209170126.ogpr2nd1-...@intel.com https://lore.kernel.org/llvm/202209161913.vndfwg7o-...@intel.com Error/Warning: (recently discovered and may have been fixed) ERROR: modpost: "devm_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_memremap" [drivers/misc/open-dice.ko] undefined! ERROR: modpost: "devm_memunmap" [drivers/misc/open-dice.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/char/xillybus/xillybus_of.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/clk/xilinx/clk-xlnx-clock-wizard.ko] undefined! ERROR: modpost: "dm365_vpss_set_pg_frame_size" [drivers/staging/media/deprecated/vpfe_capture/isif.ko] undefined! ERROR: modpost: "dm365_vpss_set_sync_pol" [drivers/staging/media/deprecated/vpfe_capture/isif.ko] undefined! ERROR: modpost: "ioremap" [drivers/tty/ipwireless/ipwireless.ko] undefined! ERROR: modpost: "iounmap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined! ERROR: modpost: "iounmap" [drivers/tty/ipwireless/ipwireless.ko] undefined! ERROR: modpost: "vpss_clear_wbl_overflow" [drivers/staging/media/deprecated/vpfe_capture/dm644x_ccdc.ko] undefined! ERROR: modpost: "vpss_enable_clock" [drivers/staging/media/deprecated/vpfe_capture/dm355_ccdc.ko] undefined! ERROR: modpost: "vpss_enable_clock" [drivers/staging/media/deprecated/vpfe_capture/isif.ko] undefined! ERROR: modpost: "vpss_select_ccdc_source" [drivers/staging/media/deprecated/vpfe_capture/dm355_ccdc.ko] undefined! ERROR: modpost: "vpss_select_ccdc_source" [drivers/staging/media/deprecated/vpfe_capture/isif.ko] undefined! arch/arm/include/asm/arch_gicv3.h:18:41: error: implicit declaration of function '__ACCESS_CP15' [-Werror=implicit-function-declaration] arch/arm/include/asm/arch_gicv3.h:18:55: error: 'c12' undeclared (first use in this function) arch/arm/include/asm/arch_gicv3.h:19:63: error: 'c11' undeclared (first use in this function) arch/arm/include/asm/arch_gicv3.h:21:41: error: implicit declaration of function '__ACCESS_CP15_64' [-Werror=implicit-function-declaration] arch/arm/include/asm/arch_gicv3.h:22:55: error: 'c4' undeclared (first use in this function) arch/arm/include/asm/arch_gicv3.h:22:62: error: 'c6' undeclared (first use in this function) arch/arm/include/asm/arch_gicv3.h:29:63: error: 'c8' undeclared (first use in this function); did you mean 'u8'? arch/arm/include/asm/arch_gicv3.h:35:63: error: 'c9' undeclared (first use in this function) arch/arm/include/asm/arch_gicv3.h:44:9: error: implicit declaration of function 'write_sysreg' [-Werror=implicit-function-declaration] arch/arm/include/asm/arch_gicv3.h:48:16: error: implicit declaration of function 'read_sysreg' [-Werror=implicit-function-declaration] arch/parisc/lib/iomap.c:363:5: warning: no previous prototype for 'ioread64_lo_hi' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:373:5: warning: no previous prototype for 'ioread64_hi_lo' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:448:6: warning: no previous prototype for 'iowrite64_lo_hi' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:454:6: warning: no previous prototype for 'iowrite64_hi_lo' [-Wmissing-prototypes] drivers/gpu/drm/drm_atomic_helper.c:802: warning: expecting prototype for drm_atomic_helper_check_wb_connector_state(). Prototype was for drm_atomic_helper_check_wb_encoder_state() instead drivers/scsi/qla2xxx/qla_os.c:2854:23: warning: assignment to 'struct trace_array *' from 'int' makes pointer from integer without a cast [-Wint-conversion] drivers/scsi/qla2xxx/qla_os.c:2854:25: error: implicit declaration of function 'trace_array_get_by_name'; did you mean 'trace_array_set_clr_event'? [-Werror=implicit-function-declaration] drivers/scsi/qla2xxx/qla_os.c:2869:9: error: implicit declaration of function 'trace_array_put' [-Werror=implicit-function-declaration] drivers/thermal/thermal_helpers.c:79:6: warning: Redundant initialization for 'ret'. The initialized value is overwritten before it is read. [redundantInitialization] make[5]: *** No rule to make target 'drivers/crypto/aspeed/aspeed_crypto.o', needed by 'drivers/crypto/aspeed/'. s390-linux-ld: (.text+0x24a4): undefined reference to `ftrace_likely_update' Unverified Error/Warning (likely false positive, please contact us if interested): ERROR: modpost: "devm_iorem
Re: [Intel-gfx] [PATCH 1/1] drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names
On 9/16/2022 02:10, Tvrtko Ursulin wrote: On 15/09/2022 21:03, John Harrison wrote: On 9/15/2022 01:59, Tvrtko Ursulin wrote: Hi, On 15/09/2022 00:46, john.c.harri...@intel.com wrote: From: John Harrison Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for all platforms that are officially GuC/HuC enabled. Also, update the expected GuC version numbers to the latest firmware release for those platforms. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 1169e2a09da24..b91ad4aede1f7 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -72,12 +72,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \ Just glancing over out of curiosity. Part which confused me is that if only major is supposed to be used then what is the '5' in guc_maj(dg2, 70, 5) ? See the earlier patch that added support for version reduced filenames. The minor number is still specified because want to be able to warn the user if their firmware is out of date and causing them to miss features, security fixes, etc. The driver will still load any old firmware with the right name and work with it, but user's need to know that there are updates available. Got it. Release is deemed not important enough to warn about? no actually, it's different, I guess we never expect to bump only the release with a source level change - so in practice kernel could not warn that there is a newer release version since it would never know. In other words those ones would only be hitting linux-firmware, while minor changes would be kernel patches as well. By "release" you mean patch level? As in . Yeah, I'm in two minds about being explicit on the patch level. It is possible that a particular feature might be added in 70.6.0 but then we find a bug, so it's only usable in 70.6.1. In which case, we want the KMD to notify users that an update is required. But in that case, we would also want to patch the kernel to disable that feature unless 70.6.1 or later is actually found. Or, there is just a straight up bug that affects everything and is fixed in 70.5.2. Again, we would want to notify that an update is available. But we can't exactly patch the kernel to not load i915 if 70.5.2 is not available. Having said that, updating the 'requested' version is a KMD change regardless of whether it is a bump of the major, minor or patch level version number. In which case, we have the opportunity to add in patch level reporting at that point if required. But the counter argument is that, as you say, a firmware bug fix does not generally require an actual KMD code change. The i915 patch would purely be to bump the version number. So is it worth the churn? For major/minor changes there are corresponding i915 changes - either a re-write of existing code (major) or a new feature being added (minor). So bumping the number is 'free' given that a patch is required regardless. And is the code churn to provide a warning really useful? Would an end user ever notice the line in dmesg? Isn't it up to the distros to provide important bug fixes via package updates when necessary? So yeah, not sure. Unnecessary code churn versus warning about potentially important bug fixes. Pick your evil. I also couldn't find guc_maj with grep so I guess it's some sort of a magic concatenation macro or what? 'guc_maj' is a macro parameter as per the definition of the macro three lines above. According to where INTEL_GUC_FIRMWARE_DEFS is used, it becomes either a mechanism for creating just a 'MODULE_FIRMWARE' definition for the firmware file or a table entry giving all the version information as well as the filename. Doh thanks, macro magic was apparently impenetrable to me yesterday. Yeah, this particular set of macro magic is impressively complex. It took me quite a while to properly understand exactly what is happening and how when I did the actual versionless filename updates in the first place! John. Regards, Tvrtko
Re: [PATCH v2 3/3] dt-bindings: display: bridge: nxp,tda998x: Convert to json-schema
On Thu, 15 Sep 2022 12:15:28 +0100, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Thu, Sep 15, 2022 at 10:26 AM Krzysztof Kozlowski
> wrote:
> > On Wed, 14 Sep 2022 16:33:22 +0200, Geert Uytterhoeven wrote:
> > > Convert the NXP TDA998x HDMI transmitter Device Tree binding
> > > documentation to json-schema.
> > >
> > > Add missing "#sound-dai-cells" property.
> > > Add ports hierarchy, as an alternative to port.
> > > Drop pinctrl properties, as they do not belong here.
> > >
> > > Signed-off-by: Geert Uytterhoeven
> > > ---
> > > v2:
> > > - Add maximum to video-ports,
> > > - Drop unneeded maxItems for audio-ports,
> > > - Complete port descriptions.
> > > ---
> > > .../bindings/display/bridge/nxp,tda998x.yaml | 109 ++
> > > .../bindings/display/bridge/tda998x.txt | 54 -
> > > 2 files changed, 109 insertions(+), 54 deletions(-)
> > > create mode 100644
> > > Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
> > > delete mode 100644
> > > Documentation/devicetree/bindings/display/bridge/tda998x.txt
> > >
> >
> > Running 'make dtbs_check' with the schema in this patch gives the
> > following warnings. Consider if they are expected or the schema is
> > incorrect. These may not be new warnings.
> >
> > Note that it is not yet a requirement to have 0 warnings for dtbs_check.
> > This will change in the future.
> >
> > Full log is available here: https://patchwork.ozlabs.org/patch/
> >
> >
> > tda19988@70: 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'
> > arch/arm64/boot/dts/renesas/r8a774c0-cat874.dtb
> > arch/arm64/boot/dts/renesas/r8a774c0-ek874.dtb
> > arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dtb
> > arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dtb
> >
> > tda19988@70: ports: 'oneOf' conditional failed, one must be fixed:
> > arch/arm/boot/dts/am335x-boneblack.dtb
> > arch/arm/boot/dts/am335x-boneblack-wireless.dtb
> > arch/arm/boot/dts/am335x-sancloud-bbe.dtb
> >
> > tda19988@70: ports:port@0: 'reg' is a required property
> > arch/arm/boot/dts/am335x-boneblack.dtb
> > arch/arm/boot/dts/am335x-boneblack-wireless.dtb
> > arch/arm/boot/dts/am335x-sancloud-bbe.dtb
> >
> > tda9988@70: ports: 'oneOf' conditional failed, one must be fixed:
> > arch/arm/boot/dts/am335x-myirtech-myd.dtb
> >
> > tda9988@70: ports:port@0: 'reg' is a required property
> > arch/arm/boot/dts/am335x-myirtech-myd.dtb
>
> Please test this with the earlier patches in the same series applied ;-)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
>
> From git@z Thu Jan 1 00:00:00 1970
> Return-Path:
> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
> aws-us-west-2-korg-lkml-1.web.codeaurora.org
> Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
> by smtp.lore.kernel.org (Postfix) with ESMTP id 56EEEC6FA8B
> for ;
> Wed, 14 Sep 2022 14:34:04 + (UTC)
> Received: (majord...@vger.kernel.org) by vger.kernel.org via listexpand
> id S230118AbiINOeC (ORCPT
> );
> Wed, 14 Sep 2022 10:34:02 -0400
> Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57410 "EHLO
> lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
> with ESMTP id S230133AbiINOeA (ORCPT
> ); Wed, 14 Sep 2022 10:34:00 -0400
> Received: from baptiste.telenet-ops.be (baptiste.telenet-ops.be
> [IPv6:2a02:1800:120:4::f00:13])
> by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC42B7C301
> for ;
> Wed, 14 Sep 2022 07:33:57 -0700 (PDT)
> Received: from ramsan.of.borg ([IPv6:2a02:1810:ac12:ed50:e925:8cbe:2e99:b03b])
> by baptiste.telenet-ops.be with bizsmtp
> id KqZi2800s3vs4GX01qZiPV; Wed, 14 Sep 2022 16:33:55 +0200
> Received: from rox.of.borg ([192.168.97.57])
> by ramsan.of.borg with esmtps (TLS1.3) tls
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> (Exim 4.93)
> (envelope-from )
> id 1oYTSP-005B5L-Rc; Wed, 14 Sep 2022 16:33:41 +0200
> Received: from geert by rox.of.borg with local (Exim 4.93)
> (envelope-from )
> id 1oYTS7-000zXm-2p; Wed, 14 Sep 2022 16:33:23 +0200
> From: Geert Uytterhoeven
> To: Russell King ,
> Rob Herring ,
> Krzysztof Kozlowski ,
> Tony Lindgren ,
> Andrzej Hajda ,
> Neil Armstrong ,
> Robert Foss ,
> Laurent Pinchart ,
> Jonas Karlman ,
> Jernej Skrabec ,
> David Airlie ,
> Daniel Vetter ,
> =?UTF-8?q?Beno=C3=AEt=20Cousson?= ,
> Magnus Damm ,
>
Re: [PATCH v5 1/9] dt-bindings: usb: Add Type-C switch binding
Hi folks,
On Fri, Sep 2, 2022 at 12:41 AM Prashant Malani wrote:
>
> Hi Rob,
>
> On Jul 12 11:45, Rob Herring wrote:
> >
> > That's not the right interpretation. There should not be some Type-C
> > specific child mux/switch node because the device has no such h/w within
> > it. Assuming all the possibilities Stephen outlined are valid, it's
> > clear this lane selection has nothing to do with Type-C. It does have an
> > output port for its DP output already and using that to describe the
> > connection to DP connector(s) and/or Type-C connector(s) should be
> > handled.
> > Rob
>
> Below I've listed the proposal binding (for the Type-C connector) along
> with 2 sample hardware diagrams and corresponding DT.
Any thoughts about this proposal?
>
> The updated binding in usb-c-connector would be as follows:
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index ae515651fc6b..a043b09cb8ec 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -183,6 +183,30 @@ properties:
>port@1:
> $ref: /schemas/graph.yaml#/properties/port
> description: Super Speed (SS), present in SS capable connectors.
> +properties:
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> +patternProperties:
> + "^endpoint@[0-1]$":
> +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> +description:
> + Endpoints for the two SS lanes. endpoint@0 refers to SSTRX1
> (A2,A3,B10,B11)
> + and endpoint@1 refers to SSTRX2 (B2,B3,A10,A11).
> +additionalProperties: false
> +
> + properties:
> +reg:
> + maxItems: 1
> +
> +remote-endpoint: true
> +
> + required:
> +- reg
> +- remote-endpoint
>
>port@2:
> $ref: /schemas/graph.yaml#/properties/port
>
> Here are 2 examples of how that would look on some existing hardware:
>
> Example 1. 2 usb-c-connectors connecting to 1 drm bridge / DP switch:
>
> Here is the diagram we are using on the MTK platform:
>
> SOC
> +-+
> C0
> | |+--+ 2 lane
> ++
> | || +-/-+
> SSTRX1 |
> | || | |
> |
> |MIPI DPI || | 2 lane |
> |
> | ++ ANX 7625 +---/-+++
> SSTRX2 |
> | || | ||
> ++
> | |+--+ ||
> +-+ ||
> | |+--+ 2 lane ||
> C1
> | || +/C+
> ++
> |USB3 HC | 2 lane | | | |
> SSTRX1 |
> | +-/--+ USB3 HUB | +-+
> |
> | (host controller) || | 2 lane |
> |
> | || +-/-+
> SSTRX2 |
> +-+| | |
> |
>+--+
> ++
>
> Some platforms use it6505, so that can be swapped in for anx7625
> without any change to the rest of the hardware diagram.
>
> From the above, we can see that it is helpful to describe the
> Type-C SS lines as 2 endpoints:
> - 1 for SSTX1+SSRX1 (A2,A3 + B10,B11)
> - 1 for SSTX2+SSRX2 (B2,B3 + A10, A11)
>
> A device tree for this would look as follows:
>
> // Type-C port driver
> ec {
> ...
> cros_ec_typec {
> ...
> usb-c0 {
> compatible = "usb-c-connector";
> ports {
> hs : port@0 {
> ...
> };
> ss: port@1 {
> reg = <1>;
> c0_sstrx1: endpoint@0 {
> reg = <0>;
> remote-endpoint = <_out0>;
> };
> c0_sstrx2: endpoint@0 {
> reg = <0>;
> remote-endpoint = <_out0>;
> };
> };
> sbu : port@2 {
> ...
> };
> };
> };
> usb-c1 {
>
[PATCH v5 11/11] drm: bridge: samsung-dsim: Add i.MX8MM support
Samsung MIPI DSIM master can also be found in i.MX8MM SoC.
Add compatible and associated driver_data for it.
v5:
* [mszyprow] rebased and adjusted to the new driver initialization
* drop quirk
v4:
* none
v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk
v2:
* collect Laurent r-b
v1:
* none
Reviewed-by: Laurent Pinchart
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 45 +++
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index a0f5438b7921..62cb42087de3 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -360,6 +360,24 @@ static const unsigned int exynos5433_reg_values[] = {
[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
};
+static const unsigned int imx8mm_dsim_reg_values[] = {
+ [RESET_TYPE] = DSIM_SWRST,
+ [PLL_TIMER] = 500,
+ [STOP_STATE_CNT] = 0xf,
+ [PHYCTRL_ULPS_EXIT] = 0,
+ [PHYCTRL_VREG_LP] = 0,
+ [PHYCTRL_SLEW_UP] = 0,
+ [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
+ [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
+ [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
+ [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x26),
+ [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
+ [PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
+ [PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x08),
+ [PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
+ [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+};
+
static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
.reg_ofs = exynos_reg_ofs,
.plltmr_reg = 0x50,
@@ -421,6 +439,23 @@ static const struct samsung_dsim_driver_data
exynos5422_dsi_driver_data = {
.reg_values = exynos5422_reg_values,
};
+static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
+ .reg_ofs = exynos5433_reg_ofs,
+ .plltmr_reg = 0xa0,
+ .has_clklane_stop = 1,
+ .num_clks = 2,
+ .max_freq = 2100,
+ .wait_for_reset = 0,
+ .num_bits_resol = 12,
+ /**
+* FIXME:
+* Offset value used from downstream drivers/gpu/drm/bridge/sec-dsim.c
+* remove this comment if it is true else update the logic.
+*/
+ .pll_p_offset = 14,
+ .reg_values = imx8mm_dsim_reg_values,
+};
+
static const struct samsung_dsim_driver_data *
samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
[SAMSUNG_DSIM_TYPE_EXYNOS3250] = _dsi_driver_data,
@@ -428,6 +463,7 @@ samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
[SAMSUNG_DSIM_TYPE_EXYNOS5410] = _dsi_driver_data,
[SAMSUNG_DSIM_TYPE_EXYNOS5422] = _dsi_driver_data,
[SAMSUNG_DSIM_TYPE_EXYNOS5433] = _dsi_driver_data,
+ [SAMSUNG_DSIM_TYPE_IMX8MM] = _dsi_driver_data,
};
static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1772,7 +1808,16 @@ const struct dev_pm_ops samsung_dsim_pm_ops = {
};
EXPORT_SYMBOL_GPL(samsung_dsim_pm_ops);
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
+ .hw_type = SAMSUNG_DSIM_TYPE_IMX8MM,
+ .host_ops = _dsim_generic_host_ops,
+};
+
static const struct of_device_id samsung_dsim_of_match[] = {
+ {
+ .compatible = "fsl,imx8mm-mipi-dsim",
+ .data = _dsim_imx8mm_pdata,
+ },
{ /* sentinel. */ }
};
MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
--
2.25.1
[PATCH v5 10/11] dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support
Samsung MIPI DSIM bridge can also be found in i.MX8MM SoC. Add dt-bingings for it. v5, v4: * none v3: * collect Rob Acked-by v2: * updated comments v1: * new patch Acked-by: Rob Herring Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt index be377786e8cd..8efcf4728e0b 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt @@ -7,6 +7,7 @@ Required properties: "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */ "samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */ "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */ + "fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini SoCs */ - reg: physical base address and length of the registers set for the device - interrupts: should contain DSI interrupt - clocks: list of clock specifiers, must contain an entry for each required -- 2.25.1
[PATCH v5 09/11] drm: bridge: samsung-dsim: Add input_bus_flags
eLCDIF is expecting to have input_bus_flags as DE_LOW in order to
set active low during valid data transfer on each horizontal line.
Add DE_LOW flag via drm bridge timings.
v5:
* rebased based on updated bridge changes
v4, v3, v2, v1:
* none
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 527fef6f1ff6..a0f5438b7921 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1585,6 +1585,10 @@ static const struct samsung_dsim_host_ops
samsung_dsim_generic_host_ops = {
.unregister_host = samsung_dsim_unregister_host,
};
+static const struct drm_bridge_timings samsung_dsim_bridge_timings = {
+ .input_bus_flags = DRM_BUS_FLAG_DE_LOW,
+};
+
int samsung_dsim_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -1665,6 +1669,7 @@ int samsung_dsim_probe(struct platform_device *pdev)
dsi->bridge.funcs = _dsim_bridge_funcs;
dsi->bridge.of_node = dev->of_node;
+ dsi->bridge.timings = _dsim_bridge_timings;
dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
--
2.25.1
[PATCH v5 04/11] drm: bridge: samsung-dsim: Mark PHY as optional
In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.
So, mark the phy get as optional.
v5, v4, v3, v2:
* none
v1:
* new patch
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 2e79fbfe2a7d..eac2dc2f24ba 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1568,7 +1568,7 @@ int samsung_dsim_probe(struct platform_device *pdev)
if (IS_ERR(dsi->reg_base))
return PTR_ERR(dsi->reg_base);
- dsi->phy = devm_phy_get(dev, "dsim");
+ dsi->phy = devm_phy_optional_get(dev, "dsim");
if (IS_ERR(dsi->phy)) {
dev_info(dev, "failed to get dsim phy\n");
return PTR_ERR(dsi->phy);
--
2.25.1
[PATCH v5 07/11] drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset
Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.
However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.
The offset 13 is not working for i.MX8M Mini SoCs but the downstream
NXP sec-dsim.c driver is using offset 14 for i.MX8M Mini SoC platforms
[1] [2].
PMS_P value set in sec_mipi_dsim_check_pll_out using PLLCTRL_SET_P()
with offset 13 and then an additional offset of one bit added in
sec_mipi_dsim_config_pll via PLLCTRL_SET_PMS().
Not sure whether it is reference manual documentation or something else
but this patch trusts the downstream code and handle PLL_P offset via
platform driver data so-that imx8mm driver data shall use pll_p_offset
to 14.
[1]
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n210
[2]
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n211
v5:
* updated clear commit message
v4, v3, v2:
* none
v1:
* updated commit message
* add downstream driver link
Signed-off-by: Frieder Schrempf
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 10 --
include/drm/bridge/samsung-dsim.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 8abf89326424..60f22c506c0f 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -168,7 +168,7 @@
/* DSIM_PLLCTRL */
#define DSIM_FREQ_BAND(x) ((x) << 24)
#define DSIM_PLL_EN(1 << 23)
-#define DSIM_PLL_P(x) ((x) << 13)
+#define DSIM_PLL_P(x, offset) ((x) << (offset))
#define DSIM_PLL_M(x) ((x) << 4)
#define DSIM_PLL_S(x) ((x) << 1)
@@ -368,6 +368,7 @@ static const struct samsung_dsim_driver_data
exynos3_dsi_driver_data = {
.max_freq = 1000,
.wait_for_reset = 1,
.num_bits_resol = 11,
+ .pll_p_offset = 13,
.reg_values = reg_values,
};
@@ -380,6 +381,7 @@ static const struct samsung_dsim_driver_data
exynos4_dsi_driver_data = {
.max_freq = 1000,
.wait_for_reset = 1,
.num_bits_resol = 11,
+ .pll_p_offset = 13,
.reg_values = reg_values,
};
@@ -390,6 +392,7 @@ static const struct samsung_dsim_driver_data
exynos5_dsi_driver_data = {
.max_freq = 1000,
.wait_for_reset = 1,
.num_bits_resol = 11,
+ .pll_p_offset = 13,
.reg_values = reg_values,
};
@@ -401,6 +404,7 @@ static const struct samsung_dsim_driver_data
exynos5433_dsi_driver_data = {
.max_freq = 1500,
.wait_for_reset = 0,
.num_bits_resol = 12,
+ .pll_p_offset = 13,
.reg_values = exynos5433_reg_values,
};
@@ -412,6 +416,7 @@ static const struct samsung_dsim_driver_data
exynos5422_dsi_driver_data = {
.max_freq = 1500,
.wait_for_reset = 1,
.num_bits_resol = 12,
+ .pll_p_offset = 13,
.reg_values = exynos5422_reg_values,
};
@@ -543,7 +548,8 @@ static unsigned long samsung_dsim_set_pll(struct
samsung_dsim *dsi,
writel(driver_data->reg_values[PLL_TIMER],
dsi->reg_base + driver_data->plltmr_reg);
- reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+ reg = DSIM_PLL_EN | DSIM_PLL_P(p, driver_data->pll_p_offset) |
+ DSIM_PLL_M(m) | DSIM_PLL_S(s);
if (driver_data->has_freqband) {
static const unsigned long freq_bands[] = {
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index 0c5a905f3de7..df3d030daec6 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -53,6 +53,7 @@ struct samsung_dsim_driver_data {
unsigned int max_freq;
unsigned int wait_for_reset;
unsigned int num_bits_resol;
+ unsigned int pll_p_offset;
const unsigned int *reg_values;
};
--
2.25.1
[PATCH v5 08/11] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts
Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
default RGB888_1X24 bus format on DSI-end.
This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component closer to pipeline
components.
v5, v4:
* none
v3:
* include media-bus-format.h
v2:
* none
v1:
* new patch
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 60f22c506c0f..527fef6f1ff6 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1321,6 +1322,32 @@ static void samsung_dsim_atomic_post_disable(struct
drm_bridge *bridge,
pm_runtime_put_sync(dsi->dev);
}
+#define MAX_INPUT_SEL_FORMATS 1
+
+static u32 *
+samsung_dsim_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ /* This is the DSI-end bus format */
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
struct drm_bridge_state *bridge_state,
struct drm_crtc_state *crtc_state,
@@ -1368,6 +1395,7 @@ static const struct drm_bridge_funcs
samsung_dsim_bridge_funcs = {
.atomic_duplicate_state =
drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state =
drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_get_input_bus_fmts =
samsung_dsim_atomic_get_input_bus_fmts,
.atomic_check = samsung_dsim_atomic_check,
.atomic_pre_enable = samsung_dsim_atomic_pre_enable,
.atomic_enable = samsung_dsim_atomic_enable,
--
2.25.1
[PATCH v5 05/11] drm: bridge: samsung-dsim: Handle proper DSI host initialization
DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.
Host transfer() is usually triggered for downstream DSI panels or
bridges and I2C-configured-DSI bridges miss these host initialization
as these downstream bridges use bridge operations hooks like pre_enable,
and enable in order to initialize or set up the host.
This patch is trying to handle the host init handler to satisfy all
downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
flag to ensure that host init is also done on first cmd transfer, this
helps existing DSI panels work on exynos platform (form Marek
Szyprowski).
v5:
* none
v4:
* update init handling to ensure host init done on first cmd transfer
v3:
* none
v2:
* check initialized state in samsung_dsim_init
v1:
* keep DSI init in host transfer
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 25 +
include/drm/bridge/samsung-dsim.h | 5 +++--
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index eac2dc2f24ba..6d524338d4ff 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
samsung_dsim *dsi)
disable_irq(dsi->irq);
}
-static int samsung_dsim_init(struct samsung_dsim *dsi)
+static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int flag)
{
const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+ if (dsi->state & flag)
+ return 0;
+
samsung_dsim_reset(dsi);
- samsung_dsim_enable_irq(dsi);
+
+ if (!(dsi->state & DSIM_STATE_INITIALIZED))
+ samsung_dsim_enable_irq(dsi);
if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
@@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
samsung_dsim_set_phy_ctrl(dsi);
samsung_dsim_init_link(dsi);
+ dsi->state |= flag;
+
return 0;
}
@@ -1269,6 +1276,10 @@ static void samsung_dsim_atomic_pre_enable(struct
drm_bridge *bridge,
}
dsi->state |= DSIM_STATE_ENABLED;
+
+ ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
+ if (ret)
+ return;
}
static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
@@ -1442,12 +1453,9 @@ static ssize_t samsung_dsim_host_transfer(struct
mipi_dsi_host *host,
if (!(dsi->state & DSIM_STATE_ENABLED))
return -EINVAL;
- if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
- ret = samsung_dsim_init(dsi);
- if (ret)
- return ret;
- dsi->state |= DSIM_STATE_INITIALIZED;
- }
+ ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
+ if (ret)
+ return ret;
ret = mipi_dsi_create_packet(, msg);
if (ret < 0)
@@ -1637,6 +1645,7 @@ static int __maybe_unused samsung_dsim_suspend(struct
device *dev)
if (dsi->state & DSIM_STATE_INITIALIZED) {
dsi->state &= ~DSIM_STATE_INITIALIZED;
+ dsi->state &= ~DSIM_STATE_REINITIALIZED;
samsung_dsim_disable_clock(dsi);
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index 478f0291fb94..57b27d75369e 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -17,8 +17,9 @@ struct samsung_dsim;
#define DSIM_STATE_ENABLED BIT(0)
#define DSIM_STATE_INITIALIZED BIT(1)
-#define DSIM_STATE_CMD_LPM BIT(2)
-#define DSIM_STATE_VIDOUT_AVAILABLEBIT(3)
+#define DSIM_STATE_REINITIALIZED BIT(2)
+#define DSIM_STATE_CMD_LPM BIT(3)
+#define DSIM_STATE_VIDOUT_AVAILABLEBIT(4)
enum samsung_dsim_type {
SAMSUNG_DSIM_TYPE_EXYNOS3250,
--
2.25.1
[PATCH v5 06/11] drm: bridge: samsung-dsim: Add atomic_check
Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.
At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work properly.
On the other hand the i.MX 8M Mini Applications Processor Reference Manual,
Rev. 3, 11/2020 says.
"13.6.3.5.2 RGB interface
Vsync, Hsync, and VDEN are active high signals."
No clear evidence about whether it can be documentation issues or
something, so added a comment FIXME for this and updated the active low
sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.
v5:
* rebase based new bridge changes [mszyprow]
* remove DSIM_QUIRK_FIXUP_SYNC_POL
* add hw_type check for sync polarities change.
v4:
* none
v3:
* add DSIM_QUIRK_FIXUP_SYNC_POL to handle mode_flasg fixup
v2:
* none
v1:
* fix mode flags in atomic_check instead of mode_fixup
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 26 ++
include/drm/bridge/samsung-dsim.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 6d524338d4ff..8abf89326424 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1315,6 +1315,31 @@ static void samsung_dsim_atomic_post_disable(struct
drm_bridge *bridge,
pm_runtime_put_sync(dsi->dev);
}
+static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+ struct drm_display_mode *adjusted_mode = _state->adjusted_mode;
+
+ if (dsi->plat_data->hw_type & SAMSUNG_DSIM_TYPE_IMX8MM) {
+ /**
+* FIXME:
+* At least LCDIF + DSIM needs active low sync,
+* but i.MX 8M Mini Applications Processor Reference Manual,
+* Rev. 3, 11/2020 says
+*
+* 13.6.3.5.2 RGB interface
+* Vsync, Hsync, and VDEN are active high signals.
+*/
+ adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC |
DRM_MODE_FLAG_NVSYNC);
+ adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
+ }
+
+ return 0;
+}
+
static void samsung_dsim_mode_set(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
const struct drm_display_mode *adjusted_mode)
@@ -1337,6 +1362,7 @@ static const struct drm_bridge_funcs
samsung_dsim_bridge_funcs = {
.atomic_duplicate_state =
drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state =
drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_check = samsung_dsim_atomic_check,
.atomic_pre_enable = samsung_dsim_atomic_pre_enable,
.atomic_enable = samsung_dsim_atomic_enable,
.atomic_disable = samsung_dsim_atomic_disable,
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index 57b27d75369e..0c5a905f3de7 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -27,6 +27,7 @@ enum samsung_dsim_type {
SAMSUNG_DSIM_TYPE_EXYNOS5410,
SAMSUNG_DSIM_TYPE_EXYNOS5422,
SAMSUNG_DSIM_TYPE_EXYNOS5433,
+ SAMSUNG_DSIM_TYPE_IMX8MM,
SAMSUNG_DSIM_TYPE_COUNT,
};
--
2.25.1
[PATCH v5 02/11] drm: bridge: Add Samsung DSIM bridge driver
Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.
This patch is trying to differentiate platform-specific and bridge driver
code by maintaining exynos platform glue code in exynos_drm_dsi.c driver
and common bridge driver code in samsung-dsim.c providing that the new
platform-specific glue should be supported in the bridge driver, unlike
exynos platform drm drivers.
- Add samsung_dsim_plat_data for keeping platform-specific attributes like
host_ops, irq_ops, and hw_type.
- Initialize the plat_data hooks for exynos platform in exynos_drm_dsi.c.
- samsung_dsim_probe is the common probe call across exynos_drm_dsi.c and
samsung-dsim.c.
- plat_data hooks like host_ops and irq_ops are invoked during the
respective bridge call chains.
v5:
* [mszyprow] reworked driver initialization using the same approach as in
drivers/gpu/drm/{exynos/exynos_dp.c, bridge/analogix/analogix_dp_core.c},
removed weak functions, moved exynos_dsi_driver back to exynos_drm_dsi.c
and restored integration with exynos_drm custom initialization.
* updated the commit message [Jagan]
v4:
* include Inki Dae in MAINTAINERS
* remove dsi_driver probe in exynos_drm_drv to support multi-arch build
v3:
* restore gpio related fixes
* restore proper bridge chain
* rework initialization issue
* fix header includes in proper way
v2:
* fixed exynos dsi driver conversion (Marek Szyprowski)
* updated commit message
* updated MAINTAINERS file
v1:
* don't maintain component_ops in bridge driver
* don't maintain platform glue code in bridge driver
* add platform-specific glue code and make a common bridge
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
MAINTAINERS |9 +
drivers/gpu/drm/bridge/Kconfig | 12 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/samsung-dsim.c | 1687 ++
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1767 ++-
include/drm/bridge/samsung-dsim.h | 112 ++
7 files changed, 1935 insertions(+), 1654 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
create mode 100644 include/drm/bridge/samsung-dsim.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c6a5d0fac39..db341eb0f4bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6634,6 +6634,15 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml
F: drivers/gpu/drm/panel/panel-samsung-db7430.c
+DRM DRIVER FOR SAMSUNG MIPI DSIM BRIDGE
+M: Jagan Teki
+M: Marek Szyprowski
+M: Inki Dae
S: Maintained
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 57946d80b02d..8e85dac9f53e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -231,6 +231,18 @@ config DRM_PARADE_PS8640
The PS8640 is a high-performance and low-power
MIPI DSI to eDP converter
+config DRM_SAMSUNG_DSIM
+ tristate "Samsung MIPI DSIM bridge driver"
+ depends on COMMON_CLK
+ depends on OF && HAS_IOMEM
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL_BRIDGE
+ help
+ The Samsung MIPI DSIM bridge controller driver.
+ This MIPI DSIM bridge can be found it on Exynos SoCs and
+ NXP's i.MX8M Mini/Nano.
+
config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 1884803c6860..dae843723991 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
+obj-$(CONFIG_DRM_SAMSUNG_DSIM) += samsung-dsim.o
obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
new file mode 100644
index ..ccaf87e19e81
--- /dev/null
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -0,0 +1,1687 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Samsung MIPI DSIM bridge driver.
+ *
+ * Copyright (C) 2021 Amarula Solutions(India)
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Author: Jagan Teki
+ *
+ * Based on exynos_drm_dsi from
+ * Tomasz Figa
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+/* returns true iff both
[PATCH v5 03/11] drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices
The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.
The OF-graph interface represents the child devices via
remote and associated endpoint numbers like
dsi {
compatible = "fsl,imx8mm-mipi-dsim";
ports {
port@0 {
reg = <0>;
dsi_in_lcdif: endpoint@0 {
reg = <0>;
remote-endpoint = <_out_dsi>;
};
};
port@1 {
reg = <1>;
dsi_out_bridge: endpoint {
remote-endpoint = <_in_dsi>;
};
};
};
The child node interface represents the child devices via
conventional child nodes on given DSI parent like
dsi {
compatible = "samsung,exynos5433-mipi-dsi";
ports {
port@0 {
reg = <0>;
dsi_to_mic: endpoint {
remote-endpoint = <_to_dsi>;
};
};
};
panel@0 {
reg = <0>;
};
};
As Samsung DSIM bridge is common DSI IP across all Exynos DSI
and NXP i.MX8M host controllers, this patch adds support to
lookup the child devices whether its bindings on the associated
host represent OF-graph or child node interfaces.
v5, v4, v3:
* none
v2:
* new patch
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 38 +--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index ccaf87e19e81..2e79fbfe2a7d 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1340,18 +1340,52 @@ static int samsung_dsim_host_attach(struct
mipi_dsi_host *host,
struct samsung_dsim *dsi = host_to_dsi(host);
const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
struct device *dev = dsi->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *remote;
struct drm_panel *panel;
int ret;
- panel = of_drm_find_panel(device->dev.of_node);
+ /**
+* Devices can also be child nodes when we also control that device
+* through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
+*
+* Lookup for a child node of the given parent that isn't either port
+* or ports.
+*/
+ for_each_available_child_of_node(np, remote) {
+ if (of_node_name_eq(remote, "port") ||
+ of_node_name_eq(remote, "ports"))
+ continue;
+
+ goto of_find_panel_or_bridge;
+ }
+
+ /*
+* of_graph_get_remote_node() produces a noisy error message if port
+* node isn't found and the absence of the port is a legit case here,
+* so at first we silently check whether graph presents in the
+* device-tree node.
+*/
+ if (!of_graph_is_present(np))
+ return -ENODEV;
+
+ remote = of_graph_get_remote_node(np, 1, 0);
+
+of_find_panel_or_bridge:
+ if (!remote)
+ return -ENODEV;
+
+ panel = of_drm_find_panel(remote);
if (!IS_ERR(panel)) {
dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
} else {
- dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
+ dsi->out_bridge = of_drm_find_bridge(remote);
if (!dsi->out_bridge)
dsi->out_bridge = ERR_PTR(-EINVAL);
}
+ of_node_put(remote);
+
if (IS_ERR(dsi->out_bridge)) {
ret = PTR_ERR(dsi->out_bridge);
DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
--
2.25.1
[PATCH v5 01/11] drm: exynos: dsi: Restore proper bridge chain order
From: Marek Szyprowski
Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.
This establishes a proper bridge chain while attaching downstream
bridges.
v5:
* exclude the NULL replacement in exynos_dsi_host_attach
v4:
* none
v3:
* new patch
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index ec673223d6b7..f4e3d2518ad0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1428,7 +1428,8 @@ static int exynos_dsi_attach(struct drm_bridge *bridge,
{
struct exynos_dsi *dsi = bridge_to_dsi(bridge);
- return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, flags);
+ return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge,
+flags);
}
static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
--
2.25.1
[PATCH v5 00/11] drm: bridge: Add Samsung MIPI DSIM bridge
This series supports common bridge support for Samsung MIPI DSIM which is used in Exynos and i.MX8MM SoC's. Previous v4 can be available here [1], repo on linux-next [2] and Engicam i.Core MX8M Mini SoM boot log [3]. The final bridge supports both the Exynos and i.MX8MM DSI devices. Changes for v3: * bridge changes to support multi-arch * updated and clear commit messages * add hw_type via plat data * removed unneeded quirk * rebased on linux-next Changes for v4: * include Inki Dae in MAINTAINERS * remove dsi_driver probe in exynos_drm_drv to support multi-arch build * update init handling to ensure host init done on first cmd transfer Changes for v3: * fix the mult-arch build * fix dsi host init * updated commit messages Changes for v2: * fix bridge handling * fix dsi host init * correct the commit messages Patch 0001: Restore proper bridge chain in exynos_dsi Patch 0002: Samsung DSIM bridge Patch 0003: PHY optional Patch 0004: OF-graph or Child node lookup Patch 0005: DSI host initialization Patch 0006: atomic check Patch 0007: PMS_P offset via plat data Patch 0008: atomic_get_input_bus_fmts Patch 0009: input_bus_flags Patch 0010: document fsl,imx8mm-mipi-dsim Patch 0011: add i.MX8MM DSIM support [3] https://gist.github.com/openedev/22b2d63b30ade0ba55ab414a2f47aaf0 [2] https://github.com/openedev/kernel/tree/imx8mm-dsi-v5 [1] https://patchwork.kernel.org/project/dri-devel/cover/20220829184031.1863663-1-ja...@amarulasolutions.com/ Any inputs? Jagan. Jagan Teki (10): drm: bridge: Add Samsung DSIM bridge driver drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices drm: bridge: samsung-dsim: Mark PHY as optional drm: bridge: samsung-dsim: Handle proper DSI host initialization drm: bridge: samsung-dsim: Add atomic_check drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts drm: bridge: samsung-dsim: Add input_bus_flags dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support drm: bridge: samsung-dsim: Add i.MX8MM support Marek Szyprowski (1): drm: exynos: dsi: Restore proper bridge chain order .../bindings/display/exynos/exynos_dsim.txt |1 + MAINTAINERS |9 + drivers/gpu/drm/bridge/Kconfig| 12 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/samsung-dsim.c | 1840 + drivers/gpu/drm/exynos/Kconfig|1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1766 +--- include/drm/bridge/samsung-dsim.h | 115 ++ 8 files changed, 2092 insertions(+), 1653 deletions(-) create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c create mode 100644 include/drm/bridge/samsung-dsim.h -- 2.25.1
Re: [PATCH -next 1/6] drm/amd/display: clean up some inconsistent indentings
Applied the series. Thanks, Alex On Wed, Sep 14, 2022 at 9:58 PM Yang Li wrote: > > clean up some inconsistent indentings > > Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2177 > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > .../gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c| 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c > b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c > index 4e3356d12147..8dfe639b6508 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c > @@ -1051,10 +1051,10 @@ static bool CalculatePrefetchSchedule( > bytes_pp = myPipe->BytePerPixelY + myPipe->BytePerPixelC; > /*rev 99*/ > prefetch_bw_pr = dml_min(1, bytes_pp * myPipe->PixelClock / (double) > myPipe->DPPPerPlane); > -max_Tsw = dml_max(PrefetchSourceLinesY, PrefetchSourceLinesC) * LineTime; > + max_Tsw = dml_max(PrefetchSourceLinesY, PrefetchSourceLinesC) * > LineTime; > prefetch_sw_bytes = PrefetchSourceLinesY * swath_width_luma_ub * > myPipe->BytePerPixelY + PrefetchSourceLinesC * swath_width_chroma_ub * > myPipe->BytePerPixelC; > prefetch_bw_oto = dml_max(bytes_pp * myPipe->PixelClock / > myPipe->DPPPerPlane, prefetch_sw_bytes / (dml_max(PrefetchSourceLinesY, > PrefetchSourceLinesC) * LineTime)); > -prefetch_bw_oto = dml_max(prefetch_bw_pr, prefetch_sw_bytes / max_Tsw); > + prefetch_bw_oto = dml_max(prefetch_bw_pr, prefetch_sw_bytes / > max_Tsw); > > min_Lsw = dml_max(1, dml_max(PrefetchSourceLinesY, > PrefetchSourceLinesC) / max_vratio_pre); > Lsw_oto = dml_ceil(4 * dml_max(prefetch_sw_bytes / prefetch_bw_oto / > LineTime, min_Lsw), 1) / 4; > -- > 2.20.1.7.g153144c >
[PATCH v2 1/3] drm/i915: Add missing mask when reading GEN12_DSMBASE
DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
of the base address of stolen. For the supported platforms bits 0-19 are
zero but that may not be true in future. Add the missing mask.
v2: Use REG_GENMASK64()
Acked-by: Aravind Iddamsetty
Reviewed-by: Caz Yokoyama
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..3665f9b035bb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -814,7 +814,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
return ERR_PTR(-ENXIO);
/* Use DSM base address instead for stolen memory */
- dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
+ dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & GEN12_BDSM_MASK;
if (IS_DG1(uncore->i915)) {
lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
if (WARN_ON(lmem_size < dsm_base))
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a9bd829fc7e..9584a50ed612 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7953,6 +7953,7 @@ enum skl_power_gate {
#define GEN12_GSMBASE _MMIO(0x108100)
#define GEN12_DSMBASE _MMIO(0x1080C0)
+#define GEN12_BDSM_MASK REG_GENMASK64(63, 20)
#define XEHP_CLOCK_GATE_DIS_MMIO(0x101014)
#define SGSI_SIDECLK_DIS REG_BIT(17)
--
b4 0.10.0-dev-bbe61
[PATCH v2 3/3] drm/i915/dgfx: Make failure to setup stolen non-fatal
There is no reason to consider the setup of Data Stolen Memory fatal on
dgfx and non-fatal on integrated. Move the debug and error propagation
around so both have the same behavior: non-fatal. Before this change,
loading i915 on a system with TGL + DG2 would result in just TGL
succeeding the initialization (without stolen).
Now loading i915 on the same system with an injected failure in
i915_gem_init_stolen():
$ dmesg | grep stolen
i915 :00:02.0: [drm] Injected failure, disabling use of stolen
memory
i915 :00:02.0: [drm:init_stolen_smem [i915]] Skip stolen region:
failed to setup
i915 :03:00.0: [drm] Injected failure, disabling use of stolen
memory
i915 :03:00.0: [drm:init_stolen_lmem [i915]] Skip stolen region:
failed to setup
Both GPUs are still available:
$ sudo build/tools/lsgpu
card1Intel Dg2 (Gen12)
drm:/dev/dri/card1
└─renderD129
drm:/dev/dri/renderD129
card0Intel Tigerlake (Gen12)
drm:/dev/dri/card0
└─renderD128
drm:/dev/dri/renderD128
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 6edf4e374f54..c5a4035c99cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -494,26 +494,26 @@ static int i915_gem_init_stolen(struct
intel_memory_region *mem)
drm_notice(>drm,
"%s, disabling use of stolen memory\n",
"iGVT-g active");
- return 0;
+ return -ENOSPC;
}
if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
drm_notice(>drm,
"%s, disabling use of stolen memory\n",
"DMAR active");
- return 0;
+ return -ENOSPC;
}
if (adjust_stolen(i915, >region))
- return 0;
+ return -ENOSPC;
if (request_smem_stolen(i915, >region))
- return 0;
+ return -ENOSPC;
i915->dsm = mem->region;
if (init_reserved_stolen(i915))
- return 0;
+ return -ENOSPC;
/* Exclude the reserved region from driver use */
mem->region.end = i915->dsm_reserved.start - 1;
@@ -527,7 +527,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
(u64)i915->stolen_usable_size >> 10);
if (i915->stolen_usable_size == 0)
- return 0;
+ return -ENOSPC;
/* Basic memrange allocator for stolen space. */
drm_mm_init(>mm.stolen, 0, i915->stolen_usable_size);
@@ -765,11 +765,17 @@ i915_gem_object_create_stolen(struct drm_i915_private
*i915,
static int init_stolen_smem(struct intel_memory_region *mem)
{
+ int err;
+
/*
* Initialise stolen early so that we may reserve preallocated
* objects for the BIOS to KMS transition.
*/
- return i915_gem_init_stolen(mem);
+ err = i915_gem_init_stolen(mem);
+ if (err)
+ drm_dbg(>i915->drm, "Skip stolen region: failed to
setup\n");
+
+ return 0;
}
static int release_stolen_smem(struct intel_memory_region *mem)
@@ -786,21 +792,25 @@ static const struct intel_memory_region_ops
i915_region_stolen_smem_ops = {
static int init_stolen_lmem(struct intel_memory_region *mem)
{
+ struct drm_i915_private *i915 = mem->i915;
int err;
if (GEM_WARN_ON(resource_size(>region) == 0))
- return -ENODEV;
+ return 0;
err = i915_gem_init_stolen(mem);
- if (err)
- return err;
+ if (err) {
+ drm_dbg(>i915->drm, "Skip stolen region: failed to
setup\n");
+ return 0;
+ }
- if (mem->io_size && !io_mapping_init_wc(>iomap,
- mem->io_start,
- mem->io_size)) {
- err = -EIO;
+ if (mem->io_size &&
+ !io_mapping_init_wc(>iomap, mem->io_start, mem->io_size))
goto err_cleanup;
- }
+
+ drm_dbg(>drm, "Stolen Local memory IO start: %pa\n",
+ >io_start);
+ drm_dbg(>drm, "Stolen Local DSM base: %pa\n", >region.start);
return 0;
@@ -874,16 +884,6 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
if (IS_ERR(mem))
return mem;
- /*
-* TODO: consider creating common helper to just print all the
-* interesting stuff from intel_memory_region, which we can use for all
-* our probed regions.
-*/
-
- drm_dbg(>drm, "Stolen Local memory IO start:
[PATCH v2 2/3] drm/i915: Split i915_gem_init_stolen()
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region.
Main goal is to split the reserved part within the stolen, also known as
WOPCM, as its calculation changes often per platform and is a big source
of confusion when handling stolen memory.
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 3665f9b035bb..6edf4e374f54 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,22 +77,26 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(>mm.stolen_lock);
}
-static int i915_adjust_stolen(struct drm_i915_private *i915,
- struct resource *dsm)
+static bool valid_stolen_size(struct resource *dsm)
+{
+ return dsm->start != 0 && dsm->end > dsm->start;
+}
+
+static int adjust_stolen(struct drm_i915_private *i915,
+struct resource *dsm)
{
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
- struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (!valid_stolen_size(dsm))
return -EINVAL;
/*
+* Make sure we don't clobber the GTT if it's within stolen memory
+*
* TODO: We have yet too encounter the case where the GTT wasn't at the
* end of stolen. With that assumption we could simplify this.
*/
-
- /* Make sure we don't clobber the GTT if it's within stolen memory */
if (GRAPHICS_VER(i915) <= 4 &&
!IS_G33(i915) && !IS_PINEVIEW(i915) && !IS_G4X(i915)) {
struct resource stolen[2] = {*dsm, *dsm};
@@ -131,10 +135,20 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ if (!valid_stolen_size(dsm))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int request_smem_stolen(struct drm_i915_private *i915,
+ struct resource *dsm)
+{
+ struct resource *r;
+
/*
-* With stolen lmem, we don't need to check if the address range
-* overlaps with the non-stolen system memory range, since lmem is local
-* to the gpu.
+* With stolen lmem, we don't need to request system memory for the
+* address range since it's local to the gpu.
*/
if (HAS_LMEM(i915))
return 0;
@@ -392,39 +406,22 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
}
}
-static int i915_gem_init_stolen(struct intel_memory_region *mem)
+/*
+ * Initialize i915->dsm_reserved to contain the reserved space within the Data
+ * Stolen Memory. This is a range on the top of DSM that is reserved, not to
+ * be used by driver, so must be excluded from the region passed to the
+ * allocator later. In the spec this is also called as WOPCM.
+ *
+ * Our expectation is that the reserved space is at the top of the stolen
+ * region, as it has been the case for every platform, and *never* at the
+ * bottom, so the calculation here can be simplified.
+ */
+static int init_reserved_stolen(struct drm_i915_private *i915)
{
- struct drm_i915_private *i915 = mem->i915;
struct intel_uncore *uncore = >uncore;
resource_size_t reserved_base, stolen_top;
- resource_size_t reserved_total, reserved_size;
-
- mutex_init(>mm.stolen_lock);
-
- if (intel_vgpu_active(i915)) {
- drm_notice(>drm,
- "%s, disabling use of stolen memory\n",
- "iGVT-g active");
- return 0;
- }
-
- if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
- drm_notice(>drm,
- "%s, disabling use of stolen memory\n",
- "DMAR active");
- return 0;
- }
-
- if (resource_size(>region) == 0)
- return 0;
-
- i915->dsm = mem->region;
-
- if (i915_adjust_stolen(i915, >dsm))
- return 0;
-
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
+ resource_size_t reserved_size;
+ int ret = 0;
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -455,17 +452,16 @@ static int i915_gem_init_stolen(struct
intel_memory_region *mem)
_base, _size);
}
- /*
-* Our expectation is that the reserved space is at the top of the
-* stolen region and *never* at the bottom. If we see !reserved_base,
-* it likely means we failed to read the registers correctly.
-*/
+ /* No reserved stolen */
+ if (reserved_base == stolen_top)
+
[PATCH v2 0/3] drm/i915: Improvements to stolen memory setup
Better split, document, and make the code paths for integrated and discrete more similar. v2: - s/GENMASK/REG_GENMASK64/ where appropriate - Fix comment Signed-off-by: Lucas De Marchi --- Lucas De Marchi (3): drm/i915: Add missing mask when reading GEN12_DSMBASE drm/i915: Split i915_gem_init_stolen() drm/i915/dgfx: Make failure to setup stolen non-fatal drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 188 + drivers/gpu/drm/i915/i915_reg.h| 1 + 2 files changed, 109 insertions(+), 80 deletions(-) --- base-commit: 13d68eac4fd3384eeb113e183c4abe2e3afdf76c change-id: 20220915-stolen-7aa0e407368f Best regards, -- Lucas De Marchi
Re: [PATCH][next] drm/amdkfd: Fix spelling mistake "detroyed" -> "destroyed"
Applied. Thanks!
On Wed, Sep 14, 2022 at 1:15 PM Colin Ian King wrote:
>
> There is a spelling mistake in a pr_debug message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> index 7522bf2d2f57..c70c026c9a93 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> @@ -898,7 +898,7 @@ static vm_fault_t svm_migrate_to_ram(struct vm_fault *vmf)
> return VM_FAULT_SIGBUS;
> }
> if (!mmget_not_zero(svm_bo->eviction_fence->mm)) {
> - pr_debug("addr 0x%lx of process mm is detroyed\n", addr);
> + pr_debug("addr 0x%lx of process mm is destroyed\n", addr);
> return VM_FAULT_SIGBUS;
> }
>
> --
> 2.37.1
>
Re: [PATCH v2 00/10] drm/msm: probe deferral fixes
Hi Johan, On Wed, Sep 14, 2022 at 1:01 AM Johan Hovold wrote: > > On Tue, Sep 13, 2022 at 03:23:10PM -0500, Steev Klimaszewski wrote: > > Hi Johan, > > > > On 9/13/22 3:53 AM, Johan Hovold wrote: > > > The MSM DRM driver is currently broken in multiple ways with respect to > > > probe deferral. Not only does the driver currently fail to probe again > > > after a late deferral, but due to a related use-after-free bug this also > > > triggers NULL-pointer dereferences. > > > > In some cases, such has for the DP IRQ, the above situation can also be > > > avoided by moving the allocation in question to the platform driver > > > probe (d0) or component bind (between d2 and d3). But as doing so is not > > > a general fix, this can be done later as a cleanup/optimisation. > > > I've tested this on both sc8180x (Lenovo Flex 5G) and sdm850 (Lenovo > > Yoga C630), and both of them show the same issue: > > [ Copied the below from IRC instead as the formatting in your mail was > off. ] > > > [7.449305] platform ae9a000.displayport-controller: Fixing up cyclic > > dependency with ae01000.mdp > > [7.454344] Unable to handle kernel NULL pointer dereference at virtual > > address 0008 > > [7.454406] Mem abort info: > > [7.454423] ESR = 0x9604 > > [7.454446] EC = 0x25: DABT (current EL), IL = 32 bits > > [7.454475] SET = 0, FnV = 0 > > [7.454494] EA = 0, S1PTW = 0 > > [7.454512] FSC = 0x04: level 0 translation fault > > [7.454539] Data abort info: > > [7.454556] ISV = 0, ISS = 0x0004 > > [7.454577] CM = 0, WnR = 0 > > [7.454595] user pgtable: 4k pages, 48-bit VAs, pgdp=000101504000 > > [7.454629] [0008] pgd=, p4d= > > [7.454669] Internal error: Oops: 9604 [#1] PREEMPT SMP > > [7.454700] Modules linked in: i2c_hid_of i2c_hid leds_qcom_lpg > > led_class_multicolor rtc_pm8xxx msm mdt_loader gpu_sched drm_dp_aux_bus > > drm_display_helper drm_kms_helper drm phy_qcom_edp llcc_qcom i2c_qcom_geni > > phy_qcom_qmp_combo phy_qcom_snps_femto_v2 phy_qcom_qmp_ufs > > phy_qcom_qmp_pcie ufs_qcom pwm_bl > > [7.454860] CPU: 2 PID: 76 Comm: kworker/u16:2 Not tainted > > 5.19.0-rc8-next-20220728 #26 > > [7.454902] Hardware name: LENOVO 82AK/LNVNB161216, BIOS EACN43WW(V1.15) > > 09/13/2021 > > [7.454941] Workqueue: events_unbound deferred_probe_work_func > > [7.454982] pstate: 4045 (nZcv daif +PAN -UAO -TCO -DIT -SSBS > > BTYPE=--) > > [7.455020] pc : dp_display_request_irq+0x50/0xdc [msm] > > [7.455145] lr : dp_display_request_irq+0x2c/0xdc [msm] > > [7.455265] sp : 88c1bb30 > > [7.455285] x29: 88c1bb30 x28: x27: > > > > [7.455327] x26: c9c91842 x25: c9c9186ec570 x24: > > 003a > > [7.455368] x23: c9c918811d30 x22: 2a5806baa998 x21: > > 2a5806ba3410 > > [7.455410] x20: 2a5806baa880 x19: 2a5806baa998 x18: > > > > [7.455451] x17: 0038 x16: c9c9164eeb24 x15: > > > > [7.455492] x14: 2a5806bc3004 x13: 2a5806bc3000 x12: > > > > [7.455533] x11: 0040 x10: c9c918493080 x9 : > > c9c918493078 > > [7.455574] x8 : 2a5800681b88 x7 : x6 : > > 2a5806baa880 > > [7.455616] x5 : c9c8ca2de000 x4 : 00080004 x3 : > > > > [7.455656] x2 : c9c8ca296000 x1 : 00a8 x0 : > > > > [7.455698] Call trace: > > [7.455714] dp_display_request_irq+0x50/0xdc [msm] > > [7.455834] dp_display_probe+0xf8/0x4a4 [msm] > > [7.455950] platform_probe+0x6c/0xc4 > > [7.455976] really_probe+0xbc/0x2d4 > > [7.455999] __driver_probe_device+0x78/0xe0 > > [7.456025] driver_probe_device+0x3c/0x13c > > [7.456051] __device_attach_driver+0xb8/0x120 > > [7.456077] bus_for_each_drv+0x78/0xd0 > > [7.456105] __device_attach+0x9c/0x1a0 > > [7.456129] device_initial_probe+0x18/0x2c > > [7.456154] bus_probe_device+0x9c/0xa4 > > [7.456178] deferred_probe_work_func+0x88/0xc0 > > [7.456204] process_one_work+0x1d4/0x330 > > [7.456231] worker_thread+0x70/0x42c > > [7.456255] kthread+0x10c/0x110 > > [7.456278] ret_from_fork+0x10/0x20 > > [7.456306] Code: aa1403e6 f2a00104 f225 f0e2 (f9400400) > > [7.456341] ---[ end trace ]--- > > > This is from the sc8180x, sdm850 is the same call stack, just with > > different addresses. > > > > I do have > > https://lore.kernel.org/all/20220712132258.671263-1-dmitry.barysh...@linaro.org/ > > applied here which makes the 10th patch not apply cleanly. > > Yeah, that is expected. You need to drop Dmitry's series first. Once you > verified that this series works, you can add it back if you want but you > then need to restore the device pointer used
[PATCH 4/4] drm/i915: Make blocking commits lockless
From: Ville Syrjälä
Make blocking commits execute locklessly (just as nonblocking
commits do) by scheduling them onto the workqueues as well.
There will be a later flush_work() done by whoever called
the commit hook to make sure the blocking behaviour of the
ioctl/etc. is preserved.
I also wondered about just dropping the locks straight from the
driver, but I guess whoever called us might still depend on
having the locks so that seems like a terrible idea. Also calling
commit_tail() directly when not holding the locks would then
allow eg. two ioctls to execute full modesets in parallel,
which we don't want as we haven't fully evaluated all modeset
codepaths for concurrency issues. Currently we achieve serial
excution with a combination of an ordered workqueue (for
nonblocking commits) and reliance on the singular connection_mutex
(for blocking commits), and a flush_workqueue() to sync between
the two.
So by always scheduling everything onto the workqueues we
don't have to worry about racing between the lockless direct
commit_tail() calls, and we don't need some kind of new atomic
hook that would do said call for us after dropping the locks.
Also less codepaths in general seems like a beneficial thing.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Rob Clark
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jonas Ådahl
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index cd617046e0ee..18a5f14e7f41 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7771,15 +7771,10 @@ static int intel_atomic_commit(struct drm_device *dev,
INIT_WORK(>base.commit_work, intel_atomic_commit_work);
i915_sw_fence_commit(>commit_ready);
- if (nonblock && state->modeset) {
+ if (state->modeset)
queue_work(dev_priv->display.wq.modeset,
>base.commit_work);
- } else if (nonblock) {
+ else
queue_work(dev_priv->display.wq.flip, >base.commit_work);
- } else {
- if (state->modeset)
- flush_workqueue(dev_priv->display.wq.modeset);
- intel_atomic_commit_tail(state);
- }
return 0;
}
--
2.35.1
[PATCH 1/4] drm/atomic: Treat a nonblocking commit following a blocking commit as blocking commit
From: Ville Syrjälä
Currently a nonblocking commit will actually block if it is
preceded by a blocking commit. It just happens block on the
mutex rather than on the completion. I shall call these as
not-actually-nonblocking commits.
I would like to make blocking commits execute locklessly,
just as nonblocking commits already do. The main benefit
would that parallel TEST_ONLY commits would not get blocked
on the mutexes until the parallel blocking commit is done.
To achieve that without a significant change in behaviour
for the not-actually-nonblocking commits let's treat them
exactly the same as blocking commit, ie. instead of
returning -EBUSY they will just block.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Rob Clark
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jonas Ådahl
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 19 ---
include/drm/drm_atomic.h| 7 +++
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ee5fea48b5cb..bff087674cb5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2109,7 +2109,7 @@ static int stall_checks(struct drm_crtc *crtc, bool
nonblock)
* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones.
*/
- if (!completed && nonblock) {
+ if (!completed && nonblock && commit->nonblock) {
spin_unlock(>commit_lock);
drm_dbg_atomic(crtc->dev,
"[CRTC:%d:%s] busy with a
previous commit\n",
@@ -2152,7 +2152,7 @@ static void release_crtc_commit(struct completion
*completion)
drm_crtc_commit_put(commit);
}
-static void init_commit(struct drm_crtc_commit *commit, struct drm_crtc *crtc)
+static void init_commit(struct drm_crtc_commit *commit, struct drm_crtc *crtc,
bool nonblock)
{
init_completion(>flip_done);
init_completion(>hw_done);
@@ -2160,10 +2160,11 @@ static void init_commit(struct drm_crtc_commit *commit,
struct drm_crtc *crtc)
INIT_LIST_HEAD(>commit_entry);
kref_init(>ref);
commit->crtc = crtc;
+ commit->nonblock = nonblock;
}
static struct drm_crtc_commit *
-crtc_or_fake_commit(struct drm_atomic_state *state, struct drm_crtc *crtc)
+crtc_or_fake_commit(struct drm_atomic_state *state, struct drm_crtc *crtc,
bool nonblock)
{
if (crtc) {
struct drm_crtc_state *new_crtc_state;
@@ -2178,7 +2179,7 @@ crtc_or_fake_commit(struct drm_atomic_state *state,
struct drm_crtc *crtc)
if (!state->fake_commit)
return NULL;
- init_commit(state->fake_commit, NULL);
+ init_commit(state->fake_commit, NULL, nonblock);
}
return state->fake_commit;
@@ -2250,7 +2251,7 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
if (!commit)
return -ENOMEM;
- init_commit(commit, crtc);
+ init_commit(commit, crtc, nonblock);
new_crtc_state->commit = commit;
@@ -2299,6 +2300,7 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
* commit with nonblocking ones.
*/
if (nonblock && old_conn_state->commit &&
+ old_conn_state->commit->nonblock &&
!try_wait_for_completion(_conn_state->commit->flip_done)) {
drm_dbg_atomic(conn->dev,
"[CONNECTOR:%d:%s] busy with a previous
commit\n",
@@ -2308,7 +2310,8 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
}
/* Always track connectors explicitly for e.g. link retraining.
*/
- commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
old_conn_state->crtc);
+ commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
old_conn_state->crtc,
+nonblock);
if (!commit)
return -ENOMEM;
@@ -2321,6 +2324,7 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
* commit with nonblocking ones.
*/
if (nonblock && old_plane_state->commit &&
+ old_plane_state->commit->nonblock &&
!try_wait_for_completion(_plane_state->commit->flip_done)) {
drm_dbg_atomic(plane->dev,
"[PLANE:%d:%s] busy with a previous
commit\n",
@@ -2330,7 +2334,8 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
}
/* Always track planes
[PATCH 2/4] drm/i915: Don't reuse commit_work for the cleanup
From: Ville Syrjälä
Currently we reuse the commit_work for a later cleanup step.
Let's not do that so that atomic ioctl handler won't accidentally
wait for the cleanup work when it really wants to just wait on the
commit_tail() part. We'll just add another work struct for the
cleanup.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Rob Clark
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jonas Ådahl
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dd008ba8afe3..cd617046e0ee 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7422,7 +7422,7 @@ static void intel_cleanup_dsbs(struct intel_atomic_state
*state)
static void intel_atomic_cleanup_work(struct work_struct *work)
{
struct intel_atomic_state *state =
- container_of(work, struct intel_atomic_state, base.commit_work);
+ container_of(work, struct intel_atomic_state, cleanup_work);
struct drm_i915_private *i915 = to_i915(state->base.dev);
intel_cleanup_dsbs(state);
@@ -7643,8 +7643,8 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
* schedule point (cond_resched()) here anyway to keep latencies
* down.
*/
- INIT_WORK(>base.commit_work, intel_atomic_cleanup_work);
- queue_work(system_highpri_wq, >base.commit_work);
+ INIT_WORK(>cleanup_work, intel_atomic_cleanup_work);
+ queue_work(system_highpri_wq, >cleanup_work);
}
static void intel_atomic_commit_work(struct work_struct *work)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 298d00a11f47..971e2b1e1b26 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -655,6 +655,7 @@ struct intel_atomic_state {
struct i915_sw_fence commit_ready;
+ struct work_struct cleanup_work;
struct llist_node freed;
};
--
2.35.1
[PATCH 3/4] drm/atomic: Allow lockless blocking commits
From: Ville Syrjälä
The easiest way to execute blocking commits locklessly is to just
schedule them onto the workqueue excatly as we do for nonblocking
commits. And to preserve the blocking behaviour of the ioctl we
just flush the work before exiting the kernel.
We do need to reorder the state_put() vs drop_locks() of course
so we don't flush_work() while still holding the locks.
Note that a lot of the current users of drm_atomic_commit()
(eg. lot of the atomic helpers) have the ww_ctx stuff outside
the drm_atomic_state handling. With that structure we can't
actually pull the flush_work() past the drop_locks(). So in
order to make those places actually lockless we'll need
reverse the layers. That is left for a future excercise
and for now we just roll the flush_work() straight into
drm_atomic_commit(), leaving the non-flushing version for
just the atomic ioctl handler.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Rob Clark
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jonas Ådahl
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 32 +--
drivers/gpu/drm/drm_atomic_uapi.c | 11 ---
include/drm/drm_atomic.h | 1 +
3 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f197f59f6d99..6d728af4e8cf 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1411,7 +1411,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
EXPORT_SYMBOL(drm_atomic_check_only);
/**
- * drm_atomic_commit - commit configuration atomically
+ * drm_atomic_commit_noflush - commit configuration atomically, without
waiting for the commit
* @state: atomic configuration to check
*
* Note that this function can return -EDEADLK if the driver needed to acquire
@@ -1424,7 +1424,7 @@ EXPORT_SYMBOL(drm_atomic_check_only);
* Returns:
* 0 on success, negative error code on failure.
*/
-int drm_atomic_commit(struct drm_atomic_state *state)
+int drm_atomic_commit_noflush(struct drm_atomic_state *state)
{
struct drm_mode_config *config = >dev->mode_config;
struct drm_printer p = drm_info_printer(state->dev->dev);
@@ -1441,6 +1441,34 @@ int drm_atomic_commit(struct drm_atomic_state *state)
return config->funcs->atomic_commit(state->dev, state, false);
}
+EXPORT_SYMBOL(drm_atomic_commit_noflush);
+
+/**
+ * drm_atomic_commit - commit configuration atomically, waiting for the commit
to finish
+ * @state: atomic configuration to check
+ *
+ * Note that this function can return -EDEADLK if the driver needed to acquire
+ * more locks but encountered a deadlock. The caller must then do the usual w/w
+ * backoff dance and restart. All other errors are fatal.
+ *
+ * This function will take its own reference on @state.
+ * Callers should always release their reference with drm_atomic_state_put().
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int drm_atomic_commit(struct drm_atomic_state *state)
+{
+ int ret;
+
+ ret = drm_atomic_commit_noflush(state);
+ if (ret)
+ return ret;
+
+ flush_work(>commit_work);
+
+ return 0;
+}
EXPORT_SYMBOL(drm_atomic_commit);
/**
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..73ec26fe3393 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1290,6 +1290,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_atomic_state *state;
struct drm_modeset_acquire_ctx ctx;
struct drm_out_fence_state *fence_state;
+ bool flush = false;
int ret = 0;
unsigned int i, j, num_fences;
@@ -1423,7 +1424,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_nonblocking_commit(state);
} else {
- ret = drm_atomic_commit(state);
+ ret = drm_atomic_commit_noflush(state);
+ flush = ret == 0;
}
out:
@@ -1436,10 +1438,13 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
goto retry;
}
- drm_atomic_state_put(state);
-
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
+ if (flush)
+ flush_work(>commit_work);
+
+ drm_atomic_state_put(state);
+
return ret;
}
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 0924c322ddfb..d19ce8898bd4 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -740,6 +740,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
*state,
struct drm_crtc *crtc);
int __must_check drm_atomic_check_only(struct drm_atomic_state *state);
+int __must_check drm_atomic_commit_noflush(struct drm_atomic_state *state);
int __must_check drm_atomic_commit(struct drm_atomic_state
[PATCH 0/4] drm/atomic: Lockless blocking commits
From: Ville Syrjälä I've talked about making blocking commits lockless a few times in the past, so here's finally an attempt at it. The main benefit I see from this is that TEST_ONLY commits no longer getting blocked on the mutexes by parallel blocking commits. I have a small test here that spools up two threads, one does just TEST_ONLY commits in a loop, the other does either blocking or non-blocking page flips. Results came out as follows on a snb machine here: test-only-vs-non-blocking: -85319 TEST_ONLY commits in 200 usecs, 23 usecs / commit +87144 TEST_ONLY commits in 206 usecs, 22 usecs / commit test-only-vs-blocking: -219 TEST_ONLY commits in 2001768 usecs, 9140 usecs / commit +82442 TEST_ONLY commits in 211 usecs, 24 usecs / commit Now, I have no idea if anyone actually cares about lack of parallelism due to locked blocking commits or not. Hence Cc'd some compositor folks as well. I guess this is more of an RFC at this point. Also curious to see if CI goes up in smoke or not... Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Rob Clark Cc: Simon Ser Cc: Pekka Paalanen Cc: Jonas Ådahl Ville Syrjälä (4): drm/atomic: Treat a nonblocking commit following a blocking commit as blocking commit drm/i915: Don't reuse commit_work for the cleanup drm/atomic: Allow lockless blocking commits drm/i915: Make blocking commits lockless drivers/gpu/drm/drm_atomic.c | 32 +-- drivers/gpu/drm/drm_atomic_helper.c | 19 +++ drivers/gpu/drm/drm_atomic_uapi.c | 11 +-- drivers/gpu/drm/i915/display/intel_display.c | 15 +++-- .../drm/i915/display/intel_display_types.h| 1 + include/drm/drm_atomic.h | 8 + 6 files changed, 64 insertions(+), 22 deletions(-) -- 2.35.1
Re: [PATCH v1 3/4] drm/i915: Split i915_gem_init_stolen()
On Fri, Sep 16, 2022 at 05:50:33PM +0530, Iddamsetty, Aravind wrote:
On 16-09-2022 02:09, Lucas De Marchi wrote:
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region. Main goal is to
split the reserved part, also known as WOPCM, as its calculation changes
often per platform.
This also fixes a bug in graphics version < 5 (in theory, not tested,
due to no machine available): it would bail out on stolen creation due
to "Stolen reserved area outside stolen memory". Other than that, no
change in behavior.
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c34065fe2ecc..0e57a6d81534 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,22 +77,26 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(>mm.stolen_lock);
}
-static int i915_adjust_stolen(struct drm_i915_private *i915,
- struct resource *dsm)
+static bool valid_stolen_size(struct resource *dsm)
+{
+ return dsm->start != 0 && dsm->end > dsm->start;
+}
+
+static int adjust_stolen(struct drm_i915_private *i915,
+struct resource *dsm)
{
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
- struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (!valid_stolen_size(dsm))
return -EINVAL;
/*
+* Make sure we don't clobber the GTT if it's within stolen memory
+*
* TODO: We have yet too encounter the case where the GTT wasn't at the
* end of stolen. With that assumption we could simplify this.
*/
-
- /* Make sure we don't clobber the GTT if it's within stolen memory */
if (GRAPHICS_VER(i915) <= 4 &&
!IS_G33(i915) && !IS_PINEVIEW(i915) && !IS_G4X(i915)) {
struct resource stolen[2] = {*dsm, *dsm};
@@ -131,10 +135,20 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ if (!valid_stolen_size(dsm))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int request_smem_stolen(struct drm_i915_private *i915,
+ struct resource *dsm)
+{
+ struct resource *r;
+
/*
-* With stolen lmem, we don't need to check if the address range
-* overlaps with the non-stolen system memory range, since lmem is local
-* to the gpu.
+* With stolen lmem, we don't need to request if the address range
replace /if/for
+* since lmem is local to the gpu.
humn.. it seems I skip some words here.
With stolen lmem, we don't need to request system memory since the
stolen region is local to the gpu.
*/
if (HAS_LMEM(i915))
return 0;
@@ -392,39 +406,22 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
}
}
-static int i915_gem_init_stolen(struct intel_memory_region *mem)
+/*
+ * Initialize i915->dsm_reserved to contain the reserved space within the Data
+ * Stolen Memory. This is a range on the top of DSM that is reserved, not to
+ * be used by driver, so must be excluded from the region passed to the
+ * allocator later. In the spec this is also called as WOPCM.
+ *
+ * Our expectation is that the reserved space is at the top of the stolen
+ * region, as it has been the case for every platform, and *never* at the
+ * bottom, so the calculation here can be simplified.
+ */
+static int init_reserved_stolen(struct drm_i915_private *i915)
{
- struct drm_i915_private *i915 = mem->i915;
struct intel_uncore *uncore = >uncore;
resource_size_t reserved_base, stolen_top;
- resource_size_t reserved_total, reserved_size;
-
- mutex_init(>mm.stolen_lock);
-
- if (intel_vgpu_active(i915)) {
- drm_notice(>drm,
- "%s, disabling use of stolen memory\n",
- "iGVT-g active");
- return 0;
- }
-
- if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
- drm_notice(>drm,
- "%s, disabling use of stolen memory\n",
- "DMAR active");
- return 0;
- }
-
- if (resource_size(>region) == 0)
- return 0;
-
- if (i915_adjust_stolen(i915, >region))
- return 0;
-
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
-
- i915->dsm = mem->region;
+ resource_size_t reserved_size;
+ int ret = 0;
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -453,19 +450,17 @@ static int i915_gem_init_stolen(struct
Re: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
>From afe79848cb74cc8e45ab426d13fa2394c87e0422 Mon Sep 17 00:00:00 2001
From: xmzyshypnc <1002992...@qq.com>
Date: Fri, 16 Sep 2022 23:48:23 +0800
Subject: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry
There is a double-free security bug in split_2MB_gtt_entry.
Here is a calling chain :
ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry.
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and
kfree(spt). But the caller does not notice that, and it will call
ppgtt_free_spt again in error path.
Fix this by only freeing spt in ppgtt_invalidate_spt in good case.
Signed-off-by: Zheng Wang
---
drivers/gpu/drm/i915/gvt/gtt.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index ce0eb03709c3..550519f0acca 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -959,7 +959,7 @@ static inline int ppgtt_put_spt(struct
intel_vgpu_ppgtt_spt *spt)
return atomic_dec_return(>refcount);
}
-static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt);
+static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt, int
is_error);
static int ppgtt_invalidate_spt_by_shadow_entry(struct intel_vgpu *vgpu,
struct intel_gvt_gtt_entry *e)
@@ -995,7 +995,7 @@ static int
ppgtt_invalidate_spt_by_shadow_entry(struct intel_vgpu *vgpu,
ops->get_pfn(e));
return -ENXIO;
}
- return ppgtt_invalidate_spt(s);
+ return ppgtt_invalidate_spt(s, 0);
}
static inline void ppgtt_invalidate_pte(struct intel_vgpu_ppgtt_spt *spt,
@@ -1016,7 +1016,7 @@ static inline void ppgtt_invalidate_pte(struct
intel_vgpu_ppgtt_spt *spt,
intel_gvt_dma_unmap_guest_page(vgpu, pfn << PAGE_SHIFT);
}
-static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt)
+static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt, int is_error)
{
struct intel_vgpu *vgpu = spt->vgpu;
struct intel_gvt_gtt_entry e;
@@ -1059,9 +1059,11 @@ static int ppgtt_invalidate_spt(struct
intel_vgpu_ppgtt_spt *spt)
}
}
- trace_spt_change(spt->vgpu->id, "release", spt,
+ if (!is_error) {
+ trace_spt_change(spt->vgpu->id, "release", spt,
spt->guest_page.gfn, spt->shadow_page.type);
- ppgtt_free_spt(spt);
+ ppgtt_free_spt(spt);
+ }
return 0;
fail:
gvt_vgpu_err("fail: shadow page %p shadow entry 0x%llx type %d\n",
@@ -1215,7 +1217,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
PAGE_SIZE, _addr);
if (ret) {
- ppgtt_invalidate_spt(spt);
+ ppgtt_invalidate_spt(spt, 1);
return ret;
}
sub_se.val64 = se->val64;
@@ -1393,7 +1395,7 @@ static int
ppgtt_handle_guest_entry_removal(struct intel_vgpu_ppgtt_spt *spt,
ret = -ENXIO;
goto fail;
}
- ret = ppgtt_invalidate_spt(s);
+ ret = ppgtt_invalidate_spt(s, 0);
if (ret)
goto fail;
} else {
--
2.25.1
[pull] amdgpu, amdkfd, radeon drm-next-6.1
Hi Dave, Daniel, Updates for 6.1. The following changes since commit 213cb76ddc8b875e772f9f4d173feefa122716af: Merge tag 'drm-intel-gt-next-2022-09-09' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-09-12 21:12:23 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.1-2022-09-16 for you to fetch changes up to dacd2d2d9d800b7ab2ee2734578112532cba8105: drm/amd/display: fix boolconv.cocci warning (2022-09-14 12:38:53 -0400) amd-drm-next-6.1-2022-09-16: amdgpu: - PCI AER fixes - BACO fix - RAS fixes - XGMI fixes - Display SubVP fixes - DCN 3.2 updates - DCN 3.1.4 updates - LLVM fixes - CS cleanup in preparation for gang submit - Add some new GC CG registers - Misc cleanups amdkfd: - Fix CRIU regression - CPU fault on COW mapping fixes - Prefault fixes - Misc cleanups radeon: - Misc cleanups Alex Deucher (5): drm/amdgpu: add HDP remap functionality to nbio 7.7 drm/amdgpu: fix warning about missing imu prototype drm/amdgpu: move nbio ih_doorbell_range() into ih code for vega drm/amdgpu: move nbio sdma_doorbell_range() into sdma code for vega drm/amdgpu: make sure to init common IP before gmc Alvin Lee (4): drm/amd/display: Update MBLK calculation for SubVP drm/amd/display: SW cursor fallback for SubVP drm/amd/display: Update viewport position for phantom pipes drm/amd/display: Refactor SubVP calculation to remove FPU Aric Cyr (4): drm/amd/display: Optimizations for DML math drm/amd/display: Fix divide by zero in DML drm/amd/display: Don't adjust VRR unnecessarily drm/amd/display: 3.2.202 Aurabindo Pillai (3): drm/amd/display: Revert "Fallback to SW cursor if SubVP + cursor too big" drm/amd/display: add workaround for subvp cursor corruption for DCN32/321 drm/amd/display: Fix register definitions for DCN32/321 Candice Li (4): drm/amdgpu: Rely on MCUMC_STATUS for umc v8_10 correctable error counter only drm/amdgpu: Enable full reset when RAS is supported on gc v11_0_0 drm/amdgpu: Add EEPROM I2C address for smu v13_0_0 drm/amdgpu: Skip reset error status for psp v13_0_0 Charlene Liu (1): drm/amd/display: update header files Chris Park (1): drm/amd/display: Correct I2C register offset Christian König (6): drm/amdgpu: remove SRIOV and MCBP dependencies from the CS drm/amdgpu: move setting the job resources drm/amdgpu: revert "partial revert "remove ctx->lock" v2" drm/amdgpu: use DMA_RESV_USAGE_BOOKKEEP v2 drm/amdgpu: cleanup CS init/fini and pass1 drm/amdgpu: reorder CS code Duncan Ma (1): drm/amd/display: Correct dram channel width for dcn314 Guchun Chen (1): drm/amd/pm: disable BACO entry/exit completely on several sienna cichlid cards Hamza Mahfooz (1): drm/amdgpu: use dirty framebuffer helper JeromeHong (1): drm/amd/display: Avoid force minimal transaction in case of surface_count equal to 0 Jiapeng Chong (13): drm/amd/display: make enc32_stream_encoder_dvi_set_stream_attribute static drm/amd/display: make dscl32_calc_lb_num_partitions static drm/amd/display: make dcn32_link_encoder_is_in_alt_mode and dcn32_link_encoder_get_max_link_cap static drm/amd/display: make mpc32_program_shaper and mpc32_program_3dlut static drm/amd/display: Remove the unused function copy_stream_update_to_stream() drm/amd/display: make some functions static drm/amd/display: make enc314_stream_encoder_dvi_set_stream_attribute static drm/amd/display: make optc314_phantom_crtc_post_enable static drm/amd/display: make some functions static drm/amd/display: make mmhubbub32_config_mcif_buf static drm/amd/display: make some functions static drm/amd/display: make some functions static drm/amd/display: make optc32_phantom_crtc_post_enable, optc32_setup_manual_trigger and optc32_set_drr static Jilin Yuan (1): drm/amd/display: fix repeated words in comments JinZe.Xu (1): drm/amd/display: Assign link type before check dsc workaround. Jingyu Wang (5): drm/amdgpu: cleanup coding style in amdgpu_acpi.c drm/amdgpu: cleanup coding style in amdgpu_sync.c file drm/amdgpu: cleanup coding style in amdgpu_amdkfd.c drm/amdgpu: cleanup coding style in amdgpu_amdkfd_gpuvm.c drm/amdgpu/display: remove unneeded "default n" options John Clements (1): drm/amdgpu: added support for ras driver loading Lee, Alvin (1): drm/amd/display: Added debug option for forcing subvp num ways Leo Chen (2): drm/amd/display: Fixing DIG FIFO Error drm/amd/display: Adding log for spread_spectrum_info Li Ma (1): drm/amd/pm:add new gpu_metrics_v2_3 to acquire average temperature info Lijo Lazar
Re: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
Hi greg, Thanks for pointing that out. Working on it now :) Best wishes, Zheng Wang Greg KH 于2022年9月16日周五 16:25写道： > > On Fri, Sep 16, 2022 at 02:39:21PM +0800, Zheng Hacker wrote: > > >From 8d95c1399e3ff345500a575e21254a73b0c89144 Mon Sep 17 00:00:00 2001 > > From: xmzyshypnc <1002992...@qq.com> > > Date: Fri, 16 Sep 2022 14:37:48 +0800 > > Subject: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry > > > > There is a double-free security bug in split_2MB_gtt_entry. > > > > Here is a calling chain : > > ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry. > > If intel_gvt_dma_map_guest_page failed, it will call > > ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and > > kfree(spt). But the caller does not notice that, and it will call > > ppgtt_free_spt again in error path. > > > > Fix this by only freeing spt in ppgtt_invalidate_spt in good case. > > > > Signed-off-by: xmzyshypnc <1002992...@qq.com> > > --- > > drivers/gpu/drm/i915/gvt/gtt.c | 16 +--- > > 1 file changed, 9 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c > > index 9f14fded8c0c..31d2a8d56384 100644 > > --- a/drivers/gpu/drm/i915/gvt/gtt.c > > +++ b/drivers/gpu/drm/i915/gvt/gtt.c > > @@ -959,7 +959,7 @@ static inline int ppgtt_put_spt(struct > > intel_vgpu_ppgtt_spt *spt) > > return atomic_dec_return(>refcount); > > } > > > > -static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt); > > +static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *sptm, > > int is_error); > > Your patch is whitespace damaged and linewrapped and can not be applied, > and can only barely read :( > > Please fix up your email client to not do this so that the change can be > properly reviewed and accepted if correct. > > thanks, > > greg k-h
[PATCH 1/3] pwm: Change prototype of .get_state() callback to return an error
Most drivers succeed to read out the programmed state unconditionally.
But some don't, allow them to signal a failure to the pwm core.
All drivers are adapted to return 0 on success and forward the error
code otherwise.
The core doesn't make use of this yet.
Signed-off-by: Uwe Kleine-König
---
drivers/gpio/gpio-mvebu.c | 9 ++---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 14 --
drivers/leds/rgb/leds-qcom-lpg.c | 12 +++-
drivers/pwm/pwm-atmel.c | 6 --
drivers/pwm/pwm-bcm-iproc.c | 8 +---
drivers/pwm/pwm-crc.c | 10 ++
drivers/pwm/pwm-cros-ec.c | 12 ++--
drivers/pwm/pwm-dwc.c | 6 --
drivers/pwm/pwm-hibvt.c | 6 --
drivers/pwm/pwm-imx-tpm.c | 8 +---
drivers/pwm/pwm-imx27.c | 8 +---
drivers/pwm/pwm-intel-lgm.c | 6 --
drivers/pwm/pwm-iqs620a.c | 6 --
drivers/pwm/pwm-keembay.c | 6 --
drivers/pwm/pwm-lpss.c| 4 +++-
drivers/pwm/pwm-meson.c | 9 -
drivers/pwm/pwm-mtk-disp.c| 17 -
drivers/pwm/pwm-pca9685.c | 8 +---
drivers/pwm/pwm-raspberrypi-poe.c | 8 +---
drivers/pwm/pwm-rockchip.c| 12 +++-
drivers/pwm/pwm-sifive.c | 4 +++-
drivers/pwm/pwm-sl28cpld.c| 8 +---
drivers/pwm/pwm-sprd.c| 13 ++---
drivers/pwm/pwm-stm32-lp.c| 8 +---
drivers/pwm/pwm-sun4i.c | 13 -
drivers/pwm/pwm-sunplus.c | 6 --
drivers/pwm/pwm-visconti.c| 4 +++-
drivers/pwm/pwm-xilinx.c | 8 +---
include/linux/pwm.h | 4 ++--
29 files changed, 145 insertions(+), 98 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index aa126ab80f0c..fa48825654c9 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -657,9 +657,10 @@ static void mvebu_pwm_free(struct pwm_chip *chip, struct
pwm_device *pwm)
spin_unlock_irqrestore(>lock, flags);
}
-static void mvebu_pwm_get_state(struct pwm_chip *chip,
- struct pwm_device *pwm,
- struct pwm_state *state) {
+static int mvebu_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
struct mvebu_gpio_chip *mvchip = mvpwm->mvchip;
@@ -693,6 +694,8 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip,
state->enabled = false;
spin_unlock_irqrestore(>lock, flags);
+
+ return 0;
}
static int mvebu_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index d6dd4d99a229..102c23f66ffd 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1427,8 +1427,8 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
return ret;
}
-static void ti_sn_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
- struct pwm_state *state)
+static int ti_sn_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
{
struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
unsigned int pwm_en_inv;
@@ -1439,19 +1439,19 @@ static void ti_sn_pwm_get_state(struct pwm_chip *chip,
struct pwm_device *pwm,
ret = regmap_read(pdata->regmap, SN_PWM_EN_INV_REG, _en_inv);
if (ret)
- return;
+ return ret;
ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_SCALE_REG, );
if (ret)
- return;
+ return ret;
ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_REG, );
if (ret)
- return;
+ return ret;
ret = regmap_read(pdata->regmap, SN_PWM_PRE_DIV_REG, _div);
if (ret)
- return;
+ return ret;
state->enabled = FIELD_GET(SN_PWM_EN_MASK, pwm_en_inv);
if (FIELD_GET(SN_PWM_INV_MASK, pwm_en_inv))
@@ -1466,6 +1466,8 @@ static void ti_sn_pwm_get_state(struct pwm_chip *chip,
struct pwm_device *pwm,
if (state->duty_cycle > state->period)
state->duty_cycle = state->period;
+
+ return 0;
}
static const struct pwm_ops ti_sn_pwm_ops = {
diff --git a/drivers/leds/rgb/leds-qcom-lpg.c b/drivers/leds/rgb/leds-qcom-lpg.c
index 02f51cc61837..dc8f3a482a5a 100644
--- a/drivers/leds/rgb/leds-qcom-lpg.c
+++ b/drivers/leds/rgb/leds-qcom-lpg.c
@@ -968,7 +968,7 @@ static int lpg_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
[PATCH 2/3] pwm/tracing: Also record trace events for failed apply calls
Record and report an error code for the events. This allows to report
about failed calls without ambiguity and so gives a more complete
picture.
Signed-off-by: Uwe Kleine-König
---
drivers/pwm/core.c | 18 --
include/trace/events/pwm.h | 20 ++--
2 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 0e042410f6b9..381db04cfa00 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -108,8 +108,8 @@ static int pwm_device_request(struct pwm_device *pwm, const
char *label)
}
if (pwm->chip->ops->get_state) {
- pwm->chip->ops->get_state(pwm->chip, pwm, >state);
- trace_pwm_get(pwm, >state);
+ err = pwm->chip->ops->get_state(pwm->chip, pwm, >state);
+ trace_pwm_get(pwm, >state, err);
if (IS_ENABLED(CONFIG_PWM_DEBUG))
pwm->last = pwm->state;
@@ -457,8 +457,8 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
* checks.
*/
- chip->ops->get_state(chip, pwm, );
- trace_pwm_get(pwm, );
+ err = chip->ops->get_state(chip, pwm, );
+ trace_pwm_get(pwm, , err);
/*
* The lowlevel driver either ignored .polarity (which is a bug) or as
@@ -514,16 +514,15 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
/* reapply the state that the driver reported being configured. */
err = chip->ops->apply(chip, pwm, );
+ trace_pwm_apply(pwm, , err);
if (err) {
*last = s1;
dev_err(chip->dev, "failed to reapply current setting\n");
return;
}
- trace_pwm_apply(pwm, );
-
- chip->ops->get_state(chip, pwm, last);
- trace_pwm_get(pwm, last);
+ err = chip->ops->get_state(chip, pwm, last);
+ trace_pwm_get(pwm, last, err);
/* reapplication of the current state should give an exact match */
if (s1.enabled != last->enabled ||
@@ -571,11 +570,10 @@ int pwm_apply_state(struct pwm_device *pwm, const struct
pwm_state *state)
return 0;
err = chip->ops->apply(chip, pwm, state);
+ trace_pwm_apply(pwm, state, err);
if (err)
return err;
- trace_pwm_apply(pwm, state);
-
pwm->state = *state;
/*
diff --git a/include/trace/events/pwm.h b/include/trace/events/pwm.h
index cf243de41cc8..12b35e4ff917 100644
--- a/include/trace/events/pwm.h
+++ b/include/trace/events/pwm.h
@@ -10,9 +10,9 @@
DECLARE_EVENT_CLASS(pwm,
- TP_PROTO(struct pwm_device *pwm, const struct pwm_state *state),
+ TP_PROTO(struct pwm_device *pwm, const struct pwm_state *state, int
err),
- TP_ARGS(pwm, state),
+ TP_ARGS(pwm, state, err),
TP_STRUCT__entry(
__field(struct pwm_device *, pwm)
@@ -20,6 +20,7 @@ DECLARE_EVENT_CLASS(pwm,
__field(u64, duty_cycle)
__field(enum pwm_polarity, polarity)
__field(bool, enabled)
+ __field(int, err)
),
TP_fast_assign(
@@ -28,28 +29,27 @@ DECLARE_EVENT_CLASS(pwm,
__entry->duty_cycle = state->duty_cycle;
__entry->polarity = state->polarity;
__entry->enabled = state->enabled;
+ __entry->err = err;
),
- TP_printk("%p: period=%llu duty_cycle=%llu polarity=%d enabled=%d",
+ TP_printk("%p: period=%llu duty_cycle=%llu polarity=%d enabled=%d
err=%d",
__entry->pwm, __entry->period, __entry->duty_cycle,
- __entry->polarity, __entry->enabled)
+ __entry->polarity, __entry->enabled, __entry->err)
);
DEFINE_EVENT(pwm, pwm_apply,
- TP_PROTO(struct pwm_device *pwm, const struct pwm_state *state),
-
- TP_ARGS(pwm, state)
+ TP_PROTO(struct pwm_device *pwm, const struct pwm_state *state, int
err),
+ TP_ARGS(pwm, state, err)
);
DEFINE_EVENT(pwm, pwm_get,
- TP_PROTO(struct pwm_device *pwm, const struct pwm_state *state),
-
- TP_ARGS(pwm, state)
+ TP_PROTO(struct pwm_device *pwm, const struct pwm_state *state, int
err),
+ TP_ARGS(pwm, state, err)
);
#endif /* _TRACE_PWM_H */
--
2.37.2
[PATCH 3/3] pwm: Handle .get_state() failures
This suppresses diagnosis for PWM_DEBUG routines and makes sure that
pwm->state isn't modified in pwm_device_request() if .get_state() fails.
Signed-off-by: Uwe Kleine-König
---
drivers/pwm/core.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 381db04cfa00..421573590613 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -108,9 +108,14 @@ static int pwm_device_request(struct pwm_device *pwm,
const char *label)
}
if (pwm->chip->ops->get_state) {
- err = pwm->chip->ops->get_state(pwm->chip, pwm, >state);
+ struct pwm_state state;
+
+ err = pwm->chip->ops->get_state(pwm->chip, pwm, );
trace_pwm_get(pwm, >state, err);
+ if (!err)
+ pwm->state = state;
+
if (IS_ENABLED(CONFIG_PWM_DEBUG))
pwm->last = pwm->state;
}
@@ -459,6 +464,9 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
err = chip->ops->get_state(chip, pwm, );
trace_pwm_get(pwm, , err);
+ if (err)
+ /* If that failed there isn't much to debug */
+ return;
/*
* The lowlevel driver either ignored .polarity (which is a bug) or as
@@ -523,6 +531,8 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
err = chip->ops->get_state(chip, pwm, last);
trace_pwm_get(pwm, last, err);
+ if (err)
+ return;
/* reapplication of the current state should give an exact match */
if (s1.enabled != last->enabled ||
--
2.37.2
[PATCH v2 3/3] drm/etnaviv: export client GPU usage statistics via fdinfo
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
---
v2:
- fix code style
- switch to raw seq_printf
- leave some breadcrumbs about the output format
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 40 ++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index b69edb40ae2a..c08748472f74 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -22,6 +22,7 @@
#include "etnaviv_gem.h"
#include "etnaviv_mmu.h"
#include "etnaviv_perfmon.h"
+#include "common.xml.h"
/*
* DRM operations:
@@ -471,7 +472,44 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_RENDER_ALLOW),
};
-DEFINE_DRM_GEM_FOPS(fops);
+static void etnaviv_fop_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct drm_file *file = f->private_data;
+ struct drm_device *dev = file->minor->dev;
+ struct etnaviv_drm_private *priv = dev->dev_private;
+ struct etnaviv_file_private *ctx = file->driver_priv;
+
+ /*
+* For a description of the text output format used here, see
+* Documentation/gpu/drm-usage-stats.rst.
+*/
+ seq_printf(m, "drm-driver:\t%s\n", dev->driver->name);
+ seq_printf(m, "drm-client-id:\t%u\n", ctx->id);
+
+ for (int i = 0; i < ETNA_MAX_PIPES; i++) {
+ struct etnaviv_gpu *gpu = priv->gpu[i];
+ char engine[8];
+ int cur = 0;
+
+ if (!gpu)
+ continue;
+
+ if (gpu->identity.features & chipFeatures_PIPE_2D)
+ cur = snprintf(engine, sizeof(engine), "2D");
+ if (gpu->identity.features & chipFeatures_PIPE_3D)
+ cur = snprintf(engine + cur, sizeof(engine) - cur,
+ "%s3D", cur ? "/" : "");
+
+ seq_printf(m, "drm-engine-%s:\t%llu ns\n", engine,
+ ctx->sched_entity[i].elapsed_ns);
+ }
+}
+
+static const struct file_operations fops = {
+ .owner = THIS_MODULE,
+ DRM_GEM_FOPS,
+ .show_fdinfo = etnaviv_fop_show_fdinfo,
+};
static const struct drm_driver etnaviv_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_RENDER,
--
2.30.2
[PATCH v2 2/3] drm/etnaviv: allocate unique ID per drm_file
Allows to easily track if several fd are pointing to the same
execution context due to being dup'ed.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 1d2b4fb4bcf8..b69edb40ae2a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -49,6 +49,7 @@ static void load_gpu(struct drm_device *dev)
static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
{
struct etnaviv_drm_private *priv = dev->dev_private;
+ static atomic_t ident = ATOMIC_INIT(0);
struct etnaviv_file_private *ctx;
int ret, i;
@@ -56,6 +57,8 @@ static int etnaviv_open(struct drm_device *dev, struct
drm_file *file)
if (!ctx)
return -ENOMEM;
+ ctx->id = atomic_inc_return();
+
ctx->mmu = etnaviv_iommu_context_init(priv->mmu_global,
priv->cmdbuf_suballoc);
if (!ctx->mmu) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index f32f4771dada..851b4b4ef146 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -27,6 +27,7 @@ struct etnaviv_iommu_global;
#define ETNAVIV_SOFTPIN_START_ADDRESS SZ_4M /* must be >= SUBALLOC_SIZE */
struct etnaviv_file_private {
+ int id;
struct etnaviv_iommu_context*mmu;
struct drm_sched_entity sched_entity[ETNA_MAX_PIPES];
};
--
2.30.2
[PATCH v2 1/3] drm/scheduler: track GPU active time per entity
Track the accumulated time that jobs from this entity were active
on the GPU. This allows drivers using the scheduler to trivially
implement the DRM fdinfo when the hardware doesn't provide more
specific information than signalling job completion anyways.
Signed-off-by: Lucas Stach
Reviewed-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 6 ++
include/drm/gpu_scheduler.h| 7 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 68317d3a7a27..5dbe826d498d 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -852,6 +852,12 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched)
spin_unlock(>job_list_lock);
+ if (job) {
+ job->entity->elapsed_ns += ktime_to_ns(
+ ktime_sub(job->s_fence->finished.timestamp,
+ job->s_fence->scheduled.timestamp));
+ }
+
return job;
}
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index addb135eeea6..573bef640664 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -196,6 +196,13 @@ struct drm_sched_entity {
* drm_sched_entity_fini().
*/
struct completion entity_idle;
+ /**
+* @elapsed_ns
+*
+* Records the amount of time where jobs from this entity were active
+* on the GPU.
+*/
+ uint64_t elapsed_ns;
};
/**
--
2.30.2
[PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fixed review comments (Ashutosh)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 7995a885c9d6..851525d2117d 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -65,6 +65,11 @@ What:
/sys/devices/.../hwmon/hwmon/energy1_input
Date: September 2022
KernelVersion: 6
Contact: dri-devel@lists.freedesktop.org
-Description: RO. Energy input of device in microjoules.
+Description: RO. Energy input of device or gt in microjoules.
+
+ For i915 device level hwmon devices (name "i915") this
+ reflects energy input for the entire device. For gt level
+ hwmon devices (name "i915_gtN") this reflects energy input
+ for the gt.
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 65336514554d..3c385395aaef 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1591,4 +1591,9 @@
*/
#define MTL_MEDIA_GSI_BASE 0x38
+#define GT0_PACKAGE_ENERGY_STATUS _MMIO(0x250004)
+#define GT0_PACKAGE_RAPL_LIMIT _MMIO(0x250008)
+#define GT0_PACKAGE_POWER_SKU_UNIT _MMIO(0x250068)
+#define GT0_PLATFORM_ENERGY_STATUS _MMIO(0x25006c)
+
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 7d85a81bc39b..4a4aec1c67ab 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
#include "intel_pcode.h"
+#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
/*
@@ -34,6 +35,7 @@ struct hwm_reg {
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
i915_reg_t energy_status_all;
+ i915_reg_t energy_status_tile;
};
struct hwm_energy_info {
@@ -47,10 +49,12 @@ struct hwm_drvdata {
struct device *hwmon_dev;
struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
+ int gt_n;
};
struct i915_hwmon {
struct hwm_drvdata ddat;
+ struct hwm_drvdata ddat_gt[I915_MAX_GT];
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
@@ -144,7 +148,10 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
i915_reg_t rgaddr;
u32 reg_val;
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
mutex_lock(>hwmon_lock);
@@ -280,6 +287,11 @@ static const struct hwmon_channel_info *hwm_info[] = {
NULL
};
+static const struct hwmon_channel_info *hwm_gt_info[] = {
+ HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ NULL
+};
+
/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
{
@@ -409,7 +421,10 @@ hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32
attr)
switch (attr) {
case hwmon_energy_input:
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
return i915_mmio_reg_valid(rgaddr) ? 0444 : 0;
default:
return 0;
@@ -544,6 +559,44 @@ static const struct hwmon_chip_info hwm_chip_info = {
.info = hwm_info,
};
+static umode_t
+hwm_gt_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
+ switch (type) {
+ case hwmon_energy:
+ return hwm_energy_is_visible(ddat, attr);
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_gt_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long *val)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+
[PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 9 ++
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 4 +
4 files changed, 129 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index cc70596fff44..7995a885c9d6 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,15 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_max_interval
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/power1_crit
Date: September 2022
KernelVersion: 6
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index bd9ba312c474..7d85a81bc39b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -20,11 +20,13 @@
* - power - microwatts
* - curr - milliamperes
* - energy - microjoules
+ * - time - milliseconds
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
#define SF_CURR1000
#define SF_ENERGY 100
+#define SF_TIME1000
struct hwm_reg {
i915_reg_t gt_perf_status;
@@ -53,6 +55,7 @@ struct i915_hwmon {
struct hwm_reg rg;
int scl_shift_power;
int scl_shift_energy;
+ int scl_shift_time;
};
static void
@@ -161,6 +164,114 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
return 0;
}
+static ssize_t
+hwm_power1_max_interval_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 r, x, y, x_w = 2; /* 2 bits */
+ u64 tau4, out;
+
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+
+ x = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_X, r);
+ y = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_Y, r);
+ /*
+* tau = 1.x * power(2,y), x = bits(23:22), y = bits(21:17)
+* = (4 | x) << (y - 2)
+* where (y - 2) ensures a 1.x fixed point representation of 1.x
+* However because y can be < 2, we compute
+* tau4 = (4 | x) << y
+* but add 2 when doing the final right shift to account for units
+*/
+ tau4 = ((1 << x_w) | x) << y;
+ /* val in hwmon interface units (millisec) */
+ out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ return sysfs_emit(buf, "%llu\n", out);
+}
+
+static ssize_t
+hwm_power1_max_interval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ long val, max_win, ret;
+ u32 x, y, rxy, x_w = 2; /* 2 bits */
+ u64 tau4, r;
+
+#define PKG_MAX_WIN_DEFAULT 0x12ull
+
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
+
+ /*
+* val must be < max in hwmon interface units. The steps below are
+* explained in i915_power1_max_interval_show()
+*/
+ r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
+ x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
+ y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
+ tau4 = ((1 << x_w) | x) << y;
+ max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ if (val > max_win)
+ return -EINVAL;
+
+ /* val in hw units */
+ val = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_time, SF_TIME);
+ /* Convert to 1.x * power(2,y) */
+ if (!val)
+ return -EINVAL;
+ y = ilog2(val);
+ /* x = (val - (1 << y)) >> (y - 2); */
+ x = (val - (1ul << y)) << x_w >> y;
+
+ rxy =
[PATCH 4/7] drm/i915/hwmon: Show device level energy usage
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2:
- Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
- Updated date, kernel version in documentation
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 ++
drivers/gpu/drm/i915/i915_hwmon.c | 107 +-
drivers/gpu/drm/i915/i915_hwmon.h | 1 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 2 +
4 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index bc061238e35c..94101f818a70 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,11 @@ Contact: dri-devel@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/energy1_input
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RO. Energy input of device in microjoules.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 5183cf51a49b..a42cfad78bef 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -17,21 +17,30 @@
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - energy - microjoules
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
+#define SF_ENERGY 100
struct hwm_reg {
i915_reg_t gt_perf_status;
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+ i915_reg_t energy_status_all;
+};
+
+struct hwm_energy_info {
+ u32 reg_val_prev;
+ long accum_energy; /* Accumulated energy for
energy1_input */
};
struct hwm_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+ struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
};
@@ -40,6 +49,7 @@ struct i915_hwmon {
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
+ int scl_shift_energy;
};
static void
@@ -98,9 +108,60 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
}
+/*
+ * hwm_energy - Obtain energy value
+ *
+ * The underlying energy hardware register is 32-bits and is subject to
+ * overflow. How long before overflow? For example, with an example
+ * scaling bit shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and
+ * a power draw of 1000 watts, the 32-bit counter will overflow in
+ * approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt: (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ *
+ * The function significantly increases overflow duration (from 4.36
+ * minutes) by accumulating the energy register into a 'long' as allowed by
+ * the hwmon API. Using x86_64 128 bit arithmetic (see mul_u64_u32_shr()),
+ * a 'long' of 63 bits, SF_ENERGY of 1e6 (~20 bits) and
+ * hwmon->scl_shift_energy of 14 bits we have 57 (63 - 20 + 14) bits before
+ * energy1_input overflows. This at 1000 W is an overflow duration of 278
years.
+ */
+static int
+hwm_energy(struct hwm_drvdata *ddat, long *energy)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct hwm_energy_info *ei = >ei;
+ intel_wakeref_t wakeref;
+ i915_reg_t rgaddr;
+ u32 reg_val;
+
+ rgaddr = hwmon->rg.energy_status_all;
+
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_val = intel_uncore_read(uncore, rgaddr);
+
+ if (reg_val >= ei->reg_val_prev)
+ ei->accum_energy += reg_val - ei->reg_val_prev;
+ else
+ ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
+ ei->reg_val_prev = reg_val;
+
+ *energy = mul_u64_u32_shr(ei->accum_energy, SF_ENERGY,
+ hwmon->scl_shift_energy);
+ mutex_unlock(>hwmon_lock);
+
+ return 0;
+}
+
static const struct hwmon_channel_info *hwm_info[] = {
[PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
- Fix review comments (Jani)
- Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
- Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
- Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6:
- Fix review comments (Ashutosh)
- Update date, kernel version in documentation
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 +++
drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 6 +
4 files changed, 187 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index e2974f928e58..bc061238e35c 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact: dri-devel@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit in
microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 45745afa5c5b..5183cf51a49b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
+ * - power - microwatts
*/
#define SF_VOLTAGE 1000
+#define SF_POWER 100
struct hwm_reg {
i915_reg_t gt_perf_status;
+ i915_reg_t pkg_power_sku_unit;
+ i915_reg_t pkg_power_sku;
+ i915_reg_t pkg_rapl_limit;
};
struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
+ int scl_shift_power;
};
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+ i915_reg_t reg, u32 clear, u32 set)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(>hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+u32 field_msk, int nshift, u32 scale_factor)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
+ reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+ return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+ u32 nval;
+ u32 bits_to_clear;
+ u32 bits_to_set;
+
+ /* Computation in 64-bits to avoid overflow. Round to nearest. */
+ nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
+ bits_to_clear = field_msk;
+ bits_to_set = FIELD_PREP(field_msk, nval);
+
+
[PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3:
- Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use hwm_ prefix for static functions (Ashutosh)
v5: Updated date, kernel version in documentation
Cc: Sujaritha Sundaresan
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 26 +
drivers/gpu/drm/i915/i915_hwmon.c | 95 ++-
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 94101f818a70..cc70596fff44 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,32 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_crit
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in microwatts.
+
+ Card reactive critical (I1) power limit in microwatts is exposed
+ for client products. The power controller will throttle the
+ operating frequency if the power averaged over a window exceeds
+ this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/curr1_crit
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in milliamperes.
+
+ Card reactive critical (I1) power limit in milliamperes is
+ exposed for server products. The power controller will throttle
+ the operating frequency if the power averaged over a window
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/energy1_input
Date: September 2022
KernelVersion: 6
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index a42cfad78bef..bd9ba312c474 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,16 +11,19 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "intel_pcode.h"
#include "gt/intel_gt_regs.h"
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - curr - milliamperes
* - energy - microjoules
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
+#define SF_CURR1000
#define SF_ENERGY 100
struct hwm_reg {
@@ -160,11 +163,25 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
static const struct hwmon_channel_info *hwm_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
- HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX),
+ HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX |
HWMON_P_CRIT),
HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
NULL
};
+/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
+static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
+{
+ return snb_pcode_read_p(>uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_READ_I1, 0, uval);
+}
+
+static int hwm_pcode_write_i1(struct drm_i915_private *i915, u32 uval)
+{
+ return snb_pcode_write_p(>uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_WRITE_I1, 0, uval);
+}
+
static umode_t
hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
{
@@ -198,13 +215,18 @@ hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
static umode_t
hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 attr, int chan)
{
+ struct drm_i915_private *i915 = ddat->uncore->i915;
struct i915_hwmon *hwmon = ddat->hwmon;
+ u32 uval;
switch (attr) {
case hwmon_power_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ? 0664 : 0;
case hwmon_power_rated_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_power_sku) ? 0444 : 0;
+ case hwmon_power_crit:
+ return (hwm_pcode_read_i1(i915, ) ||
+ !(uval & POWER_SETUP_I1_WATTS)) ? 0 : 0644;
default:
return 0;
}
@@
[PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use hwm_ prefix for static functions (Ashutosh)
v5:
- Added unit of voltage as millivolts (Ashutosh)
- Updated date, kernel version in documentation
Cc: Guenter Roeck
Cc: Anshuman Gupta
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ++
drivers/gpu/drm/i915/i915_hwmon.c | 53 +++
3 files changed, 63 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..e2974f928e58
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What: /sys/devices/.../hwmon/hwmon/in0_input
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RO. Current Voltage in millivolt.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 2275ee47da95..65336514554d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1510,6 +1510,9 @@
#define VLV_RENDER_C0_COUNT_MMIO(0x138118)
#define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
+#define GEN12_RPSTAT1 _MMIO(0x1381b4)
+#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
+
#define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
#define GEN11_CSME (31)
#define GEN11_GUNIT (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 103dd543a214..45745afa5c5b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,8 +11,16 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
+
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - voltage - millivolts
+ */
+#define SF_VOLTAGE 1000
struct hwm_reg {
+ i915_reg_t gt_perf_status;
};
struct hwm_drvdata {
@@ -29,14 +37,49 @@ struct i915_hwmon {
};
static const struct hwmon_channel_info *hwm_info[] = {
+ HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
NULL
};
+static umode_t
+hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
+{
+ switch (attr) {
+ case hwmon_in_input:
+ return i915_mmio_reg_valid(ddat->hwmon->rg.gt_perf_status) ?
0444 : 0;
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ switch (attr) {
+ case hwmon_in_input:
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(ddat->uncore,
hwmon->rg.gt_perf_status);
+ /* HW register value in units of 2.5 millivolt */
+ *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK,
reg_value) * 25, 10);
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static umode_t
hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
u32 attr, int channel)
{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -46,7 +89,11 @@ static int
hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
int channel, long *val)
{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -76,6 +123,12 @@ static const struct hwmon_chip_info hwm_chip_info = {
static void
hwm_get_preregistration_info(struct drm_i915_private *i915)
{
+ struct i915_hwmon *hwmon = i915->hwmon;
+
+ if (IS_DG1(i915) || IS_DG2(i915))
+ hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+ else
+ hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
}
void i915_hwmon_register(struct drm_i915_private *i915)
--
2.25.1
[PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments (Jani)
- Remove "select HWMON" from i915/Kconfig (Jani)
v3: Use hwm_ prefix for static functions (Ashutosh)
v4: s/#ifdef CONFIG_HWMON/#if IS_REACHABLE(CONFIG_HWMON)/ since the former
doesn't work if hwmon is compiled as a module (Guenter)
v5: Fixed review comments (Jani)
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_driver.c | 5 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +
drivers/gpu/drm/i915/i915_hwmon.c | 136 +
drivers/gpu/drm/i915/i915_hwmon.h | 20 +
5 files changed, 166 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..66a6023e61a6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -209,6 +209,9 @@ i915-y += gt/uc/intel_uc.o \
# graphics system controller (GSC) support
i915-y += gt/intel_gsc.o
+# graphics hardware monitoring (HWMON) support
+i915-$(CONFIG_HWMON) += i915_hwmon.o
+
# modesetting core code
i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c459eb362c47..75655adb7bd3 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -81,6 +81,7 @@
#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_getparam.h"
+#include "i915_hwmon.h"
#include "i915_ioc32.h"
#include "i915_ioctl.h"
#include "i915_irq.h"
@@ -763,6 +764,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_register(gt);
+ i915_hwmon_register(dev_priv);
+
intel_display_driver_register(dev_priv);
intel_power_domains_enable(dev_priv);
@@ -795,6 +798,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_unregister(gt);
+ i915_hwmon_unregister(dev_priv);
+
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f9372931fd2..01a2caf42635 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -353,6 +353,8 @@ struct drm_i915_private {
struct i915_perf perf;
+ struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct intel_gt gt0;
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..103dd543a214
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_hwmon.h"
+#include "i915_reg.h"
+#include "intel_mchbar_regs.h"
+
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+ struct i915_hwmon *hwmon;
+ struct intel_uncore *uncore;
+ struct device *hwmon_dev;
+ char name[12];
+};
+
+struct i915_hwmon {
+ struct hwm_drvdata ddat;
+ struct mutex hwmon_lock;/* counter overflow logic and
rmw */
+ struct hwm_reg rg;
+};
+
+static const struct hwmon_channel_info *hwm_info[] = {
+ NULL
+};
+
+static umode_t
+hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (type) {
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+int channel, long *val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int
+hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops hwm_ops = {
+ .is_visible = hwm_is_visible,
+ .read = hwm_read,
+ .write = hwm_write,
+};
+
+static const struct hwmon_chip_info hwm_chip_info = {
+ .ops = _ops,
+ .info = hwm_info,
+};
+
+static void
+hwm_get_preregistration_info(struct drm_i915_private *i915)
+{
+}
+
+void i915_hwmon_register(struct drm_i915_private *i915)
+{
+ struct device *dev =
[PATCH 0/7] drm/i915: Add HWMON support
This series adds the HWMON support for DGFX Test-with: 20220914140721.3500129-1-riana.ta...@intel.com v2: - Reorganized series. Created first patch as infrastructure patch followed by feature patches. (Ashutosh) - Fixed review comments (Jani) - Fixed review comments (Ashutosh) v3: - Fixed review comments from Guenter - Exposed energy inferface as standard hwmon interface (Ashutosh) - For power interface added entries for critical power and maintained standard interface for all the entries except power1_max_interval - Extended support for XEHPSDV (Ashutosh) v4: - Fixed review comment from Guenter - Cleaned up unused code v5: - Fixed review comments (Jani) v6: - Fixed review comments (Ashutosh) - Updated date and kernel version in documentation Ashutosh Dixit (2): drm/i915/hwmon: Expose card reactive critical power drm/i915/hwmon: Expose power1_max_interval Dale B Stimson (4): drm/i915/hwmon: Add HWMON infrastructure drm/i915/hwmon: Power PL1 limit and TDP setting drm/i915/hwmon: Show device level energy usage drm/i915/hwmon: Extend power/energy for XEHPSDV Riana Tauro (1): drm/i915/hwmon: Add HWMON current voltage support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 75 ++ drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 + drivers/gpu/drm/i915/i915_driver.c| 5 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_hwmon.c | 761 ++ drivers/gpu/drm/i915/i915_hwmon.h | 21 + drivers/gpu/drm/i915/i915_reg.h | 14 + drivers/gpu/drm/i915/intel_mchbar_regs.h | 12 + 9 files changed, 901 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h -- 2.25.1
Re: [PATCH v3 0/2] drm/etnaviv: GC300 fixes
Am Samstag, dem 10.09.2022 um 13:29 -0700 schrieb Doug Brown: > This series contains a few special cases for supporting the GC300 > properly. These were found in the drivers in the vivante_kernel_drivers > repository. These changes were tested on a PXA168 with GC300 revision > 0x2201 (date 0x20080814, time 0x12051100), which already has an existing > special case in the driver to modify the revision to 0x1051. > Thanks, both patches applied to my etnaviv/next branch. Regards, Lucas > Changes since v2: > - Dump canonical address in etnaviv_core_dump_registers > - Misc fixes from review by Lucas > > Changes from v1->v2: > - Move power register address remapping to new gpu_read_power and > gpu_write_power accessors instead of modifying gpu_read and gpu_write. > > Doug Brown (2): > drm/etnaviv: add missing quirks for GC300 > drm/etnaviv: fix power register offset on GC300 > > drivers/gpu/drm/etnaviv/etnaviv_dump.c | 7 +- > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 31 -- > drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 21 + > 3 files changed, 46 insertions(+), 13 deletions(-) >
Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering
On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
>
> On 16/09/2022 02:43, Matt Roper wrote:
> > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > that a subset of these are of a "GAM" subclass that has unique rules and
> > doesn't followed regular mslice steering behavior.
> >
> > * Xe_HP SDV: GAM ranges must always be steered to 0,0. These
> > registers share the regular steering control register (0xFDC) with
> > other steering types
> >
> > * DG2: GAM ranges must always be steered to 1,0. GAM registers have a
> > dedicated steering control register (0xFE0) so we can set the value
> > once at startup and rely on implicit steering. Technically the
> > hardware default should already be set to 1,0 properly, but it never
> > hurts to ensure that in the driver.
>
> Do you have any data on whether the "technically should" holds in practice?
> What would be the consequences of some platform/machine surprising us here?
The bspec indicates the hardware default value is already the necessary
1,0 value; I'm mostly paranoid about some kind of boot firmware wiping
it to 0,0 by accident. I don't have any evidence that has ever actually
happened, but explicitly re-programming it to 1,0 in the patch here is a
defensive measure just to be safe.
If we didn't have this patch _and_ some firmware screwed up the GAM
steering target, then presumably we might read back garbage or 0 from
GAM registers in places where we should have received a real value.
Matt
>
> Regards,
>
> Tvrtko
>
> >
> > Bspec: 66534
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24 +++--
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
> > 4 files changed, 34 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index e79405a45312..a2047a68ea7a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > @@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
> > "L3BANK",
> > "MSLICE",
> > "LNCF",
> > + "GAM",
> > "INSTANCE 0",
> > };
> > @@ -48,14 +49,23 @@ static const struct intel_mmio_range
> > icl_l3bank_steering_table[] = {
> > {},
> > };
> > +/*
> > + * Although the bspec lists more "MSLICE" ranges than shown here, some of
> > those
> > + * are of a "GAM" subclass that has special rules. Thus we use a separate
> > + * GAM table farther down for those.
> > + */
> > static const struct intel_mmio_range xehpsdv_mslice_steering_table[] = {
> > - { 0x004000, 0x004AFF },
> > - { 0x00C800, 0x00CFFF },
> > { 0x00DD00, 0x00DDFF },
> > { 0x00E900, 0x00 }, /* 0xEA00 - OxEFFF is unused */
> > {},
> > };
> > +static const struct intel_mmio_range xehpsdv_gam_steering_table[] = {
> > + { 0x004000, 0x004AFF },
> > + { 0x00C800, 0x00CFFF },
> > + {},
> > +};
> > +
> > static const struct intel_mmio_range xehpsdv_lncf_steering_table[] = {
> > { 0x00B000, 0x00B0FF },
> > { 0x00D800, 0x00D8FF },
> > @@ -114,9 +124,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> > } else if (IS_DG2(i915)) {
> > gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
> > gt->steering_table[LNCF] = dg2_lncf_steering_table;
> > + /*
> > +* No need to hook up the GAM table since it has a dedicated
> > +* steering control register on DG2 and can use implicit
> > +* steering.
> > +*/
> > } else if (IS_XEHPSDV(i915)) {
> > gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
> > gt->steering_table[LNCF] = xehpsdv_lncf_steering_table;
> > + gt->steering_table[GAM] = xehpsdv_gam_steering_table;
> > } else if (GRAPHICS_VER(i915) >= 11 &&
> >GRAPHICS_VER_FULL(i915) < IP_VER(12, 50)) {
> > gt->steering_table[L3BANK] = icl_l3bank_steering_table;
> > @@ -351,6 +367,10 @@ static void get_nonterminated_steering(struct intel_gt
> > *gt,
> > *group = __ffs(gt->info.mslice_mask) << 1;
> > *instance = 0; /* unused */
> > break;
> > + case GAM:
> > + *group = IS_DG2(gt->i915) ? 1 : 0;
> > + *instance = 0;
> > + break;
> > case INSTANCE0:
> > /*
> > * There are a lot of MCR types for which instance (0, 0)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 2275ee47da95..2343b26e0e21 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -42,6 +42,7 @@
> > #define MCFG_MCR_SELECTOR _MMIO(0xfd0)
> > #define
[PATCH] drm: make DRM_DEBUG_MODESET_LOCK depend on DRM
If DEBUG_KERNEL is selected with a kernel build without DRM, Kconfig still asks if DRM_DEBUG_MODESET_LOCK is to be selected or not, although this has no influence on the kernel without DRM. Make DRM_DEBUG_MODESET_LOCK depend on DRM to avoid needless questions during kernel build configuration. Signed-off-by: Lukas Bulwahn --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 198ba846d34b..393d6da0d0f7 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -96,6 +96,7 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS config DRM_DEBUG_MODESET_LOCK bool "Enable backtrace history for lock contention" + depends on DRM depends on STACKTRACE_SUPPORT depends on DEBUG_KERNEL depends on EXPERT -- 2.17.1
Re: [git pull] drm fixes for v6.0-rc6
The pull request you sent on Fri, 16 Sep 2022 18:28:58 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-09-16 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5763d7f29652f94bdfc9dab87888f79ba6bb6c34 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [Intel-gfx] [PATCH v3 01/37] drm/i915: fix kernel-doc trivial warnings on i915/*.[ch] files
On 9/9/22 10:34 AM, Mauro Carvalho Chehab wrote: There are several trivial warnings there, due to trivial things: - lack of function name at the kerneldoc markup; - renamed functions; - wrong parameter syntax. Fix such warnings: drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'active' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fence' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fn' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'active' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'rq' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or member 'active' not described in 'i915_active_fence_get' drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or member 'active' not described in 'i915_active_fence_isset' drivers/gpu/drm/i915/i915_gem.c:443: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Reads data from the object referenced by handle. drivers/gpu/drm/i915/i915_gem.c:532: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * This is the fast pwrite path, where we copy the data directly from the drivers/gpu/drm/i915/i915_gem.c:717: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Writes data to the object referenced by handle. drivers/gpu/drm/i915/i915_gem.c:802: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Called when user space has done writes to this buffer drivers/gpu/drm/i915/i915_pmu.h:22: warning: cannot understand function prototype: 'enum i915_pmu_tracked_events ' drivers/gpu/drm/i915/i915_pmu.h:33: warning: cannot understand function prototype: 'enum ' drivers/gpu/drm/i915/i915_pmu.h:42: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * How many different events we track in the global PMU mask. drivers/gpu/drm/i915/i915_request.h:177: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Request queue structure. drivers/gpu/drm/i915/i915_request.h:473: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Returns true if seq1 is later than seq2. drivers/gpu/drm/i915/i915_scatterlist.c:63: warning: Function parameter or member 'size' not described in 'i915_refct_sgt_init' drivers/gpu/drm/i915/i915_scatterlist.h:153: warning: Incorrect use of kernel-doc format: * release() - Free the memory of the struct i915_refct_sgt drivers/gpu/drm/i915/i915_scatterlist.h:157: warning: Function parameter or member 'release' not described in 'i915_refct_sgt_ops' drivers/gpu/drm/i915/i915_scatterlist.h:180: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_put' drivers/gpu/drm/i915/i915_scatterlist.h:191: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_get' drivers/gpu/drm/i915/i915_scatterlist.h:207: warning: Function parameter or member 'rsgt' not described in '__i915_refct_sgt_init' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'OP' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'COND' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'US' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'Wmin' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'Wmax' not described in '__wait_for' drivers/gpu/drm/i915/i915_vma_resource.h:88: warning: Incorrect use of kernel-doc format: * struct i915_vma_bindinfo - Information needed for async bind drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function parameter or member 'bi' not described in 'i915_vma_resource' Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at:
Re: [PATCH 1/3] drm/scheduler: track GPU active time per entity
On 2022-09-16 05:12, Lucas Stach wrote:
Am Donnerstag, dem 08.09.2022 um 14:33 -0400 schrieb Andrey Grodzovsky:
On 2022-09-08 14:10, Lucas Stach wrote:
Track the accumulated time that jobs from this entity were active
on the GPU. This allows drivers using the scheduler to trivially
implement the DRM fdinfo when the hardware doesn't provide more
specific information than signalling job completion anyways.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/scheduler/sched_main.c | 6 ++
include/drm/gpu_scheduler.h| 7 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 76fd2904c7c6..24c77a6a157f 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -847,6 +847,12 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched)
spin_unlock(>job_list_lock);
+ if (job) {
+ job->entity->elapsed_ns += ktime_to_ns(
+ ktime_sub(job->s_fence->finished.timestamp,
+ job->s_fence->scheduled.timestamp));
+ }
+
return job;
Looks like you making as assumption that drm_sched_entity will always be
allocated using kzalloc ? Isn't it a bit dangerous assumption ?
No, drm_sched_entity_init() memsets the whole struct to 0 before
initializing any members that need more specific init values.
Regards,
Lucas
Missed the memset, in that case Reviewed-by: Andrey Grodzovsky
I assume you can push that change yourself with the rest of your patchset ?
Andrey
Andrey
}
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index addb135eeea6..573bef640664 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -196,6 +196,13 @@ struct drm_sched_entity {
* drm_sched_entity_fini().
*/
struct completion entity_idle;
+ /**
+* @elapsed_ns
+*
+* Records the amount of time where jobs from this entity were active
+* on the GPU.
+*/
+ uint64_t elapsed_ns;
};
/**
Re: [Intel-gfx] [PATCH v3 02/37] drm/i915: display: fix kernel-doc markup warnings
Looks good to me. Reviewed-by: Gwan-gyeong Mun On 9/9/22 10:34 AM, Mauro Carvalho Chehab wrote: There are a couple of issues at i915 display kernel-doc markups: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: Function parameter or member 'intel_connector' not described in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: Excess function parameter 'connector' description in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_power.c:700: warning: expecting prototype for intel_display_power_put_async(). Prototype was for __intel_display_power_put_async() instead drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Function parameter or member 'work' not described in 'intel_tc_port_disconnect_phy_work' drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Excess function parameter 'dig_port' description in 'intel_tc_port_disconnect_phy_work' Those are due to wrong parameter of function name. Address them. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +- drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/display/intel_tc.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index 5dc364e9db49..e8433aa50905 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -2232,7 +2232,7 @@ DEFINE_SHOW_ATTRIBUTE(i915_current_bpc); /** * intel_connector_debugfs_add - add i915 specific connector debugfs files - * @connector: pointer to a registered drm_connector + * @intel_connector: pointer to a registered drm_connector * * Cleanup will be done by drm_connector_unregister() through a call to * drm_debugfs_connector_remove(). diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 1af1705d730d..b080d65d4461 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -686,7 +686,7 @@ intel_display_power_put_async_work(struct work_struct *work) } /** - * intel_display_power_put_async - release a power domain reference asynchronously + * __intel_display_power_put_async - release a power domain reference asynchronously * @i915: i915 device instance * @domain: power domain to reference * @wakeref: wakeref acquired for the reference that is being released diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c index e5af955b5600..10cda362537e 100644 --- a/drivers/gpu/drm/i915/display/intel_tc.c +++ b/drivers/gpu/drm/i915/display/intel_tc.c @@ -797,7 +797,7 @@ void intel_tc_port_lock(struct intel_digital_port *dig_port) /** * intel_tc_port_disconnect_phy_work: disconnect TypeC PHY from display port - * @dig_port: digital port + * @work: workqueue struct * * Disconnect the given digital port from its TypeC PHY (handing back the * control of the PHY to the TypeC subsystem). This will happen in a delayed
Re: [PATCH v1 3/4] drm/i915: Split i915_gem_init_stolen()
On 16-09-2022 02:09, Lucas De Marchi wrote:
> Add some helpers: adjust_stolen(), request_smem_stolen_() and
> init_reserved_stolen() that are now called by i915_gem_init_stolen() to
> initialize each part of the Data Stolen Memory region. Main goal is to
> split the reserved part, also known as WOPCM, as its calculation changes
> often per platform.
>
> This also fixes a bug in graphics version < 5 (in theory, not tested,
> due to no machine available): it would bail out on stolen creation due
> to "Stolen reserved area outside stolen memory". Other than that, no
> change in behavior.
>
> Signed-off-by: Lucas De Marchi
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index c34065fe2ecc..0e57a6d81534 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -77,22 +77,26 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
> *i915,
> mutex_unlock(>mm.stolen_lock);
> }
>
> -static int i915_adjust_stolen(struct drm_i915_private *i915,
> - struct resource *dsm)
> +static bool valid_stolen_size(struct resource *dsm)
> +{
> + return dsm->start != 0 && dsm->end > dsm->start;
> +}
> +
> +static int adjust_stolen(struct drm_i915_private *i915,
> + struct resource *dsm)
> {
> struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> - struct resource *r;
>
> - if (dsm->start == 0 || dsm->end <= dsm->start)
> + if (!valid_stolen_size(dsm))
> return -EINVAL;
>
> /*
> + * Make sure we don't clobber the GTT if it's within stolen memory
> + *
>* TODO: We have yet too encounter the case where the GTT wasn't at the
>* end of stolen. With that assumption we could simplify this.
>*/
> -
> - /* Make sure we don't clobber the GTT if it's within stolen memory */
> if (GRAPHICS_VER(i915) <= 4 &&
> !IS_G33(i915) && !IS_PINEVIEW(i915) && !IS_G4X(i915)) {
> struct resource stolen[2] = {*dsm, *dsm};
> @@ -131,10 +135,20 @@ static int i915_adjust_stolen(struct drm_i915_private
> *i915,
> }
> }
>
> + if (!valid_stolen_size(dsm))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int request_smem_stolen(struct drm_i915_private *i915,
> +struct resource *dsm)
> +{
> + struct resource *r;
> +
> /*
> - * With stolen lmem, we don't need to check if the address range
> - * overlaps with the non-stolen system memory range, since lmem is local
> - * to the gpu.
> + * With stolen lmem, we don't need to request if the address range
replace /if/for
> + * since lmem is local to the gpu.
>*/
> if (HAS_LMEM(i915))
> return 0;
> @@ -392,39 +406,22 @@ static void icl_get_stolen_reserved(struct
> drm_i915_private *i915,
> }
> }
>
> -static int i915_gem_init_stolen(struct intel_memory_region *mem)
> +/*
> + * Initialize i915->dsm_reserved to contain the reserved space within the
> Data
> + * Stolen Memory. This is a range on the top of DSM that is reserved, not to
> + * be used by driver, so must be excluded from the region passed to the
> + * allocator later. In the spec this is also called as WOPCM.
> + *
> + * Our expectation is that the reserved space is at the top of the stolen
> + * region, as it has been the case for every platform, and *never* at the
> + * bottom, so the calculation here can be simplified.
> + */
> +static int init_reserved_stolen(struct drm_i915_private *i915)
> {
> - struct drm_i915_private *i915 = mem->i915;
> struct intel_uncore *uncore = >uncore;
> resource_size_t reserved_base, stolen_top;
> - resource_size_t reserved_total, reserved_size;
> -
> - mutex_init(>mm.stolen_lock);
> -
> - if (intel_vgpu_active(i915)) {
> - drm_notice(>drm,
> -"%s, disabling use of stolen memory\n",
> -"iGVT-g active");
> - return 0;
> - }
> -
> - if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
> - drm_notice(>drm,
> -"%s, disabling use of stolen memory\n",
> -"DMAR active");
> - return 0;
> - }
> -
> - if (resource_size(>region) == 0)
> - return 0;
> -
> - if (i915_adjust_stolen(i915, >region))
> - return 0;
> -
> - GEM_BUG_ON(i915->dsm.start == 0);
> - GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
> -
> - i915->dsm = mem->region;
> + resource_size_t reserved_size;
> + int ret = 0;
>
> stolen_top = i915->dsm.end + 1;
> reserved_base = stolen_top;
> @@ -453,19 +450,17 @@ static int i915_gem_init_stolen(struct
> intel_memory_region *mem)
> } else if (GRAPHICS_VER(i915) >= 5 || IS_G4X(i915)) {
Re: [PATCH 3/3] drm/etnaviv: export client GPU usage statistics via fdinfo
On 16/09/2022 10:50, Lucas Stach wrote:
Hi Tvrtko,
Am Freitag, dem 16.09.2022 um 10:31 +0100 schrieb Tvrtko Ursulin:
Hi Lucas,
On 08/09/2022 19:10, Lucas Stach wrote:
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index b69edb40ae2a..11b1f11fcb58 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -22,6 +22,7 @@
#include "etnaviv_gem.h"
#include "etnaviv_mmu.h"
#include "etnaviv_perfmon.h"
+#include "common.xml.h"
/*
* DRM operations:
@@ -471,7 +472,42 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_RENDER_ALLOW),
};
-DEFINE_DRM_GEM_FOPS(fops);
+static void etnaviv_fop_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct drm_file *file = f->private_data;
+ struct drm_device *dev = file->minor->dev;
+ struct etnaviv_drm_private *priv = dev->dev_private;
+ struct etnaviv_file_private *ctx = file->driver_priv;
+ struct drm_printer p = drm_seq_file_printer(m);
Any specific reason not to use seq_printf directly? (May be my ignorance.)
Not really, I just followed what msm was doing here.
Right, no strong feelings either way I just did not see the need to wrap
it for this use case.
+ int i;
+
+ drm_printf(, "drm-driver:\t%s\n", dev->driver->name);
+ drm_printf(, "drm-client-id:\t%u\n", ctx->id);
+
+ for (i = 0; i < ETNA_MAX_PIPES; i++) {
+struct etnaviv_gpu *gpu = priv->gpu[i];
+ char engine[8];
+ int cur = 0;
Alignment renders odd in my client.
I'll check that, might have messed up here.
+
+ if (!gpu)
+ continue;
I'd stick a comment in here to the effect of "For text output format
description please see drm-usage-stats.rst!".
Just to leave a breadcrumb putting some restraint on adding vendor
specific things which may be already covered by the common spec. To help
with common tools in the future as much as possible.
Yea, it was pretty to clear to me that we want the common format as
much as possible when writing the patches, but it's a good idea to add
a pointer for the future reader.
Thanks!
+
+ if (gpu->identity.features & chipFeatures_PIPE_2D)
+ cur = snprintf(engine, sizeof(engine), "2D");
+ if (gpu->identity.features & chipFeatures_PIPE_3D)
+ cur = snprintf(engine + cur, sizeof(engine) - cur,
+ "%s3D", cur ? "/" : "");
+
+ drm_printf(, "drm-engine-%s:\t%llu ns\n", engine,
+ ctx->sched_entity[i].elapsed_ns);
Two questions:
1)
So you have max four pipes, each can be either only 2d, 3d, or 2d/3d?
Can you have multiple of the same like 2x 3D? If you do, have you
considered exporting one drm-engine-% together with drm-engine-capacity-
for it?
The four pipes is a arbitrary driver limit. Etnaviv is a bit special in
that it collects all Vivante GPUs present in a system into a single DRM
device, each of those GPUs can be either 2D, 3D or a combined core with
both 2D and 3D capabilities. In theory there could be multiple GPUs of
each kind, but for now all real SoC designs we've come across only had
a single one of each kind.
When we add support for a SoC that has multiple GPUs of one kind, I
think exposing drm-engine-capacity, together with hooking them up to
the load balancing in the scheduler is the right thing to do.
2)
Have you tried my, yet unmerged, vendor agnostic gputop tool with your
changes?
https://patchwork.freedesktop.org/series/102175/
It would be interesting to know if it works.
Yes, I did when working on this series. I had some crashes related to
(I believe) double frees in the DRM client discovery, which I hadn't
had time to investigate further. Seems there is a race, as I couldn't
reproduce the crash when running with valgrind.
Other than that, the tool works for exposing the per-client GPU load on
etnaviv.
Cool, at least some success.
Out of curiosity what is the planned consumer in etnaviv landscape?
Regards,
Tvrtko
[PULL] drm-intel-next
Hi Dave & Daniel - The final feature pull for v6.1. drm-intel-next-2022-09-16-1: drm/i915 feature pull #2 for v6.1: Features and functionality: - More Meteorlake platform enabling (Radhakrishna, Imre, Madhumitha) - Allow seamless M/N changes on eDP panels that support it (Ville) - Switch DSC debugfs from output bpp to input bpc (Swati) Refactoring and cleanups: - Clocking and DPLL refactoring and cleanups to support seamless M/N (Ville) - Plenty of VBT definition and parsing updates and cleanups (Ville) - Extract SKL watermark code to a separate file, and clean up (Ville) - Clean up IPC interfaces and debugfs (Jani) - Continue moving display data under drm_i915_private display sub-struct (Jani) - Display quirk handling refactoring and abstractions (Jani) - Stop using implicit dev_priv in gmbus registers (Jani) - BUG_ON() removals and conversions to drm_WARN_ON() and BUILD_BUG_ON() (Jani) - Use drm_dp_phy_name() for logging (Jani) - Use REG_BIT() macros for CDCLK registers (Stan) - Move display and media IP versions to runtime info (Radhakrishna) Fixes: - Fix DP MST suspend to avoid use-after-free (Andrzej) - Fix HPD suspend to avoid use-after-free for fbdev (Andrzej) - Fix various PSR issues regarding selective update and damage clips (Jouni) - Fix runtime pm wakerefs for driver remove and release (Mitul Golani) - Fix conditions for filtering fixed modes for panels (Ville) - Fix TV encoder clock computation (Ville) - Fix dvo mode_valid hook return type (Nathan Huckleberry) Merges: - Backmerge drm-next to sync the DP MST atomic changes (Jani) BR, Jani. The following changes since commit 89b03aeaef16f8ab48c10c399f97c836bdbae838: drm/vkms: fix 32bit compilation error by replacing macros (2022-09-11 22:28:56 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2022-09-16-1 for you to fetch changes up to 21f0b7dabf9c358e75a539b5554c0375bf1abe0a: drm/i915: Fix return type of mode_valid function hook (2022-09-15 10:28:55 +0300) drm/i915 feature pull #2 for v6.1: Features and functionality: - More Meteorlake platform enabling (Radhakrishna, Imre, Madhumitha) - Allow seamless M/N changes on eDP panels that support it (Ville) - Switch DSC debugfs from output bpp to input bpc (Swati) Refactoring and cleanups: - Clocking and DPLL refactoring and cleanups to support seamless M/N (Ville) - Plenty of VBT definition and parsing updates and cleanups (Ville) - Extract SKL watermark code to a separate file, and clean up (Ville) - Clean up IPC interfaces and debugfs (Jani) - Continue moving display data under drm_i915_private display sub-struct (Jani) - Display quirk handling refactoring and abstractions (Jani) - Stop using implicit dev_priv in gmbus registers (Jani) - BUG_ON() removals and conversions to drm_WARN_ON() and BUILD_BUG_ON() (Jani) - Use drm_dp_phy_name() for logging (Jani) - Use REG_BIT() macros for CDCLK registers (Stan) - Move display and media IP versions to runtime info (Radhakrishna) Fixes: - Fix DP MST suspend to avoid use-after-free (Andrzej) - Fix HPD suspend to avoid use-after-free for fbdev (Andrzej) - Fix various PSR issues regarding selective update and damage clips (Jouni) - Fix runtime pm wakerefs for driver remove and release (Mitul Golani) - Fix conditions for filtering fixed modes for panels (Ville) - Fix TV encoder clock computation (Ville) - Fix dvo mode_valid hook return type (Nathan Huckleberry) Merges: - Backmerge drm-next to sync the DP MST atomic changes (Jani) Andrzej Hajda (3): drm/i915/hpd: suspend MST at the end of intel_modeset_driver_remove drm/i915/fbdev: suspend HPD before fbdev unregistration drm/i915/fbdev: do not create fbdev if HPD is suspended Ankit Nautiyal (1): drm/i915/vdsc: Set VDSC PIC_HEIGHT before using for DP DSC Imre Deak (2): drm/i915/mtl: Add display power wells drm/i915/mtl: Add DP AUX support on TypeC ports Jani Nikula (46): drm/i915: move and group hdcp under display.hdcp drm/i915: move and group max_bw and bw_obj under display.bw drm/i915: move opregion to display.opregion drm/i915: move and group cdclk under display.cdclk drm/i915: move backlight to display.backlight drm/i915: move mipi_mmio_base to display.dsi drm/i915: move vbt to display.vbt drm/i915: move fbc to display.fbc drm/i915: move and group power related members under display.power drm/i915: move and group fdi members under display.fdi drm/i915: move fb_tracking under display sub-struct drm/i915: move dbuf under display sub-struct drm/i915: move and group modeset_wq and flip_wq under display.wq drm/i915/quirks: abstract checking for display quirks drm/i915/quirks: abstract quirks further by making quirk ids an enum drm/i915: move quirks under display
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gem: Really move i915_gem_context.link under ref protection
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 12:24 PM, Janusz Krzysztofik wrote:
From: Chris Wilson
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the list during context_close(), the link.next pointer may
be poisoned while we are holding the context reference and cause a GPF:
[ 4070.573157] i915 :00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering
on ctx_id=0x1f ctx_id_mask=0x1f
[ 4070.574881] general protection fault, probably for non-canonical address
0xdead0100: [#1] PREEMPT SMP
[ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: GE
5.17.9 #180
[ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS
BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]
[ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41
0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48
8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff
[ 4070.574990] RSP: 0018:c90002077b78 EFLAGS: 00010202
[ 4070.574995] RAX: 0002 RBX: 0002 RCX:
[ 4070.575000] RDX: 0001 RSI: c90002077b20 RDI: 88810ddc7c68
[ 4070.575004] RBP: 0001 R08: 888103242648 R09: fffc
[ 4070.575008] R10: 82c50bc0 R11: 00025c80 R12: 888101bf1860
[ 4070.575012] R13: dead00b0 R14: c90002077c04 R15: 88810be5cabc
[ 4070.575016] FS: 7f1ed50c0780() GS:5ec8()
knlGS:
[ 4070.575021] CS: 0010 DS: ES: CR0: 80050033
[ 4070.575025] CR2: 7f1ed5590280 CR3: 00010ef6f005 CR4: 003706e0
[ 4070.575029] Call Trace:
[ 4070.575033]
[ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915]
[ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915]
[ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915]
[ 4070.575224] ? asm_common_interrupt+0x1e/0x40
[ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575290] drm_ioctl_kernel+0x85/0x110
[ 4070.575296] ? update_load_avg+0x5f/0x5e0
[ 4070.575302] drm_ioctl+0x1d3/0x370
[ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915]
[ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0
[ 4070.575451] ? __do_softirq+0xaa/0x1d2
[ 4070.575456] do_syscall_64+0x35/0x80
[ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 4070.575467] RIP: 0033:0x7f1ed5c10397
[ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c
89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48
[ 4070.575478] RSP: 002b:7ffd65c8d7a8 EFLAGS: 0246 ORIG_RAX:
0010
[ 4070.575484] RAX: ffda RBX: 0006 RCX: 7f1ed5c10397
[ 4070.575488] RDX: 7ffd65c8d7c0 RSI: 40106476 RDI: 0006
[ 4070.575492] RBP: 5620972f9c60 R08: 000a R09: 0005
[ 4070.575496] R10: 000d R11: 0246 R12: 000a
[ 4070.575500] R13: 000d R14: R15: 7ffd65c8d7c0
[ 4070.575505]
[ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E)
i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E)
crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E)
cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E)
syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E)
sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E)
i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E)
[ 4070.575549] ---[ end trace ]---
v3: fix incorrect syntax of spin_lock() replacing spin_lock_irqsave()
v2: irqsave not required in a worker, neither conversion to irq safe
elsewhere (Tvrtko),
- perf: it's safe to call gen8_configure_context() even if context has
been closed, no need to check,
- drop unrelated cleanup (Andi, Tvrtko)
Reported-by: Mark Janes
Closes: https://gitlab.freedesktop.org/drm/intel/issues/6222
References: a4e7ccdac38e ("drm/i915: Move context management under GEM")
Fixes: f8246cf4d9a9 ("drm/i915/gem: Drop free_work for GEM contexts")
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
Signed-off-by: Janusz Krzysztofik
Cc: Tvrtko Ursulin
Cc: # v5.12+
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gem: Flush contexts on driver release
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 12:24 PM, Janusz Krzysztofik wrote:
Due to i915_perf assuming that it can use the i915_gem_context reference
to protect its i915->gem.contexts.list iteration, we need to defer removal
of the context from the list until last reference to the context is put.
However, there is a risk of triggering kernel warning on contexts list not
empty at driver release time if we deleagate that task to a worker for
i915_gem_context_release_work(), unless that work is flushed first.
Unfortunately, it is not flushed on driver release. Fix it.
Instead of additionally calling flush_workqueue(), either directly or via
a new dedicated wrapper around it, replace last call to
i915_gem_drain_freed_objects() with existing i915_gem_drain_workqueue()
that performs both tasks.
Fixes: 75eefd82581f ("drm/i915: Release i915_gem_context from a worker")
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Andi Shyti
Cc: sta...@kernel.org # v5.16+
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c8e14ed9c2a96..172c29a15f118 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1195,7 +1195,8 @@ void i915_gem_driver_release(struct drm_i915_private
*dev_priv)
intel_uc_cleanup_firmwares(_gt(dev_priv)->uc);
- i915_gem_drain_freed_objects(dev_priv);
+ /* Flush any outstanding work, including i915_gem_context.release_work.
*/
+ i915_gem_drain_workqueue(dev_priv);
drm_WARN_ON(_priv->drm, !list_empty(_priv->gem.contexts.list));
}
Re: [PATCH v1 2/4] drm/i915: Add missing mask when reading GEN12_DSMBASE
On 16-09-2022 02:09, Lucas De Marchi wrote:
> DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
> of the base address of stolen. For the supported platforms bits 0-19 are
> zero but that may not be true in future. Add the missing mask.
>
> Signed-off-by: Lucas De Marchi
Acked-by: Aravind Iddamsetty
Thanks,
Aravind.
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 42f4769bb4ac..c34065fe2ecc 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -814,7 +814,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
> u16 type,
> return ERR_PTR(-ENXIO);
>
> /* Use DSM base address instead for stolen memory */
> - dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
> + dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & GEN12_BDSM_MASK;
> if (IS_DG1(uncore->i915)) {
> lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
> if (WARN_ON(lmem_size < dsm_base))
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1a9bd829fc7e..0301874c76ba 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7953,6 +7953,7 @@ enum skl_power_gate {
>
> #define GEN12_GSMBASE_MMIO(0x108100)
> #define GEN12_DSMBASE_MMIO(0x1080C0)
> +#define GEN12_BDSM_MASKGENMASK(63, 20)
>
> #define XEHP_CLOCK_GATE_DIS _MMIO(0x101014)
> #define SGSI_SIDECLK_DIS REG_BIT(17)
>
Re: [PATCH v1 1/4] drm/i915: Move dsm assignment to be after adjustment
On 16-09-2022 02:09, Lucas De Marchi wrote: > Reduce possible side effects of assigning the region and bailing out due > to errors. > > Signed-off-by: Lucas De Marchi > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > index acc561c0f0aa..42f4769bb4ac 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > @@ -418,14 +418,14 @@ static int i915_gem_init_stolen(struct > intel_memory_region *mem) > if (resource_size(>region) == 0) > return 0; > > - i915->dsm = mem->region; > - > - if (i915_adjust_stolen(i915, >dsm)) > + if (i915_adjust_stolen(i915, >region)) > return 0; > > GEM_BUG_ON(i915->dsm.start == 0); > GEM_BUG_ON(i915->dsm.end <= i915->dsm.start); > > + i915->dsm = mem->region; assignment should be above the GEM_BUG_ON. but why don't you squash this into 3rd patch thanks, Aravind. > + > stolen_top = i915->dsm.end + 1; > reserved_base = stolen_top; > reserved_size = 0; >
Re: [PATCH 2/4] drm/plane: Allocate planes with drm_universal_plane_alloc()
On 9/16/22 13:41, Thomas Zimmermann wrote:
[...]
>>
>>> + * @dev: DRM device
>>> + * @type: the type of the struct which contains struct _plane
>>> + * @member: the name of the _plane within @type
>>> + * @possible_crtcs: bitmask of possible CRTCs
>>> + * @funcs: callbacks for the new plane
>>> + * @formats: array of supported formats (DRM_FORMAT\_\*)
>>> + * @format_count: number of elements in @formats
>>> + * @format_modifiers: array of struct drm_format modifiers terminated by
>>> + *DRM_FORMAT_MOD_INVALID
>>> + * @plane_type: type of plane (overlay, primary, cursor)
>>> + * @name: printf style format string for the plane name, or NULL for
>>> default name
>>> + *
>>> + * Allocates and initializes a plane object of type @type. The caller
>>> + * is responsible for releasing the allocated memory with kfree().
>>> + *
>>
>> I thought that all the drmm_*_alloc() managed interfaces should use the
>> drmm_k{z,m}alloc() helpers, so that the memory is automatically freed
>> on the last drm_dev_put() call ?
>
> For new drivers, managed cleanup is preferred. But this is an existing
> unmanaged cleanup.
>
> I don't know if drmm_ changes the semantics in unexpected ways (well,
> probably not). With managed memory releases, I was worried that plane
> memory might stay around longer than expected. And we'd have to fix the
> plane-destroy function in each user as well.
>
> Adding the existing code as a new function is the trivial solution and
> allows to address each driver individually. Also see my reply to
> Laurent's question on that topic.
>
Ah, never mind. I misread the function name definition and thought that
you had a drmm_ suffix but, now on second read I see that is only drm_
so just ignore my comment about using managed memory alloc / release.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH 2/4] drm/plane: Allocate planes with drm_universal_plane_alloc()
Hi
Am 16.09.22 um 13:22 schrieb Javier Martinez Canillas:
On 9/9/22 12:59, Thomas Zimmermann wrote:
Provide drm_univeral_plane_alloc(), which allocated an initializes a
plane. Code for non-atomic drivers uses this pattern. Convert it to
the new function. The modeset helpers contain a quirk for handling their
color formats differently. Set the flag outside plane allocation.
The new function is already deprecated to some extend. Drivers should
rather use drmm_univeral_plane_alloc() or drm_universal_plane_init().
Signed-off-by: Thomas Zimmermann
---
[...]
+__printf(10, 11)
+void *__drm_universal_plane_alloc(struct drm_device *dev,
+ size_t size, size_t offset,
+ uint32_t possible_crtcs,
+ const struct drm_plane_funcs *funcs,
+ const uint32_t *formats,
+ unsigned int format_count,
+ const uint64_t *format_modifiers,
+ enum drm_plane_type plane_type,
+ const char *name, ...);
+
+/**
+ * drm_universal_plane_alloc - Allocate and initialize an universal plane
object
Should functions kernel-doc definitions use parenthesis or not? I see in
https://elixir.bootlin.com/linux/latest/source/Documentation/doc-guide/kernel-doc.rst#L59
that the example has it but notice that there is not consistency in DRM
about this.
A wasn't aware of this convention.
+ * @dev: DRM device
+ * @type: the type of the struct which contains struct _plane
+ * @member: the name of the _plane within @type
+ * @possible_crtcs: bitmask of possible CRTCs
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
+ * @format_count: number of elements in @formats
+ * @format_modifiers: array of struct drm_format modifiers terminated by
+ *DRM_FORMAT_MOD_INVALID
+ * @plane_type: type of plane (overlay, primary, cursor)
+ * @name: printf style format string for the plane name, or NULL for default
name
+ *
+ * Allocates and initializes a plane object of type @type. The caller
+ * is responsible for releasing the allocated memory with kfree().
+ *
I thought that all the drmm_*_alloc() managed interfaces should use the
drmm_k{z,m}alloc() helpers, so that the memory is automatically freed
on the last drm_dev_put() call ?
For new drivers, managed cleanup is preferred. But this is an existing
unmanaged cleanup.
I don't know if drmm_ changes the semantics in unexpected ways (well,
probably not). With managed memory releases, I was worried that plane
memory might stay around longer than expected. And we'd have to fix the
plane-destroy function in each user as well.
Adding the existing code as a new function is the trivial solution and
allows to address each driver individually. Also see my reply to
Laurent's question on that topic.
Best regards
Thomas
Other than those two nits, the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 2/4] drm/plane: Allocate planes with drm_universal_plane_alloc()
Hi
Am 16.09.22 um 13:06 schrieb Laurent Pinchart:
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:45PM +0200, Thomas Zimmermann wrote:
Provide drm_univeral_plane_alloc(), which allocated an initializes a
plane. Code for non-atomic drivers uses this pattern. Convert it to
the new function. The modeset helpers contain a quirk for handling their
color formats differently. Set the flag outside plane allocation.
The new function is already deprecated to some extend. Drivers should
rather use drmm_univeral_plane_alloc() or drm_universal_plane_init().
If this is already deprecated and used by a single driver, what is the
point ?
It's used by nouveau and drm_modeset_helper.c. Since the code is
duplicated, it seems generally better to have it located and documented
in a central place.
Although it may look somewhat pointless now, the helper will get useful
in the future. The affected code in drm_modeset_helper is in
drm_crtc_init(), which is also a deprecated interface; only used by
non-atomic drivers. The function is a good candidate to be inlined into
calling drivers. Getting drm_crtc_init() removed will allow us to
correct these drivers' color-format handling. Once that happened,
several more drivers will call drm_univeral_plane_alloc().
Best regards
Thomas
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_modeset_helper.c| 61 +++--
drivers/gpu/drm/drm_plane.c | 38 +++
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 41 ++---
include/drm/drm_plane.h | 44 ++
4 files changed, 121 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/drm_modeset_helper.c
b/drivers/gpu/drm/drm_modeset_helper.c
index 611dd01fb604..38040eebfa16 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -113,38 +113,6 @@ static const struct drm_plane_funcs primary_plane_funcs = {
.destroy = drm_plane_helper_destroy,
};
-static struct drm_plane *create_primary_plane(struct drm_device *dev)
-{
- struct drm_plane *primary;
- int ret;
-
- primary = kzalloc(sizeof(*primary), GFP_KERNEL);
- if (primary == NULL) {
- DRM_DEBUG_KMS("Failed to allocate primary plane\n");
- return NULL;
- }
-
- /*
-* Remove the format_default field from drm_plane when dropping
-* this helper.
-*/
- primary->format_default = true;
-
- /* possible_crtc's will be filled in later by crtc_init */
- ret = drm_universal_plane_init(dev, primary, 0,
- _plane_funcs,
- safe_modeset_formats,
- ARRAY_SIZE(safe_modeset_formats),
- NULL,
- DRM_PLANE_TYPE_PRIMARY, NULL);
- if (ret) {
- kfree(primary);
- primary = NULL;
- }
-
- return primary;
-}
-
/**
* drm_crtc_init - Legacy CRTC initialization function
* @dev: DRM device
@@ -176,10 +144,33 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
const struct drm_crtc_funcs *funcs)
{
struct drm_plane *primary;
+ int ret;
+
+ /* possible_crtc's will be filled in later by crtc_init */
+ primary = __drm_universal_plane_alloc(dev, sizeof(*primary), 0, 0,
+ _plane_funcs,
+ safe_modeset_formats,
+ ARRAY_SIZE(safe_modeset_formats),
+ NULL, DRM_PLANE_TYPE_PRIMARY,
NULL);
+ if (IS_ERR(primary))
+ return PTR_ERR(primary);
- primary = create_primary_plane(dev);
- return drm_crtc_init_with_planes(dev, crtc, primary, NULL, funcs,
-NULL);
+ /*
+* Remove the format_default field from drm_plane when dropping
+* this helper.
+*/
+ primary->format_default = true;
+
+ ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL, funcs, NULL);
+ if (ret)
+ goto err_drm_plane_cleanup;
+
+ return 0;
+
+err_drm_plane_cleanup:
+ drm_plane_cleanup(primary);
+ kfree(primary);
+ return ret;
}
EXPORT_SYMBOL(drm_crtc_init);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 0f14b4d3bb10..33357629a7f5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -448,6 +448,44 @@ void *__drmm_universal_plane_alloc(struct drm_device *dev,
size_t size,
}
EXPORT_SYMBOL(__drmm_universal_plane_alloc);
+void *__drm_universal_plane_alloc(struct drm_device *dev, size_t size,
+ size_t offset, uint32_t possible_crtcs,
+ const
Re: [PATCH 4/4] drm/plane-helper: Provide DRM_PLANE_NON_ATOMIC_FUNCS initializer macro
On 9/9/22 12:59, Thomas Zimmermann wrote: > Provide DRM_PLANE_NON_ATOMIC_FUNCS, which initializes plane functions > of non-atomic drivers to default values. The macro is not supposed to > be used in new code, but helps with documenting and finding existing > users. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 3/4] drm/plane-helper: Warn if atomic drivers call non-atomic helpers
On 9/9/22 12:59, Thomas Zimmermann wrote: > The plane update and disable helpers are only useful for non-atomic > drivers. Print a warning if an atomic driver calls them. > > Suggested-by: Daniel Vetter > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v2] drm/etnaviv: don't truncate physical page address
On Fr, 2022-09-16 at 12:40 +0200, Lucas Stach wrote:
> While the interface for the MMU mapping takes phys_addr_t to hold a
> full 64bit address when necessary and MMUv2 is able to map physical
> addresses with up to 40bit, etnaviv_iommu_map() truncates the address
> to 32bits. Fix this by using the correct type.
>
> Fixes: 931e97f3afd8 ("drm/etnaviv: mmuv2: support 40 bit phys address")
> Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
regards
Philipp
Re: [PATCH 4/4] drm/plane-helper: Provide DRM_PLANE_NON_ATOMIC_FUNCS initializer macro
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:47PM +0200, Thomas Zimmermann wrote:
> Provide DRM_PLANE_NON_ATOMIC_FUNCS, which initializes plane functions
> of non-atomic drivers to default values. The macro is not supposed to
> be used in new code, but helps with documenting and finding existing
> users.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_modeset_helper.c| 4 +---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +---
> include/drm/drm_plane_helper.h | 12
> 3 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c
> index 38040eebfa16..f858dfedf2cf 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -108,9 +108,7 @@ static const uint32_t safe_modeset_formats[] = {
> };
>
> static const struct drm_plane_funcs primary_plane_funcs = {
> - .update_plane = drm_plane_helper_update_primary,
> - .disable_plane = drm_plane_helper_disable_primary,
> - .destroy = drm_plane_helper_destroy,
> + DRM_PLANE_NON_ATOMIC_FUNCS,
> };
>
> /**
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 6b8a014b5e97..ee92d576d277 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -1276,9 +1276,7 @@ static const uint32_t modeset_formats[] = {
> };
>
> static const struct drm_plane_funcs nv04_primary_plane_funcs = {
> - .update_plane = drm_plane_helper_update_primary,
> - .disable_plane = drm_plane_helper_disable_primary,
> - .destroy = drm_plane_helper_destroy,
> + DRM_PLANE_NON_ATOMIC_FUNCS,
> };
>
> static int nv04_crtc_vblank_handler(struct nvif_notify *notify)
> diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
> index 1781fab24dd6..75f9c4830564 100644
> --- a/include/drm/drm_plane_helper.h
> +++ b/include/drm/drm_plane_helper.h
> @@ -42,4 +42,16 @@ int drm_plane_helper_disable_primary(struct drm_plane
> *plane,
>struct drm_modeset_acquire_ctx *ctx);
> void drm_plane_helper_destroy(struct drm_plane *plane);
>
> +/**
> + * DRM_PLANE_NON_ATOMIC_FUNCS - Default plane functions for non-atomic
> drivers
> + *
> + * This macro initializes plane functions for non-atomic drivers to default
> + * values. Non-atomic interfaces are deprecated and should not be used in new
> + * drivers.
I wonder if we could teach checkpath.pl to catch new users.
Reviewed-by: Laurent Pinchart
> + */
> +#define DRM_PLANE_NON_ATOMIC_FUNCS \
> + .update_plane = drm_plane_helper_update_primary, \
> + .disable_plane = drm_plane_helper_disable_primary, \
> + .destroy = drm_plane_helper_destroy
> +
> #endif
--
Regards,
Laurent Pinchart
Re: [PATCH 2/4] drm/plane: Allocate planes with drm_universal_plane_alloc()
On 9/9/22 12:59, Thomas Zimmermann wrote:
> Provide drm_univeral_plane_alloc(), which allocated an initializes a
> plane. Code for non-atomic drivers uses this pattern. Convert it to
> the new function. The modeset helpers contain a quirk for handling their
> color formats differently. Set the flag outside plane allocation.
>
> The new function is already deprecated to some extend. Drivers should
> rather use drmm_univeral_plane_alloc() or drm_universal_plane_init().
>
> Signed-off-by: Thomas Zimmermann
> ---
[...]
>
> +__printf(10, 11)
> +void *__drm_universal_plane_alloc(struct drm_device *dev,
> + size_t size, size_t offset,
> + uint32_t possible_crtcs,
> + const struct drm_plane_funcs *funcs,
> + const uint32_t *formats,
> + unsigned int format_count,
> + const uint64_t *format_modifiers,
> + enum drm_plane_type plane_type,
> + const char *name, ...);
> +
> +/**
> + * drm_universal_plane_alloc - Allocate and initialize an universal plane
> object
Should functions kernel-doc definitions use parenthesis or not? I see in
https://elixir.bootlin.com/linux/latest/source/Documentation/doc-guide/kernel-doc.rst#L59
that the example has it but notice that there is not consistency in DRM
about this.
> + * @dev: DRM device
> + * @type: the type of the struct which contains struct _plane
> + * @member: the name of the _plane within @type
> + * @possible_crtcs: bitmask of possible CRTCs
> + * @funcs: callbacks for the new plane
> + * @formats: array of supported formats (DRM_FORMAT\_\*)
> + * @format_count: number of elements in @formats
> + * @format_modifiers: array of struct drm_format modifiers terminated by
> + *DRM_FORMAT_MOD_INVALID
> + * @plane_type: type of plane (overlay, primary, cursor)
> + * @name: printf style format string for the plane name, or NULL for default
> name
> + *
> + * Allocates and initializes a plane object of type @type. The caller
> + * is responsible for releasing the allocated memory with kfree().
> + *
I thought that all the drmm_*_alloc() managed interfaces should use the
drmm_k{z,m}alloc() helpers, so that the memory is automatically freed
on the last drm_dev_put() call ?
Other than those two nits, the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH 3/4] drm/plane-helper: Warn if atomic drivers call non-atomic helpers
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:46PM +0200, Thomas Zimmermann wrote:
> The plane update and disable helpers are only useful for non-atomic
> drivers. Print a warning if an atomic driver calls them.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_plane_helper.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index c7785967f5bf..1c904fc26a58 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -30,8 +30,10 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
>
> #define SUBPIXEL_MASK 0x
> @@ -195,10 +197,14 @@ int drm_plane_helper_update_primary(struct drm_plane
> *plane, struct drm_crtc *cr
> .x2 = crtc_x + crtc_w,
> .y2 = crtc_y + crtc_h,
> };
> + struct drm_device *dev = plane->dev;
> struct drm_connector **connector_list;
> int num_connectors, ret;
> bool visible;
>
> + if (drm_WARN_ON_ONCE(dev, drm_drv_uses_atomic_modeset(dev)))
> + return -EINVAL;
> +
> ret = drm_plane_helper_check_update(plane, crtc, fb,
> , ,
> DRM_MODE_ROTATE_0,
> @@ -260,6 +266,10 @@ EXPORT_SYMBOL(drm_plane_helper_update_primary);
> int drm_plane_helper_disable_primary(struct drm_plane *plane,
>struct drm_modeset_acquire_ctx *ctx)
> {
> + struct drm_device *dev = plane->dev;
> +
> + drm_WARN_ON_ONCE(dev, drm_drv_uses_atomic_modeset(dev));
> +
> return -EINVAL;
> }
> EXPORT_SYMBOL(drm_plane_helper_disable_primary);
--
Regards,
Laurent Pinchart
Re: [GIT PULL FOR v6.1] R-Car DU changes
Gentle ping. I know it's conference time, but I'd appreciate if this could be merged in time for v6.1. I also forgot to mention explicitly in the pull request that patch "media: vsp1: Add premultiplied alpha support" has Mauro's approval for merge through the DRM tree (the patch has his ack, but being explicit is better). It's a small change that we didn't consider worth a shared stable branch as there's no conflict with V4L2. On Thu, Sep 08, 2022 at 12:24:10AM +0300, Laurent Pinchart wrote: > Hi Dave, Daniel, > > The following changes since commit 8284bae723f025cb6a8431566757a3854a3c53eb: > > Merge tag 'drm-misc-next-2022-08-20-1' of > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2022-09-06 10:56:04 > +0200) > > are available in the Git repository at: > > git://linuxtv.org/pinchartl/media.git tags/du-next-20220907 > > for you to fetch changes up to cee3e5839cedcc71be755580dc9c0b87fd129116: > > dt-bindings: display: bridge: renesas,dw-hdmi: Add resets property > (2022-09-07 23:50:03 +0300) > > > - Misc fixes and improvements to the R-Car DU driver > - Synopsys DW HDMI bridge DT bindings update > > > Biju Das (2): > drm: rcar-du: Drop unused encoder header files > drm: rcar-du: Use %p4cc to print 4CC format > > Lad Prabhakar (1): > dt-bindings: display: bridge: renesas,dw-hdmi: Add resets property > > Laurent Pinchart (1): > drm: rcar-du: Drop leftovers variables from Makefile > > Takanari Hayama (3): > media: vsp1: Add premultiplied alpha support > drm: rcar-du: Add DRM_MODE_BLEND_PREMULTI support > drm: rcar-du: Add DRM_MODE_BLEND_PIXEL_NONE support > > Tomi Valkeinen (7): > drm: rcar-du: Remove unnecessary include > drm: rcar-du: Fix r8a779a0 color issue > drm: rcar-du: lvds: Rename pclk enable/disable functions > drm: rcar-du: dsi: Properly stop video mode TX > drm: rcar-du: dsi: Improve DSI shutdown > drm: rcar-du: Fix DSI enable & disable sequence > drm: rcar-du: dsi: Fix VCLKSET write > > .../bindings/display/bridge/renesas,dw-hdmi.yaml | 5 ++ > drivers/gpu/drm/rcar-du/Makefile | 7 --- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 30 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 + > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 9 ++- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.c| 16 +++-- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 26 +++- > drivers/gpu/drm/rcar-du/rcar_du_writeback.c| 4 +- > drivers/gpu/drm/rcar-du/rcar_lvds.c| 8 +-- > drivers/gpu/drm/rcar-du/rcar_lvds.h| 10 ++-- > drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c| 69 > +++--- > drivers/gpu/drm/rcar-du/rcar_mipi_dsi.h| 31 ++ > drivers/media/platform/renesas/vsp1/vsp1_drm.c | 2 + > include/media/vsp1.h | 2 + > 16 files changed, 188 insertions(+), 42 deletions(-) > create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.h -- Regards, Laurent Pinchart
Re: [PATCH 2/4] drm/plane: Allocate planes with drm_universal_plane_alloc()
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:45PM +0200, Thomas Zimmermann wrote:
> Provide drm_univeral_plane_alloc(), which allocated an initializes a
> plane. Code for non-atomic drivers uses this pattern. Convert it to
> the new function. The modeset helpers contain a quirk for handling their
> color formats differently. Set the flag outside plane allocation.
>
> The new function is already deprecated to some extend. Drivers should
> rather use drmm_univeral_plane_alloc() or drm_universal_plane_init().
If this is already deprecated and used by a single driver, what is the
point ?
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_modeset_helper.c| 61 +++--
> drivers/gpu/drm/drm_plane.c | 38 +++
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 41 ++---
> include/drm/drm_plane.h | 44 ++
> 4 files changed, 121 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c
> index 611dd01fb604..38040eebfa16 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -113,38 +113,6 @@ static const struct drm_plane_funcs primary_plane_funcs
> = {
> .destroy = drm_plane_helper_destroy,
> };
>
> -static struct drm_plane *create_primary_plane(struct drm_device *dev)
> -{
> - struct drm_plane *primary;
> - int ret;
> -
> - primary = kzalloc(sizeof(*primary), GFP_KERNEL);
> - if (primary == NULL) {
> - DRM_DEBUG_KMS("Failed to allocate primary plane\n");
> - return NULL;
> - }
> -
> - /*
> - * Remove the format_default field from drm_plane when dropping
> - * this helper.
> - */
> - primary->format_default = true;
> -
> - /* possible_crtc's will be filled in later by crtc_init */
> - ret = drm_universal_plane_init(dev, primary, 0,
> -_plane_funcs,
> -safe_modeset_formats,
> -ARRAY_SIZE(safe_modeset_formats),
> -NULL,
> -DRM_PLANE_TYPE_PRIMARY, NULL);
> - if (ret) {
> - kfree(primary);
> - primary = NULL;
> - }
> -
> - return primary;
> -}
> -
> /**
> * drm_crtc_init - Legacy CRTC initialization function
> * @dev: DRM device
> @@ -176,10 +144,33 @@ int drm_crtc_init(struct drm_device *dev, struct
> drm_crtc *crtc,
> const struct drm_crtc_funcs *funcs)
> {
> struct drm_plane *primary;
> + int ret;
> +
> + /* possible_crtc's will be filled in later by crtc_init */
> + primary = __drm_universal_plane_alloc(dev, sizeof(*primary), 0, 0,
> + _plane_funcs,
> + safe_modeset_formats,
> + ARRAY_SIZE(safe_modeset_formats),
> + NULL, DRM_PLANE_TYPE_PRIMARY,
> NULL);
> + if (IS_ERR(primary))
> + return PTR_ERR(primary);
>
> - primary = create_primary_plane(dev);
> - return drm_crtc_init_with_planes(dev, crtc, primary, NULL, funcs,
> - NULL);
> + /*
> + * Remove the format_default field from drm_plane when dropping
> + * this helper.
> + */
> + primary->format_default = true;
> +
> + ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL, funcs, NULL);
> + if (ret)
> + goto err_drm_plane_cleanup;
> +
> + return 0;
> +
> +err_drm_plane_cleanup:
> + drm_plane_cleanup(primary);
> + kfree(primary);
> + return ret;
> }
> EXPORT_SYMBOL(drm_crtc_init);
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0f14b4d3bb10..33357629a7f5 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -448,6 +448,44 @@ void *__drmm_universal_plane_alloc(struct drm_device
> *dev, size_t size,
> }
> EXPORT_SYMBOL(__drmm_universal_plane_alloc);
>
> +void *__drm_universal_plane_alloc(struct drm_device *dev, size_t size,
> + size_t offset, uint32_t possible_crtcs,
> + const struct drm_plane_funcs *funcs,
> + const uint32_t *formats, unsigned int
> format_count,
> + const uint64_t *format_modifiers,
> + enum drm_plane_type type,
> + const char *name, ...)
> +{
> + void *container;
> + struct drm_plane *plane;
> + va_list ap;
> + int ret;
> +
> + if (drm_WARN_ON(dev, !funcs))
> + return ERR_PTR(-EINVAL);
> +
> + container = kzalloc(size, GFP_KERNEL);
> + if (!container)
> + return ERR_PTR(-ENOMEM);
> +
> +
Re: [PATCH 1/4] drm/plane: Remove drm_plane_init()
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:44PM +0200, Thomas Zimmermann wrote:
> Open-code drm_plane_init() and remove the function from DRM. The
> implementation of drm_plane_init() is a simple wrapper around a call
> to drm_universal_plane_init(), so drivers can just use that instead.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_modeset_helper.c | 3 +-
> drivers/gpu/drm/drm_plane.c| 32 --
> drivers/gpu/drm/nouveau/dispnv04/overlay.c | 13 +
> drivers/gpu/drm/shmobile/shmob_drm_plane.c | 7 +++--
> drivers/gpu/drm/tilcdc/tilcdc_plane.c | 9 +++---
> include/drm/drm_plane.h| 8 +-
> 6 files changed, 17 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c
> index bd609a978848..611dd01fb604 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -100,8 +100,7 @@ EXPORT_SYMBOL(drm_helper_mode_fill_fb_struct);
> * This is the minimal list of formats that seem to be safe for modeset use
> * with all current DRM drivers. Most hardware can actually support more
> * formats than this and drivers may specify a more accurate list when
> - * creating the primary plane. However drivers that still call
> - * drm_plane_init() will use this minimal format list as the default.
> + * creating the primary plane.
> */
> static const uint32_t safe_modeset_formats[] = {
> DRM_FORMAT_XRGB,
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 726f2f163c26..0f14b4d3bb10 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -482,38 +482,6 @@ void drm_plane_unregister_all(struct drm_device *dev)
> }
> }
>
> -/**
> - * drm_plane_init - Initialize a legacy plane
> - * @dev: DRM device
> - * @plane: plane object to init
> - * @possible_crtcs: bitmask of possible CRTCs
> - * @funcs: callbacks for the new plane
> - * @formats: array of supported formats (DRM_FORMAT\_\*)
> - * @format_count: number of elements in @formats
> - * @is_primary: plane type (primary vs overlay)
> - *
> - * Legacy API to initialize a DRM plane.
> - *
> - * New drivers should call drm_universal_plane_init() instead.
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> -uint32_t possible_crtcs,
> -const struct drm_plane_funcs *funcs,
> -const uint32_t *formats, unsigned int format_count,
> -bool is_primary)
> -{
> - enum drm_plane_type type;
> -
> - type = is_primary ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
> - return drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
> - formats, format_count,
> - NULL, type, NULL);
> -}
> -EXPORT_SYMBOL(drm_plane_init);
> -
> /**
> * drm_plane_cleanup - Clean up the core plane usage
> * @plane: plane to cleanup
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> index 37e63e98cd08..33f29736024a 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> @@ -296,9 +296,10 @@ nv10_overlay_init(struct drm_device *device)
> break;
> }
>
> - ret = drm_plane_init(device, >base, 3 /* both crtc's */,
> - _plane_funcs,
> - formats, num_formats, false);
> + ret = drm_universal_plane_init(device, >base, 3 /* both crtc's
> */,
> +_plane_funcs,
> +formats, num_formats, NULL,
> +DRM_PLANE_TYPE_OVERLAY, NULL);
> if (ret)
> goto err;
>
> @@ -475,9 +476,9 @@ nv04_overlay_init(struct drm_device *device)
> if (!plane)
> return;
>
> - ret = drm_plane_init(device, >base, 1 /* single crtc */,
> - _plane_funcs,
> - formats, 2, false);
> + ret = drm_universal_plane_init(device, >base, 1 /* single crtc
> */,
> +_plane_funcs, formats, 2, NULL,
> +DRM_PLANE_TYPE_OVERLAY, NULL);
> if (ret)
> goto err;
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
> b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
> index 54228424793a..6c5f0cbe7d95 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
> @@ -252,9 +252,10 @@ int shmob_drm_plane_create(struct shmob_drm_device
> *sdev, unsigned int index)
> splane->index = index;
> splane->alpha = 255;
>
> - ret =
Re: [PATCH 1/4] drm/plane: Remove drm_plane_init()
Hello Thomas, On 9/9/22 12:59, Thomas Zimmermann wrote: > Open-code drm_plane_init() and remove the function from DRM. The > implementation of drm_plane_init() is a simple wrapper around a call > to drm_universal_plane_init(), so drivers can just use that instead. > > Signed-off-by: Thomas Zimmermann > --- [...] > diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c > b/drivers/gpu/drm/nouveau/dispnv04/overlay.c > index 37e63e98cd08..33f29736024a 100644 > --- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c > +++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c > @@ -296,9 +296,10 @@ nv10_overlay_init(struct drm_device *device) > break; > } > > - ret = drm_plane_init(device, >base, 3 /* both crtc's */, > - _plane_funcs, > - formats, num_formats, false); > + ret = drm_universal_plane_init(device, >base, 3 /* both crtc's > */, > +_plane_funcs, > +formats, num_formats, NULL, > +DRM_PLANE_TYPE_OVERLAY, NULL); Not only drm_plane_init() doesn't add much value but makes the code harder to read. Since by calling drm_universal_plane_init() instead, it's explicit whether the initialized plane is primary or an overlay. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
[PATCH v2] drm/etnaviv: don't truncate physical page address
While the interface for the MMU mapping takes phys_addr_t to hold a
full 64bit address when necessary and MMUv2 is able to map physical
addresses with up to 40bit, etnaviv_iommu_map() truncates the address
to 32bits. Fix this by using the correct type.
Fixes: 931e97f3afd8 ("drm/etnaviv: mmuv2: support 40 bit phys address")
Signed-off-by: Lucas Stach
---
v2: Use proper printk format specifier.
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index dc1aa738c4f1..efb345b31df7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -80,10 +80,10 @@ static int etnaviv_iommu_map(struct etnaviv_iommu_context
*context, u32 iova,
return -EINVAL;
for_each_sgtable_dma_sg(sgt, sg, i) {
- u32 pa = sg_dma_address(sg) - sg->offset;
+ phys_addr_t pa = sg_dma_address(sg) - sg->offset;
size_t bytes = sg_dma_len(sg) + sg->offset;
- VERB("map[%d]: %08x %08x(%zx)", i, iova, pa, bytes);
+ VERB("map[%d]: %08x %pap(%zx)", i, iova, , bytes);
ret = etnaviv_context_map(context, da, pa, bytes, prot);
if (ret)
--
2.30.2
Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver
On Fri, Sep 16, 2022 at 1:58 PM Marek Szyprowski wrote: > > Hi Jagan, > > On 14.09.2022 11:39, Jagan Teki wrote: > > On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski > > wrote: > >> On 13.09.2022 19:29, Jagan Teki wrote: > >>> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski > >>> wrote: > On 06.09.2022 21:07, Jagan Teki wrote: > > On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski > > wrote: > >> On 02.09.2022 12:47, Marek Szyprowski wrote: > >>> On 29.08.2022 20:40, Jagan Teki wrote: > Samsung MIPI DSIM controller is common DSI IP that can be used in > various > SoCs like Exynos, i.MX8M Mini/Nano. > > In order to access this DSI controller between various platform SoCs, > the ideal way to incorporate this in the drm stack is via the drm > bridge > driver. > > This patch is trying to differentiate platform-specific and bridge > driver > code and keep maintaining the exynos_drm_dsi.c code as > platform-specific > glue code and samsung-dsim.c as a common bridge driver code. > > - Exynos specific glue code is exynos specific te_irq, host_attach, > and > detach code along with conventional component_ops. > > - Samsung DSIM is a bridge driver which is common across all > platforms and > the respective platform-specific glue will initialize at the > end > of the > probe. The platform-specific operations and other glue calls > will > invoke > on associate code areas. > > v4: > * include Inki Dae in MAINTAINERS > * remove dsi_driver probe in exynos_drm_drv to support multi-arch > build > >>> This breaks Exynos DRM completely as the Exynos DRM driver is not able > >>> to wait until the DSI driver is probed and registered as component. > >>> > >>> I will show how to rework this the way it is done in > >>> drivers/gpu/drm/exynos/exynos_dp.c and > >>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon... > >> I've finally had some time to implement such approach, see > >> https://protect2.fireeye.com/v1/url?k=c5d024d9-a4ab8e4e-c5d1af96-74fe4860001d-625a8324a9797375=1=489b94d4-84fb-408e-b679-a8d27acf2930=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv6.0-dsi-v4-reworked > >> > >> If you want me to send the patches against your v4 patchset, let me > >> know, but imho my changes are much more readable after squashing to the > >> original patches. > >> > >> Now the driver is fully multi-arch safe and ready for further > >> extensions. I've removed the weak functions, reworked the way the > >> plat_data is used (dropped the patch related to it) and restored > >> exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel > >> free to resend the above as v5 after testing on your hardware. At least > >> it properly works now on all Exynos boards I have, both compiled into > >> the kernel or as modules. > > Thanks. I've seen the repo added on top of Dave patches - does it mean > > these depends on Dave changes as well? > Yes and no. My rework doesn't change anything with this dependency. It > comes from my patch "drm: exynos: dsi: Restore proper bridge chain > order" already included in your series (patch #1). Without it exynos-dsi > driver hacks the list of bridges to ensure the order of pre_enable calls > needed for proper operation. This works somehow with DSI panels on my > test systems, but it has been reported that it doesn't work with a bit > more complex display pipelines. Only that patch depends on the Dave's > patches. If you remove it, you would need to adjust the code in the > exynos_drm_dsi.c and samsung-dsim.c respectively. imho it would be > better to keep it and merge Dave's patches together with dsi changes, as > they are the first real client of it. > >>> I think the Dave patches especially "drm/bridge: Introduce > >>> pre_enable_upstream_first to alter bridge init order" seems not 100% > >>> relevant to this series as they affect bridge chain call flow > >>> globally. Having a separate series for that makes sense to me. I'm > >>> sending v5 by excluding those parts. > >> If so then drop the "drm: exynos: dsi: Restore proper bridge chain > >> order" patch and adjust code respectively in samsung-dsim.c. Without the > >> Dave's patches, that one doesn't make sense. > > Doesn't it break Exynos? > > No it won't. Lack of the "drm: exynos: dsi: Restore proper bridge chain > order" patch doesn't change much against the current state of the driver. > > Here is my rework of your v4 patchset without the mentioned patch and > Dave's patches: > > https://github.com/mszyprow/linux/tree/v6.0-dsi-v4-reworked-minimal
[PATCH v2 2/4] drm/edid: Split DSC parsing into separate function
Move the DSC parsing logic into separate function.
v2: Rebase.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 128 -
1 file changed, 69 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ebe02cf7cd95..92c9c2e28902 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5752,6 +5752,73 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
hdmi->y420_dc_modes = dc_mask;
}
+static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
+ const u8 *hf_scds)
+{
+ u8 dsc_max_slices;
+ u8 dsc_max_frl_rate;
+
+ hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
+
+ if (!hdmi_dsc->v_1p2)
+ return;
+
+ hdmi_dsc->native_420 = hf_scds[11] & DRM_EDID_DSC_NATIVE_420;
+ hdmi_dsc->all_bpp = hf_scds[11] & DRM_EDID_DSC_ALL_BPP;
+
+ if (hf_scds[11] & DRM_EDID_DSC_16BPC)
+ hdmi_dsc->bpc_supported = 16;
+ else if (hf_scds[11] & DRM_EDID_DSC_12BPC)
+ hdmi_dsc->bpc_supported = 12;
+ else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
+ hdmi_dsc->bpc_supported = 10;
+ else
+ /* Supports min 8 BPC if DSC 1.2 is supported*/
+ hdmi_dsc->bpc_supported = 8;
+
+ dsc_max_frl_rate = (hf_scds[12] & DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate, _dsc->max_lanes,
+_dsc->max_frl_rate_per_lane);
+ hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+ dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
+}
+
/* Sink Capability Data Structure */
static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
const u8 *hf_scds)
@@ -5798,71 +5865,14 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
if (hf_scds[7]) {
u8 max_frl_rate;
- u8 dsc_max_frl_rate;
- u8 dsc_max_slices;
struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
- hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
-
- if (hdmi_dsc->v_1p2) {
- hdmi_dsc->native_420 = hf_scds[11] &
DRM_EDID_DSC_NATIVE_420;
- hdmi_dsc->all_bpp = hf_scds[11] & DRM_EDID_DSC_ALL_BPP;
-
- if (hf_scds[11] & DRM_EDID_DSC_16BPC)
- hdmi_dsc->bpc_supported = 16;
- else if (hf_scds[11] & DRM_EDID_DSC_12BPC)
- hdmi_dsc->bpc_supported = 12;
- else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
- hdmi_dsc->bpc_supported = 10;
- else
- /* Supports min 8 BPC if DSC 1.2 is supported*/
- hdmi_dsc->bpc_supported = 8;
-
- dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
- drm_get_max_frl_rate(dsc_max_frl_rate,
_dsc->max_lanes,
-_dsc->max_frl_rate_per_lane);
- hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
-
- dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
- switch (dsc_max_slices) {
- case 1:
- hdmi_dsc->max_slices = 1;
-
[PATCH v2 1/4] drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink
HF-VSDB/SCDB has bits to advertise support for 16, 12 and 10 bpc.
If none of the bits are set, the minimum bpc supported with DSC is 8.
This patch corrects the min bpc supported to be 8, instead of 0.
Fixes: 76ee7b905678 ("drm/edid: Parse DSC1.2 cap fields from HFVSDB block")
Cc: Ankit Nautiyal
Cc: Uma Shankar
Cc: Jani Nikula
Cc: Maarten Lankhorst
v2: s/DSC1.2/DSC 1.2
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4005dab6147d..ebe02cf7cd95 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5819,7 +5819,8 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
hdmi_dsc->bpc_supported = 10;
else
- hdmi_dsc->bpc_supported = 0;
+ /* Supports min 8 BPC if DSC 1.2 is supported*/
+ hdmi_dsc->bpc_supported = 8;
dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(dsc_max_frl_rate,
_dsc->max_lanes,
--
2.25.1
[PATCH v2 3/4] drm/edid: Refactor HFVSDB parsing for DSC1.2
DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
SCDS). Since minimum length of Data block is 7, all bytes greater than 7
must be read only after checking the length of the data block.
This patch adds check for data block length before reading relavant DSC
bytes.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 93 --
1 file changed, 49 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 92c9c2e28902..27bdbdf6d345 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5755,9 +5755,6 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
const u8 *hf_scds)
{
- u8 dsc_max_slices;
- u8 dsc_max_frl_rate;
-
hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
if (!hdmi_dsc->v_1p2)
@@ -5776,47 +5773,54 @@ static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap
*hdmi_dsc,
/* Supports min 8 BPC if DSC 1.2 is supported*/
hdmi_dsc->bpc_supported = 8;
- dsc_max_frl_rate = (hf_scds[12] & DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
- drm_get_max_frl_rate(dsc_max_frl_rate, _dsc->max_lanes,
-_dsc->max_frl_rate_per_lane);
- hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+ if (cea_db_payload_len(hf_scds) >= 12 && hf_scds[12]) {
+ u8 dsc_max_slices;
+ u8 dsc_max_frl_rate;
- dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+ dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate, _dsc->max_lanes,
+_dsc->max_frl_rate_per_lane);
- switch (dsc_max_slices) {
- case 1:
- hdmi_dsc->max_slices = 1;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 2:
- hdmi_dsc->max_slices = 2;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 3:
- hdmi_dsc->max_slices = 4;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 4:
- hdmi_dsc->max_slices = 8;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 5:
- hdmi_dsc->max_slices = 8;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 6:
- hdmi_dsc->max_slices = 12;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 7:
- hdmi_dsc->max_slices = 16;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 0:
- default:
- hdmi_dsc->max_slices = 0;
- hdmi_dsc->clk_per_slice = 0;
+ dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
}
+
+ if (cea_db_payload_len(hf_scds) >= 13 && hf_scds[13])
+ hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
}
/* Sink Capability Data Structure */
@@ -5825,6 +5829,7 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
{
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
+ struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
display->has_hdmi_infoframe = true;
@@ -5865,17 +5870,17 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector
[PATCH v2 4/4] drm/edid: Avoid multiple log lines for HFVSDB parsing
Replace multiple log lines with a single log line at the end of
parsing HF-VSDB. Also use drm_dbg_kms instead of DRM_DBG_KMS, and
add log for DSC1.2 support.
v2: Fixed the formatting issues in the logging (Jani).
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 27bdbdf6d345..1c61e3af79c6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5830,6 +5830,9 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
+ int max_tmds_clock = 0;
+ u8 max_frl_rate = 0;
+ bool dsc_support = false;
display->has_hdmi_infoframe = true;
@@ -5849,14 +5852,13 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
*/
if (hf_scds[5]) {
- /* max clock is 5000 KHz times block value */
- u32 max_tmds_clock = hf_scds[5] * 5000;
struct drm_scdc *scdc = >scdc;
+ /* max clock is 5000 KHz times block value */
+ max_tmds_clock = hf_scds[5] * 5000;
+
if (max_tmds_clock > 34) {
display->max_tmds_clock = max_tmds_clock;
- DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
- display->max_tmds_clock);
}
if (scdc->supported) {
@@ -5869,9 +5871,6 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
}
if (hf_scds[7]) {
- u8 max_frl_rate;
-
- DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
@@ -5879,8 +5878,14 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
- if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11])
+ if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11]) {
drm_parse_dsc_info(hdmi_dsc, hf_scds);
+ dsc_support = true;
+ }
+
+ drm_dbg_kms(connector->dev,
+ "HF-VSDB: max TMDS clock: %d KHz, HDMI 2.1 support: %s, DSC
1.2 support: %s\n",
+ max_tmds_clock, str_yes_no(max_frl_rate),
str_yes_no(dsc_support));
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
--
2.25.1
[PATCH v2 0/4] Fix HFVSDB parsing
Fix issues in HFVSDB parsing for DSC support. Also minor refactoring in Logging. Split from original patch into a new series. https://patchwork.freedesktop.org/patch/495193/ v2: Minor styling fixes. Ankit Nautiyal (4): drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink drm/edid: Split DSC parsing into separate function drm/edid: Refactor HFVSDB parsing for DSC1.2 drm/edid: Avoid multiple log lines for HFVSDB parsing drivers/gpu/drm/drm_edid.c | 153 + 1 file changed, 87 insertions(+), 66 deletions(-) -- 2.25.1
Re: [PATCH 3/3] drm/etnaviv: export client GPU usage statistics via fdinfo
Hi Tvrtko,
Am Freitag, dem 16.09.2022 um 10:31 +0100 schrieb Tvrtko Ursulin:
> Hi Lucas,
>
> On 08/09/2022 19:10, Lucas Stach wrote:
> > This exposes a accumulated GPU active time per client via the
> > fdinfo infrastructure.
> >
> > Signed-off-by: Lucas Stach
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 38 ++-
> > 1 file changed, 37 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > index b69edb40ae2a..11b1f11fcb58 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > @@ -22,6 +22,7 @@
> > #include "etnaviv_gem.h"
> > #include "etnaviv_mmu.h"
> > #include "etnaviv_perfmon.h"
> > +#include "common.xml.h"
> >
> > /*
> >* DRM operations:
> > @@ -471,7 +472,42 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
> > ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_RENDER_ALLOW),
> > };
> >
> > -DEFINE_DRM_GEM_FOPS(fops);
> > +static void etnaviv_fop_show_fdinfo(struct seq_file *m, struct file *f)
> > +{
> > + struct drm_file *file = f->private_data;
> > + struct drm_device *dev = file->minor->dev;
> > + struct etnaviv_drm_private *priv = dev->dev_private;
> > + struct etnaviv_file_private *ctx = file->driver_priv;
> > + struct drm_printer p = drm_seq_file_printer(m);
>
> Any specific reason not to use seq_printf directly? (May be my ignorance.)
>
Not really, I just followed what msm was doing here.
> > + int i;
> > +
> > + drm_printf(, "drm-driver:\t%s\n", dev->driver->name);
> > + drm_printf(, "drm-client-id:\t%u\n", ctx->id);
> > +
> > + for (i = 0; i < ETNA_MAX_PIPES; i++) {
> > +struct etnaviv_gpu *gpu = priv->gpu[i];
> > + char engine[8];
> > + int cur = 0;
>
> Alignment renders odd in my client.
I'll check that, might have messed up here.
>
> > +
> > + if (!gpu)
> > + continue;
>
> I'd stick a comment in here to the effect of "For text output format
> description please see drm-usage-stats.rst!".
>
> Just to leave a breadcrumb putting some restraint on adding vendor
> specific things which may be already covered by the common spec. To help
> with common tools in the future as much as possible.
Yea, it was pretty to clear to me that we want the common format as
much as possible when writing the patches, but it's a good idea to add
a pointer for the future reader.
>
> > +
> > + if (gpu->identity.features & chipFeatures_PIPE_2D)
> > + cur = snprintf(engine, sizeof(engine), "2D");
> > + if (gpu->identity.features & chipFeatures_PIPE_3D)
> > + cur = snprintf(engine + cur, sizeof(engine) - cur,
> > + "%s3D", cur ? "/" : "");
> > +
> > + drm_printf(, "drm-engine-%s:\t%llu ns\n", engine,
> > + ctx->sched_entity[i].elapsed_ns);
>
> Two questions:
>
> 1)
> So you have max four pipes, each can be either only 2d, 3d, or 2d/3d?
> Can you have multiple of the same like 2x 3D? If you do, have you
> considered exporting one drm-engine-% together with drm-engine-capacity-
> for it?
>
The four pipes is a arbitrary driver limit. Etnaviv is a bit special in
that it collects all Vivante GPUs present in a system into a single DRM
device, each of those GPUs can be either 2D, 3D or a combined core with
both 2D and 3D capabilities. In theory there could be multiple GPUs of
each kind, but for now all real SoC designs we've come across only had
a single one of each kind.
When we add support for a SoC that has multiple GPUs of one kind, I
think exposing drm-engine-capacity, together with hooking them up to
the load balancing in the scheduler is the right thing to do.
> 2)
> Have you tried my, yet unmerged, vendor agnostic gputop tool with your
> changes?
>
> https://patchwork.freedesktop.org/series/102175/
>
> It would be interesting to know if it works.
>
Yes, I did when working on this series. I had some crashes related to
(I believe) double frees in the DRM client discovery, which I hadn't
had time to investigate further. Seems there is a race, as I couldn't
reproduce the crash when running with valgrind.
Other than that, the tool works for exposing the per-client GPU load on
etnaviv.
Regards,
Lucas
> Regards,
>
> Tvrtko
>
> > + }
> > +}
> > +
> > +static const struct file_operations fops = {
> > +.owner = THIS_MODULE,
> > +DRM_GEM_FOPS,
> > +.show_fdinfo = etnaviv_fop_show_fdinfo,
> > +};
> >
> > static const struct drm_driver etnaviv_drm_driver = {
> > .driver_features= DRIVER_GEM | DRIVER_RENDER,
