[PATCH] agp: parisc-agp: fix section mismatch warning
Fix section mismatch warning in parisc-agp:
WARNING: modpost: drivers/char/agp/parisc-agp.o(.text+0x7a0): Section mismatch
in reference from the function init_module() to the function
.init.text:parisc_agp_setup.isra.0()
The function init_module() references
the function __init parisc_agp_setup.isra.0().
This is often because init_module lacks a __init
annotation or the annotation of parisc_agp_setup.isra.0 is wrong.
Fixes: 08a6436816f7 ("[PARISC] Add support for Quicksilver AGPGART")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Kyle McMartin
Cc: David Airlie
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
---
drivers/char/agp/parisc-agp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20211126.orig/drivers/char/agp/parisc-agp.c
+++ linux-next-20211126/drivers/char/agp/parisc-agp.c
@@ -378,7 +378,7 @@ find_quicksilver(struct device *dev, voi
return 0;
}
-static int
+static int __init
parisc_agp_init(void)
{
extern struct sba_device *sba_list;
[PATCH 4/4] drm/bridge: tc358767: Add DSI-to-DPI mode support
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Add support for the
DSI-to-DPI mode.
This requires skipping most of the (e)DP initialization code, which is
currently a large part of this driver, hence it is better to have far
simpler separate tc_dpi_bridge_funcs and their implementation.
The configuration of DPI output is also much simpler. The configuration
of the DSI input is rather similar to the other TC bridge chips.
The Pixel PLL in DPI output mode does not have the 65..150 MHz limitation
imposed on the (e)DP output mode, so this limitation is skipped to permit
operating panels with far slower pixel clock, even below 9 MHz. This mode
of operation of the PLL is valid and tested.
The detection of bridge mode is now added into tc_probe_bridge_mode(),
where in case a DPI panel is found on port@1 endpoint@1, the mode is
assumed to be DSI-to-DPI. If (e)DP is detected on port@2, the mode is
assumed to be DPI-to-(e)DP.
The DSI-to-(e)DP mode is not supported due to lack of proper hardware,
but this would be some sort of mix between the two aforementioned modes.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Neil Armstrong
Cc: Sam Ravnborg
---
drivers/gpu/drm/bridge/tc358767.c | 443 --
1 file changed, 356 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 0e16ae2461fd..c653a0bd0f35 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1,6 +1,12 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * tc358767 eDP bridge driver
+ * TC358767/TC358867/TC9595 DSI/DPI-to-DPI/(e)DP bridge driver
+ *
+ * The TC358767/TC358867/TC9595 can operate in multiple modes.
+ * The following modes are supported:
+ * DPI->(e)DP -- supported
+ * DSI->DPI supported
+ * DSI->(e)DP .. NOT supported
*
* Copyright (C) 2016 CogentEmbedded Inc
* Author: Andrey Gusakov
@@ -29,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,7 +43,35 @@
/* Registers */
-/* Display Parallel Interface */
+/* PPI layer registers */
+#define PPI_STARTPPI 0x0104 /* START control bit */
+#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */
+#define LPX_PERIOD 3
+#define PPI_LANEENABLE 0x0134
+#define PPI_TX_RX_TA 0x013c
+#define TTA_GET0x4
+#define TTA_SURE 6
+#define PPI_D0S_ATMR 0x0144
+#define PPI_D1S_ATMR 0x0148
+#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */
+#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */
+#define PPI_D2S_CLRSIPOCOUNT 0x016c /* Assertion timer for Lane 2 */
+#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */
+#define PPI_START_FUNCTION BIT(0)
+
+/* DSI layer registers */
+#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */
+#define DSI_LANEENABLE 0x0210 /* Enables each lane */
+#define DSI_RX_START BIT(0)
+
+/* Lane enable PPI and DSI register bits */
+#define LANEENABLE_CLENBIT(0)
+#define LANEENABLE_L0ENBIT(1)
+#define LANEENABLE_L1ENBIT(2)
+#define LANEENABLE_L2ENBIT(1)
+#define LANEENABLE_L3ENBIT(2)
+
+/* Display Parallel Input Interface */
#define DPIPXLFMT 0x0440
#define VS_POL_ACTIVE_LOW (1 << 10)
#define HS_POL_ACTIVE_LOW (1 << 9)
@@ -48,6 +83,14 @@
#define DPI_BPP_RGB666 (1 << 0)
#define DPI_BPP_RGB565 (2 << 0)
+/* Display Parallel Output Interface */
+#define POCTRL 0x0448
+#define POCTRL_S2P BIT(7)
+#define POCTRL_PCLK_POLBIT(3)
+#define POCTRL_VS_POL BIT(2)
+#define POCTRL_HS_POL BIT(1)
+#define POCTRL_DE_POL BIT(0)
+
/* Video Path */
#define VPCTRL00x0450
#define VSDELAYGENMASK(31, 20)
@@ -247,6 +290,9 @@ struct tc_data {
struct drm_bridge *panel_bridge;
struct drm_connectorconnector;
+ struct mipi_dsi_device *dsi;
+ u8 dsi_lanes;
+
/* link settings */
struct tc_edp_link link;
@@ -502,8 +548,10 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk,
u32 pixelclock)
/*
* refclk * mul / (ext_pre_div * pre_div)
* should be in the 150 to 650 MHz range
+* for (e)DP
*/
- if ((clk > 65000) || (clk < 15000))
+
[PATCH 3/4] drm/bridge: tc358767: Move bridge endpoint parsing into dedicated function
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. In order to support the rest of the modes without
making the tc_probe() overly long, split the bridge endpoint parsing
into dedicated function, where the necessary logic to detect the bridge
mode based on which endpoints are connected, can be implemented.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Neil Armstrong
Cc: Sam Ravnborg
---
drivers/gpu/drm/bridge/tc358767.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index f7fbf6f673e9..0e16ae2461fd 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1612,19 +1612,12 @@ static irqreturn_t tc_irq_handler(int irq, void *arg)
return IRQ_HANDLED;
}
-static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
+static int tc_probe_bridge_mode(struct tc_data *tc)
{
- struct device *dev = >dev;
+ struct device *dev = tc->dev;
struct drm_panel *panel;
- struct tc_data *tc;
int ret;
- tc = devm_kzalloc(dev, sizeof(*tc), GFP_KERNEL);
- if (!tc)
- return -ENOMEM;
-
- tc->dev = dev;
-
/* port@2 is the output port */
ret = drm_of_find_panel_or_bridge(dev->of_node, 2, 0, , NULL);
if (ret && ret != -ENODEV)
@@ -1643,6 +1636,25 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
tc->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
}
+ return ret;
+}
+
+static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+ struct device *dev = >dev;
+ struct tc_data *tc;
+ int ret;
+
+ tc = devm_kzalloc(dev, sizeof(*tc), GFP_KERNEL);
+ if (!tc)
+ return -ENOMEM;
+
+ tc->dev = dev;
+
+ ret = tc_probe_bridge_mode(tc);
+ if (ret)
+ return ret;
+
/* Shut down GPIO is optional */
tc->sd_gpio = devm_gpiod_get_optional(dev, "shutdown", GPIOD_OUT_HIGH);
if (IS_ERR(tc->sd_gpio))
--
2.33.0
[PATCH 2/4] drm/bridge: tc358767: Move hardware init to enable callback
The TC358767/TC358867/TC9595 are all capable of operating either from
attached Xtal or from DSI clock lane clock. In case the later is used,
all I2C accesses will fail until the DSI clock lane is running and
supplying clock to the chip.
Move all hardware initialization to enable callback to guarantee the
DSI clock lane is running before accessing the hardware. In case Xtal
is attached to the chip, this change has no effect.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Neil Armstrong
Cc: Sam Ravnborg
---
drivers/gpu/drm/bridge/tc358767.c | 111 +-
1 file changed, 63 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 23a6f90b694b..f7fbf6f673e9 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1234,11 +1234,74 @@ static int tc_stream_disable(struct tc_data *tc)
return 0;
}
+static int tc_hardware_init(struct tc_data *tc)
+{
+ int ret;
+
+ ret = regmap_read(tc->regmap, TC_IDREG, >rev);
+ if (ret) {
+ dev_err(tc->dev, "can not read device ID: %d\n", ret);
+ return ret;
+ }
+
+ if ((tc->rev != 0x6601) && (tc->rev != 0x6603)) {
+ dev_err(tc->dev, "invalid device ID: 0x%08x\n", tc->rev);
+ return -EINVAL;
+ }
+
+ tc->assr = (tc->rev == 0x6601); /* Enable ASSR for eDP panels */
+
+ if (!tc->reset_gpio) {
+ /*
+* If the reset pin isn't present, do a software reset. It isn't
+* as thorough as the hardware reset, as we can't reset the I2C
+* communication block for obvious reasons, but it's getting the
+* chip into a defined state.
+*/
+ regmap_update_bits(tc->regmap, SYSRSTENB,
+ ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP,
+ 0);
+ regmap_update_bits(tc->regmap, SYSRSTENB,
+ ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP,
+ ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP);
+ usleep_range(5000, 1);
+ }
+
+ if (tc->hpd_pin >= 0) {
+ u32 lcnt_reg = tc->hpd_pin == 0 ? INT_GP0_LCNT : INT_GP1_LCNT;
+ u32 h_lc = INT_GPIO_H(tc->hpd_pin) | INT_GPIO_LC(tc->hpd_pin);
+
+ /* Set LCNT to 2ms */
+ regmap_write(tc->regmap, lcnt_reg,
+clk_get_rate(tc->refclk) * 2 / 1000);
+ /* We need the "alternate" mode for HPD */
+ regmap_write(tc->regmap, GPIOM, BIT(tc->hpd_pin));
+
+ if (tc->have_irq) {
+ /* enable H & LC */
+ regmap_update_bits(tc->regmap, INTCTL_G, h_lc, h_lc);
+ }
+ }
+
+ if (tc->have_irq) {
+ /* enable SysErr */
+ regmap_write(tc->regmap, INTCTL_G, INT_SYSERR);
+ }
+
+ return 0;
+}
+
static void tc_bridge_enable(struct drm_bridge *bridge)
{
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
+ ret = tc_hardware_init(tc);
+ if (ret < 0) {
+ dev_err(tc->dev, "failed to initialize bridge: %d\n", ret);
+ return;
+ }
+
ret = tc_get_display_props(tc);
if (ret < 0) {
dev_err(tc->dev, "failed to read display props: %d\n", ret);
@@ -1626,9 +1689,6 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
}
if (client->irq > 0) {
- /* enable SysErr */
- regmap_write(tc->regmap, INTCTL_G, INT_SYSERR);
-
ret = devm_request_threaded_irq(dev, client->irq,
NULL, tc_irq_handler,
IRQF_ONESHOT,
@@ -1641,51 +1701,6 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
tc->have_irq = true;
}
- ret = regmap_read(tc->regmap, TC_IDREG, >rev);
- if (ret) {
- dev_err(tc->dev, "can not read device ID: %d\n", ret);
- return ret;
- }
-
- if ((tc->rev != 0x6601) && (tc->rev != 0x6603)) {
- dev_err(tc->dev, "invalid device ID: 0x%08x\n", tc->rev);
- return -EINVAL;
- }
-
- tc->assr = (tc->rev == 0x6601); /* Enable ASSR for eDP panels */
-
- if (!tc->reset_gpio) {
- /*
-* If the reset pin isn't present, do a software reset. It isn't
-* as thorough as the hardware reset, as we can't reset the I2C
-* communication block for obvious reasons, but it's getting the
-* chip into a defined state.
-*/
-
[PATCH 1/4] dt-bindings: display: bridge: tc358867: Document DPI output support
The TC358767/TC358867/TC9595 are all capable of operating in multiple modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the DPI output port, which can now be connected both as input and output. Signed-off-by: Marek Vasut Cc: Andrzej Hajda Cc: Jernej Skrabec Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Neil Armstrong Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org To: dri-devel@lists.freedesktop.org --- .../devicetree/bindings/display/bridge/toshiba,tc358767.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml index f1541cc05297..5cfda6f2ba69 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -61,8 +61,8 @@ properties: port@1: $ref: /schemas/graph.yaml#/properties/port description: | -DPI input port. The remote endpoint phandle should be a -reference to a valid DPI output endpoint node +DPI input/output port. The remote endpoint phandle should be a +reference to a valid DPI output or input endpoint node. port@2: $ref: /schemas/graph.yaml#/properties/port -- 2.33.0
[PATCH 3/3] drm/panel: simple: Add Team Source Display TST043015CMHX panel
Add Team Source Display TST043015CMHX 4.3" 480x272 DPI panel support.
Signed-off-by: Marek Vasut
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 30
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index dde033066f3d..9e46db5e359c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3252,6 +3252,33 @@ static const struct panel_desc starry_kr070pe2t = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct display_timing tsd_tst043015cmhx_timing = {
+ .pixelclock = { 500, 900, 1200 },
+ .hactive = { 480, 480, 480 },
+ .hfront_porch = { 4, 5, 65 },
+ .hback_porch = { 36, 40, 255 },
+ .hsync_len = { 1, 1, 1 },
+ .vactive = { 272, 272, 272 },
+ .vfront_porch = { 2, 8, 97 },
+ .vback_porch = { 3, 8, 31 },
+ .vsync_len = { 1, 1, 1 },
+
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+};
+
+static const struct panel_desc tsd_tst043015cmhx = {
+ .timings = _tst043015cmhx_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 105,
+ .height = 67,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
static const struct drm_display_mode tfc_s9700rtwv43tr_01b_mode = {
.clock = 3,
.hdisplay = 800,
@@ -3928,6 +3955,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "starry,kr070pe2t",
.data = _kr070pe2t,
+ }, {
+ .compatible = "team-source-display,tst043015cmhx",
+ .data = _tst043015cmhx,
}, {
.compatible = "tfc,s9700rtwv43tr-01b",
.data = _s9700rtwv43tr_01b,
--
2.33.0
[PATCH 2/3] dt-bindings: display: simple: Add Team Source Display TST043015CMHX panel
Add Team Source Display TST043015CMHX 4.3" 480x272 DPI panel compatible string. Signed-off-by: Marek Vasut Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org To: dri-devel@lists.freedesktop.org --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index f3c9395d23b6..62f5f050c1bc 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -290,6 +290,8 @@ properties: - starry,kr070pe2t # Starry 12.2" (1920x1200 pixels) TFT LCD panel - starry,kr122ea0sra +# Team Source Display Technology TST043015CMHX 4.3" WQVGA TFT LCD panel + - team-source-display,tst043015cmhx # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel - tianma,tm070jdhg30 # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel -- 2.33.0
[PATCH 1/3] dt-bindings: Add Team Source Display Technology vendor prefix
Add vendor prefix for Team Source Display Technology Co., Ltd. Signed-off-by: Marek Vasut Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org To: dri-devel@lists.freedesktop.org --- NOTE: All the documentation abbreviates the company name as TSD, but that vendor prefix is already taken. --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 84cd16fe9380..95435428f1f1 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1240,6 +1240,8 @@ patternProperties: description: Truly Semiconductors Limited "^visionox,.*": description: Visionox + "^team-source-display,.*": +description: Shenzhen Team Source Display Technology Co., Ltd. (TSD) "^tsd,.*": description: Theobroma Systems Design und Consulting GmbH "^tyan,.*": -- 2.33.0
[Bug 205089] amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125
https://bugzilla.kernel.org/show_bug.cgi?id=205089 James Clark (j...@jclark.com) changed: What|Removed |Added CC||j...@jclark.com --- Comment #28 from James Clark (j...@jclark.com) --- I am seeing this on Ubuntu 21.10: Kernel: 5.13.0 Mesa: 21.2.2 Hardware: CPU: 3950X GPU: RX 6600 This is regular desktop use: Chrome 96 with Wayland enabled (--ozone-platform=wayland --enable-features=VaapiVideoDecoder --enable-gpu-rasterization -enable-drd --enable-zero-copy --enable-canvas-oop-rasterization) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/i915/debugfs: Do not return '0' if there is nothing to return
Change functions that always return '0' to be void type.
Signed-off-by: Andi Shyti
Cc: Maciej Patelczyk
---
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 7 ---
drivers/gpu/drm/i915/gt/intel_gt_debugfs.h| 2 +-
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 16
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h | 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
5 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index f103664b71d4..53b90b4f73d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -29,7 +29,7 @@ int intel_gt_debugfs_reset_show(struct intel_gt *gt, u64 *val)
}
}
-int intel_gt_debugfs_reset_store(struct intel_gt *gt, u64 val)
+void intel_gt_debugfs_reset_store(struct intel_gt *gt, u64 val)
{
/* Flush any previous reset before applying for a new one */
wait_event(gt->reset.queue,
@@ -37,7 +37,6 @@ int intel_gt_debugfs_reset_store(struct intel_gt *gt, u64 val)
intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
"Manually reset engine mask to %llx", val);
- return 0;
}
/*
@@ -51,7 +50,9 @@ static int __intel_gt_debugfs_reset_show(void *data, u64 *val)
static int __intel_gt_debugfs_reset_store(void *data, u64 val)
{
- return intel_gt_debugfs_reset_store(data, val);
+ intel_gt_debugfs_reset_store(data, val);
+
+ return 0;
}
DEFINE_SIMPLE_ATTRIBUTE(reset_fops, __intel_gt_debugfs_reset_show,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
index e307ceb99031..a4baf8e7f068 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
@@ -37,6 +37,6 @@ void intel_gt_debugfs_register_files(struct dentry *root,
/* functions that need to be accessed by the upper level non-gt interfaces */
int intel_gt_debugfs_reset_show(struct intel_gt *gt, u64 *val);
-int intel_gt_debugfs_reset_store(struct intel_gt *gt, u64 val);
+void intel_gt_debugfs_reset_store(struct intel_gt *gt, u64 val);
#endif /* INTEL_GT_DEBUGFS_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 404dfa7673c6..7a30157aa9d3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -20,38 +20,38 @@
#include "intel_uncore.h"
#include "vlv_sideband.h"
-int intel_gt_pm_debugfs_forcewake_user_open(struct intel_gt *gt)
+void intel_gt_pm_debugfs_forcewake_user_open(struct intel_gt *gt)
{
atomic_inc(>user_wakeref);
intel_gt_pm_get(gt);
if (GRAPHICS_VER(gt->i915) >= 6)
intel_uncore_forcewake_user_get(gt->uncore);
-
- return 0;
}
-int intel_gt_pm_debugfs_forcewake_user_release(struct intel_gt *gt)
+void intel_gt_pm_debugfs_forcewake_user_release(struct intel_gt *gt)
{
if (GRAPHICS_VER(gt->i915) >= 6)
intel_uncore_forcewake_user_put(gt->uncore);
intel_gt_pm_put(gt);
atomic_dec(>user_wakeref);
-
- return 0;
}
static int forcewake_user_open(struct inode *inode, struct file *file)
{
struct intel_gt *gt = inode->i_private;
- return intel_gt_pm_debugfs_forcewake_user_open(gt);
+ intel_gt_pm_debugfs_forcewake_user_open(gt);
+
+ return 0;
}
static int forcewake_user_release(struct inode *inode, struct file *file)
{
struct intel_gt *gt = inode->i_private;
- return intel_gt_pm_debugfs_forcewake_user_release(gt);
+ intel_gt_pm_debugfs_forcewake_user_release(gt);
+
+ return 0;
}
static const struct file_operations forcewake_user_fops = {
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h
index a8457887ec65..0ace8c2da0ac 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h
@@ -14,7 +14,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct
dentry *root);
void intel_gt_pm_frequency_dump(struct intel_gt *gt, struct drm_printer *m);
/* functions that need to be accessed by the upper level non-gt interfaces */
-int intel_gt_pm_debugfs_forcewake_user_open(struct intel_gt *gt);
-int intel_gt_pm_debugfs_forcewake_user_release(struct intel_gt *gt);
+void intel_gt_pm_debugfs_forcewake_user_open(struct intel_gt *gt);
+void intel_gt_pm_debugfs_forcewake_user_release(struct intel_gt *gt);
#endif /* INTEL_GT_PM_DEBUGFS_H */
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fe638b5da7c0..88ef63f05ead 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -565,7 +565,9 @@ static int i915_wedged_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
Re: [PATCH v3 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API
Hi Zhi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm/drm-next
tegra-drm/drm/tegra/for-next v5.16-rc2 next-20211126]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Zhi-Wang/i915-gvt-Introduce-the-mmio_info_table-c-to-support-VFIO-new-mdev-API/20211126-194800
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel-8.3
(https://download.01.org/0day-ci/archive/20211127/202111270654.ibld57di-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/82dadc38be63d9271031336db366cd71104df3a0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Zhi-Wang/i915-gvt-Introduce-the-mmio_info_table-c-to-support-VFIO-new-mdev-API/20211126-194800
git checkout 82dadc38be63d9271031336db366cd71104df3a0
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gvt/mmio_info_table.c:1414: warning: expecting
>> prototype for intel_gvt_setup_mmio_table(). Prototype was for
>> intel_gvt_setup_mmio_info() instead
vim +1414 drivers/gpu/drm/i915/gvt/mmio_info_table.c
1402
1403 /**
1404 * intel_gvt_setup_mmio_table - setup MMIO information table for GVT
device
1405 * @gvt: GVT device
1406 *
1407 * This function is called at the initialization stage, to setup the
MMIO
1408 * information table for GVT device
1409 *
1410 * Returns:
1411 * zero on success, negative if failed.
1412 */
1413 int intel_gvt_setup_mmio_info(struct intel_gvt *gvt)
> 1414 {
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH] drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_a*.c
On Fri, Nov 26, 2021 at 04:45:46PM +0100, Daniel Vetter wrote:
> On Fri, Nov 26, 2021 at 11:49:49AM +0100, Claudio Suarez wrote:
> > DRM_DEBUG_* and DRM_* log calls are deprecated.
> > Change them to drm_dbg_* / drm_{err,info,...} calls in drm core
> > files.
> >
> > To avoid making a very big patch, this change is split in
> > smaller patches. This one includes drm_a*.c
> >
> > Signed-off-by: Claudio Suarez
>
> lgtm, merged into drm-misc-next, thanks for the patch.
> -Daniel
Thanks to you, Daniel.
Best regards
Claudio Suarez
Re: [PATCH] drm/msm: Initialize MDSS irq domain at probe time
On 26/11/2021 12:26, AngeloGioacchino Del Regno wrote:
Il 26/11/21 01:06, Dmitry Baryshkov ha scritto:
On 25/11/2021 18:09, AngeloGioacchino Del Regno wrote:
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
DSI host gets initialized earlier, but this caused unability to probe
the entire stack of components because they all depend on interrupts
coming from the main `mdss` node (mdp5, or dpu1).
To fix this issue, also anticipate probing mdp5 or dpu1 by initializing
them at msm_pdev_probe() time: this will make sure that we add the
required interrupt controller mapping before dsi and/or other components
try to initialize, finally satisfying the dependency.
While at it, also change the allocation of msm_drm_private to use the
devm variant of kzalloc().
Fixes: 8f59ee9a570c ("drm/msm/dsi: Adjust probe order")
Signed-off-by: AngeloGioacchino Del Regno
Another issue (or a pack of issues):
Now the msm_drm_init() is unbalanced with msm_drm_uninit(). Bits of
code (putting the drm dev, removing the IRQ domain, etc) have to be
called now from the msm_pdev_remove() function rather than from the
unbind path.
The following changes fix the observed issues here, however additional
care should be taken.
Hello Dmitry,
thanks for the thorough review (and solutions!).
Are you going to push your changes on top, or should I send a V2?
Please send a v2. As you see, my suggestions have to be validated too
(and they were based on crashes/issues observed locally).
--
With best wishes
Dmitry
Re: [PATCH v2 00/13] drm: Add generic helpers for HDMI scrambling
On Fri, Nov 26, 2021 at 04:43:49PM +0100, Maxime Ripard wrote: > Hi Daniel, > > On Fri, Nov 19, 2021 at 05:01:14PM +0100, Daniel Vetter wrote: > > On Thu, Nov 18, 2021 at 11:38:01AM +0100, Maxime Ripard wrote: > > > This is a follow-up of the work to support the interactions between the > > > hotplug > > > and the scrambling support for vc4: > > > > > > https://lore.kernel.org/dri-devel/20210507150515.257424-11-max...@cerno.tech/ > > > https://lore.kernel.org/dri-devel/20211025152903.1088803-10-max...@cerno.tech/ > > > > > > Ville feedback was that the same discussion happened some time ago for > > > i915, > > > and resulted in a function to do an full disable/enable cycle on > > > reconnection > > > to avoid breaking the HDMI 2.0 spec. > > > > > > This series improves the current scrambling support by adding generic > > > helpers > > > for usual scrambling-related operations, and builds upon them to provide a > > > generic alternative to intel_hdmi_reset_link. > > > > Out of curiosity, can we rebuild intel_hdmi_reset_link on top of these? > > Always better to have two drivers to actually show the helpers help, than > > just one. > > Unfortunately, I don't have any Intel system I can test it on, and it > looks like the changes wouldn't be trivial. > > Maybe we can use dw-hdmi instead? Hm I guess so, maybe Ville can be motivated. Just figured since this seems at least inspired by i915 code. Also we have CI running on intel-gfx, so if you just type well enough it generally works out and CI catches anything you got wrong. Christian König is pretty good at not breaking i915 with all the dma-buf and ttm changes nowadays, much better than random arm socs dying. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [i-g-t 03/14] kms_color_helper: Add helper functions for plane color mgmt
On 2021-11-15 04:47, Bhanuprakash Modem wrote:
> Add helper functions to support Plane color management properties.
>
> Cc: Harry Wentland
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> Cc: Uma Shankar
> Signed-off-by: Bhanuprakash Modem
> ---
> tests/kms_color_helper.c | 173 +++
> tests/kms_color_helper.h | 29 +++
> 2 files changed, 202 insertions(+)
>
> diff --git a/tests/kms_color_helper.c b/tests/kms_color_helper.c
> index d71e7bb2e6..c65b7a0f50 100644
> --- a/tests/kms_color_helper.c
> +++ b/tests/kms_color_helper.c
> @@ -241,6 +241,150 @@ void disable_prop(igt_pipe_t *pipe, enum
> igt_atomic_crtc_properties prop)
> igt_pipe_obj_replace_prop_blob(pipe, prop, NULL, 0);
> }
>
> +drmModePropertyPtr get_plane_gamma_degamma_mode(igt_plane_t *plane,
> + enum igt_atomic_plane_properties prop)
> +{
> + igt_display_t *display = plane->pipe->display;
> + uint32_t prop_id = plane->props[prop];
> + drmModePropertyPtr drmProp;
> +
> + igt_assert(prop_id);
> +
> + drmProp = drmModeGetProperty(display->drm_fd, prop_id);
> +
> + igt_assert(drmProp);
> + igt_assert(drmProp->count_enums);
> +
> + return drmProp;
> +}
> +
> +struct drm_color_lut_ext *create_linear_lut(segment_data_t *info)
> +{
> + uint32_t val, segment, entry, index = 0;
> + uint32_t max_val = 0x;
> + struct drm_color_lut_ext *lut = malloc(sizeof(struct drm_color_lut_ext)
> * info->entries_count);
> + igt_assert(lut);
> +
> + for (segment = 0; segment < info->segment_count; segment++) {
> + uint32_t entry_count = info->segment_data[segment].count;
> + uint32_t start = info->segment_data[segment].start;
> + uint32_t end = info->segment_data[segment].end;
> +
> + for (entry = 1; entry <= entry_count; entry++) {
> + val = (index == 0) ? /* First entry is Zero. */
> + 0 : start + entry * ((end - start) * 1.0 /
> entry_count);
> +
> + lut[index].red = lut[index].green = lut[index].blue =
> MIN(val, max_val);
> +
> + index++;
> + }
> + }
> +
> + return lut;
> +}
> +
> +struct drm_color_lut_ext *create_max_lut(segment_data_t *info)
> +{
> + int i;
> + struct drm_color_lut_ext *lut;
> + uint32_t max_val = 0x;
> +
> + lut = malloc(sizeof(struct drm_color_lut_ext) * info->entries_count);
> + igt_assert(lut);
> +
> + lut[0].red = lut[0].green = lut[0].blue = 0; /* First entry is Zero. */
> +
> + for (i = 1; i < info->entries_count; i++)
> + lut[i].red = lut[i].green = lut[i].blue = max_val;
> +
> + return lut;
> +}
> +
> +void clear_segment_data(segment_data_t *info)
> +{
> + if (!info)
> + return;
> +
> + free(info->segment_data);
> + free(info);
> +}
> +
> +segment_data_t *get_segment_data(data_t *data,
> + uint64_t blob_id, char *mode)
> +{
> + drmModePropertyBlobPtr blob;
> + struct drm_color_lut_range *lut_range = NULL;
> + segment_data_t *info = NULL;
> + uint32_t i;
> +
> + blob = drmModeGetPropertyBlob(data->drm_fd, blob_id);
> + igt_assert(blob);
> + igt_assert(blob->length);
> +
> + info = malloc(sizeof(segment_data_t));
> + igt_assert(info);
> +
> + lut_range = (struct drm_color_lut_range *) blob->data;
> + info->segment_count = blob->length / sizeof(lut_range[0]);
> + igt_assert(info->segment_count);
> +
> + info->segment_data = malloc(sizeof(struct drm_color_lut_range) *
> info->segment_count);
> + igt_assert(info->segment_data);
> +
> + for (i = 0; i < info->segment_count; i++) {
> + info->entries_count += lut_range[i].count;
> + info->segment_data[i] = lut_range[i];
> + }
> +
> + drmModeFreePropertyBlob(blob);
> +
> + return info;
> +}
> +
> +void set_plane_gamma(igt_plane_t *plane,
> + char *mode,
> + struct drm_color_lut_ext *lut,
> + uint32_t size)
> +{
> + igt_plane_set_prop_enum(plane, IGT_PLANE_GAMMA_MODE, mode);
> + igt_plane_replace_prop_blob(plane, IGT_PLANE_GAMMA_LUT, lut, size);
> +}
> +
> +void set_plane_degamma(igt_plane_t *plane,
> + char *mode,
> + struct drm_color_lut_ext *lut,
> + uint32_t size)
> +{
> + igt_plane_set_prop_enum(plane, IGT_PLANE_DEGAMMA_MODE, mode);
> + igt_plane_replace_prop_blob(plane, IGT_PLANE_DEGAMMA_LUT, lut, size);
> +}
> +
> +void set_plane_ctm(igt_plane_t *plane, const double *coefficients)
> +{
> + struct drm_color_ctm ctm;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(ctm.matrix); i++) {
> + if (coefficients[i] < 0) {
> + ctm.matrix[i] =
> + (int64_t) (-coefficients[i] *
> + ((int64_t) 1L << 32));
> +
Re: [i-g-t 12/14] kms_color_helper: Add helper functions to support logarithmic gamma mode
On 2021-11-15 04:47, Bhanuprakash Modem wrote:
> From: Mukunda Pramodh Kumar
>
> Add helper functions to support logarithmic gamma mode
>
> Cc: Harry Wentland
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> Cc: Uma Shankar
> Signed-off-by: Mukunda Pramodh Kumar
> Signed-off-by: Bhanuprakash Modem
> ---
> tests/kms_color_helper.c | 127 +++
> tests/kms_color_helper.h | 16 +
> 2 files changed, 143 insertions(+)
>
> diff --git a/tests/kms_color_helper.c b/tests/kms_color_helper.c
> index c65b7a0f50..7ea8282df3 100644
> --- a/tests/kms_color_helper.c
> +++ b/tests/kms_color_helper.c
> @@ -190,6 +190,33 @@ struct drm_color_lut *coeffs_to_lut(data_t *data,
> return lut;
> }
>
> +struct drm_color_lut *coeffs_to_logarithmic_lut(data_t *data,
> + const gamma_lut_t *gamma,
> + uint32_t color_depth,
> + int off)
How does this create a logarithmic LUT? It seems to do the same
as coeffs_to_lut (which is also full of intellisms) except that
it also scales the values by max_hw_value / max_segment_value for
reasons that are not obvious to me.
> +{
> + struct drm_color_lut *lut;
> + int i, lut_size = gamma->size;
> + /* This is the maximum value due to 16 bit precision in hardware. */
> + uint32_t max_hw_value = (1 << 16) - 1;
> + unsigned int max_segment_value = 1 << 24;
> +
This looks like it is specific to Intel HW. Intel-specific things should
not live in kms_ tests.
Shouldn't these be encoded in the drm_color_lut_range definitions?
To be honest I am not clear why max_hw_value and max_segment_value
differ here.
Harry
> + lut = malloc(sizeof(struct drm_color_lut) * lut_size);
> +
> + for (i = 0; i < lut_size; i++) {
> + double scaling_factor = (double)max_hw_value /
> (double)max_segment_value;
> + uint32_t r = MIN((gamma->coeffs[i].r * scaling_factor),
> max_hw_value);
> + uint32_t g = MIN((gamma->coeffs[i].g * scaling_factor),
> max_hw_value);
> + uint32_t b = MIN((gamma->coeffs[i].b * scaling_factor),
> max_hw_value);
> +
> + lut[i].red = r;
> + lut[i].green = g;
> + lut[i].blue = b;
> + }
> +
> + return lut;
> +}
> +
> void set_degamma(data_t *data,
>igt_pipe_t *pipe,
>const gamma_lut_t *gamma)
> @@ -203,6 +230,15 @@ void set_degamma(data_t *data,
> free(lut);
> }
>
> +void set_pipe_gamma(igt_pipe_t *pipe,
> + uint64_t value,
> + struct drm_color_lut *lut,
> + uint32_t size)
> +{
> + igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_GAMMA_MODE, value);
> + igt_pipe_obj_replace_prop_blob(pipe, IGT_CRTC_GAMMA_LUT, lut, size);
> +}
> +
> void set_gamma(data_t *data,
> igt_pipe_t *pipe, const gamma_lut_t *gamma)
> {
> @@ -241,6 +277,51 @@ void disable_prop(igt_pipe_t *pipe, enum
> igt_atomic_crtc_properties prop)
> igt_pipe_obj_replace_prop_blob(pipe, prop, NULL, 0);
> }
>
> +drmModePropertyPtr get_pipe_gamma_degamma_mode(igt_pipe_t *pipe,
> +enum igt_atomic_crtc_properties
> prop)
> +{
> + igt_display_t *display = pipe->display;
> + uint32_t prop_id = pipe->props[prop];
> + drmModePropertyPtr drmProp;
> +
> + igt_assert(prop_id);
> +
> + drmProp = drmModeGetProperty(display->drm_fd, prop_id);
> +
> + igt_assert(drmProp);
> + igt_assert(drmProp->count_enums);
> +
> + return drmProp;
> +}
> +
> +gamma_lut_t *pipe_create_linear_lut(segment_data_t *info)
> +{
> + uint32_t segment, entry, index = 0;
> + double val;
> + int i = 0;
> + gamma_lut_t *gamma = alloc_lut(info->entries_count);
> +
> + igt_assert(gamma);
> +
> + gamma->size = info->entries_count;
> + for (segment = 0; segment < info->segment_count; segment++) {
> + uint32_t entry_count = info->segment_data[segment].count;
> + uint32_t start = (segment == 0) ? 0 : (1 << (segment - 1));
> + uint32_t end = 1 << segment;
> +
> + for (entry = 0; entry < entry_count; entry++) {
> + val = (index == 0) ? /* First entry is Zero. */
> + 0 : start + entry *
> + ((end - start) * 1.0 / entry_count);
> +
> + set_rgb(>coeffs[i++], val);
> + index++;
> + }
> + }
> +
> + return gamma;
> +}
> +
> drmModePropertyPtr get_plane_gamma_degamma_mode(igt_plane_t *plane,
> enum igt_atomic_plane_properties prop)
> {
> @@ -331,6 +412,7 @@ segment_data_t *get_segment_data(data_t *data,
> info->segment_data = malloc(sizeof(struct drm_color_lut_range) *
> info->segment_count);
> igt_assert(info->segment_data);
>
> +
Re: [i-g-t 06/14] tests/kms_color: New subtests for Plane CTM
On 2021-11-15 04:47, Bhanuprakash Modem wrote:
> To verify plane CTM, draw 3 rectangles using before colors with the
> ctm matrix applied and verify the CRC is equal to using after colors
> with an identify ctm matrix.
>
> Cc: Harry Wentland
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> Cc: Uma Shankar
> Signed-off-by: Bhanuprakash Modem
> ---
> tests/kms_color.c | 225 ++
> 1 file changed, 225 insertions(+)
>
> diff --git a/tests/kms_color.c b/tests/kms_color.c
> index 920a5eaadd..e14b37cb6f 100644
> --- a/tests/kms_color.c
> +++ b/tests/kms_color.c
> @@ -53,6 +53,77 @@ static bool is_valid_plane(igt_plane_t *plane)
> return index >= 0 && index < MAX_SUPPORTED_PLANES;
> }
>
> +struct {
> + const char *test_name;
> + int iter;
> + color_t expected_colors[3];
> + double ctm[9];
> +} ctm_tests[] = {
> + {"plane-ctm-red-to-blue", 0,
> + {{ 0.0, 0.0, 1.0 },
> + { 0.0, 1.0, 0.0 },
> + { 0.0, 0.0, 1.0 }},
> + { 0.0, 0.0, 0.0,
> + 0.0, 1.0, 0.0,
> + 1.0, 0.0, 1.0 },
> + },
> + {"plane-ctm-green-to-red", 0,
> + {{ 1.0, 0.0, 0.0 },
> + { 1.0, 0.0, 0.0 },
> + { 0.0, 0.0, 1.0 }},
> + { 1.0, 1.0, 0.0,
> + 0.0, 0.0, 0.0,
> + 0.0, 0.0, 1.0 },
> + },
> + {"plane-ctm-blue-to-red", 0,
> + {{ 1.0, 0.0, 0.0 },
> + { 0.0, 1.0, 0.0 },
> + { 1.0, 0.0, 0.0 }},
> + { 1.0, 0.0, 1.0,
> + 0.0, 1.0, 0.0,
> + 0.0, 0.0, 0.0 },
> + },
> + {"plane-ctm-max", 0,
> + {{ 1.0, 0.0, 0.0 },
> + { 0.0, 1.0, 0.0 },
> + { 0.0, 0.0, 1.0 }},
> + { 100.0, 0.0, 0.0,
> + 0.0, 100.0, 0.0,
> + 0.0, 0.0, 100.0 },
> + },
> + {"plane-ctm-negative", 0,
> + {{ 0.0, 0.0, 0.0 },
> + { 0.0, 0.0, 0.0 },
> + { 0.0, 0.0, 0.0 }},
> + { -1.0, 0.0, 0.0,
> +0.0, -1.0, 0.0,
> +0.0, 0.0, -1.0 },
> + },
> + /* We tests a few values around the expected result because
> + * it depends on the hardware we're dealing with, we can
> + * either get clamped or rounded values and we also need to
> + * account for odd number of items in the LUTs.
> + */
> + {"plane-ctm-0-25", 5,
> + {{ 0.0, }, { 0.0, }, { 0.0, }},
> + { 0.25, 0.0, 0.0,
> + 0.0, 0.25, 0.0,
> + 0.0, 0.0, 0.25 },
> + },
> + {"plane-ctm-0-50", 5,
> + {{ 0.0, }, { 0.0, }, { 0.0, }},
> + { 0.5, 0.0, 0.0,
> + 0.0, 0.5, 0.0,
> + 0.0, 0.0, 0.5 },
> + },
> + {"plane-ctm-0-75", 7,
> + {{ 0.0, }, { 0.0, }, { 0.0, }},
> + { 0.75, 0.0, 0.0,
> + 0.0, 0.75, 0.0,
> + 0.0, 0.0, 0.75 },
> + },
> +};
> +
> static void test_pipe_degamma(data_t *data,
> igt_plane_t *primary)
> {
> @@ -900,6 +971,99 @@ static bool plane_degamma_test(data_t *data, igt_plane_t
> *plane)
> return ret;
> }
>
> +static bool test_plane_ctm(data_t *data,
> + igt_plane_t *plane,
> + color_t *before,
> + color_t *after,
> + double *ctm_matrix)
> +{
> + const double ctm_identity[] = {
> + 1.0, 0.0, 0.0,
> + 0.0, 1.0, 0.0,
> + 0.0, 0.0, 1.0
> + };
> + igt_output_t *output;
> + igt_display_t *display = >display;
> + drmModeModeInfo *mode;
> + struct igt_fb fb;
> + igt_crc_t crc_software, crc_hardware;
> + igt_pipe_crc_t *pipe_crc = NULL;
> + bool ret = true;
> +
> + igt_info("Plane CTM test is running on pipe-%s plane-%s(%s)\n",
> + kmstest_pipe_name(plane->pipe->pipe),
> + kmstest_plane_type_name(plane->type),
> + is_hdr_plane(plane) ? "hdr":"sdr");
> +
> + igt_require(igt_plane_has_prop(plane, IGT_PLANE_CTM));
> +
> + pipe_crc = igt_pipe_crc_new(data->drm_fd,
> + plane->pipe->pipe,
> + INTEL_PIPE_CRC_SOURCE_AUTO);
> +
> + output = igt_get_single_output_for_pipe(display, plane->pipe->pipe);
> + igt_assert(output);
> +
> + igt_output_set_pipe(output, plane->pipe->pipe);
> + mode =
Re: [i-g-t 04/14] tests/kms_color: New subtests for Plane gamma
On 2021-11-15 04:47, Bhanuprakash Modem wrote:
> To verify Plane gamma, draw 3 gradient rectangles in red, green and blue,
> with a maxed out gamma LUT and verify we have the same CRC as drawing solid
> color rectangles.
>
> Cc: Harry Wentland
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> Cc: Uma Shankar
> Signed-off-by: Bhanuprakash Modem
> ---
> tests/kms_color.c | 179 +-
> 1 file changed, 178 insertions(+), 1 deletion(-)
>
> diff --git a/tests/kms_color.c b/tests/kms_color.c
> index 775f35964f..b45d66762f 100644
> --- a/tests/kms_color.c
> +++ b/tests/kms_color.c
> @@ -24,7 +24,34 @@
>
> #include "kms_color_helper.h"
>
> -IGT_TEST_DESCRIPTION("Test Color Features at Pipe level");
> +IGT_TEST_DESCRIPTION("Test Color Features at Pipe & Plane level");
> +
> +#define MAX_SUPPORTED_PLANES 7
> +#define SDR_PLANE_BASE 3
> +
> +typedef bool (*test_t)(data_t*, igt_plane_t*);
> +
> +static bool is_hdr_plane(const igt_plane_t *plane)
> +{
> + return plane->index >= 0 && plane->index < SDR_PLANE_BASE;
> +}
> +
> +static bool is_valid_plane(igt_plane_t *plane)
> +{
> + int index = plane->index;
> +
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> + return false;
> +
> + /*
> + * Test 1 HDR plane, 1 SDR plane.
> + *
> + * 0,1,2 HDR planes
> + * 3,4,5,6 SDR planes
> + *
> + */
This seems to be about Intel HW. AMD HW for example does
not have HDR or SDR planes, only one generic plane.
> + return index >= 0 && index < MAX_SUPPORTED_PLANES;
> +}
>
> static void test_pipe_degamma(data_t *data,
> igt_plane_t *primary)
> @@ -638,6 +665,122 @@ static void test_pipe_limited_range_ctm(data_t *data,
> }
> #endif
>
> +static bool plane_gamma_test(data_t *data, igt_plane_t *plane)
> +{
> + igt_output_t *output;
> + igt_display_t *display = >display;
> + drmModeModeInfo *mode;
> + struct igt_fb fb;
> + drmModePropertyPtr gamma_mode = NULL;
> + uint32_t i;
> + bool ret = true;
> + igt_pipe_crc_t *pipe_crc = NULL;
> + color_t red_green_blue[] = {
> + { 1.0, 0.0, 0.0 },
> + { 0.0, 1.0, 0.0 },
> + { 0.0, 0.0, 1.0 }
> + };
> +
> + igt_info("Plane gamma test is running on pipe-%s plane-%s(%s)\n",
> + kmstest_pipe_name(plane->pipe->pipe),
> + kmstest_plane_type_name(plane->type),
> + is_hdr_plane(plane) ? "hdr":"sdr");
> +
is_hdr_plane is Intel-specific.
> + igt_require(igt_plane_has_prop(plane, IGT_PLANE_GAMMA_MODE));
> + igt_require(igt_plane_has_prop(plane, IGT_PLANE_GAMMA_LUT));
> +
> + pipe_crc = igt_pipe_crc_new(data->drm_fd,
> + plane->pipe->pipe,
> + INTEL_PIPE_CRC_SOURCE_AUTO);
> +
> + output = igt_get_single_output_for_pipe(display, plane->pipe->pipe);
> + igt_assert(output);
> +
> + igt_output_set_pipe(output, plane->pipe->pipe);
> + mode = igt_output_get_mode(output);
> +
> + /* Create a framebuffer at the size of the output. */
> + igt_assert(igt_create_fb(data->drm_fd,
> + mode->hdisplay,
> + mode->vdisplay,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_MOD_LINEAR,
> + ));
> + igt_plane_set_fb(plane, );
> +
> + /* Disable Pipe color props. */
> + disable_ctm(plane->pipe);
> + disable_degamma(plane->pipe);
> + disable_gamma(plane->pipe);
> +
> + disable_plane_ctm(plane);
> + disable_plane_degamma(plane);
> + igt_display_commit2(display, display->is_atomic ?
> + COMMIT_ATOMIC : COMMIT_LEGACY);
> +
> + gamma_mode = get_plane_gamma_degamma_mode(plane, IGT_PLANE_GAMMA_MODE);
> +
> + /* Iterate all supported gamma modes. */
> + for (i = 0; i < gamma_mode->count_enums; i++) {
> + igt_crc_t crc_gamma, crc_fullcolors;
> + segment_data_t *segment_info = NULL;
> + struct drm_color_lut_ext *lut = NULL;
> + uint32_t lut_size = 0;
> +
> + /* Ignore 'no gamma' from enum list. */
> + if (!strcmp(gamma_mode->enums[i].name, "no gamma"))
> + continue;
> +
It might still make sense to test that this is doing bypass.
> + igt_info("Trying to use gamma mode: \'%s\'\n",
> gamma_mode->enums[i].name);
> +
> + /* Draw solid colors with no gamma transformation. */
> + disable_plane_gamma(plane);
> + paint_rectangles(data, mode, red_green_blue, );
> + igt_plane_set_fb(plane, );
> + igt_display_commit2(display, display->is_atomic ?
> + COMMIT_ATOMIC : COMMIT_LEGACY);
> + igt_wait_for_vblank(data->drm_fd,
> +
Re: [i-g-t 00/14] Add IGT support for plane color management
On 2021-11-18 04:50, Pekka Paalanen wrote: > On Mon, 15 Nov 2021 15:17:45 +0530 > Bhanuprakash Modem wrote: > >> From the Plane Color Management feature design, userspace can >> take the smart blending decisions based on hardware supported >> plane color features to obtain an accurate color profile. >> >> These IGT patches extend the existing pipe color management >> tests to the plane level. >> >> Kernel implementation: >> https://patchwork.freedesktop.org/series/90825/ > Are these tested and passing on any current or future Intel HW? > Hi, > > it's really good to get these, but I am worried that the tests here may > be too easy to pass when trying to ensure the KMS features work > correctly and in the way real userspace is going to be using them. > In particular per-plane color management is mainly beneficial when using HW composition, i.e. plane blending. I don't see tests for plane blending. Another thing that would be good to test is to make sure the order of operations is as documented in the KMS API, i.e. degamma -> CTM -> gamma. In order to test this it might be good to create a test case that sets these operations up in a way that only yields the expected outcome if they are implemented in this order. Last, and likely not easy to test, is the precision or accuracy of the PWL though I am unsure whether we can even test this at all with CRC. It looks like we might be able to test this with the Chamelium to some degree. > I also found some things that looked hardware-specific in this code > that to my understanding is supposed to be generic, and some concerns > about UAPI as well. > I left some comments on intellisms in these patches. Do you have any specifics about your concerns about UAPI? Harry > > Thanks, > pq > >> Bhanuprakash Modem (11): >> HAX: Get uapi headers to compile the IGT >> lib/igt_kms: Add plane color mgmt properties >> kms_color_helper: Add helper functions for plane color mgmt >> tests/kms_color: New subtests for Plane gamma >> tests/kms_color: New subtests for Plane degamma >> tests/kms_color: New subtests for Plane CTM >> tests/kms_color: New negative tests for plane level color mgmt >> tests/kms_color_chamelium: New subtests for Plane gamma >> tests/kms_color_chamelium: New subtests for Plane degamma >> tests/kms_color_chamelium: New subtests for Plane CTM >> tests/kms_color_chamelium: Extended IGT tests to support logarithmic >> gamma mode >> >> Mukunda Pramodh Kumar (3): >> lib/igt_kms: Add pipe color mgmt properties >> kms_color_helper: Add helper functions to support logarithmic gamma >> mode >> tests/kms_color: Extended IGT tests to support logarithmic gamma mode >> >> include/drm-uapi/drm.h | 10 + >> include/drm-uapi/drm_mode.h | 28 ++ >> lib/igt_kms.c | 6 + >> lib/igt_kms.h | 6 + >> tests/kms_color.c | 674 +++- >> tests/kms_color_chamelium.c | 588 ++- >> tests/kms_color_helper.c| 300 >> tests/kms_color_helper.h| 45 +++ >> 8 files changed, 1648 insertions(+), 9 deletions(-) >> >> -- >> 2.32.0 >> >
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #82 from James Zhu (jam...@amd.com) --- Hi @kolAflash, I don't have issue with your .config. on ubuntu 20.04 >From source code, it should be fine. $ grep -rn "kgd2kfd_resume_iommu" drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 309:int kgd2kfd_resume_iommu(struct kfd_dev *kfd); $ grep -rn "amdgpu_amdkfd.h\|kgd2kfd_resume_iommu" drivers/gpu/drm/amd/amdkfd/kfd_device.c 31:#include "amdgpu_amdkfd.h" 604:kfd->pci_atomic_requested = amdgpu_amdkfd_have_atomics_support(kgd); 792:if (kgd2kfd_resume_iommu(kfd)) 940:int kgd2kfd_resume_iommu(struct kfd_dev *kfd) Looks we are using different 5.10, should we use 5.10 stable for adding this backport patches?. 754 | if (kgd2kfd_resume_iommu(kfd)) | ^~~~ | kgd2kfd_resume_mm Best Regards! James -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 15/20] drm/tegra: hdmi: Register audio CODEC on Tegra20
Tegra20 SoC supports only S/PDIF source for HDMI audio. Register ASoC HDMI
S/PDIF CODEC for Tegra20, it will be linked with the S/PDIF CPU DAI.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/Kconfig | 3 +
drivers/gpu/drm/tegra/hdmi.c | 153 +++---
2 files changed, 145 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 32fe64553d2e..40f0d14cb240 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -13,6 +13,9 @@ config DRM_TEGRA_ORIG
select INTERCONNECT
select IOMMU_IOVA
select CEC_CORE if CEC_NOTIFIER
+ select SND_SIMPLE_CARD if SND_SOC_TEGRA20_SPDIF
+ select SND_SOC_HDMI_CODEC if SND_SOC_TEGRA20_SPDIF
+ select SND_AUDIO_GRAPH_CARD if SND_SOC_TEGRA20_SPDIF
help
Choose this option if you have an NVIDIA Tegra SoC.
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 142ad696426f..a99861f95e89 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -18,6 +18,8 @@
#include
+#include
+
#include
#include
#include
@@ -81,6 +83,9 @@ struct tegra_hdmi {
bool dvi;
struct drm_info_list *debugfs_files;
+
+ struct platform_device *audio_pdev;
+ struct mutex audio_lock;
};
static inline struct tegra_hdmi *
@@ -363,6 +368,18 @@ static const struct tmds_config tegra124_tmds_config[] = {
},
};
+static void tegra_hdmi_audio_lock(struct tegra_hdmi *hdmi)
+{
+ mutex_lock(>audio_lock);
+ disable_irq(hdmi->irq);
+}
+
+static void tegra_hdmi_audio_unlock(struct tegra_hdmi *hdmi)
+{
+ enable_irq(hdmi->irq);
+ mutex_unlock(>audio_lock);
+}
+
static int
tegra_hdmi_get_audio_config(unsigned int audio_freq, unsigned int pix_clock,
struct tegra_hdmi_audio_config *config)
@@ -832,6 +849,23 @@ static void tegra_hdmi_setup_tmds(struct tegra_hdmi *hdmi,
HDMI_NV_PDISP_SOR_IO_PEAK_CURRENT);
}
+static int tegra_hdmi_reconfigure_audio(struct tegra_hdmi *hdmi)
+{
+ int err;
+
+ err = tegra_hdmi_setup_audio(hdmi);
+ if (err < 0) {
+ tegra_hdmi_disable_audio_infoframe(hdmi);
+ tegra_hdmi_disable_audio(hdmi);
+ } else {
+ tegra_hdmi_setup_audio_infoframe(hdmi);
+ tegra_hdmi_enable_audio_infoframe(hdmi);
+ tegra_hdmi_enable_audio(hdmi);
+ }
+
+ return err;
+}
+
static bool tegra_output_is_hdmi(struct tegra_output *output)
{
struct edid *edid;
@@ -1138,6 +1172,8 @@ static void tegra_hdmi_encoder_disable(struct drm_encoder
*encoder)
u32 value;
int err;
+ tegra_hdmi_audio_lock(hdmi);
+
/*
* The following accesses registers of the display controller, so make
* sure it's only executed when the output is attached to one.
@@ -1162,6 +1198,10 @@ static void tegra_hdmi_encoder_disable(struct
drm_encoder *encoder)
tegra_hdmi_writel(hdmi, 0, HDMI_NV_PDISP_INT_ENABLE);
tegra_hdmi_writel(hdmi, 0, HDMI_NV_PDISP_INT_MASK);
+ hdmi->pixel_clock = 0;
+
+ tegra_hdmi_audio_unlock(hdmi);
+
err = host1x_client_suspend(>client);
if (err < 0)
dev_err(hdmi->dev, "failed to suspend: %d\n", err);
@@ -1185,6 +1225,8 @@ static void tegra_hdmi_encoder_enable(struct drm_encoder
*encoder)
return;
}
+ tegra_hdmi_audio_lock(hdmi);
+
/*
* Enable and unmask the HDA codec SCRATCH0 register interrupt. This
* is used for interoperability between the HDA codec driver and the
@@ -1390,6 +1432,8 @@ static void tegra_hdmi_encoder_enable(struct drm_encoder
*encoder)
}
/* TODO: add HDCP support */
+
+ tegra_hdmi_audio_unlock(hdmi);
}
static int
@@ -1419,6 +1463,91 @@ static const struct drm_encoder_helper_funcs
tegra_hdmi_encoder_helper_funcs = {
.atomic_check = tegra_hdmi_encoder_atomic_check,
};
+static int tegra_hdmi_hw_params(struct device *dev, void *data,
+ struct hdmi_codec_daifmt *fmt,
+ struct hdmi_codec_params *hparms)
+{
+ struct tegra_hdmi *hdmi = data;
+ int ret = 0;
+
+ tegra_hdmi_audio_lock(hdmi);
+
+ hdmi->format.sample_rate = hparms->sample_rate;
+ hdmi->format.channels = hparms->channels;
+
+ if (hdmi->pixel_clock && !hdmi->dvi)
+ ret = tegra_hdmi_reconfigure_audio(hdmi);
+
+ tegra_hdmi_audio_unlock(hdmi);
+
+ return ret;
+}
+
+static int tegra_hdmi_audio_startup(struct device *dev, void *data)
+{
+ struct tegra_hdmi *hdmi = data;
+ int ret;
+
+ ret = host1x_client_resume(>client);
+ if (ret < 0)
+ dev_err(hdmi->dev, "failed to resume: %d\n", ret);
+
+ return ret;
+}
+
+static void
[PATCH v2 20/20] ARM: tegra: paz00: Enable S/PDIF and HDMI audio
Enable S/PDIF controller to enable HDMI audio support on Toshiba AC100.
Use nvidia,fixed-parent-rate property that prevents audio rate conflict
between S/PDIF and I2S.
Tested-by: Agneli
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20-paz00.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
index 5b2260f61f05..921a811632a1 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -264,8 +264,16 @@ conf_ld17_0 {
};
};
+ spdif@70002400 {
+ status = "okay";
+
+ nvidia,fixed-parent-rate;
+ };
+
i2s@70002800 {
status = "okay";
+
+ nvidia,fixed-parent-rate;
};
serial@70006000 {
--
2.33.1
[PATCH v2 16/20] ARM: tegra_defconfig: Enable S/PDIF driver
Enable Tegra20 S/PDIF driver. It's a part of HDMI audio subsystem on Tegra. Signed-off-by: Dmitry Osipenko --- arch/arm/configs/tegra_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index 817b39190d54..1b8f8fdbedc5 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -235,6 +235,7 @@ CONFIG_SND_HDA_CODEC_HDMI=y CONFIG_SND_SOC=y CONFIG_SND_SOC_TEGRA=y CONFIG_SND_SOC_TEGRA20_I2S=y +CONFIG_SND_SOC_TEGRA20_SPDIF=y CONFIG_SND_SOC_TEGRA30_I2S=y CONFIG_SND_SOC_TEGRA_RT5640=y CONFIG_SND_SOC_TEGRA_WM8753=y -- 2.33.1
[PATCH v2 19/20] ARM: tegra: acer-a500: Enable S/PDIF and HDMI audio
Enable S/PDIF controller to enable HDMI audio support on Acer A500.
Use nvidia,fixed-parent-rate property that prevents audio rate conflict
between S/PDIF and I2S.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
index db388ddd062f..f47b946627c3 100644
--- a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -376,8 +376,16 @@ pta {
};
};
+ tegra_spdif: spdif@70002400 {
+ status = "okay";
+
+ nvidia,fixed-parent-rate;
+ };
+
tegra_i2s1: i2s@70002800 {
status = "okay";
+
+ nvidia,fixed-parent-rate;
};
uartb: serial@70006040 {
--
2.33.1
[PATCH v2 14/20] drm/tegra: hdmi: Unwind tegra_hdmi_init() errors
Add missing error unwinding to tegra_hdmi_init(), for consistency.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/hdmi.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 9a87d351a828..142ad696426f 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -1456,22 +1456,31 @@ static int tegra_hdmi_init(struct host1x_client *client)
if (err < 0) {
dev_err(client->dev, "failed to enable HDMI regulator: %d\n",
err);
- return err;
+ goto output_exit;
}
err = regulator_enable(hdmi->pll);
if (err < 0) {
dev_err(hdmi->dev, "failed to enable PLL regulator: %d\n", err);
- return err;
+ goto disable_hdmi;
}
err = regulator_enable(hdmi->vdd);
if (err < 0) {
dev_err(hdmi->dev, "failed to enable VDD regulator: %d\n", err);
- return err;
+ goto disable_pll;
}
return 0;
+
+disable_pll:
+ regulator_disable(hdmi->pll);
+disable_hdmi:
+ regulator_disable(hdmi->hdmi);
+output_exit:
+ tegra_output_exit(>output);
+
+ return err;
}
static int tegra_hdmi_exit(struct host1x_client *client)
--
2.33.1
[PATCH v2 07/20] ASoC: tegra20: spdif: Support device-tree
Tegra20 S/PDIF driver was added in a pre-DT era and was never used since
that time. Revive driver by adding device-tree support.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_spdif.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
index e45e371edc42..6650875d2555 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -340,10 +341,17 @@ static const struct dev_pm_ops tegra20_spdif_pm_ops = {
tegra20_spdif_runtime_resume, NULL)
};
+static const struct of_device_id tegra20_spdif_of_match[] = {
+ { .compatible = "nvidia,tegra20-spdif", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tegra20_spdif_of_match);
+
static struct platform_driver tegra20_spdif_driver = {
.driver = {
.name = DRV_NAME,
.pm = _spdif_pm_ops,
+ .of_match_table = tegra20_spdif_of_match,
},
.probe = tegra20_spdif_platform_probe,
.remove = tegra20_spdif_platform_remove,
@@ -354,4 +362,3 @@ module_platform_driver(tegra20_spdif_driver);
MODULE_AUTHOR("Stephen Warren ");
MODULE_DESCRIPTION("Tegra20 SPDIF ASoC driver");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:" DRV_NAME);
--
2.33.1
[PATCH v2 06/20] ASoC: tegra20-spdif: stop setting slave_id
From: Arnd Bergmann The DMA resource is never set up anywhere, and passing this as slave_id has not been the proper procedure in a long time. As a preparation for removing all slave_id references from the ALSA code, remove this one. According to Dmitry Osipenko, this driver has never been used and the mechanism for configuring DMA would not work as it is implemented, so this part will get rewritten when the driver gets put into use again in the future. Reviewed-by: Dmitry Osipenko Signed-off-by: Arnd Bergmann --- sound/soc/tegra/tegra20_spdif.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c index 6f0570cde964..e45e371edc42 100644 --- a/sound/soc/tegra/tegra20_spdif.c +++ b/sound/soc/tegra/tegra20_spdif.c @@ -298,7 +298,6 @@ static int tegra20_spdif_platform_probe(struct platform_device *pdev) spdif->playback_dma_data.addr = mem->start + TEGRA20_SPDIF_DATA_OUT; spdif->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; spdif->playback_dma_data.maxburst = 4; - spdif->playback_dma_data.slave_id = dmareq->start; pm_runtime_enable(>dev); -- 2.33.1
[PATCH v2 13/20] ASoC: tegra20: i2s: Filter out unsupported rates
Support new nvidia,fixed-parent-rate device-tree property which instructs
I2S that board wants parent clock rate to stay at a fixed rate. This allows
to play audio over S/PDIF and I2S simultaneously. The root of the problem
is that audio components on Tegra share the same audio PLL, and thus, only
a subset of rates can be supported if we want to play audio simultaneously.
Filter out audio rates that don't match parent clock rate if device-tree
has the nvidia,fixed-parent-rate property.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_i2s.c | 49 +++
1 file changed, 49 insertions(+)
diff --git a/sound/soc/tegra/tegra20_i2s.c b/sound/soc/tegra/tegra20_i2s.c
index 266d2cab9f49..27365a877e47 100644
--- a/sound/soc/tegra/tegra20_i2s.c
+++ b/sound/soc/tegra/tegra20_i2s.c
@@ -262,10 +262,59 @@ static int tegra20_i2s_probe(struct snd_soc_dai *dai)
return 0;
}
+static const unsigned int tegra20_i2s_rates[] = {
+ 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200, 96000
+};
+
+static int tegra20_i2s_filter_rates(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *r = hw_param_interval(params, rule->var);
+ struct snd_soc_dai *dai = rule->private;
+ struct tegra20_i2s *i2s = dev_get_drvdata(dai->dev);
+ struct clk *parent = clk_get_parent(i2s->clk_i2s);
+ long i, parent_rate, valid_rates = 0;
+
+ parent_rate = clk_get_rate(parent);
+ if (parent_rate <= 0) {
+ dev_err(dai->dev, "Can't get parent clock rate: %ld\n",
+ parent_rate);
+ return parent_rate ?: -EINVAL;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(tegra20_i2s_rates); i++) {
+ if (parent_rate % (tegra20_i2s_rates[i] * 128) == 0)
+ valid_rates |= BIT(i);
+ }
+
+ /*
+* At least one rate must be valid, otherwise the parent clock isn't
+* audio PLL. Nothing should be filtered in this case.
+*/
+ if (!valid_rates)
+ valid_rates = BIT(ARRAY_SIZE(tegra20_i2s_rates)) - 1;
+
+ return snd_interval_list(r, ARRAY_SIZE(tegra20_i2s_rates),
+tegra20_i2s_rates, valid_rates);
+}
+
+static int tegra20_i2s_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ if (!device_property_read_bool(dai->dev, "nvidia,fixed-parent-rate"))
+ return 0;
+
+ return snd_pcm_hw_rule_add(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ tegra20_i2s_filter_rates, dai,
+ SNDRV_PCM_HW_PARAM_RATE, -1);
+}
+
static const struct snd_soc_dai_ops tegra20_i2s_dai_ops = {
.set_fmt= tegra20_i2s_set_fmt,
.hw_params = tegra20_i2s_hw_params,
.trigger= tegra20_i2s_trigger,
+ .startup= tegra20_i2s_startup,
};
static const struct snd_soc_dai_driver tegra20_i2s_dai_template = {
--
2.33.1
[PATCH v2 12/20] ASoC: tegra20: spdif: Filter out unsupported rates
SPDIF and other SoC components share audio PLL on Tegra, thus only one
component may set the desired base clock rate. This creates problem for
HDMI audio because it uses SPDIF and audio may not work if SPDIF's clock
doesn't exactly match standard audio rate since some receivers may reject
audio in that case. Filter out audio rates which SPDIF output can't
support, assuming that other components won't change rate at runtime.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_spdif.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
index 89f7fc5c8aad..52be59c58126 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -79,6 +79,7 @@ static int tegra20_spdif_hw_params(struct snd_pcm_substream
*substream,
struct tegra20_spdif *spdif = dev_get_drvdata(dai->dev);
unsigned int mask = 0, val = 0;
int ret, spdifclock;
+ long rate;
mask |= TEGRA20_SPDIF_CTRL_PACK |
TEGRA20_SPDIF_CTRL_BIT_MODE_MASK;
@@ -133,6 +134,12 @@ static int tegra20_spdif_hw_params(struct
snd_pcm_substream *substream,
return ret;
}
+ rate = clk_get_rate(spdif->clk_spdif_out);
+ if (rate != spdifclock)
+ dev_warn_once(dai->dev,
+ "SPDIF clock rate %d doesn't match requested rate
%lu\n",
+ spdifclock, rate);
+
return 0;
}
@@ -172,6 +179,59 @@ static int tegra20_spdif_trigger(struct snd_pcm_substream
*substream, int cmd,
return 0;
}
+static int tegra20_spdif_filter_rates(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *r = hw_param_interval(params, rule->var);
+ struct snd_soc_dai *dai = rule->private;
+ struct tegra20_spdif *spdif = dev_get_drvdata(dai->dev);
+ struct clk *parent = clk_get_parent(spdif->clk_spdif_out);
+ const unsigned int rates[] = { 32000, 44100, 48000 };
+ long i, parent_rate, valid_rates = 0;
+
+ parent_rate = clk_get_rate(parent);
+ if (parent_rate <= 0) {
+ dev_err(dai->dev, "Can't get parent clock rate: %ld\n",
+ parent_rate);
+ return parent_rate ?: -EINVAL;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(rates); i++) {
+ if (parent_rate % (rates[i] * 128) == 0)
+ valid_rates |= BIT(i);
+ }
+
+ /*
+* At least one rate must be valid, otherwise the parent clock isn't
+* audio PLL. Nothing should be filtered in this case.
+*/
+ if (!valid_rates)
+ valid_rates = BIT(ARRAY_SIZE(rates)) - 1;
+
+ return snd_interval_list(r, ARRAY_SIZE(rates), rates, valid_rates);
+}
+
+static int tegra20_spdif_startup(struct snd_pcm_substream *substream,
+struct snd_soc_dai *dai)
+{
+ if (!device_property_read_bool(dai->dev, "nvidia,fixed-parent-rate"))
+ return 0;
+
+ /*
+* SPDIF and I2S share audio PLL. HDMI takes audio packets from SPDIF
+* and audio may not work on some TVs if clock rate isn't precise.
+*
+* PLL rate is controlled by I2S side. Filter out audio rates that
+* don't match PLL rate at the start of stream to allow both SPDIF
+* and I2S work simultaneously, assuming that PLL rate won't be
+* changed later on.
+*/
+ return snd_pcm_hw_rule_add(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ tegra20_spdif_filter_rates, dai,
+ SNDRV_PCM_HW_PARAM_RATE, -1);
+}
+
static int tegra20_spdif_probe(struct snd_soc_dai *dai)
{
struct tegra20_spdif *spdif = dev_get_drvdata(dai->dev);
@@ -185,6 +245,7 @@ static int tegra20_spdif_probe(struct snd_soc_dai *dai)
static const struct snd_soc_dai_ops tegra20_spdif_dai_ops = {
.hw_params = tegra20_spdif_hw_params,
.trigger = tegra20_spdif_trigger,
+ .startup = tegra20_spdif_startup,
};
static struct snd_soc_dai_driver tegra20_spdif_dai = {
--
2.33.1
[PATCH v2 09/20] ASoC: tegra20: spdif: Use more resource-managed helpers
Use resource-managed helpers to make code cleaner. Driver's remove callback
isn't needed anymore since driver is completely resource-managed now.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_spdif.c | 33 +
sound/soc/tegra/tegra_pcm.c | 6 ++
sound/soc/tegra/tegra_pcm.h | 1 +
3 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
index 9383683aa4e9..6ca48bc322ae 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -289,38 +289,24 @@ static int tegra20_spdif_platform_probe(struct
platform_device *pdev)
spdif->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
spdif->playback_dma_data.maxburst = 4;
- pm_runtime_enable(>dev);
+ ret = devm_pm_runtime_enable(>dev);
+ if (ret)
+ return ret;
- ret = snd_soc_register_component(>dev, _spdif_component,
-_spdif_dai, 1);
+ ret = devm_snd_soc_register_component(>dev,
+ _spdif_component,
+ _spdif_dai, 1);
if (ret) {
dev_err(>dev, "Could not register DAI: %d\n", ret);
- goto err_pm_disable;
+ return ret;
}
- ret = tegra_pcm_platform_register(>dev);
+ ret = devm_tegra_pcm_platform_register(>dev);
if (ret) {
dev_err(>dev, "Could not register PCM: %d\n", ret);
- goto err_unregister_component;
+ return ret;
}
- return 0;
-
-err_unregister_component:
- snd_soc_unregister_component(>dev);
-err_pm_disable:
- pm_runtime_disable(>dev);
-
- return ret;
-}
-
-static int tegra20_spdif_platform_remove(struct platform_device *pdev)
-{
- tegra_pcm_platform_unregister(>dev);
- snd_soc_unregister_component(>dev);
-
- pm_runtime_disable(>dev);
-
return 0;
}
@@ -342,7 +328,6 @@ static struct platform_driver tegra20_spdif_driver = {
.of_match_table = tegra20_spdif_of_match,
},
.probe = tegra20_spdif_platform_probe,
- .remove = tegra20_spdif_platform_remove,
};
module_platform_driver(tegra20_spdif_driver);
diff --git a/sound/soc/tegra/tegra_pcm.c b/sound/soc/tegra/tegra_pcm.c
index ef1e74d95236..468c8e77de21 100644
--- a/sound/soc/tegra/tegra_pcm.c
+++ b/sound/soc/tegra/tegra_pcm.c
@@ -48,6 +48,12 @@ int tegra_pcm_platform_register(struct device *dev)
}
EXPORT_SYMBOL_GPL(tegra_pcm_platform_register);
+int devm_tegra_pcm_platform_register(struct device *dev)
+{
+ return devm_snd_dmaengine_pcm_register(dev,
_dmaengine_pcm_config, 0);
+}
+EXPORT_SYMBOL_GPL(devm_tegra_pcm_platform_register);
+
int tegra_pcm_platform_register_with_chan_names(struct device *dev,
struct snd_dmaengine_pcm_config *config,
char *txdmachan, char *rxdmachan)
diff --git a/sound/soc/tegra/tegra_pcm.h b/sound/soc/tegra/tegra_pcm.h
index d602126c65b7..2a36eea1740d 100644
--- a/sound/soc/tegra/tegra_pcm.h
+++ b/sound/soc/tegra/tegra_pcm.h
@@ -32,6 +32,7 @@ int tegra_pcm_hw_params(struct snd_soc_component *component,
snd_pcm_uframes_t tegra_pcm_pointer(struct snd_soc_component *component,
struct snd_pcm_substream *substream);
int tegra_pcm_platform_register(struct device *dev);
+int devm_tegra_pcm_platform_register(struct device *dev);
int tegra_pcm_platform_register_with_chan_names(struct device *dev,
struct snd_dmaengine_pcm_config *config,
char *txdmachan, char *rxdmachan);
--
2.33.1
[PATCH v2 18/20] ARM: tegra: Add HDMI audio graph to Tegra20 device-tree
Add HDMI audio graph to Tegra20 device-tree to enable HDMI audio on
Tegra20 devices.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 799da7dc929b..a2cdc591b4be 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -186,7 +186,7 @@ rgb {
};
};
- hdmi@5428 {
+ tegra_hdmi: hdmi@5428 {
compatible = "nvidia,tegra20-hdmi";
reg = <0x5428 0x0004>;
interrupts = ;
@@ -1063,4 +1063,24 @@ pmu {
interrupt-affinity = <&{/cpus/cpu@0}>,
<&{/cpus/cpu@1}>;
};
+
+ sound-hdmi {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "NVIDIA Tegra20 HDMI";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ simple-audio-card,dai-link@0 {
+ reg = <0>;
+
+ cpu {
+ sound-dai = <_spdif>;
+ };
+
+ codec {
+ sound-dai = <_hdmi>;
+ };
+ };
+ };
};
--
2.33.1
[PATCH v2 10/20] ASoC: tegra20: spdif: Reset hardware
Reset S/PDIF controller on runtime PM suspend/resume to ensure that we
always have a consistent hardware state.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_spdif.c | 32
sound/soc/tegra/tegra20_spdif.h | 1 +
2 files changed, 33 insertions(+)
diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
index 6ca48bc322ae..8b9bac30d5cd 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -27,6 +29,8 @@ static __maybe_unused int
tegra20_spdif_runtime_suspend(struct device *dev)
{
struct tegra20_spdif *spdif = dev_get_drvdata(dev);
+ regcache_cache_only(spdif->regmap, true);
+
clk_disable_unprepare(spdif->clk_spdif_out);
return 0;
@@ -37,13 +41,35 @@ static __maybe_unused int
tegra20_spdif_runtime_resume(struct device *dev)
struct tegra20_spdif *spdif = dev_get_drvdata(dev);
int ret;
+ ret = reset_control_assert(spdif->reset);
+ if (ret)
+ return ret;
+
ret = clk_prepare_enable(spdif->clk_spdif_out);
if (ret) {
dev_err(dev, "clk_enable failed: %d\n", ret);
return ret;
}
+ usleep_range(10, 100);
+
+ ret = reset_control_deassert(spdif->reset);
+ if (ret)
+ goto disable_clocks;
+
+ regcache_cache_only(spdif->regmap, false);
+ regcache_mark_dirty(spdif->regmap);
+
+ ret = regcache_sync(spdif->regmap);
+ if (ret)
+ goto disable_clocks;
+
return 0;
+
+disable_clocks:
+ clk_disable_unprepare(spdif->clk_spdif_out);
+
+ return ret;
}
static int tegra20_spdif_hw_params(struct snd_pcm_substream *substream,
@@ -268,6 +294,12 @@ static int tegra20_spdif_platform_probe(struct
platform_device *pdev)
dev_set_drvdata(>dev, spdif);
+ spdif->reset = devm_reset_control_get_exclusive(>dev, NULL);
+ if (IS_ERR(spdif->reset)) {
+ dev_err(>dev, "Can't retrieve spdif reset\n");
+ return PTR_ERR(spdif->reset);
+ }
+
spdif->clk_spdif_out = devm_clk_get(>dev, "spdif_out");
if (IS_ERR(spdif->clk_spdif_out)) {
dev_err(>dev, "Could not retrieve spdif clock\n");
diff --git a/sound/soc/tegra/tegra20_spdif.h b/sound/soc/tegra/tegra20_spdif.h
index 1973ffc2d5c7..ff4b79e2052f 100644
--- a/sound/soc/tegra/tegra20_spdif.h
+++ b/sound/soc/tegra/tegra20_spdif.h
@@ -451,6 +451,7 @@ struct tegra20_spdif {
struct snd_dmaengine_dai_dma_data capture_dma_data;
struct snd_dmaengine_dai_dma_data playback_dma_data;
struct regmap *regmap;
+ struct reset_control *reset;
};
#endif
--
2.33.1
[PATCH v2 17/20] ARM: tegra: Add S/PDIF node to Tegra20 device-tree
Add S/PDIF node to Tegra20 device-tree. It's needed for enabling HDMI
audio support.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 63c2c2f8c0ce..799da7dc929b 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -197,6 +197,7 @@ hdmi@5428 {
reset-names = "hdmi";
power-domains = <_core>;
operating-points-v2 = <_dvfs_opp_table>;
+ #sound-dai-cells = <0>;
status = "disabled";
};
@@ -396,6 +397,23 @@ tegra_ac97: ac97@70002000 {
status = "disabled";
};
+ tegra_spdif: spdif@70002400 {
+ compatible = "nvidia,tegra20-spdif";
+ reg = <0x70002400 0x200>;
+ interrupts = ;
+ clocks = <_car TEGRA20_CLK_SPDIF_OUT>,
+<_car TEGRA20_CLK_SPDIF_IN>;
+ clock-names = "spdif_out", "spdif_in";
+ resets = <_car 10>;
+ dmas = < 3>, < 3>;
+ dma-names = "rx", "tx";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+
+ assigned-clocks = <_car TEGRA20_CLK_SPDIF_OUT>;
+ assigned-clock-parents = <_car TEGRA20_CLK_PLL_A_OUT0>;
+ };
+
tegra_i2s1: i2s@70002800 {
compatible = "nvidia,tegra20-i2s";
reg = <0x70002800 0x200>;
--
2.33.1
[PATCH v2 11/20] ASoC: tegra20: spdif: Support system suspend
Support system suspend by enforcing runtime PM suspend/resume.
Now there is no doubt that h/w is indeed stopped during suspend
and that h/w state will be properly restored after resume.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_spdif.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
index 8b9bac30d5cd..89f7fc5c8aad 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -345,6 +345,8 @@ static int tegra20_spdif_platform_probe(struct
platform_device *pdev)
static const struct dev_pm_ops tegra20_spdif_pm_ops = {
SET_RUNTIME_PM_OPS(tegra20_spdif_runtime_suspend,
tegra20_spdif_runtime_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static const struct of_device_id tegra20_spdif_of_match[] = {
--
2.33.1
[PATCH v2 02/20] ASoC: dt-bindings: tegra20-i2s: Convert to schema
Convert NVIDIA Tegra20 I2S binding to schema.
Signed-off-by: Dmitry Osipenko
---
.../bindings/sound/nvidia,tegra20-i2s.txt | 30
.../bindings/sound/nvidia,tegra20-i2s.yaml| 70 +++
2 files changed, 70 insertions(+), 30 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
create mode 100644
Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
deleted file mode 100644
index dc30c6bfbe95..
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-NVIDIA Tegra 20 I2S controller
-
-Required properties:
-- compatible : "nvidia,tegra20-i2s"
-- reg : Should contain I2S registers location and length
-- interrupts : Should contain I2S interrupt
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - i2s
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-
-Example:
-
-i2s@70002800 {
- compatible = "nvidia,tegra20-i2s";
- reg = <0x70002800 0x200>;
- interrupts = < 45 >;
- clocks = <_car 11>;
- resets = <_car 11>;
- reset-names = "i2s";
- dmas = < 21>, < 21>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml
b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml
new file mode 100644
index ..ad43b237d9af
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra20-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20 I2S Controller
+
+description: |
+ The I2S Controller streams synchronous serial audio data between system
+ memory and an external audio device. The controller supports the I2S Left
+ Justified Mode, Right Justified Mode, and DSP mode formats.
+
+maintainers:
+ - Thierry Reding
+ - Jon Hunter
+
+properties:
+ compatible:
+const: nvidia,tegra20-i2s
+
+ reg:
+maxItems: 1
+
+ resets:
+maxItems: 1
+
+ reset-names:
+const: i2s
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+minItems: 1
+
+ dmas:
+minItems: 2
+
+ dma-names:
+items:
+ - const: rx
+ - const: tx
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+ - interrupts
+ - clocks
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+i2s@70002800 {
+compatible = "nvidia,tegra20-i2s";
+reg = <0x70002800 0x200>;
+interrupts = <45>;
+clocks = <_car 11>;
+resets = <_car 11>;
+reset-names = "i2s";
+dmas = < 21>, < 21>;
+dma-names = "rx", "tx";
+};
+
+...
--
2.33.1
[PATCH v2 08/20] ASoC: tegra20: spdif: Improve driver's code
- Clean up whitespaces, defines and variables.
- Remove obsolete code.
- Adhere to upstream coding style.
- Don't override returned error code.
- Replace pr_err with dev_err.
No functional changes are made by this patch. This is a minor code's
refactoring that will ease further maintenance of the driver.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_spdif.c | 49 -
1 file changed, 18 insertions(+), 31 deletions(-)
diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
index 6650875d2555..9383683aa4e9 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -23,8 +23,6 @@
#include "tegra20_spdif.h"
-#define DRV_NAME "tegra20-spdif"
-
static __maybe_unused int tegra20_spdif_runtime_suspend(struct device *dev)
{
struct tegra20_spdif *spdif = dev_get_drvdata(dev);
@@ -49,11 +47,10 @@ static __maybe_unused int
tegra20_spdif_runtime_resume(struct device *dev)
}
static int tegra20_spdif_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params,
- struct snd_soc_dai *dai)
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
{
- struct device *dev = dai->dev;
- struct tegra20_spdif *spdif = snd_soc_dai_get_drvdata(dai);
+ struct tegra20_spdif *spdif = dev_get_drvdata(dai->dev);
unsigned int mask = 0, val = 0;
int ret, spdifclock;
@@ -106,7 +103,7 @@ static int tegra20_spdif_hw_params(struct snd_pcm_substream
*substream,
ret = clk_set_rate(spdif->clk_spdif_out, spdifclock);
if (ret) {
- dev_err(dev, "Can't set SPDIF clock rate: %d\n", ret);
+ dev_err(dai->dev, "Can't set SPDIF clock rate: %d\n", ret);
return ret;
}
@@ -127,9 +124,9 @@ static void tegra20_spdif_stop_playback(struct
tegra20_spdif *spdif)
}
static int tegra20_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
- struct snd_soc_dai *dai)
+struct snd_soc_dai *dai)
{
- struct tegra20_spdif *spdif = snd_soc_dai_get_drvdata(dai);
+ struct tegra20_spdif *spdif = dev_get_drvdata(dai->dev);
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -151,7 +148,7 @@ static int tegra20_spdif_trigger(struct snd_pcm_substream
*substream, int cmd,
static int tegra20_spdif_probe(struct snd_soc_dai *dai)
{
- struct tegra20_spdif *spdif = snd_soc_dai_get_drvdata(dai);
+ struct tegra20_spdif *spdif = dev_get_drvdata(dai->dev);
dai->capture_dma_data = NULL;
dai->playback_dma_data = >playback_dma_data;
@@ -160,26 +157,26 @@ static int tegra20_spdif_probe(struct snd_soc_dai *dai)
}
static const struct snd_soc_dai_ops tegra20_spdif_dai_ops = {
- .hw_params = tegra20_spdif_hw_params,
- .trigger= tegra20_spdif_trigger,
+ .hw_params = tegra20_spdif_hw_params,
+ .trigger = tegra20_spdif_trigger,
};
static struct snd_soc_dai_driver tegra20_spdif_dai = {
- .name = DRV_NAME,
+ .name = "tegra20-spdif",
.probe = tegra20_spdif_probe,
.playback = {
.stream_name = "Playback",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
- SNDRV_PCM_RATE_48000,
+SNDRV_PCM_RATE_48000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.ops = _spdif_dai_ops,
};
static const struct snd_soc_component_driver tegra20_spdif_component = {
- .name = DRV_NAME,
+ .name = "tegra20-spdif",
};
static bool tegra20_spdif_wr_rd_reg(struct device *dev, unsigned int reg)
@@ -260,7 +257,7 @@ static const struct regmap_config
tegra20_spdif_regmap_config = {
static int tegra20_spdif_platform_probe(struct platform_device *pdev)
{
struct tegra20_spdif *spdif;
- struct resource *mem, *dmareq;
+ struct resource *mem;
void __iomem *regs;
int ret;
@@ -273,27 +270,19 @@ static int tegra20_spdif_platform_probe(struct
platform_device *pdev)
spdif->clk_spdif_out = devm_clk_get(>dev, "spdif_out");
if (IS_ERR(spdif->clk_spdif_out)) {
- pr_err("Can't retrieve spdif clock\n");
- ret = PTR_ERR(spdif->clk_spdif_out);
- return ret;
+ dev_err(>dev, "Could not retrieve spdif clock\n");
+ return PTR_ERR(spdif->clk_spdif_out);
}
regs = devm_platform_get_and_ioremap_resource(pdev, 0, );
if (IS_ERR(regs))
return PTR_ERR(regs);
- dmareq = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!dmareq) {
- dev_err(>dev, "No DMA resource\n");
-
[PATCH v2 03/20] ASoC: dt-bindings: tegra20-i2s: Document new nvidia, fixed-parent-rate property
Document new nvidia,fixed-parent-rate property which instructs that this board wants parent clock to stay at a fixed rate. It allows to prevent conflicts between audio components that share same parent PLL. For instance, this property allows to have HDMI audio, speaker and headphones in the system playing audio simultaneously, which is a common pattern for consumer devices. Signed-off-by: Dmitry Osipenko --- .../devicetree/bindings/sound/nvidia,tegra20-i2s.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml index ad43b237d9af..68ae124eaf80 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml @@ -42,6 +42,13 @@ properties: - const: rx - const: tx + nvidia,fixed-parent-rate: +description: | + Specifies whether board prefers parent clock to stay at a fixed rate. + This allows multiple Tegra20 audio components work simultaneously by + limiting number of supportable audio rates. +type: boolean + required: - compatible - reg -- 2.33.1
[PATCH v2 05/20] ASoC: tegra20: spdif: Set FIFO trigger level
FIFO trigger level must be not less than the size of DMA burst, otherwise
audio will be played x4 faster that it should be because part of the DMA
data will be dropped on FIFO input buffer overflow.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_spdif.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
index 7751575cd6d6..6f0570cde964 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -69,6 +69,14 @@ static int tegra20_spdif_hw_params(struct snd_pcm_substream
*substream,
regmap_update_bits(spdif->regmap, TEGRA20_SPDIF_CTRL, mask, val);
+ /*
+* FIFO trigger level must be bigger than DMA burst or equal to it,
+* otherwise data is discarded on overflow.
+*/
+ regmap_update_bits(spdif->regmap, TEGRA20_SPDIF_DATA_FIFO_CSR,
+ TEGRA20_SPDIF_DATA_FIFO_CSR_TX_ATN_LVL_MASK,
+
TEGRA20_SPDIF_DATA_FIFO_CSR_TX_ATN_LVL_TU4_WORD_FULL);
+
switch (params_rate(params)) {
case 32000:
spdifclock = 4096000;
--
2.33.1
[PATCH v2 01/20] ASoC: dt-bindings: Add binding for Tegra20 S/PDIF
Add device-tree binding for Tegra20 S/PDIF controller.
Signed-off-by: Dmitry Osipenko
---
.../bindings/sound/nvidia,tegra20-spdif.yaml | 85 +++
1 file changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml
b/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml
new file mode 100644
index ..00240205817d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra20-spdif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20 S/PDIF Controller
+
+description: |
+ The S/PDIF controller supports both input and output in serial audio
+ digital interface format. The input controller can digitally recover
+ a clock from the received stream. The S/PDIF controller is also used
+ to generate the embedded audio for HDMI output channel.
+
+maintainers:
+ - Thierry Reding
+ - Jon Hunter
+
+properties:
+ compatible:
+const: nvidia,tegra20-spdif
+
+ reg:
+maxItems: 1
+
+ resets:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+minItems: 2
+
+ clock-names:
+items:
+ - const: spdif_out
+ - const: spdif_in
+
+ dmas:
+minItems: 2
+
+ dma-names:
+items:
+ - const: rx
+ - const: tx
+
+ "#sound-dai-cells":
+const: 0
+
+ nvidia,fixed-parent-rate:
+description: |
+ Specifies whether board prefers parent clock to stay at a fixed rate.
+ This allows multiple Tegra20 audio components work simultaneously by
+ limiting number of supportable audio rates.
+type: boolean
+
+required:
+ - compatible
+ - reg
+ - resets
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+ - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+spdif@70002400 {
+compatible = "nvidia,tegra20-spdif";
+reg = <0x70002400 0x200>;
+interrupts = <77>;
+clocks = <_car99>, <_car 98>;
+clock-names = "spdif_out", "spdif_in";
+resets = <_car 10>;
+dmas = < 3>, < 3>;
+dma-names = "rx", "tx";
+#sound-dai-cells = <0>;
+};
+
+...
--
2.33.1
[PATCH v2 04/20] dt-bindings: host1x: Document optional HDMI sound-dai-cells
Document new optional sound-dai-cells property of HDMI node. This node will be used as endpoint of HDMI sound DAI graph. Signed-off-by: Dmitry Osipenko --- .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt index e61999ce54e9..27b746f28f31 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt @@ -297,6 +297,7 @@ of the following host1x client modules: - nvidia,edid: supplies a binary EDID blob - nvidia,panel: phandle of a display panel - operating-points-v2: See ../bindings/opp/opp.txt for details. + - #sound-dai-cells: Should be 0. - tvo: TV encoder output -- 2.33.1
[PATCH v2 00/20] Support HDMI audio on NVIDIA Tegra20
This series revives Tegra20 S/PDIF driver which was upstreamed long time ago, but never was used. It also turns Tegra DRM HDMI driver into HDMI audio CODEC provider. Finally, HDMI audio is enabled in device-trees. For now the audio is enable only for Acer A500 tablet and Toshiba AC100 netbook because they're already supported by upstream, later on ASUS TF101 tablet will join them. I based S/PDIF patches on Arnd's Bergmann patch from a separate series [1] that removes obsolete slave_id. This eases merging of the patches by removing the merge conflict. [1] https://patchwork.ozlabs.org/project/linux-tegra/list/?submitter=80402 Changelog: v1: - Corrected I2S yaml problem that was reported by the DT bot for v1 by removing the non-existent required clock-names property. - Removed assigned-clocks property from S/PDIF yaml since this property is now inherited from the clocks property. - Reordered the "tegra20: spdif: Set FIFO trigger level" patch, making it the first sound/soc patch in the series, like it was suggested by Mark Brown in the comment to v1. Also reworded commit message of this patch to *not* make it looks like it should be backported to stable kernels. Arnd Bergmann (1): ASoC: tegra20-spdif: stop setting slave_id Dmitry Osipenko (19): ASoC: dt-bindings: Add binding for Tegra20 S/PDIF ASoC: dt-bindings: tegra20-i2s: Convert to schema ASoC: dt-bindings: tegra20-i2s: Document new nvidia,fixed-parent-rate property dt-bindings: host1x: Document optional HDMI sound-dai-cells ASoC: tegra20: spdif: Set FIFO trigger level ASoC: tegra20: spdif: Support device-tree ASoC: tegra20: spdif: Improve driver's code ASoC: tegra20: spdif: Use more resource-managed helpers ASoC: tegra20: spdif: Reset hardware ASoC: tegra20: spdif: Support system suspend ASoC: tegra20: spdif: Filter out unsupported rates ASoC: tegra20: i2s: Filter out unsupported rates drm/tegra: hdmi: Unwind tegra_hdmi_init() errors drm/tegra: hdmi: Register audio CODEC on Tegra20 ARM: tegra_defconfig: Enable S/PDIF driver ARM: tegra: Add S/PDIF node to Tegra20 device-tree ARM: tegra: Add HDMI audio graph to Tegra20 device-tree ARM: tegra: acer-a500: Enable S/PDIF and HDMI audio ARM: tegra: paz00: Enable S/PDIF and HDMI audio .../display/tegra/nvidia,tegra20-host1x.txt | 1 + .../bindings/sound/nvidia,tegra20-i2s.txt | 30 --- .../bindings/sound/nvidia,tegra20-i2s.yaml| 77 +++ .../bindings/sound/nvidia,tegra20-spdif.yaml | 85 .../boot/dts/tegra20-acer-a500-picasso.dts| 8 + arch/arm/boot/dts/tegra20-paz00.dts | 8 + arch/arm/boot/dts/tegra20.dtsi| 40 +++- arch/arm/configs/tegra_defconfig | 1 + drivers/gpu/drm/tegra/Kconfig | 3 + drivers/gpu/drm/tegra/hdmi.c | 168 +-- sound/soc/tegra/tegra20_i2s.c | 49 + sound/soc/tegra/tegra20_spdif.c | 195 +- sound/soc/tegra/tegra20_spdif.h | 1 + sound/soc/tegra/tegra_pcm.c | 6 + sound/soc/tegra/tegra_pcm.h | 1 + 15 files changed, 571 insertions(+), 102 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml -- 2.33.1
Re: [PATCH] drm/msm: Initialize MDSS irq domain at probe time
Il 26/11/21 01:06, Dmitry Baryshkov ha scritto:
On 25/11/2021 18:09, AngeloGioacchino Del Regno wrote:
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
DSI host gets initialized earlier, but this caused unability to probe
the entire stack of components because they all depend on interrupts
coming from the main `mdss` node (mdp5, or dpu1).
To fix this issue, also anticipate probing mdp5 or dpu1 by initializing
them at msm_pdev_probe() time: this will make sure that we add the
required interrupt controller mapping before dsi and/or other components
try to initialize, finally satisfying the dependency.
While at it, also change the allocation of msm_drm_private to use the
devm variant of kzalloc().
Fixes: 8f59ee9a570c ("drm/msm/dsi: Adjust probe order")
Signed-off-by: AngeloGioacchino Del Regno
Another issue (or a pack of issues):
Now the msm_drm_init() is unbalanced with msm_drm_uninit(). Bits of code (putting
the drm dev, removing the IRQ domain, etc) have to be called now from the
msm_pdev_remove() function rather than from the unbind path.
The following changes fix the observed issues here, however additional care should
be taken.
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 5a92417d21d0..0abb16256b61 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -342,7 +342,6 @@ static int msm_drm_uninit(struct device *dev)
struct drm_device *ddev = platform_get_drvdata(pdev);
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
- struct msm_mdss *mdss = priv->mdss;
int i;
/*
@@ -402,14 +401,7 @@ static int msm_drm_uninit(struct device *dev)
component_unbind_all(dev, ddev);
- if (mdss && mdss->funcs)
- mdss->funcs->destroy(ddev);
-
- ddev->dev_private = NULL;
- drm_dev_put(ddev);
-
destroy_workqueue(priv->wq);
- kfree(priv);
return 0;
}
@@ -515,7 +507,6 @@ static int msm_drm_init(struct device *dev, const
struct drm_device *ddev = platform_get_drvdata(pdev);
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
- struct msm_mdss *mdss = priv->mdss;
int ret, i;
priv->wq = alloc_ordered_workqueue("msm", 0);
@@ -538,12 +529,12 @@ static int msm_drm_init(struct device *dev, const
ret = msm_init_vram(ddev);
if (ret)
- goto err_destroy_mdss;
+ return ret;
/* Bind all our sub-components: */
ret = component_bind_all(dev, ddev);
if (ret)
- goto err_destroy_mdss;
+ return ret;
dma_set_max_seg_size(dev, UINT_MAX);
@@ -649,10 +640,6 @@ static int msm_drm_init(struct device *dev, const
err_msm_uninit:
msm_drm_uninit(dev);
return ret;
-err_destroy_mdss:
- if (mdss && mdss->funcs)
- mdss->funcs->destroy(ddev);
- return ret;
}
/*
@@ -1424,9 +1411,20 @@ static int msm_pdev_probe(struct platform_device
static int msm_pdev_remove(struct platform_device *pdev)
{
+ struct drm_device *ddev = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = ddev->dev_private;
+ struct msm_mdss *mdss = priv->mdss;
+
component_master_del(>dev, _drm_ops);
+
of_platform_depopulate(>dev);
+ if (mdss && mdss->funcs)
+ mdss->funcs->destroy(ddev);
+
+ ddev->dev_private = NULL;
+ drm_dev_put(ddev);
+
return 0;
}
Hello,
I had a chance to get back to this patch... and there's a bit more to do...
Applying your suggestion makes the kernel crash when removing the DSI panel:
[ 92.084668] Unable to handle kernel paging request at virtual address
dd7f137945d8
[ 92.092848] Mem abort info:
[ 92.095758] ESR = 0x9607
[ 92.098918] EC = 0x25: DABT (current EL), IL = 32 bits
[ 92.104395] SET = 0, FnV = 0
[ 92.107545] EA = 0, S1PTW = 0
[ 92.110785] FSC = 0x07: level 3 translation fault
[ 92.115802] Data abort info:
[ 92.118767] ISV = 0, ISS = 0x0007
[ 92.122720] CM = 0, WnR = 0
[ 92.125770] swapper pgtable: 4k pages, 48-bit VAs, pgdp=82466000
[ 92.132668] [dd7f137945d8] pgd=10017003, p4d=10017003,
pud=1001034bb003, pmd=100108ec2003, pte=
[ 92.145530] Internal error: Oops: 9607 [#1] SMP
[ 92.150557] Modules linked in: af_alg ipv6 uvcvideo videobuf2_vmalloc
snd_soc_hdmi_codec venus_enc venus_dec videobuf2_dma_contig videobuf2_memops
cdc_ether usbnet hci_uart ath10k_snoc msm venus_core r8152 ath10k_core btqca btbcm
v4l2_mem2mem ti_sn65dsi86(-) ath gpu_sched videobuf2_v4l2 sx9310 cros_ec_typec
drm_dp_aux_bus bluetooth mac80211 snd_soc_rt5682_i2c qrtr typec drm_kms_helper
sbs_battery snd_soc_rt5682 videobuf2_common cros_usbpd_charger cros_usbpd_logger
Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver
On Thu, Nov 25, 2021 at 09:44:14PM +0530, Jagan Teki wrote:
> On Thu, Nov 25, 2021 at 9:40 PM Maxime Ripard wrote:
> >
> > On Thu, Nov 25, 2021 at 07:55:41PM +0530, Jagan Teki wrote:
> > > Hi,
> > >
> > > On Thu, Nov 25, 2021 at 7:45 PM Maxime Ripard wrote:
> > > >
> > > > On Wed, Nov 24, 2021 at 12:02:47AM +0530, Jagan Teki wrote:
> > > > > > > > > > + dsi->panel = of_drm_find_panel(remote);
> > > > > > > > > > + if (IS_ERR(dsi->panel)) {
> > > > > > > > > > + dsi->panel = NULL;
> > > > > > > > > > +
> > > > > > > > > > + dsi->next_bridge = of_drm_find_bridge(remote);
> > > > > > > > > > + if (IS_ERR(dsi->next_bridge)) {
> > > > > > > > > > + dev_err(dsi->dev, "failed to find
> > > > > > > > > > bridge\n");
> > > > > > > > > > + return PTR_ERR(dsi->next_bridge);
> > > > > > > > > > + }
> > > > > > > > > > + } else {
> > > > > > > > > > + dsi->next_bridge = NULL;
> > > > > > > > > > + }
> > > > > > > > > > +
> > > > > > > > > > + of_node_put(remote);
> > > > > > > > >
> > > > > > > > > Using devm_drm_of_get_bridge would greatly simplify the driver
> > > > > > > >
> > > > > > > > I'm aware of this and this would break the existing sunxi dsi
> > > > > > > > binding,
> > > > > > > > we are not using ports based pipeline in dsi node. Of-course
> > > > > > > > you have
> > > > > > > > pointed the same before, please check below
> > > > > > > > https://patchwork.kernel.org/project/dri-devel/patch/20210322140152.101709-2-ja...@amarulasolutions.com/
> > > > > > >
> > > > > > > Then drm_of_find_panel_or_bridge needs to be adjusted to handle
> > > > > > > the DSI
> > > > > > > bindings and look for a panel or bridge not only through the OF
> > > > > > > graph,
> > > > > > > but also on the child nodes
> > > > > >
> > > > > > Okay. I need to check this.
> > > > >
> > > > > devm_drm_of_get_bridge is not working with legacy binding like the one
> > > > > used in sun6i dsi
> > > >
> > > > There's nothing legacy about it.
> > >
> > > What I'm mean legacy here with current binding used in sun6i-dsi like
> > > this.
> > >
> > > {
> > > vcc-dsi-supply = <_dcdc1>; /* VCC-DSI */
> > > status = "okay";
> > >
> > > panel@0 {
> > >compatible = "bananapi,s070wv20-ct16-icn6211";
> > >reg = <0>;
> > >reset-gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /*
> > > LCD-RST: PL5 */
> > > enable-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /*
> > > LCD-PWR-EN: PB7 */
> > > backlight = <>;
> > > };
> > > };
> >
> > Yes, I know, it's the generic DSI binding. It's still not legacy.
> >
> > > devm_drm_of_get_bridge cannot find the device with above binding and
> > > able to find the device with below binding.
> > >
> > > {
> > >vcc-dsi-supply = <_dcdc1>; /* VCC-DSI */
> > >status = "okay";
> > >
> > > ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > >dsi_out: port@0 {
> > >reg = <0>;
> > >
> > > dsi_out_bridge: endpoint {
> > > remote-endpoint = <_out_dsi>;
> > > };
> > >};
> > > };
> > >
> > > panel@0 {
> > > compatible = "bananapi,s070wv20-ct16-icn6211";
> > > reg = <0>;
> > > reset-gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5
> > > */
> > > enable-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN:
> > > PB7 */
> > > backlight = <>;
> > >
> > > port {
> > > bridge_out_dsi: endpoint {
> > > remote-endpoint = <_out_bridge>;
> > > };
> > > };
> > >};
> > > };
> >
> > Yes, I know, and that's because ...
>
> Okay. I will use find panel and bridge separately instead of
> devm_drm_of_get_bridge in version patches.
That's not been my point, at all?
I mean, that whole discussion has been because you shouldn't do that.
> >
> > > >
> > > > > https://patchwork.kernel.org/project/dri-devel/patch/20211122065223.88059-6-ja...@amarulasolutions.com/
> > > > >
> > > > > dsi->next_bridge = devm_drm_of_get_bridge(dsi->dev,
> > > > > dsi->dev->of_node, 0, 0);
> > > > > if (IS_ERR(dsi->next_bridge))
> > > > >return PTR_ERR(dsi->next_bridge);
> > > > >
> > > > > It is only working if we have ports on the pipeline, something like
> > > > > this
> > > > > https://patchwork.kernel.org/project/dri-devel/patch/20210214194102.126146-8-ja...@amarulasolutions.com/
> > > > >
> > > > > Please have a look and let me know if I miss anything?
> > > >
> > > > Yes, you're missing the answer you quoted earlier:
> > >
> > > Yes, I'm trying to resolve the comment one after another. Will get back.
> >
> > ... You've ignored that comment.
>
> Not
Re: [PATCH] drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_a*.c
On Fri, Nov 26, 2021 at 11:49:49AM +0100, Claudio Suarez wrote:
> DRM_DEBUG_* and DRM_* log calls are deprecated.
> Change them to drm_dbg_* / drm_{err,info,...} calls in drm core
> files.
>
> To avoid making a very big patch, this change is split in
> smaller patches. This one includes drm_a*.c
>
> Signed-off-by: Claudio Suarez
lgtm, merged into drm-misc-next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c| 180 +++--
> drivers/gpu/drm/drm_atomic_helper.c | 243 +++-
> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> drivers/gpu/drm/drm_auth.c | 12 +-
> 4 files changed, 242 insertions(+), 195 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ff1416cd609a..21174efd91be 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -74,7 +74,7 @@ int drm_crtc_commit_wait(struct drm_crtc_commit *commit)
>
> ret = wait_for_completion_timeout(>hw_done, timeout);
> if (!ret) {
> - DRM_ERROR("hw_done timed out\n");
> + drm_err(commit->crtc->dev, "hw_done timed out\n");
> return -ETIMEDOUT;
> }
>
> @@ -84,7 +84,7 @@ int drm_crtc_commit_wait(struct drm_crtc_commit *commit)
>*/
> ret = wait_for_completion_timeout(>flip_done, timeout);
> if (!ret) {
> - DRM_ERROR("flip_done timed out\n");
> + drm_err(commit->crtc->dev, "flip_done timed out\n");
> return -ETIMEDOUT;
> }
>
> @@ -140,7 +140,7 @@ drm_atomic_state_init(struct drm_device *dev, struct
> drm_atomic_state *state)
>
> state->dev = dev;
>
> - DRM_DEBUG_ATOMIC("Allocated atomic state %p\n", state);
> + drm_dbg_atomic(dev, "Allocated atomic state %p\n", state);
>
> return 0;
> fail:
> @@ -191,7 +191,7 @@ void drm_atomic_state_default_clear(struct
> drm_atomic_state *state)
> struct drm_mode_config *config = >mode_config;
> int i;
>
> - DRM_DEBUG_ATOMIC("Clearing atomic state %p\n", state);
> + drm_dbg_atomic(dev, "Clearing atomic state %p\n", state);
>
> for (i = 0; i < state->num_connector; i++) {
> struct drm_connector *connector = state->connectors[i].ptr;
> @@ -301,7 +301,7 @@ void __drm_atomic_state_free(struct kref *ref)
>
> drm_atomic_state_clear(state);
>
> - DRM_DEBUG_ATOMIC("Freeing atomic state %p\n", state);
> + drm_dbg_atomic(state->dev, "Freeing atomic state %p\n", state);
>
> if (config->funcs->atomic_state_free) {
> config->funcs->atomic_state_free(state);
> @@ -358,8 +358,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> state->crtcs[index].ptr = crtc;
> crtc_state->state = state;
>
> - DRM_DEBUG_ATOMIC("Added [CRTC:%d:%s] %p state to %p\n",
> - crtc->base.id, crtc->name, crtc_state, state);
> + drm_dbg_atomic(state->dev, "Added [CRTC:%d:%s] %p state to %p\n",
> +crtc->base.id, crtc->name, crtc_state, state);
>
> return crtc_state;
> }
> @@ -379,8 +379,9 @@ static int drm_atomic_crtc_check(const struct
> drm_crtc_state *old_crtc_state,
>*/
>
> if (new_crtc_state->active && !new_crtc_state->enable) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
> - crtc->base.id, crtc->name);
> + drm_dbg_atomic(crtc->dev,
> +"[CRTC:%d:%s] active without enabled\n",
> +crtc->base.id, crtc->name);
> return -EINVAL;
> }
>
> @@ -390,15 +391,17 @@ static int drm_atomic_crtc_check(const struct
> drm_crtc_state *old_crtc_state,
>*/
> if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
> WARN_ON(new_crtc_state->enable && !new_crtc_state->mode_blob)) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
> - crtc->base.id, crtc->name);
> + drm_dbg_atomic(crtc->dev,
> +"[CRTC:%d:%s] enabled without mode blob\n",
> +crtc->base.id, crtc->name);
> return -EINVAL;
> }
>
> if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
> WARN_ON(!new_crtc_state->enable && new_crtc_state->mode_blob)) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n",
> - crtc->base.id, crtc->name);
> + drm_dbg_atomic(crtc->dev,
> +"[CRTC:%d:%s] disabled with mode blob\n",
> +crtc->base.id, crtc->name);
> return -EINVAL;
> }
>
> @@ -414,8 +417,9 @@ static int drm_atomic_crtc_check(const struct
> drm_crtc_state *old_crtc_state,
>*/
> if (new_crtc_state->event &&
> !new_crtc_state->active && !old_crtc_state->active) {
>
Re: [PATCH v2 0/6] drm/vc4: kms: Misc fixes for HVS commits
On Fri, Nov 19, 2021 at 06:24:34PM +0800, Jian-Hong Pan wrote: > Maxime Ripard 於 2021年11月18日 週四 下午6:40寫道： > > > > On Thu, Nov 18, 2021 at 02:42:58PM +0800, Jian-Hong Pan wrote: > > > Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道： > > > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: > > > > Convert to > > > > atomic helpers") introduced a number of issues in corner cases, most of > > > > them > > > > showing themselves in the form of either a vblank timeout or > > > > use-after-free > > > > error. > > > > > > > > These patches should fix most of them, some of them still being > > > > debugged. > > > > > > > > Maxime > > > > > > > > Changes from v1: > > > > - Prevent a null pointer dereference > > > > > > > > Maxime Ripard (6): > > > > drm/vc4: kms: Wait for the commit before increasing our clock rate > > > > drm/vc4: kms: Fix return code check > > > > drm/vc4: kms: Add missing drm_crtc_commit_put > > > > drm/vc4: kms: Clear the HVS FIFO commit pointer once done > > > > drm/vc4: kms: Don't duplicate pending commit > > > > drm/vc4: kms: Fix previous HVS commit wait > > > > > > > > drivers/gpu/drm/vc4/vc4_kms.c | 42 --- > > > > 1 file changed, 19 insertions(+), 23 deletions(-) > > > > > > I tested the v2 patches based on latest mainline kernel with RPi 4B. > > > System can boot up into desktop environment. > > > > So the thing that was broken initially isn't anymore? > > No. It does not appear anymore. > > > > Although it still hit the bug [1], which might be under debugging, I > > > think these patches LGTM. > > > > The vblank timeout stuff is a symptom of various different bugs. Can you > > share your setup, your config.txt, and what you're doing to trigger it? > > I get the RPi boot firmware files from raspberrypi's repository at tag > 1.20211029 [1] > And, make system boots: > RPi firmware -> U-Boot -> Linux kernel (aarch64) with corresponding DTB > > The config.txt only has: > enable_uart=1 > arm_64bit=1 > kernel=uboot.bin > > This bug can be reproduced with es2gears command easily. May need to > wait it running a while. > > Mesa: 21.2.2 > libdrm: 2.4.107 > xserver/wayland: 1.20.11 Using wayland > > This bug happens with direct boot path as well: > RPi firmware -> Linux kernel (aarch64) with corresponding DTB > > I tried with Endless OS and Ubuntu's RPi 4B images. > An easy setup is using Ubuntu 21.10 RPi 4B image [2]. Then, replace > the kernel & device tree blob and edit the config.txt. Does it still appear if you raise the core clock in the config.txt file using: core_freq_min=600 ? Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v2 00/13] drm: Add generic helpers for HDMI scrambling
Hi Daniel, On Fri, Nov 19, 2021 at 05:01:14PM +0100, Daniel Vetter wrote: > On Thu, Nov 18, 2021 at 11:38:01AM +0100, Maxime Ripard wrote: > > This is a follow-up of the work to support the interactions between the > > hotplug > > and the scrambling support for vc4: > > > > https://lore.kernel.org/dri-devel/20210507150515.257424-11-max...@cerno.tech/ > > https://lore.kernel.org/dri-devel/20211025152903.1088803-10-max...@cerno.tech/ > > > > Ville feedback was that the same discussion happened some time ago for i915, > > and resulted in a function to do an full disable/enable cycle on > > reconnection > > to avoid breaking the HDMI 2.0 spec. > > > > This series improves the current scrambling support by adding generic > > helpers > > for usual scrambling-related operations, and builds upon them to provide a > > generic alternative to intel_hdmi_reset_link. > > Out of curiosity, can we rebuild intel_hdmi_reset_link on top of these? > Always better to have two drivers to actually show the helpers help, than > just one. Unfortunately, I don't have any Intel system I can test it on, and it looks like the changes wouldn't be trivial. Maybe we can use dw-hdmi instead? Maxime signature.asc Description: PGP signature
Re: [PATCH 1/6] Documentation/gpu: Reorganize DC documentation
On Thu, Nov 25, 2021 at 10:38:25AM -0500, Rodrigo Siqueira wrote: > Display core documentation is not well organized, and it is hard to find > information due to the lack of sections. This commit reorganizes the > documentation layout, and it is preparation work for future changes. > > Signed-off-by: Rodrigo Siqueira > --- > Documentation/gpu/amdgpu-dc.rst | 74 --- > .../gpu/amdgpu-dc/amdgpu-dc-debug.rst | 4 + > Documentation/gpu/amdgpu-dc/amdgpu-dc.rst | 29 > Documentation/gpu/amdgpu-dc/amdgpu-dm.rst | 42 +++ > Documentation/gpu/drivers.rst | 2 +- > 5 files changed, 76 insertions(+), 75 deletions(-) > delete mode 100644 Documentation/gpu/amdgpu-dc.rst > create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst > create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dc.rst > create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dm.rst > > diff --git a/Documentation/gpu/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc.rst > deleted file mode 100644 > index f7ff7e1309de.. > --- a/Documentation/gpu/amdgpu-dc.rst > +++ /dev/null > @@ -1,74 +0,0 @@ > -=== > -drm/amd/display - Display Core (DC) > -=== > - > -*placeholder - general description of supported platforms, what dc is, etc.* > - > -Because it is partially shared with other operating systems, the Display Core > -Driver is divided in two pieces. > - > -1. **Display Core (DC)** contains the OS-agnostic components. Things like > - hardware programming and resource management are handled here. > -2. **Display Manager (DM)** contains the OS-dependent components. Hooks to > the > - amdgpu base driver and DRM are implemented here. > - > -It doesn't help that the entire package is frequently referred to as DC. But > -with the context in mind, it should be clear. > - > -When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for > -supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command line. > -Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`. > - > -To determine if DC is loaded, search dmesg for the following entry: > - > -``Display Core initialized with `` > - > -AMDgpu Display Manager > -== > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > - :doc: overview > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h > - :internal: > - > -Lifecycle > -- > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > - :doc: DM Lifecycle > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > - :functions: dm_hw_init dm_hw_fini > - > -Interrupts > --- > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c > - :doc: overview > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c > - :internal: > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > - :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq > - > -Atomic Implementation > -- > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > - :doc: atomic > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > - :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail > - > -Display Core > - > - > -**WIP** > - > -FreeSync Video > --- > - > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > - :doc: FreeSync Video > diff --git a/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst > b/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst > new file mode 100644 > index ..bbb8c3fc8eee > --- /dev/null > +++ b/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst > @@ -0,0 +1,4 @@ > +Display Core Debug tools > + > + > +TODO > diff --git a/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst > b/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst > new file mode 100644 > index ..3685b3b1ad64 > --- /dev/null > +++ b/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst While we bikeshed names, I think it'd would make sense to call this overview.rst or intro.rst or similar, since it's meant to contain the overall toctree for everything amdgpu related (maybe there will be more in the future). -Daniel > @@ -0,0 +1,29 @@ > +=== > +drm/amd/display - Display Core (DC) > +=== > + > +*placeholder - general description of supported platforms, what dc is, etc.* > + > +Because it is partially shared with other operating systems, the Display Core > +Driver is divided in two pieces. > + > +1. **Display Core (DC)** contains the OS-agnostic components. Things like > + hardware programming and resource management are handled here. > +2. **Display Manager (DM)** contains the OS-dependent components. Hooks to > the > + amdgpu base driver and
Re: [PATCH 1/6] Documentation/gpu: Reorganize DC documentation
On Fri, Nov 26, 2021 at 11:35:03AM +0100, Christian König wrote: > Just a general comment. Could you name the new subdirectory "amdgpu" > instead? > > DC is just a component of the amdgpu driver and I think it would sooner or > later make sense to group together the amdgpu documentation in one folder. Seconded, I think when driver docs get too big for the single file approach a directory matching the driver name sounds best. Also at that point maybe just drop the amdgpu prefix in the .rst files, it's kinda redundant? -Daniel > > Regards, > Christian. > > Am 25.11.21 um 16:38 schrieb Rodrigo Siqueira: > > Display core documentation is not well organized, and it is hard to find > > information due to the lack of sections. This commit reorganizes the > > documentation layout, and it is preparation work for future changes. > > > > Signed-off-by: Rodrigo Siqueira > > --- > > Documentation/gpu/amdgpu-dc.rst | 74 --- > > .../gpu/amdgpu-dc/amdgpu-dc-debug.rst | 4 + > > Documentation/gpu/amdgpu-dc/amdgpu-dc.rst | 29 > > Documentation/gpu/amdgpu-dc/amdgpu-dm.rst | 42 +++ > > Documentation/gpu/drivers.rst | 2 +- > > 5 files changed, 76 insertions(+), 75 deletions(-) > > delete mode 100644 Documentation/gpu/amdgpu-dc.rst > > create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst > > create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dc.rst > > create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dm.rst > > > > diff --git a/Documentation/gpu/amdgpu-dc.rst > > b/Documentation/gpu/amdgpu-dc.rst > > deleted file mode 100644 > > index f7ff7e1309de.. > > --- a/Documentation/gpu/amdgpu-dc.rst > > +++ /dev/null > > @@ -1,74 +0,0 @@ > > -=== > > -drm/amd/display - Display Core (DC) > > -=== > > - > > -*placeholder - general description of supported platforms, what dc is, > > etc.* > > - > > -Because it is partially shared with other operating systems, the Display > > Core > > -Driver is divided in two pieces. > > - > > -1. **Display Core (DC)** contains the OS-agnostic components. Things like > > - hardware programming and resource management are handled here. > > -2. **Display Manager (DM)** contains the OS-dependent components. Hooks to > > the > > - amdgpu base driver and DRM are implemented here. > > - > > -It doesn't help that the entire package is frequently referred to as DC. > > But > > -with the context in mind, it should be clear. > > - > > -When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for > > -supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command > > line. > > -Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`. > > - > > -To determine if DC is loaded, search dmesg for the following entry: > > - > > -``Display Core initialized with `` > > - > > -AMDgpu Display Manager > > -== > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > - :doc: overview > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h > > - :internal: > > - > > -Lifecycle > > -- > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > - :doc: DM Lifecycle > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > - :functions: dm_hw_init dm_hw_fini > > - > > -Interrupts > > --- > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c > > - :doc: overview > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c > > - :internal: > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > - :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq > > - > > -Atomic Implementation > > -- > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > - :doc: atomic > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > - :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail > > - > > -Display Core > > - > > - > > -**WIP** > > - > > -FreeSync Video > > --- > > - > > -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > - :doc: FreeSync Video > > diff --git a/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst > > b/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst > > new file mode 100644 > > index ..bbb8c3fc8eee > > --- /dev/null > > +++ b/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst > > @@ -0,0 +1,4 @@ > > +Display Core Debug tools > > + > > + > > +TODO > > diff --git a/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst > > b/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst > > new file mode 100644 > > index ..3685b3b1ad64 > > --- /dev/null > > +++ b/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst > > @@ -0,0 +1,29 @@ > >
Re: [PATCH 19/26] drm: support more than one write fence in drm_gem_plane_helper_prepare_fb
On Fri, Nov 26, 2021 at 11:30:19AM +0100, Christian König wrote:
> Am 25.11.21 um 16:47 schrieb Daniel Vetter:
> > On Tue, Nov 23, 2021 at 03:21:04PM +0100, Christian König wrote:
> > > Use dma_resv_get_singleton() here to eventually get more than one write
> > > fence as single fence.
> > Yeah this is nice, atomic commit helpers not supporting multiple write
> > fences was really my main worry in this entire endeavour. Otherwise looks
> > all rather reasonable.
> >
> > I'll try to find some review bandwidth, but would be really if you can
> > volunteer others too (especially making sure ttm drivers set the KERNEL
> > fences correctly in all cases).
>
> Maybe I should split that up into switching over to adding the enum and then
> switching to kernel/bookkeep(previously other) for some use cases.
>
> It would be good if I could get an rb on the trivial driver cleanups first.
> I can send those out individually if that helps.
Yeah some of the conversion patches might make sense to be split a bit
more. Especially when there's functional changes hiding, but I tought
you've split them out? But didn't read them in detail.
Either way for stuff like this I think it's always best to split the
mechanical stuff from the concept intro/docs and functional changes,
except when it's really very obvious what's going on and just as small
patch.
-Daniel
>
> Thanks,
> Christian.
>
> > -Daniel
> >
> >
> > > Signed-off-by: Christian König
> > > ---
> > > drivers/gpu/drm/drm_gem_atomic_helper.c | 18 +++---
> > > 1 file changed, 7 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > b/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > index c3189afe10cb..9338ddb7edff 100644
> > > --- a/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > @@ -143,25 +143,21 @@
> > >*/
> > > int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct
> > > drm_plane_state *state)
> > > {
> > > - struct dma_resv_iter cursor;
> > > struct drm_gem_object *obj;
> > > struct dma_fence *fence;
> > > + int ret;
> > > if (!state->fb)
> > > return 0;
> > > obj = drm_gem_fb_get_obj(state->fb, 0);
> > > - dma_resv_iter_begin(, obj->resv, false);
> > > - dma_resv_for_each_fence_unlocked(, fence) {
> > > - /* TODO: Currently there should be only one write fence, so this
> > > - * here works fine. But drm_atomic_set_fence_for_plane() should
> > > - * be changed to be able to handle more fences in general for
> > > - * multiple BOs per fb anyway. */
> > > - dma_fence_get(fence);
> > > - break;
> > > - }
> > > - dma_resv_iter_end();
> > > + ret = dma_resv_get_singleton(obj->resv, false, );
> > > + if (ret)
> > > + return ret;
> > > + /* TODO: drm_atomic_set_fence_for_plane() should be changed to be able
> > > + * to handle more fences in general for multiple BOs per fb.
> > > + */
> > > drm_atomic_set_fence_for_plane(state, fence);
> > > return 0;
> > > }
> > > --
> > > 2.25.1
> > >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v4] drm/i915: Use per device iommu check
From: Tvrtko Ursulin
With both integrated and discrete Intel GPUs in a system, the current
global check of intel_iommu_gfx_mapped, as done from intel_vtd_active()
may not be completely accurate.
In this patch we add i915 parameter to intel_vtd_active() in order to
prepare it for multiple GPUs and we also change the check away from Intel
specific intel_iommu_gfx_mapped (global exported by the Intel IOMMU
driver) to probing the presence of IOMMU on a specific device using
device_iommu_mapped().
This will return true both for IOMMU pass-through and address translation
modes which matches the current behaviour. If in the future we wanted to
distinguish between these two modes we could either use
iommu_get_domain_for_dev() and check for __IOMMU_DOMAIN_PAGING bit
indicating address translation, or ask for a new API to be exported from
the IOMMU core code.
v2:
* Check for dmar translation specifically, not just iommu domain. (Baolu)
v3:
* Go back to plain "any domain" check for now, rewrite commit message.
v4:
* Use device_iommu_mapped. (Robin, Baolu)
Signed-off-by: Tvrtko Ursulin
Cc: Lu Baolu
Cc: Lucas De Marchi
Cc: Robin Murphy
Acked-by: Robin Murphy
Reviewed-by: Lu Baolu
---
drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gemfs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_driver.c | 7 +++
drivers/gpu/drm/i915/i915_drv.h | 13 +++--
drivers/gpu/drm/i915/i915_gpu_error.c| 5 +
drivers/gpu/drm/i915/intel_device_info.c | 14 +-
drivers/gpu/drm/i915/intel_pm.c | 2 +-
12 files changed, 25 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index abec394f6869..2da4aacc956b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -634,7 +634,7 @@ static unsigned int intel_bw_data_rate(struct
drm_i915_private *dev_priv,
for_each_pipe(dev_priv, pipe)
data_rate += bw_state->data_rate[pipe];
- if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active())
+ if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active(dev_priv))
data_rate = data_rate * 105 / 100;
return data_rate;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b2d51cd79d6c..1ef77ba7f645 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1293,7 +1293,7 @@ static bool needs_async_flip_vtd_wa(const struct
intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
- return crtc_state->uapi.async_flip && intel_vtd_active() &&
+ return crtc_state->uapi.async_flip && intel_vtd_active(i915) &&
(DISPLAY_VER(i915) == 9 || IS_BROADWELL(i915) ||
IS_HASWELL(i915));
}
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index d0c34bc3af6c..614e8697c068 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1677,7 +1677,7 @@ static int intel_sanitize_fbc_option(struct
drm_i915_private *i915)
static bool need_fbc_vtd_wa(struct drm_i915_private *i915)
{
/* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
- if (intel_vtd_active() &&
+ if (intel_vtd_active(i915) &&
(IS_SKYLAKE(i915) || IS_BROXTON(i915))) {
drm_info(>drm,
"Disabling framebuffer compression (FBC) to prevent
screen flicker with VT-d enabled\n");
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 80680395bb3b..bce03d74a0b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -399,7 +399,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
return 0;
}
- if (intel_vtd_active() && GRAPHICS_VER(i915) < 8) {
+ if (intel_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
drm_notice(>drm,
"%s, disabling use of stolen memory\n",
"DMAR active");
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index dbdbdc344d87..11cd66d183e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -31,7 +31,7 @@ int i915_gemfs_init(struct drm_i915_private *i915)
*/
opts = NULL;
- if (intel_vtd_active()) {
+ if (intel_vtd_active(i915)) {
if
Re: [PATCH v7 2/6] drm/sprd: add Unisoc's drm kms master
On 25-10-2021 11:34, Kevin Tang wrote:
> Adds drm support for the Unisoc's display subsystem.
>
> This is drm kms driver, this driver provides support for the
> application framework in Android, Yocto and more.
>
> Application framework can access Unisoc's display internal
> peripherals through libdrm or libkms, it's test ok by modetest
> (DRM/KMS test tool) and Android HWComposer.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
>
> v4:
> - Move the devm_drm_dev_alloc to master_ops->bind function.
> - The managed drmm_mode_config_init() it is no longer necessary for drivers
> to explicitly call drm_mode_config_cleanup, so delete it.
>
> v5:
> - Remove subdir-ccflgas-y for Makefile.
> - Keep the selects sorted by alphabet for Kconfig.
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile| 1 +
> drivers/gpu/drm/sprd/Kconfig| 11 ++
> drivers/gpu/drm/sprd/Makefile | 3 +
> drivers/gpu/drm/sprd/sprd_drm.c | 203
> drivers/gpu/drm/sprd/sprd_drm.h | 16 +++
> 6 files changed, 236 insertions(+)
> create mode 100644 drivers/gpu/drm/sprd/Kconfig
> create mode 100644 drivers/gpu/drm/sprd/Makefile
> create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
> create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 2a926d0de..8220be1b5 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -380,6 +380,8 @@ source "drivers/gpu/drm/xlnx/Kconfig"
>
> source "drivers/gpu/drm/gud/Kconfig"
>
> +source "drivers/gpu/drm/sprd/Kconfig"
> +
> config DRM_HYPERV
> tristate "DRM Support for Hyper-V synthetic video device"
> depends on DRM && PCI && MMU && HYPERV
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 0dff40bb8..ec2756806 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -127,3 +127,4 @@ obj-$(CONFIG_DRM_TIDSS) += tidss/
> obj-y+= xlnx/
> obj-y+= gud/
> obj-$(CONFIG_DRM_HYPERV) += hyperv/
> +obj-$(CONFIG_DRM_SPRD) += sprd/
> diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> new file mode 100644
> index 0..726c3e76d
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Kconfig
> @@ -0,0 +1,11 @@
> +config DRM_SPRD
> + tristate "DRM Support for Unisoc SoCs Platform"
> + depends on ARCH_SPRD || COMPILE_TEST
> + depends on DRM && OF
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_KMS_HELPER
> + help
> + Choose this option if you have a Unisoc chipset.
> + If M is selected the module will be called sprd_drm.
> +
> diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> new file mode 100644
> index 0..9850f00b8
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-y := sprd_drm.o
> diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
> new file mode 100644
> index 0..bb87f28f2
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Unisoc Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sprd_drm.h"
> +
> +#define DRIVER_NAME "sprd"
> +#define DRIVER_DESC "Spreadtrum SoCs' DRM Driver"
> +#define DRIVER_DATE "20200201"
> +#define DRIVER_MAJOR 1
> +#define DRIVER_MINOR 0
> +
> +static const struct drm_mode_config_helper_funcs sprd_drm_mode_config_helper
> = {
> + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> +};
> +
> +static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
> + .fb_create = drm_gem_fb_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static void sprd_drm_mode_config_init(struct drm_device *drm)
> +{
> + drm->mode_config.min_width = 0;
> + drm->mode_config.min_height = 0;
> + drm->mode_config.max_width = 8192;
> + drm->mode_config.max_height = 8192;
> + drm->mode_config.allow_fb_modifiers = true;
> +
> + drm->mode_config.funcs = _drm_mode_config_funcs;
> + drm->mode_config.helper_private = _drm_mode_config_helper;
> +}
> +
> +DEFINE_DRM_GEM_CMA_FOPS(sprd_drm_fops);
> +
> +static struct drm_driver sprd_drm_drv = {
> + .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> + .fops = _drm_fops,
> +
> + /* GEM Operations */
> + DRM_GEM_CMA_DRIVER_OPS,
> +
> + .name = DRIVER_NAME,
> + .desc = DRIVER_DESC,
> + .date = DRIVER_DATE,
> + .major = DRIVER_MAJOR,
> +
Re: [PATCH] drm/i915: Use per device iommu check
On 26/11/2021 08:26, Lu Baolu wrote: On 2021/11/25 19:47, Robin Murphy wrote: On 2021-11-25 10:42, Tvrtko Ursulin wrote: From: Tvrtko Ursulin With both integrated and discrete Intel GPUs in a system, the current global check of intel_iommu_gfx_mapped, as done from intel_vtd_active() may not be completely accurate. In this patch we add i915 parameter to intel_vtd_active() in order to prepare it for multiple GPUs and we also change the check away from Intel specific intel_iommu_gfx_mapped (global exported by the Intel IOMMU driver) to probing the presence of IOMMU domain on a specific device using iommu_get_domain_for_dev(). FWIW the way you have it now is functionally equivalent to using device_iommu_mapped(), which I think might be slightly clearer for the current intent, but I don't have a significantly strong preference (after all, this *was* the de-facto way of checking before device_iommu_mapped() was introduced, and there are still other examples of it around). So from the IOMMU perspective, Acked-by: Robin Murphy Perhaps the AGP driver could also be tweaked and intel_iommu_gfx_mapped cleaned away entirely, but I'll leave that for Baolu to think about :) I fully agreed with Robin. I prefer device_iommu_mapped() more than iommu_get_domain_for_dev(). "iommu_get_domain_for_dev(dev) == NULL" simply means that the device does not have any domain attached. Although at present, it is equivalent to device DMAing without IOMMU translation. But I'm sure it will change in the future. With device_iommu_mapped() replaced, Reviewed-by: Lu Baolu I have empirically established device_iommu_mapped() matches 1:1 with intel_iommu_gfx_mapped and a simple non-NULL check against iommu_get_domain_for_dev(), so okay, I will respin with that change. We leave the problem of being able to distinguish between pass-through and address translation from the drivers for later. Thanks both! Regards, Tvrtko
Re: [Intel-gfx] [PATCH] drm/i915: Disable bonding on gen12+ platforms
On 07/08/2021 06:02, Matt Roper wrote:
On Fri, Aug 06, 2021 at 08:54:59PM +0200, Daniel Vetter wrote:
On Fri, Aug 6, 2021 at 8:25 PM John Harrison wrote:
On 7/28/2021 12:21, Matthew Brost wrote:
Disable bonding on gen12+ platforms aside from ones already supported by
the i915 - TGL, RKL, and ADL-S.
Does this needs adjusting for the change in ADL-P plans?
Regards,
Tvrtko
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 05c3ee191710..9c3672bac0e2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -446,6 +446,13 @@ set_proto_ctx_engines_bond(struct i915_user_extension
__user *base, void *data)
u16 idx, num_bonds;
int err, n;
+ if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915) &&
+ !IS_ROCKETLAKE(i915) && !IS_ALDERLAKE_S(i915)) {
+ drm_dbg(>drm,
+ "Bonding on gen12+ aside from TGL, RKL, and ADL_S not
allowed\n");
I would have said not supported rather than not allowed. Either way:
Reviewed-by: John Harrison
Either is fine with me.
Acked-by: Daniel Vetter
Applied to drm-intel-gt-next (with the suggested debug message wording
tweak). Thanks for the patch and reviews.
Matt
+ return -ENODEV;
+ }
+
if (get_user(idx, >virtual_index))
return -EFAULT;
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/2] drm/ bridge: tc358762: move bridge init to enable callback
Hi Dmitry
On Fri, 26 Nov 2021 at 00:32, Dmitry Baryshkov
wrote:
>
> During the pre_enable time the previous bridge (e.g. DSI host) might be
> not initialized yet. Move the regulator enablement and bridge init to
> te enable callback (and consequently regulator disblement to disable).
Except that in the enable callback the DSI host has video enabled too,
so the data lanes may be in HS mode too, and the bridge may not be
prepared to accept that during power on / initialisation. That means
you've got a race condition over how quickly the composition hardware
starts producing pixel data vs when this enable callback is called. I
suspect that is why we had [1] for the rare case when the race
condition failed.
There's also seems to be no guarantee that a host can do LP commands
between HS video packets (eg sunxi [2])
This is the same issue that was being hacked around in [3], and is one
of the questions I'd raised back in July [4].
The DSI support is broken when it comes to accommodating
initialisation sequences, but in trying to ensure all possible
sequences can be accomodated, all currently proposed solutions have
been shot down.
Some platforms have worked around it by powering up the DSI host in
mode_set (dw-mipi-dsi), others have broken the bridge chain apart so
their pre_enable gets called first (exynos and currently vc4) except
that approach is broken for the atomic API.
There is a need for some form of resolution, even if it is only
documenting the correct hack to implement in the DSI host driver.
Hacking bridge or panel drivers to try and workaround it seems wrong.
Dave
[1] https://lists.freedesktop.org/archives/dri-devel/2021-September/322119.html
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#n776
[3] https://lists.freedesktop.org/archives/dri-devel/2021-November/332003.html
[4] https://lists.freedesktop.org/archives/dri-devel/2021-July/313576.html
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/tc358762.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358762.c
> b/drivers/gpu/drm/bridge/tc358762.c
> index 7104828024fd..ebdf771a1e49 100644
> --- a/drivers/gpu/drm/bridge/tc358762.c
> +++ b/drivers/gpu/drm/bridge/tc358762.c
> @@ -64,7 +64,7 @@ struct tc358762 {
> struct drm_connector connector;
> struct regulator *regulator;
> struct drm_bridge *panel_bridge;
> - bool pre_enabled;
> + bool enabled;
> int error;
> };
>
> @@ -125,26 +125,26 @@ static int tc358762_init(struct tc358762 *ctx)
> return tc358762_clear_error(ctx);
> }
>
> -static void tc358762_post_disable(struct drm_bridge *bridge)
> +static void tc358762_disable(struct drm_bridge *bridge)
> {
> struct tc358762 *ctx = bridge_to_tc358762(bridge);
> int ret;
>
> /*
> -* The post_disable hook might be called multiple times.
> +* The disable hook might be called multiple times.
> * We want to avoid regulator imbalance below.
> */
> - if (!ctx->pre_enabled)
> + if (!ctx->enabled)
> return;
>
> - ctx->pre_enabled = false;
> + ctx->enabled = false;
>
> ret = regulator_disable(ctx->regulator);
> if (ret < 0)
> dev_err(ctx->dev, "error disabling regulators (%d)\n", ret);
> }
>
> -static void tc358762_pre_enable(struct drm_bridge *bridge)
> +static void tc358762_enable(struct drm_bridge *bridge)
> {
> struct tc358762 *ctx = bridge_to_tc358762(bridge);
> int ret;
> @@ -157,7 +157,7 @@ static void tc358762_pre_enable(struct drm_bridge *bridge)
> if (ret < 0)
> dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
>
> - ctx->pre_enabled = true;
> + ctx->enabled = true;
> }
>
> static int tc358762_attach(struct drm_bridge *bridge,
> @@ -170,8 +170,8 @@ static int tc358762_attach(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs tc358762_bridge_funcs = {
> - .post_disable = tc358762_post_disable,
> - .pre_enable = tc358762_pre_enable,
> + .disable = tc358762_disable,
> + .enable = tc358762_enable,
> .attach = tc358762_attach,
> };
>
> @@ -218,7 +218,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi)
> mipi_dsi_set_drvdata(dsi, ctx);
>
> ctx->dev = dev;
> - ctx->pre_enabled = false;
> + ctx->enabled = false;
>
> /* TODO: Find out how to get dual-lane mode working */
> dsi->lanes = 1;
> --
> 2.33.0
>
[PATCH v3 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API
From: Zhi Wang
To support the new mdev interfaces and the re-factor patches from
Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
initialization path has to be seperated into two phases:
a) Early initialization.
The early initialization of GVT requires to be done when loading i915.
Mostly it's because the inital clean HW state needs to be saved before
i915 touches the HW.
b) Late initalization.
This phases of initalization will setup the rest components of GVT-g,
which can be done later when the dedicated module is being loaded.
v3:
- Fix the errors when CONFIG_DRM_I915_WERROR is turned on. (Jani)
v2:
- Implement a mmio table instead of generating it by marco in i915. (Jani)
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Vivi Rodrigo
Cc: Zhenyu Wang
Cc: Zhi Wang
Tested-by: Terrence Xu
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/Makefile |2 +-
drivers/gpu/drm/i915/gvt/gvt.c | 38 +-
drivers/gpu/drm/i915/gvt/gvt.h |1 +
drivers/gpu/drm/i915/gvt/handlers.c| 1780 +++-
drivers/gpu/drm/i915/gvt/mmio.h|5 +-
drivers/gpu/drm/i915/gvt/mmio_info_table.c | 1461
drivers/gpu/drm/i915/gvt/mmio_info_table.h | 37 +
drivers/gpu/drm/i915/gvt/reg.h |9 +-
drivers/gpu/drm/i915/intel_gvt.c | 42 +-
9 files changed, 1777 insertions(+), 1598 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/mmio_info_table.c
create mode 100644 drivers/gpu/drm/i915/gvt/mmio_info_table.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index cdc244bbbfc1..55603aebe3e4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -309,7 +309,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
i915-y += i915_vgpu.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
-i915-y += intel_gvt.o
+i915-y += intel_gvt.o gvt/mmio_info_table.o
include $(src)/gvt/Makefile
endif
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index cbac409f6c8a..c7580db355c0 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -63,23 +63,6 @@ static const struct intel_gvt_ops intel_gvt_ops = {
.emulate_hotplug = intel_vgpu_emulate_hotplug,
};
-static void init_device_info(struct intel_gvt *gvt)
-{
- struct intel_gvt_device_info *info = >device_info;
- struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
-
- info->max_support_vgpus = 8;
- info->cfg_space_size = PCI_CFG_SPACE_EXP_SIZE;
- info->mmio_size = 2 * 1024 * 1024;
- info->mmio_bar = 0;
- info->gtt_start_offset = 8 * 1024 * 1024;
- info->gtt_entry_size = 8;
- info->gtt_entry_size_shift = 3;
- info->gmadr_bytes_in_cmd = 8;
- info->max_surface_size = 36 * 1024 * 1024;
- info->msi_cap_offset = pdev->msi_cap;
-}
-
static void intel_gvt_test_and_emulate_vblank(struct intel_gvt *gvt)
{
struct intel_vgpu *vgpu;
@@ -169,7 +152,6 @@ void intel_gvt_clean_device(struct drm_i915_private *i915)
intel_gvt_clean_workload_scheduler(gvt);
intel_gvt_clean_gtt(gvt);
intel_gvt_free_firmware(gvt);
- intel_gvt_clean_mmio_info(gvt);
idr_destroy(>vgpu_idr);
kfree(i915->gvt);
@@ -188,16 +170,12 @@ void intel_gvt_clean_device(struct drm_i915_private *i915)
*/
int intel_gvt_init_device(struct drm_i915_private *i915)
{
- struct intel_gvt *gvt;
+ struct intel_gvt *gvt = i915->gvt;
struct intel_vgpu *vgpu;
int ret;
- if (drm_WARN_ON(>drm, i915->gvt))
- return -EEXIST;
-
- gvt = kzalloc(sizeof(struct intel_gvt), GFP_KERNEL);
- if (!gvt)
- return -ENOMEM;
+ if (drm_WARN_ON(>drm, !i915->gvt))
+ return -ENODEV;
gvt_dbg_core("init gvt device\n");
@@ -205,12 +183,8 @@ int intel_gvt_init_device(struct drm_i915_private *i915)
spin_lock_init(>scheduler.mmio_context_lock);
mutex_init(>lock);
mutex_init(>sched_lock);
- gvt->gt = >gt;
- i915->gvt = gvt;
-
- init_device_info(gvt);
- ret = intel_gvt_setup_mmio_info(gvt);
+ ret = intel_gvt_setup_mmio_handlers(gvt);
if (ret)
goto out_clean_idr;
@@ -218,7 +192,7 @@ int intel_gvt_init_device(struct drm_i915_private *i915)
ret = intel_gvt_load_firmware(gvt);
if (ret)
- goto out_clean_mmio_info;
+ goto out_clean_idr;
ret = intel_gvt_init_irq(gvt);
if (ret)
@@ -277,8 +251,6 @@ int intel_gvt_init_device(struct drm_i915_private *i915)
intel_gvt_clean_gtt(gvt);
out_free_firmware:
intel_gvt_free_firmware(gvt);
-out_clean_mmio_info:
- intel_gvt_clean_mmio_info(gvt);
out_clean_idr:
idr_destroy(>vgpu_idr);
kfree(gvt);
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h
[PATCH v3 2/2] i915/gvt: save the MMIO snapshot in the early init of GVT-g
From: Zhi Wang
To support the early init of GVT-g, which will be put in i915, after the
GVT-g is moved into a dedicated module, we need to save the MMIO snapshot
in the early init of GVT-g, when the HW hasn't been touched.
v3:
- Fix errors when CONFIG_DRM_I915_WERROR is turned on. (Jani)
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Vivi Rodrigo
Cc: Zhenyu Wang
Cc: Zhi Wang
Tested-by: Terrence Xu
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/gvt/firmware.c| 40 +---
drivers/gpu/drm/i915/gvt/handlers.c| 39
drivers/gpu/drm/i915/gvt/mmio_info_table.c | 72 +-
drivers/gpu/drm/i915/gvt/mmio_info_table.h | 3 +
4 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c
b/drivers/gpu/drm/i915/gvt/firmware.c
index 1a8274a3f4b1..28719c2f253f 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -66,12 +66,6 @@ static struct bin_attribute firmware_attr = {
.mmap = NULL,
};
-static int mmio_snapshot_handler(struct intel_gvt *gvt, u32 offset, void *data)
-{
- *(u32 *)(data + offset) = intel_uncore_read_notrace(gvt->gt->uncore,
- _MMIO(offset));
- return 0;
-}
static int expose_firmware_sysfs(struct intel_gvt *gvt)
{
@@ -81,7 +75,7 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
void *firmware;
void *p;
unsigned long size, crc32_start;
- int i, ret;
+ int ret;
size = sizeof(*h) + info->mmio_size + info->cfg_space_size;
firmware = vzalloc(size);
@@ -99,17 +93,11 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
p = firmware + h->cfg_space_offset;
- for (i = 0; i < h->cfg_space_size; i += 4)
- pci_read_config_dword(pdev, i, p + i);
-
- memcpy(gvt->firmware.cfg_space, p, info->cfg_space_size);
+ memcpy(p, gvt->firmware.cfg_space, info->cfg_space_size);
p = firmware + h->mmio_offset;
- /* Take a snapshot of hw mmio registers. */
- intel_gvt_for_each_tracked_mmio(gvt, mmio_snapshot_handler, p);
-
- memcpy(gvt->firmware.mmio, p, info->mmio_size);
+ memcpy(p, gvt->firmware.mmio, info->mmio_size);
crc32_start = offsetof(struct gvt_firmware_header, crc32) + 4;
h->crc32 = crc32_le(0, firmware + crc32_start, size - crc32_start);
@@ -142,9 +130,6 @@ void intel_gvt_free_firmware(struct intel_gvt *gvt)
{
if (!gvt->firmware.firmware_loaded)
clean_firmware_sysfs(gvt);
-
- kfree(gvt->firmware.cfg_space);
- vfree(gvt->firmware.mmio);
}
static int verify_firmware(struct intel_gvt *gvt,
@@ -204,36 +189,17 @@ static int verify_firmware(struct intel_gvt *gvt,
*/
int intel_gvt_load_firmware(struct intel_gvt *gvt)
{
- struct intel_gvt_device_info *info = >device_info;
struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct intel_gvt_firmware *firmware = >firmware;
struct gvt_firmware_header *h;
const struct firmware *fw;
char *path;
- void *mem;
int ret;
path = kmalloc(PATH_MAX, GFP_KERNEL);
if (!path)
return -ENOMEM;
- mem = kmalloc(info->cfg_space_size, GFP_KERNEL);
- if (!mem) {
- kfree(path);
- return -ENOMEM;
- }
-
- firmware->cfg_space = mem;
-
- mem = vmalloc(info->mmio_size);
- if (!mem) {
- kfree(path);
- kfree(firmware->cfg_space);
- return -ENOMEM;
- }
-
- firmware->mmio = mem;
-
sprintf(path, "%s/vid_0x%04x_did_0x%04x_rid_0x%02x.golden_hw_state",
GVT_FIRMWARE_PATH, pdev->vendor, pdev->device,
pdev->revision);
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 2c064da3db6d..ba7b330a2c71 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -2406,45 +2406,6 @@ int intel_gvt_setup_mmio_handlers(struct intel_gvt *gvt)
return ret;
}
-/**
- * intel_gvt_for_each_tracked_mmio - iterate each tracked mmio
- * @gvt: a GVT device
- * @handler: the handler
- * @data: private data given to handler
- *
- * Returns:
- * Zero on success, negative error code if failed.
- */
-int intel_gvt_for_each_tracked_mmio(struct intel_gvt *gvt,
- int (*handler)(struct intel_gvt *gvt, u32 offset, void *data),
- void *data)
-{
- struct gvt_mmio_block *block = gvt->mmio.mmio_block;
- struct intel_gvt_mmio_info *e;
- int i, j, ret;
-
- hash_for_each(gvt->mmio.mmio_info_table, i, e, node) {
- ret = handler(gvt, e->offset, data);
- if (ret)
- return ret;
- }
-
- for (i = 0; i < gvt->mmio.num_mmio_block; i++, block++) {
-
[Bug 205089] amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125
https://bugzilla.kernel.org/show_bug.cgi?id=205089 ker...@feedmebits.nl changed: What|Removed |Added CC||ker...@feedmebits.nl --- Comment #27 from ker...@feedmebits.nl --- (In reply to Hristos from comment #25) > Kernel: 5.15.3 > Mesa: 21.2.5 > Xorg: 7.6 > > I see this when running OpenMW and a lot of mods > (https://modding-openmw.com/lists/total-overhaul/). OpenMW with no mods or a > smaller mod list seems to run fine. > > When the program starts rendering the actual game scene (after loading data > files and etc) it will hang, and then crash with "Failed to initialize > parser -125" messages in the console. > > It only happens with Mesa 21.2.X, though. When I downgraded to Mesa 21.1.7 > everything ran as expected. I'm running into the same issue with one of my games so far. What other packages did you have to downgrade besides mesa and lib32-mesa in order to get a working opengl? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
RE: [PATCH 4/4] drm: rcar-du: mipi-dsi: Support bridge probe ordering
Quoting Biju Das (2021-11-26 10:51:48)
> Hi Kieran,
>
> Thanks for the patch.
>
> > Subject: [PATCH 4/4] drm: rcar-du: mipi-dsi: Support bridge probe ordering
> >
> > The bridge probe ordering for DSI devices has been clarified and further
> > documented in
> >
> > To support connecting with the SN65DSI86 device after commit c3b75d4734cb
> > ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe"),
> > update to the new probe ordering to remove a perpetual -EPROBE_DEFER loop
> > between the two devices.
> >
> > Signed-off-by: Kieran Bingham
> > ---
> > drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 48 +
> > 1 file changed, 26 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > index 833f4480bdf3..f783bacee8da 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > @@ -639,6 +639,8 @@ static int rcar_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> > struct mipi_dsi_device *device)
> > {
> > struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> > + struct drm_panel *panel;
> > + int ret;
> >
> > if (device->lanes > dsi->num_data_lanes)
> > return -EINVAL;
> > @@ -646,12 +648,36 @@ static int rcar_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> > dsi->lanes = device->lanes;
> > dsi->format = device->format;
> >
> > + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> > + >next_bridge);
> > + if (ret) {
> > + dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
> > + return ret;
>
> This can merged with previous line. return dev_err_probe(dsi->dev, ret,
> "could not find next bridge\n");
> > + }
> > +
> > + if (!dsi->next_bridge) {
> > + dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
> > + if (IS_ERR(dsi->next_bridge)) {
> > + dev_err(dsi->dev, "failed to create panel bridge\n");
> > + return PTR_ERR(dsi->next_bridge);
>
> Why not return dev_err_probe??
Yes, I think it probably should. This was just a code move, so I didn't
change it.
--
Kieran
>
> Cheers,
> Biju
>
> > + }
> > + }
> > +
> > + /* Initialize the DRM bridge. */
> > + dsi->bridge.funcs = _mipi_dsi_bridge_ops;
> > + dsi->bridge.of_node = dsi->dev->of_node;
> > + drm_bridge_add(>bridge);
> > +
> > return 0;
> > }
> >
> > static int rcar_mipi_dsi_host_detach(struct mipi_dsi_host *host,
> > struct mipi_dsi_device *device)
> > {
> > + struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> > +
> > + drm_bridge_remove(>bridge);
> > +
> > return 0;
> > }
> >
> > @@ -766,21 +792,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
> > *pdev)
> > return PTR_ERR(dsi->rstc);
> > }
> >
> > - ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> > - >next_bridge);
> > - if (ret) {
> > - dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
> > - return ret;
> > - }
> > -
> > - if (!dsi->next_bridge) {
> > - dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
> > - if (IS_ERR(dsi->next_bridge)) {
> > - dev_err(dsi->dev, "failed to create panel bridge\n");
> > - return PTR_ERR(dsi->next_bridge);
> > - }
> > - }
> > -
> > /* Initialize the DSI host. */
> > dsi->host.dev = dsi->dev;
> > dsi->host.ops = _mipi_dsi_host_ops; @@ -788,11 +799,6 @@ static
> > int rcar_mipi_dsi_probe(struct platform_device *pdev)
> > if (ret < 0)
> > return ret;
> >
> > - /* Initialize the DRM bridge. */
> > - dsi->bridge.funcs = _mipi_dsi_bridge_ops;
> > - dsi->bridge.of_node = dsi->dev->of_node;
> > - drm_bridge_add(>bridge);
> > -
> > return 0;
> > }
> >
> > @@ -800,8 +806,6 @@ static int rcar_mipi_dsi_remove(struct platform_device
> > *pdev) {
> > struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
> >
> > - drm_bridge_remove(>bridge);
> > -
> > mipi_dsi_host_unregister(>host);
> >
> > return 0;
> > --
> > 2.30.2
>
RE: [PATCH 4/4] drm: rcar-du: mipi-dsi: Support bridge probe ordering
Hi Kieran,
Thanks for the patch.
> Subject: [PATCH 4/4] drm: rcar-du: mipi-dsi: Support bridge probe ordering
>
> The bridge probe ordering for DSI devices has been clarified and further
> documented in
>
> To support connecting with the SN65DSI86 device after commit c3b75d4734cb
> ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe"),
> update to the new probe ordering to remove a perpetual -EPROBE_DEFER loop
> between the two devices.
>
> Signed-off-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 48 +
> 1 file changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> index 833f4480bdf3..f783bacee8da 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -639,6 +639,8 @@ static int rcar_mipi_dsi_host_attach(struct
> mipi_dsi_host *host,
> struct mipi_dsi_device *device)
> {
> struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> + struct drm_panel *panel;
> + int ret;
>
> if (device->lanes > dsi->num_data_lanes)
> return -EINVAL;
> @@ -646,12 +648,36 @@ static int rcar_mipi_dsi_host_attach(struct
> mipi_dsi_host *host,
> dsi->lanes = device->lanes;
> dsi->format = device->format;
>
> + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> + >next_bridge);
> + if (ret) {
> + dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
> + return ret;
This can merged with previous line. return dev_err_probe(dsi->dev, ret, "could
not find next bridge\n");
> + }
> +
> + if (!dsi->next_bridge) {
> + dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
> + if (IS_ERR(dsi->next_bridge)) {
> + dev_err(dsi->dev, "failed to create panel bridge\n");
> + return PTR_ERR(dsi->next_bridge);
Why not return dev_err_probe??
Cheers,
Biju
> + }
> + }
> +
> + /* Initialize the DRM bridge. */
> + dsi->bridge.funcs = _mipi_dsi_bridge_ops;
> + dsi->bridge.of_node = dsi->dev->of_node;
> + drm_bridge_add(>bridge);
> +
> return 0;
> }
>
> static int rcar_mipi_dsi_host_detach(struct mipi_dsi_host *host,
> struct mipi_dsi_device *device)
> {
> + struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> +
> + drm_bridge_remove(>bridge);
> +
> return 0;
> }
>
> @@ -766,21 +792,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
> *pdev)
> return PTR_ERR(dsi->rstc);
> }
>
> - ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> - >next_bridge);
> - if (ret) {
> - dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
> - return ret;
> - }
> -
> - if (!dsi->next_bridge) {
> - dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
> - if (IS_ERR(dsi->next_bridge)) {
> - dev_err(dsi->dev, "failed to create panel bridge\n");
> - return PTR_ERR(dsi->next_bridge);
> - }
> - }
> -
> /* Initialize the DSI host. */
> dsi->host.dev = dsi->dev;
> dsi->host.ops = _mipi_dsi_host_ops; @@ -788,11 +799,6 @@ static
> int rcar_mipi_dsi_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> - /* Initialize the DRM bridge. */
> - dsi->bridge.funcs = _mipi_dsi_bridge_ops;
> - dsi->bridge.of_node = dsi->dev->of_node;
> - drm_bridge_add(>bridge);
> -
> return 0;
> }
>
> @@ -800,8 +806,6 @@ static int rcar_mipi_dsi_remove(struct platform_device
> *pdev) {
> struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
>
> - drm_bridge_remove(>bridge);
> -
> mipi_dsi_host_unregister(>host);
>
> return 0;
> --
> 2.30.2
[PATCH] drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_a*.c
DRM_DEBUG_* and DRM_* log calls are deprecated.
Change them to drm_dbg_* / drm_{err,info,...} calls in drm core
files.
To avoid making a very big patch, this change is split in
smaller patches. This one includes drm_a*.c
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/drm_atomic.c| 180 +++--
drivers/gpu/drm/drm_atomic_helper.c | 243 +++-
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_auth.c | 12 +-
4 files changed, 242 insertions(+), 195 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ff1416cd609a..21174efd91be 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -74,7 +74,7 @@ int drm_crtc_commit_wait(struct drm_crtc_commit *commit)
ret = wait_for_completion_timeout(>hw_done, timeout);
if (!ret) {
- DRM_ERROR("hw_done timed out\n");
+ drm_err(commit->crtc->dev, "hw_done timed out\n");
return -ETIMEDOUT;
}
@@ -84,7 +84,7 @@ int drm_crtc_commit_wait(struct drm_crtc_commit *commit)
*/
ret = wait_for_completion_timeout(>flip_done, timeout);
if (!ret) {
- DRM_ERROR("flip_done timed out\n");
+ drm_err(commit->crtc->dev, "flip_done timed out\n");
return -ETIMEDOUT;
}
@@ -140,7 +140,7 @@ drm_atomic_state_init(struct drm_device *dev, struct
drm_atomic_state *state)
state->dev = dev;
- DRM_DEBUG_ATOMIC("Allocated atomic state %p\n", state);
+ drm_dbg_atomic(dev, "Allocated atomic state %p\n", state);
return 0;
fail:
@@ -191,7 +191,7 @@ void drm_atomic_state_default_clear(struct drm_atomic_state
*state)
struct drm_mode_config *config = >mode_config;
int i;
- DRM_DEBUG_ATOMIC("Clearing atomic state %p\n", state);
+ drm_dbg_atomic(dev, "Clearing atomic state %p\n", state);
for (i = 0; i < state->num_connector; i++) {
struct drm_connector *connector = state->connectors[i].ptr;
@@ -301,7 +301,7 @@ void __drm_atomic_state_free(struct kref *ref)
drm_atomic_state_clear(state);
- DRM_DEBUG_ATOMIC("Freeing atomic state %p\n", state);
+ drm_dbg_atomic(state->dev, "Freeing atomic state %p\n", state);
if (config->funcs->atomic_state_free) {
config->funcs->atomic_state_free(state);
@@ -358,8 +358,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
state->crtcs[index].ptr = crtc;
crtc_state->state = state;
- DRM_DEBUG_ATOMIC("Added [CRTC:%d:%s] %p state to %p\n",
-crtc->base.id, crtc->name, crtc_state, state);
+ drm_dbg_atomic(state->dev, "Added [CRTC:%d:%s] %p state to %p\n",
+ crtc->base.id, crtc->name, crtc_state, state);
return crtc_state;
}
@@ -379,8 +379,9 @@ static int drm_atomic_crtc_check(const struct
drm_crtc_state *old_crtc_state,
*/
if (new_crtc_state->active && !new_crtc_state->enable) {
- DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
-crtc->base.id, crtc->name);
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] active without enabled\n",
+ crtc->base.id, crtc->name);
return -EINVAL;
}
@@ -390,15 +391,17 @@ static int drm_atomic_crtc_check(const struct
drm_crtc_state *old_crtc_state,
*/
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(new_crtc_state->enable && !new_crtc_state->mode_blob)) {
- DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
-crtc->base.id, crtc->name);
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] enabled without mode blob\n",
+ crtc->base.id, crtc->name);
return -EINVAL;
}
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(!new_crtc_state->enable && new_crtc_state->mode_blob)) {
- DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n",
-crtc->base.id, crtc->name);
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] disabled with mode blob\n",
+ crtc->base.id, crtc->name);
return -EINVAL;
}
@@ -414,8 +417,9 @@ static int drm_atomic_crtc_check(const struct
drm_crtc_state *old_crtc_state,
*/
if (new_crtc_state->event &&
!new_crtc_state->active && !old_crtc_state->active) {
- DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
-crtc->base.id, crtc->name);
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] requesting
Re: [PATCH 1/6] Documentation/gpu: Reorganize DC documentation
Just a general comment. Could you name the new subdirectory "amdgpu" instead? DC is just a component of the amdgpu driver and I think it would sooner or later make sense to group together the amdgpu documentation in one folder. Regards, Christian. Am 25.11.21 um 16:38 schrieb Rodrigo Siqueira: Display core documentation is not well organized, and it is hard to find information due to the lack of sections. This commit reorganizes the documentation layout, and it is preparation work for future changes. Signed-off-by: Rodrigo Siqueira --- Documentation/gpu/amdgpu-dc.rst | 74 --- .../gpu/amdgpu-dc/amdgpu-dc-debug.rst | 4 + Documentation/gpu/amdgpu-dc/amdgpu-dc.rst | 29 Documentation/gpu/amdgpu-dc/amdgpu-dm.rst | 42 +++ Documentation/gpu/drivers.rst | 2 +- 5 files changed, 76 insertions(+), 75 deletions(-) delete mode 100644 Documentation/gpu/amdgpu-dc.rst create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dc.rst create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dm.rst diff --git a/Documentation/gpu/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc.rst deleted file mode 100644 index f7ff7e1309de.. --- a/Documentation/gpu/amdgpu-dc.rst +++ /dev/null @@ -1,74 +0,0 @@ -=== -drm/amd/display - Display Core (DC) -=== - -*placeholder - general description of supported platforms, what dc is, etc.* - -Because it is partially shared with other operating systems, the Display Core -Driver is divided in two pieces. - -1. **Display Core (DC)** contains the OS-agnostic components. Things like - hardware programming and resource management are handled here. -2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the - amdgpu base driver and DRM are implemented here. - -It doesn't help that the entire package is frequently referred to as DC. But -with the context in mind, it should be clear. - -When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for -supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command line. -Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`. - -To determine if DC is loaded, search dmesg for the following entry: - -``Display Core initialized with `` - -AMDgpu Display Manager -== - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :doc: overview - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h - :internal: - -Lifecycle -- - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :doc: DM Lifecycle - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :functions: dm_hw_init dm_hw_fini - -Interrupts --- - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c - :doc: overview - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c - :internal: - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq - -Atomic Implementation -- - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :doc: atomic - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail - -Display Core - - -**WIP** - -FreeSync Video --- - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :doc: FreeSync Video diff --git a/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst b/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst new file mode 100644 index ..bbb8c3fc8eee --- /dev/null +++ b/Documentation/gpu/amdgpu-dc/amdgpu-dc-debug.rst @@ -0,0 +1,4 @@ +Display Core Debug tools + + +TODO diff --git a/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst new file mode 100644 index ..3685b3b1ad64 --- /dev/null +++ b/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst @@ -0,0 +1,29 @@ +=== +drm/amd/display - Display Core (DC) +=== + +*placeholder - general description of supported platforms, what dc is, etc.* + +Because it is partially shared with other operating systems, the Display Core +Driver is divided in two pieces. + +1. **Display Core (DC)** contains the OS-agnostic components. Things like + hardware programming and resource management are handled here. +2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the + amdgpu base driver and DRM are implemented here. + +It doesn't help that the entire package is frequently referred to as DC. But +with the context in mind, it should be clear. + +When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for +supported ASICs. To
Re: [PATCH 19/26] drm: support more than one write fence in drm_gem_plane_helper_prepare_fb
Am 25.11.21 um 16:47 schrieb Daniel Vetter:
On Tue, Nov 23, 2021 at 03:21:04PM +0100, Christian König wrote:
Use dma_resv_get_singleton() here to eventually get more than one write
fence as single fence.
Yeah this is nice, atomic commit helpers not supporting multiple write
fences was really my main worry in this entire endeavour. Otherwise looks
all rather reasonable.
I'll try to find some review bandwidth, but would be really if you can
volunteer others too (especially making sure ttm drivers set the KERNEL
fences correctly in all cases).
Maybe I should split that up into switching over to adding the enum and
then switching to kernel/bookkeep(previously other) for some use cases.
It would be good if I could get an rb on the trivial driver cleanups
first. I can send those out individually if that helps.
Thanks,
Christian.
-Daniel
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_atomic_helper.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index c3189afe10cb..9338ddb7edff 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -143,25 +143,21 @@
*/
int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct
drm_plane_state *state)
{
- struct dma_resv_iter cursor;
struct drm_gem_object *obj;
struct dma_fence *fence;
+ int ret;
if (!state->fb)
return 0;
obj = drm_gem_fb_get_obj(state->fb, 0);
- dma_resv_iter_begin(, obj->resv, false);
- dma_resv_for_each_fence_unlocked(, fence) {
- /* TODO: Currently there should be only one write fence, so this
-* here works fine. But drm_atomic_set_fence_for_plane() should
-* be changed to be able to handle more fences in general for
-* multiple BOs per fb anyway. */
- dma_fence_get(fence);
- break;
- }
- dma_resv_iter_end();
+ ret = dma_resv_get_singleton(obj->resv, false, );
+ if (ret)
+ return ret;
+ /* TODO: drm_atomic_set_fence_for_plane() should be changed to be able
+* to handle more fences in general for multiple BOs per fb.
+*/
drm_atomic_set_fence_for_plane(state, fence);
return 0;
}
--
2.25.1
Re: [PATCH v6 5/7] drm/mediatek: dpi: Add dpintf support
Il 10/11/21 14:06, Guillaume Ranquet ha scritto: From: Markus Schneider-Pargmann dpintf is the displayport interface hardware unit. This unit is similar to dpi and can reuse most of the code. This patch adds support for mt8195-dpintf to this dpi driver. Main differences are: - Some features/functional components are not available for dpintf which are now excluded from code execution once is_dpintf is set - dpintf can and needs to choose between different clockdividers based on the clockspeed. This is done by choosing a different clock parent. - There are two additional clocks that need to be managed. These are only set for dpintf and will be set to NULL if not supplied. The clk_* calls handle these as normal clocks then. - Some register contents differ slightly between the two components. To work around this I added register bits/masks with a DPINTF_ prefix and use them where different. Based on a separate driver for dpintf created by Jason-JH.Lin . Signed-off-by: Markus Schneider-Pargmann Signed-off-by: Guillaume Ranquet Hello Guillaume, Markus Strictly speaking about functionality, the entire series is totally fine, however, I cannot give you a R-b on patches 6 and 7, since this code should *really* make use of phy_get(), like suggested by Vinod. In any case, for this patch: Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v6 5/7] drm/mediatek: dpi: Add dpintf support
Il 10/11/21 14:06, Guillaume Ranquet ha scritto: From: Markus Schneider-Pargmann dpintf is the displayport interface hardware unit. This unit is similar to dpi and can reuse most of the code. This patch adds support for mt8195-dpintf to this dpi driver. Main differences are: - Some features/functional components are not available for dpintf which are now excluded from code execution once is_dpintf is set - dpintf can and needs to choose between different clockdividers based on the clockspeed. This is done by choosing a different clock parent. - There are two additional clocks that need to be managed. These are only set for dpintf and will be set to NULL if not supplied. The clk_* calls handle these as normal clocks then. - Some register contents differ slightly between the two components. To work around this I added register bits/masks with a DPINTF_ prefix and use them where different. Based on a separate driver for dpintf created by Jason-JH.Lin . Signed-off-by: Markus Schneider-Pargmann Signed-off-by: Guillaume Ranquet Hello Guillaume, Markus Strictly speaking about functionality, the entire series is totally fine, however, I cannot give you a R-b on patches 6 and 7, since this code should *really* make use of phy_get(), like suggested by Vinod. In any case, for this patch: Reviewed-by: AngeloGioacchino Del Regno
[PATCH 1/4] drm: rcar-du: Fix Makefile indentation for DSI
From: Kieran Bingham Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile index adc1b49d02cf..286bc81b3e7c 100644 --- a/drivers/gpu/drm/rcar-du/Makefile +++ b/drivers/gpu/drm/rcar-du/Makefile @@ -19,7 +19,7 @@ obj-$(CONFIG_DRM_RCAR_CMM)+= rcar_cmm.o obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o -obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o +obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o # 'remote-endpoint' is fixed up at run-time DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint -- 2.30.2
[PATCH 4/4] drm: rcar-du: mipi-dsi: Support bridge probe ordering
The bridge probe ordering for DSI devices has been clarified and further
documented in
To support connecting with the SN65DSI86 device after commit c3b75d4734cb
("drm/bridge: sn65dsi86: Register and attach our DSI device at probe"),
update to the new probe ordering to remove a perpetual -EPROBE_DEFER
loop between the two devices.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 48 +
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
index 833f4480bdf3..f783bacee8da 100644
--- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
@@ -639,6 +639,8 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
+ struct drm_panel *panel;
+ int ret;
if (device->lanes > dsi->num_data_lanes)
return -EINVAL;
@@ -646,12 +648,36 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->lanes = device->lanes;
dsi->format = device->format;
+ ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
+ >next_bridge);
+ if (ret) {
+ dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
+ return ret;
+ }
+
+ if (!dsi->next_bridge) {
+ dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
+ if (IS_ERR(dsi->next_bridge)) {
+ dev_err(dsi->dev, "failed to create panel bridge\n");
+ return PTR_ERR(dsi->next_bridge);
+ }
+ }
+
+ /* Initialize the DRM bridge. */
+ dsi->bridge.funcs = _mipi_dsi_bridge_ops;
+ dsi->bridge.of_node = dsi->dev->of_node;
+ drm_bridge_add(>bridge);
+
return 0;
}
static int rcar_mipi_dsi_host_detach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
+ struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
+
+ drm_bridge_remove(>bridge);
+
return 0;
}
@@ -766,21 +792,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
*pdev)
return PTR_ERR(dsi->rstc);
}
- ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
- >next_bridge);
- if (ret) {
- dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
- return ret;
- }
-
- if (!dsi->next_bridge) {
- dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
- if (IS_ERR(dsi->next_bridge)) {
- dev_err(dsi->dev, "failed to create panel bridge\n");
- return PTR_ERR(dsi->next_bridge);
- }
- }
-
/* Initialize the DSI host. */
dsi->host.dev = dsi->dev;
dsi->host.ops = _mipi_dsi_host_ops;
@@ -788,11 +799,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
*pdev)
if (ret < 0)
return ret;
- /* Initialize the DRM bridge. */
- dsi->bridge.funcs = _mipi_dsi_bridge_ops;
- dsi->bridge.of_node = dsi->dev->of_node;
- drm_bridge_add(>bridge);
-
return 0;
}
@@ -800,8 +806,6 @@ static int rcar_mipi_dsi_remove(struct platform_device
*pdev)
{
struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
- drm_bridge_remove(>bridge);
-
mipi_dsi_host_unregister(>host);
return 0;
--
2.30.2
[PATCH 3/4] drm: rcar-du: mipi-dsi: Ensure correct fout is reported
The debug reporting for the clock calculations was erroneously reporting
the last calculation of fout, rather than the fout that was determined
to have the least error, and therefore be the values chosen to operate
with.
Fix the reporting to show the correct output by storing the determined
fout, along with the error value.
Signed-off-by: Kieran Bingham
---
I spent /way/ too long confused why my clock values didn't make sense
before I noticed this.. :-(
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
index e94245029f95..833f4480bdf3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
@@ -168,6 +168,7 @@ static int rcar_mipi_dsi_phtw_test(struct rcar_mipi_dsi
*dsi, u32 phtw)
*/
struct dsi_setup_info {
+ unsigned long fout;
unsigned int err;
u16 vco_cntrl;
u16 prop_cntrl;
@@ -247,6 +248,7 @@ static void rcar_mipi_dsi_parameters_calc(struct
rcar_mipi_dsi *dsi,
setup_info->m = m - 2;
setup_info->n = n - 1;
setup_info->err = err;
+ setup_info->fout = fout;
if (err == 0)
goto done;
}
@@ -256,7 +258,7 @@ static void rcar_mipi_dsi_parameters_calc(struct
rcar_mipi_dsi *dsi,
done:
dev_dbg(dsi->dev,
"%pC %lu Hz -> Fout %lu Hz (target %lu Hz, error %d.%02u%%),
PLL M/N/DIV %u/%u/%u\n",
- clk, fin, fout, fout_target, setup_info->err / 100,
+ clk, fin, setup_info->fout, fout_target, setup_info->err / 100,
setup_info->err % 100, setup_info->m,
setup_info->n, setup_info->div);
dev_dbg(dsi->dev,
--
2.30.2
[PATCH 2/4] drm: rcar-du: Select DRM_MIPI_DSI with DRM_RCAR_MIPI_DSI
The RCAR_MIPI_DSI uses the DRM_MIPI_DSI interface. Ensure that it is selected when the option is enabled. Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index 8cb94fe90639..8145c6d4cbc8 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -41,6 +41,7 @@ config DRM_RCAR_LVDS config DRM_RCAR_MIPI_DSI tristate "R-Car DU MIPI DSI Encoder Support" depends on DRM && DRM_BRIDGE && OF + select DRM_MIPI_DSI help Enable support for the R-Car Display Unit embedded MIPI DSI encoders. -- 2.30.2
[PATCH 0/4] drm: rcar-du: mipi-dsi: Cleanup and Fixes
These patches are against the as-yet-unmerged posting from Laurent of "drm: rcar-du: Add R-Car DSI driver" from [0] [0] https://lore.kernel.org/all/20210623135639.17125-1-laurent.pinchart+rene...@ideasonboard.com/ Notably, the comments blocking the integration of the series on the handling of bridge probe ordering have hopefully been solved by 4/4 here. This has been validated and is working on the Falcon-V3U with an SN65DSI86 on a merge of the latest drm/drm-next and drm-misc/drm-misc-next. Other updates to the SN65DSI86 were also used to support the bridge connecting to non-eDP, and have previously been posted by Laurent [1]. I've made no specific changes to those, so I'll refrain from reposting them. [1] https://lore.kernel.org/all/20210322030128.2283-1-laurent.pinchart+rene...@ideasonboard.com/ Kieran Bingham (4): drm: rcar-du: Fix Makefile indentation for DSI drm: rcar-du: Select DRM_MIPI_DSI with DRM_RCAR_MIPI_DSI drm: rcar-du: mipi-dsi: Ensure correct fout is reported drm: rcar-du: mipi-dsi: Support bridge probe ordering drivers/gpu/drm/rcar-du/Kconfig | 1 + drivers/gpu/drm/rcar-du/Makefile| 2 +- drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 52 ++--- 3 files changed, 31 insertions(+), 24 deletions(-) -- 2.30.2
Re: [RFC 08/13] soc: mediatek: apu: Add apusys rv driver
Il 26/11/21 10:25, Flora.Fu ha scritto:
On Tue, 2021-10-26 at 17:21 +0200, AngeloGioacchino Del Regno wrote:
Il 23/10/21 13:14, Flora Fu ha scritto:
Add driver for control APU tinysys
APU integrated subsystem having MD32RV33 (MD32) that runs tinysys
The tinsys is running on a micro processor in APU.
Its firmware is load and boot from Kernel side. Kernel and tinysys
use
IPI to tx/rx messages.
Signed-off-by: Flora Fu
---
drivers/soc/mediatek/apusys/Makefile| 6 +
drivers/soc/mediatek/apusys/apu-config.h| 100 +++
drivers/soc/mediatek/apusys/apu-core.c | 2 +
drivers/soc/mediatek/apusys/apu-core.h | 2 +
drivers/soc/mediatek/apusys/apu-ipi.c | 486
I'm not sure of that, but your apu-ipi.c may be more suited to be in
drivers/remoteproc instead.
drivers/soc/mediatek/apusys/apu-mbox.c | 83 ++
apu-mbox.c should go to drivers/mailbox/ and you should register it
with
the mailbox API as a mailbox controller instead of what you're
currently
doing...
From what I see, you have functions in there that can be indeed
mapped
to struct mbox_chan_ops .send_data and .peek_data... also your
function
apu_mbox_wait_inbox seems to be waiting on an interrupt, and such irq
is
apparently your "mbox0_irq" (as you named it in the dt).
In that case, you can also manage that in your drivers/mailbox/
driver.
+
drivers/soc/mediatek/apusys/apu-mbox.h | 27 +
drivers/soc/mediatek/apusys/apu-rproc.c | 806
The apu-rproc.c driver seems to be a good candidate to be moved away
from
drivers/soc/mediatek/apusys/ - as this is indeed a remoteproc driver.
Having it as drivers/remoteproc/mtk_apu.c seems to be a good option.
For mbox/ipi/apu-rproc, we will check the kernel framework and make
more fix on it.
drivers/soc/mediatek/apusys/apu-sw-logger.c | 429 +++
This one definitely belongs here in drivers/soc/mediatek, and it's a
consumer
of the mailbox driver.
drivers/soc/mediatek/apusys/apu.h | 256 +++
drivers/soc/mediatek/apusys/mt81xx-plat.c | 320
If we end up keeping to be in need to have a separate mt81xx-plat.c
file,
then I believe this should have another name, so that it becomes one
that
aggregates all of the very-platform-specific functions in one,
instead of
having one file for each platform.
Though, it may also be possible that this file will disappear
entirely:
since most of the things here will be moved around, it may become
mostly
empty... but it's probably too soon to judge.
The mt81xx-platform.c is prepared for the similiar apu desing platforms
but some of them will have differnt operations in the functions. I will
just keep it and we can reivew it again in the feature versions.
11 files changed, 2517 insertions(+)
create mode 100644 drivers/soc/mediatek/apusys/apu-config.h
create mode 100644 drivers/soc/mediatek/apusys/apu-ipi.c
create mode 100644 drivers/soc/mediatek/apusys/apu-mbox.c
create mode 100644 drivers/soc/mediatek/apusys/apu-mbox.h
create mode 100644 drivers/soc/mediatek/apusys/apu-rproc.c
create mode 100644 drivers/soc/mediatek/apusys/apu-sw-logger.c
create mode 100644 drivers/soc/mediatek/apusys/apu.h
create mode 100644 drivers/soc/mediatek/apusys/mt81xx-plat.c
snip...
diff --git a/drivers/soc/mediatek/apusys/apu-ipi.c
b/drivers/soc/mediatek/apusys/apu-ipi.c
new file mode 100644
index ..547e034b3620
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/apu-ipi.c
snip...
+int apu_ipi_init(struct platform_device *pdev, struct mtk_apu
*apu)
+{
+ struct device *dev = apu->dev;
+ int i, ret;
+
+ tx_serial_no = 0;
+ rx_serial_no = 0;
+
+ mutex_init(>send_lock);
+ spin_lock_init(>usage_cnt_lock);
+ for (i = 0; i < APU_IPI_MAX; i++) {
+ mutex_init(>ipi_desc[i].lock);
+ lockdep_set_class_and_name(>ipi_desc[i].lock,
+ _lock_key[i],
+ apu->platdata-
ipi_attrs[i].name);
+ }
+
+ init_waitqueue_head(>run.wq);
+ init_waitqueue_head(>ack_wq);
+
+ /* APU initialization IPI register */
+ ret = apu_ipi_register(apu, APU_IPI_INIT, apu_init_ipi_handler,
apu);
+ if (ret) {
+ dev_err(dev, "failed to register ipi for init,
ret=%d\n",
+ ret);
+ return ret;
+ }
+
+ /* add rpmsg subdev */
+ apu_add_rpmsg_subdev(apu);
+
+ /* register mailbox IRQ */
+ apu->mbox0_irq_number = platform_get_irq_byname(pdev,
"mbox0_irq");
+ dev_info(>dev, "%s: mbox0_irq = %d\n", __func__,
+apu->mbox0_irq_number);
+
+ ret = devm_request_threaded_irq(>dev, apu-
mbox0_irq_number,
+ NULL, apu_ipi_handler,
IRQF_ONESHOT,
+ "apu_ipi", apu);
This is the mailbox interrupt... but it's
Re: [PATCH v4] dma-buf: system_heap: Use 'for_each_sgtable_sg' in pages free flow
Am 26.11.21 um 08:49 schrieb guangming@mediatek.com:
From: Guangming
For previous version, it uses 'sg_table.nent's to traverse sg_table in pages
free flow.
However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the number of
created entries in the DMA adderess space.
So, use 'sg_table.nents' in pages free flow will case some pages can't be freed.
Here we should use sg_table.orig_nents to free pages memory, but use the
sgtable helper 'for each_sgtable_sg'(, instead of the previous rather common
helper 'for_each_sg' which maybe cause memory leak) is much better.
Fixes: d963ab0f15fb0 ("dma-buf: system_heap: Allocate higher order pages if
available")
Signed-off-by: Guangming
Reviewed-by: Robin Murphy
Reviewed-by: Christian König
Cc: # 5.11.*
---
v4: Correct commit message
1. Cc sta...@vger.kernel.org in commit message and add required kernel
version.
2. Add reviewed-by since patch V2 and V4 are same and V2 is reviewed by
Robin.
3. There is no new code change in V4.
V3: Cc sta...@vger.kernel.org
1. This patch needs to be merged stable branch, add sta...@vger.kernel.org
in mail list.
2. Correct some spelling mistake.
3. There is No new code change in V3.
V2: use 'for_each_sgtable_sg' to 'replece for_each_sg' as suggested by Robin.
---
drivers/dma-buf/heaps/system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 23a7e74ef966..8660508f3684 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -289,7 +289,7 @@ static void system_heap_dma_buf_release(struct dma_buf
*dmabuf)
int i;
table = >sg_table;
- for_each_sg(table->sgl, sg, table->nents, i) {
+ for_each_sgtable_sg(table, sg, i) {
struct page *page = sg_page(sg);
__free_pages(page, compound_order(page));
[PATCH] drm: rcar-du: crtc: Support external DSI dot clock
On platforms with an external clock, both the group and crtc must be
handled accordingly to correctly pass through the external clock and
configure the DU to use the external rate.
The CRTC support was missed while adding the DSI support on the r8a779a0
which led to the output clocks being incorrectly determined.
Ensure that when a CRTC is routed through the DSI encoder, the external
clock is used without any further divider being applied.
Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 5672830ca184..5236f917cc68 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -261,12 +261,13 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
rcar_du_group_write(rcrtc->group, DPLLCR, dpllcr);
escr = ESCR_DCLKSEL_DCLKIN | div;
- } else if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index)) {
+ } else if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index) ||
+ rcdu->info->dsi_clk_mask & BIT(rcrtc->index)) {
/*
-* Use the LVDS PLL output as the dot clock when outputting to
-* the LVDS encoder on an SoC that supports this clock routing
-* option. We use the clock directly in that case, without any
-* additional divider.
+* Use the external LVDS or DSI PLL output as the dot clock when
+* outputting to the LVDS or DSI encoder on an SoC that supports
+* this clock routing option. We use the clock directly in that
+* case, without any additional divider.
*/
escr = ESCR_DCLKSEL_DCLKIN;
} else {
--
2.30.2
Re: [RFC 06/13] soc: mediatek: apu: Add apu core driver
On Sat, 2021-10-23 at 08:49 -0700, Randy Dunlap wrote: > Hi, > > On 10/23/21 4:14 AM, Flora Fu wrote: > > diff --git a/drivers/soc/mediatek/Kconfig > > b/drivers/soc/mediatek/Kconfig > > index d9bac2710494..074b0cf24c44 100644 > > --- a/drivers/soc/mediatek/Kconfig > > +++ b/drivers/soc/mediatek/Kconfig > > @@ -24,6 +24,24 @@ config MTK_APU_PM > > APU power domain shall be enabled before accessing the > > internal sub modules. > > > > +config MTK_APU > > + tristate "MediaTek APUSYS Support" > > + select REGMAP > > + select MTK_APU_PM > > + select MTK_SCP > > + help > > + Say yes here to add support for the APU tinysys. The tinsys > > is > > tinysys > runs on > > > + running on a micro processor in APU. > > a microprocessor in the APU. > > > + Its firmware is load and boot from Kernel side. Kernel and > > tinysys use > > is loaded and booted > > > + IPI to tx/rx messages. > > to send/receive messages. Ack. > > + > > +config MTK_APU_DEBUG > > + tristate "MediaTek APUSYS debug functions" > > + depends on MTK_APU > > + help > > + Say yes here to enalbe debug on APUSYS. > > enable Ack. The tpyo will be fix in the next submission. Thanks for your review. > > > + Disable it if you don't need them. > >
Re: [PATCH] drm/msm: Initialize MDSS irq domain at probe time
Il 26/11/21 01:06, Dmitry Baryshkov ha scritto:
On 25/11/2021 18:09, AngeloGioacchino Del Regno wrote:
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
DSI host gets initialized earlier, but this caused unability to probe
the entire stack of components because they all depend on interrupts
coming from the main `mdss` node (mdp5, or dpu1).
To fix this issue, also anticipate probing mdp5 or dpu1 by initializing
them at msm_pdev_probe() time: this will make sure that we add the
required interrupt controller mapping before dsi and/or other components
try to initialize, finally satisfying the dependency.
While at it, also change the allocation of msm_drm_private to use the
devm variant of kzalloc().
Fixes: 8f59ee9a570c ("drm/msm/dsi: Adjust probe order")
Signed-off-by: AngeloGioacchino Del Regno
Another issue (or a pack of issues):
Now the msm_drm_init() is unbalanced with msm_drm_uninit(). Bits of code (putting
the drm dev, removing the IRQ domain, etc) have to be called now from the
msm_pdev_remove() function rather than from the unbind path.
The following changes fix the observed issues here, however additional care should
be taken.
Hello Dmitry,
thanks for the thorough review (and solutions!).
Are you going to push your changes on top, or should I send a V2?
Cheers,
- Angelo
Re: [RFC 08/13] soc: mediatek: apu: Add apusys rv driver
On Tue, 2021-10-26 at 17:21 +0200, AngeloGioacchino Del Regno wrote:
> Il 23/10/21 13:14, Flora Fu ha scritto:
> > Add driver for control APU tinysys
> >
> > APU integrated subsystem having MD32RV33 (MD32) that runs tinysys
> > The tinsys is running on a micro processor in APU.
> > Its firmware is load and boot from Kernel side. Kernel and tinysys
> > use
> > IPI to tx/rx messages.
> >
> > Signed-off-by: Flora Fu
> > ---
> > drivers/soc/mediatek/apusys/Makefile| 6 +
> > drivers/soc/mediatek/apusys/apu-config.h| 100 +++
> > drivers/soc/mediatek/apusys/apu-core.c | 2 +
> > drivers/soc/mediatek/apusys/apu-core.h | 2 +
> > drivers/soc/mediatek/apusys/apu-ipi.c | 486
>
> I'm not sure of that, but your apu-ipi.c may be more suited to be in
> drivers/remoteproc instead.
>
> > drivers/soc/mediatek/apusys/apu-mbox.c | 83 ++
>
> apu-mbox.c should go to drivers/mailbox/ and you should register it
> with
> the mailbox API as a mailbox controller instead of what you're
> currently
> doing...
>
> From what I see, you have functions in there that can be indeed
> mapped
> to struct mbox_chan_ops .send_data and .peek_data... also your
> function
> apu_mbox_wait_inbox seems to be waiting on an interrupt, and such irq
> is
> apparently your "mbox0_irq" (as you named it in the dt).
> In that case, you can also manage that in your drivers/mailbox/
> driver.
> +
> > drivers/soc/mediatek/apusys/apu-mbox.h | 27 +
> > drivers/soc/mediatek/apusys/apu-rproc.c | 806
> >
>
> The apu-rproc.c driver seems to be a good candidate to be moved away
> from
>
> drivers/soc/mediatek/apusys/ - as this is indeed a remoteproc driver.
>
> Having it as drivers/remoteproc/mtk_apu.c seems to be a good option.
>
For mbox/ipi/apu-rproc, we will check the kernel framework and make
more fix on it.
>
> > drivers/soc/mediatek/apusys/apu-sw-logger.c | 429 +++
>
> This one definitely belongs here in drivers/soc/mediatek, and it's a
> consumer
> of the mailbox driver.
>
> > drivers/soc/mediatek/apusys/apu.h | 256 +++
> > drivers/soc/mediatek/apusys/mt81xx-plat.c | 320
>
> If we end up keeping to be in need to have a separate mt81xx-plat.c
> file,
> then I believe this should have another name, so that it becomes one
> that
> aggregates all of the very-platform-specific functions in one,
> instead of
> having one file for each platform.
>
> Though, it may also be possible that this file will disappear
> entirely:
> since most of the things here will be moved around, it may become
> mostly
> empty... but it's probably too soon to judge.
The mt81xx-platform.c is prepared for the similiar apu desing platforms
but some of them will have differnt operations in the functions. I will
just keep it and we can reivew it again in the feature versions.
>
> > 11 files changed, 2517 insertions(+)
> > create mode 100644 drivers/soc/mediatek/apusys/apu-config.h
> > create mode 100644 drivers/soc/mediatek/apusys/apu-ipi.c
> > create mode 100644 drivers/soc/mediatek/apusys/apu-mbox.c
> > create mode 100644 drivers/soc/mediatek/apusys/apu-mbox.h
> > create mode 100644 drivers/soc/mediatek/apusys/apu-rproc.c
> > create mode 100644 drivers/soc/mediatek/apusys/apu-sw-logger.c
> > create mode 100644 drivers/soc/mediatek/apusys/apu.h
> > create mode 100644 drivers/soc/mediatek/apusys/mt81xx-plat.c
> >
>
> snip...
>
> > diff --git a/drivers/soc/mediatek/apusys/apu-ipi.c
> > b/drivers/soc/mediatek/apusys/apu-ipi.c
> > new file mode 100644
> > index ..547e034b3620
> > --- /dev/null
> > +++ b/drivers/soc/mediatek/apusys/apu-ipi.c
>
> snip...
>
> > +int apu_ipi_init(struct platform_device *pdev, struct mtk_apu
> > *apu)
> > +{
> > + struct device *dev = apu->dev;
> > + int i, ret;
> > +
> > + tx_serial_no = 0;
> > + rx_serial_no = 0;
> > +
> > + mutex_init(>send_lock);
> > + spin_lock_init(>usage_cnt_lock);
> > + for (i = 0; i < APU_IPI_MAX; i++) {
> > + mutex_init(>ipi_desc[i].lock);
> > + lockdep_set_class_and_name(>ipi_desc[i].lock,
> > + _lock_key[i],
> > + apu->platdata-
> > >ipi_attrs[i].name);
> > + }
> > +
> > + init_waitqueue_head(>run.wq);
> > + init_waitqueue_head(>ack_wq);
> > +
> > + /* APU initialization IPI register */
> > + ret = apu_ipi_register(apu, APU_IPI_INIT, apu_init_ipi_handler,
> > apu);
> > + if (ret) {
> > + dev_err(dev, "failed to register ipi for init,
> > ret=%d\n",
> > + ret);
> > + return ret;
> > + }
> > +
> > + /* add rpmsg subdev */
> > + apu_add_rpmsg_subdev(apu);
> > +
> > + /* register mailbox IRQ */
> > + apu->mbox0_irq_number = platform_get_irq_byname(pdev,
> > "mbox0_irq");
> > + dev_info(>dev, "%s: mbox0_irq = %d\n", __func__,
> > +apu->mbox0_irq_number);
> > +
> > + ret =
Re: [RFC 12/13] arm64: dts: mt8192: Add apu tinysys
On Tue, 2021-10-26 at 17:18 +0200, AngeloGioacchino Del Regno wrote:
> Il 23/10/21 13:14, Flora Fu ha scritto:
> > Add node for APU tinysys.
> >
> > Signed-off-by: Flora Fu
> > ---
> > arch/arm64/boot/dts/mediatek/mt8192.dtsi | 36
> >
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> > index c505c6926839..8108084a3f6f 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> > @@ -925,6 +925,42 @@
> > #iommu-cells = <1>;
> > };
> >
> > + apusys_rv@19001000 {
> > + compatible = "mediatek,mt8192-apusys-rv";
> > + reg = <0 0x1900 0 0x1000>,
> > + <0 0x19001000 0 0x1000>,
> > + <0 0x19002000 0 0x10>;
> > + reg-names = "apu_mbox",
> > + "md32_sysctrl",
> > + "apu_wdt";
> > + mediatek,apusys-power = <_power>;
>
> As said on the IOMMU commit, I think that apusys-power can be passed
> as a
> power domain here as well... also keeping in mind that the apuspm
> power
> domain is being used in both the IOMMU and in apusys-power already,
> so you
> could even pass only the apusys-power pd here, because apuspm would
> be
> already being turned on by the former...
>
> ...unless there's any possibility to have some functionality with
> apuspm up
> but apusys-power down? From how it looks right now, that's not a
> thing.
>
OK, we will check it.
> > + power-domains = < 0>;
> > + iommus = <_apu IOMMU_PORT_APU_DATA>;
> > + interrupts = > 0>,
> > + > 0>;
> > + interrupt-names = "apu_wdt",
> > + "mbox0_irq";
> > + apu_ctrl {
> > + compatible = "mediatek,apu-ctrl-rpmsg";
> > + mtk,rpmsg-name = "apu-ctrl-rpmsg";
>
> This is supposed to be "mediatek,rpmsg-name" instead... or it won't
> work.
>
The latest kernel uses "mediatek,rpmsg-name" and I will update the
string in the next submission.
> > + };
> > +
> > + apu_pwr_tx {
> > + compatible = "mediatek,apupwr-tx-
> > rpmsg";
> > + mtk,rpmsg-name = "apupwr-tx-rpmsg";
> > + };
> > +
> > + apu_pwr_rx {
> > + compatible = "mediatek,apupwr-rx-
> > rpmsg";
> > + mtk,rpmsg-name = "apupwr-rx-rpmsg";
> > + };
> > +
> > + apu_mdw_rpmsg {
> > + compatible = "mediatek,apu-mdw-rpmsg";
> > + mtk,rpmsg-name = "apu-mdw-rpmsg";
> > + };
> > + };
> > +
> > apu_conn: apu_conn@1902 {
> > compatible = "mediatek,mt8192-apu-conn",
> > "syscon";
> > reg = <0 0x1902 0 0x1000>;
> >
Re: [RFC 04/13] iommu/mediatek: Add APU iommu support
On Tue, 2021-10-26 at 17:17 +0200, AngeloGioacchino Del Regno wrote:
> Il 23/10/21 13:14, Flora Fu ha scritto:
> > APU IOMMU is a new iommu HW. it use a new pagetable.
> > Add support for mt8192 apu iommu.
> >
> > Signed-off-by: Yong Wu
> > Signed-off-by: Flora Fu
> > ---
> > drivers/iommu/mtk_iommu.c | 57
> > +++
> > include/dt-bindings/memory/mt8192-larb-port.h | 4 ++
> > 2 files changed, 61 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 90be8ebbc98a..a5f8f19e053a 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -133,6 +133,7 @@
> > /* 2 bits: iommu type */
> > #define MTK_IOMMU_TYPE_MM (0x0 << 13)
> > #define MTK_IOMMU_TYPE_INFRA (0x1 << 13)
> > +#define MTK_IOMMU_TYPE_APU (0x2 << 13)
> > #define MTK_IOMMU_TYPE_MASK (0x3 << 13)
> > #define IFA_IOMMU_PCIe_SUPPORTBIT(15)
> >
> > @@ -185,6 +186,7 @@ static int mtk_iommu_hw_init(const struct
> > mtk_iommu_data *data, unsigned int ban
> > #define MTK_IOMMU_4GB_MODE_REMAP_BASE 0x14000UL
> >
> > static LIST_HEAD(m4ulist);/* List all the M4U HWs */
> > +static LIST_HEAD(apulist); /* List the apu iommu HWs */
> >
> > #define for_each_m4u(data, head) list_for_each_entry(data, head,
> > list)
> >
> > @@ -209,6 +211,13 @@ static const struct mtk_iommu_iova_region
> > mt8192_multi_dom[] = {
> > #endif
> > };
> >
> > +static const struct mtk_iommu_iova_region mt8192_multi_dom_apu[] =
> > {
> > + { .iova_base = 0x0, .size = SZ_4G}, /* APU DATA */
> > + { .iova_base = 0x400ULL,.size = 0x400}, /* APU
> > VLM */
> > + { .iova_base = 0x1000ULL, .size = 0x1000}, /* APU
> > VPU */
> > + { .iova_base = 0x7000ULL, .size = 0x1260}, /* APU
> > REG */
> > +};
> > +
> > /* If 2 M4U share a domain(use the same hwlist), Put the
> > corresponding info in first data.*/
> > static struct mtk_iommu_data *mtk_iommu_get_frst_data(struct
> > list_head *hwlist)
> > {
> > @@ -923,6 +932,37 @@ static int mtk_iommu_mm_dts_parse(struct
> > device *dev,
> > return 0;
> > }
> >
> > +static int mtk_iommu_apu_prepare(struct device *dev)
> > +{
> > + struct device_node *apupower_node;
> > + struct platform_device *apudev;
> > + struct device_link *link;
> > +
> > + apupower_node = of_find_compatible_node(NULL, NULL,
> > "mediatek,apusys-power");
>
> Is it expected to have PM ops in the apusys-power driver? Currently,
> I can't see
> any, but maybe it's because of how complex is this entire
> implementation.
>
> In any case, the name suggests that this controls power for the
> entire APU... so
> it would be more appropriate if apusys-power would expose a power
> domain (since it
> also has some sort of OPP, from what I can see), in which case you
> wouldn't be
> retrieving it here like you're doing right now... but simply as a
> power domain,
> simplifying the entire handling of that in here.
>
>
Hi, Angelo, Thanks for your comments.
In the design, we do use the power domain to enable the power for iommu
and reset drivers.
In the APU hardware, it requires sharing all pages if it has more than
one iommu in APU hardware. In current iommu driver, it can only wakeup
one iommu device so we add the apusys-power as a wrapper to make all
iommu resume/suspend at the same time. That's why you can also see
another devices drivers, apusys_rv also links to apusys-power to comply
with the flow.
Thanks for your comments. We will check your comments and try to
optimze the wrapper device link.
> > + if (!apupower_node) {
> > + dev_warn(dev, "Can't find apu power node!\n");
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_device_is_available(apupower_node)) {
> > + of_node_put(apupower_node);
> > + return -EPERM;
> > + }
> > +
> > + apudev = of_find_device_by_node(apupower_node);
> > + if (!apudev) {
> > + of_node_put(apupower_node);
> > + return -EPROBE_DEFER;
> > + }
> > +
> > + link = device_link_add(>dev, dev, DL_FLAG_PM_RUNTIME);
> > + if (!link)
> > + dev_err(dev, "Unable link %s.\n", apudev->name);
> > +
> > + of_node_put(apupower_node);
> > + return 0;
> > +}
> > +
> > static int mtk_iommu_probe(struct platform_device *pdev)
> > {
> > struct mtk_iommu_data *data;
> > @@ -1021,6 +1061,10 @@ static int mtk_iommu_probe(struct
> > platform_device *pdev)
> > }
> >
> > data->pericfg = infracfg;
> > + } else if (MTK_IOMMU_IS_TYPE(data->plat_data,
> > MTK_IOMMU_TYPE_APU)) {
> > + ret = mtk_iommu_apu_prepare(dev);
> > + if (ret)
> > + goto out_runtime_disable;
> > }
> >
> > platform_set_drvdata(pdev, data);
> > @@ -1268,6 +1312,18 @@ static const struct mtk_iommu_plat_data
> > mt8192_data = {
> >
Re: [PATCH] drm/i915: Use per device iommu check
On 2021/11/25 19:47, Robin Murphy wrote: On 2021-11-25 10:42, Tvrtko Ursulin wrote: From: Tvrtko Ursulin With both integrated and discrete Intel GPUs in a system, the current global check of intel_iommu_gfx_mapped, as done from intel_vtd_active() may not be completely accurate. In this patch we add i915 parameter to intel_vtd_active() in order to prepare it for multiple GPUs and we also change the check away from Intel specific intel_iommu_gfx_mapped (global exported by the Intel IOMMU driver) to probing the presence of IOMMU domain on a specific device using iommu_get_domain_for_dev(). FWIW the way you have it now is functionally equivalent to using device_iommu_mapped(), which I think might be slightly clearer for the current intent, but I don't have a significantly strong preference (after all, this *was* the de-facto way of checking before device_iommu_mapped() was introduced, and there are still other examples of it around). So from the IOMMU perspective, Acked-by: Robin Murphy Perhaps the AGP driver could also be tweaked and intel_iommu_gfx_mapped cleaned away entirely, but I'll leave that for Baolu to think about :) I fully agreed with Robin. I prefer device_iommu_mapped() more than iommu_get_domain_for_dev(). "iommu_get_domain_for_dev(dev) == NULL" simply means that the device does not have any domain attached. Although at present, it is equivalent to device DMAing without IOMMU translation. But I'm sure it will change in the future. With device_iommu_mapped() replaced, Reviewed-by: Lu Baolu Best regards, baolu
Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
On Thu, 25 Nov 2021 20:43:19 + "Shankar, Uma" wrote: > > -Original Message- > > From: Harry Wentland > > Sent: Tuesday, November 23, 2021 8:35 PM > > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > > dri- > > de...@lists.freedesktop.org > > Cc: ville.syrj...@linux.intel.com; ppaala...@gmail.com; > > brian.star...@arm.com; > > sebast...@sebastianwick.net; shashank.sha...@amd.com > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline > > > > > > > > On 2021-09-06 17:38, Uma Shankar wrote: > > > This is a RFC proposal for plane color hardware blocks. > > > It exposes the property interface to userspace and calls out the > > > details or interfaces created and the intended purpose. > > > > > > Credits: Ville Syrjälä > > > Signed-off-by: Uma Shankar > > > --- > > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167 > > > +++ > > > 1 file changed, 167 insertions(+) > > > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst > > > > > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst > > > b/Documentation/gpu/rfc/drm_color_pipeline.rst > > > new file mode 100644 > > > index ..0d1ca858783b > > > --- /dev/null > > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst > > > @@ -0,0 +1,167 @@ > > > +== > > > +Display Color Pipeline: Proposed DRM Properties > > > +== > > > + > > > +This is how a typical display color hardware pipeline looks like: > > > + +---+ > > > + |RAM| > > > + | +--++-++-+ | > > > + | | FB 1 || FB 2 || FB N| | > > > + | +--++-++-+ | > > > + +---+ > > > + | Plane Color Hardware Block | > > > + ++ > > > + | +---v-+ +---v---+ +---v--+ | > > > + | | Plane A | | Plane B | | Plane N | | > > > + | | DeGamma | | Degamma | | Degamma | | > > > + | +---+-+ +---+---+ +---+--+ | > > > + | | | || > > > + | +---v-+ +---v---+ +---v--+ | > > > + | |Plane A | | Plane B | | Plane N | | > > > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > > + | +---+-+ ++--+ ++-+ | > > > + | | | | | > > > + | +---v-+ +v--+ +v-+ | > > > + | | Plane A | | Plane B | | Plane N | | > > > + | | Gamma | | Gamma | | Gamma| | > > > + | +---+-+ ++--+ ++-+ | > > > + | | | | | > > > + ++ > > > ++--v--v---v---| > > > +|| || > > > +|| Pipe Blender|| > > > ++++ > > > +||| > > > +|+---v--+ | > > > +|| Pipe DeGamma| | > > > +|| | | > > > +|+---+--+ | > > > +||Pipe Color | > > > +|+---v--+ Hardware| > > > +|| Pipe CSC/CTM| | > > > +|| | | > > > +|+---+--+ | > > > +||| > > > +|+---v--+ | > > > +|| Pipe Gamma | | > > > +|| | | > > > +|+---+--+ | > > > +||| > > > ++-+ > > > + | > > > + v > > > + Pipe Output > > > + > > > > This diagram defines what happens before and after the blending space but > > did > > where does scaling fit into it? Scaling can look different when performed > > in linear or > > non-linear space so I think it is important to define where in the pipeline > > it sits. > > > > In my view scaling would happen between plane degamma and plane CSC. > > Yeah we can add scaling as well to make it clear. Scaling ideally should > happen after > Degamma. In intel's case it is after the CSC. Btw. are you aware that if a plane has an alpha channel which is used for pixel coverage (i.e. shape anti-aliasing), then non-nearest sampling and therefore also scaling must operate on alpha pre-multiplied optical (linear) values? For the best results, of course. So after degamma indeed, but you cannot degamma with pre-multiplied alpha, yet scaling should use
Re: [PATCH 08/12] arm64: dts: rockchip: rk356x: Add VOP2 nodes
Am Freitag, 26. November 2021, 08:40:21 CET schrieb Sascha Hauer:
> On Thu, Nov 25, 2021 at 09:25:28PM +0100, Johan Jonker wrote:
> > Hi Sascha,
> >
> >
> > On 11/17/21 3:33 PM, Sascha Hauer wrote:
> > > The VOP2 is the display output controller on the RK3568. Add the node
> > > for it to the dtsi file along with the required display-subsystem node
> > > and the iommu node.
> > >
> > > Signed-off-by: Sascha Hauer
> > > ---
> > > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 52
> > > 1 file changed, 52 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > > b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > > index 46d9552f60284..6ebf7c14e096a 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > > @@ -447,6 +447,58 @@ gmac1_mtl_tx_setup: tx-queues-config {
> > > };
> > > };
> > >
> >
> > > + display_subsystem: display-subsystem {
> > > + compatible = "rockchip,display-subsystem";
> > > + ports = <_out>;
> > > + };
> >
> > Some DT sort rules:
> >
> > For nodes:
> > Sort things without reg alphabetical first,
> > then sort the rest by reg address.
> >
> > > +
> > > + vop: vop@fe04 {
> >
> > > + compatible = "rockchip,rk3568-vop";
> >
> > From rockchip-vop2.yaml:
> > +properties:
> > + compatible:
> > +enum:
> >
> > + - rockchip,rk3568-vop
> > + - rockchip,rk3566-vop
> >
> > Maybe sort yaml compatibles in alphabetical order.
> >
> > rockchip,rk3566-vop is not used in the dtsi I think.
> >
> > Comment by Andy Yan:
> > >
> > > But take care that the vop on rk3566 has a special limitation: there are
> > > three
> > >
> > > windows(Cluster1/Esmart1/Smart1) that have a mirror lock, that means they
> > >
> > > can't be programed framebuffer address independently , they can only
> > >
> > > share framebuffer address with Cluster0/Esmart0/Smart0.
> >
> > Question:
> > Given Andy's comment could someone explain weather the vop and hdmi
> > nodes should be in rk3566.dtsi and rk3568.dtsi with an extra
> > rockchip,rk3566-dw-hdmi compatible?
>
> We could put the vop/hdmi nodes into rk356x.dtsi and just add the
> compatible properties to rk3566.dtsi and rk3568.dtsi.
sounds about right. We have similar solutions in place in other socs.
Heiko
