Re: [PATCH v2 01/41] drm/tests: Order Kunit tests in Makefile

[Konstantin Ryabitsev]

On Mon, Aug 29, 2022 at 08:46:42PM +0200, Noralf Trønnes wrote:
> Something has gone wrong with this patchset, there are double line endings.

I noticed this, too, and I think the reason is because these patches were
generated with "b4 send -o", but actually sent using git-send-email. It's not
a use-case I've considered (or tested) and the breakage is because when b4
generates patches with "-o", they are written with CRLF line endings, which is
not something git-send-email expects.

Maxime, any reason you went this direction instead of just letting b4 send
these patches directly?

-K

[PATCH v2] drm/bridge: it6505: Fix the order of DP_SET_POWER commands

[Pin-yen Lin]

Send DP_SET_POWER_D3 command to the downstream before stopping DP, so the
suspend process will not be interrupted by the HPD interrupt. Also modify
the order in .atomic_enable callback to make the callbacks symmetric.

Fixes: 46ca7da7f1e8 ("drm/bridge: it6505: Send DPCD SET_POWER to downstream")
Signed-off-by: Pin-yen Lin 
Reviewed-by: Robert Foss 
---

Changes in v2:
- Correct "fixes" tag.
- Collect "Reviewed-by" tag.

 drivers/gpu/drm/bridge/ite-it6505.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index f9251ec49bf0..2bb957cffd94 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2951,9 +2951,6 @@ static void it6505_bridge_atomic_enable(struct drm_bridge 
*bridge,
if (ret)
dev_err(dev, "Failed to setup AVI infoframe: %d", ret);
 
-   it6505_drm_dp_link_set_power(>aux, >link,
-DP_SET_POWER_D0);
-
it6505_update_video_parameter(it6505, mode);
 
ret = it6505_send_video_infoframe(it6505, );
@@ -2963,6 +2960,9 @@ static void it6505_bridge_atomic_enable(struct drm_bridge 
*bridge,
 
it6505_int_mask_enable(it6505);
it6505_video_reset(it6505);
+
+   it6505_drm_dp_link_set_power(>aux, >link,
+DP_SET_POWER_D0);
 }
 
 static void it6505_bridge_atomic_disable(struct drm_bridge *bridge,
@@ -2974,9 +2974,9 @@ static void it6505_bridge_atomic_disable(struct 
drm_bridge *bridge,
DRM_DEV_DEBUG_DRIVER(dev, "start");
 
if (it6505->powered) {
-   it6505_video_disable(it6505);
it6505_drm_dp_link_set_power(>aux, >link,
 DP_SET_POWER_D3);
+   it6505_video_disable(it6505);
}
 }
 
-- 
2.37.2.672.g94769d06f0-goog

[PATCH v9 10/10] video: backlight: mt6370: Add MediaTek MT6370 support

[ChiaEn Wu]

From: ChiaEn Wu 

MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and PD
standards.

Add support for the MediaTek MT6370 backlight driver.
It controls 4 channels of 8 series WLEDs in
2048 (only for MT6370/MT6371) / 16384 (only for MT6372)
current steps (30 mA) in exponential or linear mapping curves.

Reviewed-by: Daniel Thompson 
Signed-off-by: ChiaEn Wu 
---

v9
- Revise the format of the comments.
---
 drivers/video/backlight/Kconfig|  13 ++
 drivers/video/backlight/Makefile   |   1 +
 drivers/video/backlight/mt6370-backlight.c | 351 +
 3 files changed, 365 insertions(+)
 create mode 100644 drivers/video/backlight/mt6370-backlight.c

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index a003e02..936ba1e 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -268,6 +268,19 @@ config BACKLIGHT_MAX8925
  If you have a LCD backlight connected to the WLED output of MAX8925
  WLED output, say Y here to enable this driver.
 
+config BACKLIGHT_MT6370
+   tristate "MediaTek MT6370 Backlight Driver"
+   depends on MFD_MT6370
+   help
+ This enables support for Mediatek MT6370 Backlight driver.
+ It's commonly used to drive the display WLED. There are 4 channels
+ inside, and each channel supports up to 30mA of current capability
+ with 2048 current steps (only for MT6370/MT6371) or 16384 current
+ steps (only for MT6372) in exponential or linear mapping curves.
+
+ This driver can also be built as a module. If so, the module
+ will be called "mt6370-backlight".
+
 config BACKLIGHT_APPLE
tristate "Apple Backlight Driver"
depends on X86 && ACPI
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index cae2c83..e815f3f 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_BACKLIGHT_LP855X)+= lp855x_bl.o
 obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
 obj-$(CONFIG_BACKLIGHT_LV5207LP)   += lv5207lp.o
 obj-$(CONFIG_BACKLIGHT_MAX8925)+= max8925_bl.o
+obj-$(CONFIG_BACKLIGHT_MT6370) += mt6370-backlight.o
 obj-$(CONFIG_BACKLIGHT_OMAP1)  += omap1_bl.o
 obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
 obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
diff --git a/drivers/video/backlight/mt6370-backlight.c 
b/drivers/video/backlight/mt6370-backlight.c
new file mode 100644
index 000..623d4f2
--- /dev/null
+++ b/drivers/video/backlight/mt6370-backlight.c
@@ -0,0 +1,351 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Author: ChiaEn Wu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MT6370_REG_DEV_INFO0x100
+#define MT6370_REG_BL_EN   0x1A0
+#define MT6370_REG_BL_BSTCTRL  0x1A1
+#define MT6370_REG_BL_PWM  0x1A2
+#define MT6370_REG_BL_DIM2 0x1A4
+
+#define MT6370_VENID_MASK  GENMASK(7, 4)
+#define MT6370_BL_EXT_EN_MASK  BIT(7)
+#define MT6370_BL_EN_MASK  BIT(6)
+#define MT6370_BL_CODE_MASKBIT(0)
+#define MT6370_BL_CH_MASK  GENMASK(5, 2)
+#define MT6370_BL_CH_SHIFT 2
+#define MT6370_BL_DIM2_COMMON_MASK GENMASK(2, 0)
+#define MT6370_BL_DIM2_COMMON_SHIFT3
+#define MT6370_BL_DIM2_6372_MASK   GENMASK(5, 0)
+#define MT6370_BL_DIM2_6372_SHIFT  6
+#define MT6370_BL_PWM_EN_MASK  BIT(7)
+#define MT6370_BL_PWM_HYS_EN_MASK  BIT(2)
+#define MT6370_BL_PWM_HYS_SEL_MASK GENMASK(1, 0)
+#define MT6370_BL_OVP_EN_MASK  BIT(7)
+#define MT6370_BL_OVP_SEL_MASK GENMASK(6, 5)
+#define MT6370_BL_OVP_SEL_SHIFT5
+#define MT6370_BL_OC_EN_MASK   BIT(3)
+#define MT6370_BL_OC_SEL_MASK  GENMASK(2, 1)
+#define MT6370_BL_OC_SEL_SHIFT 1
+
+#define MT6370_BL_PWM_HYS_TH_MIN_STEP  1
+#define MT6370_BL_PWM_HYS_TH_MAX_STEP  64
+#define MT6370_BL_OVP_MIN_UV   1700
+#define MT6370_BL_OVP_MAX_UV   2900
+#define MT6370_BL_OVP_STEP_UV  400
+#define MT6370_BL_OCP_MIN_UA   90
+#define MT6370_BL_OCP_MAX_UA   180
+#define MT6370_BL_OCP_STEP_UA  30
+#define MT6370_BL_MAX_COMMON_BRIGHTNESS2048
+#define MT6370_BL_MAX_6372_BRIGHTNESS  16384
+#define MT6370_BL_MAX_CH   15
+
+enum {
+   MT6370_VID_COMMON = 1,
+   MT6370_VID_6372,
+};
+
+struct mt6370_priv {
+   u8 dim2_mask;
+   u8 dim2_shift;
+   int 

[PATCH v9 09/10] leds: flash: mt6370: Add MediaTek MT6370 flashlight support

[ChiaEn Wu]

From: Alice Chen 

The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias driver and a general LDO for portable devices.

Add support for the MT6370 Flash LED driver. Flash LED in MT6370
has 2 channels and support torch/strobe mode.

Signed-off-by: Alice Chen 
Signed-off-by: ChiaEn Wu 
---

v9
- Revise the format of the comments.
---
 drivers/leds/flash/Kconfig |  14 +
 drivers/leds/flash/Makefile|   1 +
 drivers/leds/flash/leds-mt6370-flash.c | 632 +
 3 files changed, 647 insertions(+)
 create mode 100644 drivers/leds/flash/leds-mt6370-flash.c

diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
index d3eb689..405bd16 100644
--- a/drivers/leds/flash/Kconfig
+++ b/drivers/leds/flash/Kconfig
@@ -61,6 +61,20 @@ config LEDS_MT6360
  Independent current sources supply for each flash LED support torch
  and strobe mode.
 
+config LEDS_MT6370_FLASH
+   tristate "Flash LED Support for MediaTek MT6370 PMIC"
+   depends on LEDS_CLASS && OF
+   depends on LEDS_CLASS_FLASH || !LEDS_CLASS_FLASH
+   depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
+   depends on MFD_MT6370
+   help
+ Support 2 channels and torch/strobe mode.
+ Say Y here to enable support for
+ MT6370_FLASH_LED device.
+
+ This driver can also be built as a module. If so, the module
+ will be called "leds-mt6370-flash".
+
 config LEDS_RT4505
tristate "LED support for RT4505 flashlight controller"
depends on I2C && OF
diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
index 0acbddc..0c1f3c5 100644
--- a/drivers/leds/flash/Makefile
+++ b/drivers/leds/flash/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
 obj-$(CONFIG_LEDS_RT4505)  += leds-rt4505.o
 obj-$(CONFIG_LEDS_RT8515)  += leds-rt8515.o
 obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
+obj-$(CONFIG_LEDS_MT6370_FLASH)+= leds-mt6370-flash.o
diff --git a/drivers/leds/flash/leds-mt6370-flash.c 
b/drivers/leds/flash/leds-mt6370-flash.c
new file mode 100644
index 000..a8ec7e1
--- /dev/null
+++ b/drivers/leds/flash/leds-mt6370-flash.c
@@ -0,0 +1,632 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Author: Alice Chen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+enum {
+   MT6370_LED_FLASH1,
+   MT6370_LED_FLASH2,
+   MT6370_MAX_LEDS
+};
+
+/* Virtual definition for multicolor */
+
+#define MT6370_REG_FLEDEN  0x17E
+#define MT6370_REG_STRBTO  0x173
+#define MT6370_REG_CHGSTAT20x1D1
+#define MT6370_REG_FLEDSTAT1   0x1D9
+#define MT6370_REG_FLEDISTRB(_id)  (0x174 + 4 * (_id))
+#define MT6370_REG_FLEDITOR(_id)   (0x175 + 4 * (_id))
+#define MT6370_ITORCH_MASK GENMASK(4, 0)
+#define MT6370_ISTROBE_MASKGENMASK(6, 0)
+#define MT6370_STRBTO_MASK GENMASK(6, 0)
+#define MT6370_TORCHEN_MASKBIT(3)
+#define MT6370_STROBEN_MASKBIT(2)
+#define MT6370_FLCSEN_MASK(_id)BIT(MT6370_LED_FLASH2 - (_id))
+#define MT6370_FLCSEN_MASK_ALL GENMASK(1, 0)
+#define MT6370_FLEDCHGVINOVP_MASK  BIT(3)
+#define MT6370_FLED1STRBTO_MASKBIT(11)
+#define MT6370_FLED2STRBTO_MASKBIT(10)
+#define MT6370_FLED1STRB_MASK  BIT(9)
+#define MT6370_FLED2STRB_MASK  BIT(8)
+#define MT6370_FLED1SHORT_MASK BIT(7)
+#define MT6370_FLED2SHORT_MASK BIT(6)
+#define MT6370_FLEDLVF_MASKBIT(3)
+
+#define MT6370_LED_JOINT   2
+#define MT6370_RANGE_FLED_REG  4
+#define MT6370_ITORCH_MIN_uA   25000
+#define MT6370_ITORCH_STEP_uA  12500
+#define MT6370_ITORCH_MAX_uA   40
+#define MT6370_ITORCH_DOUBLE_MAX_uA80
+#define MT6370_ISTRB_MIN_uA5
+#define MT6370_ISTRB_STEP_uA   12500
+#define MT6370_ISTRB_MAX_uA150
+#define MT6370_ISTRB_DOUBLE_MAX_uA 300
+#define MT6370_STRBTO_MIN_US   64000
+#define MT6370_STRBTO_STEP_US  32000
+#define MT6370_STRBTO_MAX_US   2432000
+
+#define STATE_OFF  0
+#define STATE_KEEP 1
+#define STATE_ON   2
+
+#define to_mt6370_led(ptr, member) container_of(ptr, struct mt6370_led, member)
+
+struct mt6370_led {
+   struct led_classdev_flash flash;
+   struct v4l2_flash *v4l2_flash;
+   struct mt6370_priv *priv;
+   u32 led_no;
+   u32 default_state;
+};
+
+struct mt6370_priv {
+   struct device *dev;
+ 

[PATCH v9 08/10] leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support

[ChiaEn Wu]

From: ChiYuan Huang 

The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias driver and a general LDO for portable devices.

Add support for the MediaTek MT6370 Current Sink Type LED Indicator
driver. It can control four channels current-sink RGB LEDs with 3 modes:
constant current, PWM, and breath mode.

Reviewed-by: AngeloGioacchino Del Regno 

Co-developed-by: Alice Chen 
Signed-off-by: Alice Chen 
Signed-off-by: ChiYuan Huang 
Signed-off-by: ChiaEn Wu 
---
 drivers/leds/rgb/Kconfig   |   13 +
 drivers/leds/rgb/Makefile  |1 +
 drivers/leds/rgb/leds-mt6370-rgb.c | 1010 
 3 files changed, 1024 insertions(+)
 create mode 100644 drivers/leds/rgb/leds-mt6370-rgb.c

diff --git a/drivers/leds/rgb/Kconfig b/drivers/leds/rgb/Kconfig
index 204cf47..7d86bb2 100644
--- a/drivers/leds/rgb/Kconfig
+++ b/drivers/leds/rgb/Kconfig
@@ -26,4 +26,17 @@ config LEDS_QCOM_LPG
 
  If compiled as a module, the module will be named leds-qcom-lpg.
 
+config LEDS_MT6370_RGB
+   tristate "LED Support for MediaTek MT6370 PMIC"
+   depends on MFD_MT6370
+   select LINEAR_RANGE
+   help
+ Say Y here to enable support for MT6370_RGB LED device.
+ In MT6370, there are four channel current-sink LED drivers that
+ support hardware pattern for constant current, PWM, and breath mode.
+ Isink4 channel can also be used as a CHG_VIN power good indicator.
+
+ This driver can also be built as a module. If so, the module
+ will be called "leds-mt6370-rgb".
+
 endif # LEDS_CLASS_MULTICOLOR
diff --git a/drivers/leds/rgb/Makefile b/drivers/leds/rgb/Makefile
index 0675bc0..8c01daf 100644
--- a/drivers/leds/rgb/Makefile
+++ b/drivers/leds/rgb/Makefile
@@ -2,3 +2,4 @@
 
 obj-$(CONFIG_LEDS_PWM_MULTICOLOR)  += leds-pwm-multicolor.o
 obj-$(CONFIG_LEDS_QCOM_LPG)+= leds-qcom-lpg.o
+obj-$(CONFIG_LEDS_MT6370_RGB)  += leds-mt6370-rgb.o
diff --git a/drivers/leds/rgb/leds-mt6370-rgb.c 
b/drivers/leds/rgb/leds-mt6370-rgb.c
new file mode 100644
index 000..1f9d648
--- /dev/null
+++ b/drivers/leds/rgb/leds-mt6370-rgb.c
@@ -0,0 +1,1010 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Authors:
+ *   ChiYuan Huang 
+ *   Alice Chen 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+enum {
+   MT6370_LED_ISNK1 = 0,
+   MT6370_LED_ISNK2,
+   MT6370_LED_ISNK3,
+   MT6370_LED_ISNK4,
+   MT6370_MAX_LEDS
+};
+
+enum mt6370_led_mode {
+   MT6370_LED_PWM_MODE = 0,
+   MT6370_LED_BREATH_MODE,
+   MT6370_LED_REG_MODE,
+   MT6370_LED_MAX_MODE
+};
+
+enum mt6370_led_field {
+   F_RGB_EN = 0,
+   F_CHGIND_EN,
+   F_LED1_CURR,
+   F_LED2_CURR,
+   F_LED3_CURR,
+   F_LED4_CURR,
+   F_LED1_MODE,
+   F_LED2_MODE,
+   F_LED3_MODE,
+   F_LED4_MODE,
+   F_LED1_DUTY,
+   F_LED2_DUTY,
+   F_LED3_DUTY,
+   F_LED4_DUTY,
+   F_LED1_FREQ,
+   F_LED2_FREQ,
+   F_LED3_FREQ,
+   F_LED4_FREQ,
+   F_MAX_FIELDS
+};
+
+enum mt6370_led_ranges {
+   R_LED123_CURR = 0,
+   R_LED4_CURR,
+   R_LED_TRFON,
+   R_LED_TOFF,
+   R_MAX_RANGES
+};
+
+enum mt6370_pattern {
+   P_LED_TR1 = 0,
+   P_LED_TR2,
+   P_LED_TF1,
+   P_LED_TF2,
+   P_LED_TON,
+   P_LED_TOFF,
+   P_MAX_PATTERNS
+};
+
+#define MT6370_REG_DEV_INFO0x100
+#define MT6370_REG_RGB1_DIM0x182
+#define MT6370_REG_RGB2_DIM0x183
+#define MT6370_REG_RGB3_DIM0x184
+#define MT6370_REG_RGB_EN  0x185
+#define MT6370_REG_RGB1_ISNK   0x186
+#define MT6370_REG_RGB2_ISNK   0x187
+#define MT6370_REG_RGB3_ISNK   0x188
+#define MT6370_REG_RGB1_TR 0x189
+#define MT6370_REG_RGB_CHRIND_DIM  0x192
+#define MT6370_REG_RGB_CHRIND_CTRL 0x193
+#define MT6370_REG_RGB_CHRIND_TR   0x194
+
+#define MT6372_REG_RGB_EN  0x182
+#define MT6372_REG_RGB1_ISNK   0x183
+#define MT6372_REG_RGB2_ISNK   0x184
+#define MT6372_REG_RGB3_ISNK   0x185
+#define MT6372_REG_RGB4_ISNK   0x186
+#define MT6372_REG_RGB1_DIM0x187
+#define MT6372_REG_RGB2_DIM0x188
+#define MT6372_REG_RGB3_DIM0x189
+#define MT6372_REG_RGB4_DIM0x18A
+#define MT6372_REG_RGB12_FREQ  0x18B
+#define MT6372_REG_RGB34_FREQ  0x18C
+#define 

[PATCH v9 07/10] power: supply: mt6370: Add MediaTek MT6370 charger driver

[ChiaEn Wu]

From: ChiaEn Wu 

MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and PD
standards.

Add support for the MediaTek MT6370 Charger driver. The charger module
of MT6370 supports High-Accuracy Voltage/Current Regulation,
Average Input Current Regulation, Battery Temperature Sensing,
Over-Temperature Protection, DPDM Detection for BC1.2.

Reviewed-by: Andy Shevchenko 
Signed-off-by: ChiaEn Wu 
---

v9
- Fix wrong 'F_IINLMTSEL' setting in 'mt6370_chg_init_setting()'
- Revise the usage of LINEAR_RANGE_IDX()
---
 drivers/power/supply/Kconfig  |  14 +
 drivers/power/supply/Makefile |   1 +
 drivers/power/supply/mt6370-charger.c | 957 ++
 3 files changed, 972 insertions(+)
 create mode 100644 drivers/power/supply/mt6370-charger.c

diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 1aa8323..591deb8 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -619,6 +619,20 @@ config CHARGER_MT6360
  Average Input Current Regulation, Battery Temperature Sensing,
  Over-Temperature Protection, DPDM Detection for BC1.2.
 
+config CHARGER_MT6370
+   tristate "MediaTek MT6370 Charger Driver"
+   depends on MFD_MT6370
+   depends on REGULATOR
+   select LINEAR_RANGES
+   help
+ Say Y here to enable MT6370 Charger Part.
+ The device supports High-Accuracy Voltage/Current Regulation,
+ Average Input Current Regulation, Battery Temperature Sensing,
+ Over-Temperature Protection, DPDM Detection for BC1.2.
+
+ This driver can also be built as a module. If so, the module
+ will be called "mt6370-charger".
+
 config CHARGER_QCOM_SMBB
tristate "Qualcomm Switch-Mode Battery Charger and Boost"
depends on MFD_SPMI_PMIC || COMPILE_TEST
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 7f02f36..8c95276 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o
 obj-$(CONFIG_CHARGER_MAX8998)  += max8998_charger.o
 obj-$(CONFIG_CHARGER_MP2629)   += mp2629_charger.o
 obj-$(CONFIG_CHARGER_MT6360)   += mt6360_charger.o
+obj-$(CONFIG_CHARGER_MT6370)   += mt6370-charger.o
 obj-$(CONFIG_CHARGER_QCOM_SMBB)+= qcom_smbb.o
 obj-$(CONFIG_CHARGER_BQ2415X)  += bq2415x_charger.o
 obj-$(CONFIG_CHARGER_BQ24190)  += bq24190_charger.o
diff --git a/drivers/power/supply/mt6370-charger.c 
b/drivers/power/supply/mt6370-charger.c
new file mode 100644
index 000..11c48ec
--- /dev/null
+++ b/drivers/power/supply/mt6370-charger.c
@@ -0,0 +1,957 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Author: ChiaEn Wu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MT6370_REG_CHG_CTRL1   0x111
+#define MT6370_REG_CHG_CTRL2   0x112
+#define MT6370_REG_CHG_CTRL3   0x113
+#define MT6370_REG_CHG_CTRL4   0x114
+#define MT6370_REG_CHG_CTRL5   0x115
+#define MT6370_REG_CHG_CTRL6   0x116
+#define MT6370_REG_CHG_CTRL7   0x117
+#define MT6370_REG_CHG_CTRL8   0x118
+#define MT6370_REG_CHG_CTRL9   0x119
+#define MT6370_REG_CHG_CTRL10  0x11A
+#define MT6370_REG_DEVICE_TYPE 0x122
+#define MT6370_REG_USB_STATUS1 0x127
+#define MT6370_REG_CHG_STAT0x14A
+#define MT6370_REG_FLED_EN 0x17E
+#define MT6370_REG_CHG_STAT1   0X1D0
+#define MT6370_REG_OVPCTRL_STAT0x1D8
+
+#define MT6370_VOBST_MASK  GENMASK(7, 2)
+#define MT6370_OTG_PIN_EN_MASK BIT(1)
+#define MT6370_OPA_MODE_MASK   BIT(0)
+#define MT6370_OTG_OC_MASK GENMASK(2, 0)
+
+#define MT6370_MIVR_IBUS_TH_100_mA 10
+#define MT6370_ADC_CHAN_IBUS   5
+#define MT6370_ADC_CHAN_MAX9
+
+enum mt6370_chg_reg_field {
+   /* MT6370_REG_CHG_CTRL2 */
+   F_IINLMTSEL, F_CFO_EN, F_CHG_EN,
+   /* MT6370_REG_CHG_CTRL3 */
+   F_IAICR, F_AICR_EN, F_ILIM_EN,
+   /* MT6370_REG_CHG_CTRL4 */
+   F_VOREG,
+   /* MT6370_REG_CHG_CTRL6 */
+   F_VMIVR,
+   /* MT6370_REG_CHG_CTRL7 */
+   F_ICHG,
+   /* MT6370_REG_CHG_CTRL8 */
+   F_IPREC,
+   /* MT6370_REG_CHG_CTRL9 */
+   F_IEOC,
+   /* MT6370_REG_DEVICE_TYPE */
+   F_USBCHGEN,
+   /* MT6370_REG_USB_STATUS1 */
+   F_USB_STAT, F_CHGDET,
+   /* MT6370_REG_CHG_STAT */
+   F_CHG_STAT, F_BOOST_STAT, F_VBAT_LVL,
+   /* MT6370_REG_FLED_EN */
+   F_FL_STROBE,
+   /* MT6370_REG_CHG_STAT1 */
+   

[PATCH v9 06/10] iio: adc: mt6370: Add MediaTek MT6370 support

[ChiaEn Wu]

From: ChiaEn Wu 

MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and PD
standards.

Add support for the MT6370 ADC driver for system monitoring, including
charger current, voltage, and temperature.

Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: Andy Shevchenko 
Acked-by: Jonathan Cameron 
Signed-off-by: ChiaEn Wu 
---
 drivers/iio/adc/Kconfig  |  12 ++
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/mt6370-adc.c | 305 +++
 3 files changed, 318 insertions(+)
 create mode 100644 drivers/iio/adc/mt6370-adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7fe5930..995cbb5 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -736,6 +736,18 @@ config MEDIATEK_MT6360_ADC
  is used in smartphones and tablets and supports a 11 channel
  general purpose ADC.
 
+config MEDIATEK_MT6370_ADC
+   tristate "MediaTek MT6370 ADC driver"
+   depends on MFD_MT6370
+   help
+ Say yes here to enable MediaTek MT6370 ADC support.
+
+ This ADC driver provides 9 channels for system monitoring (charger
+ current, voltage, and temperature).
+
+ This driver can also be built as a module. If so, the module
+ will be called "mt6370-adc".
+
 config MEDIATEK_MT6577_AUXADC
tristate "MediaTek AUXADC driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 1772a54..c6bc35f 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
 obj-$(CONFIG_MCP3911) += mcp3911.o
 obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
+obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
 obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
 obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
diff --git a/drivers/iio/adc/mt6370-adc.c b/drivers/iio/adc/mt6370-adc.c
new file mode 100644
index 000..2a46471
--- /dev/null
+++ b/drivers/iio/adc/mt6370-adc.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Author: ChiaEn Wu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define MT6370_REG_CHG_CTRL3   0x113
+#define MT6370_REG_CHG_CTRL7   0x117
+#define MT6370_REG_CHG_ADC 0x121
+#define MT6370_REG_ADC_DATA_H  0x14C
+
+#define MT6370_ADC_START_MASK  BIT(0)
+#define MT6370_ADC_IN_SEL_MASK GENMASK(7, 4)
+#define MT6370_AICR_ICHG_MASK  GENMASK(7, 2)
+
+#define MT6370_AICR_100_mA 0x0
+#define MT6370_AICR_150_mA 0x1
+#define MT6370_AICR_200_mA 0x2
+#define MT6370_AICR_250_mA 0x3
+#define MT6370_AICR_300_mA 0x4
+#define MT6370_AICR_350_mA 0x5
+
+#define MT6370_ICHG_100_mA 0x0
+#define MT6370_ICHG_200_mA 0x1
+#define MT6370_ICHG_300_mA 0x2
+#define MT6370_ICHG_400_mA 0x3
+#define MT6370_ICHG_500_mA 0x4
+#define MT6370_ICHG_600_mA 0x5
+#define MT6370_ICHG_700_mA 0x6
+#define MT6370_ICHG_800_mA 0x7
+
+#define ADC_CONV_TIME_MS   35
+#define ADC_CONV_POLLING_TIME_US   1000
+
+struct mt6370_adc_data {
+   struct device *dev;
+   struct regmap *regmap;
+   /*
+* This mutex lock is for preventing the different ADC channels
+* from being read at the same time.
+*/
+   struct mutex adc_lock;
+};
+
+static int mt6370_adc_read_channel(struct mt6370_adc_data *priv, int chan,
+  unsigned long addr, int *val)
+{
+   unsigned int reg_val;
+   __be16 be_val;
+   int ret;
+
+   mutex_lock(>adc_lock);
+
+   reg_val = MT6370_ADC_START_MASK |
+ FIELD_PREP(MT6370_ADC_IN_SEL_MASK, addr);
+   ret = regmap_write(priv->regmap, MT6370_REG_CHG_ADC, reg_val);
+   if (ret)
+   goto adc_unlock;
+
+   msleep(ADC_CONV_TIME_MS);
+
+   ret = regmap_read_poll_timeout(priv->regmap,
+  MT6370_REG_CHG_ADC, reg_val,
+  !(reg_val & MT6370_ADC_START_MASK),
+  ADC_CONV_POLLING_TIME_US,
+  ADC_CONV_TIME_MS * MILLI * 3);
+   if (ret) {
+   dev_err(priv->dev, "Failed to read ADC register (%d)\n", ret);
+   goto adc_unlock;
+   }
+
+   ret = regmap_raw_read(priv->regmap, MT6370_REG_ADC_DATA_H,
+

[PATCH v9 05/10] lib: add linear range index macro

[ChiaEn Wu]

From: ChiaEn Wu 

Add linear_range_idx macro for declaring the linear_range struct simply.

Signed-off-by: ChiaEn Wu 
---

v9
- Revise LINEAR_RANGE() and LINEAR_RANGE_IDX()
---
 include/linux/linear_range.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/linear_range.h b/include/linux/linear_range.h
index fd3d0b3..2e4f4c3 100644
--- a/include/linux/linear_range.h
+++ b/include/linux/linear_range.h
@@ -26,6 +26,17 @@ struct linear_range {
unsigned int step;
 };
 
+#define LINEAR_RANGE(_min, _min_sel, _max_sel, _step)  \
+   {   \
+   .min = _min,\
+   .min_sel = _min_sel,\
+   .max_sel = _max_sel,\
+   .step = _step,  \
+   }
+
+#define LINEAR_RANGE_IDX(_idx, _min, _min_sel, _max_sel, _step)\
+   [_idx] = LINEAR_RANGE(_min, _min_sel, _max_sel, _step)
+
 unsigned int linear_range_values_in_range(const struct linear_range *r);
 unsigned int linear_range_values_in_range_array(const struct linear_range *r,
int ranges);
-- 
2.7.4

[PATCH v9 04/10] dt-bindings: backlight: Add MediaTek MT6370 backlight

[ChiaEn Wu]

From: ChiYuan Huang 

Add MT6370 backlight binding documentation.

Reviewed-by: Rob Herring 
Reviewed-by: Daniel Thompson 
Signed-off-by: ChiYuan Huang 
Signed-off-by: ChiaEn Wu 
---
 .../leds/backlight/mediatek,mt6370-backlight.yaml  | 121 +
 1 file changed, 121 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
 
b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
new file mode 100644
index 000..5533b65
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/leds/backlight/mediatek,mt6370-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6370 Backlight
+
+maintainers:
+  - ChiaEn Wu 
+
+description: |
+  This module is part of the MT6370 MFD device.
+  The MT6370 Backlight WLED driver supports up to a 29V output voltage for
+  4 channels of 8 series WLEDs. Each channel supports up to 30mA of current
+  capability with 2048 current steps (11 bits, only for MT6370/MT6371) or
+  16384 current steps (14 bits, only for MT6372) in exponential or linear
+  mapping curves.
+
+allOf:
+  - $ref: common.yaml#
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt6370-backlight
+  - mediatek,mt6372-backlight
+
+  default-brightness:
+minimum: 0
+
+  max-brightness:
+minimum: 0
+
+  enable-gpios:
+description: External backlight 'enable' pin
+maxItems: 1
+
+  mediatek,bled-pwm-enable:
+description: |
+  Enable external PWM input for backlight dimming
+type: boolean
+
+  mediatek,bled-pwm-hys-enable:
+description: |
+  Enable the backlight input-hysteresis for PWM mode
+type: boolean
+
+  mediatek,bled-pwm-hys-input-th-steps:
+$ref: /schemas/types.yaml#/definitions/uint8
+enum: [1, 4, 16, 64]
+description: |
+  The selection of the upper and lower bounds threshold of backlight
+  PWM resolution. If we choose selection 64, the variation of PWM
+  resolution needs more than 64 steps.
+
+  mediatek,bled-ovp-shutdown:
+description: |
+  Enable the backlight shutdown when OVP level triggered
+type: boolean
+
+  mediatek,bled-ovp-microvolt:
+enum: [1700, 2100, 2500, 2900]
+description: |
+  Backlight OVP level selection.
+
+  mediatek,bled-ocp-shutdown:
+description: |
+  Enable the backlight shutdown when OCP level triggerred.
+type: boolean
+
+  mediatek,bled-ocp-microamp:
+enum: [90, 120, 150, 180]
+description: |
+  Backlight OC level selection.
+
+  mediatek,bled-exponential-mode-enable:
+description: |
+  Enable the exponential mode of backlight brightness. If this property
+  is not enabled, the default is to use linear mode.
+type: boolean
+
+  mediatek,bled-channel-use:
+$ref: /schemas/types.yaml#/definitions/uint8
+description: |
+  Backlight LED channel to be used.
+  Each bit mapping to:
+- 0: CH4
+- 1: CH3
+- 2: CH2
+- 3: CH1
+minimum: 1
+maximum: 15
+
+if:
+  properties:
+compatible:
+  contains:
+const: mediatek,mt6372-backlight
+
+then:
+  properties:
+default-brightness:
+  maximum: 16384
+
+max-brightness:
+  maximum: 16384
+
+else:
+  properties:
+default-brightness:
+  maximum: 2048
+
+max-brightness:
+  maximum: 2048
+
+required:
+  - compatible
+  - mediatek,bled-channel-use
+
+additionalProperties: false
-- 
2.7.4

[PATCH v9 03/10] dt-bindings: leds: Add MediaTek MT6370 flashlight

[ChiaEn Wu]

From: Alice Chen 

Add MediaTek MT6370 flashlight binding documentation.

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Alice Chen 
Signed-off-by: ChiaEn Wu 
---
 .../bindings/leds/mediatek,mt6370-flashlight.yaml  | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml

diff --git 
a/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml 
b/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml
new file mode 100644
index 000..e9d02ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/mediatek,mt6370-flashlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Flash LED driver for MT6370 PMIC from MediaTek Integrated.
+
+maintainers:
+  - Alice Chen 
+
+description: |
+  This module is part of the MT6370 MFD device.
+  Add MT6370 flash LED driver include 2-channel flash LED support Torch/Strobe 
Mode.
+
+properties:
+  compatible:
+const: mediatek,mt6370-flashlight
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^led@[0-1]$":
+type: object
+$ref: common.yaml#
+unevaluatedProperties: false
+
+properties:
+  reg:
+enum: [0, 1]
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties: false
-- 
2.7.4

[PATCH v9 02/10] dt-bindings: leds: mt6370: Add MediaTek MT6370 current sink type LED indicator

[ChiaEn Wu]

From: ChiYuan Huang 

Add MediaTek MT6370 current sink type LED indicator binding documentation.

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: ChiYuan Huang 
Signed-off-by: ChiaEn Wu 
---
 .../bindings/leds/mediatek,mt6370-indicator.yaml   | 81 ++
 1 file changed, 81 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml

diff --git 
a/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml 
b/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml
new file mode 100644
index 000..204b103
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/mediatek,mt6370-indicator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LED driver for MT6370 PMIC from MediaTek Integrated.
+
+maintainers:
+  - Alice Chen 
+
+description: |
+  This module is part of the MT6370 MFD device.
+  Add MT6370 LED driver include 4-channel RGB LED support Register/PWM/Breath 
Mode
+
+allOf:
+  - $ref: leds-class-multicolor.yaml#
+
+properties:
+  compatible:
+const: mediatek,mt6370-indicator
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^multi-led@[0-3]$":
+type: object
+
+properties:
+  reg:
+enum: [0, 1, 2, 3]
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^led@[0-2]$":
+type: object
+$ref: common.yaml#
+unevaluatedProperties: false
+
+properties:
+  reg:
+enum: [0, 1, 2]
+
+required:
+  - reg
+  - color
+
+required:
+  - reg
+  - color
+  - "#address-cells"
+  - "#size-cells"
+
+  "^led@[0-3]$":
+type: object
+$ref: common.yaml#
+unevaluatedProperties: false
+
+properties:
+  reg:
+enum: [0, 1, 2, 3]
+
+required:
+  - reg
+  - color
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties: false
-- 
2.7.4

[PATCH v9 01/10] dt-bindings: power: supply: Add MediaTek MT6370 Charger

[ChiaEn Wu]

From: ChiaEn Wu 

Add MediaTek MT6370 Charger binding documentation.

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: ChiaEn Wu 
---
 .../power/supply/mediatek,mt6370-charger.yaml  | 88 ++
 1 file changed, 88 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml

diff --git 
a/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml 
b/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml
new file mode 100644
index 000..bd09a0a
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/mediatek,mt6370-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6370 Battery Charger
+
+maintainers:
+  - ChiaEn Wu 
+
+description: |
+  This module is part of the MT6370 MFD device.
+  Provides Battery Charger, Boost for OTG devices and BC1.2 detection.
+
+properties:
+  compatible:
+const: mediatek,mt6370-charger
+
+  interrupts:
+description: |
+  Specify what irqs are needed to be handled by MT6370 Charger driver. IRQ
+  "MT6370_IRQ_CHG_MIVR", "MT6370_IRQ_ATTACH" and "MT6370_IRQ_OVPCTRL_UVP_D"
+  are required.
+items:
+  - description: BC1.2 done irq
+  - description: usb plug in irq
+  - description: mivr irq
+
+  interrupt-names:
+items:
+  - const: attach_i
+  - const: uvp_d_evt
+  - const: mivr
+
+  io-channels:
+description: |
+  Use ADC channel to read VBUS, IBUS, IBAT, etc., info.
+minItems: 1
+items:
+  - description: |
+  VBUS voltage with lower accuracy (+-75mV) but higher measure
+  range (1~22V)
+  - description: |
+  VBUS voltage with higher accuracy (+-30mV) but lower measure
+  range (1~9.76V)
+  - description: the main system input voltage
+  - description: battery voltage
+  - description: battery temperature-sense input voltage
+  - description: IBUS current (required)
+  - description: battery current
+  - description: |
+  regulated output voltage to supply for the PWM low-side gate driver
+  and the bootstrap capacitor
+  - description: IC junction temperature
+
+  io-channel-names:
+minItems: 1
+items:
+  - const: vbusdiv5
+  - const: vbusdiv2
+  - const: vsys
+  - const: vbat
+  - const: ts_bat
+  - const: ibus
+  - const: ibat
+  - const: chg_vddp
+  - const: temp_jc
+
+  usb-otg-vbus-regulator:
+type: object
+description: OTG boost regulator.
+unevaluatedProperties: false
+$ref: /schemas/regulator/regulator.yaml#
+
+properties:
+  enable-gpios:
+maxItems: 1
+
+required:
+  - compatible
+  - interrupts
+  - interrupt-names
+  - io-channels
+
+additionalProperties: false
+
+...
-- 
2.7.4

[PATCH v9 00/10] Add MediaTek MT6370 PMIC support

[ChiaEn Wu]

From: ChiaEn Wu 

This patch series add MediaTek MT6370 PMIC support and add a index macro
to . The MT6370 is a highly-integrated smart power
management IC, which includes a single cell Li-Ion/Li-Polymer switching
battery charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias driver and a general LDO for portable devices.

First, in this series of patches,
'dt-binding: mfd', 'mfd driver' has been applied by Lee in the v7.
https://lore.kernel.org/all/yvjdpq0mwnpqz...@google.com/
https://lore.kernel.org/all/yvjdxepc2cb58...@google.com/

'tcpci driver' has been applied by Greg in the v8.
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=c2a8ea5997fdfeb43eda259d5533234c3cae05d7

Second, the LED RGB driver is based on Andy's patch which moves
led_init_default_state_get() to the global header.
https://lore.kernel.org/all/20220805154907.32263-3-andriy.shevche...@linux.intel.com/

In addition, we added a macro to the  for declaring the
linear_range struct simply (see patch v9-0005) and made some changes for
MT6370 drivers (see v9 section of the change log below).

Thank you,
ChiaEn Wu
---
Changes in v9:
- In Patch 05/10:
- Revise LINEAR_RANGE() and LINEAR_RANGE_IDX()

- In Patch 07/10:
- Fix wrong 'F_IINLMTSEL' setting in 'mt6370_chg_init_setting()'
- Revise the usage of LINEAR_RANGE_IDX()

- In Patch 09/10:
- Revise the format of the comments.

- In Patch 10/10:
- Revise the format of the comments.


Changes in v8:
- In Patch 06/12:
- Add linear_range_idx macro for declaring the linear_range
  struct simply.

- In Patch 09/12:
- Remove MT6370_CHG_LINEAR_RANGE() macro, and change to use
  LINEAR_RANGE_IDX() macro

- In Patch 10/12:
- Add include header file 
- Remove useless 'enum mt6370_state' because of using 'enum 
led_default_state'
- Revise the calculation of 'val' in 'mt6370_gen_breath_pattern()'
- Replace the medthod of getting default-state by using
  led_init_default_state_get()

- In Patch 11/12:
- Add missing 'dependency config' in Kconfig
- Revise all multi-line comments

- In Patch 12/12:
- Add missing header file 
- Remove useledd header file 
- Revise the comment of 'mt6370_check_vendor_info()'


Changes in v7:
- In Patch 05/13:
- Add the second compatible string for 'mt6372'
- Add 'mediatek,bled-exponential-mode-enable' property for enable the
  exponential mode of backlight brightness
- Add validation for the maximum value of 'default-brightness' and
  'max-brightness'

- In Patch 07/13:
- Move '#define MT6370_REG_MAXADDR' to the next line of
  '#define MT6370_REG_CHG_MASK1'
- Rename 'MT6370_REG_ADDRLEN' to 'MT6370_MAX_ADDRLEN'

- In Patch 08/13:
- Revise 'devm_add_action_or_reset(dev, ...)' to one line
- Revise 'return regmap_update_bits(...)' with using positive
  conditional

- In Patch 09/13:
- Add AICR(100mA ~ 350mA), ICHG(100mA ~ 800mA) macros
- Remove 400mA AICR and 900mA ICHG macros
- Revise using 'if-else' to 'switch-case' in mt6370_adc_read_scale()
  where the adc channel is ibus or ibat

- In Patch 10/13:
- Revise the method to enable/disable irq
- Revise all 'if (ret < 0)' to 'if (ret)' after using
  mt6370_chg_field_set/get()
- Revise all 'OTG' text again

- In Patch 11/13:
- Add the comment for the union of 'struct mt6370_led'
- Revise the wrong description of 'Authors'
- Revise some typos (e.g. led --> LED)
- Revise 'if (!fwnode_property_read_string())' to
  'ret = fwnode_property_read_string()'
- Replace 'memcpy(...)' with 'put_unaligned_be24()' in
  mt6370_gen_breath_pattern()
- Replace all 'LED_OFF' with 0
- Remove the redundant assignment in mt6370_mc_pattern_clear()

- In Patch 12/13:
- Fix the indentation.
- For the well defined macro, the parenthesis is needed for input 
parameters.
- Replace some dev_warn to dev_info in 'init_flash_properties'.
- Add sentinel comment for the terminator entry of of_device_id.
- Use priv->fled_torch_used directly.
- Delete 0 in {}.
- Use _uA instead of _UA in definition.
- Refine the description.
- Use usleep_range instead of udelay.
- Rename config to LEDS_MT6370_FLASH.
- Add missing ">" in copyright.
- Change the Kconfig order

- In Patch 13/13:
- Add support 'exponential mode' property parsing
- Add 'return dev_err_probe()' after 'if (IS_ERR(priv->enable_gpio))'
- Add 'mt6372' compatible string
- Revise Kconfig help text
- Revise update()/get() for supporting 16384 steps (MT6372)
- Revise all shift usages 

[RFC PATCH 2/3] drm/msm: filter out modes for DSI bridge having unsupported clock

[Abhinav Kumar]

DSI interface used with a bridge chip connected to an external
display is subject to the same pixel clock limits as one
which is natively pluggable like DisplayPort.

Hence filter out DSI modes having an unsupported pixel clock
if its connected to a bridge which is pluggable.

Ideally, this can be accommodated into msm_dsi_modeset_init()
by passing an extra parameter but this will also affect non-dpu
targets. Till we add the same logic for non-dpu chipsets, lets
have this as a separate call.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 11 +++--
 drivers/gpu/drm/msm/dsi/dsi.c   |  5 +
 drivers/gpu/drm/msm/dsi/dsi.h   |  6 +++--
 drivers/gpu/drm/msm/dsi/dsi_host.c  | 40 -
 drivers/gpu/drm/msm/dsi/dsi_manager.c   |  2 +-
 drivers/gpu/drm/msm/msm_drv.h   |  4 
 6 files changed, 58 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 7a5fabc0fd4f..e6f7e07fd2a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -539,7 +539,8 @@ static void dpu_kms_wait_flush(struct msm_kms *kms, 
unsigned crtc_mask)
 
 static int _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
-   struct dpu_kms *dpu_kms)
+   struct dpu_kms *dpu_kms,
+   int max_ext_pclk)
 {
struct drm_encoder *encoder = NULL;
struct msm_display_info info;
@@ -582,6 +583,8 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
break;
}
 
+   msm_dsi_set_max_extpclk(priv->dsi[i], max_ext_pclk);
+
info.h_tile_instance[info.num_of_h_tiles++] = i;
info.is_cmd_mode = msm_dsi_is_cmd_mode(priv->dsi[i]);
 
@@ -595,6 +598,8 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
break;
}
 
+   msm_dsi_set_max_extpclk(priv->dsi[i], max_ext_pclk);
+
info.h_tile_instance[info.num_of_h_tiles++] = other;
}
 
@@ -702,7 +707,9 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
int rc = 0;
int i;
 
-   rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+   int max_ext_pclk = dpu_kms->catalog->caps->max_ext_pclk;
+
+   rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms, max_ext_pclk);
if (rc) {
DPU_ERROR("initialize_dsi failed, rc = %d\n", rc);
return rc;
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 39bbabb5daf6..3a06a157d1b1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -265,6 +265,11 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
return ret;
 }
 
+void msm_dsi_set_max_extpclk(struct msm_dsi *msm_dsi, int max_ext_pclk)
+{
+msm_dsi_host_set_max_extpclk(msm_dsi->host, max_ext_pclk);
+}
+
 void msm_dsi_snapshot(struct msm_disp_state *disp_state, struct msm_dsi 
*msm_dsi)
 {
msm_dsi_host_snapshot(disp_state, msm_dsi->host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 2a96b4fe7839..1be4ebb0f9c8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -93,8 +93,9 @@ int msm_dsi_host_power_on(struct mipi_dsi_host *host,
 int msm_dsi_host_power_off(struct mipi_dsi_host *host);
 int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
  const struct drm_display_mode *mode);
-enum drm_mode_status msm_dsi_host_check_dsc(struct mipi_dsi_host *host,
-   const struct drm_display_mode 
*mode);
+enum drm_mode_status msm_dsi_host_mode_valid(struct mipi_dsi_host *host,
+   const struct drm_display_mode *mode,
+   struct drm_bridge *ext_bridge);
 unsigned long msm_dsi_host_get_mode_flags(struct mipi_dsi_host *host);
 int msm_dsi_host_register(struct mipi_dsi_host *host);
 void msm_dsi_host_unregister(struct mipi_dsi_host *host);
@@ -109,6 +110,7 @@ void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host 
*host,
 void msm_dsi_host_destroy(struct mipi_dsi_host *host);
 int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
+void msm_dsi_host_set_max_extpclk(struct mipi_dsi_host *host, int 
max_ext_pclk);
 int msm_dsi_host_init(struct msm_dsi *msm_dsi);
 int msm_dsi_runtime_suspend(struct device *dev);
 int msm_dsi_runtime_resume(struct device *dev);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 57a4c0fa614b..4428a6a66ee1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ 

[RFC PATCH 1/3] drm/msm/dpu: add max external pixel clock for all targets

[Abhinav Kumar]

Add maximum external pixel clock for all targets based on
the advertised limits for each of them.

The pixel clock has been calculated from the timings mentioned
in the CEA specification for CEA modes and according to
the VESA CVT standard for the others.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 8 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 27f029fdc682..b04d219ac380 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -277,6 +277,7 @@ static const struct dpu_caps msm8998_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+   .max_ext_pclk = 594000,
 };
 
 static const struct dpu_caps qcm2290_dpu_caps = {
@@ -288,6 +289,7 @@ static const struct dpu_caps qcm2290_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .max_ext_pclk = 101250,
 };
 
 static const struct dpu_caps sdm845_dpu_caps = {
@@ -304,6 +306,7 @@ static const struct dpu_caps sdm845_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+   .max_ext_pclk = 594000,
 };
 
 static const struct dpu_caps sc7180_dpu_caps = {
@@ -316,6 +319,7 @@ static const struct dpu_caps sc7180_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .max_ext_pclk = 312250,
 };
 
 static const struct dpu_caps sm8150_dpu_caps = {
@@ -332,6 +336,7 @@ static const struct dpu_caps sm8150_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+   .max_ext_pclk = 594000,
 };
 
 static const struct dpu_caps sc8180x_dpu_caps = {
@@ -348,6 +353,7 @@ static const struct dpu_caps sc8180x_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+   .max_ext_pclk = 594000,
 };
 
 static const struct dpu_caps sm8250_dpu_caps = {
@@ -362,6 +368,7 @@ static const struct dpu_caps sm8250_dpu_caps = {
.has_3d_merge = true,
.max_linewidth = 4096,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .max_ext_pclk = 594000,
 };
 
 static const struct dpu_caps sc7280_dpu_caps = {
@@ -374,6 +381,7 @@ static const struct dpu_caps sc7280_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2400,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .max_ext_pclk = 312250,
 };
 
 static const struct dpu_mdp_cfg msm8998_mdp[] = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 38aa38ab1568..35cab76d9530 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -370,6 +370,7 @@ struct dpu_rotation_cfg {
 
 /**
  * struct dpu_caps - define DPU capabilities
+ * @max_ext_pclk   max pixel clock of the external display
  * @max_mixer_widthmax layer mixer line width support.
  * @max_mixer_blendstages max layer mixer blend stages or
  *   supported z order
@@ -386,6 +387,7 @@ struct dpu_rotation_cfg {
  * @max_vdeci_exp  max vertical decimation supported (max is 2^value)
  */
 struct dpu_caps {
+   int max_ext_pclk;
u32 max_mixer_width;
u32 max_mixer_blendstages;
u32 qseed_type;
-- 
2.7.4

[RFC PATCH 3/3] drm/msm: filter out modes for DP/eDP bridge having unsupported clock

[Abhinav Kumar]

Filter out DP/eDP modes having an unsupported pixel clock by
replacing the current hard-coded limit with the per chipset advertised
value.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  7 ---
 drivers/gpu/drm/msm/dp/dp_display.c | 16 +---
 drivers/gpu/drm/msm/dp/dp_parser.h  |  1 -
 drivers/gpu/drm/msm/msm_drv.h   |  5 +++--
 4 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e6f7e07fd2a6..7857ce58b615 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -614,7 +614,8 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
 
 static int _dpu_kms_initialize_displayport(struct drm_device *dev,
struct msm_drm_private *priv,
-   struct dpu_kms *dpu_kms)
+   struct dpu_kms *dpu_kms,
+   int max_ext_pclk)
 {
struct drm_encoder *encoder = NULL;
struct msm_display_info info;
@@ -632,7 +633,7 @@ static int _dpu_kms_initialize_displayport(struct 
drm_device *dev,
}
 
memset(, 0, sizeof(info));
-   rc = msm_dp_modeset_init(priv->dp[i], dev, encoder);
+   rc = msm_dp_modeset_init(priv->dp[i], dev, encoder, 
max_ext_pclk);
if (rc) {
DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
drm_encoder_cleanup(encoder);
@@ -715,7 +716,7 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
return rc;
}
 
-   rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
+   rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms, max_ext_pclk);
if (rc) {
DPU_ERROR("initialize_DP failed, rc = %d\n", rc);
return rc;
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aeff3f0d..8b91d8adf921 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -117,6 +117,7 @@ struct dp_display_private {
 
bool wide_bus_en;
 
+   int max_ext_pclk;
struct dp_audio *audio;
 };
 
@@ -986,8 +987,15 @@ enum drm_mode_status dp_bridge_mode_valid(struct 
drm_bridge *bridge,
if (dp->is_edp)
return MODE_OK;
 
-   if (mode->clock > DP_MAX_PIXEL_CLK_KHZ)
-   return MODE_CLOCK_HIGH;
+   /*
+* If DP/eDP supports HPD natively or through a bridge, need to make
+* sure that we filter out the modes with pixel clock higher than the
+* chipset capabilities
+*/
+   if ((bridge->ops & DRM_BRIDGE_OP_HPD) ||
+   (dp->next_bridge && (dp->next_bridge->ops & 
DRM_BRIDGE_OP_HPD)))
+   if (mode->clock > dp_display->max_ext_pclk)
+   return MODE_CLOCK_HIGH;
 
dp_display = container_of(dp, struct dp_display_private, dp_display);
link_info = _display->panel->link_info;
@@ -1587,7 +1595,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
 }
 
 int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
-   struct drm_encoder *encoder)
+   struct drm_encoder *encoder, int max_ext_pclk)
 {
struct msm_drm_private *priv;
struct dp_display_private *dp_priv;
@@ -1599,6 +1607,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct 
drm_device *dev,
priv = dev->dev_private;
dp_display->drm_dev = dev;
 
+   dp_priv->max_ext_pclk = max_ext_pclk;
+
dp_priv = container_of(dp_display, struct dp_display_private, 
dp_display);
 
ret = dp_display_request_irq(dp_display);
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h 
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a82bf1a..c94b793027a2 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -13,7 +13,6 @@
 #include "msm_drv.h"
 
 #define DP_LABEL "MDSS DP DISPLAY"
-#define DP_MAX_PIXEL_CLK_KHZ   675000
 #define DP_MAX_NUM_DP_LANES4
 
 enum dp_pm_type {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 44d882b04327..39e8cdde6152 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -329,7 +329,7 @@ static inline struct drm_dsc_config 
*msm_dsi_get_dsc_config(struct msm_dsi *msm_
 int __init msm_dp_register(void);
 void __exit msm_dp_unregister(void);
 int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
-struct drm_encoder *encoder);
+struct drm_encoder *encoder, int max_ext_pclk);
 void msm_dp_irq_postinstall(struct msm_dp *dp_display);
 void msm_dp_snapshot(struct msm_disp_state *disp_state, struct msm_dp 

[RFC PATCH 0/3] Limit pluggable display modes

[Abhinav Kumar]

As reported on https://gitlab.freedesktop.org/drm/msm/-/issues/17, currently
there is no mechanism to limit the display output to the pluggable displays
and it lets users connect any monitor on any chipset based device.

This can lead to undefined behavior because lets say the display
advertises an unsupported pixel clock as its preferred resolution, then
the end-user can experience undefined behavior such as black screen,
crash or an underrun.

The capabilities of every chipset are advertised in the product
specification for both on-device displays and pluggable displays.

Documents such as [1], [2] and [3] can easily be found on the vendor's
website which advertise the max resolution support for that chipset.

Utilize this information to filter out the resolutions which have
pixel clock more than the supported limits.

This change only addresses pluggable displays because the underlying
assumption is that for the built-in displays, the display being chosen
for the product will be done so after referring to the advertised limits.

For calculating the pixel clock, the value has been taken from the CEA
speficiation if the resolution is a CEA one and from the CVT specification
for non-CEA.

This change has only been compile tested so far to get a general feedback
first and once it takes a final shape, will validate on whatever devices I have
and will appreciate help from others who have devices which I dont.

[1]: 
https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/prod_brief_qcom_sd7c.pdf
[2]: 
https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/prod_brief_qcom_sd7c_gen2.pdf
[3]: 
https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/prod_brief_qcom_sd8cx_gen2.pdf

Abhinav Kumar (3):
  drm/msm/dpu: add max external pixel clock for all targets
  drm/msm: filter out modes for DSI bridge having unsupported clock
  drm/msm: filter out modes for DP/eDP bridge having unsupported clock

 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  8 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 18 
 drivers/gpu/drm/msm/dp/dp_display.c| 16 +--
 drivers/gpu/drm/msm/dp/dp_parser.h |  1 -
 drivers/gpu/drm/msm/dsi/dsi.c  |  5 
 drivers/gpu/drm/msm/dsi/dsi.h  |  6 ++--
 drivers/gpu/drm/msm/dsi/dsi_host.c | 40 ++
 drivers/gpu/drm/msm/dsi/dsi_manager.c  |  2 +-
 drivers/gpu/drm/msm/msm_drv.h  |  9 --
 10 files changed, 88 insertions(+), 19 deletions(-)

-- 
2.7.4

Re: [PATCH] dt-bindings: display: bridge: renesas,dw-hdmi: Fix 'unevaluatedProperties' warnings

[Laurent Pinchart]

Hi Prabhakar,

Thank you for the patch.

On Mon, Aug 29, 2022 at 10:58:16PM +0100, Lad Prabhakar wrote:
> With 'unevaluatedProperties' support implemented, there's a number of
> warnings when running dtbs_check:
> 
> arch/arm64/boot/dts/renesas/r8a774b1-hihope-rzg2n-rev2-ex-idk-1110wr.dtb: 
> hdmi@fead: Unevaluated properties are not allowed ('resets' was 
> unexpected)
>   From schema: 
> Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> 
> The main problem is that SoC DTSI's are including resets property, whereas
> the renesas,dw-hdmi.yaml has 'unevaluatedProperties: false'. So just add
> optional resets property to the binding.

Given that all the DT sources in the kernel specify the resets property,
how about making it mandatory ?

Reviewed-by: Laurent Pinchart 

> Signed-off-by: Lad Prabhakar 
> ---
>  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml| 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> index 0c9785c8db51..a7e44e249dd3 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> @@ -38,6 +38,9 @@ properties:
>clock-names:
>  maxItems: 2
>  
> +  resets:
> +maxItems: 1
> +
>ports:
>  $ref: /schemas/graph.yaml#/properties/ports
>  

-- 
Regards,

Laurent Pinchart

Re: [PATCH v5 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface

[Stephen Boyd]

+Philipp

Quoting Akhil P Oommen (2022-08-28 12:21:13)
> 
> Some clients like adreno gpu driver would like to ensure that its gdsc
> is collapsed at hardware during a gpu reset sequence. This is because it
> has a votable gdsc which could be ON due to a vote from another subsystem
> like tz, hyp etc or due to an internal hardware signal. To allow
> this, gpucc driver can expose an interface to the client driver using
> reset framework. Using this the client driver can trigger a polling within
> the gdsc driver.

Please include the reset maintainer on reset related patches.

-Stephen

> 
> This series is rebased on top of linus's master branch.
> 
> Related discussion: https://patchwork.freedesktop.org/patch/493144/
> 
> Changes in v5:
> - Nit: Remove a duplicate blank line (Krzysztof)
> 
> Changes in v4:
> - Update gpu dt-binding schema
> - Typo fix in commit text
> 
> Changes in v3:
> - Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map 
> (Krzysztof)
> 
> Changes in v2:
> - Return error when a particular custom reset op is not implemented. (Dmitry)
> 
> Akhil P Oommen (6):
>   dt-bindings: clk: qcom: Support gpu cx gdsc reset
>   clk: qcom: Allow custom reset ops
>   clk: qcom: gdsc: Add a reset op to poll gdsc collapse
>   clk: qcom: gpucc-sc7280: Add cx collapse reset support
>   dt-bindings: drm/msm/gpu: Add optional resets
>   arm64: dts: qcom: sc7280: Add Reset support for gpu
> 
>  .../devicetree/bindings/display/msm/gpu.yaml   |  6 +
>  arch/arm64/boot/dts/qcom/sc7280.dtsi   |  3 +++
>  drivers/clk/qcom/gdsc.c| 23 ++
>  drivers/clk/qcom/gdsc.h|  7 ++
>  drivers/clk/qcom/gpucc-sc7280.c| 10 
>  drivers/clk/qcom/reset.c   | 27 
> ++
>  drivers/clk/qcom/reset.h   |  8 +++
>  include/dt-bindings/clock/qcom,gpucc-sc7280.h  |  3 +++
>  8 files changed, 83 insertions(+), 4 deletions(-)

[PATCH] dt-bindings: display: bridge: renesas, dw-hdmi: Fix 'unevaluatedProperties' warnings

[Lad Prabhakar]

With 'unevaluatedProperties' support implemented, there's a number of
warnings when running dtbs_check:

arch/arm64/boot/dts/renesas/r8a774b1-hihope-rzg2n-rev2-ex-idk-1110wr.dtb: 
hdmi@fead: Unevaluated properties are not allowed ('resets' was unexpected)
From schema: 
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml

The main problem is that SoC DTSI's are including resets property, whereas
the renesas,dw-hdmi.yaml has 'unevaluatedProperties: false'. So just add
optional resets property to the binding.

Signed-off-by: Lad Prabhakar 
---
 .../devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml| 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
index 0c9785c8db51..a7e44e249dd3 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
@@ -38,6 +38,9 @@ properties:
   clock-names:
 maxItems: 2
 
+  resets:
+maxItems: 1
+
   ports:
 $ref: /schemas/graph.yaml#/properties/ports
 
-- 
2.25.1

Re: [PATCH] drm/bridge: ps8640: Add double reset T4 and T5 to power-on sequence

[Doug Anderson]

Hi,

On Mon, Aug 22, 2022 at 9:33 AM Doug Anderson  wrote:
>
> Hi,
>
> On Thu, Aug 18, 2022 at 8:03 AM Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Wed, Aug 17, 2022 at 8:22 PM Hsin-Yi Wang  wrote:
> > >
> > > On Thu, Aug 18, 2022 at 11:19 AM Rock Chiu
> > >  wrote:
> > > >
> > > > How does T4/T5  impact the real case? We talked previously the T4/T5
> > > > shouldn't cause user impact.
> > > > Do we have testing data from ODM?
> > > >
> > > Please leave comments below the previous comment's headline.
> > >
> > > I'm confused. The reason I upstreamed this patch is because this is in
> > > your application note and you asked us to help upstream it. Now do you
> > > mean that we don't need T4 and T5?
> >
> > I think Rock is asking what problems the extra delay is causing. In
> > other words: why do we care about keeping these delays short?
> >
> > The answer is that it affects boot speed and also resume speed of
> > devices. Adding these two delays here means that there's an extra 100
> > ms before the user can see something on the screen. That may not seem
> > like a lot, but those kinds of delays add up quickly. At least on
> > Chromebooks, booting quickly is always a big goal.
>
> While I'm not very happy with this change and I don't really
> understand why these delays need to be so long, if folks are really
> certain that we need them and can't make them shorter then I guess we
> can land it. I'll wait a few more days in case anyone wants to chime
> in with their thoughts.

I'll continue to grumble, but I did push it.

55453c0914d9 drm/bridge: ps8640: Add double reset T4 and T5 to power-on sequence

I pushed to "drm-misc-next" and not "drm-misc-fixes". It doesn't feel
massively urgent since apparently we've been without the
"double-reset" for years and having the extra bake time feels like the
better way to lean.

-Doug

Re: New subsystem for acceleration devices

[Kevin Hilman]

Hi Oded (and sorry I misspelled your name last time),

Oded Gabbay  writes:

> On Tue, Aug 23, 2022 at 9:24 PM Kevin Hilman  wrote:
>>
>> Hi Obed,
>>
>> Oded Gabbay  writes:
>>
>> [...]
>>
>> > I want to update that I'm currently in discussions with Dave to figure
>> > out what's the best way to move forward. We are writing it down to do
>> > a proper comparison between the two paths (new accel subsystem or
>> > using drm). I guess it will take a week or so.
>>
>> Any update on the discussions with Dave? and/or are there any plans to
>> discuss this further at LPC/ksummit yet?
> Hi Kevin.
>
> We are still discussing the details, as at least the habanalabs driver
> is very complex and there are multiple parts that I need to see if and
> how they can be mapped to drm.
> Some of us will attend LPC so we will probably take advantage of that
> to talk more about this.

OK, looking forward to some more conversations at LPC.

>>
>> We (BayLibre) are upstreaming support for APUs on Mediatek SoCs, and are
>> using the DRM-based approach.  I'll also be at LPC and happy to discuss
>> in person.
>>
>> For some context on my/our interest: back in Sept 2020 we initially
>> submitted an rpmesg based driver for kernel communication[1].  After
>> review comments, we rewrote that based on DRM[2] and are now using it
>> for some MTK SoCs[3] and supporting our MTK customers with it.
>>
>> Hopefully we will get the kernel interfaces sorted out soon, but next,
>> there's the userspace side of things.  To that end, we're also working
>> on libAPU, a common, open userspace stack.  Alex Bailon recently
>> presented a proposal earlier this year at Embedded Recipes in Paris
>> (video[4], slides[5].)
>>
>> libAPU would include abstractions of the kernel interfaces for DRM
>> (using libdrm), remoteproc/rpmsg, virtio etc. but also goes farther and
>> proposes an open firmware for the accelerator side using
>> libMetal/OpenAMP + rpmsg for communication with (most likely closed
>> source) vendor firmware.  Think of this like sound open firmware (SOF[6]),
>> but for accelerators.
>
> I think your device and the habana device are very different in
> nature, and it is part of what Dave and I discussed, whether these two
> classes of devices can live together. I guess they can live together
> in the kernel, but in the userspace, not so much imo.

Yeah, for now I think focusing on how to handle both classes of devices
in the kernel is the most important.

> The first class is the edge inference devices (usually as part of some
> SoC). I think your description of the APU on MTK SoC is a classic
> example of such a device.

Correct.

> You usually have some firmware you load, you give it a graph and
> pointers for input and output and then you just execute the graph
> again and again to perform inference and just replace the inputs.
>
> The second class is the data-center, training accelerators, which
> habana's gaudi device is classified as such. These devices usually
> have a number of different compute engines, a fabric for scaling out,
> on-device memory, internal MMUs and RAS monitoring requirements. Those
> devices are usually operated via command queues, either through their
> kernel driver or directly from user-space. They have multiple APIs for
> memory management, RAS, scaling-out and command-submissions.

OK, I see.

>>
>> We've been using this succesfully for Mediatek SoCs (which have a
>> Cadence VP6 APU) and have submitted/published the code, including the
>> OpenAMP[7] and libmetal[8] parts in addition to the kernel parts already
>> mentioned.
> What's the difference between libmetal and other open-source low-level
> runtime drivers, such as oneAPI level-zero ?

TBH, I'd never heard of oneAPI before, so I'm assuming it's mainly
focused in the data center.  libmetal/openAMP are widely used
in the consumer, industrial embedded space, and heavily used by FPGAs in
many market segments.

> Currently we have our own runtime driver which is tightly coupled with
> our h/w. For example, the method the userspace "talks" to the
> data-plane firmware is very proprietary as it is hard-wired into the
> architecture of the entire ASIC and how it performs deep-learning
> training. Therefore, I don't see how this can be shared with other
> vendors. Not because of secrecy but because it is simply not relevant
> to any other ASIC.

OK, makes sense.

Thanks for clarifying your use case in more detail.

Kevin

[PATCH v2 4/8] drm/i915: Prepare more multi-GT initialization

[Matt Roper]

We're going to introduce an additional intel_gt for MTL's media unit
soon.  Let's provide a bit more multi-GT initialization framework in
preparation for that.  The initialization will pull the list of GTs for
a platform from the device info structure.  Although necessary for the
immediate MTL media enabling, this same framework will also be used
farther down the road when we enable remote tiles on xehpsdv and pvc.

v2:
 - Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all().

Cc: Aravind Iddamsetty 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 51 +--
 drivers/gpu/drm/i915/gt/intel_gt.h|  1 -
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
 drivers/gpu/drm/i915/i915_drv.h   |  2 +
 drivers/gpu/drm/i915/intel_device_info.h  | 16 ++
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 +
 7 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 275ad72940c1..41acc285e8bf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -736,7 +736,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt 
*gt)
u16 vdbox_mask;
u16 vebox_mask;
 
-   info->engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+   GEM_BUG_ON(!info->engine_mask);
 
if (GRAPHICS_VER(i915) < 11)
return info->engine_mask;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index cf7aab7adb30..7b880dbed6ce 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -807,17 +807,16 @@ static void
 intel_gt_tile_cleanup(struct intel_gt *gt)
 {
intel_uncore_cleanup_mmio(gt->uncore);
-
-   if (!gt_is_root(gt))
-   kfree(gt);
 }
 
 int intel_gt_probe_all(struct drm_i915_private *i915)
 {
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct intel_gt *gt = >gt0;
+   const struct intel_gt_definition *gtdef;
phys_addr_t phys_addr;
unsigned int mmio_bar;
+   unsigned int i;
int ret;
 
mmio_bar = GRAPHICS_VER(i915) == 2 ? GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
@@ -828,14 +827,58 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
 * and it has been already initialized early during probe
 * in i915_driver_probe()
 */
+   gt->i915 = i915;
+   gt->name = "Primary GT";
+   gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+
+   drm_dbg(>drm, "Setting up %s\n", gt->name);
ret = intel_gt_tile_setup(gt, phys_addr);
if (ret)
return ret;
 
i915->gt[0] = gt;
 
-   /* TODO: add more tiles */
+   if (!HAS_EXTRA_GT_LIST(i915))
+   return 0;
+
+   for (i = 1, gtdef = _INFO(i915)->extra_gt_list[i - 1];
+gtdef->setup != NULL;
+i++, gtdef = _INFO(i915)->extra_gt_list[i - 1]) {
+   gt = drmm_kzalloc(>drm, sizeof(*gt), GFP_KERNEL);
+   if (!gt) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   gt->i915 = i915;
+   gt->name = gtdef->name;
+   gt->type = gtdef->type;
+   gt->info.engine_mask = gtdef->engine_mask;
+   gt->info.id = i;
+
+   drm_dbg(>drm, "Setting up %s\n", gt->name);
+   if (GEM_WARN_ON(range_overflows_t(resource_size_t,
+ gtdef->mapping_base,
+ SZ_16M,
+ pci_resource_len(pdev, 
mmio_bar {
+   ret = -ENODEV;
+   goto err;
+   }
+
+   ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
+   if (ret)
+   goto err;
+
+   i915->gt[i] = gt;
+   }
+
return 0;
+
+err:
+   i915_probe_error(i915, "Failed to initialize %s! (%d)\n", gtdef->name, 
ret);
+   intel_gt_release_all(i915);
+
+   return ret;
 }
 
 int intel_gt_tiles_init(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 40b06adf509a..4d8779529cc2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -54,7 +54,6 @@ void intel_gt_driver_register(struct intel_gt *gt);
 void intel_gt_driver_unregister(struct intel_gt *gt);
 void intel_gt_driver_remove(struct intel_gt *gt);
 void intel_gt_driver_release(struct intel_gt *gt);
-
 void intel_gt_driver_late_release_all(struct drm_i915_private *i915);
 
 int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 

Re: [PATCH 3/5] dt-bindings: clock: drop minItems equal to maxItems

[Rob Herring]

On Thu, 25 Aug 2022 14:33:32 +0300, Krzysztof Kozlowski wrote:
> minItems, if missing, are implicitly equal to maxItems, so drop
> redundant piece to reduce size of code.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml   | 1 -
>  .../devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml  | 2 --
>  Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml| 1 -
>  3 files changed, 4 deletions(-)
> 

Acked-by: Rob Herring 

Re: [PATCH RESEND - dt 2/2] dt-bindings: leds: qcom-wled: fix number of addresses

[Rob Herring]

On Thu, 25 Aug 2022 15:54:10 +0300, Krzysztof Kozlowski wrote:
> On PM660L, PMI8994 and PMI8998, the WLED has two address spaces.  This
> also fixes dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dtb: leds@d800: reg: 
> [[55296], [2]] is too long
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../devicetree/bindings/leds/backlight/qcom-wled.yaml| 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 

Applied, thanks!

Re: [PATCH RESEND - dt 1/2] dt-bindings: nvmem: qfprom: add IPQ8064 and SDM630 compatibles

[Rob Herring]

On Thu, 25 Aug 2022 15:54:09 +0300, Krzysztof Kozlowski wrote:
> Document compatibles for QFPROM used on IPQ8064 and SDM630.  They are
> compatible with generic QFPROM fallback.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Applied, thanks!

Re: [PATCH 5/5] dt-bindings: display: drop minItems equal to maxItems

[Rob Herring]

On Thu, 25 Aug 2022 14:33:34 +0300, Krzysztof Kozlowski wrote:
> minItems, if missing, are implicitly equal to maxItems, so drop
> redundant piece to reduce size of code.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml   | 1 -
>  .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 --
>  Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 2 --
>  .../bindings/display/samsung/samsung,exynos5433-decon.yaml  | 2 --
>  .../bindings/display/samsung/samsung,exynos5433-mic.yaml| 1 -
>  .../bindings/display/samsung/samsung,exynos7-decon.yaml | 1 -
>  .../devicetree/bindings/display/samsung/samsung,fimd.yaml   | 1 -
>  .../devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml  | 1 -
>  .../devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml   | 2 --
>  9 files changed, 13 deletions(-)
> 

Applied, thanks!

Re: [PATCH 4/5] dt-bindings: crypto: drop minItems equal to maxItems

[Rob Herring]

On Thu, 25 Aug 2022 14:33:33 +0300, Krzysztof Kozlowski wrote:
> minItems, if missing, are implicitly equal to maxItems, so drop
> redundant piece to reduce size of code.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml | 1 -
>  1 file changed, 1 deletion(-)
> 

Applied, thanks!

Re: [PATCH 2/5] dt-bindings: ata: drop minItems equal to maxItems

[Rob Herring]

On Thu, 25 Aug 2022 14:33:31 +0300, Krzysztof Kozlowski wrote:
> minItems, if missing, are implicitly equal to maxItems, so drop
> redundant piece to reduce size of code.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml   | 1 -
>  .../devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml | 2 --
>  Documentation/devicetree/bindings/ata/sata_highbank.yaml| 1 -
>  3 files changed, 4 deletions(-)
> 

Applied, thanks!

Re: [PATCH 1/5] dt-bindings: socionext,uniphier-system-cache: drop minItems equal to maxItems

[Rob Herring]

On Thu, 25 Aug 2022 14:33:30 +0300, Krzysztof Kozlowski wrote:
> minItems, if missing, are implicitly equal to maxItems, so drop
> redundant piece to reduce size of code.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../bindings/arm/socionext/socionext,uniphier-system-cache.yaml  | 1 -
>  1 file changed, 1 deletion(-)
> 

Applied, thanks!

Re: [PATCH] dt-bindings: display: Add missing (unevaluated|additional)Properties on child nodes

[Rob Herring]

On Tue, 23 Aug 2022 09:56:42 -0500, Rob Herring wrote:
> In order to ensure only documented properties are present, node schemas
> must have unevaluatedProperties or additionalProperties set to false
> (typically).
> 
> Signed-off-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/display/arm,komeda.yaml| 1 +
>  Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
>  Documentation/devicetree/bindings/display/msm/gpu.yaml   | 1 +
>  .../bindings/display/samsung/samsung,exynos7-decon.yaml  | 1 +
>  .../devicetree/bindings/display/samsung/samsung,fimd.yaml| 1 +
>  5 files changed, 5 insertions(+)
> 

Applied, thanks!

Re: [PATCH] dt-bindings: display: synopsys, dw-hdmi: drop ref from reg-io-width

[Rob Herring]

On Tue, 23 Aug 2022 13:10:31 +0300, Krzysztof Kozlowski wrote:
> reg-io-width is a standard property, so no need for defining its type
> with $ref.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml | 1 -
>  1 file changed, 1 deletion(-)
> 

Applied, thanks!

Re: [PATCH linux-next] drm/amdkfd: remove redundant variables err and ret

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Aug 29, 2022 at 8:29 AM  wrote:
>
> From: Jinpeng Cui 
>
> Return value from kfd_wait_on_events() and io_remap_pfn_range() directly
> instead of taking this in another redundant variable.
>
> Reported-by: Zeal Robot 
> Signed-off-by: Jinpeng Cui 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 664e8b5d82c0..84da1a9ce37c 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -876,14 +876,11 @@ static int kfd_ioctl_wait_events(struct file *filp, 
> struct kfd_process *p,
> void *data)
>  {
> struct kfd_ioctl_wait_events_args *args = data;
> -   int err;
>
> -   err = kfd_wait_on_events(p, args->num_events,
> +   return kfd_wait_on_events(p, args->num_events,
> (void __user *)args->events_ptr,
> (args->wait_for_all != 0),
> >timeout, >wait_result);
> -
> -   return err;
>  }
>  static int kfd_ioctl_set_scratch_backing_va(struct file *filep,
> struct kfd_process *p, void *data)
> @@ -2860,7 +2857,6 @@ static int kfd_mmio_mmap(struct kfd_dev *dev, struct 
> kfd_process *process,
>   struct vm_area_struct *vma)
>  {
> phys_addr_t address;
> -   int ret;
>
> if (vma->vm_end - vma->vm_start != PAGE_SIZE)
> return -EINVAL;
> @@ -2880,12 +2876,11 @@ static int kfd_mmio_mmap(struct kfd_dev *dev, struct 
> kfd_process *process,
>  process->pasid, (unsigned long long) vma->vm_start,
>  address, vma->vm_flags, PAGE_SIZE);
>
> -   ret = io_remap_pfn_range(vma,
> +   return io_remap_pfn_range(vma,
> vma->vm_start,
> address >> PAGE_SHIFT,
> PAGE_SIZE,
> vma->vm_page_prot);
> -   return ret;
>  }
>
>
> --
> 2.25.1
>

Re: [PATCH linux-next] drm/amd/display: remove redundant vertical_line_start variable

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Aug 29, 2022 at 8:13 AM  wrote:
>
> From: Jinpeng Cui 
>
> Return value from expression directly instead of
> taking this in another redundant variable.
>
> Reported-by: Zeal Robot 
> Signed-off-by: Jinpeng Cui 
> ---
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> index 37246e965457..8f4f1ea447a7 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> @@ -3741,7 +3741,6 @@ int dcn10_get_vupdate_offset_from_vsync(struct pipe_ctx 
> *pipe_ctx)
> int vesa_sync_start;
> int asic_blank_end;
> int interlace_factor;
> -   int vertical_line_start;
>
> patched_crtc_timing = *dc_crtc_timing;
> apply_front_porch_workaround(_crtc_timing);
> @@ -3757,10 +3756,8 @@ int dcn10_get_vupdate_offset_from_vsync(struct 
> pipe_ctx *pipe_ctx)
> patched_crtc_timing.v_border_top)
> * interlace_factor;
>
> -   vertical_line_start = asic_blank_end -
> +   return asic_blank_end -
> pipe_ctx->pipe_dlg_param.vstartup_start + 1;
> -
> -   return vertical_line_start;
>  }
>
>  void dcn10_calc_vupdate_position(
> --
> 2.25.1
>

Re: [PATCH v4 07/12] drm: bridge: samsung-dsim: Fix PLL_P (PMS_P) offset

[Adam Ford]

On Mon, Aug 29, 2022 at 1:41 PM Jagan Teki  wrote:
>
> The i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020
> with 13.7.10.1 Master PLL PMS Value setting Register mentioned PMS_P offset
> range from BIT[18-13] and the upstream driver is using the same offset.
>
> However, offset 13 is not working on i.MX8M Mini platforms but downstream
> NXP driver is using 14 [1] and it is working with i.MX8M Mini SoC.

>From the line you highlighted in the link, the downstream NXP ones
shows 13 if I'm reading it correctly.

#define PLLCTRL_SET_P(x) REG_PUT(x, 18, 13)

>From what I can tell the PMS calculation here needs to be updated for
the Mini because the ranges of the FCO calculator are different.  Took
your series and tweaked it a bit [2] which changes a few settings, and
the PMS calculator appears to more closely match the values I get from
the NXP one.  I think it could be further tweaked because p min and
p_max also have changed.

>
> Not sure about whether it is reference manual documentation or something
> else but this patch trusts the downstream code and fixes the PLL_P offset.
>
> [1] 
> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n211
>

[2] 
-https://github.com/aford173/linux/commit/a5fa184160ec9ea45a7546eaa0d8b8fc760cf3d9

> v4, v3, v2:
> * none
>
> v1:
> * updated commit message
> * add downstream driver link
>
> Signed-off-by: Frieder Schrempf 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/gpu/drm/bridge/samsung-dsim.c | 10 --
>  include/drm/bridge/samsung-dsim.h |  1 +
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index b6883a6d4681..b6d17c0c9e58 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -168,7 +168,7 @@
>  /* DSIM_PLLCTRL */
>  #define DSIM_FREQ_BAND(x)  ((x) << 24)
>  #define DSIM_PLL_EN(1 << 23)
> -#define DSIM_PLL_P(x)  ((x) << 13)
> +#define DSIM_PLL_P(x, offset)  ((x) << (offset))
>  #define DSIM_PLL_M(x)  ((x) << 4)
>  #define DSIM_PLL_S(x)  ((x) << 1)
>
> @@ -368,6 +368,7 @@ static const struct samsung_dsim_driver_data 
> exynos3_dsi_driver_data = {
> .max_freq = 1000,
> .wait_for_reset = 1,
> .num_bits_resol = 11,
> +   .pll_p_offset = 13,
> .reg_values = reg_values,
> .quirks = DSIM_QUIRK_PLAT_DATA,
>  };
> @@ -381,6 +382,7 @@ static const struct samsung_dsim_driver_data 
> exynos4_dsi_driver_data = {
> .max_freq = 1000,
> .wait_for_reset = 1,
> .num_bits_resol = 11,
> +   .pll_p_offset = 13,
> .reg_values = reg_values,
> .quirks = DSIM_QUIRK_PLAT_DATA,
>  };
> @@ -392,6 +394,7 @@ static const struct samsung_dsim_driver_data 
> exynos5_dsi_driver_data = {
> .max_freq = 1000,
> .wait_for_reset = 1,
> .num_bits_resol = 11,
> +   .pll_p_offset = 13,
> .reg_values = reg_values,
> .quirks = DSIM_QUIRK_PLAT_DATA,
>  };
> @@ -404,6 +407,7 @@ static const struct samsung_dsim_driver_data 
> exynos5433_dsi_driver_data = {
> .max_freq = 1500,
> .wait_for_reset = 0,
> .num_bits_resol = 12,
> +   .pll_p_offset = 13,
> .reg_values = exynos5433_reg_values,
> .quirks = DSIM_QUIRK_PLAT_DATA,
>  };
> @@ -416,6 +420,7 @@ static const struct samsung_dsim_driver_data 
> exynos5422_dsi_driver_data = {
> .max_freq = 1500,
> .wait_for_reset = 1,
> .num_bits_resol = 12,
> +   .pll_p_offset = 13,
> .reg_values = exynos5422_reg_values,
> .quirks = DSIM_QUIRK_PLAT_DATA,
>  };
> @@ -563,7 +568,8 @@ static unsigned long samsung_dsim_set_pll(struct 
> samsung_dsim *dsi,
> writel(driver_data->reg_values[PLL_TIMER],
> dsi->reg_base + driver_data->plltmr_reg);
>
> -   reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
> +   reg = DSIM_PLL_EN | DSIM_PLL_P(p, driver_data->pll_p_offset) |
> + DSIM_PLL_M(m) | DSIM_PLL_S(s);
>
> if (driver_data->has_freqband) {
> static const unsigned long freq_bands[] = {
> diff --git a/include/drm/bridge/samsung-dsim.h 
> b/include/drm/bridge/samsung-dsim.h
> index e15fbfd49efe..95d3f89aec4f 100644
> --- a/include/drm/bridge/samsung-dsim.h
> +++ b/include/drm/bridge/samsung-dsim.h
> @@ -47,6 +47,7 @@ struct samsung_dsim_driver_data {
> unsigned int max_freq;
> unsigned int wait_for_reset;
> unsigned int num_bits_resol;
> +   unsigned int pll_p_offset;
> const unsigned int *reg_values;
> enum samsung_dsim_quirks quirks;
>  };
> --
> 2.25.1
>

Re: [PATCH v2 1/3] drm/atomic-helper: print message on driver connector check failure

[Lyude Paul]

Thanks for this! We definitely need more logging like this in DRM. for patches
1 and 2:

Reviewed-by: Lyude Paul 

On Mon, 2022-08-29 at 15:14 +, Simon Ser wrote:
> Sometimes drivers are missing logs when they return EINVAL.
> Printing the failure here in common code can help understand where
> EINVAL is coming from.
> 
> All other atomic_check() calls in this file already have similar
> logging.
> 
> v2: add missing newlines
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Lyude Paul 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c6abfd3d4b62..4aa05b626b57 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -702,8 +702,12 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>  
>   if (funcs->atomic_check)
>   ret = funcs->atomic_check(connector, state);
> - if (ret)
> + if (ret) {
> + drm_dbg_atomic(dev,
> +"[CONNECTOR:%d:%s] driver check 
> failed\n",
> +connector->base.id, connector->name);
>   return ret;
> + }
>  
>   connectors_mask |= BIT(i);
>   }
> @@ -745,8 +749,12 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>  
>   if (funcs->atomic_check)
>   ret = funcs->atomic_check(connector, state);
> - if (ret)
> + if (ret) {
> + drm_dbg_atomic(dev,
> +"[CONNECTOR:%d:%s] driver check 
> failed\n",
> +connector->base.id, connector->name);
>   return ret;
> + }
>   }
>  
>   /*

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [PATCH v2 01/41] drm/tests: Order Kunit tests in Makefile

[Noralf Trønnes]

Den 29.08.2022 15.11, skrev Maxime Ripard:
> Since we've recently added a ton of tests, the list starts to be a bit
> 
> of a mess and creates unneeded conflicts.
> 
> 
> 
> Let's order it alphabetically.
> 
> 
> 
> Signed-off-by: Maxime Ripard 
> 
> 
> 

Something has gone wrong with this patchset, there are double line endings.

I looked at the patchwork version and it look all right there so I
figured it might have fixed up the patches, but it failed:

git apply -v --check
/home/pi/tinydrm.gud-gadget/workdirs/tv_norm_gadget/53.patch
Checking patch drivers/gpu/drm/tests/Makefile...
error: while searching for:
# SPDX-License-Identifier: GPL-2.0?
?
obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o
drm_damage_helper_test.o \?
drm_cmdline_parser_test.o drm_rect_test.o drm_format_test.o
drm_plane_helper_test.o \?
drm_dp_mst_helper_test.o drm_framebuffer_test.o drm_buddy_test.o
drm_mm_test.o?

error: patch failed: drivers/gpu/drm/tests/Makefile:1
error: drivers/gpu/drm/tests/Makefile: patch does not apply

ERROR: Failed check apply patch

pi@build-server:~/tinydrm.gud-gadget$ file
workdirs/tv_norm_gadget/53.patch
workdirs/tv_norm_gadget/53.patch: unified diff output, ASCII text,
with CRLF, LF line terminators

Noralf.

> diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
> 
> index 91b70f7d2769..2d9f49b62ecb 100644
> 
> --- a/drivers/gpu/drm/tests/Makefile
> 
> +++ b/drivers/gpu/drm/tests/Makefile
> 
> @@ -1,5 +1,13 @@
> 
>  # SPDX-License-Identifier: GPL-2.0
> 
>  
> 
> -obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o 
> drm_damage_helper_test.o \
> 
> - drm_cmdline_parser_test.o drm_rect_test.o drm_format_test.o 
> drm_plane_helper_test.o \
> 
> - drm_dp_mst_helper_test.o drm_framebuffer_test.o drm_buddy_test.o 
> drm_mm_test.o
> 
> +obj-$(CONFIG_DRM_KUNIT_TEST) += \
> 
> + drm_buddy_test.o \
> 
> + drm_cmdline_parser_test.o \
> 
> + drm_damage_helper_test.o \
> 
> + drm_dp_mst_helper_test.o \
> 
> + drm_format_helper_test.o \
> 
> + drm_format_test.o \
> 
> + drm_framebuffer_test.o \
> 
> + drm_mm_test.o \
> 
> + drm_plane_helper_test.o \
> 
> + drm_rect_test.o
> 
> 
> 

[PATCH v4 12/12] drm: bridge: samsung-dsim: Add i.MX8MM support

[Jagan Teki]

Samsung MIPI DSIM master can also be found in i.MX8MM SoC.

Add compatible and associated driver_data for it.

v4:
* none

v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk

v2:
* collect Laurent r-b

v1:
* none

Reviewed-by: Laurent Pinchart 
Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index f3b5e265b027..749b11e19217 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -360,6 +360,24 @@ static const unsigned int exynos5433_reg_values[] = {
[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
 };
 
+static const unsigned int imx8mm_dsim_reg_values[] = {
+   [RESET_TYPE] = DSIM_SWRST,
+   [PLL_TIMER] = 500,
+   [STOP_STATE_CNT] = 0xf,
+   [PHYCTRL_ULPS_EXIT] = 0,
+   [PHYCTRL_VREG_LP] = 0,
+   [PHYCTRL_SLEW_UP] = 0,
+   [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
+   [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
+   [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
+   [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x26),
+   [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
+   [PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
+   [PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x08),
+   [PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
+   [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+};
+
 static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
.reg_ofs = exynos_reg_ofs,
.plltmr_reg = 0x50,
@@ -426,6 +444,19 @@ static const struct samsung_dsim_driver_data 
exynos5422_dsi_driver_data = {
.quirks = DSIM_QUIRK_PLAT_DATA,
 };
 
+static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
+   .reg_ofs = exynos5433_reg_ofs,
+   .plltmr_reg = 0xa0,
+   .has_clklane_stop = 1,
+   .num_clks = 2,
+   .max_freq = 2100,
+   .wait_for_reset = 0,
+   .num_bits_resol = 12,
+   .pll_p_offset = 14,
+   .reg_values = imx8mm_dsim_reg_values,
+   .quirks = DSIM_QUIRK_FIXUP_SYNC_POL,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
{
.compatible = "samsung,exynos3250-mipi-dsi",
@@ -447,6 +478,10 @@ static const struct of_device_id samsung_dsim_of_match[] = 
{
.compatible = "samsung,exynos5433-mipi-dsi",
.data = _dsi_driver_data
},
+   {
+   .compatible = "fsl,imx8mm-mipi-dsim",
+   .data = _dsi_driver_data
+   },
{ /* sentinel. */ }
 };
 
-- 
2.25.1

[PATCH v4 10/12] drm: bridge: samsung-dsim: Add input_bus_flags

[Jagan Teki]

eLCDIF is expecting to have input_bus_flags as DE_LOW in order to
set active low during valid data transfer on each horizontal line.

Add DE_LOW flag via drm bridge timings.

v4, v3, v2:
* none

v1:
* none

Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 871cc8cc5352..f3b5e265b027 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1593,6 +1593,10 @@ __weak void samsung_dsim_plat_remove(struct samsung_dsim 
*priv)
 {
 }
 
+static const struct drm_bridge_timings samsung_dsim_bridge_timings = {
+   .input_bus_flags = DRM_BUS_FLAG_DE_LOW,
+};
+
 static int samsung_dsim_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1672,6 +1676,7 @@ static int samsung_dsim_probe(struct platform_device 
*pdev)
 
dsi->bridge.funcs = _dsim_bridge_funcs;
dsi->bridge.of_node = dev->of_node;
+   dsi->bridge.timings = _dsim_bridge_timings;
dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
 
if (dsi->driver_data->quirks & DSIM_QUIRK_PLAT_DATA)
-- 
2.25.1

[PATCH v4 06/12] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.

Host transfer() is usually triggered for downstream DSI panels or
bridges and I2C-configured-DSI bridges miss these host initialization
as these downstream bridges use bridge operations hooks like pre_enable,
and enable in order to initialize or set up the host.

This patch is trying to handle the host init handler to satisfy all
downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
flag to ensure that host init is also done on first cmd transfer, this
helps existing DSI panels work on exynos platform (form Marek
Szyprowski).

v4:
* update init handling to ensure host init done on first cmd transfer

v3:
* none

v2:
* check initialized state in samsung_dsim_init

v1:
* keep DSI init in host transfer

Signed-off-by: Marek Szyprowski 
Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 25 +
 include/drm/bridge/samsung-dsim.h |  5 +++--
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index c3ed317996ad..b6883a6d4681 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1254,12 +1254,17 @@ static void samsung_dsim_disable_irq(struct 
samsung_dsim *dsi)
disable_irq(dsi->irq);
 }
 
-static int samsung_dsim_init(struct samsung_dsim *dsi)
+static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int flag)
 {
const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
 
+   if (dsi->state & flag)
+   return 0;
+
samsung_dsim_reset(dsi);
-   samsung_dsim_enable_irq(dsi);
+
+   if (!(dsi->state & DSIM_STATE_INITIALIZED))
+   samsung_dsim_enable_irq(dsi);
 
if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
@@ -1270,6 +1275,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
samsung_dsim_set_phy_ctrl(dsi);
samsung_dsim_init_link(dsi);
 
+   dsi->state |= flag;
+
return 0;
 }
 
@@ -1289,6 +1296,10 @@ static void samsung_dsim_atomic_pre_enable(struct 
drm_bridge *bridge,
}
 
dsi->state |= DSIM_STATE_ENABLED;
+
+   ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
+   if (ret)
+   return;
 }
 
 static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
@@ -1464,12 +1475,9 @@ static ssize_t samsung_dsim_host_transfer(struct 
mipi_dsi_host *host,
if (!(dsi->state & DSIM_STATE_ENABLED))
return -EINVAL;
 
-   if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
-   ret = samsung_dsim_init(dsi);
-   if (ret)
-   return ret;
-   dsi->state |= DSIM_STATE_INITIALIZED;
-   }
+   ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
+   if (ret)
+   return ret;
 
ret = mipi_dsi_create_packet(, msg);
if (ret < 0)
@@ -1654,6 +1662,7 @@ static int __maybe_unused samsung_dsim_suspend(struct 
device *dev)
 
if (dsi->state & DSIM_STATE_INITIALIZED) {
dsi->state &= ~DSIM_STATE_INITIALIZED;
+   dsi->state &= ~DSIM_STATE_REINITIALIZED;
 
samsung_dsim_disable_clock(dsi);
 
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index 97fdee5ef5df..e15fbfd49efe 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -17,8 +17,9 @@ struct samsung_dsim;
 
 #define DSIM_STATE_ENABLED BIT(0)
 #define DSIM_STATE_INITIALIZED BIT(1)
-#define DSIM_STATE_CMD_LPM BIT(2)
-#define DSIM_STATE_VIDOUT_AVAILABLEBIT(3)
+#define DSIM_STATE_REINITIALIZED   BIT(2)
+#define DSIM_STATE_CMD_LPM BIT(3)
+#define DSIM_STATE_VIDOUT_AVAILABLEBIT(4)
 
 struct samsung_dsim_transfer {
struct list_head list;
-- 
2.25.1

[PATCH v4 08/12] drm: bridge: samsung-dsim: Add atomic_check

[Jagan Teki]

Explicit fixing up of mode_flags is required for DSIM present
in i.MX8M SoC.

At least the LCDIF + DSIM needs active low sync polarities in
order to correlate the correct sync flags of the surrounding
components in the chain to make sure the whole pipeline can
work properly.

So, add DSIM_QUIRK_FIXUP_SYNC_POL to handle this fixup via bridge
atomic_check.

v4:
* none

v3:
* add DSIM_QUIRK_FIXUP_SYNC_POL to handle mode_flasg fixup

v2:
* none

v1:
* fix mode flags in atomic_check instead of mode_fixup

Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 18 ++
 include/drm/bridge/samsung-dsim.h |  1 +
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index b6d17c0c9e58..724fd76435c6 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1341,6 +1341,23 @@ static void samsung_dsim_atomic_post_disable(struct 
drm_bridge *bridge,
pm_runtime_put_sync(dsi->dev);
 }
 
+static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+   struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+   struct drm_display_mode *adjusted_mode = _state->adjusted_mode;
+
+   if (dsi->driver_data->quirks & DSIM_QUIRK_FIXUP_SYNC_POL) {
+   /* At least LCDIF + DSIM needs active low sync */
+   adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | 
DRM_MODE_FLAG_NVSYNC);
+   adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | 
DRM_MODE_FLAG_PVSYNC);
+   }
+
+   return 0;
+}
+
 static void samsung_dsim_mode_set(struct drm_bridge *bridge,
  const struct drm_display_mode *mode,
  const struct drm_display_mode *adjusted_mode)
@@ -1363,6 +1380,7 @@ static const struct drm_bridge_funcs 
samsung_dsim_bridge_funcs = {
.atomic_duplicate_state = 
drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state   = 
drm_atomic_helper_bridge_destroy_state,
.atomic_reset   = drm_atomic_helper_bridge_reset,
+   .atomic_check   = samsung_dsim_atomic_check,
.atomic_pre_enable  = samsung_dsim_atomic_pre_enable,
.atomic_enable  = samsung_dsim_atomic_enable,
.atomic_disable = samsung_dsim_atomic_disable,
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index 95d3f89aec4f..62e1078f43cc 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -36,6 +36,7 @@ struct samsung_dsim_transfer {
 
 enum samsung_dsim_quirks {
DSIM_QUIRK_PLAT_DATA= BIT(0),
+   DSIM_QUIRK_FIXUP_SYNC_POL   = BIT(1),
 };
 
 struct samsung_dsim_driver_data {
-- 
2.25.1

[PATCH v4 11/12] dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8MM SoC.

Add dt-bingings for it.

v4:
* none

v3:
* collect Rob Acked-by

v2:
* updated comments

v1:
* new patch

Acked-by: Rob Herring 
Signed-off-by: Jagan Teki 
---
 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index be377786e8cd..8efcf4728e0b 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -7,6 +7,7 @@ Required properties:
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs 
*/
"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
+   "fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1

[PATCH v4 05/12] drm: bridge: samsung-dsim: Mark PHY as optional

[Jagan Teki]

In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.

So, mark the phy get as optional.

v4, v3, v2:
* none

v1:
* new patch

Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 76dc7687857a..c3ed317996ad 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1583,7 +1583,7 @@ static int samsung_dsim_probe(struct platform_device 
*pdev)
if (IS_ERR(dsi->reg_base))
return PTR_ERR(dsi->reg_base);
 
-   dsi->phy = devm_phy_get(dev, "dsim");
+   dsi->phy = devm_phy_optional_get(dev, "dsim");
if (IS_ERR(dsi->phy)) {
dev_info(dev, "failed to get dsim phy\n");
return PTR_ERR(dsi->phy);
-- 
2.25.1

[PATCH v4 09/12] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
default RGB888_1X24 bus format on DSI-end.

This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component closer to pipeline
components.

v4:
* none

v3:
* include media-bus-format.h

v2:
* none

v1:
* new patch

Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 28 +++
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 724fd76435c6..871cc8cc5352 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1341,6 +1342,32 @@ static void samsung_dsim_atomic_post_disable(struct 
drm_bridge *bridge,
pm_runtime_put_sync(dsi->dev);
 }
 
+#define MAX_INPUT_SEL_FORMATS  1
+
+static u32 *
+samsung_dsim_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+  struct drm_bridge_state *bridge_state,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state,
+  u32 output_fmt,
+  unsigned int *num_input_fmts)
+{
+   u32 *input_fmts;
+
+   *num_input_fmts = 0;
+
+   input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+   if (!input_fmts)
+   return NULL;
+
+   /* This is the DSI-end bus format */
+   input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+   *num_input_fmts = 1;
+
+   return input_fmts;
+}
+
 static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
 struct drm_bridge_state *bridge_state,
 struct drm_crtc_state *crtc_state,
@@ -1380,6 +1407,7 @@ static const struct drm_bridge_funcs 
samsung_dsim_bridge_funcs = {
.atomic_duplicate_state = 
drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state   = 
drm_atomic_helper_bridge_destroy_state,
.atomic_reset   = drm_atomic_helper_bridge_reset,
+   .atomic_get_input_bus_fmts  = 
samsung_dsim_atomic_get_input_bus_fmts,
.atomic_check   = samsung_dsim_atomic_check,
.atomic_pre_enable  = samsung_dsim_atomic_pre_enable,
.atomic_enable  = samsung_dsim_atomic_enable,
-- 
2.25.1

[PATCH v4 07/12] drm: bridge: samsung-dsim: Fix PLL_P (PMS_P) offset

[Jagan Teki]

The i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020
with 13.7.10.1 Master PLL PMS Value setting Register mentioned PMS_P offset
range from BIT[18-13] and the upstream driver is using the same offset.

However, offset 13 is not working on i.MX8M Mini platforms but downstream
NXP driver is using 14 [1] and it is working with i.MX8M Mini SoC.

Not sure about whether it is reference manual documentation or something
else but this patch trusts the downstream code and fixes the PLL_P offset.

[1] 
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n211

v4, v3, v2:
* none

v1:
* updated commit message
* add downstream driver link

Signed-off-by: Frieder Schrempf 
Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 10 --
 include/drm/bridge/samsung-dsim.h |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index b6883a6d4681..b6d17c0c9e58 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -168,7 +168,7 @@
 /* DSIM_PLLCTRL */
 #define DSIM_FREQ_BAND(x)  ((x) << 24)
 #define DSIM_PLL_EN(1 << 23)
-#define DSIM_PLL_P(x)  ((x) << 13)
+#define DSIM_PLL_P(x, offset)  ((x) << (offset))
 #define DSIM_PLL_M(x)  ((x) << 4)
 #define DSIM_PLL_S(x)  ((x) << 1)
 
@@ -368,6 +368,7 @@ static const struct samsung_dsim_driver_data 
exynos3_dsi_driver_data = {
.max_freq = 1000,
.wait_for_reset = 1,
.num_bits_resol = 11,
+   .pll_p_offset = 13,
.reg_values = reg_values,
.quirks = DSIM_QUIRK_PLAT_DATA,
 };
@@ -381,6 +382,7 @@ static const struct samsung_dsim_driver_data 
exynos4_dsi_driver_data = {
.max_freq = 1000,
.wait_for_reset = 1,
.num_bits_resol = 11,
+   .pll_p_offset = 13,
.reg_values = reg_values,
.quirks = DSIM_QUIRK_PLAT_DATA,
 };
@@ -392,6 +394,7 @@ static const struct samsung_dsim_driver_data 
exynos5_dsi_driver_data = {
.max_freq = 1000,
.wait_for_reset = 1,
.num_bits_resol = 11,
+   .pll_p_offset = 13,
.reg_values = reg_values,
.quirks = DSIM_QUIRK_PLAT_DATA,
 };
@@ -404,6 +407,7 @@ static const struct samsung_dsim_driver_data 
exynos5433_dsi_driver_data = {
.max_freq = 1500,
.wait_for_reset = 0,
.num_bits_resol = 12,
+   .pll_p_offset = 13,
.reg_values = exynos5433_reg_values,
.quirks = DSIM_QUIRK_PLAT_DATA,
 };
@@ -416,6 +420,7 @@ static const struct samsung_dsim_driver_data 
exynos5422_dsi_driver_data = {
.max_freq = 1500,
.wait_for_reset = 1,
.num_bits_resol = 12,
+   .pll_p_offset = 13,
.reg_values = exynos5422_reg_values,
.quirks = DSIM_QUIRK_PLAT_DATA,
 };
@@ -563,7 +568,8 @@ static unsigned long samsung_dsim_set_pll(struct 
samsung_dsim *dsi,
writel(driver_data->reg_values[PLL_TIMER],
dsi->reg_base + driver_data->plltmr_reg);
 
-   reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+   reg = DSIM_PLL_EN | DSIM_PLL_P(p, driver_data->pll_p_offset) |
+ DSIM_PLL_M(m) | DSIM_PLL_S(s);
 
if (driver_data->has_freqband) {
static const unsigned long freq_bands[] = {
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index e15fbfd49efe..95d3f89aec4f 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -47,6 +47,7 @@ struct samsung_dsim_driver_data {
unsigned int max_freq;
unsigned int wait_for_reset;
unsigned int num_bits_resol;
+   unsigned int pll_p_offset;
const unsigned int *reg_values;
enum samsung_dsim_quirks quirks;
 };
-- 
2.25.1

[PATCH v4 04/12] drm: bridge: samsung-dsim: Handle platform init via driver_data

[Jagan Teki]

In order to make a common Samsung DSIM bridge driver some platform
specific glue code needs to maintain separately as it is hard to
maintain platform specific glue and conventional component_ops on
the drm bridge drivers side.

This patch is trying to support that glue code initialization based
on the DSIM_QUIRK_PLAT_DATA set from respective driver_data.

So, the platforms which enable DSIM_QUIRK_PLAT_DATA flags will handle
all platform specific initialization via samsung_dsim_plat_probe.

The platform probe is responsible to
- initialize samsung_dsim_plat_data and install hooks
- initialize component_ops
- preserve samsung_dsim structure pointer

v4:
* none

v3:
* update samsung_dsim_plat_probe return value
* add plat_data quirk to handle platform init

v2:
* fix samsung_dsim_plat_probe return pointer

v1:
* use platform_init instead of exynos_specific
* handle component_ops in glue code

Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 16 ++--
 include/drm/bridge/samsung-dsim.h |  5 +
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 8130845750ac..76dc7687857a 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -369,6 +369,7 @@ static const struct samsung_dsim_driver_data 
exynos3_dsi_driver_data = {
.wait_for_reset = 1,
.num_bits_resol = 11,
.reg_values = reg_values,
+   .quirks = DSIM_QUIRK_PLAT_DATA,
 };
 
 static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
@@ -381,6 +382,7 @@ static const struct samsung_dsim_driver_data 
exynos4_dsi_driver_data = {
.wait_for_reset = 1,
.num_bits_resol = 11,
.reg_values = reg_values,
+   .quirks = DSIM_QUIRK_PLAT_DATA,
 };
 
 static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
@@ -391,6 +393,7 @@ static const struct samsung_dsim_driver_data 
exynos5_dsi_driver_data = {
.wait_for_reset = 1,
.num_bits_resol = 11,
.reg_values = reg_values,
+   .quirks = DSIM_QUIRK_PLAT_DATA,
 };
 
 static const struct samsung_dsim_driver_data exynos5433_dsi_driver_data = {
@@ -402,6 +405,7 @@ static const struct samsung_dsim_driver_data 
exynos5433_dsi_driver_data = {
.wait_for_reset = 0,
.num_bits_resol = 12,
.reg_values = exynos5433_reg_values,
+   .quirks = DSIM_QUIRK_PLAT_DATA,
 };
 
 static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
@@ -413,6 +417,7 @@ static const struct samsung_dsim_driver_data 
exynos5422_dsi_driver_data = {
.wait_for_reset = 1,
.num_bits_resol = 12,
.reg_values = exynos5422_reg_values,
+   .quirks = DSIM_QUIRK_PLAT_DATA,
 };
 
 static const struct of_device_id samsung_dsim_of_match[] = {
@@ -1609,7 +1614,11 @@ static int samsung_dsim_probe(struct platform_device 
*pdev)
dsi->bridge.of_node = dev->of_node;
dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
 
-   ret = samsung_dsim_plat_probe(dsi);
+   if (dsi->driver_data->quirks & DSIM_QUIRK_PLAT_DATA)
+   ret = samsung_dsim_plat_probe(dsi);
+   else
+   ret = mipi_dsi_host_register(>dsi_host);
+
if (ret)
goto err_disable_runtime;
 
@@ -1627,7 +1636,10 @@ static int samsung_dsim_remove(struct platform_device 
*pdev)
 
pm_runtime_disable(>dev);
 
-   samsung_dsim_plat_remove(dsi);
+   if (dsi->driver_data->quirks & DSIM_QUIRK_PLAT_DATA)
+   samsung_dsim_plat_remove(dsi);
+   else
+   mipi_dsi_host_unregister(>dsi_host);
 
return 0;
 }
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index 2e245bffd1b6..97fdee5ef5df 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -33,6 +33,10 @@ struct samsung_dsim_transfer {
u16 rx_done;
 };
 
+enum samsung_dsim_quirks {
+   DSIM_QUIRK_PLAT_DATA= BIT(0),
+};
+
 struct samsung_dsim_driver_data {
const unsigned int *reg_ofs;
unsigned int plltmr_reg;
@@ -43,6 +47,7 @@ struct samsung_dsim_driver_data {
unsigned int wait_for_reset;
unsigned int num_bits_resol;
const unsigned int *reg_values;
+   enum samsung_dsim_quirks quirks;
 };
 
 struct samsung_dsim_host_ops {
-- 
2.25.1

[PATCH v4 00/12] drm: bridge: Add Samsung MIPI DSIM bridge

[Jagan Teki]

This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.

Previous v2 can be available here [1].

The final bridge supports both the Exynos and i.MX8MM DSI devices.

On, summary this patch-set break the entire DSIM driver into
- platform specific glue code for platform ops, component_ops.
- common bridge driver which handle platform glue init and invoke.

Changes for v3:
* fix the mult-arch build
* fix dsi host init
* updated commit messages

Changes for v2:
* fix bridge handling
* fix dsi host init
* correct the commit messages

Patch 0001: Restore proper bridge chain in exynos_dsi

Patch 0002: Samsung DSIM bridge

Patch 0003: Common lookup code for OF-graph or child

Patch 0004: plat_data quirk flag via driver_data

Patch 0005/10:  bridge fixes, atomic API's

Patch 0011: document fsl,imx8mm-mipi-dsim

Patch 0012: add i.MX8MM DSIM support

Tested in Engicam i.Core MX8M Mini SoM.

Anyone interested, please have a look on this repo [2] and 
boot log [3].

[3] https://gist.github.com/openedev/22b2d63b30ade0ba55ab414a2f47aaf0
[2] https://github.com/openedev/kernel/tree/imx8mm-dsi-v4
[1] 
https://patchwork.kernel.org/project/dri-devel/cover/20220720155210.365977-1-ja...@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (11):
  drm: bridge: Add Samsung DSIM bridge driver
  drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices
  drm: bridge: samsung-dsim: Handle platform init via driver_data
  drm: bridge: samsung-dsim: Mark PHY as optional
  drm: bridge: samsung-dsim: Handle proper DSI host initialization
  drm: bridge: samsung-dsim: Fix PLL_P (PMS_P) offset
  drm: bridge: samsung-dsim: Add atomic_check
  drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts
  drm: bridge: samsung-dsim: Add input_bus_flags
  dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support
  drm: bridge: samsung-dsim: Add i.MX8MM support

Marek Szyprowski (1):
  drm: exynos: dsi: Restore proper bridge chain order

 .../bindings/display/exynos/exynos_dsim.txt   |1 +
 MAINTAINERS   |9 +
 drivers/gpu/drm/bridge/Kconfig|   12 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/samsung-dsim.c | 1833 +
 drivers/gpu/drm/exynos/Kconfig|1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |3 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |1 -
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 1717 +--
 include/drm/bridge/samsung-dsim.h |  107 +
 10 files changed, 2027 insertions(+), 1658 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.25.1

[PATCH v4 03/12] drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices

[Jagan Teki]

The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.

The OF-graph interface represents the child devices via
remote and associated endpoint numbers like

dsi {
   compatible = "fsl,imx8mm-mipi-dsim";

   ports {
port@0 {
 reg = <0>;

 dsi_in_lcdif: endpoint@0 {
  reg = <0>;
  remote-endpoint = <_out_dsi>;
 };
};

port@1 {
 reg = <1>;

 dsi_out_bridge: endpoint {
  remote-endpoint = <_in_dsi>;
 };
};
};

The child node interface represents the child devices via
conventional child nodes on given DSI parent like

dsi {
   compatible = "samsung,exynos5433-mipi-dsi";

   ports {
port@0 {
 reg = <0>;

 dsi_to_mic: endpoint {
  remote-endpoint = <_to_dsi>;
 };
};
   };

   panel@0 {
reg = <0>;
   };
};

As Samsung DSIM bridge is common DSI IP across all Exynos DSI
and NXP i.MX8M host controllers, this patch adds support to
lookup the child devices whether its bindings on the associated
host represent OF-graph or child node interfaces.

v4, v3:
* none

v2:
* new patch

Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 38 +--
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index ab2fa0f42f40..8130845750ac 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1357,18 +1357,52 @@ static int samsung_dsim_host_attach(struct 
mipi_dsi_host *host,
struct samsung_dsim *dsi = host_to_dsi(host);
const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
struct device *dev = dsi->dev;
+   struct device_node *np = dev->of_node;
+   struct device_node *remote;
struct drm_panel *panel;
int ret;
 
-   panel = of_drm_find_panel(device->dev.of_node);
+   /**
+* Devices can also be child nodes when we also control that device
+* through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
+*
+* Lookup for a child node of the given parent that isn't either port
+* or ports.
+*/
+   for_each_available_child_of_node(np, remote) {
+   if (of_node_name_eq(remote, "port") ||
+   of_node_name_eq(remote, "ports"))
+   continue;
+
+   goto of_find_panel_or_bridge;
+   }
+
+   /*
+* of_graph_get_remote_node() produces a noisy error message if port
+* node isn't found and the absence of the port is a legit case here,
+* so at first we silently check whether graph presents in the
+* device-tree node.
+*/
+   if (!of_graph_is_present(np))
+   return -ENODEV;
+
+   remote = of_graph_get_remote_node(np, 1, 0);
+
+of_find_panel_or_bridge:
+   if (!remote)
+   return -ENODEV;
+
+   panel = of_drm_find_panel(remote);
if (!IS_ERR(panel)) {
dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
} else {
-   dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
+   dsi->out_bridge = of_drm_find_bridge(remote);
if (!dsi->out_bridge)
dsi->out_bridge = ERR_PTR(-EINVAL);
}
 
+   of_node_put(remote);
+
if (IS_ERR(dsi->out_bridge)) {
ret = PTR_ERR(dsi->out_bridge);
DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
-- 
2.25.1

[PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver

[Jagan Teki]

Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.

In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.

This patch is trying to differentiate platform-specific and bridge driver
code and keep maintaining the exynos_drm_dsi.c code as platform-specific
glue code and samsung-dsim.c as a common bridge driver code.

- Exynos specific glue code is exynos specific te_irq, host_attach, and
  detach code along with conventional component_ops.

- Samsung DSIM is a bridge driver which is common across all platforms and
  the respective platform-specific glue will initialize at the end of the
  probe. The platform-specific operations and other glue calls will invoke
  on associate code areas.

v4:
* include Inki Dae in MAINTAINERS
* remove dsi_driver probe in exynos_drm_drv to support multi-arch build

v3:
* restore gpio related fixes
* restore proper bridge chain
* rework initialization issue
* fix header includes in proper way

v2:
* fixed exynos dsi driver conversion (Marek Szyprowski)
* updated commit message
* updated MAINTAINERS file

v1:
* don't maintain component_ops in bridge driver
* don't maintain platform glue code in bridge driver
* add platform-specific glue code and make a common bridge

Signed-off-by: Marek Szyprowski 
Signed-off-by: Jagan Teki 
---
 MAINTAINERS |9 +
 drivers/gpu/drm/bridge/Kconfig  |   12 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/samsung-dsim.c   | 1686 ++
 drivers/gpu/drm/exynos/Kconfig  |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |3 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1715 +--
 include/drm/bridge/samsung-dsim.h   |   99 ++
 9 files changed, 1868 insertions(+), 1659 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 589517372408..301478f70b41 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6624,6 +6624,15 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml
 F: drivers/gpu/drm/panel/panel-samsung-db7430.c
 
+DRM DRIVER FOR SAMSUNG MIPI DSIM BRIDGE
+M: Jagan Teki 
+M: Marek Szyprowski 
+M: Inki Dae 
 S: Maintained
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 57946d80b02d..8e85dac9f53e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -231,6 +231,18 @@ config DRM_PARADE_PS8640
  The PS8640 is a high-performance and low-power
  MIPI DSI to eDP converter
 
+config DRM_SAMSUNG_DSIM
+   tristate "Samsung MIPI DSIM bridge driver"
+   depends on COMMON_CLK
+   depends on OF && HAS_IOMEM
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL_BRIDGE
+   help
+ The Samsung MIPI DSIM bridge controller driver.
+ This MIPI DSIM bridge can be found it on Exynos SoCs and
+ NXP's i.MX8M Mini/Nano.
+
 config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 1884803c6860..dae843723991 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
+obj-$(CONFIG_DRM_SAMSUNG_DSIM) += samsung-dsim.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
new file mode 100644
index ..ab2fa0f42f40
--- /dev/null
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -0,0 +1,1686 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Samsung MIPI DSIM bridge driver.
+ *
+ * Copyright (C) 2021 Amarula Solutions(India)
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Author: Jagan Teki 
+ *
+ * Based on exynos_drm_dsi from
+ * Tomasz Figa 
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+/* returns true iff both arguments logically differs */
+#define NEQV(a, b) (!(a) ^ !(b))
+
+/* DSIM_STATUS */
+#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
+#define DSIM_STOP_STATE_CLK(1 << 8)
+#define DSIM_TX_READY_HS_CLK   (1 << 10)
+#define DSIM_PLL_STABLE(1 << 31)
+
+/* DSIM_SWRST */
+#define DSIM_FUNCRST   

[PATCH v4 01/12] drm: exynos: dsi: Restore proper bridge chain order

[Jagan Teki]

From: Marek Szyprowski 

Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.

This establishes a proper bridge chain while attaching downstream
bridges.

v4:
* none

v3:
* new patch

Signed-off-by: Marek Szyprowski 
Signed-off-by: Jagan Teki 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index ec673223d6b7..e5b1540c4ae4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1428,7 +1428,8 @@ static int exynos_dsi_attach(struct drm_bridge *bridge,
 {
struct exynos_dsi *dsi = bridge_to_dsi(bridge);
 
-   return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, flags);
+   return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge,
+flags);
 }
 
 static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
@@ -1474,7 +1475,10 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host 
*host,
 
drm_bridge_add(>bridge);
 
-   drm_bridge_attach(encoder, >bridge, NULL, 0);
+   drm_bridge_attach(encoder, >bridge,
+ list_first_entry_or_null(>bridge_chain,
+  struct drm_bridge,
+  chain_node), 0);
 
/*
 * This is a temporary solution and should be made by more generic way.
-- 
2.25.1

Re: [RFC] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge

[Abhinav Kumar]

Hi Laurent

On 8/26/2022 4:55 AM, Laurent Pinchart wrote:

Hello,

On Fri, Aug 26, 2022 at 01:17:43PM +0300, Dmitry Baryshkov wrote:

On 22/08/2022 19:31, Dmitry Baryshkov wrote:

On 09/08/2022 22:40, Laurent Pinchart wrote:

On Mon, Aug 08, 2022 at 05:35:30PM -0700, Abhinav Kumar wrote:

adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.

This approach is incorrect because as per the DSI spec the
number of lanes is fixed at the time of system design or initial
configuration and may not change dynamically.


Is that really so ? The number of lanes connected on the board is
certainlyset at design time, but a lower number of lanes can be used at
runtime. It shouldn't change dynamically while the display is on, but it
could change at mode set time.


I'm not sure if I interpreted the standard correctly, but I tended to
have the same interpretation as Abhinav did.

Anyway, even if we allow the drivers to switch the amount of lanes, this
should not happen in the form of detach()/attach() cycle. The drivers


Agreed.


use mipi_dsi_attach() as way to signal the DSI hosts that the sink
device is ready. Some of DSI hosts (including MSM one) would bind
components from the attach callback.

If we were to support dynamically changing the amount of lanes, I would
ask for additional mipi_dsi API call telling the host to switch the
amount of lanes. And note that this can open the can of worms. Different
hosts might have different requirements here. For example for the MSM
platform the amount of lanes is programmed during bridge_pre_enable
chain call, so it is possible to just set the amount of lanes following
the msm_dsi_device::lanes. Other hosts might have other requirements.


Conceptually, I would expect the number of effective lanes to be
selected at mode set time, because it has to be done while the output is
disabled. With the atomic API for bridges the .mode_set() operation is
deprecated, so .pre_enable() sounds best, but there's a potential issue:
the .pre_enable() operation is called from sink to source. It means that
a DSI sink .pre_enable() operation would need to call a DSI host
operation to set (or maybe negotiate instead of just setting a fixed
value) the number of lanes first if it wants to control the sink through
DCS at .pre_enable() time. We'd have to see how that fits.


Thus said I'd suggest accepting this patch and maybe working on the
API/support for the lane switching as a followup.


I don't have a personal need for the ADV7533 so I won't really complain
about any potential regression this may introduce (given that it fixes a
deadlock maybe things are completely broken already and nothing can
regress). I'd like to see this fixed though, doing it as a follow up is
too often a way to avoid doing it at all :-)

In any case, the commit message should be reworded to explain the
rationale and what needs to be done. Adding a TODO or FIXME comment in
the code would also help.



Yes, I have added a TODO in the code . fixed the commit text and posted 
this removing the RFC tag to address this deadlock issue.


Thanks

Abhinav


Laurent, gracious ping for your response.


Done :-)


In addition this method of dynamic switch of detaching and
attaching the mipi dsi device also results in removing
and adding the component which is not necessary.


Yes, that doesn't look good, and the .mode_valid() operation is
definitely not the right point where to set the number of lanes.


.mode_set()?


This approach is also prone to deadlocks. So for example, on the
db410c whenever this path is executed with lockdep enabled,
this results in a deadlock due to below ordering of locks.


Even without the deadlock, we are pulling the whole DRM device from
beneath the DSI panel by unbinding all the components. This is not going
to work correctly.



-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
  lock_acquire+0x6c/0x90
  drm_modeset_acquire_init+0xf4/0x150
  drmm_mode_config_init+0x220/0x770
  msm_drm_bind+0x13c/0x654
  try_to_bring_up_aggregate_device+0x164/0x1d0
  __component_add+0xa8/0x174
  component_add+0x18/0x2c
  dsi_dev_attach+0x24/0x30
  dsi_host_attach+0x98/0x14c
  devm_mipi_dsi_attach+0x38/0xb0
  adv7533_attach_dsi+0x8c/0x110
  adv7511_probe+0x5a0/0x930
  i2c_device_probe+0x30c/0x350
  really_probe.part.0+0x9c/0x2b0
  __driver_probe_device+0x98/0x144
  driver_probe_device+0xac/0x14c
  __device_attach_driver+0xbc/0x124
  bus_for_each_drv+0x78/0xd0
  __device_attach+0xa8/0x1c0
  device_initial_probe+0x18/0x24
  bus_probe_device+0xa0/0xac
  deferred_probe_work_func+0x90/0xd0
  process_one_work+0x28c/0x6b0
  worker_thread+0x240/0x444
  kthread+0x110/0x114
  ret_from_fork+0x10/0x20

-> #0 (component_mutex){+.+.}-{3:3}:
  

Re: [PATCH v3 06/13] drm: bridge: samsung-dsim: Add DSI init in bridge pre_enable()

[Jagan Teki]

Hi Dave,

On Fri, Jul 22, 2022 at 9:35 PM Dave Stevenson
 wrote:
>
> Hi Jagan and Marek.
>
> On Fri, 22 Jul 2022 at 16:35, Marek Szyprowski  
> wrote:
> >
> > On 20.07.2022 17:52, Jagan Teki wrote:
> > > Host transfer() in DSI master will invoke only when the DSI commands
> > > are sent from DSI devices like DSI Panel or DSI bridges and this
> > > host transfer wouldn't invoke for I2C-based-DSI bridge drivers.
> > >
> > > Handling DSI host initialization in transfer calls misses the
> > > controller setup for I2C configured DSI bridges.
> > >
> > > This patch adds the DSI initialization from transfer to bridge
> > > pre_enable as the bridge pre_enable API is invoked by core as
> > > it is common across all classes of DSI device drivers.
> >
> > This is still problematic in case of Exynos. Without a workaround like this
> >
> > https://github.com/mszyprow/linux/commit/11bbfc61272da9610dd5c574bb8ef838dc150961
> >
> > the display on the all real DSI panels on my Exynos based boards is broken.
>
> I'd queried on the other thread trying to address DSI operation [1] as
> to whether the test for STOP_STATE (presumably LP-11) at [2] was
> actually valid, but had no response.
> There is no need to check for bus contention at that point, but should
> it happen the driver doesn't write the registers in lines 862-868
> having returned -EFAULT at line 853. The controller is therefore only
> partially initialised.

Can you link me if you have any updated series on this? or the
existing one is the latest one itself?

Thanks,
Jagan.

Re: [PATCH v6 2/2] drm: rcar-du: Add RZ/G2L DSI driver

[Laurent Pinchart]

Hi Biju,

Thank you for the patch.

On Mon, Aug 29, 2022 at 10:19:01AM +0100, Biju Das wrote:
> This driver supports the MIPI DSI encoder found in the RZ/G2L
> SoC. It currently supports DSI video mode only.
> 
> Signed-off-by: Biju Das 
> Acked-by: Sam Ravnborg 
> ---
> v5->v6:
>  * Updated commit description
>  * Moved handling of arst and prst from rzg2l_mipi_dsi_startup->runtime
>PM suspend/resume handlers.
>  * Max lane capability read at probe(), and enforced in
>rzg2l_mipi_dsi_host_attach()
>  * Simplified vich1ppsetr setting.
>  * Renamed hsclk_running_mode,hsclk_mode->is_clk_cont.
>  * Fixed typo in probe error message(arst->rst).
>  * Reordered DRM bridge initaization in probe()
>  * Updated typo in e-mail address.
> v4->v5:
>  * Added Ack from Sam.
>  * Added a trivial change, replaced rzg2l_mipi_dsi_parse_dt()
>with drm_of_get_data_lanes_count_ep() in probe.
> v3->v4:
>  * Updated error handling in rzg2l_mipi_dsi_startup() and 
> rzg2l_mipi_dsi_atomic_enable()
> v2->v3:
>  * pass rzg2l_mipi_dsi pointer to {Link,Phy} register rd/wr function instead
>of the memory pointer
>  * Fixed the comment in rzg2l_mipi_dsi_startup()
>  * Removed unnecessary dbg message from rzg2l_mipi_dsi_start_video()
>  * DRM bridge parameter initialization moved to probe
>  * Replaced dev_dbg->dev_err in rzg2l_mipi_dsi_parse_dt()
>  * Inserted the missing blank lane after return in probe()
>  * Added missing MODULE_DEVICE_TABLE
>  * Added include linux/bits.h in header file
>  * Fixed various macros in header file.
>  * Reorder the make file for DSI, so that it is no more dependent
>on RZ/G2L DU patch series.
> v1->v2:
>  * Rework based on dt-binding change (DSI + D-PHY) as single block
>  * Replaced link_mmio and phy_mmio with mmio in struct rzg2l_mipi_dsi
>  * Replaced rzg2l_mipi_phy_write with rzg2l_mipi_dsi_phy_write
>and rzg2l_mipi_dsi_link_write
>  * Replaced rzg2l_mipi_phy_read->rzg2l_mipi_dsi_link_read
> RFC->v1:
>  * Added "depends on ARCH_RENESAS || COMPILE_TEST" on KCONFIG
>and dropped DRM as it is implied by DRM_BRIDGE
>  * Used devm_reset_control_get_exclusive() for reset handle
>  * Removed bool hsclkmode from struct rzg2l_mipi_dsi
>  * Added error check for pm, using pm_runtime_resume_and_get() instead of
>pm_runtime_get_sync()
>  * Added check for unsupported formats in rzg2l_mipi_dsi_host_attach()
>  * Avoided read-modify-write stopping hsclock
>  * Used devm_platform_ioremap_resource for resource allocation
>  * Removed unnecessary assert call from probe and remove.
>  * wrap the line after the PTR_ERR() in probe()
>  * Updated reset failure messages in probe
>  * Fixed the typo arstc->prstc
>  * Made hex constants to lower case.
> RFC:
>  * 
> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-23-biju.das...@bp.renesas.com/
> ---
>  drivers/gpu/drm/rcar-du/Kconfig   |   8 +
>  drivers/gpu/drm/rcar-du/Makefile  |   2 +
>  drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c  | 703 ++
>  drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 151 
>  4 files changed, 864 insertions(+)
>  create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
>  create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index c959e8c6be7d..58ffb8c2443b 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -51,6 +51,14 @@ config DRM_RCAR_MIPI_DSI
>   help
> Enable support for the R-Car Display Unit embedded MIPI DSI encoders.
>  
> +config DRM_RZG2L_MIPI_DSI
> + tristate "RZ/G2L MIPI DSI Encoder Support"
> + depends on DRM_BRIDGE && OF
> + depends on ARCH_RENESAS || COMPILE_TEST
> + select DRM_MIPI_DSI
> + help
> +   Enable support for the RZ/G2L Display Unit embedded MIPI DSI encoders.
> +
>  config DRM_RCAR_VSP
>   bool "R-Car DU VSP Compositor Support" if ARM
>   default y if ARM64
> diff --git a/drivers/gpu/drm/rcar-du/Makefile 
> b/drivers/gpu/drm/rcar-du/Makefile
> index 6f132325c8b7..b8f2c82651d9 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -14,3 +14,5 @@ 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_RZG2L_MIPI_DSI) += rzg2l_mipi_dsi.o
> diff --git a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c 
> b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> new file mode 100644
> index ..46a71e39e336
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> @@ -0,0 +1,703 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * RZ/G2L MIPI DSI Encoder Driver
> + *
> + * Copyright (C) 2022 Renesas Electronics Corporation
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> 

[PATCH] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge

[Abhinav Kumar]

adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.

This approach is incorrect because this method of dynamic switch of
detaching and attaching the mipi dsi device also results in removing
and adding the component which is not necessary.

This approach is also prone to deadlocks. So for example, on the
db410c whenever this path is executed with lockdep enabled,
this results in a deadlock due to below ordering of locks.

-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
lock_acquire+0x6c/0x90
drm_modeset_acquire_init+0xf4/0x150
drmm_mode_config_init+0x220/0x770
msm_drm_bind+0x13c/0x654
try_to_bring_up_aggregate_device+0x164/0x1d0
__component_add+0xa8/0x174
component_add+0x18/0x2c
dsi_dev_attach+0x24/0x30
dsi_host_attach+0x98/0x14c
devm_mipi_dsi_attach+0x38/0xb0
adv7533_attach_dsi+0x8c/0x110
adv7511_probe+0x5a0/0x930
i2c_device_probe+0x30c/0x350
really_probe.part.0+0x9c/0x2b0
__driver_probe_device+0x98/0x144
driver_probe_device+0xac/0x14c
__device_attach_driver+0xbc/0x124
bus_for_each_drv+0x78/0xd0
__device_attach+0xa8/0x1c0
device_initial_probe+0x18/0x24
bus_probe_device+0xa0/0xac
deferred_probe_work_func+0x90/0xd0
process_one_work+0x28c/0x6b0
worker_thread+0x240/0x444
kthread+0x110/0x114
ret_from_fork+0x10/0x20

-> #0 (component_mutex){+.+.}-{3:3}:
__lock_acquire+0x1280/0x20ac
lock_acquire.part.0+0xe0/0x230
lock_acquire+0x6c/0x90
__mutex_lock+0x84/0x400
mutex_lock_nested+0x3c/0x70
component_del+0x34/0x170
dsi_dev_detach+0x24/0x30
dsi_host_detach+0x20/0x64
mipi_dsi_detach+0x2c/0x40
adv7533_mode_set+0x64/0x90
adv7511_bridge_mode_set+0x210/0x214
drm_bridge_chain_mode_set+0x5c/0x84
crtc_set_mode+0x18c/0x1dc
drm_atomic_helper_commit_modeset_disables+0x40/0x50
msm_atomic_commit_tail+0x1d0/0x6e0
commit_tail+0xa4/0x180
drm_atomic_helper_commit+0x178/0x3b0
drm_atomic_commit+0xa4/0xe0
drm_client_modeset_commit_atomic+0x228/0x284
drm_client_modeset_commit_locked+0x64/0x1d0
drm_client_modeset_commit+0x34/0x60
drm_fb_helper_lastclose+0x74/0xcc
drm_lastclose+0x3c/0x80
drm_release+0xfc/0x114
__fput+0x70/0x224
fput+0x14/0x20
task_work_run+0x88/0x1a0
do_exit+0x350/0xa50
do_group_exit+0x38/0xa4
__wake_up_parent+0x0/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x60/0x11c
do_el0_svc+0x30/0xc0
el0_svc+0x58/0x100
el0t_64_sync_handler+0x1b0/0x1bc
el0t_64_sync+0x18c/0x190

Due to above reasons, remove the dynamic lane switching
code from adv7533 bridge chip and filter out the modes
which would need different number of lanes as compared
to the initialization time using the mode_valid callback.

This can be potentially re-introduced by using the pre_enable()
callback but this needs to be evaluated first whether such an
approach will work so this will be done with a separate change.

changes since RFC:
- Fix commit text and add TODO comment

Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes 
dynamically")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
Suggested-by: Dmitry Baryshkov 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/bridge/adv7511/adv7511.h |  3 ++-
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 ++
 drivers/gpu/drm/bridge/adv7511/adv7533.c | 25 +
 3 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 9e3bb8a8ee40..0a7cec80b75d 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -417,7 +417,8 @@ static inline int adv7511_cec_init(struct device *dev, 
struct adv7511 *adv7511)
 
 void adv7533_dsi_power_on(struct adv7511 *adv);
 void adv7533_dsi_power_off(struct adv7511 *adv);
-void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode 
*mode);
+enum drm_mode_status adv7533_mode_valid(struct adv7511 *adv,
+   const struct drm_display_mode *mode);
 int adv7533_patch_registers(struct adv7511 *adv);
 int adv7533_patch_cec_registers(struct adv7511 *adv);
 int adv7533_attach_dsi(struct adv7511 *adv);
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 5bb9300040dd..1115ef9be83c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -697,7 +697,7 @@ adv7511_detect(struct adv7511 *adv7511, struct 
drm_connector *connector)
 }
 
 static enum drm_mode_status adv7511_mode_valid(struct 

Re: [PATCH v6 2/2] drm: rcar-du: Add RZ/G2L DSI driver

[Laurent Pinchart]

Hi Biju,

On Mon, Aug 29, 2022 at 04:26:02PM +, Biju Das wrote:
> Hi Robert,
> 
> Thanks for the feedback.
> 
> > Subject: Re: [PATCH v6 2/2] drm: rcar-du: Add RZ/G2L DSI driver
> > 
> > Hey Biju,
> > 
> > The patch does not apply on drm-misc-next, could you rebase it and
> > submit the next version?
> 
> I believe[1] is dependent on this patch series. Sorry for not
> making it clear while sending this patch series out.
> 
> I thought Laurent is going to give a pull request for RCar DU patches.

That's right. The patches apply fine to my branch.

> Based on that assumption, currently my environment is drm-tip + 
> 12 patches from[2], as [2] doesn't have all the latest patches from
> drm-misc-next/drm-tip.
> 
> [1] 
> https://git.linuxtv.org/pinchartl/media.git/commit/drivers/gpu/drm/rcar-du?h=drm/du/next=2de250465c3ed5e13bfb5139d9a8c17105d3a1f1
> 
> [2] 
> https://git.linuxtv.org/pinchartl/media.git/log/drivers/gpu/drm/rcar-du?h=drm/du/next
> 
> > Additionally it has a few 'checkpatch --strict' warnings.
> 
> I got a review comment[3] to use (1 << 1) style instead of BIT macro.
> Some of the warnings related to this.
> 
> [3] 
> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220328065115.11724-1-biju.das...@bp.renesas.com/
> 
> Laurent, any thoughts??

(1 << x) instead of BIT it correct when the field stores a value, not a
single bit flag.

> > On Mon, 29 Aug 2022 at 11:19, Biju Das wrote:
> > >
> > > This driver supports the MIPI DSI encoder found in the RZ/G2L SoC. It
> > > currently supports DSI video mode only.
> > >
> > > Signed-off-by: Biju Das 
> > > Acked-by: Sam Ravnborg 
> > > ---
> > > v5->v6:
> > >  * Updated commit description
> > >  * Moved handling of arst and prst from rzg2l_mipi_dsi_startup-
> > >runtime
> > >PM suspend/resume handlers.
> > >  * Max lane capability read at probe(), and enforced in
> > >rzg2l_mipi_dsi_host_attach()
> > >  * Simplified vich1ppsetr setting.
> > >  * Renamed hsclk_running_mode,hsclk_mode->is_clk_cont.
> > >  * Fixed typo in probe error message(arst->rst).
> > >  * Reordered DRM bridge initaization in probe()
> > >  * Updated typo in e-mail address.
> > > v4->v5:
> > >  * Added Ack from Sam.
> > >  * Added a trivial change, replaced rzg2l_mipi_dsi_parse_dt()
> > >with drm_of_get_data_lanes_count_ep() in probe.
> > > v3->v4:
> > >  * Updated error handling in rzg2l_mipi_dsi_startup() and
> > > rzg2l_mipi_dsi_atomic_enable()
> > > v2->v3:
> > >  * pass rzg2l_mipi_dsi pointer to {Link,Phy} register rd/wr function
> > instead
> > >of the memory pointer
> > >  * Fixed the comment in rzg2l_mipi_dsi_startup()
> > >  * Removed unnecessary dbg message from rzg2l_mipi_dsi_start_video()
> > >  * DRM bridge parameter initialization moved to probe
> > >  * Replaced dev_dbg->dev_err in rzg2l_mipi_dsi_parse_dt()
> > >  * Inserted the missing blank lane after return in probe()
> > >  * Added missing MODULE_DEVICE_TABLE
> > >  * Added include linux/bits.h in header file
> > >  * Fixed various macros in header file.
> > >  * Reorder the make file for DSI, so that it is no more dependent
> > >on RZ/G2L DU patch series.
> > > v1->v2:
> > >  * Rework based on dt-binding change (DSI + D-PHY) as single block
> > >  * Replaced link_mmio and phy_mmio with mmio in struct rzg2l_mipi_dsi
> > >  * Replaced rzg2l_mipi_phy_write with rzg2l_mipi_dsi_phy_write
> > >and rzg2l_mipi_dsi_link_write
> > >  * Replaced rzg2l_mipi_phy_read->rzg2l_mipi_dsi_link_read
> > > RFC->v1:
> > >  * Added "depends on ARCH_RENESAS || COMPILE_TEST" on KCONFIG
> > >and dropped DRM as it is implied by DRM_BRIDGE
> > >  * Used devm_reset_control_get_exclusive() for reset handle
> > >  * Removed bool hsclkmode from struct rzg2l_mipi_dsi
> > >  * Added error check for pm, using pm_runtime_resume_and_get() instead
> > of
> > >pm_runtime_get_sync()
> > >  * Added check for unsupported formats in rzg2l_mipi_dsi_host_attach()
> > >  * Avoided read-modify-write stopping hsclock
> > >  * Used devm_platform_ioremap_resource for resource allocation
> > >  * Removed unnecessary assert call from probe and remove.
> > >  * wrap the line after the PTR_ERR() in probe()
> > >  * Updated reset failure messages in probe
> > >  * Fixed the typo arstc->prstc
> > >  * Made hex constants to lower case.
> > > RFC:
> > >  *
> > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > > hwork.kernel.org%2Fproject%2Flinux-renesas-soc%2Fpatch%2F2022011217461
> > > 2.10773-23-biju.das.jz%40bp.renesas.com%2Fdata=05%7C01%7Cbiju.das
> > > .jz%40bp.renesas.com%7C003e031f5e7f454bdfdf08da89d4d82d%7C53d82571da19
> > > 47e49cb4625a166a4a2a%7C0%7C0%7C637973844501238222%7CUnknown%7CTWFpbGZs
> > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > > %7C3000%7C%7C%7Csdata=uNJMSsB3FHHDBnczS4jLEL8OADLe03K6gksF2aNn31k
> > > %3Dreserved=0
> > > ---
> > >  drivers/gpu/drm/rcar-du/Kconfig   |   8 +
> > >  drivers/gpu/drm/rcar-du/Makefile  |   

[PATCH 1/8] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}

[Matt Roper]

Moving the locking for MMIO debug (and the final check for unclaimed
accesses when resuming debug after a userspace-initiated forcewake) will
make it simpler to completely skip MMIO debug handling on uncores that
don't support it in future patches.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 9b81b2543ce2..e717ea55484a 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct 
intel_uncore_mmio_debug *mmio_debug)
mmio_debug->unclaimed_mmio_check = 1;
 }
 
-static void mmio_debug_suspend(struct intel_uncore_mmio_debug *mmio_debug)
+static void mmio_debug_suspend(struct intel_uncore *uncore)
 {
-   lockdep_assert_held(_debug->lock);
+   spin_lock(>debug->lock);
 
/* Save and disable mmio debugging for the user bypass */
-   if (!mmio_debug->suspend_count++) {
-   mmio_debug->saved_mmio_check = mmio_debug->unclaimed_mmio_check;
-   mmio_debug->unclaimed_mmio_check = 0;
+   if (!uncore->debug->suspend_count++) {
+   uncore->debug->saved_mmio_check = 
uncore->debug->unclaimed_mmio_check;
+   uncore->debug->unclaimed_mmio_check = 0;
}
+
+   spin_unlock(>debug->lock);
 }
 
-static void mmio_debug_resume(struct intel_uncore_mmio_debug *mmio_debug)
+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
+
+static void mmio_debug_resume(struct intel_uncore *uncore)
 {
-   lockdep_assert_held(_debug->lock);
+   spin_lock(>debug->lock);
+
+   if (!--uncore->debug->suspend_count)
+   uncore->debug->unclaimed_mmio_check = 
uncore->debug->saved_mmio_check;
 
-   if (!--mmio_debug->suspend_count)
-   mmio_debug->unclaimed_mmio_check = mmio_debug->saved_mmio_check;
+   if (check_for_unclaimed_mmio(uncore))
+   drm_info(>i915->drm,
+"Invalid mmio detected during user access\n");
+
+   spin_unlock(>debug->lock);
 }
 
 static const char * const forcewake_domain_names[] = {
@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct intel_uncore 
*uncore)
spin_lock_irq(>lock);
if (!uncore->user_forcewake_count++) {
intel_uncore_forcewake_get__locked(uncore, FORCEWAKE_ALL);
-   spin_lock(>debug->lock);
-   mmio_debug_suspend(uncore->debug);
-   spin_unlock(>debug->lock);
+   mmio_debug_suspend(uncore);
}
spin_unlock_irq(>lock);
 }
@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct intel_uncore 
*uncore)
 {
spin_lock_irq(>lock);
if (!--uncore->user_forcewake_count) {
-   spin_lock(>debug->lock);
-   mmio_debug_resume(uncore->debug);
-
-   if (check_for_unclaimed_mmio(uncore))
-   drm_info(>i915->drm,
-"Invalid mmio detected during user access\n");
-   spin_unlock(>debug->lock);
-
+   mmio_debug_resume(uncore);
intel_uncore_forcewake_put__locked(uncore, FORCEWAKE_ALL);
}
spin_unlock_irq(>lock);
-- 
2.37.2

[PATCH 6/8] drm/i915/xelpmp: Expose media as another GT

[Matt Roper]

Xe_LPM+ platforms have "standalone media."  I.e., the media unit is
designed as an additional GT with its own engine list, GuC, forcewake,
etc.  Let's allow platforms to include media GTs in their device info.

Cc: Aravind Iddamsetty 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile|  1 +
 drivers/gpu/drm/i915/gt/intel_gt.c   | 12 ++--
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  8 +
 drivers/gpu/drm/i915/gt/intel_sa_media.c | 39 
 drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +
 drivers/gpu/drm/i915/i915_pci.c  | 15 +
 drivers/gpu/drm/i915/intel_device_info.h |  5 ++-
 drivers/gpu/drm/i915/intel_uncore.c  | 16 --
 drivers/gpu/drm/i915/intel_uncore.h  | 20 ++--
 9 files changed, 123 insertions(+), 8 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..e83e4cd46968 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -123,6 +123,7 @@ gt-y += \
gt/intel_ring.o \
gt/intel_ring_submission.o \
gt/intel_rps.o \
+   gt/intel_sa_media.o \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index d21ec11346a5..2a29502289cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -776,10 +776,15 @@ void intel_gt_driver_late_release_all(struct 
drm_i915_private *i915)
}
 }
 
-static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
+static int intel_gt_tile_setup(struct intel_gt *gt,
+  phys_addr_t phys_addr,
+  u32 gsi_offset)
 {
int ret;
 
+   /* GSI offset is only applicable for media GTs */
+   drm_WARN_ON(>i915->drm, gsi_offset);
+
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
 
@@ -832,7 +837,7 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
 
drm_dbg(>drm, "Setting up %s\n", gt->name);
-   ret = intel_gt_tile_setup(gt, phys_addr);
+   ret = intel_gt_tile_setup(gt, phys_addr, 0);
if (ret)
return ret;
 
@@ -862,7 +867,8 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
goto err;
}
 
-   ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
+   ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base,
+  gtdef->gsi_offset);
if (ret)
goto err;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 94f9ddcfb3a5..05a40ef33258 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1576,4 +1576,12 @@
 
 #define GEN12_SFC_DONE(n)  _MMIO(0x1cc000 + (n) * 0x1000)
 
+/*
+ * Standalone Media's non-engine GT registers are located at their regular GT
+ * offsets plus 0x38.  This extra offset is stored inside the intel_uncore
+ * structure so that the existing code can be used for both GTs without
+ * modification.
+ */
+#define MTL_MEDIA_GSI_BASE 0x38
+
 #endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c 
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
new file mode 100644
index ..8c5c519457cc
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_sa_media.h"
+
+int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
+  u32 gsi_offset)
+{
+   struct drm_i915_private *i915 = gt->i915;
+   struct intel_uncore *uncore;
+
+   uncore = drmm_kzalloc(>drm, sizeof(*uncore), GFP_KERNEL);
+   if (!uncore)
+   return -ENOMEM;
+
+   uncore->gsi_offset = gsi_offset;
+
+   intel_gt_common_init_early(gt);
+   intel_uncore_init_early(uncore, gt);
+
+   /*
+* Standalone media shares the general MMIO space with the primary
+* GT.  We'll re-use the primary GT's mapping.
+*/
+   uncore->regs = i915->uncore.regs;
+   if (drm_WARN_ON(>drm, uncore->regs == NULL))
+   return -EIO;
+
+   gt->uncore = uncore;
+   gt->phys_addr = phys_addr;
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.h 
b/drivers/gpu/drm/i915/gt/intel_sa_media.h
new file mode 100644
index ..3afb310de932
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.h

[PATCH 3/8] drm/i915: Use managed allocations for extra uncore objects

[Matt Roper]

We're slowly transitioning the init-time kzalloc's of the driver over to
DRM-managed allocations; let's make sure the uncore objects allocated
for non-root GTs are thus allocated.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a82b5e2e0d83..cf7aab7adb30 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -783,7 +783,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt, 
phys_addr_t phys_addr)
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
 
-   uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+   uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore), 
GFP_KERNEL);
if (!uncore)
return -ENOMEM;
 
@@ -808,10 +808,8 @@ intel_gt_tile_cleanup(struct intel_gt *gt)
 {
intel_uncore_cleanup_mmio(gt->uncore);
 
-   if (!gt_is_root(gt)) {
-   kfree(gt->uncore);
+   if (!gt_is_root(gt))
kfree(gt);
-   }
 }
 
 int intel_gt_probe_all(struct drm_i915_private *i915)
-- 
2.37.2

[PATCH 7/8] drm/i915/mtl: Use primary GT's irq lock for media GT

[Matt Roper]

When we hook up interrupts (in the next patch), interrupts for the media
GT are still processed as part of the primary GT's interrupt flow.  As
such, we should share the same IRQ lock with the primary GT.  Let's
convert gt->irq_lock into a pointer and just point the media GT's
instance at the same lock the primary GT is using.

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  8 +++---
 drivers/gpu/drm/i915/gt/intel_gt.c| 15 +--
 drivers/gpu/drm/i915/gt/intel_gt.h|  2 +-
 drivers/gpu/drm/i915/gt/intel_gt_irq.c| 16 ++--
 drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c |  8 +++---
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  2 +-
 drivers/gpu/drm/i915/gt/intel_rps.c   | 26 +--
 drivers/gpu/drm/i915/gt/intel_sa_media.c  |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 -
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  4 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  4 +--
 drivers/gpu/drm/i915/i915_driver.c|  4 ++-
 drivers/gpu/drm/i915/i915_irq.c   |  4 +--
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  4 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c  | 14 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  4 +--
 16 files changed, 77 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 41acc285e8bf..6e0122b3dca2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1688,9 +1688,9 @@ bool intel_engine_irq_enable(struct intel_engine_cs 
*engine)
return false;
 
/* Caller disables interrupts */
-   spin_lock(>gt->irq_lock);
+   spin_lock(engine->gt->irq_lock);
engine->irq_enable(engine);
-   spin_unlock(>gt->irq_lock);
+   spin_unlock(engine->gt->irq_lock);
 
return true;
 }
@@ -1701,9 +1701,9 @@ void intel_engine_irq_disable(struct intel_engine_cs 
*engine)
return;
 
/* Caller disables interrupts */
-   spin_lock(>gt->irq_lock);
+   spin_lock(engine->gt->irq_lock);
engine->irq_disable(engine);
-   spin_unlock(>gt->irq_lock);
+   spin_unlock(engine->gt->irq_lock);
 }
 
 void intel_engines_reset_default_submission(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 2a29502289cb..b974a6d23281 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -37,7 +37,7 @@
 
 void intel_gt_common_init_early(struct intel_gt *gt)
 {
-   spin_lock_init(>irq_lock);
+   spin_lock_init(gt->irq_lock);
 
INIT_LIST_HEAD(>closed_vma);
spin_lock_init(>closed_lock);
@@ -58,14 +58,19 @@ void intel_gt_common_init_early(struct intel_gt *gt)
 }
 
 /* Preliminary initialization of Tile 0 */
-void intel_root_gt_init_early(struct drm_i915_private *i915)
+int intel_root_gt_init_early(struct drm_i915_private *i915)
 {
struct intel_gt *gt = to_gt(i915);
 
gt->i915 = i915;
gt->uncore = >uncore;
+   gt->irq_lock = drmm_kzalloc(>drm, sizeof(*gt->irq_lock), 
GFP_KERNEL);
+   if (!gt->irq_lock)
+   return -ENOMEM;
 
intel_gt_common_init_early(gt);
+
+   return 0;
 }
 
 static int intel_gt_probe_lmem(struct intel_gt *gt)
@@ -787,12 +792,18 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
 
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
+   spinlock_t *irq_lock;
 
uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore), 
GFP_KERNEL);
if (!uncore)
return -ENOMEM;
 
+   irq_lock = drmm_kzalloc(>i915->drm, sizeof(*irq_lock), 
GFP_KERNEL);
+   if (!irq_lock)
+   return -ENOMEM;
+
gt->uncore = uncore;
+   gt->irq_lock = irq_lock;
 
intel_gt_common_init_early(gt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index c9a359f35d0f..2ee582e287c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -45,7 +45,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc 
*gsc)
 }
 
 void intel_gt_common_init_early(struct intel_gt *gt);
-void intel_root_gt_init_early(struct drm_i915_private *i915);
+int intel_root_gt_init_early(struct drm_i915_private *i915);
 int intel_gt_assign_ggtt(struct intel_gt *gt);
 int intel_gt_init_mmio(struct intel_gt *gt);
 int __must_check intel_gt_init_hw(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 3a72d4fd0214..0dfd0c42d00d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -29,7 +29,7 @@ 

[PATCH 8/8] drm/i915/mtl: Hook up interrupts for standalone media

[Matt Roper]

Top-level handling of standalone media interrupts will be processed as
part of the primary GT's interrupt handler (since primary and media GTs
share an MMIO space, unlike remote tile setups).  When we get down to
the point of handling engine interrupts, we need to take care to lookup
VCS and VECS engines in the media GT rather than the primary.

There are also a couple of additional "other" instance bits that
correspond to the media GT's GuC and media GT's power management
interrupts; we need to direct those to the media GT instance as well.

Bspec: 45605
Cc: Anusha Srivatsa 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c   | 19 +++
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  2 ++
 drivers/gpu/drm/i915/gt/intel_sa_media.c |  7 +++
 drivers/gpu/drm/i915/i915_drv.h  |  3 +++
 4 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0dfd0c42d00d..f26882fdc24c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -59,11 +59,17 @@ static void
 gen11_other_irq_handler(struct intel_gt *gt, const u8 instance,
const u16 iir)
 {
+   struct intel_gt *media_gt = gt->i915->media_gt;
+
if (instance == OTHER_GUC_INSTANCE)
return guc_irq_handler(>uc.guc, iir);
+   if (instance == OTHER_MEDIA_GUC_INSTANCE && media_gt)
+   return guc_irq_handler(_gt->uc.guc, iir);
 
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>rps, iir);
+   if (instance == OTHER_MEDIA_GTPM_INSTANCE && media_gt)
+   return gen11_rps_irq_handler(_gt->rps, iir);
 
if (instance == OTHER_KCR_INSTANCE)
return intel_pxp_irq_handler(>pxp, iir);
@@ -81,6 +87,18 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
 {
struct intel_engine_cs *engine;
 
+   /*
+* Platforms with standalone media have their media engines in another
+* GT.
+*/
+   if (MEDIA_VER(gt->i915) >= 13 &&
+   (class == VIDEO_DECODE_CLASS || class == VIDEO_ENHANCEMENT_CLASS)) {
+   if (!gt->i915->media_gt)
+   goto err;
+
+   gt = gt->i915->media_gt;
+   }
+
if (instance <= MAX_ENGINE_INSTANCE)
engine = gt->engine_class[class][instance];
else
@@ -89,6 +107,7 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
if (likely(engine))
return intel_engine_cs_irq(engine, iir);
 
+err:
WARN_ONCE(1, "unhandled engine interrupt class=0x%x, instance=0x%x\n",
  class, instance);
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 05a40ef33258..21c7a225157f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1552,6 +1552,8 @@
 #define   OTHER_GTPM_INSTANCE  1
 #define   OTHER_KCR_INSTANCE   4
 #define   OTHER_GSC_INSTANCE   6
+#define   OTHER_MEDIA_GUC_INSTANCE 16
+#define   OTHER_MEDIA_GTPM_INSTANCE17
 
 #define GEN11_IIR_REG_SELECTOR(x)  _MMIO(0x190070 + ((x) * 4))
 
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c 
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
index cf3053710bbf..41c270f103cf 100644
--- a/drivers/gpu/drm/i915/gt/intel_sa_media.c
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -36,5 +36,12 @@ int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t 
phys_addr,
gt->uncore = uncore;
gt->phys_addr = phys_addr;
 
+   /*
+* For current platforms we can assume there's only a single
+* media GT and cache it for quick lookup.
+*/
+   drm_WARN_ON(>drm, i915->media_gt);
+   i915->media_gt = gt;
+
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d45dca70bfa6..917958d42805 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -497,6 +497,9 @@ struct drm_i915_private {
 
struct kobject *sysfs_gt;
 
+   /* Quick lookup of media GT (current platforms only have one) */
+   struct intel_gt *media_gt;
+
struct {
struct i915_gem_contexts {
spinlock_t lock; /* locks list */
-- 
2.37.2

[PATCH 4/8] drm/i915: Prepare more multi-GT initialization

[Matt Roper]

We're going to introduce an additional intel_gt for MTL's media unit
soon.  Let's provide a bit more multi-GT initialization framework in
preparation for that.  The initialization will pull the list of GTs for
a platform from the device info structure.  Although necessary for the
immediate MTL media enabling, this same framework will also be used
farther down the road when we enable remote tiles on xehpsdv and pvc.

Cc: Aravind Iddamsetty 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 48 +--
 drivers/gpu/drm/i915/gt/intel_gt.h|  1 -
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
 drivers/gpu/drm/i915/i915_drv.h   |  2 +
 drivers/gpu/drm/i915/intel_device_info.h  | 16 +++
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 +
 7 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 275ad72940c1..41acc285e8bf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -736,7 +736,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt 
*gt)
u16 vdbox_mask;
u16 vebox_mask;
 
-   info->engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+   GEM_BUG_ON(!info->engine_mask);
 
if (GRAPHICS_VER(i915) < 11)
return info->engine_mask;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index cf7aab7adb30..7c0525e96155 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -807,17 +807,16 @@ static void
 intel_gt_tile_cleanup(struct intel_gt *gt)
 {
intel_uncore_cleanup_mmio(gt->uncore);
-
-   if (!gt_is_root(gt))
-   kfree(gt);
 }
 
 int intel_gt_probe_all(struct drm_i915_private *i915)
 {
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct intel_gt *gt = >gt0;
+   const struct intel_gt_definition *gtdef;
phys_addr_t phys_addr;
unsigned int mmio_bar;
+   unsigned int i;
int ret;
 
mmio_bar = GRAPHICS_VER(i915) == 2 ? GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
@@ -828,14 +827,55 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
 * and it has been already initialized early during probe
 * in i915_driver_probe()
 */
+   gt->i915 = i915;
+   gt->name = "Primary GT";
+   gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+
+   drm_dbg(>drm, "Setting up %s\n", gt->name);
ret = intel_gt_tile_setup(gt, phys_addr);
if (ret)
return ret;
 
i915->gt[0] = gt;
 
-   /* TODO: add more tiles */
+   for (i = 1, gtdef = _INFO(i915)->extra_gt_list[i - 1];
+gtdef->setup != NULL;
+i++, gtdef = _INFO(i915)->extra_gt_list[i - 1]) {
+   gt = drmm_kzalloc(>drm, sizeof(*gt), GFP_KERNEL);
+   if (!gt) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   gt->i915 = i915;
+   gt->name = gtdef->name;
+   gt->type = gtdef->type;
+   gt->info.engine_mask = gtdef->engine_mask;
+   gt->info.id = i;
+
+   drm_dbg(>drm, "Setting up %s\n", gt->name);
+   if (GEM_WARN_ON(range_overflows_t(resource_size_t,
+ gtdef->mapping_base,
+ SZ_16M,
+ pci_resource_len(pdev, 
mmio_bar {
+   ret = -ENODEV;
+   goto err;
+   }
+
+   ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
+   if (ret)
+   goto err;
+
+   i915->gt[i] = gt;
+   }
+
return 0;
+
+err:
+   i915_probe_error(i915, "Failed to initialize %s! (%d)\n", gtdef->name, 
ret);
+   intel_gt_release_all(i915);
+
+   return ret;
 }
 
 int intel_gt_tiles_init(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 40b06adf509a..4d8779529cc2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -54,7 +54,6 @@ void intel_gt_driver_register(struct intel_gt *gt);
 void intel_gt_driver_unregister(struct intel_gt *gt);
 void intel_gt_driver_remove(struct intel_gt *gt);
 void intel_gt_driver_release(struct intel_gt *gt);
-
 void intel_gt_driver_late_release_all(struct drm_i915_private *i915);
 
 int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 4d56f7d5a3be..3bd36caee321 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ 

[PATCH 5/8] drm/i915: Rename and expose common GT early init routine

[Matt Roper]

The common early GT init is needed for initialization of all GT types
(root/primary, remote tile, standalone media).  Since standalone media
(coming in the next patch) will be implemented in a separate file,
rename and expose the function for use.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt.c | 6 +++---
 drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 7c0525e96155..d21ec11346a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -35,7 +35,7 @@
 #include "intel_uncore.h"
 #include "shmem_utils.h"
 
-static void __intel_gt_init_early(struct intel_gt *gt)
+void intel_gt_common_init_early(struct intel_gt *gt)
 {
spin_lock_init(>irq_lock);
 
@@ -65,7 +65,7 @@ void intel_root_gt_init_early(struct drm_i915_private *i915)
gt->i915 = i915;
gt->uncore = >uncore;
 
-   __intel_gt_init_early(gt);
+   intel_gt_common_init_early(gt);
 }
 
 static int intel_gt_probe_lmem(struct intel_gt *gt)
@@ -789,7 +789,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt, 
phys_addr_t phys_addr)
 
gt->uncore = uncore;
 
-   __intel_gt_init_early(gt);
+   intel_gt_common_init_early(gt);
}
 
intel_uncore_init_early(gt->uncore, gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 4d8779529cc2..c9a359f35d0f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -44,6 +44,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc 
*gsc)
return container_of(gsc, struct intel_gt, gsc);
 }
 
+void intel_gt_common_init_early(struct intel_gt *gt);
 void intel_root_gt_init_early(struct drm_i915_private *i915);
 int intel_gt_assign_ggtt(struct intel_gt *gt);
 int intel_gt_init_mmio(struct intel_gt *gt);
-- 
2.37.2

[PATCH 2/8] drm/i915: Only hook up uncore->debug for primary uncore

[Matt Roper]

The original intent of intel_uncore_mmio_debug as described in commit
0a9b26306d6a ("drm/i915: split out uncore_mmio_debug") was to be a
singleton structure that could be shared between multiple GTs' uncore
objects in a multi-tile system.  Somehow we went off track and
started allocating separate instances of this structure for each GT,
which defeats that original goal.

But in reality, there isn't even a need to share the mmio_debug between
multiple GTs; on all modern platforms (i.e., everything after gen7)
unclaimed register accesses are something that can only be detected for
display registers.  There's no point in grabbing the debug spinlock and
checking for unclaimed accesses on an uncore used by an xehpsdv or pvc
remote tile GT, or the uncore used by a mtl standalone media GT since
all of the display accesses go through the primary intel_uncore.

The simplest solution is to simply leave uncore->debug NULL on all
intel_uncore instances except for the primary one.  This will allow us
to avoid the pointless debug spinlock acquisition we've been doing on
MMIO accesses coming in through these intel_uncores.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt.c  |  9 -
 drivers/gpu/drm/i915/i915_driver.c  |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c | 23 ++-
 drivers/gpu/drm/i915/intel_uncore.h |  3 +--
 4 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e4bac2431e41..a82b5e2e0d83 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -781,21 +781,13 @@ static int intel_gt_tile_setup(struct intel_gt *gt, 
phys_addr_t phys_addr)
int ret;
 
if (!gt_is_root(gt)) {
-   struct intel_uncore_mmio_debug *mmio_debug;
struct intel_uncore *uncore;
 
uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
if (!uncore)
return -ENOMEM;
 
-   mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
-   if (!mmio_debug) {
-   kfree(uncore);
-   return -ENOMEM;
-   }
-
gt->uncore = uncore;
-   gt->uncore->debug = mmio_debug;
 
__intel_gt_init_early(gt);
}
@@ -817,7 +809,6 @@ intel_gt_tile_cleanup(struct intel_gt *gt)
intel_uncore_cleanup_mmio(gt->uncore);
 
if (!gt_is_root(gt)) {
-   kfree(gt->uncore->debug);
kfree(gt->uncore);
kfree(gt);
}
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 053a7dab5506..de9020771836 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -326,7 +326,7 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
intel_device_info_subplatform_init(dev_priv);
intel_step_init(dev_priv);
 
-   intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
+   intel_uncore_mmio_debug_init_early(dev_priv);
 
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index e717ea55484a..6841f76533f9 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -44,14 +44,19 @@ fw_domains_get(struct intel_uncore *uncore, enum 
forcewake_domains fw_domains)
 }
 
 void
-intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug)
+intel_uncore_mmio_debug_init_early(struct drm_i915_private *i915)
 {
-   spin_lock_init(_debug->lock);
-   mmio_debug->unclaimed_mmio_check = 1;
+   spin_lock_init(>mmio_debug.lock);
+   i915->mmio_debug.unclaimed_mmio_check = 1;
+
+   i915->uncore.debug = >mmio_debug;
 }
 
 static void mmio_debug_suspend(struct intel_uncore *uncore)
 {
+   if (!uncore->debug)
+   return;
+
spin_lock(>debug->lock);
 
/* Save and disable mmio debugging for the user bypass */
@@ -67,6 +72,9 @@ static bool check_for_unclaimed_mmio(struct intel_uncore 
*uncore);
 
 static void mmio_debug_resume(struct intel_uncore *uncore)
 {
+   if (!uncore->debug)
+   return;
+
spin_lock(>debug->lock);
 
if (!--uncore->debug->suspend_count)
@@ -1705,7 +1713,7 @@ unclaimed_reg_debug(struct intel_uncore *uncore,
const bool read,
const bool before)
 {
-   if (likely(!uncore->i915->params.mmio_debug))
+   if (likely(!uncore->i915->params.mmio_debug) || !uncore->debug)
return;
 
/* interrupts are disabled and re-enabled around uncore->lock usage */
@@ -2267,7 +2275,6 @@ void intel_uncore_init_early(struct intel_uncore *uncore,
uncore->i915 = gt->i915;
uncore->gt = gt;
uncore->rpm = >i915->runtime_pm;
-   

[PATCH 0/8] i915: Add "standalone media" support for MTL

[Matt Roper]

Starting with MTL, media functionality has moved into a new, second GT
at the hardware level.  This new GT, referred to as "standalone media"
in the spec, has its own GuC, power management/forcewake, etc.  The
general non-engine GT registers for standalone media start at 0x38,
but otherwise use the same MMIO offsets as the primary GT.

Standalone media has a lot of similarity to the remote tiles
present on platforms like xehpsdv and pvc, and our i915 implementation 
can share much of the general "multi GT" infrastructure between the two
types of platforms.  However there are a few notable differences
we must deal with:
 - The 0x38 offset only applies to the non-engine GT registers
   (which the specs refer to as "GSI" registers).  The engine registers
   remain at their usual locations (e.g., 0x1C for VCS0).
 - Unlike platforms with remote tiles, all interrupt handling for
   standalone media still happens via the primary GT.


Matt Roper (8):
  drm/i915: Move locking and unclaimed check into
mmio_debug_{suspend,resume}
  drm/i915: Only hook up uncore->debug for primary uncore
  drm/i915: Use managed allocations for extra uncore objects
  drm/i915: Prepare more multi-GT initialization
  drm/i915: Rename and expose common GT early init routine
  drm/i915/xelpmp: Expose media as another GT
  drm/i915/mtl: Use primary GT's irq lock for media GT
  drm/i915/mtl: Hook up interrupts for standalone media

 drivers/gpu/drm/i915/Makefile |  1 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 +--
 drivers/gpu/drm/i915/gt/intel_gt.c| 88 ++-
 drivers/gpu/drm/i915/gt/intel_gt.h|  4 +-
 drivers/gpu/drm/i915/gt/intel_gt_irq.c| 35 ++--
 drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c |  8 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   | 10 +++
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  5 +-
 drivers/gpu/drm/i915/gt/intel_rps.c   | 26 +++---
 drivers/gpu/drm/i915/gt/intel_sa_media.c  | 47 ++
 drivers/gpu/drm/i915/gt/intel_sa_media.h  | 15 
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 ++---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  4 +-
 drivers/gpu/drm/i915/i915_driver.c|  6 +-
 drivers/gpu/drm/i915/i915_drv.h   |  5 ++
 drivers/gpu/drm/i915/i915_irq.c   |  4 +-
 drivers/gpu/drm/i915/i915_pci.c   | 15 
 drivers/gpu/drm/i915/intel_device_info.h  | 19 
 drivers/gpu/drm/i915/intel_uncore.c   | 80 +++--
 drivers/gpu/drm/i915/intel_uncore.h   | 23 -
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  4 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c  | 14 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  4 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 +
 25 files changed, 340 insertions(+), 116 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h

-- 
2.37.2

Re: [PATCH v5 4/4] drm/bridge: ti-sn65dsi86: Implement bridge connector operations

[Doug Anderson]

Hi,

On Wed, Aug 24, 2022 at 6:00 AM Tomi Valkeinen
 wrote:
>
> From: Laurent Pinchart 
>
> Implement the bridge connector-related .get_edid() and .detect()
> operations, and report the related bridge capabilities and type.
>
> These ops are only added for DP mode. They should also be used for eDP
> mode, but the driver seems to be mostly used for eDP and, according to
> the comments, they've had issues with eDP panels and HPD. So better be
> safe and only enable them for DP for now.

Just to be clear: the "They should also be used for eDP" is not correct.

* The detect() function should be returning whether the display is
physically there. For eDP it is _always_ physically there. Thus for
eDP the _correct_ implementation for detect is to always return true.
Yes, there is a line called HPD for eDP and yes that line is used for
full DisplayPort for detecting a display. For eDP, though, HPD does
not detect the presence of a display. A display is always there.

* For eDP implementing get_edid() is done in the panel so that power
sequencing can be done properly. While it could have been designed
other ways, that's how we ended up in the end. Thus eDP controllers
don't implement get_edid().


> @@ -1163,10 +1165,33 @@ static void ti_sn_bridge_atomic_post_disable(struct 
> drm_bridge *bridge,
> pm_runtime_put_sync(pdata->dev);
>  }
>
> +static enum drm_connector_status ti_sn_bridge_detect(struct drm_bridge 
> *bridge)
> +{
> +   struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> +   int val = 0;
> +
> +   pm_runtime_get_sync(pdata->dev);
> +   regmap_read(pdata->regmap, SN_HPD_DISABLE_REG, );
> +   pm_runtime_put_autosuspend(pdata->dev);
> +
> +   return val & HPD_DEBOUNCED_STATE ? connector_status_connected
> +: connector_status_disconnected;
> +}

I thought in the end we decided that you _could_ get a hot plug detect
interrupt if you just did a pm_runtime_get_sync() sometime earlier in
the case of DP. Basically you're just saying that if you're DP that
you always powered up. Doing some searches makes me find some
discussion at:

https://lore.kernel.org/r/20220310152227.2122960-4-kieran.bingham+rene...@ideasonboard.com

Specifically, the right answer is: "In general the pm_runtime_get
reference need to go with the IRQ enabling"

In any case, if we want to start with just implementing "detect"
that's OK with me...

Thus with the commit message clarified, feel free to add my Reviewed-by.

Re: [PATCH v5 2/4] drm/bridge: ti-sn65dsi86: Reject modes with too large blanking

[Doug Anderson]

Hi,

On Wed, Aug 24, 2022 at 6:00 AM Tomi Valkeinen
 wrote:
>
> From: Tomi Valkeinen 
>
> The blanking related registers are 8 bits, so reject any modes
> with larger blanking periods.
>
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index ba84215c1511..f085a037ff5b 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -752,6 +752,29 @@ ti_sn_bridge_mode_valid(struct drm_bridge *bridge,
> if (mode->clock > 594000)
> return MODE_CLOCK_HIGH;
>
> +   /*
> +* The blanking related registers are 8 bits, so reject any modes
> +* with larger blanking periods.
> +*/
> +
> +   if ((mode->hsync_start - mode->hdisplay) > 0xff)
> +   return MODE_HBLANK_WIDE;
> +
> +   if ((mode->vsync_start - mode->vdisplay) > 0xff)
> +   return MODE_VBLANK_WIDE;
> +
> +   if ((mode->hsync_end - mode->hsync_start) > 0xff)
> +   return MODE_HSYNC_WIDE;

Please double-check your patch. Reading through
ti_sn_bridge_set_video_timings(), I see "mode->hsync_end -
mode->hsync_start" is allowed to be up to 0x7fff. The datasheet seems
to confirm. If I got that right it means you're rejecting valid modes.

I didn't validate any of your other checks, but at least that one seems wrong.

SInce this already had a Reviewed-by tag, being explicit:

Naked-by: Douglas Anderson 

Re: [PATCH 2/2] drm: bridge: icn6211: Add support for external REFCLK

[Marek Vasut]

On 8/29/22 16:54, Robert Foss wrote:

Hey Marek,


Hi,


On Mon, 1 Aug 2022 at 15:18, Marek Vasut  wrote:


The ICN6211 is capable of deriving its internal PLL clock from either
MIPI DSI HS clock, external REFCLK clock, or even internal oscillator.
Currently supported is only the first option. Add support for external
REFCLK clock input in addition to that.

There is little difference between these options, except that in case
of MIPI DSI HS clock input, the HS clock are pre-divided by a fixed /4
divider before being fed to the PLL input, while in case of external
REFCLK, the RECLK clock are fed directly into the PLL input.

Per exceptionally poor documentation, the REFCLK must be in range of
10..154 MHz.


[...]


This patch looks good to me, but it doesn't apply on drm-misc-next. Do
you mind re-spinning it?


I already see this patch in drm-misc-next, so it was applied already:

378e0f9f0b3e0 ("drm: bridge: icn6211: Add support for external REFCLK")

I think all is good ?

Re: [PATCH v5 1/4] drm/bridge: ti-sn65dsi86: check AUX errors better

[Doug Anderson]

Hi,

On Wed, Aug 24, 2022 at 6:01 AM Tomi Valkeinen
 wrote:
>
> From: Tomi Valkeinen 
>
> The driver does not check AUX_IRQ_STATUS_NAT_I2C_FAIL bit at all when
> sending AUX transfers,

It doesn't? What about a few lines down from where your patch modifies
that reads:

  else if (val & AUX_IRQ_STATUS_NAT_I2C_FAIL) {

That seems like it's checking that bit?


> which leads to the driver not returning an error.

Right that it doesn't return an error. I guess the question is: should
it? Right now it sets the proper reply (DP_AUX_I2C_REPLY_NACK or
DP_AUX_NATIVE_REPLY_NACK) and returns 0. Is it supposed to be
returning an error code? What problem are you fixing?

In commit 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux
failures"), at least, we thought that returning "0" and setting the
"reply" was the correct thing to do (though we didn't have any good
setup to test all the error paths).

...and looking through the code at drm_dp_i2c_do_msg(), I see that it
only ever looks at DP_AUX_I2C_REPLY_NACK if "ret" was 0.

So I guess I would say:

1. Your patch doesn't seem right to me.

2. If your patch is actually fixing a problem, you should at least
modify it so that it doesn't create dead code (the old handling of
AUX_IRQ_STATUS_NAT_I2C_FAIL is no longer reachable after your patch.

Naked-by: Douglas Anderson 

Re: [PATCH v3 1/3] PCI: Move PCI_VENDOR_ID_MICROSOFT/PCI_DEVICE_ID_HYPERV_VIDEO definitions to pci_ids.h

[Bjorn Helgaas]

On Sat, Aug 27, 2022 at 03:03:43PM +0200, Vitaly Kuznetsov wrote:
> There are already three places in kernel which define PCI_VENDOR_ID_MICROSOFT
> and two for PCI_DEVICE_ID_HYPERV_VIDEO and there's a need to use these
> from core Vmbus code. Move the defines where they belong.

It's a minor annoyance that the above is 81 characters long when "git
log" adds its 4-character indent, so it wraps in a default terminal.

It'd be nice if we could settle on a conventional spelling of "Vmbus",
too.  "Vmbus" looks to be in the minority:

  $ git grep Vmbus | wc -l; git grep VMbus | wc -l; git grep VMBus | wc -l
  4
  82
  62

FWIW, one published microsoft.com doc uses "VMBus":
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/hyper-v-architecture

[PATCH] drm/msm/dsi: Remove use of device_node in dsi_host_parse_dt()

[Nathan Chancellor]

Clang warns:

  drivers/gpu/drm/msm/dsi/dsi_host.c:1903:14: error: variable 'device_node' is 
uninitialized when used here [-Werror,-Wuninitialized]
  of_node_put(device_node);
  ^~~
  drivers/gpu/drm/msm/dsi/dsi_host.c:1870:44: note: initialize the variable 
'device_node' to silence this warning
  struct device_node *endpoint, *device_node;
^
= NULL
  1 error generated.

device_node's assignment was removed but not all of its uses. Remove the
call to of_node_put() and the variable declaration to clean up the
warning.

Fixes: 5f8cdece42ff ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")
Link: https://github.com/ClangBuiltLinux/linux/issues/1700
Signed-off-by: Nathan Chancellor 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 57a4c0fa614b..7fbf391c024f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1867,7 +1867,7 @@ static int dsi_host_parse_dt(struct msm_dsi_host 
*msm_host)
 {
struct device *dev = _host->pdev->dev;
struct device_node *np = dev->of_node;
-   struct device_node *endpoint, *device_node;
+   struct device_node *endpoint;
int ret = 0;
 
/*
@@ -1900,8 +1900,6 @@ static int dsi_host_parse_dt(struct msm_dsi_host 
*msm_host)
}
}
 
-   of_node_put(device_node);
-
 err:
of_node_put(endpoint);
 

base-commit: 5f8cdece42ff0c615e213b6619d29487f9f409d7
-- 
2.37.2

Re: [Intel-gfx] [PATCH] Revert "drm/i915/dg2: Add preemption changes for Wa_14015141709"

[Matt Atwood]

On Fri, Aug 26, 2022 at 02:02:33PM -0700, Matt Roper wrote:
> This reverts commit ca6920811aa5428270dd78af0a7a36b10119065a.
> 
> The intent of Wa_14015141709 was to inform us that userspace can no
> longer control object-level preemption as it has on past platforms
> (i.e., by twiddling register bit CS_CHICKEN1[0]).  The description of
> the workaround in the spec wasn't terribly well-written, and when we
> requested clarification from the hardware teams we were told that on the
> kernel side we should also probably stop setting
> FF_SLICE_CS_CHICKEN1[14], which is the register bit that directs the
> hardware to honor the settings in per-context register CS_CHICKEN1.  It
> turns out that this guidance about FF_SLICE_CS_CHICKEN1[14] was a
> mistake; even though CS_CHICKEN1[0] is non-operational and useless to
> userspace, there are other bits in the register that do still work and
> might need to be adjusted by userspace in the future (e.g., to implement
> other workarounds that show up).  If we don't set
> FF_SLICE_CS_CHICKEN1[14] in i915, then those future workarounds would
> not take effect.
> 
> This miscommunication came to light because another workaround
> (Wa_16013994831) has now shown up that requires userspace to adjust the
> value of CS_CHICKEN[10] in certain circumstances.  To ensure userspace's
> updates to this chicken bit are handled properly by the hardware, we
> need to make sure that FF_SLICE_CS_CHICKEN1[14] is once again set by the
> kernel.
> 
Reviewed-by: Matt Atwood 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
>  drivers/gpu/drm/i915/i915_drv.h | 3 ---
>  2 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3cdb8294e13f..69a0c6a74474 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2389,7 +2389,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>FF_DOP_CLOCK_GATE_DISABLE);
>   }
>  
> - if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
> + if (IS_GRAPHICS_VER(i915, 9, 12)) {
>   /* 
> FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */
>   wa_masked_en(wal,
>GEN7_FF_SLICE_CS_CHICKEN1,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2b00ef3626db..d6a1ab6f65de 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1352,9 +1352,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define HAS_GUC_DEPRIVILEGE(dev_priv) \
>   (INTEL_INFO(dev_priv)->has_guc_deprivilege)
>  
> -#define HAS_PERCTX_PREEMPT_CTRL(i915) \
> - ((GRAPHICS_VER(i915) >= 9) &&  GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
> -
>  #define HAS_D12_PLANE_MINIMIZATION(dev_priv) (IS_ROCKETLAKE(dev_priv) || \
> IS_ALDERLAKE_S(dev_priv))
>  
> -- 
> 2.37.2
> 

Re: [PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)

[Daniel Dadap]

On 8/29/22 06:41, Hans de Goede wrote:

Hi,

On 8/26/22 00:21, Daniel Dadap wrote:

On 8/25/22 9:37 AM, Hans de Goede wrote:

On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.

When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.

Changes in v2:
- Use the new shared nvidia-wmi-ec-backlight.h header for the
    WMI firmware API definitions
- ACPI_VIDEO can now be enabled on non X86 too,
    adjust the Kconfig changes to match this.

Changes in v3:
- Use WMI_BRIGHTNESS_GUID define

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
   drivers/acpi/Kconfig   |  1 +
   drivers/acpi/video_detect.c    | 37 ++
   drivers/gpu/drm/gma500/Kconfig |  2 ++
   drivers/gpu/drm/i915/Kconfig   |  2 ++
   include/acpi/video.h   |  1 +
   5 files changed, 43 insertions(+)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7802d8846a8d..44ad4b6bd234 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -212,6 +212,7 @@ config ACPI_VIDEO
   tristate "Video"
   depends on BACKLIGHT_CLASS_DEVICE
   depends on INPUT
+    depends on ACPI_WMI || !X86
   select THERMAL
   help
     This driver implements the ACPI Extensions For Display Adapters
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index cc9d0d91e268..4dc7fb865083 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -32,6 +32,7 @@
   #include 
   #include 
   #include 
+#include 
   #include 
   #include 
   #include 
@@ -75,6 +76,36 @@ find_video(acpi_handle handle, u32 lvl, void *context, void 
**rv)
   return AE_OK;
   }
   +/* This depends on ACPI_WMI which is X86 only */
+#ifdef CONFIG_X86


This could probably also provide the { return false; } stub which you have for 
non-x86 if the kernel is built without nvidia-wmi-ec-backight, e.g.:

#if defined(CONFIG_X86) && (defined(CONFIG_NVIDIA_WMI_EC_BACKLIGHT) || 
defined(CONFIG_NVIDIA_WMI_EC_BACKLIGHT_MODULE))

Although I suppose that would break things if somebody has a kernel that 
originally had NVIDIA_WMI_EC_BACKLIGHT=n in Kconfig, and then builds the 
nvidia-wmi-ec-backlight driver out-of-tree later. I don't know whether that's 
intended to be a supported use case, so I guess it is fine either way.

The video-detect code is about detecting what interface should be used.
So far it does this independently of the driver implementing that interface
actually being enabled or not.

If someone has a system which needs the nvidia-wmi-ec-backlight driver,
but it is disabled then they / their distro should enable that driver,
rather then trying to fallback on e.g. acpi_video.

Taking which drivers are enabled into account would both make
the code more complicated and would also explode the test matrix.

All of this is already somewhat fragile, so lets not make it
extra complicated :)



That is fair.

Reviewed-by: Daniel Dadap 



Regards,

Hans






+static bool nvidia_wmi_ec_supported(void)
+{
+    struct wmi_brightness_args args = {
+    .mode = WMI_BRIGHTNESS_MODE_GET,
+    .val = 0,
+    .ret = 0,
+    };
+    struct acpi_buffer buf = { (acpi_size)sizeof(args),  };
+    acpi_status status;
+
+    status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0,
+ WMI_BRIGHTNESS_METHOD_SOURCE, , );
+    if (ACPI_FAILURE(status))
+    return false;
+
+    /*
+ * If brightness is handled by the EC then nvidia-wmi-ec-backlight
+ * should be used, else the GPU driver(s) should be used.
+ */
+    return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
+}
+#else
+static bool nvidia_wmi_ec_supported(void)
+{
+    return false;
+}
+#endif
+
   /* Force to use vendor driver when the ACPI device is known to be
    * buggy */
   static int video_detect_force_vendor(const struct dmi_system_id *d)
@@ -541,6 +572,7 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
   static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
   {
   static DEFINE_MUTEX(init_mutex);
+    static bool nvidia_wmi_ec_present;
   static bool native_available;
   static bool init_done;
   static long video_caps;
@@ -553,6 +585,7 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
   acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
   ACPI_UINT32_MAX, find_video, NULL,
   _caps, NULL);
+    nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
   init_done = true;
   }
   if (native)
@@ -570,6 +603,10 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
   if (acpi_backlight_dmi != acpi_backlight_undef)
   return 

RE: [PATCH v6 2/2] drm: rcar-du: Add RZ/G2L DSI driver

[Biju Das]

Hi Robert,

Thanks for the feedback.

> Subject: Re: [PATCH v6 2/2] drm: rcar-du: Add RZ/G2L DSI driver
> 
> Hey Biju,
> 
> The patch does not apply on drm-misc-next, could you rebase it and
> submit the next version?

I believe[1] is dependent on this patch series. Sorry for not
making it clear while sending this patch series out.

I thought Laurent is going to give a pull request for RCar DU patches.

Based on that assumption, currently my environment is drm-tip + 
12 patches from[2], as [2] doesn't have all the latest patches from
drm-misc-next/drm-tip.

[1] 
https://git.linuxtv.org/pinchartl/media.git/commit/drivers/gpu/drm/rcar-du?h=drm/du/next=2de250465c3ed5e13bfb5139d9a8c17105d3a1f1

[2] 
https://git.linuxtv.org/pinchartl/media.git/log/drivers/gpu/drm/rcar-du?h=drm/du/next

> 
> Additionally it has a few 'checkpatch --strict' warnings.

I got a review comment[3] to use (1 << 1) style instead of BIT macro.
Some of the warnings related to this.

[3]https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220328065115.11724-1-biju.das...@bp.renesas.com/

Laurent, any thoughts??

Cheers,
Biju

> 
> On Mon, 29 Aug 2022 at 11:19, Biju Das 
> wrote:
> >
> > This driver supports the MIPI DSI encoder found in the RZ/G2L SoC. It
> > currently supports DSI video mode only.
> >
> > Signed-off-by: Biju Das 
> > Acked-by: Sam Ravnborg 
> > ---
> > v5->v6:
> >  * Updated commit description
> >  * Moved handling of arst and prst from rzg2l_mipi_dsi_startup-
> >runtime
> >PM suspend/resume handlers.
> >  * Max lane capability read at probe(), and enforced in
> >rzg2l_mipi_dsi_host_attach()
> >  * Simplified vich1ppsetr setting.
> >  * Renamed hsclk_running_mode,hsclk_mode->is_clk_cont.
> >  * Fixed typo in probe error message(arst->rst).
> >  * Reordered DRM bridge initaization in probe()
> >  * Updated typo in e-mail address.
> > v4->v5:
> >  * Added Ack from Sam.
> >  * Added a trivial change, replaced rzg2l_mipi_dsi_parse_dt()
> >with drm_of_get_data_lanes_count_ep() in probe.
> > v3->v4:
> >  * Updated error handling in rzg2l_mipi_dsi_startup() and
> > rzg2l_mipi_dsi_atomic_enable()
> > v2->v3:
> >  * pass rzg2l_mipi_dsi pointer to {Link,Phy} register rd/wr function
> instead
> >of the memory pointer
> >  * Fixed the comment in rzg2l_mipi_dsi_startup()
> >  * Removed unnecessary dbg message from rzg2l_mipi_dsi_start_video()
> >  * DRM bridge parameter initialization moved to probe
> >  * Replaced dev_dbg->dev_err in rzg2l_mipi_dsi_parse_dt()
> >  * Inserted the missing blank lane after return in probe()
> >  * Added missing MODULE_DEVICE_TABLE
> >  * Added include linux/bits.h in header file
> >  * Fixed various macros in header file.
> >  * Reorder the make file for DSI, so that it is no more dependent
> >on RZ/G2L DU patch series.
> > v1->v2:
> >  * Rework based on dt-binding change (DSI + D-PHY) as single block
> >  * Replaced link_mmio and phy_mmio with mmio in struct rzg2l_mipi_dsi
> >  * Replaced rzg2l_mipi_phy_write with rzg2l_mipi_dsi_phy_write
> >and rzg2l_mipi_dsi_link_write
> >  * Replaced rzg2l_mipi_phy_read->rzg2l_mipi_dsi_link_read
> > RFC->v1:
> >  * Added "depends on ARCH_RENESAS || COMPILE_TEST" on KCONFIG
> >and dropped DRM as it is implied by DRM_BRIDGE
> >  * Used devm_reset_control_get_exclusive() for reset handle
> >  * Removed bool hsclkmode from struct rzg2l_mipi_dsi
> >  * Added error check for pm, using pm_runtime_resume_and_get() instead
> of
> >pm_runtime_get_sync()
> >  * Added check for unsupported formats in rzg2l_mipi_dsi_host_attach()
> >  * Avoided read-modify-write stopping hsclock
> >  * Used devm_platform_ioremap_resource for resource allocation
> >  * Removed unnecessary assert call from probe and remove.
> >  * wrap the line after the PTR_ERR() in probe()
> >  * Updated reset failure messages in probe
> >  * Fixed the typo arstc->prstc
> >  * Made hex constants to lower case.
> > RFC:
> >  *
> > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > hwork.kernel.org%2Fproject%2Flinux-renesas-soc%2Fpatch%2F2022011217461
> > 2.10773-23-biju.das.jz%40bp.renesas.com%2Fdata=05%7C01%7Cbiju.das
> > .jz%40bp.renesas.com%7C003e031f5e7f454bdfdf08da89d4d82d%7C53d82571da19
> > 47e49cb4625a166a4a2a%7C0%7C0%7C637973844501238222%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C3000%7C%7C%7Csdata=uNJMSsB3FHHDBnczS4jLEL8OADLe03K6gksF2aNn31k
> > %3Dreserved=0
> > ---
> >  drivers/gpu/drm/rcar-du/Kconfig   |   8 +
> >  drivers/gpu/drm/rcar-du/Makefile  |   2 +
> >  drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c  | 703
> ++
> >  drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 151 
> >  4 files changed, 864 insertions(+)
> >  create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> >  create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > b/drivers/gpu/drm/rcar-du/Kconfig 

Re: [Intel-gfx] [PATCH] drm/i915/ats-m: Add thread execution tuning setting

[Matt Atwood]

On Fri, Aug 26, 2022 at 02:27:18PM -0700, Matt Roper wrote:
> On client DG2 platforms, optimal performance is achieved with the
> hardware's default "age based" thread execution setting.  However on
> ATS-M, switching this to "round robin after dependencies" provides
> better performance.  We'll add a new "tuning" feature flag to the ATS-M
> device info to enable/disable this setting.
> 
> Bspec: 68331
> Cc: Lucas De Marchi 
Reviewed-by: Matt Atwood 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
>  drivers/gpu/drm/i915/i915_pci.c | 1 +
>  drivers/gpu/drm/i915/intel_device_info.h| 1 +
>  4 files changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 94f9ddcfb3a5..d414785003cc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1110,6 +1110,8 @@
>  #define   GEN12_DISABLE_TDL_PUSH REG_BIT(9)
>  #define   GEN11_DIS_PICK_2ND_EU  REG_BIT(7)
>  #define   GEN12_DISABLE_HDR_PAST_PAYLOAD_HOLD_FIXREG_BIT(4)
> +#define   THREAD_EX_ARB_MODE REG_GENMASK(3, 2)
> +#define   THREAD_EX_ARB_MODE_RR_AFTER_DEP
> REG_FIELD_PREP(THREAD_EX_ARB_MODE, 0x2)
>  
>  #define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
>  #define   HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE (1 << 6)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3cdb8294e13f..ff8c3735abc9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2700,6 +2700,15 @@ add_render_compute_tuning_settings(struct 
> drm_i915_private *i915,
>  0 /* write-only, so skip validation */,
>  true);
>   }
> +
> + /*
> +  * This tuning setting proves beneficial only on ATS-M designs; the
> +  * default "age based" setting is optimal on regular DG2 and other
> +  * platforms.
> +  */
> + if (INTEL_INFO(i915)->tuning_thread_rr_after_dep)
> + wa_masked_field_set(wal, GEN9_ROW_CHICKEN4, THREAD_EX_ARB_MODE,
> + THREAD_EX_ARB_MODE_RR_AFTER_DEP);
>  }
>  
>  /*
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 857e8bb6865c..26b25d9434d6 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1080,6 +1080,7 @@ static const struct intel_device_info ats_m_info = {
>   DG2_FEATURES,
>   .display = { 0 },
>   .require_force_probe = 1,
> + .tuning_thread_rr_after_dep = 1,
>  };
>  
>  #define XE_HPC_FEATURES \
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 0ccde94b225f..6904ad03ca19 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -171,6 +171,7 @@ enum intel_ppgtt_type {
>   func(has_runtime_pm); \
>   func(has_snoop); \
>   func(has_coherent_ggtt); \
> + func(tuning_thread_rr_after_dep); \
>   func(unfenced_needs_alignment); \
>   func(hws_needs_physical);
>  
> -- 
> 2.37.2
> 

Re: [PATCH 2/2] drm/bridge: chrontel-ch7033: Add option for setting byteswap order

[Robert Foss]

On Wed, 30 Mar 2022 at 21:39, Chris Morgan  wrote:
>
> From: Chris Morgan 
>
> Add the option to set the byteswap order in the devicetree. For the
> official HDMI DIP for the NTC CHIP the byteswap order needs to be
> RGB, however the driver sets it as BGR. With this patch the driver
> will remain at BGR unless manually specified via devicetree.
>
> Signed-off-by: Chris Morgan 
> ---
>  drivers/gpu/drm/bridge/chrontel-ch7033.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c 
> b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> index 486f405c2e16..88175b7e80d4 100644
> --- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> +++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> @@ -67,6 +67,7 @@ enum {
> BYTE_SWAP_GBR   = 3,
> BYTE_SWAP_BRG   = 4,
> BYTE_SWAP_BGR   = 5,
> +   BYTE_SWAP_MAX   = 6,
>  };
>
>  /* Page 0, Register 0x19 */
> @@ -354,6 +355,8 @@ static void ch7033_bridge_mode_set(struct drm_bridge 
> *bridge,
> int hsynclen = mode->hsync_end - mode->hsync_start;
> int vbporch = mode->vsync_start - mode->vdisplay;
> int vsynclen = mode->vsync_end - mode->vsync_start;
> +   u8 byte_swap;
> +   int ret;
>
> /*
>  * Page 4
> @@ -397,8 +400,16 @@ static void ch7033_bridge_mode_set(struct drm_bridge 
> *bridge,
> regmap_write(priv->regmap, 0x15, vbporch);
> regmap_write(priv->regmap, 0x16, vsynclen);
>
> -   /* Input color swap. */
> -   regmap_update_bits(priv->regmap, 0x18, SWAP, BYTE_SWAP_BGR);
> +   /* Input color swap. Byte order is optional and will default to
> +* BYTE_SWAP_BGR to preserve backwards compatibility with existing
> +* driver.
> +*/
> +   ret = of_property_read_u8(priv->bridge.of_node, "chrontel,byteswap",
> + _swap);
> +   if (!ret && byte_swap < BYTE_SWAP_MAX)
> +   regmap_update_bits(priv->regmap, 0x18, SWAP, byte_swap);
> +   else
> +   regmap_update_bits(priv->regmap, 0x18, SWAP, BYTE_SWAP_BGR);
>
> /* Input clock and sync polarity. */
> regmap_update_bits(priv->regmap, 0x19, 0x1, mode->clock >> 16);
> --
> 2.25.1
>

Reviewed-by: Robert Foss 

Re: [PATCH 1/2] dt-bindings: Add byteswap order to chrontel ch7033

[Robert Foss]

Hey Chris,

Sorry about being slow getting to this.

On Wed, 30 Mar 2022 at 21:39, Chris Morgan  wrote:
>
> From: Chris Morgan 
>
> Update dt-binding documentation to add support for setting byteswap of
> chrontel ch7033.
>
> New property name of chrontel,byteswap added to set the byteswap order.
> This property is optional.
>
> Signed-off-by: Chris Morgan 
> ---
>  .../bindings/display/bridge/chrontel,ch7033.yaml  | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml 
> b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> index bb6289c7d375..ecd3062c5215 100644
> --- a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> @@ -14,6 +14,14 @@ properties:
>compatible:
>  const: chrontel,ch7033
>
> +  chrontel,byteswap:
> +$ref: /schemas/types.yaml#/definitions/uint8
> +enum: [0, 1, 2, 3, 4, 5]
> +description: |
> +  Set the byteswap value of the bridge. Values 0-5 correspond to
> +  BYTE_SWAP_RGB, BYTE_SWAP_RBG, BYTE_SWAP_GRB, BYTE_SWAP_GBR,
> +  BYTE_SWAP_BRG, and BYTE_SWAP_BGR respectively.

This is acceptable, but maybe we can make this a little bit nicer by
documenting the enum and it's description on the same line.

enum:
  - 0 # automode
  - 1 # internal
  - 2 # external

> +
>reg:
>  maxItems: 1
>  description: I2C address of the device
> --
> 2.25.1
>

With this addressed, please add my r-b.

Reviewed-by: Robert Foss 

Re: [PATCH 0/2] drm: bridge: adv7511: CEC support for ADV7535

[Robert Foss]

Hi Alvin,

Sorry about being slow to get to this series.

Can you rebase it on drm-misc-next and send out the next version?

On Sat, 19 Mar 2022 at 16:10, Alvin Šipraga  wrote:
>
> From: Alvin Šipraga 
>
> We have an ADV7535 which is nominally supported by this driver. These
> two patches fix up the driver to get CEC working too.
>
> The first adds the basic support by correcting some register offsets.
>
> The second addresses an issue we saw with CEC RX on the ADV7535. It
> hasn't been tested with the other chips (e.g. ADV7533), although it
> should be compatible. I'm sending it against drm-misc-next because the
> issue wasn't reported for other chips, and ADV7535 didn't have CEC
> support before. But feel free to take it into -fixes instead.
>
> Alvin Šipraga (2):
>   drm: bridge: adv7511: enable CEC support for ADV7535
>   drm: bridge: adv7511: use non-legacy mode for CEC RX
>
>  drivers/gpu/drm/bridge/adv7511/adv7511.h |  27 -
>  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 116 +--
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |  22 +++-
>  3 files changed, 119 insertions(+), 46 deletions(-)
>
> --
> 2.35.1
>

Re: [PATCH 3/4] drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP

[Simon Ser]

On Friday, August 26th, 2022 at 10:19, Ville Syrjälä 
 wrote:

> On Wed, Aug 24, 2022 at 03:08:55PM +, Simon Ser wrote:
> > This new kernel capability indicates whether async page-flips are
> > supported via the atomic uAPI. DRM clients can use it to check
> > for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
> 
> I think we'd need to clarify the semantics of the async flag
> for atomic commits.
> 
> Eg. on Intel hw only pure page flips are possible async, if you do
> anything else (change plane size/pos/scaling/etc.) you will need
> to do a sync update. Technically not even all page flips (from the
> uapi POV) might be possible as the exact scanout source address
> is specified via two registers, only one of which can be update
> async. So technically the two framebuffers might be laid out
> just slightly differently which could prevent an async flip.
> Also only some subset of planes actually support async flips.

Also IIRC some format modifiers don't support async flip at all (CCS)?

> And on hw where multiple planes support it on the same crtc, only one
> plane can do it at a time. Well, more accurately we can only select
> one plane at a time to give us the "flip done" interrupt. I guess
> if the user wants to async flip multiple planes at the same time
> we could do them serially as opposed to in parallel to make sure
> all the flips actually happened before we signal completion of the
> entire commit. Async flips of multiple planes probably won't
> happen atomically anyway so doing them serially seems fine.
> 
> ATM in i915 we probably don't have sufficient state checks in
> place to catch all the restrictions, and instead in part we rely
> on the limited scope of the legacy async flip ioctl to make sure
> the operation doesn't attempt something the hw can't do.

Yeah, that makes sense.

In the documentation patch discussion [1], it appears it's not clear what
drivers should do when async flip isn't possible with the legacy uAPI.

For the atomic uAPI, we need to pick on of these two approaches:

1. Let the kernel fall back to a sync flip if async isn't possible. This
   simplifies user-space, but then user-space has no reliable way to figure out
   what really happened (sync or async?). That could be fixed with a new
   read-only CRTC prop indicating whether the last flip was async or not.
   However, maybe someone will come up in the future with user-space which
   needs to only apply an update if async flip is possible, in which case this
   approach falls short.
2. Make the kernel return EINVAL if async flip isn't possible. This adds more
   complexity to user-space, but enables a more reliable and deterministic
   uAPI. This is also more consistent with the rest of the existing atomic
   uAPI.

Note, current user-space would only need to opportunistically enable async
flip. IOW, I think that for current user-space plans "async if possible,
otherwise sync" is good enough. That behavior maps well to the Vulkan present
modes as well (which says that "this mode *may* result in visible tearing", but
doesn't guarantee it).

Another possible shortcoming of the proposed new uAPI here is that user-space
cannot submit a single atomic commit which updates multiple CRTCs, and
individually select which CRTC does an async flip. This could be fixed with
a "ASYNC_FLIP" CRTC prop which the kernel always resets to 0 on commit. I'm not
sure we want/need to cross that bridge right now, it would be easy enough to
add as a second step if some user-space would benefit from it.

What do you think?

[1]: 
https://lore.kernel.org/dri-devel/ASSNOUe9wtsXskZjVlf1X4pl53T7pVE0MfEzkQ_h4cX0tjnF7e3cxpwGpRNPudmIHoRuW4kz_v1AeTpXgouLpTYcI8q-lPTzc1YMLR8JiJM=@emersion.fr/

Re: [PATCH v2] drm: bridge: dw_hdmi: only trigger hotplug event on link change

[Robert Foss]

On Fri, 26 Aug 2022 at 20:57, Lucas Stach  wrote:
>
> There are two events that signal a real change of the link state: HPD going
> high means the sink is newly connected or wants the source to re-read the
> EDID, RX sense going low is a indication that the link has been disconnected.
>
> Ignore the other two events that also trigger interrupts, but don't need
> immediate attention: HPD going low does not necessarily mean the link has
> been lost and should not trigger a immediate read of the status. RX sense
> going high also does not require a detect cycle, as HPD going high is the
> right point in time to read the EDID.
>
> Signed-off-by: Lucas Stach 
> Reviewed-by: Neil Armstrong  (v1)
> ---
> v2: Take HDMI_PHY_RX_SENSE into account when reporting disconnect
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 25a60eb4d67c..40d8ca37f5bc 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -3096,6 +3096,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>  {
> struct dw_hdmi *hdmi = dev_id;
> u8 intr_stat, phy_int_pol, phy_pol_mask, phy_stat;
> +   enum drm_connector_status status = connector_status_unknown;
>
> intr_stat = hdmi_readb(hdmi, HDMI_IH_PHY_STAT0);
> phy_int_pol = hdmi_readb(hdmi, HDMI_PHY_POL0);
> @@ -3134,13 +3135,15 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> cec_notifier_phys_addr_invalidate(hdmi->cec_notifier);
> mutex_unlock(>cec_notifier_mutex);
> }
> -   }
>
> -   if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
> -   enum drm_connector_status status = phy_int_pol & HDMI_PHY_HPD
> -? connector_status_connected
> -: 
> connector_status_disconnected;
> +   if (phy_stat & HDMI_PHY_HPD)
> +   status = connector_status_connected;
> +
> +   if (!(phy_stat & (HDMI_PHY_HPD | HDMI_PHY_RX_SENSE)))
> +   status = connector_status_disconnected;
> +   }
>
> +   if (status != connector_status_unknown) {
> dev_dbg(hdmi->dev, "EVENT=%s\n",
> status == connector_status_connected ?
> "plugin" : "plugout");

Reviewed-by: Robert Foss 

Applied to drm-misc-next.

Re: [PATCH v6 2/2] drm: rcar-du: Add RZ/G2L DSI driver

[Robert Foss]

Hey Biju,

The patch does not apply on drm-misc-next, could you rebase it and
submit the next version?

Additionally it has a few 'checkpatch --strict' warnings.

On Mon, 29 Aug 2022 at 11:19, Biju Das  wrote:
>
> This driver supports the MIPI DSI encoder found in the RZ/G2L
> SoC. It currently supports DSI video mode only.
>
> Signed-off-by: Biju Das 
> Acked-by: Sam Ravnborg 
> ---
> v5->v6:
>  * Updated commit description
>  * Moved handling of arst and prst from rzg2l_mipi_dsi_startup->runtime
>PM suspend/resume handlers.
>  * Max lane capability read at probe(), and enforced in
>rzg2l_mipi_dsi_host_attach()
>  * Simplified vich1ppsetr setting.
>  * Renamed hsclk_running_mode,hsclk_mode->is_clk_cont.
>  * Fixed typo in probe error message(arst->rst).
>  * Reordered DRM bridge initaization in probe()
>  * Updated typo in e-mail address.
> v4->v5:
>  * Added Ack from Sam.
>  * Added a trivial change, replaced rzg2l_mipi_dsi_parse_dt()
>with drm_of_get_data_lanes_count_ep() in probe.
> v3->v4:
>  * Updated error handling in rzg2l_mipi_dsi_startup() and 
> rzg2l_mipi_dsi_atomic_enable()
> v2->v3:
>  * pass rzg2l_mipi_dsi pointer to {Link,Phy} register rd/wr function instead
>of the memory pointer
>  * Fixed the comment in rzg2l_mipi_dsi_startup()
>  * Removed unnecessary dbg message from rzg2l_mipi_dsi_start_video()
>  * DRM bridge parameter initialization moved to probe
>  * Replaced dev_dbg->dev_err in rzg2l_mipi_dsi_parse_dt()
>  * Inserted the missing blank lane after return in probe()
>  * Added missing MODULE_DEVICE_TABLE
>  * Added include linux/bits.h in header file
>  * Fixed various macros in header file.
>  * Reorder the make file for DSI, so that it is no more dependent
>on RZ/G2L DU patch series.
> v1->v2:
>  * Rework based on dt-binding change (DSI + D-PHY) as single block
>  * Replaced link_mmio and phy_mmio with mmio in struct rzg2l_mipi_dsi
>  * Replaced rzg2l_mipi_phy_write with rzg2l_mipi_dsi_phy_write
>and rzg2l_mipi_dsi_link_write
>  * Replaced rzg2l_mipi_phy_read->rzg2l_mipi_dsi_link_read
> RFC->v1:
>  * Added "depends on ARCH_RENESAS || COMPILE_TEST" on KCONFIG
>and dropped DRM as it is implied by DRM_BRIDGE
>  * Used devm_reset_control_get_exclusive() for reset handle
>  * Removed bool hsclkmode from struct rzg2l_mipi_dsi
>  * Added error check for pm, using pm_runtime_resume_and_get() instead of
>pm_runtime_get_sync()
>  * Added check for unsupported formats in rzg2l_mipi_dsi_host_attach()
>  * Avoided read-modify-write stopping hsclock
>  * Used devm_platform_ioremap_resource for resource allocation
>  * Removed unnecessary assert call from probe and remove.
>  * wrap the line after the PTR_ERR() in probe()
>  * Updated reset failure messages in probe
>  * Fixed the typo arstc->prstc
>  * Made hex constants to lower case.
> RFC:
>  * 
> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-23-biju.das...@bp.renesas.com/
> ---
>  drivers/gpu/drm/rcar-du/Kconfig   |   8 +
>  drivers/gpu/drm/rcar-du/Makefile  |   2 +
>  drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c  | 703 ++
>  drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 151 
>  4 files changed, 864 insertions(+)
>  create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
>  create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h
>
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index c959e8c6be7d..58ffb8c2443b 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -51,6 +51,14 @@ config DRM_RCAR_MIPI_DSI
> help
>   Enable support for the R-Car Display Unit embedded MIPI DSI 
> encoders.
>
> +config DRM_RZG2L_MIPI_DSI
> +   tristate "RZ/G2L MIPI DSI Encoder Support"
> +   depends on DRM_BRIDGE && OF
> +   depends on ARCH_RENESAS || COMPILE_TEST
> +   select DRM_MIPI_DSI
> +   help
> + Enable support for the RZ/G2L Display Unit embedded MIPI DSI 
> encoders.
> +
>  config DRM_RCAR_VSP
> bool "R-Car DU VSP Compositor Support" if ARM
> default y if ARM64
> diff --git a/drivers/gpu/drm/rcar-du/Makefile 
> b/drivers/gpu/drm/rcar-du/Makefile
> index 6f132325c8b7..b8f2c82651d9 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -14,3 +14,5 @@ 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_RZG2L_MIPI_DSI)   += rzg2l_mipi_dsi.o
> diff --git a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c 
> b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> new file mode 100644
> index ..46a71e39e336
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> @@ -0,0 +1,703 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * RZ/G2L MIPI DSI 

[PATCH v2] drm: document uAPI page-flip flags

[Simon Ser]

Document flags accepted by the page-flip and atomic IOCTLs.

v2 (Pekka):
- Mention DRM_EVENT_FLIP_COMPLETE in DRM_MODE_PAGE_FLIP_EVENT docs.
- Expand DRM_MODE_ATOMIC_NONBLOCK and DRM_MODE_ATOMIC_ALLOW_MODESET
  description.

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Pekka Paalanen 
Cc: Ville Syrjala 
---
 include/uapi/drm/drm_mode.h | 60 -
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fa953309d9ce..fa26bda6ffb3 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -935,12 +935,31 @@ struct hdr_output_metadata {
};
 };
 
+/**
+ * DRM_MODE_PAGE_FLIP_EVENT
+ *
+ * Request that the kernel sends back a vblank event (see
+ * struct drm_event_vblank) with the _EVENT_FLIP_COMPLETE type when the
+ * page-flip is done.
+ */
 #define DRM_MODE_PAGE_FLIP_EVENT 0x01
+/**
+ * DRM_MODE_PAGE_FLIP_ASYNC
+ *
+ * Request that the page-flip is performed as soon as possible, ie. with no
+ * delay due to waiting for vblank. This may cause tearing to be visible on
+ * the screen.
+ */
 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
 #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
 #define DRM_MODE_PAGE_FLIP_TARGET_RELATIVE 0x8
 #define DRM_MODE_PAGE_FLIP_TARGET (DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE | \
   DRM_MODE_PAGE_FLIP_TARGET_RELATIVE)
+/**
+ * DRM_MODE_PAGE_FLIP_FLAGS
+ *
+ * Bitmask of flags suitable for _mode_crtc_page_flip_target.flags.
+ */
 #define DRM_MODE_PAGE_FLIP_FLAGS (DRM_MODE_PAGE_FLIP_EVENT | \
  DRM_MODE_PAGE_FLIP_ASYNC | \
  DRM_MODE_PAGE_FLIP_TARGET)
@@ -1034,11 +1053,50 @@ struct drm_mode_destroy_dumb {
__u32 handle;
 };
 
-/* page-flip flags are valid, plus: */
+/**
+ * DRM_MODE_ATOMIC_TEST_ONLY
+ *
+ * Do not apply the atomic commit, instead check whether the hardware supports
+ * this configuration.
+ *
+ * See drm_mode_config_funcs.atomic_check for more details on test-only
+ * commits.
+ */
 #define DRM_MODE_ATOMIC_TEST_ONLY 0x0100
+/**
+ * DRM_MODE_ATOMIC_NONBLOCK
+ *
+ * Do not block while applying the atomic commit. The _IOCTL_MODE_ATOMIC
+ * IOCTL returns immediately instead of waiting for the changes to be applied
+ * in hardware. Note, the driver will still check that the update can be
+ * applied before retuning.
+ */
 #define DRM_MODE_ATOMIC_NONBLOCK  0x0200
+/**
+ * DRM_MODE_ATOMIC_ALLOW_MODESET
+ *
+ * Allow the update to result in temporary or transient visible artifacts while
+ * the update is being applied. Applying the update may also take significantly
+ * more time than a page flip. The visual artifacts will not appear after the
+ * update is completed.
+ *
+ * This flag must be set when the KMS update might cause visible artifacts.
+ * Without this flag such KMS update will return a EINVAL error. What kind of
+ * update may cause visible artifacts depends on the driver and the hardware.
+ * User-space that needs to know beforehand if an update might cause visible
+ * artifacts can use _MODE_ATOMIC_TEST_ONLY without
+ * _MODE_ATOMIC_ALLOW_MODESET to see if it fails.
+ *
+ * Visual artifacts are guaranteed to not appear when this flag is not set.
+ */
 #define DRM_MODE_ATOMIC_ALLOW_MODESET 0x0400
 
+/**
+ * DRM_MODE_ATOMIC_FLAGS
+ *
+ * Bitfield of flags accepted by the _IOCTL_MODE_ATOMIC IOCTL in
+ * _mode_atomic.flags.
+ */
 #define DRM_MODE_ATOMIC_FLAGS (\
DRM_MODE_PAGE_FLIP_EVENT |\
DRM_MODE_PAGE_FLIP_ASYNC |\
-- 
2.37.2

Re: drm: document uAPI page-flip flags

[Simon Ser]

CC Ville for the ASYNC bits, see below.

On Friday, August 26th, 2022 at 10:53, Pekka Paalanen  
wrote:

> > +/**
> > + * DRM_MODE_PAGE_FLIP_EVENT
> > + *
> > + * Request that the kernel sends back a vblank event (see
> > + * struct drm_event_vblank) when the page-flip is done.
> 
> ...with type = DRM_EVENT_FLIP_COMPLETE?
> 
> This was a bit new to me, because libdrm abstracts vblank and pageflip
> events into different APIs.

Indeed.

Maybe should clarify what "done" means here? Would "when the page-flip has been
displayed on-screen" be correct?

> > + */
> >  #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> > +/**
> > + * DRM_MODE_PAGE_FLIP_ASYNC
> > + *
> > + * Request that the page-flip is performed as soon as possible, ie. with no
> > + * delay due to waiting for vblank. This may cause tearing to be visible on
> > + * the screen.
> 
> Btw. does the kernel fail the flip if the driver does not support async?
> Or does it silently fall back to sync flip?
> Asking for both legacy and atomic APIs.

Atomic doesn't support this yet, so it's pretty much TBD (see Ville's reply 
[1]).

For legacy, it seems like drivers do what they want. AFAIU, i915 will reject
(see intel_async_flip_check_uapi etc), and amdgpu will silently fall back to
vsync (see the `acrtc_state->update_type == UPDATE_TYPE_FAST` check in
amdgpu_dm_commit_planes).

Maybe one of the drivers is wrong here and should be fixed?

[1]: https://lore.kernel.org/dri-devel/ywib%2fxqf6z6sc...@intel.com/

> > +/**
> > + * DRM_MODE_ATOMIC_NONBLOCK
> > + *
> > + * Do not block while applying the atomic commit.
> 
> Maybe add something like:
> 
>   The atomic commit ioctl returns immediately instead of waiting
>   for the changes to be applied in hardware.

Good idea. Also added:

Note, the driver will still check that the update can be applied before
retuning.

> > + */
> >  #define DRM_MODE_ATOMIC_NONBLOCK  0x0200
> > +/**
> > + * DRM_MODE_ATOMIC_ALLOW_MODESET
> > + *
> > + * Allow the update to result in visible artifacts such as a black screen.
> 
> Maybe add:
> 
>   ...temporary or transient visible artifacts while the update is
>   being applied. Applying the update may also take significantly
>   more time than a page flip. The visual artifacts will not
>   appear after the update is completed.
> 
>   This flag must be set when the KMS update might cause visible
>   artifacts. Without this flag such KMS update will return EINVAL
>   error. What kind of updates may cause visible artifacts depends
>   on the driver and the hardware. Userspace that needs to know
>   beforehand if an update might cause visible artifacts can use
>   DRM_MODE_ATOMIC_TEST_ONLY without DRM_MODE_ATOMIC_ALLOW_MODESET
>   to see if it fails.
> 
>   Visual artifacts are guaranteed to not appear when this flag is
>   not set.
> 
> That "artifacts will not appear after the update is completed" is a bit
> awkward, because when this commit completes and triggers the completion
> event (if requested), the visual artifacts might still be on screen, but
> as soon as the scanout cycle that just started finishes, all artifacts
> are gone for good. Isn't that how it works?
> 
> Or does the kernel wait with the completion event until a good picture
> has been fully scanned out at least once? I'd expect not.

That generally looks like a good description to me, and AFAIK is how things
work indeed.

Re: [PATCH] drm/bridge: lvds-codec: Fix error checking of drm_of_lvds_get_data_mapping()

[Robert Foss]

On Wed, 10 Aug 2022 at 11:27, Neil Armstrong  wrote:
>
> On 01/08/2022 14:54, Marek Vasut wrote:
> > The drm_of_lvds_get_data_mapping() returns either negative value on
> > error or MEDIA_BUS_FMT_* otherwise. The check for 'ret' would also
> > catch the positive case of MEDIA_BUS_FMT_* and lead to probe failure
> > every time 'data-mapping' DT property is specified.
> >
> > Fixes: 7c4dd0a266527 ("drm: of: Add drm_of_lvds_get_data_mapping")
> > Signed-off-by: Marek Vasut 
> > Cc: Laurent Pinchart 
> > Cc: Sam Ravnborg 
> > To: dri-devel@lists.freedesktop.org
> > ---
> >   drivers/gpu/drm/bridge/lvds-codec.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c 
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > index 702ea803a743c..39e7004de7200 100644
> > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -180,7 +180,7 @@ static int lvds_codec_probe(struct platform_device 
> > *pdev)
> >   of_node_put(bus_node);
> >   if (ret == -ENODEV) {
> >   dev_warn(dev, "missing 'data-mapping' DT property\n");
> > - } else if (ret) {
> > + } else if (ret < 0) {
> >   dev_err(dev, "invalid 'data-mapping' DT property\n");
> >   return ret;
> >   } else {
>
> Reviewed-by: Neil Armstrong 

Applied to drm-misc-next.

[PATCH v2 2/3] drm/atomic-helper: log EINVAL cause in drm_atomic_helper_async_check()

[Simon Ser]

This can help figure out why the kernel returns EINVAL from
user-space.

v2: add missing newlines

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Lyude Paul 
---
 drivers/gpu/drm/drm_atomic_helper.c | 32 +++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 4aa05b626b57..d36720f419f7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1796,7 +1796,7 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
struct drm_plane_state *old_plane_state = NULL;
struct drm_plane_state *new_plane_state = NULL;
const struct drm_plane_helper_funcs *funcs;
-   int i, n_planes = 0;
+   int i, ret, n_planes = 0;
 
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (drm_atomic_crtc_needs_modeset(crtc_state))
@@ -1807,19 +1807,34 @@ int drm_atomic_helper_async_check(struct drm_device 
*dev,
n_planes++;
 
/* FIXME: we support only single plane updates for now */
-   if (n_planes != 1)
+   if (n_planes != 1) {
+   drm_dbg_atomic(dev,
+  "only single plane async updates are 
supported\n");
return -EINVAL;
+   }
 
if (!new_plane_state->crtc ||
-   old_plane_state->crtc != new_plane_state->crtc)
+   old_plane_state->crtc != new_plane_state->crtc) {
+   drm_dbg_atomic(dev,
+  "[PLANE:%d:%s] async update cannot change 
CRTC\n",
+  plane->base.id, plane->name);
return -EINVAL;
+   }
 
funcs = plane->helper_private;
-   if (!funcs->atomic_async_update)
+   if (!funcs->atomic_async_update) {
+   drm_dbg_atomic(dev,
+  "[PLANE:%d:%s] driver does not support async 
updates\n",
+  plane->base.id, plane->name);
return -EINVAL;
+   }
 
-   if (new_plane_state->fence)
+   if (new_plane_state->fence) {
+   drm_dbg_atomic(dev,
+  "[PLANE:%d:%s] missing fence for async update\n",
+  plane->base.id, plane->name);
return -EINVAL;
+   }
 
/*
 * Don't do an async update if there is an outstanding commit modifying
@@ -1834,7 +1849,12 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
return -EBUSY;
}
 
-   return funcs->atomic_async_check(plane, state);
+   ret = funcs->atomic_async_check(plane, state);
+   if (ret != 0)
+   drm_dbg_atomic(dev,
+  "[PLANE:%d:%s] driver async check failed\n",
+  plane->base.id, plane->name);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_async_check);
 
-- 
2.37.2

[PATCH v2 3/3] drm/bridge: log message on atomic_check() and mode_fixup() failure

[Simon Ser]

This helps user-space understand why an atomic commit fails.

v2: new patch

Signed-off-by: Simon Ser 
---
 drivers/gpu/drm/drm_bridge.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1545c50fd1c8..c41c728b0c28 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -830,12 +830,26 @@ static int drm_atomic_bridge_check(struct drm_bridge 
*bridge,
 
ret = bridge->funcs->atomic_check(bridge, bridge_state,
  crtc_state, conn_state);
-   if (ret)
+   if (ret) {
+   drm_dbg_atomic(bridge->dev,
+  "bridge driver check failed for 
[CRTC:%d:%s] and [CONNECTOR:%d:%s]\n",
+  crtc_state->crtc->base.id,
+  crtc_state->crtc->name,
+  conn_state->connector->base.id,
+  conn_state->connector->name);
return ret;
+   }
} else if (bridge->funcs->mode_fixup) {
if (!bridge->funcs->mode_fixup(bridge, _state->mode,
-  _state->adjusted_mode))
+  _state->adjusted_mode)) {
+   drm_dbg_atomic(bridge->dev,
+  "bridge mode fixup failed for 
[CRTC:%d:%s] and [CONNECTOR:%d:%s]\n",
+  crtc_state->crtc->base.id,
+  crtc_state->crtc->name,
+  conn_state->connector->base.id,
+  conn_state->connector->name);
return -EINVAL;
+   }
}
 
return 0;
-- 
2.37.2

[PATCH v2 1/3] drm/atomic-helper: print message on driver connector check failure

[Simon Ser]

Sometimes drivers are missing logs when they return EINVAL.
Printing the failure here in common code can help understand where
EINVAL is coming from.

All other atomic_check() calls in this file already have similar
logging.

v2: add missing newlines

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Lyude Paul 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c6abfd3d4b62..4aa05b626b57 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -702,8 +702,12 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 
if (funcs->atomic_check)
ret = funcs->atomic_check(connector, state);
-   if (ret)
+   if (ret) {
+   drm_dbg_atomic(dev,
+  "[CONNECTOR:%d:%s] driver check 
failed\n",
+  connector->base.id, connector->name);
return ret;
+   }
 
connectors_mask |= BIT(i);
}
@@ -745,8 +749,12 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 
if (funcs->atomic_check)
ret = funcs->atomic_check(connector, state);
-   if (ret)
+   if (ret) {
+   drm_dbg_atomic(dev,
+  "[CONNECTOR:%d:%s] driver check 
failed\n",
+  connector->base.id, connector->name);
return ret;
+   }
}
 
/*
-- 
2.37.2

Re: [PATCH v1 0/7] drm/vc4: Fix the core clock behaviour

[Maxime Ripard]

Hi Stephen, Mike,

On Mon, Aug 15, 2022 at 05:31:22PM +0200, Maxime Ripard wrote:
> Those patches used to be part of a larger clock fixes series:
> https://lore.kernel.org/linux-clk/20220715160014.2623107-1-max...@cerno.tech/
> 
> However, that series doesn't seem to be getting anywhere, so I've split out
> these patches that fix a regression that has been there since 5.18 and that
> prevents the 4k output from working on the RaspberryPi4.
> 
> Hopefully, we will be able to merge those patches through the DRM tree to 
> avoid
> any further disruption.

I've ping'd Stephen privately on IRC multiple times, and it's basically
a resend of the previous clock series linked above that has been around
since almost a month and a half.

Can you Ack the first three patches so we can merge those patches
through the DRM tree and close this regression?

Maxime


signature.asc
Description: PGP signature

Re: [PATCH 0/6] TI SN65DSI83 Features

[Robert Foss]

Hey Marco,

Sorry about the slow reply.

This series no longer applies on drm-misc-next. Can you rebase this
series and send it out a v2?


Rob.

Re: [PATCH] drm/bridge: megachips: Fix a null pointer dereference bug

[Robert Foss]

On Sat, 16 Jul 2022 at 10:13, Zheyu Ma  wrote:
>
> When removing the module we will get the following warning:
>
> [   31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered
> [   31.912484] general protection fault, probably for non-canonical address 
> 0xdc01:  [#1] PREEMPT SMP KASAN PTI
> [   31.913338] KASAN: null-ptr-deref in range 
> [0x0008-0x000f]
> [   31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130
> [   31.921825] Call Trace:
> [   31.922533]  stdp4028_ge_b850v3_fw_remove+0x34/0x60 
> [megachips_stdp_ge_b850v3_fw]
> [   31.923139]  i2c_device_remove+0x181/0x1f0
>
> The two bridges (stdp2690, stdp4028) do not probe at the same time, so
> the driver does not call ge_b850v3_resgiter() when probing, causing the
> driver to try to remove the object that has not been initialized.
>
> Fix this by checking whether both the bridges are probed.
>
> Signed-off-by: Zheyu Ma 
> ---
>  drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c 
> b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> index cce98bf2a4e7..c68a4cdf4625 100644
> --- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> @@ -296,7 +296,9 @@ static void ge_b850v3_lvds_remove(void)
>  * This check is to avoid both the drivers
>  * removing the bridge in their remove() function
>  */
> -   if (!ge_b850v3_lvds_ptr)
> +   if (!ge_b850v3_lvds_ptr ||
> +   !ge_b850v3_lvds_ptr->stdp2690_i2c ||
> +   !ge_b850v3_lvds_ptr->stdp4028_i2c)

This chunk fails checkpatch --strict.

Alignment should match open parenthesis
#39: FILE: drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c:300:


> goto out;
>
> drm_bridge_remove(_b850v3_lvds_ptr->bridge);
> --
> 2.25.1
>

[PATCH 1/2] drm/atomic-helper: print message on driver connector check failure

[Simon Ser]

Sometimes drivers are missing logs when they return EINVAL.
Printing the failure here in common code can help understand where
EINVAL is coming from.

All other atomic_check() calls in this file already have similar
logging.

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Lyude Paul 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c6abfd3d4b62..fbdcca3047f2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -702,8 +702,12 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 
if (funcs->atomic_check)
ret = funcs->atomic_check(connector, state);
-   if (ret)
+   if (ret) {
+   drm_dbg_atomic(dev,
+  "[CONNECTOR:%d:%s] driver check failed",
+  connector->base.id, connector->name);
return ret;
+   }
 
connectors_mask |= BIT(i);
}
@@ -745,8 +749,12 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 
if (funcs->atomic_check)
ret = funcs->atomic_check(connector, state);
-   if (ret)
+   if (ret) {
+   drm_dbg_atomic(dev,
+  "[CONNECTOR:%d:%s] driver check failed",
+  connector->base.id, connector->name);
return ret;
+   }
}
 
/*
-- 
2.37.2

[PATCH 2/2] drm/atomic-helper: log EINVAL cause in drm_atomic_helper_async_check()

[Simon Ser]

This can help figure out why the kernel returns EINVAL from
user-space.

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Lyude Paul 
---
 drivers/gpu/drm/drm_atomic_helper.c | 32 +++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fbdcca3047f2..63a0e1553408 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1796,7 +1796,7 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
struct drm_plane_state *old_plane_state = NULL;
struct drm_plane_state *new_plane_state = NULL;
const struct drm_plane_helper_funcs *funcs;
-   int i, n_planes = 0;
+   int i, ret, n_planes = 0;
 
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (drm_atomic_crtc_needs_modeset(crtc_state))
@@ -1807,19 +1807,34 @@ int drm_atomic_helper_async_check(struct drm_device 
*dev,
n_planes++;
 
/* FIXME: we support only single plane updates for now */
-   if (n_planes != 1)
+   if (n_planes != 1) {
+   drm_dbg_atomic(dev,
+  "only single plane async updates are 
supported\n");
return -EINVAL;
+   }
 
if (!new_plane_state->crtc ||
-   old_plane_state->crtc != new_plane_state->crtc)
+   old_plane_state->crtc != new_plane_state->crtc) {
+   drm_dbg_atomic(dev,
+  "[PLANE:%d:%s] async update cannot change 
CRTC\n",
+  plane->base.id, plane->name);
return -EINVAL;
+   }
 
funcs = plane->helper_private;
-   if (!funcs->atomic_async_update)
+   if (!funcs->atomic_async_update) {
+   drm_dbg_atomic(dev,
+  "[PLANE:%d:%s] driver does not support async 
updates\n",
+  plane->base.id, plane->name);
return -EINVAL;
+   }
 
-   if (new_plane_state->fence)
+   if (new_plane_state->fence) {
+   drm_dbg_atomic(dev,
+  "[PLANE:%d:%s] missing fence for async update\n",
+  plane->base.id, plane->name);
return -EINVAL;
+   }
 
/*
 * Don't do an async update if there is an outstanding commit modifying
@@ -1834,7 +1849,12 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
return -EBUSY;
}
 
-   return funcs->atomic_async_check(plane, state);
+   ret = funcs->atomic_async_check(plane, state);
+   if (ret != 0)
+   drm_dbg_atomic(dev,
+  "[PLANE:%d:%s] driver async check failed",
+  plane->base.id, plane->name);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_async_check);
 
-- 
2.37.2

Re: [PATCH] drm/bridge: tc358767: Handle bridge past DPI output

[Robert Foss]

Hi Marek,

On Mon, 25 Jul 2022 at 00:43, Marek Vasut  wrote:
>
> Currently the driver only handles panel directly connected to the DPI output.
> Handle the case where a bridge is connected past DPI output of this bridge.
> This could be e.g. DPI to LVDS encoder chip.
>
> Signed-off-by: Marek Vasut 
> Cc: Jonas Karlman 
> Cc: Laurent Pinchart 
> Cc: Lucas Stach 
> Cc: Maxime Ripard 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Sam Ravnborg 
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index f8c1cd711753b..814ab206fe7ef 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1926,22 +1926,23 @@ static int tc_mipi_dsi_host_attach(struct tc_data *tc)
>  static int tc_probe_dpi_bridge_endpoint(struct tc_data *tc)
>  {
> struct device *dev = tc->dev;
> +   struct drm_bridge *bridge;
> struct drm_panel *panel;
> int ret;
>
> /* port@1 is the DPI input/output port */
> -   ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, , NULL);
> +   ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, , 
> );
> if (ret && ret != -ENODEV)
> return ret;
>
> if (panel) {
> -   struct drm_bridge *panel_bridge;
> -
> -   panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> -   if (IS_ERR(panel_bridge))
> -   return PTR_ERR(panel_bridge);
> +   bridge = devm_drm_panel_bridge_add(dev, panel);
> +   if (IS_ERR(bridge))
> +   return PTR_ERR(bridge);
> +   }
>
> -   tc->panel_bridge = panel_bridge;
> +   if (bridge) {
> +   tc->panel_bridge = bridge;
> tc->bridge.type = DRM_MODE_CONNECTOR_DPI;
> tc->bridge.funcs = _dpi_bridge_funcs;
>
> --
> 2.35.1

Reviewed-by: Robert Foss 

Applied to drm-misc-next.

Re: [PATCH 2/2] drm: bridge: icn6211: Add support for external REFCLK

[Robert Foss]

Hey Marek,

On Mon, 1 Aug 2022 at 15:18, Marek Vasut  wrote:
>
> The ICN6211 is capable of deriving its internal PLL clock from either
> MIPI DSI HS clock, external REFCLK clock, or even internal oscillator.
> Currently supported is only the first option. Add support for external
> REFCLK clock input in addition to that.
>
> There is little difference between these options, except that in case
> of MIPI DSI HS clock input, the HS clock are pre-divided by a fixed /4
> divider before being fed to the PLL input, while in case of external
> REFCLK, the RECLK clock are fed directly into the PLL input.
>
> Per exceptionally poor documentation, the REFCLK must be in range of
> 10..154 MHz.
>
> Signed-off-by: Marek Vasut 
> Cc: Jagan Teki 
> Cc: Laurent Pinchart 
> Cc: Linus Walleij 
> Cc: Robert Foss 
> Cc: Sam Ravnborg 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/bridge/chipone-icn6211.c | 39 +---
>  1 file changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c 
> b/drivers/gpu/drm/bridge/chipone-icn6211.c
> index 65966f280cf4e..7ee1858bab321 100644
> --- a/drivers/gpu/drm/bridge/chipone-icn6211.c
> +++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
> @@ -11,6 +11,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -151,6 +152,8 @@ struct chipone {
> struct regulator *vdd1;
> struct regulator *vdd2;
> struct regulator *vdd3;
> +   struct clk *refclk;
> +   unsigned long refclk_rate;
> bool interface_i2c;
>  };
>
> @@ -273,7 +276,10 @@ static void chipone_configure_pll(struct chipone *icn,
>  * It seems the PLL input clock after applying P pre-divider have
>  * to be lower than 20 MHz.
>  */
> -   fin = icn->dsi->hs_rate / 4; /* in Hz */
> +   if (icn->refclk)
> +   fin = icn->refclk_rate;
> +   else
> +   fin = icn->dsi->hs_rate / 4; /* in Hz */
>
> /* Minimum value of P predivider for PLL input in 5..20 MHz */
> p_min = clamp(DIV_ROUND_UP(fin, 2000), 1U, 31U);
> @@ -318,16 +324,18 @@ static void chipone_configure_pll(struct chipone *icn,
> best_p_pot = !(best_p & 1);
>
> dev_dbg(icn->dev,
> -   "PLL: P[3:0]=%d P[4]=2*%d M=%d S[7:5]=2^%d delta=%d => DSI 
> f_in=%d Hz ; DPI f_out=%d Hz\n",
> +   "PLL: P[3:0]=%d P[4]=2*%d M=%d S[7:5]=2^%d delta=%d => DSI 
> f_in(%s)=%d Hz ; DPI f_out=%d Hz\n",
> best_p >> best_p_pot, best_p_pot, best_m, best_s + 1,
> -   min_delta, fin, (fin * best_m) / (best_p << (best_s + 1)));
> +   min_delta, icn->refclk ? "EXT" : "DSI", fin,
> +   (fin * best_m) / (best_p << (best_s + 1)));
>
> ref_div = PLL_REF_DIV_P(best_p >> best_p_pot) | PLL_REF_DIV_S(best_s);
> if (best_p_pot) /* Prefer /2 pre-divider */
> ref_div |= PLL_REF_DIV_Pe;
>
> -   /* Clock source selection fixed to MIPI DSI clock lane */
> -   chipone_writeb(icn, PLL_CTRL(6), PLL_CTRL_6_MIPI_CLK);
> +   /* Clock source selection either external clock or MIPI DSI clock 
> lane */
> +   chipone_writeb(icn, PLL_CTRL(6),
> +  icn->refclk ? PLL_CTRL_6_EXTERNAL : 
> PLL_CTRL_6_MIPI_CLK);
> chipone_writeb(icn, PLL_REF_DIV, ref_div);
> chipone_writeb(icn, PLL_INT(0), best_m);
>  }
> @@ -463,6 +471,11 @@ static void chipone_atomic_pre_enable(struct drm_bridge 
> *bridge,
>   "failed to enable VDD3 regulator: 
> %d\n", ret);
> }
>
> +   ret = clk_prepare_enable(icn->refclk);
> +   if (ret)
> +   DRM_DEV_ERROR(icn->dev,
> + "failed to enable RECLK clock: %d\n", ret);
> +
> gpiod_set_value(icn->enable_gpio, 1);
>
> usleep_range(1, 11000);
> @@ -473,6 +486,8 @@ static void chipone_atomic_post_disable(struct drm_bridge 
> *bridge,
>  {
> struct chipone *icn = bridge_to_chipone(bridge);
>
> +   clk_disable_unprepare(icn->refclk);
> +
> if (icn->vdd1)
> regulator_disable(icn->vdd1);
>
> @@ -618,6 +633,20 @@ static int chipone_parse_dt(struct chipone *icn)
> struct device *dev = icn->dev;
> int ret;
>
> +   icn->refclk = devm_clk_get_optional(dev, "refclk");
> +   if (IS_ERR(icn->refclk)) {
> +   ret = PTR_ERR(icn->refclk);
> +   DRM_DEV_ERROR(dev, "failed to get REFCLK clock: %d\n", ret);
> +   return ret;
> +   } else if (icn->refclk) {
> +   icn->refclk_rate = clk_get_rate(icn->refclk);
> +   if (icn->refclk_rate < 1000 || icn->refclk_rate > 
> 15400) {
> +   DRM_DEV_ERROR(dev, "REFCLK out of range: %ld Hz\n",
> + icn->refclk_rate);
> +   return -EINVAL;
> +   }
> +   }
> +
> icn->vdd1 = 

Re: [PATCH 4/4] drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate function

[Govindapillai, Vinod]

Hi Stan,

I wonder if it is better if you reorder the 3 and 4 patches in this - move this 
4/4 before the 3rd
one and modify the 3rd one accordingly.

Also, instead of getting rid of limits, keep limits and populate the limits 
according to dsc or
normal dp_mst. What do you think?

BR
vinod


On Mon, 2022-08-29 at 12:58 +0300, Stanislav Lisovskiy wrote:
> We are using almost same code to loop through bpps while calling
> drm_dp_atomic_find_vcpi_slots - lets remove this duplication by
> introducing a new function intel_dp_mst_find_vcpi_slots_for_bpp
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 88 +++--
>  1 file changed, 46 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 94d7e7f84c51..2a524816dbfd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -44,10 +44,14 @@
>  #include "intel_hotplug.h"
>  #include "skl_scaler.h"
>  
> -static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
> -   struct intel_crtc_state 
> *crtc_state,
> -   struct drm_connector_state 
> *conn_state,
> -   struct link_config_limits *limits)
> +static int intel_dp_mst_find_vcpi_slots_for_bpp(struct intel_encoder 
> *encoder,
> +   struct intel_crtc_state 
> *crtc_state,
> +   int max_bpp,
> +   int min_bpp,
> +   struct link_config_limits 
> *limits,
> +   struct drm_connector_state 
> *conn_state,
> +   int step,
> +   bool dsc)
>  {
> struct drm_atomic_state *state = crtc_state->uapi.state;
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> @@ -58,7 +62,6 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
> struct drm_i915_private *i915 = to_i915(connector->base.dev);
> const struct drm_display_mode *adjusted_mode =
> _state->hw.adjusted_mode;
> -   bool constant_n = drm_dp_has_quirk(_dp->desc, 
> DP_DPCD_QUIRK_CONSTANT_N);
> int bpp, slots = -EINVAL;
> int ret = 0;
>  
> @@ -71,19 +74,21 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
>  
> // TODO: Handle pbn_div changes by adding a new MST helper
> if (!mst_state->pbn_div) {
> -   mst_state->pbn_div = 
> drm_dp_get_vc_payload_bw(_dp->mst_mgr,
> - 
> limits->max_rate,
> - 
> limits->max_lane_count);
> +   mst_state->pbn_div = !dsc ? 
> drm_dp_get_vc_payload_bw(_dp->mst_mgr,
> +    
> crtc_state->port_clock,
> +    
> crtc_state->lane_count) : 0;
> }
>  
> -   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> +   for (bpp = max_bpp; bpp >= min_bpp; bpp -= step) {
> crtc_state->pipe_bpp = bpp;
>  
> crtc_state->pbn = 
> drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock,
> -  crtc_state->pipe_bpp,
> -  false);
> +  dsc ? bpp << 4 : 
> crtc_state->pipe_bpp,
> +  dsc);
> +
> slots = drm_dp_atomic_find_time_slots(state, 
> _dp->mst_mgr,
> - connector->port, 
> crtc_state->pbn);
> + connector->port,
> + crtc_state->pbn);
> if (slots == -EDEADLK)
> return slots;
> if (slots >= 0) {
> @@ -101,11 +106,32 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
> if (ret && slots >= 0)
> slots = ret;
>  
> -   if (slots < 0) {
> +   if (slots < 0)
> drm_dbg_kms(>drm, "failed finding vcpi slots:%d\n",
>     slots);
> +
> +   return slots;
> +}
> +
> +
> +static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
> +   struct intel_crtc_state 
> *crtc_state,
> +   struct drm_connector_state 
> *conn_state,
> +   

Re: [PATCH v5 4/4] drm/bridge: ti-sn65dsi86: Implement bridge connector operations

[Robert Foss]

On Sat, 27 Aug 2022 at 03:10, Laurent Pinchart
 wrote:
>
> Hi Tomi,
>
> On Wed, Aug 24, 2022 at 04:00:34PM +0300, Tomi Valkeinen wrote:
> > From: Laurent Pinchart 
> >
> > Implement the bridge connector-related .get_edid() and .detect()
> > operations, and report the related bridge capabilities and type.
> >
> > These ops are only added for DP mode. They should also be used for eDP
> > mode, but the driver seems to be mostly used for eDP and, according to
> > the comments, they've had issues with eDP panels and HPD. So better be
> > safe and only enable them for DP for now.
> >
> > Signed-off-by: Laurent Pinchart 
> > Signed-off-by: Kieran Bingham 
> > Signed-off-by: Tomi Valkeinen 
>
> This patch is missing a third-party review, so I won't apply the series
> to my tree but will let you pushing it through drm-misc once we get the
> necessary review.
>
> > ---
> > Changes since v1:
> >
> > - The connector .get_modes() operation doesn't rely on EDID anymore,
> >   __ti_sn_bridge_get_edid() and ti_sn_bridge_get_edid() got merged
> >   together
> >  - Fix on top of Sam Ravnborg's DRM_BRIDGE_STATE_OPS
> >
> > Changes since v2: [Kieran]
> >  - Only support EDID on DRM_MODE_CONNECTOR_DisplayPort modes.
> >
> > Changes since v3: [Kieran]
> >  - Remove PM calls in ti_sn_bridge_get_edid() and simplify
> >
> > Changes since v4:
> >  - Add .detect()
> > ---
> >  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 28 +++
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index a6b15ea4e84d..dd20624adc70 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -68,6 +69,7 @@
> >  #define  BPP_18_RGB  BIT(0)
> >  #define SN_HPD_DISABLE_REG   0x5C
> >  #define  HPD_DISABLE BIT(0)
> > +#define  HPD_DEBOUNCED_STATE BIT(4)
> >  #define SN_GPIO_IO_REG   0x5E
> >  #define  SN_GPIO_INPUT_SHIFT 4
> >  #define  SN_GPIO_OUTPUT_SHIFT0
> > @@ -1163,10 +1165,33 @@ static void ti_sn_bridge_atomic_post_disable(struct 
> > drm_bridge *bridge,
> >   pm_runtime_put_sync(pdata->dev);
> >  }
> >
> > +static enum drm_connector_status ti_sn_bridge_detect(struct drm_bridge 
> > *bridge)
> > +{
> > + struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > + int val = 0;
> > +
> > + pm_runtime_get_sync(pdata->dev);
>
> Would this
>
> int ret;
>
> ret = pm_runtime_resume_and_get(pdata->dev);
> if (ret)
> return connector_status_disconnected;
>
> (or possibly connector_status_unknown) help avoiding problems ?
>
> Apart from that, the patch looks good to me.
>
> > + regmap_read(pdata->regmap, SN_HPD_DISABLE_REG, );
> > + pm_runtime_put_autosuspend(pdata->dev);
> > +
> > + return val & HPD_DEBOUNCED_STATE ? connector_status_connected
> > +  : connector_status_disconnected;
> > +}
> > +
> > +static struct edid *ti_sn_bridge_get_edid(struct drm_bridge *bridge,
> > +   struct drm_connector *connector)
> > +{
> > + struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > +
> > + return drm_get_edid(connector, >aux.ddc);
> > +}
> > +
> >  static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
> >   .attach = ti_sn_bridge_attach,
> >   .detach = ti_sn_bridge_detach,
> >   .mode_valid = ti_sn_bridge_mode_valid,
> > + .get_edid = ti_sn_bridge_get_edid,
> > + .detect = ti_sn_bridge_detect,
> >   .atomic_pre_enable = ti_sn_bridge_atomic_pre_enable,
> >   .atomic_enable = ti_sn_bridge_atomic_enable,
> >   .atomic_disable = ti_sn_bridge_atomic_disable,
> > @@ -1262,6 +1287,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device 
> > *adev,
> >   pdata->bridge.type = pdata->next_bridge->type == 
> > DRM_MODE_CONNECTOR_DisplayPort
> >  ? DRM_MODE_CONNECTOR_DisplayPort : 
> > DRM_MODE_CONNECTOR_eDP;
> >
> > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
> > + pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT;
> > +
> >   drm_bridge_add(>bridge);
> >
> >   ret = ti_sn_attach_host(pdata);
> > --
> > 2.34.1

I think this patch looks good, please add my r-b.

@Laurent: I'll let you apply this, if you want the above suggestion to
be included.

Reviewed-by: Robert Foss 

[PATCH] drm/amd/amdgpu: Add modeset module parameter support

[Zhen Ni]

Nomodeset kernel parameter is for all graphics cards. Amdgpu cannot
be set separately in some scenarios, such as hybrid graphics(i + a).
Add modeset module parameter for amdgpu to set kernel mode separately.

Signed-off-by: Zhen Ni 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 429fcdf28836..856a70370e3c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -107,6 +107,7 @@
 #define KMS_DRIVER_MINOR   48
 #define KMS_DRIVER_PATCHLEVEL  0
 
+int amdgpu_modeset = -1;
 int amdgpu_vram_limit;
 int amdgpu_vis_vram_limit;
 int amdgpu_gart_size = -1; /* auto */
@@ -199,6 +200,13 @@ struct amdgpu_watchdog_timer amdgpu_watchdog_timer = {
.period = 0x0, /* default to 0x0 (timeout disable) */
 };
 
+/**
+ * DOC: modeset (int)
+ * Disable/Enable kernel modesetting (1 = enable, 0 = disable, -1 = auto 
(default)).
+ */
+MODULE_PARM_DESC(modeset, "Disable/Enable kernel modesetting");
+module_param_named(modeset, amdgpu_modeset, int, 0400);
+
 /**
  * DOC: vramlimit (int)
  * Restrict the total amount of VRAM in MiB for testing.  The default is 0 
(Use full VRAM).
@@ -2753,7 +2761,10 @@ static int __init amdgpu_init(void)
 {
int r;
 
-   if (drm_firmware_drivers_only())
+   if (drm_firmware_drivers_only() && amdgpu_modeset == -1)
+   amdgpu_modeset = 0;
+
+   if (amdgpu_modeset == 0)
return -EINVAL;
 
r = amdgpu_sync_init();
-- 
2.20.1

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

On Mon, Aug 29, 2022 at 04:14:54PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Mon, Aug 29, 2022 at 3:30 PM Maxime Ripard  wrote:
> > On Wed, Aug 24, 2022 at 06:42:18PM +0200, Mateusz Kwiatkowski wrote:
> > > - Speaking of closed captioning... a lot of different stuff were put in 
> > > the
> > >   blanking interval over the years. Like teletext in Europe. There are 
> > > projects
> > >   like VBIT2  which intentionally
> > >   reconfigure the Raspberry Pi composite output to include the blanking 
> > > interval
> > >   in the framebuffer so that teletext can be output by drawing on the 
> > > edge of
> > >   the "screen" (from the computer point of view).
> >
> > I'm not sure how we would support this in KMS to be honest. Asking for a
> > wider mode and the userspace putting whatever it wants in the margins
> > seems like a good choice.
> 
> s/wider/higher/
> 
> Teletext is transmitted in the "visible" parts of (horizontal) lines, but 
> during
> the vertical blank.

Yeah, sorry I meant wider as in larger than the active area, without any
direction in mind. Thanks for the correction :)

Maxime


signature.asc
Description: PGP signature

Re: [PATCH 2/4] drm/i915: Fix intel_dp_mst_compute_link_config

[Govindapillai, Vinod]

Reviewed-by: Vinod Govindapillai 


On Mon, 2022-08-29 at 12:58 +0300, Stanislav Lisovskiy wrote:
> We currently always exit that bpp loop because drm_dp_atomic_find_vcpi_slots
> doesn't care if we actually can fit those or not.
> I think that wasn't the initial intention here, especially when
> we keep trying with lower bpps, we are supposed to keep trying
> until we actually find some _working_ configuration, which isn't the
> case here.
> So added that drm_dp_mst_check here, so that we can make sure
> that try all the bpps before we fail.
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 13abe2b2170e..c4f92edbdd08 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -60,6 +60,7 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
> _state->hw.adjusted_mode;
> bool constant_n = drm_dp_has_quirk(_dp->desc, 
> DP_DPCD_QUIRK_CONSTANT_N);
> int bpp, slots = -EINVAL;
> +   int ret = 0;
>  
> mst_state = drm_atomic_get_mst_topology_state(state, 
> _dp->mst_mgr);
> if (IS_ERR(mst_state))
> @@ -85,10 +86,21 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   connector->port, 
> crtc_state->pbn);
> if (slots == -EDEADLK)
> return slots;
> -   if (slots >= 0)
> -   break;
> +   if (slots >= 0) {
> +   ret = drm_dp_mst_atomic_check(state);
> +   /*
> +    * If we got slots >= 0 and we can fit those based on 
> check
> +    * then we can exit the loop. Otherwise keep trying.
> +    */
> +   if (!ret)
> +   break;
> +   }
> }
>  
> +   /* Despite slots are non-zero, we still failed the atomic check */
> +   if (ret && slots >= 0)
> +   slots = ret;
> +
> if (slots < 0) {
> drm_dbg_kms(>drm, "failed finding vcpi slots:%d\n",
>     slots);

Re: [PATCH] drm/i915: fix repeated words in comments

[Jani Nikula]

On Tue, 23 Aug 2022, Jilin Yuan  wrote:
>  Delete the redundant word 'other'.
>  Delete the redundant word 'the'.
>  Delete the redundant word 'will'.
>
> Signed-off-by: Jilin Yuan 

Doesn't apply because some of the hunks were already fixed by other
commits.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
>  drivers/gpu/drm/i915/i915_irq.c   | 4 ++--
>  drivers/gpu/drm/i915/i915_memcpy.h| 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index f025ee4fa526..028e509e1628 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -256,7 +256,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
>   goto search_again;
>  
>  found:
> - /* drm_mm doesn't allow any other other operations while
> + /* drm_mm doesn't allow any other operations while
>* scanning, therefore store to-be-evicted objects on a
>* temporary list and take a reference for all before
>* calling unbind (which may remove the active reference
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 73cebc6aa650..1e4a705bc5cc 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -65,7 +65,7 @@
>  
>  /*
>   * Interrupt statistic for PMU. Increments the counter only if the
> - * interrupt originated from the the GPU so interrupts from a device which
> + * interrupt originated from the GPU so interrupts from a device which
>   * shares the interrupt line are not accounted.
>   */
>  static inline void pmu_irq_stats(struct drm_i915_private *i915,
> @@ -2175,7 +2175,7 @@ static irqreturn_t ilk_irq_handler(int irq, void *arg)
>   raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
>  
>   /* Disable south interrupts. We'll only write to SDEIIR once, so further
> -  * interrupts will will be stored on its back queue, and then we'll be
> +  * interrupts will be stored on its back queue, and then we'll be
>* able to process them after we restore SDEIER (as soon as we restore
>* it, we'll get an interrupt if SDEIIR still has something to process
>* due to its back queue). */
> diff --git a/drivers/gpu/drm/i915/i915_memcpy.h 
> b/drivers/gpu/drm/i915/i915_memcpy.h
> index 3df063a3293b..126dfb4352f0 100644
> --- a/drivers/gpu/drm/i915/i915_memcpy.h
> +++ b/drivers/gpu/drm/i915/i915_memcpy.h
> @@ -18,7 +18,7 @@ void i915_unaligned_memcpy_from_wc(void *dst, const void 
> *src, unsigned long len
>  /* The movntdqa instructions used for memcpy-from-wc require 16-byte 
> alignment,
>   * as well as SSE4.1 support. i915_memcpy_from_wc() will report if it cannot
>   * perform the operation. To check beforehand, pass in the parameters to
> - * to i915_can_memcpy_from_wc() - since we only care about the low 4 bits,
> + * i915_can_memcpy_from_wc() - since we only care about the low 4 bits,
>   * you only need to pass in the minor offsets, page-aligned pointers are
>   * always valid.
>   *

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v3 03/14] gpu: drm: simplify drivers using devm_regulator_*get_enable*()

[Robert Foss]

Hi Matti,

On Fri, 19 Aug 2022 at 21:18, Matti Vaittinen  wrote:
>
> Simplify drivers using managed "regulator get and enable".
>
> meson:
> Use the devm_regulator_get_enable_optional(). Also drop the seemingly
> unused struct member 'hdmi_supply'.
>
> sii902x:
> Simplify using devm_regulator_bulk_get_enable()
>
> Signed-off-by: Matti Vaittinen 
>
> ---
> v2 => v3:
> No changes
>
> RFCv1 => v2:
> - Change also sii902x to use devm_regulator_bulk_get_enable()
>
> Please note - this is only compile-tested due to the lack of HW. Careful
> review and testing is _highly_ appreciated.
> ---
>  drivers/gpu/drm/bridge/sii902x.c  | 22 +++---
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 23 +++
>  2 files changed, 6 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index 7ab38d734ad6..162f9c87eeb2 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -171,7 +171,6 @@ struct sii902x {
> struct drm_connector connector;
> struct gpio_desc *reset_gpio;
> struct i2c_mux_core *i2cmux;
> -   struct regulator_bulk_data supplies[2];
> bool sink_is_hdmi;
> /*
>  * Mutex protects audio and video functions from interfering
> @@ -1072,6 +1071,7 @@ static int sii902x_probe(struct i2c_client *client,
> struct device *dev = >dev;
> struct device_node *endpoint;
> struct sii902x *sii902x;
> +   static const char * const supplies[] = {"iovcc", "cvcc12"};
> int ret;
>
> ret = i2c_check_functionality(client->adapter,
> @@ -1122,27 +1122,13 @@ static int sii902x_probe(struct i2c_client *client,
>
> mutex_init(>mutex);
>
> -   sii902x->supplies[0].supply = "iovcc";
> -   sii902x->supplies[1].supply = "cvcc12";
> -   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
> - sii902x->supplies);
> -   if (ret < 0)
> -   return ret;
> -
> -   ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
> -   sii902x->supplies);
> +   ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(supplies), 
> supplies);
> if (ret < 0) {
> dev_err_probe(dev, ret, "Failed to enable supplies");
> return ret;
> }
>
> -   ret = sii902x_init(sii902x);
> -   if (ret < 0) {
> -   regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> -  sii902x->supplies);
> -   }
> -
> -   return ret;
> +   return sii902x_init(sii902x);
>  }
>
>  static int sii902x_remove(struct i2c_client *client)
> @@ -1152,8 +1138,6 @@ static int sii902x_remove(struct i2c_client *client)
>
> i2c_mux_del_adapters(sii902x->i2cmux);
> drm_bridge_remove(>bridge);
> -   regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> -  sii902x->supplies);
>
> return 0;
>  }

Ideally this patch would be split into two parts here, due to
maintainership boundaries.

For the sii902x part, please add my r-b.

Reviewed-by: Robert Foss 

> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 5cd2b2ebbbd3..7642f740272b 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -140,7 +140,6 @@ struct meson_dw_hdmi {
> struct reset_control *hdmitx_apb;
> struct reset_control *hdmitx_ctrl;
> struct reset_control *hdmitx_phy;
> -   struct regulator *hdmi_supply;
> u32 irq_stat;
> struct dw_hdmi *hdmi;
> struct drm_bridge *bridge;
> @@ -665,11 +664,6 @@ static void meson_dw_hdmi_init(struct meson_dw_hdmi 
> *meson_dw_hdmi)
>
>  }
>
> -static void meson_disable_regulator(void *data)
> -{
> -   regulator_disable(data);
> -}
> -
>  static void meson_disable_clk(void *data)
>  {
> clk_disable_unprepare(data);
> @@ -723,20 +717,9 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
> device *master,
> meson_dw_hdmi->data = match;
> dw_plat_data = _dw_hdmi->dw_plat_data;
>
> -   meson_dw_hdmi->hdmi_supply = devm_regulator_get_optional(dev, "hdmi");
> -   if (IS_ERR(meson_dw_hdmi->hdmi_supply)) {
> -   if (PTR_ERR(meson_dw_hdmi->hdmi_supply) == -EPROBE_DEFER)
> -   return -EPROBE_DEFER;
> -   meson_dw_hdmi->hdmi_supply = NULL;
> -   } else {
> -   ret = regulator_enable(meson_dw_hdmi->hdmi_supply);
> -   if (ret)
> -   return ret;
> -   ret = devm_add_action_or_reset(dev, meson_disable_regulator,
> -  meson_dw_hdmi->hdmi_supply);
> -   if (ret)
> -   return ret;
> -   }
> +   ret = devm_regulator_get_enable_optional(dev,