[PATCH v10 06/24] dt-bindings: reset: mt8188: Add VDOSYS reset control bits

2023-10-18 Thread Hsiao Chien Sung
Add MT8188 VDOSYS0 and VDOSYS1 reset control bits.

Reviewed-by: AngeloGioacchino Del Regno 

Acked-by: Krzysztof Kozlowski 
Signed-off-by: Hsiao Chien Sung 
---
 include/dt-bindings/reset/mt8188-resets.h | 75 +++
 1 file changed, 75 insertions(+)

diff --git a/include/dt-bindings/reset/mt8188-resets.h 
b/include/dt-bindings/reset/mt8188-resets.h
index ba9a5e9b8899..5a58c54e7d20 100644
--- a/include/dt-bindings/reset/mt8188-resets.h
+++ b/include/dt-bindings/reset/mt8188-resets.h
@@ -38,4 +38,79 @@
 #define MT8188_INFRA_RST1_THERMAL_CTRL_RST 1
 #define MT8188_INFRA_RST3_PTP_CTRL_RST 2
 
+#define MT8188_VDO0_RST_DISP_OVL0  0
+#define MT8188_VDO0_RST_FAKE_ENG0  1
+#define MT8188_VDO0_RST_DISP_CCORR02
+#define MT8188_VDO0_RST_DISP_MUTEX03
+#define MT8188_VDO0_RST_DISP_GAMMA04
+#define MT8188_VDO0_RST_DISP_DITHER0   5
+#define MT8188_VDO0_RST_DISP_WDMA0 6
+#define MT8188_VDO0_RST_DISP_RDMA0 7
+#define MT8188_VDO0_RST_DSI0   8
+#define MT8188_VDO0_RST_DSI1   9
+#define MT8188_VDO0_RST_DSC_WRAP0  10
+#define MT8188_VDO0_RST_VPP_MERGE0 11
+#define MT8188_VDO0_RST_DP_INTF0   12
+#define MT8188_VDO0_RST_DISP_AAL0  13
+#define MT8188_VDO0_RST_INLINEROT0 14
+#define MT8188_VDO0_RST_APB_BUS15
+#define MT8188_VDO0_RST_DISP_COLOR016
+#define MT8188_VDO0_RST_MDP_WROT0  17
+#define MT8188_VDO0_RST_DISP_RSZ0  18
+
+#define MT8188_VDO1_RST_SMI_LARB2  0
+#define MT8188_VDO1_RST_SMI_LARB3  1
+#define MT8188_VDO1_RST_GALS   2
+#define MT8188_VDO1_RST_FAKE_ENG0  3
+#define MT8188_VDO1_RST_FAKE_ENG1  4
+#define MT8188_VDO1_RST_MDP_RDMA0  5
+#define MT8188_VDO1_RST_MDP_RDMA1  6
+#define MT8188_VDO1_RST_MDP_RDMA2  7
+#define MT8188_VDO1_RST_MDP_RDMA3  8
+#define MT8188_VDO1_RST_VPP_MERGE0 9
+#define MT8188_VDO1_RST_VPP_MERGE1 10
+#define MT8188_VDO1_RST_VPP_MERGE2 11
+#define MT8188_VDO1_RST_VPP_MERGE3 12
+#define MT8188_VDO1_RST_VPP_MERGE4 13
+#define MT8188_VDO1_RST_VPP2_TO_VDO1_DL_ASYNC  14
+#define MT8188_VDO1_RST_VPP3_TO_VDO1_DL_ASYNC  15
+#define MT8188_VDO1_RST_DISP_MUTEX 16
+#define MT8188_VDO1_RST_MDP_RDMA4  17
+#define MT8188_VDO1_RST_MDP_RDMA5  18
+#define MT8188_VDO1_RST_MDP_RDMA6  19
+#define MT8188_VDO1_RST_MDP_RDMA7  20
+#define MT8188_VDO1_RST_DP_INTF1_MMCK  21
+#define MT8188_VDO1_RST_DPI0_MM_CK 22
+#define MT8188_VDO1_RST_DPI1_MM_CK 23
+#define MT8188_VDO1_RST_MERGE0_DL_ASYNC24
+#define MT8188_VDO1_RST_MERGE1_DL_ASYNC25
+#define MT8188_VDO1_RST_MERGE2_DL_ASYNC26
+#define MT8188_VDO1_RST_MERGE3_DL_ASYNC27
+#define MT8188_VDO1_RST_MERGE4_DL_ASYNC28
+#define MT8188_VDO1_RST_VDO0_DSC_TO_VDO1_DL_ASYNC  29
+#define MT8188_VDO1_RST_VDO0_MERGE_TO_VDO1_DL_ASYNC30
+#define MT8188_VDO1_RST_PADDING0   31
+#define MT8188_VDO1_RST_PADDING1   32
+#define MT8188_VDO1_RST_PADDING2   33
+#define MT8188_VDO1_RST_PADDING3   34
+#define MT8188_VDO1_RST_PADDING4   35
+#define MT8188_VDO1_RST_PADDING5   36
+#define MT8188_VDO1_RST_PADDING6   37
+#define MT8188_VDO1_RST_PADDING7   38
+#define MT8188_VDO1_RST_DISP_RSZ0  39
+#define MT8188_VDO1_RST_DISP_RSZ1  40
+#define MT8188_VDO1_RST_DISP_RSZ2  41
+#define MT8188_VDO1_RST_DISP_RSZ3  42
+#define MT8188_VDO1_RST_HDR_VDO_FE043
+#define MT8188_VDO1_RST_HDR_GFX_FE044
+#define MT8188_VDO1_RST_HDR_VDO_BE 45
+#define MT8188_VDO1_RST_HDR_VDO_FE146
+#define MT8188_VDO1_RST_HDR_GFX_FE147
+#define MT8188_VDO1_RST_DISP_MIXER 48
+#define MT8188_VDO1_RST_HDR_VDO_FE0_DL_ASYNC   49
+#define MT8188_VDO1_RST_HDR_VDO_FE1_DL_ASYNC   50
+#define MT8188_VDO1_RST_HDR_GFX_FE0_DL_ASYNC   51
+#define MT8188_VDO1_RST_HDR_GFX_FE1_DL_ASYNC   52
+#define MT8188_VDO1_RST_HDR_VDO_BE_DL_ASYNC53
+
 #endif  /* _DT_BINDINGS_RESET_CONTROLLER_MT8188 */
-- 
2.18.0



[PATCH v10 07/24] soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys

2023-10-18 Thread Hsiao Chien Sung
- Add register definitions for MT8188
- Add VDOSYS1 routing table
- Update MUTEX definitions accordingly
- Set VSYNC length from 0x40 (default) to 1 since ETHDR is bypassed

Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/soc/mediatek/mt8188-mmsys.h | 126 
 drivers/soc/mediatek/mtk-mmsys.c|  13 +++
 drivers/soc/mediatek/mtk-mmsys.h|  29 +++
 drivers/soc/mediatek/mtk-mutex.c|  35 
 4 files changed, 203 insertions(+)

diff --git a/drivers/soc/mediatek/mt8188-mmsys.h 
b/drivers/soc/mediatek/mt8188-mmsys.h
index 448cc3761b43..a9490c3c4256 100644
--- a/drivers/soc/mediatek/mt8188-mmsys.h
+++ b/drivers/soc/mediatek/mt8188-mmsys.h
@@ -67,6 +67,56 @@
 #define MT8188_SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE BIT(18)
 #define MT8188_SOUT_DSC_WRAP0_OUT_TO_DISP_WDMA0BIT(19)
 
+#define MT8188_VDO1_HDR_TOP_CFG0xd00
+#define MT8188_VDO1_MIXER_IN1_ALPHA0xd30
+#define MT8188_VDO1_MIXER_IN1_PAD  0xd40
+#define MT8188_VDO1_MIXER_VSYNC_LEN0xd5c
+#define MT8188_VDO1_MERGE0_ASYNC_CFG_WD0xe30
+#define MT8188_VDO1_HDRBE_ASYNC_CFG_WD 0xe70
+#define MT8188_VDO1_VPP_MERGE0_P0_SEL_IN   0xf04
+#define MT8188_VPP_MERGE0_P0_SEL_IN_FROM_MDP_RDMA0 1
+#define MT8188_VDO1_VPP_MERGE0_P1_SEL_IN   0xf08
+#define MT8188_VPP_MERGE0_P1_SEL_IN_FROM_MDP_RDMA1 1
+#define MT8188_VDO1_DISP_DPI1_SEL_IN   0xf10
+#define MT8188_DISP_DPI1_SEL_IN_FROM_VPP_MERGE4_MOUT   0
+#define MT8188_VDO1_DISP_DP_INTF0_SEL_IN   0xf14
+#define MT8188_DISP_DP_INTF0_SEL_IN_FROM_VPP_MERGE4_MOUT   0
+#define MT8188_VDO1_MERGE4_SOUT_SEL0xf18
+#define MT8188_MERGE4_SOUT_TO_DPI1_SEL BIT(2)
+#define MT8188_MERGE4_SOUT_TO_DP_INTF0_SEL BIT(3)
+#define MT8188_VDO1_MIXER_IN1_SEL_IN   0xf24
+#define MT8188_MIXER_IN1_SEL_IN_FROM_MERGE0_ASYNC_SOUT 1
+#define MT8188_VDO1_MIXER_IN2_SEL_IN   0xf28
+#define MT8188_MIXER_IN2_SEL_IN_FROM_MERGE1_ASYNC_SOUT 1
+#define MT8188_VDO1_MIXER_IN3_SEL_IN   0xf2c
+#define MT8188_MIXER_IN3_SEL_IN_FROM_MERGE2_ASYNC_SOUT 1
+#define MT8188_VDO1_MIXER_IN4_SEL_IN   0xf30
+#define MT8188_MIXER_IN4_SEL_IN_FROM_MERGE3_ASYNC_SOUT 1
+#define MT8188_VDO1_MIXER_OUT_SOUT_SEL 0xf34
+#define MT8188_MIXER_SOUT_TO_MERGE4_ASYNC_SEL  1
+#define MT8188_VDO1_VPP_MERGE1_P0_SEL_IN   0xf3c
+#define MT8188_VPP_MERGE1_P0_SEL_IN_FROM_MDP_RDMA2 1
+#define MT8188_VDO1_MERGE0_ASYNC_SOUT_SEL  0xf40
+#define MT8188_SOUT_TO_MIXER_IN1_SEL   1
+#define MT8188_VDO1_MERGE1_ASYNC_SOUT_SEL  0xf44
+#define MT8188_SOUT_TO_MIXER_IN2_SEL   1
+#define MT8188_VDO1_MERGE2_ASYNC_SOUT_SEL  0xf48
+#define MT8188_SOUT_TO_MIXER_IN3_SEL   1
+#define MT8188_VDO1_MERGE3_ASYNC_SOUT_SEL  0xf4c
+#define MT8188_SOUT_TO_MIXER_IN4_SEL   1
+#define MT8188_VDO1_MERGE4_ASYNC_SEL_IN0xf50
+#define MT8188_MERGE4_ASYNC_SEL_IN_FROM_MIXER_OUT_SOUT 1
+#define MT8188_VDO1_MIXER_IN1_SOUT_SEL 0xf58
+#define MT8188_MIXER_IN1_SOUT_TO_DISP_MIXER0
+#define MT8188_VDO1_MIXER_IN2_SOUT_SEL 0xf5c
+#define MT8188_MIXER_IN2_SOUT_TO_DISP_MIXER0
+#define MT8188_VDO1_MIXER_IN3_SOUT_SEL 0xf60
+#define MT8188_MIXER_IN3_SOUT_TO_DISP_MIXER0
+#define MT8188_VDO1_MIXER_IN4_SOUT_SEL 0xf64
+#define MT8188_MIXER_IN4_SOUT_TO_DISP_MIXER0
+#define MT8188_VDO1_MIXER_SOUT_SEL_IN  0xf68
+#define MT8188_MIXER_SOUT_SEL_IN_FROM_DISP_MIXER   0
+
 static const struct mtk_mmsys_routes mmsys_mt8188_routing_table[] = {
{
DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
@@ -146,4 +196,80 @@ static const struct mtk_mmsys_routes 
mmsys_mt8188_routing_table[] = {
},
 };
 
+static const struct mtk_mmsys_routes mmsys_mt8188_vdo1_routing_table[] = {
+   {
+   DDP_COMPONENT_MDP_RDMA0, DDP_COMPONENT_MERGE1,
+   MT8188_VDO1_VPP_MERGE0_P0_SEL_IN, GENMASK(0, 0),
+   MT8188_VPP_MERGE0_P0_SEL_IN_FROM_MDP_RDMA0
+   }, {
+   DDP_COMPONENT_MDP_RDMA1, DDP_COMPONENT_MERGE1,
+   MT8188_VDO1_VPP_MERGE0_P1_SEL_IN, GENMASK(0, 0),
+   MT8188_VPP_MERGE0_P1_SEL_IN_FROM_MDP_RDMA1
+   }, {
+  

[PATCH v10 12/24] drm/mediatek: Add component ID to component match structure

2023-10-18 Thread Hsiao Chien Sung
Add component ID to component match structure so we can
configure them with a for-loop.

The main reason we do such code refactoring is that
there is a new hardware component called "Padding" since
MT8188, while MT8195 doesn't have this module, we can't
use the original logic to manage the components.

While MT8195 does not define Padding in the device tree,
the corresponding components will be NULL and being skipped
by the functions.

Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 69 ---
 1 file changed, 30 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 33b0f74937a2..d55d8931a36f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -51,6 +51,7 @@ enum mtk_ovl_adaptor_comp_id {
 
 struct ovl_adaptor_comp_match {
enum mtk_ovl_adaptor_comp_type type;
+   enum mtk_ddp_comp_id comp_id;
int alias_id;
 };
 
@@ -67,19 +68,19 @@ static const char * const 
private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
 };
 
 static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
-   [OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 0 },
-   [OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 1 },
-   [OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 2 },
-   [OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 3 },
-   [OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 4 },
-   [OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 5 },
-   [OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 6 },
-   [OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 7 },
-   [OVL_ADAPTOR_MERGE0]= { OVL_ADAPTOR_TYPE_MERGE, 1 },
-   [OVL_ADAPTOR_MERGE1]= { OVL_ADAPTOR_TYPE_MERGE, 2 },
-   [OVL_ADAPTOR_MERGE2]= { OVL_ADAPTOR_TYPE_MERGE, 3 },
-   [OVL_ADAPTOR_MERGE3]= { OVL_ADAPTOR_TYPE_MERGE, 4 },
-   [OVL_ADAPTOR_ETHDR0]= { OVL_ADAPTOR_TYPE_ETHDR, 0 },
+   [OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA0, 0 },
+   [OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA1, 1 },
+   [OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA2, 2 },
+   [OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA3, 3 },
+   [OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA4, 4 },
+   [OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA5, 5 },
+   [OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA6, 6 },
+   [OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA7, 7 },
+   [OVL_ADAPTOR_MERGE0] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE1, 
1 },
+   [OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 
2 },
+   [OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 
3 },
+   [OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 
4 },
+   [OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, 
DDP_COMPONENT_ETHDR_MIXER, 0 },
 };
 
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -313,36 +314,26 @@ size_t mtk_ovl_adaptor_get_num_formats(struct device *dev)
 
 void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex)
 {
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA0);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA1);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA2);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA3);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA4);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA5);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA6);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA7);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MERGE1);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MERGE2);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MERGE3);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_MERGE4);
-   mtk_mutex_add_comp(mutex, DDP_COMPONENT_ETHDR_MIXER);
+   int i;
+   struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+   for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+   if (!ovl_adaptor->ovl_adaptor_comp[i])
+   continue;
+   mtk_mutex_add_comp(mutex, comp_matches[i].comp_id);
+   }
 }
 
 void mtk_ovl_adaptor_remove_comp(struct device *dev, struct mtk_mutex *mutex)
 {
-   mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA0);
-   mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA1);
-   mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA2);
-   mtk_mutex_remove_comp(mutex, 

[PATCH v10 24/24] drm/mediatek: Support MT8188 VDOSYS1 in display driver

2023-10-18 Thread Hsiao Chien Sung
- The mmsys_dev_num in MT8188 VDOSYS0 was set to 1 since
  VDOSYS1 was not available before. Increase it to support
  VDOSYS1 in display driver.
- Add compatible name for MT8188 VDOSYS1
  (shares the same driver data with MT8195 VDOSYS1)

Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 62e6e9785443..eecfeb8fbde1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -303,7 +303,7 @@ static const struct mtk_mmsys_driver_data 
mt8188_vdosys0_driver_data = {
.main_len = ARRAY_SIZE(mt8188_mtk_ddp_main),
.conn_routes = mt8188_mtk_ddp_main_routes,
.conn_routes_num = ARRAY_SIZE(mt8188_mtk_ddp_main_routes),
-   .mmsys_dev_num = 1,
+   .mmsys_dev_num = 2,
 };
 
 static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
@@ -344,6 +344,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
  .data = _mmsys_driver_data},
{ .compatible = "mediatek,mt8188-vdosys0",
  .data = _vdosys0_driver_data},
+   { .compatible = "mediatek,mt8188-vdosys1",
+ .data = _vdosys1_driver_data},
{ .compatible = "mediatek,mt8192-mmsys",
  .data = _mmsys_driver_data},
{ .compatible = "mediatek,mt8195-mmsys",
-- 
2.18.0



[PATCH v10 05/24] dt-bindings: arm: mediatek: Add compatible for MT8188

2023-10-18 Thread Hsiao Chien Sung
Add compatible name for MediaTek MT8188 VDOSYS1.

Reviewed-by: AngeloGioacchino Del Regno 

Acked-by: Krzysztof Kozlowski 
Signed-off-by: Hsiao Chien Sung 
---
 .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index d1410345ef18..8180199d6573 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -32,6 +32,7 @@ properties:
   - mediatek,mt8183-mmsys
   - mediatek,mt8186-mmsys
   - mediatek,mt8188-vdosys0
+  - mediatek,mt8188-vdosys1
   - mediatek,mt8192-mmsys
   - mediatek,mt8195-vdosys1
   - mediatek,mt8195-vppsys0
-- 
2.18.0



[PATCH v10 10/24] soc: mediatek: Add MT8188 VDOSYS reset bit map

2023-10-18 Thread Hsiao Chien Sung
Add MT8188 reset bit map for VDOSYS0 and VDOSYS1.

Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/soc/mediatek/mt8188-mmsys.h | 84 +
 drivers/soc/mediatek/mtk-mmsys.c|  7 ++-
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mt8188-mmsys.h 
b/drivers/soc/mediatek/mt8188-mmsys.h
index a9490c3c4256..6bebf1a69fc0 100644
--- a/drivers/soc/mediatek/mt8188-mmsys.h
+++ b/drivers/soc/mediatek/mt8188-mmsys.h
@@ -3,6 +3,10 @@
 #ifndef __SOC_MEDIATEK_MT8188_MMSYS_H
 #define __SOC_MEDIATEK_MT8188_MMSYS_H
 
+#include 
+#include 
+
+#define MT8188_VDO0_SW0_RST_B  0x190
 #define MT8188_VDO0_OVL_MOUT_EN0xf14
 #define MT8188_MOUT_DISP_OVL0_TO_DISP_RDMA0BIT(0)
 #define MT8188_MOUT_DISP_OVL0_TO_DISP_WDMA0BIT(1)
@@ -67,6 +71,7 @@
 #define MT8188_SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE BIT(18)
 #define MT8188_SOUT_DSC_WRAP0_OUT_TO_DISP_WDMA0BIT(19)
 
+#define MT8188_VDO1_SW0_RST_B  0x1d0
 #define MT8188_VDO1_HDR_TOP_CFG0xd00
 #define MT8188_VDO1_MIXER_IN1_ALPHA0xd30
 #define MT8188_VDO1_MIXER_IN1_PAD  0xd40
@@ -117,6 +122,85 @@
 #define MT8188_VDO1_MIXER_SOUT_SEL_IN  0xf68
 #define MT8188_MIXER_SOUT_SEL_IN_FROM_DISP_MIXER   0
 
+static const u8 mmsys_mt8188_vdo0_rst_tb[] = {
+   [MT8188_VDO0_RST_DISP_OVL0] = MMSYS_RST_NR(0, 0),
+   [MT8188_VDO0_RST_FAKE_ENG0] = MMSYS_RST_NR(0, 2),
+   [MT8188_VDO0_RST_DISP_CCORR0]   = MMSYS_RST_NR(0, 4),
+   [MT8188_VDO0_RST_DISP_MUTEX0]   = MMSYS_RST_NR(0, 6),
+   [MT8188_VDO0_RST_DISP_GAMMA0]   = MMSYS_RST_NR(0, 8),
+   [MT8188_VDO0_RST_DISP_DITHER0]  = MMSYS_RST_NR(0, 10),
+   [MT8188_VDO0_RST_DISP_WDMA0]= MMSYS_RST_NR(0, 17),
+   [MT8188_VDO0_RST_DISP_RDMA0]= MMSYS_RST_NR(0, 19),
+   [MT8188_VDO0_RST_DSI0]  = MMSYS_RST_NR(0, 21),
+   [MT8188_VDO0_RST_DSI1]  = MMSYS_RST_NR(0, 22),
+   [MT8188_VDO0_RST_DSC_WRAP0] = MMSYS_RST_NR(0, 23),
+   [MT8188_VDO0_RST_VPP_MERGE0]= MMSYS_RST_NR(0, 24),
+   [MT8188_VDO0_RST_DP_INTF0]  = MMSYS_RST_NR(0, 25),
+   [MT8188_VDO0_RST_DISP_AAL0] = MMSYS_RST_NR(0, 26),
+   [MT8188_VDO0_RST_INLINEROT0]= MMSYS_RST_NR(0, 27),
+   [MT8188_VDO0_RST_APB_BUS]   = MMSYS_RST_NR(0, 28),
+   [MT8188_VDO0_RST_DISP_COLOR0]   = MMSYS_RST_NR(0, 29),
+   [MT8188_VDO0_RST_MDP_WROT0] = MMSYS_RST_NR(0, 30),
+   [MT8188_VDO0_RST_DISP_RSZ0] = MMSYS_RST_NR(0, 31),
+};
+
+static const u8 mmsys_mt8188_vdo1_rst_tb[] = {
+   [MT8188_VDO1_RST_SMI_LARB2] = MMSYS_RST_NR(0, 0),
+   [MT8188_VDO1_RST_SMI_LARB3] = MMSYS_RST_NR(0, 1),
+   [MT8188_VDO1_RST_GALS]  = MMSYS_RST_NR(0, 2),
+   [MT8188_VDO1_RST_FAKE_ENG0] = MMSYS_RST_NR(0, 3),
+   [MT8188_VDO1_RST_FAKE_ENG1] = MMSYS_RST_NR(0, 4),
+   [MT8188_VDO1_RST_MDP_RDMA0] = MMSYS_RST_NR(0, 5),
+   [MT8188_VDO1_RST_MDP_RDMA1] = MMSYS_RST_NR(0, 6),
+   [MT8188_VDO1_RST_MDP_RDMA2] = MMSYS_RST_NR(0, 7),
+   [MT8188_VDO1_RST_MDP_RDMA3] = MMSYS_RST_NR(0, 8),
+   [MT8188_VDO1_RST_VPP_MERGE0]= MMSYS_RST_NR(0, 9),
+   [MT8188_VDO1_RST_VPP_MERGE1]= MMSYS_RST_NR(0, 10),
+   [MT8188_VDO1_RST_VPP_MERGE2]= MMSYS_RST_NR(0, 11),
+   [MT8188_VDO1_RST_VPP_MERGE3]= MMSYS_RST_NR(1, 0),
+   [MT8188_VDO1_RST_VPP_MERGE4]= MMSYS_RST_NR(1, 1),
+   [MT8188_VDO1_RST_VPP2_TO_VDO1_DL_ASYNC] = MMSYS_RST_NR(1, 2),
+   [MT8188_VDO1_RST_VPP3_TO_VDO1_DL_ASYNC] = MMSYS_RST_NR(1, 3),
+   [MT8188_VDO1_RST_DISP_MUTEX]= MMSYS_RST_NR(1, 4),
+   [MT8188_VDO1_RST_MDP_RDMA4] = MMSYS_RST_NR(1, 5),
+   [MT8188_VDO1_RST_MDP_RDMA5] = MMSYS_RST_NR(1, 6),
+   [MT8188_VDO1_RST_MDP_RDMA6] = MMSYS_RST_NR(1, 7),
+   [MT8188_VDO1_RST_MDP_RDMA7] = MMSYS_RST_NR(1, 8),
+   [MT8188_VDO1_RST_DP_INTF1_MMCK] = MMSYS_RST_NR(1, 9),
+   [MT8188_VDO1_RST_DPI0_MM_CK]= MMSYS_RST_NR(1, 10),
+   [MT8188_VDO1_RST_DPI1_MM_CK]= MMSYS_RST_NR(1, 11),
+   [MT8188_VDO1_RST_MERGE0_DL_ASYNC]   = MMSYS_RST_NR(1, 13),
+   [MT8188_VDO1_RST_MERGE1_DL_ASYNC]   = MMSYS_RST_NR(1, 14),
+   [MT8188_VDO1_RST_MERGE2_DL_ASYNC]   = MMSYS_RST_NR(1, 15),
+   [MT8188_VDO1_RST_MERGE3_DL_ASYNC]   = MMSYS_RST_NR(1, 16),
+   

[PATCH v10 04/24] dt-bindings: display: mediatek: padding: Add MT8188

2023-10-18 Thread Hsiao Chien Sung
Padding is a new hardware module on MediaTek MT8188,
add dt-bindings for it.

Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 .../display/mediatek/mediatek,padding.yaml| 81 +++
 1 file changed, 81 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
new file mode 100644
index ..db24801ebc48
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,padding.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Display Padding
+
+maintainers:
+  - Chun-Kuang Hu 
+  - Philipp Zabel 
+
+description:
+  Padding provides ability to add pixels to width and height of a layer with
+  specified colors. Due to hardware design, Mixer in VDOSYS1 requires
+  width of a layer to be 2-pixel-align, or 4-pixel-align when ETHDR is enabled,
+  we need Padding to deal with odd width.
+  Please notice that even if the Padding is in bypass mode, settings in
+  register must be cleared to 0, or undefined behaviors could happen.
+
+properties:
+  compatible:
+const: mediatek,mt8188-padding
+
+  reg:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+
+  clocks:
+items:
+  - description: RDMA Clock
+
+  mediatek,gce-client-reg:
+description:
+  GCE (Global Command Engine) is a multi-core micro processor that helps
+  its clients to execute commands without interrupting CPU. This property
+  describes GCE client's information that is composed by 4 fields.
+  1. Phandle of the GCE (there may be several GCE processors)
+  2. Sub-system ID defined in the dt-binding like a user ID
+ (Please refer to include/dt-bindings/gce/-gce.h)
+  3. Offset from base address of the subsys you are at
+  4. Size of the register the client needs
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+  items:
+- description: Phandle of the GCE
+- description: Subsys ID defined in the dt-binding
+- description: Offset from base address of the subsys
+- description: Size of register
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - power-domains
+  - clocks
+  - mediatek,gce-client-reg
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+#include 
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+padding0: padding@1c11d000 {
+compatible = "mediatek,mt8188-padding";
+reg = <0 0x1c11d000 0 0x1000>;
+clocks = < CLK_VDO1_PADDING0>;
+power-domains = < MT8188_POWER_DOMAIN_VDOSYS1>;
+mediatek,gce-client-reg = < SUBSYS_1c11 0xd000 0x1000>;
+};
+};
-- 
2.18.0



[PATCH v10 09/24] soc: mediatek: Support reset bit mapping in mmsys driver

2023-10-18 Thread Hsiao Chien Sung
- Reset ID must starts from 0 and be consecutive, but
  the reset bits in our hardware design is not continuous,
  some bits are left unused, we need a map to solve the problem
- Use old style 1-to-1 mapping if .rst_tb is not defined

Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/soc/mediatek/mtk-mmsys.c | 9 +
 drivers/soc/mediatek/mtk-mmsys.h | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index b1db09e19905..3a7108eefe9d 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -314,6 +314,15 @@ static int mtk_mmsys_reset_update(struct 
reset_controller_dev *rcdev, unsigned l
u32 offset;
u32 reg;
 
+   if (mmsys->data->rst_tb) {
+   if (id >= mmsys->data->num_resets) {
+   dev_err(rcdev->dev, "Invalid reset ID: %lu (>=%u)\n",
+   id, mmsys->data->num_resets);
+   return -EINVAL;
+   }
+   id = mmsys->data->rst_tb[id];
+   }
+
offset = (id / MMSYS_SW_RESET_PER_REG) * sizeof(u32);
id = id % MMSYS_SW_RESET_PER_REG;
reg = mmsys->data->sw0_rst_offset + offset;
diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
index 9d8507f98b7a..d370192737ca 100644
--- a/drivers/soc/mediatek/mtk-mmsys.h
+++ b/drivers/soc/mediatek/mtk-mmsys.h
@@ -78,6 +78,8 @@
 #define DSI_SEL_IN_RDMA0x1
 #define DSI_SEL_IN_MASK0x1
 
+#define MMSYS_RST_NR(bank, bit) (((bank) * 32) + (bit))
+
 struct mtk_mmsys_routes {
u32 from_comp;
u32 to_comp;
@@ -119,6 +121,7 @@ struct mtk_mmsys_driver_data {
const struct mtk_mmsys_routes *routes;
const unsigned int num_routes;
const u16 sw0_rst_offset;
+   const u8 *rst_tb;
const u32 num_resets;
const bool is_vppsys;
const u8 vsync_len;
-- 
2.18.0



[PATCH v10 13/24] drm/mediatek: Manage component's clock with function pointers

2023-10-18 Thread Hsiao Chien Sung
By registering component related functions to the pointers,
we can easily manage them within a for-loop and simplify the
logic of clock control significantly.

Signed-off-by: Hsiao Chien Sung 
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 89 +--
 1 file changed, 43 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index d55d8931a36f..81067f49ea69 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -53,6 +53,7 @@ struct ovl_adaptor_comp_match {
enum mtk_ovl_adaptor_comp_type type;
enum mtk_ddp_comp_id comp_id;
int alias_id;
+   const struct mtk_ddp_comp_funcs *funcs;
 };
 
 struct mtk_disp_ovl_adaptor {
@@ -67,20 +68,35 @@ static const char * const 
private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
[OVL_ADAPTOR_TYPE_ETHDR]= "ethdr",
 };
 
+static const struct mtk_ddp_comp_funcs ethdr = {
+   .clk_enable = mtk_ethdr_clk_enable,
+   .clk_disable = mtk_ethdr_clk_disable,
+};
+
+static const struct mtk_ddp_comp_funcs merge = {
+   .clk_enable = mtk_merge_clk_enable,
+   .clk_disable = mtk_merge_clk_disable,
+};
+
+static const struct mtk_ddp_comp_funcs rdma = {
+   .clk_enable = mtk_mdp_rdma_clk_enable,
+   .clk_disable = mtk_mdp_rdma_clk_disable,
+};
+
 static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
-   [OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA0, 0 },
-   [OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA1, 1 },
-   [OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA2, 2 },
-   [OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA3, 3 },
-   [OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA4, 4 },
-   [OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA5, 5 },
-   [OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA6, 6 },
-   [OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA7, 7 },
-   [OVL_ADAPTOR_MERGE0] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE1, 
1 },
-   [OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 
2 },
-   [OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 
3 },
-   [OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 
4 },
-   [OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, 
DDP_COMPONENT_ETHDR_MIXER, 0 },
+   [OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA0, 0,  },
+   [OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA1, 1,  },
+   [OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA2, 2,  },
+   [OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA3, 3,  },
+   [OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA4, 4,  },
+   [OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA5, 5,  },
+   [OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA6, 6,  },
+   [OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA7, 7,  },
+   [OVL_ADAPTOR_MERGE0] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE1, 
1,  },
+   [OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 
2,  },
+   [OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 
3,  },
+   [OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 
4,  },
+   [OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, 
DDP_COMPONENT_ETHDR_MIXER, 0,  },
 };
 
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -196,40 +212,25 @@ int mtk_ovl_adaptor_clk_enable(struct device *dev)
ret = pm_runtime_get_sync(comp);
if (ret < 0) {
dev_err(dev, "Failed to enable power domain %d, err 
%d\n", i, ret);
-   goto pwr_err;
+   goto error;
}
}
 
for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
comp = ovl_adaptor->ovl_adaptor_comp[i];
-
-   if (i < OVL_ADAPTOR_MERGE0)
-   ret = mtk_mdp_rdma_clk_enable(comp);
-   else if (i < OVL_ADAPTOR_ETHDR0)
-   ret = mtk_merge_clk_enable(comp);
-   else
-   ret = mtk_ethdr_clk_enable(comp);
+   if (!comp || !comp_matches[i].funcs->clk_enable)
+   continue;
+   ret = comp_matches[i].funcs->clk_enable(comp);
if (ret) {
dev_err(dev, "Failed to enable clock %d, err %d\n", i, 
ret);
-  

[PATCH v10 14/24] drm/mediatek: Power on/off devices with function pointers

2023-10-18 Thread Hsiao Chien Sung
Different from OVL, OVL adaptor is a pseudo device so we didn't
define it in the device tree, consequently, pm_runtime_resume_and_get()
called by .atomic_enable() powers on no device. For this reason, we
implement a function to power on the RDMAs in OVL adaptor, and the
system will make sure the IOMMUs are powered on as well because of the
device link (iommus) in the RDMA nodes in DTS.

This patch separates power and clock management process, it would be
easier to maintain and extensions.

Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h   |  4 +
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 75 +++
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c   | 10 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   | 20 +
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c   | 16 
 6 files changed, 107 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h 
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index bf06ccb65652..8465beeab435 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -109,6 +109,8 @@ void mtk_ovl_adaptor_connect(struct device *dev, struct 
device *mmsys_dev,
 unsigned int next);
 void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev,
unsigned int next);
+int mtk_ovl_adaptor_power_on(struct device *dev);
+void mtk_ovl_adaptor_power_off(struct device *dev);
 int mtk_ovl_adaptor_clk_enable(struct device *dev);
 void mtk_ovl_adaptor_clk_disable(struct device *dev);
 void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
@@ -150,6 +152,8 @@ void mtk_rdma_disable_vblank(struct device *dev);
 const u32 *mtk_rdma_get_formats(struct device *dev);
 size_t mtk_rdma_get_num_formats(struct device *dev);
 
+int mtk_mdp_rdma_power_on(struct device *dev);
+void mtk_mdp_rdma_power_off(struct device *dev);
 int mtk_mdp_rdma_clk_enable(struct device *dev);
 void mtk_mdp_rdma_clk_disable(struct device *dev);
 void mtk_mdp_rdma_start(struct device *dev, struct cmdq_pkt *cmdq_pkt);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 81067f49ea69..aab98adcd9a4 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -79,6 +79,8 @@ static const struct mtk_ddp_comp_funcs merge = {
 };
 
 static const struct mtk_ddp_comp_funcs rdma = {
+   .power_on = mtk_mdp_rdma_power_on,
+   .power_off = mtk_mdp_rdma_power_off,
.clk_enable = mtk_mdp_rdma_clk_enable,
.clk_disable = mtk_mdp_rdma_clk_disable,
 };
@@ -200,21 +202,72 @@ void mtk_ovl_adaptor_stop(struct device *dev)
mtk_ethdr_stop(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
 }
 
-int mtk_ovl_adaptor_clk_enable(struct device *dev)
+/**
+ * power_off - Power off the devices in OVL adaptor
+ * @dev: Device to be powered off
+ * @num: Number of the devices to be powered off
+ *
+ * Calls the .power_off() ovl_adaptor component callback if it is present.
+ */
+static inline void power_off(struct device *dev, unsigned int num)
 {
struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
-   struct device *comp;
-   int ret;
int i;
 
-   for (i = 0; i < OVL_ADAPTOR_MERGE0; i++) {
-   comp = ovl_adaptor->ovl_adaptor_comp[i];
-   ret = pm_runtime_get_sync(comp);
+   if (num > OVL_ADAPTOR_ID_MAX)
+   num = OVL_ADAPTOR_ID_MAX;
+
+   for (i = num - 1; i >= 0; i--) {
+   if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+   !comp_matches[i].funcs->power_off)
+   continue;
+
+   
comp_matches[i].funcs->power_off(ovl_adaptor->ovl_adaptor_comp[i]);
+   }
+}
+
+/**
+ * mtk_ovl_adaptor_power_on - Power on the devices in OVL adaptor
+ * @dev: Device to be powered on
+ *
+ * Different from OVL, OVL adaptor is a pseudo device so
+ * we didn't define it in the device tree, pm_runtime_resume_and_get()
+ * called by .atomic_enable() power on no device in OVL adaptor,
+ * we have to implement a function to do the job instead.
+ *
+ * Return: Zero for success or negative number for failure.
+ */
+int mtk_ovl_adaptor_power_on(struct device *dev)
+{
+   struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+   int i, ret;
+
+   for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+   if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+   !comp_matches[i].funcs->power_on)
+   continue;
+
+   ret = 
comp_matches[i].funcs->power_on(ovl_adaptor->ovl_adaptor_comp[i]);
if (ret < 0) {
dev_err(dev, "Failed to enable power domain %d, err 
%d\n", i, ret);
-   goto error;
+   power_off(dev, i);
+

[PATCH v10 18/24] drm/mediatek: Refine device table of OVL adaptor

2023-10-18 Thread Hsiao Chien Sung
- Adjust indentation to align with other files
- Sort device table in alphabetical order
- Add sentinel to device table

Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 06d28e8fc29a..f46ca1c68610 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -436,17 +436,10 @@ static int ovl_adaptor_comp_get_id(struct device *dev, 
struct device_node *node,
 }
 
 static const struct of_device_id mtk_ovl_adaptor_comp_dt_ids[] = {
-   {
-   .compatible = "mediatek,mt8195-vdo1-rdma",
-   .data = (void *)OVL_ADAPTOR_TYPE_MDP_RDMA,
-   }, {
-   .compatible = "mediatek,mt8195-disp-merge",
-   .data = (void *)OVL_ADAPTOR_TYPE_MERGE,
-   }, {
-   .compatible = "mediatek,mt8195-disp-ethdr",
-   .data = (void *)OVL_ADAPTOR_TYPE_ETHDR,
-   },
-   {},
+   { .compatible = "mediatek,mt8195-disp-ethdr", .data = (void 
*)OVL_ADAPTOR_TYPE_ETHDR },
+   { .compatible = "mediatek,mt8195-disp-merge", .data = (void 
*)OVL_ADAPTOR_TYPE_MERGE },
+   { .compatible = "mediatek,mt8195-vdo1-rdma", .data = (void 
*)OVL_ADAPTOR_TYPE_MDP_RDMA },
+   { /* sentinel */ }
 };
 
 static int compare_of(struct device *dev, void *data)
-- 
2.18.0



[PATCH v10 21/24] drm/mediatek: Return error if MDP RDMA failed to enable the clock

2023-10-18 Thread Hsiao Chien Sung
Return the result of clk_prepare_enable() instead of
always returns 0.

Fixes: f8946e2b6bb2 ("drm/mediatek: Add display MDP RDMA support for MT8195")

Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
index 769ae7564da2..8feeb6dce217 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
@@ -263,8 +263,7 @@ int mtk_mdp_rdma_clk_enable(struct device *dev)
 {
struct mtk_mdp_rdma *rdma = dev_get_drvdata(dev);
 
-   clk_prepare_enable(rdma->clk);
-   return 0;
+   return clk_prepare_enable(rdma->clk);
 }
 
 void mtk_mdp_rdma_clk_disable(struct device *dev)
-- 
2.18.0



[PATCH v10 19/24] drm/mediatek: Support MT8188 Padding in display driver

2023-10-18 Thread Hsiao Chien Sung
Padding is a new display module on MT8188, it provides ability
to add pixels to width and height of a layer with specified colors.

Due to hardware design, Mixer in VDOSYS1 requires width of a layer
to be 2-pixel-align, or 4-pixel-align when ETHDR is enabled,
we need Padding to deal with odd width.

Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/Makefile   |   3 +-
 drivers/gpu/drm/mediatek/mtk_disp_drv.h |   4 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   2 +-
 drivers/gpu/drm/mediatek/mtk_padding.c  | 160 
 5 files changed, 168 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_padding.c

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index d4d193f60271..5e4436403b8d 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -16,7 +16,8 @@ mediatek-drm-y := mtk_disp_aal.o \
  mtk_dsi.o \
  mtk_dpi.o \
  mtk_ethdr.o \
- mtk_mdp_rdma.o
+ mtk_mdp_rdma.o \
+ mtk_padding.o
 
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
 
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h 
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 8465beeab435..c44f5b31bab5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -163,4 +163,8 @@ void mtk_mdp_rdma_config(struct device *dev, struct 
mtk_mdp_rdma_cfg *cfg,
 const u32 *mtk_mdp_rdma_get_formats(struct device *dev);
 size_t mtk_mdp_rdma_get_num_formats(struct device *dev);
 
+int mtk_padding_clk_enable(struct device *dev);
+void mtk_padding_clk_disable(struct device *dev);
+void mtk_padding_start(struct device *dev);
+void mtk_padding_stop(struct device *dev);
 #endif
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index cdce165c092e..62e6e9785443 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -1025,6 +1025,7 @@ static struct platform_driver * const mtk_drm_drivers[] = 
{
_dsi_driver,
_ethdr_driver,
_mdp_rdma_driver,
+   _padding_driver,
 };
 
 static int __init mtk_drm_init(void)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 8dca68ea1b94..d2efd715699f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -72,5 +72,5 @@ extern struct platform_driver mtk_dpi_driver;
 extern struct platform_driver mtk_dsi_driver;
 extern struct platform_driver mtk_ethdr_driver;
 extern struct platform_driver mtk_mdp_rdma_driver;
-
+extern struct platform_driver mtk_padding_driver;
 #endif /* MTK_DRM_DRV_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_padding.c 
b/drivers/gpu/drm/mediatek/mtk_padding.c
new file mode 100644
index ..14efb6ab2341
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_padding.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_disp_drv.h"
+#include "mtk_drm_crtc.h"
+#include "mtk_drm_ddp_comp.h"
+
+#define PADDING_CONTROL_REG0x00
+#define PADDING_BYPASS BIT(0)
+#define PADDING_ENABLE BIT(1)
+#define PADDING_PIC_SIZE_REG   0x04
+#define PADDING_H_REG  0x08 /* horizontal */
+#define PADDING_V_REG  0x0c /* vertical */
+#define PADDING_COLOR_REG  0x10
+
+/**
+ * struct mtk_padding - Basic information of the Padding
+ * @clk: Clock of the module
+ * @reg: Virtual address of the Padding for CPU to access
+ * @cmdq_reg: CMDQ setting of the Padding
+ *
+ * Every Padding should have different clock source, register base, and
+ * CMDQ settings, we stored these differences all together.
+ */
+struct mtk_padding {
+   struct clk  *clk;
+   void __iomem*reg;
+   struct cmdq_client_reg  cmdq_reg;
+};
+
+int mtk_padding_clk_enable(struct device *dev)
+{
+   struct mtk_padding *padding = dev_get_drvdata(dev);
+
+   return clk_prepare_enable(padding->clk);
+}
+
+void mtk_padding_clk_disable(struct device *dev)
+{
+   struct mtk_padding *padding = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(padding->clk);
+}
+
+void mtk_padding_start(struct device *dev)
+{
+   struct mtk_padding *padding = dev_get_drvdata(dev);
+
+   writel(PADDING_ENABLE | PADDING_BYPASS,
+  padding->reg + PADDING_CONTROL_REG);
+
+   /*
+* Notice that even the padding is in bypass mode,
+* all the settings must be cleared to 0 or
+* undefined behaviors could happen
+*/
+   writel(0, padding->reg + PADDING_PIC_SIZE_REG);
+   writel(0, padding->reg + PADDING_H_REG);
+   

[PATCH v10 16/24] drm/mediatek: Start/Stop components with function pointers

2023-10-18 Thread Hsiao Chien Sung
By registering component related functions to the pointers,
we can easily manage them within a for-loop and simplify the
logic of component start/stop process.

Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 20 +--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index aab98adcd9a4..07ab0e7c3d3b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -71,6 +71,8 @@ static const char * const 
private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
 static const struct mtk_ddp_comp_funcs ethdr = {
.clk_enable = mtk_ethdr_clk_enable,
.clk_disable = mtk_ethdr_clk_disable,
+   .start = mtk_ethdr_start,
+   .stop = mtk_ethdr_stop,
 };
 
 static const struct mtk_ddp_comp_funcs merge = {
@@ -190,16 +192,30 @@ void mtk_ovl_adaptor_config(struct device *dev, unsigned 
int w,
 
 void mtk_ovl_adaptor_start(struct device *dev)
 {
+   int i;
struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
 
-   mtk_ethdr_start(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+   for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+   if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+   !comp_matches[i].funcs->start)
+   continue;
+
+   comp_matches[i].funcs->start(ovl_adaptor->ovl_adaptor_comp[i]);
+   }
 }
 
 void mtk_ovl_adaptor_stop(struct device *dev)
 {
+   int i;
struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
 
-   mtk_ethdr_stop(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+   for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+   if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+   !comp_matches[i].funcs->stop)
+   continue;
+
+   comp_matches[i].funcs->stop(ovl_adaptor->ovl_adaptor_comp[i]);
+   }
 }
 
 /**
-- 
2.18.0



[PATCH v10 20/24] drm/mediatek: Add Padding to OVL adaptor

2023-10-18 Thread Hsiao Chien Sung
Add MT8188 Padding to OVL adaptor to probe the driver.

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 26 +++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index f46ca1c68610..f693b47745ba 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -29,6 +29,7 @@ enum mtk_ovl_adaptor_comp_type {
OVL_ADAPTOR_TYPE_ETHDR,
OVL_ADAPTOR_TYPE_MDP_RDMA,
OVL_ADAPTOR_TYPE_MERGE,
+   OVL_ADAPTOR_TYPE_PADDING,
OVL_ADAPTOR_TYPE_NUM,
 };
 
@@ -46,6 +47,14 @@ enum mtk_ovl_adaptor_comp_id {
OVL_ADAPTOR_MERGE1,
OVL_ADAPTOR_MERGE2,
OVL_ADAPTOR_MERGE3,
+   OVL_ADAPTOR_PADDING0,
+   OVL_ADAPTOR_PADDING1,
+   OVL_ADAPTOR_PADDING2,
+   OVL_ADAPTOR_PADDING3,
+   OVL_ADAPTOR_PADDING4,
+   OVL_ADAPTOR_PADDING5,
+   OVL_ADAPTOR_PADDING6,
+   OVL_ADAPTOR_PADDING7,
OVL_ADAPTOR_ID_MAX
 };
 
@@ -66,6 +75,7 @@ static const char * const 
private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
[OVL_ADAPTOR_TYPE_ETHDR]= "ethdr",
[OVL_ADAPTOR_TYPE_MDP_RDMA] = "vdo1-rdma",
[OVL_ADAPTOR_TYPE_MERGE]= "merge",
+   [OVL_ADAPTOR_TYPE_PADDING]  = "padding",
 };
 
 static const struct mtk_ddp_comp_funcs ethdr = {
@@ -80,6 +90,13 @@ static const struct mtk_ddp_comp_funcs merge = {
.clk_disable = mtk_merge_clk_disable,
 };
 
+static const struct mtk_ddp_comp_funcs padding = {
+   .clk_enable = mtk_padding_clk_enable,
+   .clk_disable = mtk_padding_clk_disable,
+   .start = mtk_padding_start,
+   .stop = mtk_padding_stop,
+};
+
 static const struct mtk_ddp_comp_funcs rdma = {
.power_on = mtk_mdp_rdma_power_on,
.power_off = mtk_mdp_rdma_power_off,
@@ -101,6 +118,14 @@ static const struct ovl_adaptor_comp_match 
comp_matches[OVL_ADAPTOR_ID_MAX] = {
[OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 
2,  },
[OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 
3,  },
[OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 
4,  },
+   [OVL_ADAPTOR_PADDING0] = { OVL_ADAPTOR_TYPE_PADDING, 
DDP_COMPONENT_PADDING0, 0,  },
+   [OVL_ADAPTOR_PADDING1] = { OVL_ADAPTOR_TYPE_PADDING, 
DDP_COMPONENT_PADDING1, 1,  },
+   [OVL_ADAPTOR_PADDING2] = { OVL_ADAPTOR_TYPE_PADDING, 
DDP_COMPONENT_PADDING2, 2,  },
+   [OVL_ADAPTOR_PADDING3] = { OVL_ADAPTOR_TYPE_PADDING, 
DDP_COMPONENT_PADDING3, 3,  },
+   [OVL_ADAPTOR_PADDING4] = { OVL_ADAPTOR_TYPE_PADDING, 
DDP_COMPONENT_PADDING4, 4,  },
+   [OVL_ADAPTOR_PADDING5] = { OVL_ADAPTOR_TYPE_PADDING, 
DDP_COMPONENT_PADDING5, 5,  },
+   [OVL_ADAPTOR_PADDING6] = { OVL_ADAPTOR_TYPE_PADDING, 
DDP_COMPONENT_PADDING6, 6,  },
+   [OVL_ADAPTOR_PADDING7] = { OVL_ADAPTOR_TYPE_PADDING, 
DDP_COMPONENT_PADDING7, 7,  },
 };
 
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -436,6 +461,7 @@ static int ovl_adaptor_comp_get_id(struct device *dev, 
struct device_node *node,
 }
 
 static const struct of_device_id mtk_ovl_adaptor_comp_dt_ids[] = {
+   { .compatible = "mediatek,mt8188-padding", .data = (void 
*)OVL_ADAPTOR_TYPE_PADDING },
{ .compatible = "mediatek,mt8195-disp-ethdr", .data = (void 
*)OVL_ADAPTOR_TYPE_ETHDR },
{ .compatible = "mediatek,mt8195-disp-merge", .data = (void 
*)OVL_ADAPTOR_TYPE_MERGE },
{ .compatible = "mediatek,mt8195-vdo1-rdma", .data = (void 
*)OVL_ADAPTOR_TYPE_MDP_RDMA },
-- 
2.18.0



[PATCH v10 11/24] drm/mediatek: Rename OVL_ADAPTOR_TYPE_RDMA

2023-10-18 Thread Hsiao Chien Sung
Rename OVL_ADAPTOR_TYPE_RDMA to OVL_ADAPTOR_TYPE_MDP_RDMA
to align the naming rule of mtk_ovl_adaptor_comp_id.

Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 22 +--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index f2f6a5c01a6d..33b0f74937a2 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -26,7 +26,7 @@
 #define MTK_OVL_ADAPTOR_LAYER_NUM 4
 
 enum mtk_ovl_adaptor_comp_type {
-   OVL_ADAPTOR_TYPE_RDMA = 0,
+   OVL_ADAPTOR_TYPE_MDP_RDMA = 0,
OVL_ADAPTOR_TYPE_MERGE,
OVL_ADAPTOR_TYPE_ETHDR,
OVL_ADAPTOR_TYPE_NUM,
@@ -61,20 +61,20 @@ struct mtk_disp_ovl_adaptor {
 };
 
 static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
-   [OVL_ADAPTOR_TYPE_RDMA] = "vdo1-rdma",
+   [OVL_ADAPTOR_TYPE_MDP_RDMA] = "vdo1-rdma",
[OVL_ADAPTOR_TYPE_MERGE]= "merge",
[OVL_ADAPTOR_TYPE_ETHDR]= "ethdr",
 };
 
 static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
-   [OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_RDMA, 0 },
-   [OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_RDMA, 1 },
-   [OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_RDMA, 2 },
-   [OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_RDMA, 3 },
-   [OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_RDMA, 4 },
-   [OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_RDMA, 5 },
-   [OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_RDMA, 6 },
-   [OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_RDMA, 7 },
+   [OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 0 },
+   [OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 1 },
+   [OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 2 },
+   [OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 3 },
+   [OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 4 },
+   [OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 5 },
+   [OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 6 },
+   [OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 7 },
[OVL_ADAPTOR_MERGE0]= { OVL_ADAPTOR_TYPE_MERGE, 1 },
[OVL_ADAPTOR_MERGE1]= { OVL_ADAPTOR_TYPE_MERGE, 2 },
[OVL_ADAPTOR_MERGE2]= { OVL_ADAPTOR_TYPE_MERGE, 3 },
@@ -387,7 +387,7 @@ static int ovl_adaptor_comp_get_id(struct device *dev, 
struct device_node *node,
 static const struct of_device_id mtk_ovl_adaptor_comp_dt_ids[] = {
{
.compatible = "mediatek,mt8195-vdo1-rdma",
-   .data = (void *)OVL_ADAPTOR_TYPE_RDMA,
+   .data = (void *)OVL_ADAPTOR_TYPE_MDP_RDMA,
}, {
.compatible = "mediatek,mt8195-disp-merge",
.data = (void *)OVL_ADAPTOR_TYPE_MERGE,
-- 
2.18.0



[PATCH v10 08/24] soc: mediatek: Support MT8188 VDOSYS1 Padding in mtk-mmsys

2023-10-18 Thread Hsiao Chien Sung
- Add Padding components
- Add Mutex module definitions for Padding

Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/soc/mediatek/mtk-mutex.c   | 16 
 include/linux/soc/mediatek/mtk-mmsys.h |  8 
 2 files changed, 24 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 988a678819d9..d52ce093adb7 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -142,6 +142,14 @@
 #define MT8188_MUTEX_MOD_DISP1_MDP_RDMA5   5
 #define MT8188_MUTEX_MOD_DISP1_MDP_RDMA6   6
 #define MT8188_MUTEX_MOD_DISP1_MDP_RDMA7   7
+#define MT8188_MUTEX_MOD_DISP1_PADDING08
+#define MT8188_MUTEX_MOD_DISP1_PADDING19
+#define MT8188_MUTEX_MOD_DISP1_PADDING210
+#define MT8188_MUTEX_MOD_DISP1_PADDING311
+#define MT8188_MUTEX_MOD_DISP1_PADDING412
+#define MT8188_MUTEX_MOD_DISP1_PADDING513
+#define MT8188_MUTEX_MOD_DISP1_PADDING614
+#define MT8188_MUTEX_MOD_DISP1_PADDING715
 #define MT8188_MUTEX_MOD_DISP1_VPP_MERGE0  20
 #define MT8188_MUTEX_MOD_DISP1_VPP_MERGE1  21
 #define MT8188_MUTEX_MOD_DISP1_VPP_MERGE2  22
@@ -474,6 +482,14 @@ static const unsigned int 
mt8188_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_MDP_RDMA5] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA5,
[DDP_COMPONENT_MDP_RDMA6] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA6,
[DDP_COMPONENT_MDP_RDMA7] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA7,
+   [DDP_COMPONENT_PADDING0] = MT8188_MUTEX_MOD_DISP1_PADDING0,
+   [DDP_COMPONENT_PADDING1] = MT8188_MUTEX_MOD_DISP1_PADDING1,
+   [DDP_COMPONENT_PADDING2] = MT8188_MUTEX_MOD_DISP1_PADDING2,
+   [DDP_COMPONENT_PADDING3] = MT8188_MUTEX_MOD_DISP1_PADDING3,
+   [DDP_COMPONENT_PADDING4] = MT8188_MUTEX_MOD_DISP1_PADDING4,
+   [DDP_COMPONENT_PADDING5] = MT8188_MUTEX_MOD_DISP1_PADDING5,
+   [DDP_COMPONENT_PADDING6] = MT8188_MUTEX_MOD_DISP1_PADDING6,
+   [DDP_COMPONENT_PADDING7] = MT8188_MUTEX_MOD_DISP1_PADDING7,
[DDP_COMPONENT_MERGE1] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE0,
[DDP_COMPONENT_MERGE2] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE1,
[DDP_COMPONENT_MERGE3] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE2,
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
b/include/linux/soc/mediatek/mtk-mmsys.h
index 2475ef914746..4885b065b849 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -62,6 +62,14 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL_2L1,
DDP_COMPONENT_OVL_2L2,
DDP_COMPONENT_OVL1,
+   DDP_COMPONENT_PADDING0,
+   DDP_COMPONENT_PADDING1,
+   DDP_COMPONENT_PADDING2,
+   DDP_COMPONENT_PADDING3,
+   DDP_COMPONENT_PADDING4,
+   DDP_COMPONENT_PADDING5,
+   DDP_COMPONENT_PADDING6,
+   DDP_COMPONENT_PADDING7,
DDP_COMPONENT_POSTMASK0,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
-- 
2.18.0



[PATCH v10 22/24] drm/mediatek: Remove the redundant driver data for DPI

2023-10-18 Thread Hsiao Chien Sung
DPI input is in 1T2P mode on both MT8195 and MT8188.
Remove the redundant driver data to align the settings, or
the screen will glitch.

Fixes: 2847cd7e6403 ("drm/mediatek: Add mt8188 dpi compatibles and platform 
data")

Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 1bf6041dd88b..d633f1ca3e71 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -967,20 +967,6 @@ static const struct mtk_dpi_conf mt8186_conf = {
.csc_enable_bit = CSC_ENABLE,
 };
 
-static const struct mtk_dpi_conf mt8188_dpintf_conf = {
-   .cal_factor = mt8195_dpintf_calculate_factor,
-   .max_clock_khz = 60,
-   .output_fmts = mt8195_output_fmts,
-   .num_output_fmts = ARRAY_SIZE(mt8195_output_fmts),
-   .pixels_per_iter = 4,
-   .input_2pixel = false,
-   .dimension_mask = DPINTF_HPW_MASK,
-   .hvsize_mask = DPINTF_HSIZE_MASK,
-   .channel_swap_shift = DPINTF_CH_SWAP,
-   .yuv422_en_bit = DPINTF_YUV422_EN,
-   .csc_enable_bit = DPINTF_CSC_ENABLE,
-};
-
 static const struct mtk_dpi_conf mt8192_conf = {
.cal_factor = mt8183_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -1104,7 +1090,7 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8173-dpi", .data = _conf },
{ .compatible = "mediatek,mt8183-dpi", .data = _conf },
{ .compatible = "mediatek,mt8186-dpi", .data = _conf },
-   { .compatible = "mediatek,mt8188-dp-intf", .data = _dpintf_conf 
},
+   { .compatible = "mediatek,mt8188-dp-intf", .data = _dpintf_conf 
},
{ .compatible = "mediatek,mt8192-dpi", .data = _conf },
{ .compatible = "mediatek,mt8195-dp-intf", .data = _dpintf_conf 
},
{ /* sentinel */ },
-- 
2.18.0



[PATCH v10 17/24] drm/mediatek: Sort OVL adaptor components

2023-10-18 Thread Hsiao Chien Sung
Sort OVL adaptor components' names in alphabetical order.

Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 07ab0e7c3d3b..06d28e8fc29a 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -26,13 +26,14 @@
 #define MTK_OVL_ADAPTOR_LAYER_NUM 4
 
 enum mtk_ovl_adaptor_comp_type {
-   OVL_ADAPTOR_TYPE_MDP_RDMA = 0,
-   OVL_ADAPTOR_TYPE_MERGE,
OVL_ADAPTOR_TYPE_ETHDR,
+   OVL_ADAPTOR_TYPE_MDP_RDMA,
+   OVL_ADAPTOR_TYPE_MERGE,
OVL_ADAPTOR_TYPE_NUM,
 };
 
 enum mtk_ovl_adaptor_comp_id {
+   OVL_ADAPTOR_ETHDR0,
OVL_ADAPTOR_MDP_RDMA0,
OVL_ADAPTOR_MDP_RDMA1,
OVL_ADAPTOR_MDP_RDMA2,
@@ -45,7 +46,6 @@ enum mtk_ovl_adaptor_comp_id {
OVL_ADAPTOR_MERGE1,
OVL_ADAPTOR_MERGE2,
OVL_ADAPTOR_MERGE3,
-   OVL_ADAPTOR_ETHDR0,
OVL_ADAPTOR_ID_MAX
 };
 
@@ -63,9 +63,9 @@ struct mtk_disp_ovl_adaptor {
 };
 
 static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
+   [OVL_ADAPTOR_TYPE_ETHDR]= "ethdr",
[OVL_ADAPTOR_TYPE_MDP_RDMA] = "vdo1-rdma",
[OVL_ADAPTOR_TYPE_MERGE]= "merge",
-   [OVL_ADAPTOR_TYPE_ETHDR]= "ethdr",
 };
 
 static const struct mtk_ddp_comp_funcs ethdr = {
@@ -88,6 +88,7 @@ static const struct mtk_ddp_comp_funcs rdma = {
 };
 
 static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
+   [OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, 
DDP_COMPONENT_ETHDR_MIXER, 0,  },
[OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA0, 0,  },
[OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA1, 1,  },
[OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, 
DDP_COMPONENT_MDP_RDMA2, 2,  },
@@ -100,7 +101,6 @@ static const struct ovl_adaptor_comp_match 
comp_matches[OVL_ADAPTOR_ID_MAX] = {
[OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 
2,  },
[OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 
3,  },
[OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 
4,  },
-   [OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, 
DDP_COMPONENT_ETHDR_MIXER, 0,  },
 };
 
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -398,6 +398,7 @@ void mtk_ovl_adaptor_remove_comp(struct device *dev, struct 
mtk_mutex *mutex)
 
 void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev, 
unsigned int next)
 {
+   mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_ETHDR_MIXER, next);
mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MDP_RDMA0, 
DDP_COMPONENT_MERGE1);
mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MDP_RDMA1, 
DDP_COMPONENT_MERGE1);
mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MDP_RDMA2, 
DDP_COMPONENT_MERGE2);
@@ -405,11 +406,11 @@ void mtk_ovl_adaptor_connect(struct device *dev, struct 
device *mmsys_dev, unsig
mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MERGE2, 
DDP_COMPONENT_ETHDR_MIXER);
mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MERGE3, 
DDP_COMPONENT_ETHDR_MIXER);
mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MERGE4, 
DDP_COMPONENT_ETHDR_MIXER);
-   mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_ETHDR_MIXER, next);
 }
 
 void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev, 
unsigned int next)
 {
+   mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_ETHDR_MIXER, next);
mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MDP_RDMA0, 
DDP_COMPONENT_MERGE1);
mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MDP_RDMA1, 
DDP_COMPONENT_MERGE1);
mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MDP_RDMA2, 
DDP_COMPONENT_MERGE2);
@@ -417,7 +418,6 @@ void mtk_ovl_adaptor_disconnect(struct device *dev, struct 
device *mmsys_dev, un
mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MERGE2, 
DDP_COMPONENT_ETHDR_MIXER);
mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MERGE3, 
DDP_COMPONENT_ETHDR_MIXER);
mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MERGE4, 
DDP_COMPONENT_ETHDR_MIXER);
-   mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_ETHDR_MIXER, next);
 }
 
 static int ovl_adaptor_comp_get_id(struct device *dev, struct device_node 
*node,
-- 
2.18.0



[PATCH v10 23/24] drm/mediatek: Fix underrun in VDO1 when switches off the layer

2023-10-18 Thread Hsiao Chien Sung
Do not reset Merge while using CMDQ because reset API doesn't
wait for frame done event as CMDQ does and could lead to
underrun when the layer is switching off.

Fixes: aaf94f7c3ae6 ("drm/mediatek: Add display merge async reset control")

Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/mtk_disp_merge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c 
b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
index fd14a59bc951..c19fb1836034 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
@@ -104,7 +104,7 @@ void mtk_merge_stop_cmdq(struct device *dev, struct 
cmdq_pkt *cmdq_pkt)
mtk_ddp_write(cmdq_pkt, 0, >cmdq_reg, priv->regs,
  DISP_REG_MERGE_CTRL);
 
-   if (priv->async_clk)
+   if (!cmdq_pkt && priv->async_clk)
reset_control_reset(priv->reset_ctl);
 }
 
-- 
2.18.0



[PATCH v10 03/24] dt-bindings: display: mediatek: merge: Add compatible for MT8188

2023-10-18 Thread Hsiao Chien Sung
Add compatible name for MediaTek MT8188 MERGE.

Reviewed-by: AngeloGioacchino Del Regno 

Acked-by: Krzysztof Kozlowski 
Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 
---
 .../devicetree/bindings/display/mediatek/mediatek,merge.yaml   | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index eead5cb8636e..5c678695162e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -27,6 +27,9 @@ properties:
   - items:
   - const: mediatek,mt6795-disp-merge
   - const: mediatek,mt8173-disp-merge
+  - items:
+  - const: mediatek,mt8188-disp-merge
+  - const: mediatek,mt8195-disp-merge
 
   reg:
 maxItems: 1
-- 
2.18.0



[PATCH v10 01/24] dt-bindings: display: mediatek: ethdr: Add compatible for MT8188

2023-10-18 Thread Hsiao Chien Sung
Add compatible name for MediaTek MT8188 ETHDR.

Reviewed-by: AngeloGioacchino Del Regno 

Acked-by: Krzysztof Kozlowski 
Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 
---
 .../bindings/display/mediatek/mediatek,ethdr.yaml   | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
index 801fa66ae615..677882348ede 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
@@ -23,7 +23,11 @@ description:
 
 properties:
   compatible:
-const: mediatek,mt8195-disp-ethdr
+oneOf:
+  - const: mediatek,mt8195-disp-ethdr
+  - items:
+  - const: mediatek,mt8188-disp-ethdr
+  - const: mediatek,mt8195-disp-ethdr
 
   reg:
 maxItems: 7
-- 
2.18.0



[PATCH v10 15/24] drm/mediatek: Remove ineffectual power management codes

2023-10-18 Thread Hsiao Chien Sung
Display modules will be powered on when .atomic_enable(),
there is no need to do it again in mtk_crtc_ddp_hw_init().
Besides, the DRM devices are created manually when mtk-mmsys
is probed and there is no power domain linked to it.

Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")

Signed-off-by: Hsiao Chien Sung 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index bc4cc75cca18..c7edd80be428 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -362,22 +361,16 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc, struct drm_atomic
drm_connector_list_iter_end(_iter);
}
 
-   ret = pm_runtime_resume_and_get(crtc->dev->dev);
-   if (ret < 0) {
-   DRM_ERROR("Failed to enable power domain: %d\n", ret);
-   return ret;
-   }
-
ret = mtk_mutex_prepare(mtk_crtc->mutex);
if (ret < 0) {
DRM_ERROR("Failed to enable mutex clock: %d\n", ret);
-   goto err_pm_runtime_put;
+   goto error;
}
 
ret = mtk_crtc_ddp_clk_enable(mtk_crtc);
if (ret < 0) {
DRM_ERROR("Failed to enable component clocks: %d\n", ret);
-   goto err_mutex_unprepare;
+   goto error;
}
 
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
@@ -426,16 +419,13 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc, struct drm_atomic
 
return 0;
 
-err_mutex_unprepare:
+error:
mtk_mutex_unprepare(mtk_crtc->mutex);
-err_pm_runtime_put:
-   pm_runtime_put(crtc->dev->dev);
return ret;
 }
 
 static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
 {
-   struct drm_device *drm = mtk_crtc->base.dev;
struct drm_crtc *crtc = _crtc->base;
int i;
 
@@ -465,8 +455,6 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc 
*mtk_crtc)
mtk_crtc_ddp_clk_disable(mtk_crtc);
mtk_mutex_unprepare(mtk_crtc->mutex);
 
-   pm_runtime_put(drm->dev);
-
if (crtc->state->event && !crtc->state->active) {
spin_lock_irq(>dev->event_lock);
drm_crtc_send_vblank_event(crtc, crtc->state->event);
-- 
2.18.0



[PATCH v10 00/24] Add display driver for MT8188 VDOSYS1

2023-10-18 Thread Hsiao Chien Sung
This series is based on mediatek-drm-next.

Changes in v10:
- Remove "Reviewed-by" tags of the following commits:
- drm/mediatek: Power on/off devices with function pointers
- drm/mediatek: Manage component's clock with function pointers
- Separate the commit into smaller ones
- (new) drm/mediatek: Remove the redundant driver data for DPI

Changes in v9:
- Add a static inline function to power off the device
- Change driver name to "mediatek-disp-padding"
- Fix typo and kernel doc format error

Changes in v8:
- Power on/off the components with .power_on() and .power_off()
- Remove mtk_padding_config()
- Remove "Reviewed-by" tags in "drm/mediatek: Add Padding to OVL adaptor"
  because of the modifications.

Changes in v7:
- Start/Stop the components in OVL Adaptor with function pointers
- Refine Padding driver
- Fix underrun when the layer is switching off

Changes in v6:
- Separate the commits into smaller ones
- Add DPI input mode setting
- Fix VDOSYS1 power-on issues

Changes in v5:
- Reuse .clk_enable/.clk_disable in struct mtk_ddp_comp_funcs
  in mtk_disp_ovl_adaptor.c
- Adjust commits order

Changes in v4:
- Add new functions in mtk_disp_ovl_adaptor.c to enable/disable
  components and reuse them when clock enable/disable
- Rename components in mtk_disp_ovl_adaptor.c and sort them in
  alphabetical order

Changes in v3:
- Define macro MMSYS_RST_NR in mtk-mmsys.h and update reset table
- Fix typos (ETDHR -> ETHDR, VSNYC -> VSYNC)
- Rebase dt-bindings on linux-next
- Refine description of Padding
- Squash reset bit map commits for VDO0 and VDO1 into one

Changes in v2:
- Remove redundant compatibles of MT8188 because it shares the same
  configuration with MT8195
- Separate dt-bindings by modules
- Support reset bit mapping in mmsys driver

Hsiao Chien Sung (24):
  dt-bindings: display: mediatek: ethdr: Add compatible for MT8188
  dt-bindings: display: mediatek: mdp-rdma: Add compatible for MT8188
  dt-bindings: display: mediatek: merge: Add compatible for MT8188
  dt-bindings: display: mediatek: padding: Add MT8188
  dt-bindings: arm: mediatek: Add compatible for MT8188
  dt-bindings: reset: mt8188: Add VDOSYS reset control bits
  soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys
  soc: mediatek: Support MT8188 VDOSYS1 Padding in mtk-mmsys
  soc: mediatek: Support reset bit mapping in mmsys driver
  soc: mediatek: Add MT8188 VDOSYS reset bit map
  drm/mediatek: Rename OVL_ADAPTOR_TYPE_RDMA
  drm/mediatek: Add component ID to component match structure
  drm/mediatek: Manage component's clock with function pointers
  drm/mediatek: Power on/off devices with function pointers
  drm/mediatek: Remove ineffectual power management codes
  drm/mediatek: Start/Stop components with function pointers
  drm/mediatek: Sort OVL adaptor components
  drm/mediatek: Refine device table of OVL adaptor
  drm/mediatek: Support MT8188 Padding in display driver
  drm/mediatek: Add Padding to OVL adaptor
  drm/mediatek: Return error if MDP RDMA failed to enable the clock
  drm/mediatek: Remove the redundant driver data for DPI
  drm/mediatek: Fix underrun in VDO1 when switches off the layer
  drm/mediatek: Support MT8188 VDOSYS1 in display driver

 .../bindings/arm/mediatek/mediatek,mmsys.yaml |   1 +
 .../display/mediatek/mediatek,ethdr.yaml  |   6 +-
 .../display/mediatek/mediatek,mdp-rdma.yaml   |   6 +-
 .../display/mediatek/mediatek,merge.yaml  |   3 +
 .../display/mediatek/mediatek,padding.yaml|  81 ++
 drivers/gpu/drm/mediatek/Makefile |   3 +-
 drivers/gpu/drm/mediatek/mtk_disp_drv.h   |   8 +
 drivers/gpu/drm/mediatek/mtk_disp_merge.c |   2 +-
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 274 +++---
 drivers/gpu/drm/mediatek/mtk_dpi.c|  16 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |  28 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |   2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   |  20 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c|   5 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h|   2 +-
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c   |  19 +-
 drivers/gpu/drm/mediatek/mtk_padding.c| 160 ++
 drivers/soc/mediatek/mt8188-mmsys.h   | 210 ++
 drivers/soc/mediatek/mtk-mmsys.c  |  27 ++
 drivers/soc/mediatek/mtk-mmsys.h  |  32 ++
 drivers/soc/mediatek/mtk-mutex.c  |  51 
 include/dt-bindings/reset/mt8188-resets.h |  75 +
 include/linux/soc/mediatek/mtk-mmsys.h|   8 +
 23 files changed, 893 insertions(+), 146 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
 create mode 100644 drivers/gpu/drm/mediatek/mtk_padding.c

--
2.18.0



[PATCH v10 02/24] dt-bindings: display: mediatek: mdp-rdma: Add compatible for MT8188

2023-10-18 Thread Hsiao Chien Sung
Add compatible name for MediaTek MT8188 MDP-RDMA.

Reviewed-by: AngeloGioacchino Del Regno 

Acked-by: Krzysztof Kozlowski 
Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 
---
 .../bindings/display/mediatek/mediatek,mdp-rdma.yaml| 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
index dd12e2ff685c..7570a0684967 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
@@ -21,7 +21,11 @@ description:
 
 properties:
   compatible:
-const: mediatek,mt8195-vdo1-rdma
+oneOf:
+  - const: mediatek,mt8195-vdo1-rdma
+  - items:
+  - const: mediatek,mt8188-vdo1-rdma
+  - const: mediatek,mt8195-vdo1-rdma
 
   reg:
 maxItems: 1
-- 
2.18.0



Re: [PATCH v4 5/6] drm/msm/dpu: Add hw revision 4.1 (SDM670)

2023-10-18 Thread kernel test robot
Hi Richard,

kernel test robot noticed the following build errors:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next robh/for-next linus/master v6.6-rc6 
next-20231018]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Richard-Acayan/dt-bindings-display-msm-dsi-controller-main-add-SDM670-compatible/20231017-155345
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20231017021805.1083350-14-mailingradian%40gmail.com
patch subject: [PATCH v4 5/6] drm/msm/dpu: Add hw revision 4.1 (SDM670)
config: sparc-allyesconfig 
(https://download.01.org/0day-ci/archive/20231019/202310191232.ptdontbi-...@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231019/202310191232.ptdontbi-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202310191232.ptdontbi-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:658:
>> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h:29:26: error: 
>> 'dpu_vig_sblk_qseed3_1_3' undeclared here (not in a function)
  29 | .sblk = _vig_sblk_qseed3_1_3,
 |  ^~~
>> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h:45:26: error: 
>> 'dpu_dma_sblk' undeclared here (not in a function); did you mean 
>> 'dpu_dsc_blk'?
  45 | .sblk = _dma_sblk,
 |  ^~~~
 |  dpu_dsc_blk


vim +/dpu_vig_sblk_qseed3_1_3 +29 
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h

23  
24  static const struct dpu_sspp_cfg sdm670_sspp[] = {
25  {
26  .name = "sspp_0", .id = SSPP_VIG0,
27  .base = 0x4000, .len = 0x1c8,
28  .features = VIG_SDM845_MASK_SDMA,
  > 29  .sblk = _vig_sblk_qseed3_1_3,
30  .xin_id = 0,
31  .type = SSPP_TYPE_VIG,
32  .clk_ctrl = DPU_CLK_CTRL_VIG0,
33  }, {
34  .name = "sspp_1", .id = SSPP_VIG1,
35  .base = 0x6000, .len = 0x1c8,
36  .features = VIG_SDM845_MASK_SDMA,
37  .sblk = _vig_sblk_qseed3_1_3,
38  .xin_id = 4,
39  .type = SSPP_TYPE_VIG,
40  .clk_ctrl = DPU_CLK_CTRL_VIG0,
41  }, {
42  .name = "sspp_8", .id = SSPP_DMA0,
43  .base = 0x24000, .len = 0x1c8,
44  .features = DMA_SDM845_MASK_SDMA,
  > 45  .sblk = _dma_sblk,
46  .xin_id = 1,
47  .type = SSPP_TYPE_DMA,
48  .clk_ctrl = DPU_CLK_CTRL_DMA0,
49  }, {
50  .name = "sspp_9", .id = SSPP_DMA1,
51  .base = 0x26000, .len = 0x1c8,
52  .features = DMA_CURSOR_SDM845_MASK_SDMA,
53  .sblk = _dma_sblk,
54  .xin_id = 5,
55  .type = SSPP_TYPE_DMA,
56  .clk_ctrl = DPU_CLK_CTRL_DMA1,
57  }, {
58  .name = "sspp_10", .id = SSPP_DMA2,
59  .base = 0x28000, .len = 0x1c8,
60  .features = DMA_CURSOR_SDM845_MASK_SDMA,
61  .sblk = _dma_sblk,
62  .xin_id = 9,
63  .type = SSPP_TYPE_DMA,
64  .clk_ctrl = DPU_CLK_CTRL_DMA2,
65  },
66  };
67  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


Re: [PATCH RFC v6 01/10] drm: Introduce pixel_source DRM plane property

2023-10-18 Thread Jessica Zhang




On 9/24/2023 3:06 AM, Dmitry Baryshkov wrote:

On 29/08/2023 03:05, Jessica Zhang wrote:

Add support for pixel_source property to drm_plane and related
documentation. In addition, force pixel_source to
DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
legacy userspace.

This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources will be defined in the
drm_plane_pixel_source enum.

Currently, the only pixel sources are DRM_PLANE_PIXEL_SOURCE_FB (the
default value) and DRM_PLANE_PIXEL_SOURCE_NONE.

Signed-off-by: Jessica Zhang 


Acked-by: Dmitry Baryshkov 

Minor question below


---
  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
  drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
  drivers/gpu/drm/drm_blend.c   | 90 
+++

  drivers/gpu/drm/drm_plane.c   | 19 +--
  include/drm/drm_blend.h   |  2 +
  include/drm/drm_plane.h   | 21 
  6 files changed, 133 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c

index 784e63d70a42..01638c51ce0a 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct 
drm_plane_state *plane_state,

  plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
  plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
+    plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
  if (plane->color_encoding_property) {
  if (!drm_object_property_get_default_value(>base,
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c

index d867e7f9f2cd..454f980e16c9 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -544,6 +544,8 @@ static int drm_atomic_plane_set_property(struct 
drm_plane *plane,

  state->src_w = val;
  } else if (property == config->prop_src_h) {
  state->src_h = val;
+    } else if (property == plane->pixel_source_property) {
+    state->pixel_source = val;
  } else if (property == plane->alpha_property) {
  state->alpha = val;
  } else if (property == plane->blend_mode_property) {
@@ -616,6 +618,8 @@ drm_atomic_plane_get_property(struct drm_plane 
*plane,

  *val = state->src_w;
  } else if (property == config->prop_src_h) {
  *val = state->src_h;
+    } else if (property == plane->pixel_source_property) {
+    *val = state->pixel_source;
  } else if (property == plane->alpha_property) {
  *val = state->alpha;
  } else if (property == plane->blend_mode_property) {
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 6e74de833466..c3c57bae06b7 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -185,6 +185,21 @@
   * plane does not expose the "alpha" property, then this is
   * assumed to be 1.0
   *
+ * pixel_source:
+ *    pixel_source is set up with 
drm_plane_create_pixel_source_property().
+ *    It is used to toggle the active source of pixel data for the 
plane.

+ *    The plane will only display data from the set pixel_source -- any
+ *    data from other sources will be ignored.
+ *
+ *    Possible values:
+ *
+ *    "NONE":
+ *    No active pixel source.
+ *    Committing with a NONE pixel source will disable the plane.
+ *
+ *    "FB":
+ *    Framebuffer source set by the "FB_ID" property.
+ *
   * Note that all the property extensions described here apply either 
to the
   * plane or the CRTC (e.g. for the background color, which currently 
is not

   * exposed and assumed to be black).
@@ -615,3 +630,78 @@ int drm_plane_create_blend_mode_property(struct 
drm_plane *plane,

  return 0;
  }
  EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
+
+static const struct drm_prop_enum_list drm_pixel_source_enum_list[] = {
+    { DRM_PLANE_PIXEL_SOURCE_NONE, "NONE" },
+    { DRM_PLANE_PIXEL_SOURCE_FB, "FB" },
+};
+
+/**
+ * drm_plane_create_pixel_source_property - create a new pixel source 
property

+ * @plane: DRM plane
+ * @extra_sources: Bitmask of additional supported pixel_sources for 
the driver.
+ *   DRM_PLANE_PIXEL_SOURCE_FB and 
DRM_PLANE_PIXEL_SOURCE_NONE will

+ *   always be enabled as supported sources.
+ *
+ * This creates a new property describing the current source of pixel 
data for the
+ * plane. The pixel_source will be initialized as 
DRM_PLANE_PIXEL_SOURCE_FB by default.

+ *
+ * Drivers can set a custom default source by overriding the 
pixel_source value in

+ * drm_plane_funcs.reset()
+ *
+ * The property is exposed to userspace as an enumeration property 
called

+ * "pixel_source" and has the following enumeration values:
+ *
+ * "NONE":
+ * No active pixel source
+ *
+ * "FB":
+ *    Framebuffer pixel source
+ *
+ * Returns:
+ * Zero 

Re: [PATCH v3] drm/virtio: add new virtio gpu capset definitions

2023-10-18 Thread Akihiko Odaki

On 2023/10/19 8:25, Gurchetan Singh wrote:



On Tue, Oct 10, 2023 at 9:41 PM Huang Rui > wrote:


On Tue, Oct 10, 2023 at 11:52:14PM +0800, Dmitry Osipenko wrote:
 > On 10/10/23 18:40, Dmitry Osipenko wrote:
 > > On 10/10/23 16:57, Huang Rui wrote:
 > >> These definitions are used fro qemu, and qemu imports this
marco in the
 > >> headers to enable gfxstream, venus, cross domain, and drm (native
 > >> context) for virtio gpu. So it should add them even kernel
doesn't use
 > >> this.
 > >>
 > >> Signed-off-by: Huang Rui mailto:ray.hu...@amd.com>>
 > >> Reviewed-by: Akihiko Odaki mailto:akihiko.od...@daynix.com>>
 > >> ---
 > >>
 > >> Changes V1 -> V2:
 > >> - Add all capsets including gfxstream and venus in kernel
header (Dmitry Osipenko)
 > >>
 > >> Changes V2 -> V3:
 > >> - Add missed capsets including cross domain and drm (native
context)
 > >>   (Dmitry Osipenko)
 > >>
 > >> v1:
https://lore.kernel.org/lkml/20230915105918.3763061-1-ray.hu...@amd.com/ 

 > >> v2:
https://lore.kernel.org/lkml/20231010032553.1138036-1-ray.hu...@amd.com/ 

 > >>
 > >>  include/uapi/linux/virtio_gpu.h | 4 
 > >>  1 file changed, 4 insertions(+)
 > >>
 > >> diff --git a/include/uapi/linux/virtio_gpu.h
b/include/uapi/linux/virtio_gpu.h
 > >> index f556fde07b76..240911c8da31 100644
 > >> --- a/include/uapi/linux/virtio_gpu.h
 > >> +++ b/include/uapi/linux/virtio_gpu.h
 > >> @@ -309,6 +309,10 @@ struct virtio_gpu_cmd_submit {
 > >>
 > >>  #define VIRTIO_GPU_CAPSET_VIRGL 1
 > >>  #define VIRTIO_GPU_CAPSET_VIRGL2 2
 > >> +#define VIRTIO_GPU_CAPSET_GFXSTREAM 3
 > >
 > > The GFXSTREAM capset isn't correct, it should be
GFXSTREAM_VULKAN in
 > > accordance to [1] and [2]. There are more capsets for GFXSTREAM.
 > >
 > > [1]
 > >

https://github.com/google/crosvm/blob/main/rutabaga_gfx/src/rutabaga_utils.rs#L172 

 > >
 > > [2]
 > >

https://patchwork.kernel.org/project/qemu-devel/patch/20231006010835.444-7-gurchetansi...@chromium.org/
 

 >
 > Though, maybe those are "rutabaga" capsets that not related to
 > virtio-gpu because crosvm has another defs for virtio-gpu capsets
[3].
 > The DRM capset is oddly missing in [3] and code uses "rutabaga"
capset
 > for DRM and virtio-gpu.
 >
 > [3]
 >

https://github.com/google/crosvm/blob/main/devices/src/virtio/gpu/protocol.rs#L416 


Yes, [3] is the file that I referred to add these capsets
definitions. And
it's defined as gfxstream not gfxstream_vulkan.

 >
 > Gurchetan, could you please clarify which capsets definitions are
 > related to virtio-gpu and gfxstream. The
 > GFXSTREAM_VULKAN/GLES/MAGMA/COMPOSER or just the single GFXSTREAM?


It should be GFXSTREAM_VULKAN.  The rest are more experimental and easy 
to modify in terms of the enum value, should the need arise.


I imagine the virtio-spec update to reflect the GFXSTREAM to 
GFXSTREAM_VULKAN change will happen eventually.


I think this is a matter what the committee should determine, but in 
general I don't think it is OK to change the existing identifier.


I also think even experimental values should be added to virtio spec at 
an early stage unless such an "experiment" is done only on one laptop. 
We can obsolete a capset anytime so it's more important to avoid 
conflicts of capsets.


[PATCH] drm/amd/display: clean up some inconsistent indenting

2023-10-18 Thread Jiapeng Chong
No functional modification involved.

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2902 dm_resume() 
warn: inconsistent indenting.

Reported-by: Abaci Robot 
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6940
Signed-off-by: Jiapeng Chong 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 801f87a12ccf..0e1f8c5d7f9b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2899,7 +2899,7 @@ static int dm_resume(void *handle)
}
 
/* power on hardware */
-dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D0);
+   dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D0);
 
/* program HPD filter */
dc_resume(dm->dc);
-- 
2.20.1.7.g153144c



Re: [PATCH v6 5/7] drm/sched: Split free_job into own work item

2023-10-18 Thread Luben Tuikov
Hi,

On 2023-10-17 11:09, Matthew Brost wrote:
> Rather than call free_job and run_job in same work item have a dedicated
> work item for each. This aligns with the design and intended use of work
> queues.
> 
> v2:
>- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
>  timestamp in free_job() work item (Danilo)
> v3:
>   - Drop forward dec of drm_sched_select_entity (Boris)
>   - Return in drm_sched_run_job_work if entity NULL (Boris)
> v4:
>   - Replace dequeue with peek and invert logic (Luben)
>   - Wrap to 100 lines (Luben)
>   - Update comments for *_queue / *_queue_if_ready functions (Luben)
> 
> Signed-off-by: Matthew Brost 
> ---
>  drivers/gpu/drm/scheduler/sched_main.c | 287 +++--
>  include/drm/gpu_scheduler.h|   8 +-
>  2 files changed, 178 insertions(+), 117 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 273e0fbc4eab..b1b8d9f96da5 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -213,11 +213,12 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
>   * drm_sched_rq_select_entity_rr - Select an entity which could provide a 
> job to run
>   *
>   * @rq: scheduler run queue to check.
> + * @peek: Just find, don't set to current.

The "peek" rename is good--thanks!

>   *
>   * Try to find a ready entity, returns NULL if none found.
>   */
>  static struct drm_sched_entity *
> -drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
> +drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq, bool peek)
>  {
>   struct drm_sched_entity *entity;
>  
> @@ -227,8 +228,10 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
>   if (entity) {
>   list_for_each_entry_continue(entity, >entities, list) {
>   if (drm_sched_entity_is_ready(entity)) {
> - rq->current_entity = entity;
> - reinit_completion(>entity_idle);
> + if (!peek) {
> + rq->current_entity = entity;
> + reinit_completion(>entity_idle);
> + }
>   spin_unlock(>lock);
>   return entity;
>   }
> @@ -238,8 +241,10 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
>   list_for_each_entry(entity, >entities, list) {
>  
>   if (drm_sched_entity_is_ready(entity)) {
> - rq->current_entity = entity;
> - reinit_completion(>entity_idle);
> + if (!peek) {
> + rq->current_entity = entity;
> + reinit_completion(>entity_idle);
> + }
>   spin_unlock(>lock);
>   return entity;
>   }
> @@ -257,11 +262,12 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
>   * drm_sched_rq_select_entity_fifo - Select an entity which provides a job 
> to run
>   *
>   * @rq: scheduler run queue to check.
> + * @peek: Just find, don't set to current.
>   *
>   * Find oldest waiting ready entity, returns NULL if none found.
>   */
>  static struct drm_sched_entity *
> -drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
> +drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq, bool peek)
>  {
>   struct rb_node *rb;
>  
> @@ -271,8 +277,10 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
>  
>   entity = rb_entry(rb, struct drm_sched_entity, rb_tree_node);
>   if (drm_sched_entity_is_ready(entity)) {
> - rq->current_entity = entity;
> - reinit_completion(>entity_idle);
> + if (!peek) {
> + rq->current_entity = entity;
> + reinit_completion(>entity_idle);
> + }
>   break;
>   }
>   }
> @@ -282,13 +290,98 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
>  }
>  
>  /**
> - * drm_sched_wqueue_enqueue - enqueue scheduler submission
> + * drm_sched_run_job_queue - enqueue run-job work

Hmm... so this removes the change from patch 1 in this series, and as such
obviates patch 1.

Do you want to go with "run_job_queue" and the names introduced here?

In this case, we can have that in patch 1 instead, and this patch
would only split the "free job" into its own work item.

> + * @sched: scheduler instance
> + */
> +static void drm_sched_run_job_queue(struct drm_gpu_scheduler *sched)
> +{
> + if (!READ_ONCE(sched->pause_submit))
> + queue_work(sched->submit_wq, >work_run_job);
> +}
> +
> +/**
> + * drm_sched_can_queue -- Can we queue more to the hardware?
> + * @sched: scheduler instance
> + *
> + * Return true if we can push more jobs to the hw, otherwise 

Re: [PATCH v5 3/7] drm/sched: Move schedule policy to scheduler

2023-10-18 Thread Luben Tuikov
One more very important thing!

Once you add an R-V tag, you cannot change the patch and keep the R-V, when 
reposting it.

If you change the code and thus the patch changes, you _*must*_ remove the R-V 
tag,
to let people know that there's changes which need reviewing.

Regards,
Luben

On 2023-10-12 01:54, Luben Tuikov wrote:
> On 2023-10-12 00:31, Matthew Brost wrote:
>> On Wed, Oct 11, 2023 at 08:39:55PM -0400, Luben Tuikov wrote:
>>> On 2023-10-11 19:58, Matthew Brost wrote:
 Rather than a global modparam for scheduling policy, move the scheduling
 policy to scheduler so user can control each scheduler policy.

 v2:
   - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
   - Only include policy in scheduler (Luben)
 v3:
   - use a ternary operator as opposed to an if-control (Luben)
   - s/DRM_SCHED_POLICY_DEFAULT/DRM_SCHED_POLICY_UNSET/ (Luben)
   - s/default_drm_sched_policy/drm_sched_policy_default/ (Luben)
   - Update commit message (Boris)
   - Fix v3d build (CI)
   - s/bad_policies/drm_sched_policy_mismatch/ (Luben)
   - Don't update modparam doc (Luben)
 v4:
   - Fix alignment in msm_ringbuffer_new (Luben / checkpatch)

 Reviewed-by: Luben Tuikov 
 Signed-off-by: Matthew Brost 
>>>
>>> Was the R-V added by hand? (As in editing the commit message manually?)
>>>
>>
>> Yes.
>>
>>> I use automated tools for this which do not re-order the tags.
>>> IOW, the S-O-B is first as this is how it appears in the patch,
>>> then the R-V most probably added by automated tools, and then
>>> any other as are tacked on by other automated tools.
>>>
>>
>> Ok, so always add tags in order starting with S-O-B?
> 
> Yes!
> 
> The S-O-B tag you add when you write the commit and then you post
> it up to a mailing list, it's mandatory and it's always there.
> It's most likely the first, top tag.
> 
> Then various other scripts and tools start adding tags in an automated way,
> and those tags are just appended below any existing tags.
> 
> Generally, always follow a natural order (meaning least amount of energy
> expenditure--if you have to edit to reorder, that is extra energy expenditure
> and nature doesn't like that). Make it like a letter you'd get from or write 
> to
> your bank, attorney, etc.
>   These are tags you add when you craft your commit:
> Cc: goes first, followed by other tags whose values
> Cc: are personal emails, i.e. people. These are people
> Cc: you want to let know of this commit. This is followed
> Cc: by other personal tags, for instance,
> Co-developed-by: or
> Suggested-by: Another personal tag is,
> Reported-by: which must be followed by a Link tag with
> Link: the link of the report. This could also be a link to anything else. You 
> can also add a
> Fixes: tag which should follow a --pretty %h (\"%s\") format.
> Closes: link to the bug the patch closes
> Signed-off-by: You
>   Then scripts and tools (or even people) would append the tag list with:
> Tested-by: someone reliable, could have more than one instance of this tag,
> Acked-by: someone
> Reviewed-by: someone
> 
> There are no empty lines between tags. They form a block paragraph as they 
> would
> if/when added by a script. (I never add _any_ tag manually.)
> 
> So, for instance, you may have:
> 
> Cc: Luben
> Signed-off-by: Matt
> 
> And when the patch is R-V-ed this becomes (least amount of energy, append at 
> the bottom),
> 
> Cc: Luben
> Signed-off-by: Matt
> Reviewed-by: Luben
> 
> Then other tags may be appended, depending on the path the patch takes to 
> land in a tree.
> 
> Check out:
> https://docs.kernel.org/process/5.Posting.html
> https://docs.kernel.org/process/submitting-patches.html
> https://docs.kernel.org/process/submit-checklist.html
> And there's more resources to check out in the Documentation/process 
> directory.



Re: [PATCH 2/2] backlight: Add Kinetic KTD2801 driver

2023-10-18 Thread kernel test robot
Hi Duje,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 8a749fd1a8720d4619c91c8b6e7528c0a355c0aa]

url:
https://github.com/intel-lab-lkp/linux/commits/Duje-Mihanovi/dt-bindings-backlight-add-Kinetic-KTD2801-binding/20231006-025106
base:   8a749fd1a8720d4619c91c8b6e7528c0a355c0aa
patch link:
https://lore.kernel.org/r/20231005-ktd2801-v1-2-43cd85b0629a%40skole.hr
patch subject: [PATCH 2/2] backlight: Add Kinetic KTD2801 driver
config: i386-allyesconfig 
(https://download.01.org/0day-ci/archive/20231019/202310190928.ngf81cxq-...@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git 
ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231019/202310190928.ngf81cxq-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202310190928.ngf81cxq-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/video/backlight/ktd2801-backlight.c:15:9: warning: 'DS' macro 
>> redefined [-Wmacro-redefined]
   #define DS  5
   ^
   arch/x86/include/uapi/asm/ptrace-abi.h:14:9: note: previous definition is 
here
   #define DS 7
   ^
   1 warning generated.


vim +/DS +15 drivers/video/backlight/ktd2801-backlight.c

 8  
 9  #define EW_DELAY150
10  #define EW_DET  270
11  #define LOW_BIT_HIGH5
12  #define LOW_BIT_LOW (4 * HIGH_BIT_LOW)
13  #define HIGH_BIT_LOW5
14  #define HIGH_BIT_HIGH   (4 * HIGH_BIT_LOW)
  > 15  #define DS  5
16  #define EOD_L   10
17  #define EOD_H   350
18  #define PWR_DOWN_DELAY  2600
19  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


Re: linux-next: build failure after merge of the amdgpu tree

2023-10-18 Thread Stephen Rothwell
Hi all,

On Tue, 10 Oct 2023 12:43:57 +1100 Stephen Rothwell  
wrote:
>
> After merging the amdgpu tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c: In 
> function 'dml_core_mode_support':
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:8229:1: 
> error: the frame size of 2736 bytes is larger than 2048 bytes 
> [-Werror=frame-larger-than=]
>  8229 | } // dml_core_mode_support
>   | ^
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   7966f319c66d ("drm/amd/display: Introduce DML2")
> 
> (or maybe something later that changed storage size).
> 
> I have used the amdgpu tree from next-20231009 for today.

This build failure now (presumably) exists in the drm tree.  I am still
applying the 2 patches from Rodrigo to my tree as a work around.

I would have expected that this was fixed in the amdgpu tree before
Dave was asked to merge it ...
-- 
Cheers,
Stephen Rothwell


pgp9lEtiR0dIs.pgp
Description: OpenPGP digital signature


[PATCH -next 2/2] drm/amd/display: clean up one inconsistent indenting

2023-10-18 Thread Yang Li
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_policy.c:206 
dml2_policy_build_synthetic_soc_states() warn: inconsistent indenting

Reported-by: Abaci Robot 
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6933
Signed-off-by: Yang Li 
---
 drivers/gpu/drm/amd/display/dc/dml2/dml2_policy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml2/dml2_policy.c 
b/drivers/gpu/drm/amd/display/dc/dml2/dml2_policy.c
index f8e9aa32ceab..0b3ab7aaea87 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/dml2_policy.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2/dml2_policy.c
@@ -203,7 +203,7 @@ int dml2_policy_build_synthetic_soc_states(struct 
dml2_policy_build_synthetic_so
s->entry.fabricclk_mhz = 
p->in_states->state_array[i].fabricclk_mhz;
s->entry.dram_speed_mts = 0;
 
-   insert_entry_into_table_sorted(p->in_bbox, p->out_states, 
>entry);
+   insert_entry_into_table_sorted(p->in_bbox, 
p->out_states, >entry);
}
}
// Add max FCLK
-- 
2.20.1.7.g153144c



[PATCH -next 1/2] drm/amd/display: clean up one inconsistent indenting

2023-10-18 Thread Yang Li
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_util.c:150 dml_max() 
warn: inconsistent indenting

Reported-by: Abaci Robot 
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6933
Signed-off-by: Yang Li 
---
 drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c 
b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c
index 7dd1f8a12582..3a70838abfba 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c
@@ -147,7 +147,7 @@ dml_float_t dml_max(dml_float_t x, dml_float_t y)
return y;
if (y != y)
return x;
-if (x > y)
+   if (x > y)
return x;
else
return y;
-- 
2.20.1.7.g153144c



Re: [PATCH RFC v6 08/10] drm/msm/dpu: Allow NULL FBs in atomic commit

2023-10-18 Thread Jessica Zhang




On 9/24/2023 3:29 AM, Dmitry Baryshkov wrote:

On 29/08/2023 03:05, Jessica Zhang wrote:

Since solid fill planes allow for a NULL framebuffer in a valid commit,
add NULL framebuffer checks to atomic commit calls within DPU.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  9 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 41 
---

  2 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c

index 8ce7586e2ddf..5e845510e8c1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -451,6 +451,7 @@ static void _dpu_crtc_blend_setup_mixer(struct 
drm_crtc *crtc,

  struct drm_plane_state *state;
  struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
  struct dpu_plane_state *pstate = NULL;
+    const struct msm_format *fmt;
  struct dpu_format *format;
  struct dpu_hw_ctl *ctl = mixer->lm_ctl;
@@ -470,7 +471,13 @@ static void _dpu_crtc_blend_setup_mixer(struct 
drm_crtc *crtc,

  pstate = to_dpu_plane_state(state);
  fb = state->fb;
-    format = to_dpu_format(msm_framebuffer_format(pstate->base.fb));
+    if (drm_plane_solid_fill_enabled(state))
+    fmt = dpu_get_msm_format(&_dpu_crtc_get_kms(crtc)->base,
+    DRM_FORMAT_ABGR, 0);
+    else
+    fmt = msm_framebuffer_format(pstate->base.fb);
+
+    format = to_dpu_format(fmt);
  if (pstate->stage == DPU_STAGE_BASE && format->alpha_enable)
  bg_alpha_enable = true;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c

index c2aaaded07ed..114c803ff99b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -837,8 +837,13 @@ static int dpu_plane_atomic_check(struct 
drm_plane *plane,

  pipe_cfg->dst_rect = new_plane_state->dst;
-    fb_rect.x2 = new_plane_state->fb->width;
-    fb_rect.y2 = new_plane_state->fb->height;
+    if (drm_plane_solid_fill_enabled(new_plane_state))
+    return 0;


This would skip all the width checks, dpu_plane_atomic_check_pipe(), 
etc. Could you please confirm that all of those checks are irrelevant 
for solid fill?


Hi Dmitry,

Good point -- I think it would be good to keep the rect and pipe checks 
for solid fill.





+
+    if (new_plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && 
new_plane_state->fb) {

+    fb_rect.x2 = new_plane_state->fb->width;
+    fb_rect.y2 = new_plane_state->fb->height;
+    }
  /* Ensure fb size is supported */
  if (drm_rect_width(_rect) > MAX_IMG_WIDTH ||
@@ -1082,21 +1087,32 @@ static void 
dpu_plane_sspp_atomic_update(struct drm_plane *plane)

  struct drm_crtc *crtc = state->crtc;
  struct drm_framebuffer *fb = state->fb;
  bool is_rt_pipe;
-    const struct dpu_format *fmt =
-    to_dpu_format(msm_framebuffer_format(fb));
+    const struct dpu_format *fmt;
  struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
  struct dpu_sw_pipe_cfg *r_pipe_cfg = >r_pipe_cfg;
  struct dpu_kms *kms = _dpu_plane_get_kms(>base);
  struct msm_gem_address_space *aspace = kms->base.aspace;
  struct dpu_hw_fmt_layout layout;
  bool layout_valid = false;
-    int ret;
-    ret = dpu_format_populate_layout(aspace, fb, );
-    if (ret)
-    DPU_ERROR_PLANE(pdpu, "failed to get format layout, %d\n", ret);
-    else
-    layout_valid = true;
+    if (state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
+    int ret;
+
+    fmt = to_dpu_format(msm_framebuffer_format(fb));
+
+    ret = dpu_format_populate_layout(aspace, fb, );
+    if (ret)
+    DPU_ERROR_PLANE(pdpu, "failed to get format layout, 
%d\n", ret);

+    else
+    layout_valid = true;
+
+    DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FP_FMT "->crtc%u " 
DRM_RECT_FMT
+    ", %4.4s ubwc %d\n", fb->base.id, 
DRM_RECT_FP_ARG(>src),

+    crtc->base.id, DRM_RECT_ARG(>dst),
+    (char *)>base.pixel_format, 
DPU_FORMAT_IS_UBWC(fmt));

+    } else {
+    fmt = dpu_get_dpu_format(DRM_FORMAT_ABGR);


#define DPU_SOLID_FILL_FORMAT ?


Acked.



Also, I don't think that solid_fill planes consume bandwidth, so this 
likely needs to be fixed too.


You're right -- I think we can actually return early here if solid fill 
is enabled.


Thanks,

Jessica Zhang





+    }
  pstate->pending = true;
@@ -1104,11 +1120,6 @@ static void dpu_plane_sspp_atomic_update(struct 
drm_plane *plane)

  pstate->needs_qos_remap |= (is_rt_pipe != pdpu->is_rt_pipe);
  pdpu->is_rt_pipe = is_rt_pipe;
-    DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FP_FMT "->crtc%u " 
DRM_RECT_FMT
-    ", %4.4s ubwc %d\n", fb->base.id, 
DRM_RECT_FP_ARG(>src),

-    crtc->base.id, 

Re: [PATCH v2] drm/modes: replace deprecated strncpy with strscpy_pad

2023-10-18 Thread Kees Cook
On Mon, Oct 16, 2023 at 10:38:20PM +, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
> 
> We should NUL-pad as there are full struct copies happening in places:
> |   struct drm_mode_modeinfo umode;
> |
> |   ...
> |   struct drm_property_blob *blob;
> |
> |   drm_mode_convert_to_umode(, mode);
> |   blob = drm_property_create_blob(crtc->dev,
> |   sizeof(umode), );
> 
> A suitable replacement is `strscpy_pad` due to the fact that it
> guarantees both NUL-termination and NUL-padding on the destination
> buffer.
> 
> Additionally, replace size macro `DRM_DISPLAY_MODE_LEN` with sizeof() to
> more directly tie the maximum buffer size to the destination buffer:
> |   struct drm_display_mode {
> |   ...
> | char name[DRM_DISPLAY_MODE_LEN];
> 
> Link: 
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
>  [1]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Cc: Xu Panda 
> Signed-off-by: Justin Stitt 

Thanks for the respin; this looks good to me.

Reviewed-by: Kees Cook 

-- 
Kees Cook


Re: [PATCH v3] drm/virtio: add new virtio gpu capset definitions

2023-10-18 Thread Dmitry Osipenko
On 10/19/23 02:25, Gurchetan Singh wrote:
> On Tue, Oct 10, 2023 at 9:41 PM Huang Rui  wrote:
> 
>> On Tue, Oct 10, 2023 at 11:52:14PM +0800, Dmitry Osipenko wrote:
>>> On 10/10/23 18:40, Dmitry Osipenko wrote:
 On 10/10/23 16:57, Huang Rui wrote:
> These definitions are used fro qemu, and qemu imports this marco in
>> the
> headers to enable gfxstream, venus, cross domain, and drm (native
> context) for virtio gpu. So it should add them even kernel doesn't use
> this.
>
> Signed-off-by: Huang Rui 
> Reviewed-by: Akihiko Odaki 
> ---
>
> Changes V1 -> V2:
> - Add all capsets including gfxstream and venus in kernel header
>> (Dmitry Osipenko)
>
> Changes V2 -> V3:
> - Add missed capsets including cross domain and drm (native context)
>   (Dmitry Osipenko)
>
> v1:
>> https://lore.kernel.org/lkml/20230915105918.3763061-1-ray.hu...@amd.com/
> v2:
>> https://lore.kernel.org/lkml/20231010032553.1138036-1-ray.hu...@amd.com/
>
>  include/uapi/linux/virtio_gpu.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/uapi/linux/virtio_gpu.h
>> b/include/uapi/linux/virtio_gpu.h
> index f556fde07b76..240911c8da31 100644
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -309,6 +309,10 @@ struct virtio_gpu_cmd_submit {
>
>  #define VIRTIO_GPU_CAPSET_VIRGL 1
>  #define VIRTIO_GPU_CAPSET_VIRGL2 2
> +#define VIRTIO_GPU_CAPSET_GFXSTREAM 3

 The GFXSTREAM capset isn't correct, it should be GFXSTREAM_VULKAN in
 accordance to [1] and [2]. There are more capsets for GFXSTREAM.

 [1]

>> https://github.com/google/crosvm/blob/main/rutabaga_gfx/src/rutabaga_utils.rs#L172

 [2]

>> https://patchwork.kernel.org/project/qemu-devel/patch/20231006010835.444-7-gurchetansi...@chromium.org/
>>>
>>> Though, maybe those are "rutabaga" capsets that not related to
>>> virtio-gpu because crosvm has another defs for virtio-gpu capsets [3].
>>> The DRM capset is oddly missing in [3] and code uses "rutabaga" capset
>>> for DRM and virtio-gpu.
>>>
>>> [3]
>>>
>> https://github.com/google/crosvm/blob/main/devices/src/virtio/gpu/protocol.rs#L416
>>
>> Yes, [3] is the file that I referred to add these capsets definitions. And
>> it's defined as gfxstream not gfxstream_vulkan.
>>
>>>
>>> Gurchetan, could you please clarify which capsets definitions are
>>> related to virtio-gpu and gfxstream. The
>>> GFXSTREAM_VULKAN/GLES/MAGMA/COMPOSER or just the single GFXSTREAM?
> 
> 
> It should be GFXSTREAM_VULKAN.  The rest are more experimental and easy to
> modify in terms of the enum value, should the need arise.
> 
> I imagine the virtio-spec update to reflect the GFXSTREAM to
> GFXSTREAM_VULKAN change will happen eventually.

Thanks for the clarification. Good point about the spec updating, we
should document DRM context too,

-- 
Best regards,
Dmitry



Re: [PATCH v3] drm/virtio: add new virtio gpu capset definitions

2023-10-18 Thread Gurchetan Singh
On Tue, Oct 10, 2023 at 9:41 PM Huang Rui  wrote:

> On Tue, Oct 10, 2023 at 11:52:14PM +0800, Dmitry Osipenko wrote:
> > On 10/10/23 18:40, Dmitry Osipenko wrote:
> > > On 10/10/23 16:57, Huang Rui wrote:
> > >> These definitions are used fro qemu, and qemu imports this marco in
> the
> > >> headers to enable gfxstream, venus, cross domain, and drm (native
> > >> context) for virtio gpu. So it should add them even kernel doesn't use
> > >> this.
> > >>
> > >> Signed-off-by: Huang Rui 
> > >> Reviewed-by: Akihiko Odaki 
> > >> ---
> > >>
> > >> Changes V1 -> V2:
> > >> - Add all capsets including gfxstream and venus in kernel header
> (Dmitry Osipenko)
> > >>
> > >> Changes V2 -> V3:
> > >> - Add missed capsets including cross domain and drm (native context)
> > >>   (Dmitry Osipenko)
> > >>
> > >> v1:
> https://lore.kernel.org/lkml/20230915105918.3763061-1-ray.hu...@amd.com/
> > >> v2:
> https://lore.kernel.org/lkml/20231010032553.1138036-1-ray.hu...@amd.com/
> > >>
> > >>  include/uapi/linux/virtio_gpu.h | 4 
> > >>  1 file changed, 4 insertions(+)
> > >>
> > >> diff --git a/include/uapi/linux/virtio_gpu.h
> b/include/uapi/linux/virtio_gpu.h
> > >> index f556fde07b76..240911c8da31 100644
> > >> --- a/include/uapi/linux/virtio_gpu.h
> > >> +++ b/include/uapi/linux/virtio_gpu.h
> > >> @@ -309,6 +309,10 @@ struct virtio_gpu_cmd_submit {
> > >>
> > >>  #define VIRTIO_GPU_CAPSET_VIRGL 1
> > >>  #define VIRTIO_GPU_CAPSET_VIRGL2 2
> > >> +#define VIRTIO_GPU_CAPSET_GFXSTREAM 3
> > >
> > > The GFXSTREAM capset isn't correct, it should be GFXSTREAM_VULKAN in
> > > accordance to [1] and [2]. There are more capsets for GFXSTREAM.
> > >
> > > [1]
> > >
> https://github.com/google/crosvm/blob/main/rutabaga_gfx/src/rutabaga_utils.rs#L172
> > >
> > > [2]
> > >
> https://patchwork.kernel.org/project/qemu-devel/patch/20231006010835.444-7-gurchetansi...@chromium.org/
> >
> > Though, maybe those are "rutabaga" capsets that not related to
> > virtio-gpu because crosvm has another defs for virtio-gpu capsets [3].
> > The DRM capset is oddly missing in [3] and code uses "rutabaga" capset
> > for DRM and virtio-gpu.
> >
> > [3]
> >
> https://github.com/google/crosvm/blob/main/devices/src/virtio/gpu/protocol.rs#L416
>
> Yes, [3] is the file that I referred to add these capsets definitions. And
> it's defined as gfxstream not gfxstream_vulkan.
>
> >
> > Gurchetan, could you please clarify which capsets definitions are
> > related to virtio-gpu and gfxstream. The
> > GFXSTREAM_VULKAN/GLES/MAGMA/COMPOSER or just the single GFXSTREAM?


It should be GFXSTREAM_VULKAN.  The rest are more experimental and easy to
modify in terms of the enum value, should the need arise.

I imagine the virtio-spec update to reflect the GFXSTREAM to
GFXSTREAM_VULKAN change will happen eventually.


> >
>
> Gurchetan, may we have your insight?
>
> Thanks,
> Ray
>
> > --
> > Best regards,
> > Dmitry
> >
>


Re: [PATCH v3 2/2] drm/uapi: add explicit virtgpu context debug name

2023-10-18 Thread Dmitry Osipenko
On 10/18/23 21:17, Gurchetan Singh wrote:
> There are two problems with the current method of determining the
> virtio-gpu debug name.
> 
> 1) TASK_COMM_LEN is defined to be 16 bytes only, and this is a
>Linux kernel idiom (see PR_SET_NAME + PR_GET_NAME). Though,
>Android/FreeBSD get around this via setprogname(..)/getprogname(..)
>in libc.
> 
>On Android, names longer than 16 bytes are common.  For example,
>one often encounters a program like "com.android.systemui".
> 
>The virtio-gpu spec allows the debug name to be up to 64 bytes, so
>ideally userspace should be able to set debug names up to 64 bytes.
> 
> 2) The current implementation determines the debug name using whatever
>task initiated virtgpu.  This is could be a "RenderThread" of a
>larger program, when we actually want to propagate the debug name
>of the program.
> 
> To fix these issues, add a new CONTEXT_INIT param that allows userspace
> to set the debug name when creating a context.
> 
> It takes a null-terminated C-string as the param value. The length of the
> string (excluding the terminator) **should** be <= 64 bytes.  Otherwise,
> the debug_name will be truncated to 64 bytes.
> 
> Link to open-source userspace:
> https://android-review.googlesource.com/c/platform/hardware/google/gfxstream/+/2787176
> 
> Signed-off-by: Gurchetan Singh 
> Reviewed-by: Josh Simonot 
> ---
> Fixes suggested by Dmitry Osipenko
> v2:
> - Squash implementation and UAPI change into one commit
> - Avoid unnecessary casts
> - Use bool when necessary
> v3:
> - Use DEBUG_NAME_MAX_LEN - 1 when copying string
> 
>  drivers/gpu/drm/virtio/virtgpu_drv.h   |  5 
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 39 ++
>  include/uapi/drm/virtgpu_drm.h |  2 ++
>  3 files changed, 40 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 96365a772f77..bb7d86a0c6a1 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -58,6 +58,9 @@
>  #define MAX_CAPSET_ID 63
>  #define MAX_RINGS 64
>  
> +/* See virtio_gpu_ctx_create. One additional character for NULL terminator. 
> */
> +#define DEBUG_NAME_MAX_LEN 65
> +
>  struct virtio_gpu_object_params {
>   unsigned long size;
>   bool dumb;
> @@ -274,6 +277,8 @@ struct virtio_gpu_fpriv {
>   uint64_t base_fence_ctx;
>   uint64_t ring_idx_mask;
>   struct mutex context_lock;
> + char debug_name[DEBUG_NAME_MAX_LEN];
> + bool explicit_debug_name;
>  };
>  
>  /* virtgpu_ioctl.c */
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 8d13b17c215b..65811e818925 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -42,12 +42,19 @@
>  static void virtio_gpu_create_context_locked(struct virtio_gpu_device *vgdev,
>struct virtio_gpu_fpriv *vfpriv)
>  {
> - char dbgname[TASK_COMM_LEN];
> + if (vfpriv->explicit_debug_name) {
> + virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> +   vfpriv->context_init,
> +   strlen(vfpriv->debug_name),
> +   vfpriv->debug_name);
> + } else {
> + char dbgname[TASK_COMM_LEN];
>  
> - get_task_comm(dbgname, current);
> - virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> -   vfpriv->context_init, strlen(dbgname),
> -   dbgname);
> + get_task_comm(dbgname, current);
> + virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> +   vfpriv->context_init, 
> strlen(dbgname),
> +   dbgname);
> + }
>  
>   vfpriv->context_created = true;
>  }
> @@ -107,6 +114,9 @@ static int virtio_gpu_getparam_ioctl(struct drm_device 
> *dev, void *data,
>   case VIRTGPU_PARAM_SUPPORTED_CAPSET_IDs:
>   value = vgdev->capset_id_mask;
>   break;
> + case VIRTGPU_PARAM_EXPLICIT_DEBUG_NAME:
> + value = vgdev->has_context_init ? 1 : 0;
> + break;
>   default:
>   return -EINVAL;
>   }
> @@ -580,7 +590,7 @@ static int virtio_gpu_context_init_ioctl(struct 
> drm_device *dev,
>   return -EINVAL;
>  
>   /* Number of unique parameters supported at this time. */
> - if (num_params > 3)
> + if (num_params > 4)
>   return -EINVAL;
>  
>   ctx_set_params = memdup_user(u64_to_user_ptr(args->ctx_set_params),
> @@ -642,6 +652,23 @@ static int virtio_gpu_context_init_ioctl(struct 
> drm_device *dev,
>  
>   vfpriv->ring_idx_mask = value;
>   break;
> + case 

Re: [PATCH] backlight: pwm_bl: Avoid backlight flicker applying initial PWM state

2023-10-18 Thread Uwe Kleine-König
Hello Philipp,

On Thu, Jun 08, 2023 at 04:11:14PM +0200, Philipp Zabel wrote:
> The initial PWM state returned by pwm_init_state() has a duty cycle
> of 0 ns.

This is only true for drivers without a .get_state() callback, isn't it?

> To avoid backlight flicker when taking over an enabled
> display from the bootloader, skip the initial pwm_apply_state()
> and leave the PWM be until backlight_update_state() will apply the
> state with the desired brightness.
> 
> Signed-off-by: Philipp Zabel 
> ---
> With a PWM driver that allows to inherit PWM state from the bootloader,
> postponing the initial pwm_apply_state() with 0 ns duty cycle allows to
> set the desired duty cycle before the PWM is set, avoiding a short flicker
> if the backlight was previously enabled and will be enabled again.
> ---
>  drivers/video/backlight/pwm_bl.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index fce412234d10..47a917038f58 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -531,12 +531,10 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
>   if (!state.period && (data->pwm_period_ns > 0))
>   state.period = data->pwm_period_ns;
>  
> - ret = pwm_apply_state(pb->pwm, );
> - if (ret) {
> - dev_err(>dev, "failed to apply initial PWM state: %d\n",
> - ret);
> - goto err_alloc;
> - }
> + /*
> +  * No need to apply initial state, except in the error path.

Why do you want to modify the PWM in the error path? I would have
expected not touching it at all in .probe() is fine?!

> +  * State will be applied by backlight_update_status() on success.
> +  */
>  
>   memset(, 0, sizeof(struct backlight_properties));
>  

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


Re: [PATCH 5/7] arm64: dts: qcom: sc7280: Fix up GPU SIDs

2023-10-18 Thread Konrad Dybcio




On 10/16/23 22:22, Akhil P Oommen wrote:

On Tue, Sep 26, 2023 at 08:24:40PM +0200, Konrad Dybcio wrote:


GPU_SMMU SID 1 is meant for Adreno LPAC (Low Priority Async Compute).
On platforms that support it (in firmware), it is necessary to
describe that link, or Adreno register access will hang the board.

Add that and fix up the SMR mask of SID 0, which seems to have been
copypasted from another SoC.

Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu support")
Signed-off-by: Konrad Dybcio 
---
  arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index c38ddf267ef5..0d96d1454c49 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2603,7 +2603,8 @@ gpu: gpu@3d0 {
"cx_mem",
"cx_dbgc";
interrupts = ;
-   iommus = <_smmu 0 0x401>;
+   iommus = <_smmu 0 0x400>,
+<_smmu 1 0x400>;

Aren't both functionally same? 401 works fine on sc7280. You might be
having issue due to Qcom TZ policies on your platform. I am okay with the 
change, but can
you please reword the commit text?

Hm, looking at what the SMR registers represent, it looks like
they should do the same thing and it may indeed be down to the
TZ being picky.. I'll rephrase.

Konrad


[PATCH] accel/ivpu: Delete the TODO file

2023-10-18 Thread Deepak R Varma
The work items listed in the TODO file of this driver file are either
completed or dropped. The file is no more significant according
to the maintainers. Hence removing it from the sources.

Suggested-by: Stanislaw Gruszka 
Signed-off-by: Deepak R Varma 
---
 drivers/accel/ivpu/TODO | 11 ---
 1 file changed, 11 deletions(-)
 delete mode 100644 drivers/accel/ivpu/TODO

diff --git a/drivers/accel/ivpu/TODO b/drivers/accel/ivpu/TODO
deleted file mode 100644
index 9077217ae10f..
--- a/drivers/accel/ivpu/TODO
+++ /dev/null
@@ -1,11 +0,0 @@
-- Move to threaded_irqs to mitigate potential infinite loop in 
ivpu_ipc_irq_handler()
-- Implement support for BLOB IDs
-- Add debugfs support to improve debugging and testing
-- Add tracing events for performance debugging
-- Implement HW based scheduling support
-- Use syncobjs for submit/sync
-- Refactor IPC protocol to improve message latency
-- Implement BO cache and MADVISE IOCTL
-- Add support for user allocated buffers using prime import and dma-buf heaps
-- Refactor struct ivpu_bo to use struct drm_gem_shmem_object
-- Add driver/device documentation
--
2.39.2





Re: [PATCH v4 13/17] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-10-18 Thread Hans de Goede
Hi,

I was not following this at first, so my apologies for
jumping in in the middle of the thread:




> +static int amd_pmf_gpu_get_cur_state(struct thermal_cooling_device 
> *cooling_dev,
> + unsigned long *state)
> +{
> +    struct backlight_device *bd;
> +
> +    if (!acpi_video_backlight_use_native())
> +    return -ENODEV;
> +
> +    bd = backlight_device_get_by_type(BACKLIGHT_RAW);
> +    if (!bd)
> +    return -ENODEV;
> +
> +    *state = backlight_get_brightness(bd);
> +
> +    return 0;
> +}
> +
> +static int amd_pmf_gpu_get_max_state(struct thermal_cooling_device 
> *cooling_dev,
> + unsigned long *state)
> +{
> +    struct backlight_device *bd;
> +
> +    if (!acpi_video_backlight_use_native())
> +    return -ENODEV;
> +
> +    bd = backlight_device_get_by_type(BACKLIGHT_RAW);
> +    if (!bd)
> +    return -ENODEV;
> +
> +    if (backlight_is_blank(bd))
> +    *state = 0;
> +    else
> +    *state = bd->props.max_brightness;
> +
> +    return 0;
> +}
> +
> +static const struct thermal_cooling_device_ops bd_cooling_ops = {
> +    .get_max_state = amd_pmf_gpu_get_max_state,
> +    .get_cur_state = amd_pmf_gpu_get_cur_state,
> +};

So first of all, good to see that this is using the
thermal_cooling_device APIs now, that is great thank you.

But the whole idea behind using the thermal_cooling_device APIs
is that amdgpu exports the cooling_device itself, rather then have
the AMD PMF code export it. Now the AMD PMF code is still poking
at the backlight_device itself, while the idea was to delegate
this to the GPU driver.

Actually seeing all the acpi_video_backlight_use_native()
checks here, I wonder why only have this work with native backlight
control. One step better would be to add thermal_cooling_device
support to the backlight core in:
drivers/video/backlight/backlight.c

Then it will work with any backlight control provider!



Last but not least this code MUST not call
acpi_video_backlight_use_native()

No code other then native GPU drivers must ever call
acpi_video_backlight_use_native(). This special function
not only checks if the native backlight control is the
one which the detection code in drivers/acpi/video_detect.c
has selected, it also signals to video_detect.c that
native GPU backlight control is available.

So by calling this in the AMD PMF code you are now
telling video_detect.c that native GPU backlight control
is available on all systems where AMD PMF runs.

As I already said I really believe the whole cooling
device should be registered somewhere else. But if you
do end up sticking with this then you MUST replace
the acpi_video_backlight_use_native() calls with:

if (acpi_video_get_backlight_type() == acpi_backlight_native) {...}

Regards,

Hans





Re: [PATCH] drm/amd/display: Respect CONFIG_FRAME_WARN=0 in DML2

2023-10-18 Thread Hamza Mahfooz

On 10/18/23 14:45, Nathan Chancellor wrote:

display_mode_code.c is unconditionally built with
-Wframe-larger-than=2048, which causes warnings even when
CONFIG_FRAME_WARN has been set to 0, which should show no warnings.

Use the existing $(frame_warn_flag) variable, which handles this
situation. This is basically commit 25f178bbd078 ("drm/amd/display:
Respect CONFIG_FRAME_WARN=0 in dml Makefile") but for DML2.

Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2")
Signed-off-by: Nathan Chancellor 


Applied, thanks!


---
  drivers/gpu/drm/amd/display/dc/dml2/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index f35ed8de260d..66431525f2a0 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -61,7 +61,7 @@ ifneq ($(CONFIG_FRAME_WARN),0)
  frame_warn_flag := -Wframe-larger-than=2048
  endif
  
-CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) -Wframe-larger-than=2048

+CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) 
$(frame_warn_flag)
  CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_util.o := $(dml2_ccflags)
  CFLAGS_$(AMDDALPATH)/dc/dml2/dml2_wrapper.o := $(dml2_ccflags)
  CFLAGS_$(AMDDALPATH)/dc/dml2/dml2_utils.o := $(dml2_ccflags)

---
base-commit: cd90511557fdfb394bb4ac4c3b539b007383914c
change-id: 20231018-amdgpu-dml2-respect-frame_warn-536e19b69ce0

Best regards,

--
Hamza



[PATCH] drm/amd/display: Respect CONFIG_FRAME_WARN=0 in DML2

2023-10-18 Thread Nathan Chancellor
display_mode_code.c is unconditionally built with
-Wframe-larger-than=2048, which causes warnings even when
CONFIG_FRAME_WARN has been set to 0, which should show no warnings.

Use the existing $(frame_warn_flag) variable, which handles this
situation. This is basically commit 25f178bbd078 ("drm/amd/display:
Respect CONFIG_FRAME_WARN=0 in dml Makefile") but for DML2.

Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2")
Signed-off-by: Nathan Chancellor 
---
 drivers/gpu/drm/amd/display/dc/dml2/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index f35ed8de260d..66431525f2a0 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -61,7 +61,7 @@ ifneq ($(CONFIG_FRAME_WARN),0)
 frame_warn_flag := -Wframe-larger-than=2048
 endif
 
-CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) 
-Wframe-larger-than=2048
+CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) 
$(frame_warn_flag)
 CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_util.o := $(dml2_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml2/dml2_wrapper.o := $(dml2_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml2/dml2_utils.o := $(dml2_ccflags)

---
base-commit: cd90511557fdfb394bb4ac4c3b539b007383914c
change-id: 20231018-amdgpu-dml2-respect-frame_warn-536e19b69ce0

Best regards,
-- 
Nathan Chancellor 



[PATCH v3 2/2] drm/uapi: add explicit virtgpu context debug name

2023-10-18 Thread Gurchetan Singh
There are two problems with the current method of determining the
virtio-gpu debug name.

1) TASK_COMM_LEN is defined to be 16 bytes only, and this is a
   Linux kernel idiom (see PR_SET_NAME + PR_GET_NAME). Though,
   Android/FreeBSD get around this via setprogname(..)/getprogname(..)
   in libc.

   On Android, names longer than 16 bytes are common.  For example,
   one often encounters a program like "com.android.systemui".

   The virtio-gpu spec allows the debug name to be up to 64 bytes, so
   ideally userspace should be able to set debug names up to 64 bytes.

2) The current implementation determines the debug name using whatever
   task initiated virtgpu.  This is could be a "RenderThread" of a
   larger program, when we actually want to propagate the debug name
   of the program.

To fix these issues, add a new CONTEXT_INIT param that allows userspace
to set the debug name when creating a context.

It takes a null-terminated C-string as the param value. The length of the
string (excluding the terminator) **should** be <= 64 bytes.  Otherwise,
the debug_name will be truncated to 64 bytes.

Link to open-source userspace:
https://android-review.googlesource.com/c/platform/hardware/google/gfxstream/+/2787176

Signed-off-by: Gurchetan Singh 
Reviewed-by: Josh Simonot 
---
Fixes suggested by Dmitry Osipenko
v2:
- Squash implementation and UAPI change into one commit
- Avoid unnecessary casts
- Use bool when necessary
v3:
- Use DEBUG_NAME_MAX_LEN - 1 when copying string

 drivers/gpu/drm/virtio/virtgpu_drv.h   |  5 
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 39 ++
 include/uapi/drm/virtgpu_drm.h |  2 ++
 3 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 96365a772f77..bb7d86a0c6a1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -58,6 +58,9 @@
 #define MAX_CAPSET_ID 63
 #define MAX_RINGS 64
 
+/* See virtio_gpu_ctx_create. One additional character for NULL terminator. */
+#define DEBUG_NAME_MAX_LEN 65
+
 struct virtio_gpu_object_params {
unsigned long size;
bool dumb;
@@ -274,6 +277,8 @@ struct virtio_gpu_fpriv {
uint64_t base_fence_ctx;
uint64_t ring_idx_mask;
struct mutex context_lock;
+   char debug_name[DEBUG_NAME_MAX_LEN];
+   bool explicit_debug_name;
 };
 
 /* virtgpu_ioctl.c */
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 8d13b17c215b..65811e818925 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -42,12 +42,19 @@
 static void virtio_gpu_create_context_locked(struct virtio_gpu_device *vgdev,
 struct virtio_gpu_fpriv *vfpriv)
 {
-   char dbgname[TASK_COMM_LEN];
+   if (vfpriv->explicit_debug_name) {
+   virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
+ vfpriv->context_init,
+ strlen(vfpriv->debug_name),
+ vfpriv->debug_name);
+   } else {
+   char dbgname[TASK_COMM_LEN];
 
-   get_task_comm(dbgname, current);
-   virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
- vfpriv->context_init, strlen(dbgname),
- dbgname);
+   get_task_comm(dbgname, current);
+   virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
+ vfpriv->context_init, 
strlen(dbgname),
+ dbgname);
+   }
 
vfpriv->context_created = true;
 }
@@ -107,6 +114,9 @@ static int virtio_gpu_getparam_ioctl(struct drm_device 
*dev, void *data,
case VIRTGPU_PARAM_SUPPORTED_CAPSET_IDs:
value = vgdev->capset_id_mask;
break;
+   case VIRTGPU_PARAM_EXPLICIT_DEBUG_NAME:
+   value = vgdev->has_context_init ? 1 : 0;
+   break;
default:
return -EINVAL;
}
@@ -580,7 +590,7 @@ static int virtio_gpu_context_init_ioctl(struct drm_device 
*dev,
return -EINVAL;
 
/* Number of unique parameters supported at this time. */
-   if (num_params > 3)
+   if (num_params > 4)
return -EINVAL;
 
ctx_set_params = memdup_user(u64_to_user_ptr(args->ctx_set_params),
@@ -642,6 +652,23 @@ static int virtio_gpu_context_init_ioctl(struct drm_device 
*dev,
 
vfpriv->ring_idx_mask = value;
break;
+   case VIRTGPU_CONTEXT_PARAM_DEBUG_NAME:
+   if (vfpriv->explicit_debug_name) {
+   ret = -EINVAL;
+   goto out_unlock;
+   

[PATCH v3 1/2] drm/virtio: use uint64_t more in virtio_gpu_context_init_ioctl

2023-10-18 Thread Gurchetan Singh
drm_virtgpu_context_set_param defines both param and
value to be u64s.

Signed-off-by: Gurchetan Singh 
Reviewed-by: Josh Simonot 
Reviewed-by: Dmitry Osipenko 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index b24b11f25197..8d13b17c215b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -565,8 +565,8 @@ static int virtio_gpu_context_init_ioctl(struct drm_device 
*dev,
 void *data, struct drm_file *file)
 {
int ret = 0;
-   uint32_t num_params, i, param, value;
-   uint64_t valid_ring_mask;
+   uint32_t num_params, i;
+   uint64_t valid_ring_mask, param, value;
size_t len;
struct drm_virtgpu_context_set_param *ctx_set_params = NULL;
struct virtio_gpu_device *vgdev = dev->dev_private;
-- 
2.42.0.655.g421f12c284-goog



Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3

2023-10-18 Thread Andi Shyti
Hi Vinay,

On Tue, Oct 17, 2023 at 12:53:09PM -0700, Vinay Belgaumkar wrote:
> This bit does not cause an explicit L3 flush. We already use
> PIPE_CONTROL_DC_FLUSH_ENABLE for that purpose.
> 
> v2: Use FLUSH_L3 only pre-MTL since spec will likely remain
> the same going forward.
> 
> Cc: Nirmoy Das 
> Cc: Mika Kuoppala 
> Acked-by: Mika Kuoppala 
> Reviewed-by: Nirmoy Das 
> Signed-off-by: Vinay Belgaumkar 

pushed to drm-intel-gt-next.

Thanks,
Andi


Re: ivpu TODO list items

2023-10-18 Thread Deepak R Varma
On Wed, Oct 18, 2023 at 09:50:53AM +0200, Stanislaw Gruszka wrote:
> Hi
>
> On Tue, Oct 17, 2023 at 10:25:19PM +0530, Deepak R Varma wrote:
> > On Fri, Oct 13, 2023 at 12:54:43PM +0530, Deepak R Varma wrote:
> > > Hello,
> > > I am shortlisted as a mentee for the LF Mentorship program. I looked at 
> > > the TODO
> > > file for the ivpu driver for my project tasks. Could you please answer the
> > > following questions:
> > >
> > > 1. Is the TODO list up to date? If not, can we have it updated? Let me 
> > > know if I
> > > can help.
> It's not. Some of those was already implemented (but yet not submitted).
> Some ideas there was dropped.
>
> I think this file can be whole removed. Feel free to post patch for
> that.

Hello,
Thank you for the response. I sincerely appreciate your time.
I will send in a patch to remove the TODO file.

>
> > > 2. Is it absolutely necessary for me to have a specialized hardware to 
> > > test my
> > > patches? Is it limited to the 14thGen or above CPU or do I need more than 
> > > that?
> Yes, I don't think someone can work on ivpu without hardware.

Okay. Could you suggest what would be the minimum hardware required to explore
this driver?

>
> > > 3. Is it okay for me to work on the TODO list items. Let me know if you 
> > > have a
> > > preference [Please note I just started a few months ago and still 
> > > learning].
> I recommend you to work on items from:
> https://www.kernel.org/doc/html/latest/gpu/todo.html

This is helpful. I will review the list tiems.
Thank you again.

Deepak.

>
> > Hello,
> > May I request the maintainer to review my questions and comment please?
>
> Sorry, I haven't seen this email before.
>
> Regards
> Stanislaw




Re: [PATCH v2 2/2] drm/uapi: add explicit virtgpu context debug name

2023-10-18 Thread Dmitry Osipenko
On 10/18/23 20:04, Gurchetan Singh wrote:
> +
> + ret = strncpy_from_user(vfpriv->debug_name,
> + u64_to_user_ptr(value),
> + DEBUG_NAME_MAX_LEN);
> +
> + if (ret < 0) {
> + ret = -EFAULT;
> + goto out_unlock;
> + }
> +
> + /*
> +  * strncpy_from_user doesn't copy the NULL terminator 
> when
> +  * DEBUG_NAME_MAX_LEN bytes is copied. Fix that here.
> +  */
> + if (ret == DEBUG_NAME_MAX_LEN)
> + vfpriv->debug_name[DEBUG_NAME_MAX_LEN - 1] = 
> '\0';

If you'll copy DEBUG_NAME_MAX_LEN-1 bytes, then string will be always
NULL-terminated. It is a standard practice for strncpy usage to do it
like this:

ret = strncpy_from_user(vfpriv->debug_name,
u64_to_user_ptr(value),
DEBUG_NAME_MAX_LEN - 1);
-- 
Best regards,
Dmitry



[PATCH v7c 23/24] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers

2023-10-18 Thread Jim Cromie
Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files.  For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.

Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its class'd prdbgs stuck in the initial
(disabled, but for DEBUG) state.

The stuck sites are evident in /proc/dynamic_debug/control as:

   class:_UNKNOWN_ _id:N# control's last column

rather than a proper "enumeration":

   class:DRM_UT_CORE

This set of updates was found by choosing M for all DRM-config items I
found (not allmodconfig), building & modprobing them, and grepping
"class unknown," control.  There may yet be others.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++
 drivers/gpu/drm/gud/gud_drv.c  | 2 ++
 drivers/gpu/drm/mgag200/mgag200_drv.c  | 2 ++
 drivers/gpu/drm/qxl/qxl_drv.c  | 2 ++
 drivers/gpu/drm/radeon/radeon_drv.c| 2 ++
 drivers/gpu/drm/udl/udl_main.c | 2 ++
 drivers/gpu/drm/vkms/vkms_drv.c| 2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 ++
 8 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index e435f986cd13..066d906e3199 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 MODULE_IMPORT_NS(DMA_BUF);
 
 /**
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index 9d7bf8ee45f1..5b555045fce4 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -31,6 +31,8 @@
 
 #include "gud_internal.h"
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 /* Only used internally */
 static const struct drm_format_info gud_drm_format_r1 = {
.format = GUD_DRM_FORMAT_R1,
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index abddf37f0ea1..d678eb8e028d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -24,6 +24,8 @@ static int mgag200_modeset = -1;
 MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
 module_param_named(modeset, mgag200_modeset, int, 0400);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 int mgag200_init_pci_options(struct pci_dev *pdev, u32 option, u32 option2)
 {
struct device *dev = >dev;
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index b30ede1cf62d..91942ffcc2b4 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -65,6 +65,8 @@ module_param_named(modeset, qxl_modeset, int, 0400);
 MODULE_PARM_DESC(num_heads, "Number of virtual crtcs to expose (default 4)");
 module_param_named(num_heads, qxl_num_crtc, int, 0400);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static struct drm_driver qxl_driver;
 static struct pci_driver qxl_pci_driver;
 
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index fa531493b111..ab29945af657 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -247,6 +247,8 @@ int radeon_cik_support = 1;
 MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled (default), 0 = 
disabled)");
 module_param_named(cik_support, radeon_cik_support, int, 0444);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
 };
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 3ebe2ce55dfd..ba57c14454e5 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -19,6 +19,8 @@
 
 #define NR_USB_REQUEST_CHANNEL 0x12
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
 #define WRITES_IN_FLIGHT (20)
 #define MAX_VENDOR_DESCRIPTOR_SIZE 256
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index dd0af086e7fa..086797c4b82b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -39,6 +39,8 @@
 
 static struct vkms_config *default_config;
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static bool enable_cursor = true;
 module_param_named(enable_cursor, enable_cursor, bool, 0444);
 MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 8b24ecf60e3e..9cb6be422621 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -275,6 +275,8 @@ static int vmw_probe(struct pci_dev *, const struct 
pci_device_id *);
 static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
  void *ptr);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
 module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
 

[PATCH v7c 24/24] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

2023-10-18 Thread Jim Cromie
Lots of burn-in testing needed before signing, upstreaming.

NOTE: I set default Y to maximize testing by default.
Is there a better way to do this ?

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3caa020391c7..708f5e8cb205 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -55,8 +55,7 @@ config DRM_DEBUG_MM
 
 config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
-   default n
-   depends on BROKEN
+   default y
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
-- 
2.41.0



[PATCH v7c 20/24] dyndbg: refactor *dynamic_emit_prefix

2023-10-18 Thread Jim Cromie
Refactor the split of duties between outer & inner fns.

The outer fn was previously just an inline unlikely forward to inner,
which did all the work.

Now, outer handles +t and +l flags itself, and calls inner only when
_DPRINTK_FLAGS_INCL_LOOKUP is needed.

No functional change.

But it does make the results of the inner-fn more cache-friendly
(fewer entries, reused more often):

1- no spurious [TID] or  noise
2- no LINE-number to bloat the cache (avg 9 pr_debugs/fn)
3- only LOOKUP stuff

Currently LOOKUPs are descriptor-field refs but could be replaced by
accessor functions.  This would allow the __dyndbg_sites section to be
de-duplicated and reclaimed; currently module, filename fields are
~90% repeated.  As the accessors get more expensive, the value of
caching part of the prefix goes up.

Also change inner-fn to return count of extra chars written to the
buffer, and drop "inline" from outer, let the compiler decide.  Maybe
also change name accordingly.

Signed-off-by: Jim Cromie 
---
fixup whitespace
---
 lib/dynamic_debug.c | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a6ee142668bf..9db797a0cf82 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -774,11 +774,28 @@ static int remaining(int wrote)
return 0;
 }
 
-static char *__dynamic_emit_prefix(const struct _ddebug *desc, char *buf)
+static int __dynamic_emit_prefix(const struct _ddebug *desc, char *buf, int 
pos)
+{
+   if (desc->flags & _DPRINTK_FLAGS_INCL_MODNAME)
+   pos += snprintf(buf + pos, remaining(pos), "%s:",
+   desc->modname);
+   if (desc->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
+   pos += snprintf(buf + pos, remaining(pos), "%s:",
+   desc->function);
+   if (desc->flags & _DPRINTK_FLAGS_INCL_SOURCENAME)
+   pos += snprintf(buf + pos, remaining(pos), "%s:",
+   trim_prefix(desc->filename));
+   return pos;
+}
+
+static char *dynamic_emit_prefix(struct _ddebug *desc, char *buf)
 {
int pos_after_tid;
int pos = 0;
 
+   if (likely(!(desc->flags & _DPRINTK_FLAGS_INCL_ANY)))
+   return buf;
+
if (desc->flags & _DPRINTK_FLAGS_INCL_TID) {
if (in_interrupt())
pos += snprintf(buf + pos, remaining(pos), " ");
@@ -787,15 +804,10 @@ static char *__dynamic_emit_prefix(const struct _ddebug 
*desc, char *buf)
task_pid_vnr(current));
}
pos_after_tid = pos;
-   if (desc->flags & _DPRINTK_FLAGS_INCL_MODNAME)
-   pos += snprintf(buf + pos, remaining(pos), "%s:",
-   desc->modname);
-   if (desc->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
-   pos += snprintf(buf + pos, remaining(pos), "%s:",
-   desc->function);
-   if (desc->flags & _DPRINTK_FLAGS_INCL_SOURCENAME)
-   pos += snprintf(buf + pos, remaining(pos), "%s:",
-   trim_prefix(desc->filename));
+
+   if (unlikely(desc->flags & _DPRINTK_FLAGS_INCL_LOOKUP))
+   pos += __dynamic_emit_prefix(desc, buf, pos);
+
if (desc->flags & _DPRINTK_FLAGS_INCL_LINENO)
pos += snprintf(buf + pos, remaining(pos), "%d:",
desc->lineno);
@@ -807,13 +819,6 @@ static char *__dynamic_emit_prefix(const struct _ddebug 
*desc, char *buf)
return buf;
 }
 
-static inline char *dynamic_emit_prefix(struct _ddebug *desc, char *buf)
-{
-   if (unlikely(desc->flags & _DPRINTK_FLAGS_INCL_ANY))
-   return __dynamic_emit_prefix(desc, buf);
-   return buf;
-}
-
 void __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
 {
va_list args;
-- 
2.41.0



[PATCH v7c 18/24] dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED

2023-10-18 Thread Jim Cromie
Reserve bit 7 to remember that a pr-debug callsite is/was:
- enabled, with +p
- wants a dynamic-prefix, with one+ of module:function:sourcfile
- was previously called
- was thus saved in the cache. NOT YET.

Its unclear whether any cache fetch would be faster than 2-3 field
fetches, but theres another factor; the 3 columns in the __dyndbg
section are highly redundant and compressible, but to get the
compression, we need field accessors, which will rebalance the
tradeoff.

So, for now, its just the bit reservation.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index f182f95caabb..927cb14f24e0 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -38,6 +38,7 @@ struct _ddebug {
 #define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
 #define _DPRINTK_FLAGS_INCL_TID(1<<4)
 #define _DPRINTK_FLAGS_INCL_SOURCENAME (1<<5)
+#define _DPRINTK_FLAGS_PREFIX_CACHED   (1<<7)
 
 #define _DPRINTK_FLAGS_INCL_ANY\
(_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
-- 
2.41.0



[PATCH v7c 22/24] drm: use correct ccflags-y spelling

2023-10-18 Thread Jim Cromie
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:

CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DYNAMIC_DEBUG=n

Also add subdir-ccflags so that all drivers pick up the addition.

Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory 
macro")
Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 215e78e79125..22b1984cc982 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -3,7 +3,8 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
+ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG)+= 
-DDYNAMIC_DEBUG_MODULE
+subdir-ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
 
 drm-y := \
drm_aperture.o \
-- 
2.41.0



[PATCH v7c 21/24] dyndbg: change WARN_ON to WARN_ON_ONCE

2023-10-18 Thread Jim Cromie
This shouldn't ever happen, and 1st 2 conditions never have.

The 3rd condition did happen, due to corrupt linkage due to a missing
align(8) in DYNDBG_CLASSMAP_USE, on the static struct allocation into
the __dyndbg_class_users section.

Not sure whether changing to _ONCE is appropriate - this is a
module-load activity, so it won't continuously spam syslog.

Signed-off-by: Jim Cromie 
---
undo BUG_ON addition
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 9db797a0cf82..213110ec1e9c 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1281,7 +1281,7 @@ static void ddebug_attach_user_module_classes(struct 
ddebug_table *dt,
 */
for (i = 0, cli = di->class_users; i < di->num_class_users; i++, cli++) 
{
 
-   if (WARN_ON(!cli || !cli->map || !cli->user_mod_name))
+   if (WARN_ON_ONCE(!cli || !cli->map || !cli->user_mod_name))
continue;
 
if (!strcmp(cli->user_mod_name, dt->mod_name)) {
-- 
2.41.0



[PATCH v7c 13/24] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code

2023-10-18 Thread Jim Cromie
Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:

  echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names

The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things for now.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  19 ++-
 lib/dynamic_debug.c   | 103 +++---
 lib/test_dynamic_debug.c  |  26 -
 3 files changed, 12 insertions(+), 136 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 8116d0a0d33a..8eaf8eabdc8d 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -61,24 +61,13 @@ struct _ddebug {
 enum class_map_type {
DD_CLASS_TYPE_DISJOINT_BITS,
/**
-* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, one per bit.
-* expecting hex input. Built for drm.debug, basis for other types.
+* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, mapped to 
bits[0..N].
+* Expects hex input. Built for drm.debug, basis for other types.
 */
DD_CLASS_TYPE_LEVEL_NUM,
/**
-* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0-N.
-* N turns on just bits N-1 .. 0, so N=0 turns all bits off.
-*/
-   DD_CLASS_TYPE_DISJOINT_NAMES,
-   /**
-* DD_CLASS_TYPE_DISJOINT_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* classes are independent, like _DISJOINT_BITS.
-*/
-   DD_CLASS_TYPE_LEVEL_NAMES,
-   /**
-* DD_CLASS_TYPE_LEVEL_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* intended for names like: INFO,DEBUG,TRACE, with a module prefix
-* avoid EMERG,ALERT,CRIT,ERR,WARNING: they're not debug
+* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0..N.
+* Input N turns on bits 0..N-1
 */
 };
 
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 45870a699507..91c8b67fd8f8 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -632,77 +632,6 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
 
 #define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
 
-/* accept comma-separated-list of [+-] classnames */
-static int param_set_dyndbg_classnames(const char *instr, const struct 
kernel_param *kp)
-{
-   const struct ddebug_class_param *dcp = kp->arg;
-   const struct ddebug_class_map *map = dcp->map;
-   unsigned long curr_bits, old_bits;
-   char *cl_str, *p, *tmp;
-   int cls_id, totct = 0;
-   bool wanted;
-
-   cl_str = tmp = kstrdup(instr, GFP_KERNEL);
-   p = strchr(cl_str, '\n');
-   if (p)
-   *p = '\0';
-
-   /* start with previously set state-bits, then modify */
-   curr_bits = old_bits = *dcp->bits;
-   vpr_info("\"%s\" > %s:0x%lx\n", cl_str, KP_NAME(kp), curr_bits);
-
-   for (; cl_str; cl_str = p) {
-   p = strchr(cl_str, ',');
-   if (p)
-   *p++ = '\0';
-
-   if (*cl_str == '-') {
-   wanted = false;
-   cl_str++;
-   } else {
-   wanted = true;
-   if (*cl_str == '+')
-   cl_str++;
-   }
-   cls_id = match_string(map->class_names, map->length, cl_str);
-   if (cls_id < 0) {
-   pr_err("%s unknown to %s\n", cl_str, KP_NAME(kp));
-   continue;
-   }
-
-   /* have one or more valid class_ids of one *_NAMES type */
-   switch (map->map_type) {
-   case DD_CLASS_TYPE_DISJOINT_NAMES:
-   /* the +/- pertains to a single bit */
-   if (test_bit(cls_id, _bits) == wanted) {
-   v3pr_info("no change on %s\n", cl_str);
-   continue;
-   }
-   curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
*dcp->bits, NULL);
-   *dcp->bits = curr_bits;
-   v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
- map->class_names[cls_id]);
-   break;
-   case DD_CLASS_TYPE_LEVEL_NAMES:
-   /* cls_id = N in 0..max. wanted +/- determines N or N-1 
*/
-   old_bits = CLASSMAP_BITMASK(*dcp->lvl);
-   curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
-
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
old_bits, NULL);
-   *dcp->lvl = (cls_id + (wanted ? 1 : 0));
-   v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
- 

[PATCH v7c 19/24] dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP

2023-10-18 Thread Jim Cromie
dyndbg's dynamic prefixing (by +tmfsl flags) is needlessly expensive.

When an enabled (with +p) pr_debug is called, _DPRINTK_FLAGS_INCL_ANY
prefix decorations are sprintf'd into stack-mem for every call.

This string (or part of it) could be cached once its 1st generated,
and retrieved thereafter, as long as its deleted any time the
callsite's flags are changed afterwards.

So consider the prefix/decoration flags: 'tmfsl', and what should be
in the cache:

-t  thread-id. not part of the "callsite" info, derived from current.
doesn't belong in the cache. it would be wrong.
can be done in outer: dynamic_emit_prefix()

-l  line number
this could be part of the prefix, but would bloat the cache
can also be done in outer: dynamic_emit_prefix()

-mfs  module, function, source-file
we cache these, composed into a sub-string.
they are "lookups", currently to descriptor fields,
could be accessor macros to "compressed" tables.
cache saves more access work.

All enabled together, they compose a prefix string like:

  # outer   -inner--   outer
  "[tid] module:function:sourcfile:line: "

So this patch extracts _DPRINTK_FLAGS_INCL_LOOKUP macro out of
_DPRINTK_FLAGS_INCL_ANY macro, then redefs latter.

Next re-refactor dynamic_emit_prefix inner/outer fns accordingly.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 927cb14f24e0..2237d454bc19 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -40,10 +40,12 @@ struct _ddebug {
 #define _DPRINTK_FLAGS_INCL_SOURCENAME (1<<5)
 #define _DPRINTK_FLAGS_PREFIX_CACHED   (1<<7)
 
-#define _DPRINTK_FLAGS_INCL_ANY\
-   (_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
-_DPRINTK_FLAGS_INCL_LINENO  | _DPRINTK_FLAGS_INCL_TID |\
+#define _DPRINTK_FLAGS_INCL_LOOKUP \
+   (_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |   \
 _DPRINTK_FLAGS_INCL_SOURCENAME)
+#define _DPRINTK_FLAGS_INCL_ANY
\
+   (_DPRINTK_FLAGS_INCL_LINENO | _DPRINTK_FLAGS_INCL_TID | \
+_DPRINTK_FLAGS_INCL_LOOKUP)
 
 #if defined DEBUG
 #define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
-- 
2.41.0



[PATCH v7c 17/24] dyndbg-doc: add classmap info to howto

2023-10-18 Thread Jim Cromie
Add some basic info on classmap usage and api

cc: linux-...@vger.kernel.org
Signed-off-by: Jim Cromie 
---
v5- adjustments per Randy Dunlap, me
v7b- checkpatch fixes
---
 .../admin-guide/dynamic-debug-howto.rst   | 60 ++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst 
b/Documentation/admin-guide/dynamic-debug-howto.rst
index 0b3d39c610d9..028c2cb5b4c5 100644
--- a/Documentation/admin-guide/dynamic-debug-howto.rst
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -225,7 +225,6 @@ the ``p`` flag has meaning, other flags are ignored.
 Note the regexp ``^[-+=][fslmpt_]+$`` matches a flags specification.
 To clear all flags at once, use ``=_`` or ``-fslmpt``.
 
-
 Debug messages during Boot Process
 ==
 
@@ -375,3 +374,62 @@ just a shortcut for ``print_hex_dump(KERN_DEBUG)``.
 For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is
 its ``prefix_str`` argument, if it is constant string; or ``hexdump``
 in case ``prefix_str`` is built dynamically.
+
+Dynamic Debug classmaps
+===
+
+Dyndbg allows selection/grouping of *prdbg* callsites using structural
+info: module, file, function, line.  Classmaps allow authors to add
+their own domain-oriented groupings using class-names.  Classmaps are
+exported, so they referencable from other modules.
+
+  # enable classes individually
+  :#> ddcmd class DRM_UT_CORE +p
+  :#> ddcmd class DRM_UT_KMS +p
+  # or more selectively
+  :#> ddcmd class DRM_UT_CORE module drm +p
+
+The "class FOO" syntax protects class'd prdbgs from generic overwrite::
+
+  # IOW this doesn't wipe any DRM.debug settings
+  :#> ddcmd -p
+
+To support the DRM.debug parameter, DYNDBG_CLASSMAP_PARAM* updates all
+classes in a classmap, mapping param-bits 0..N onto the classes:
+DRM_UT_<*> for the DRM use-case.
+
+Dynamic Debug Classmap API
+==
+
+DYNDBG_CLASSMAP_DEFINE - modules use this to create classmaps, naming
+each of the classes (stringified enum-symbols: "DRM_UT_<*>"), and
+type, and mapping the class-names to consecutive _class_ids.
+
+By doing so, modules tell dyndbg that they are have prdbgs with those
+class_ids, and they authorize dyndbg to accept "class FOO" for the
+module defining that classname.
+
+There are 2 types of classmaps:
+
+ DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, like DRM.debug
+ DD_CLASS_TYPE_LEVEL_NUM: classes are relative, ordered (V3 > V2)
+
+DYNDBG_CLASSMAP_PARAM - refers to a DEFINEd classmap, exposing the set
+of defined classes to manipulation as a group.  This interface
+enforces the relatedness of classes of DD_CLASS_TYPE_LEVEL_NUM typed
+classmaps; all classes are independent in the >control parser itself.
+
+DYNDBG_CLASSMAP_USE - drm drivers invoke this to ref the CLASSMAP that
+drm DEFINEs.  This shares the classmap definition, and authorizes
+dyndbg to apply changes to the user module's class'd pr_debugs.  It
+also tells dyndbg how to initialize the user's prdbgs at modprobe,
+based upon the current setting of the parent's controlling param.
+
+Modules or module-groups (drm & drivers) can define multiple
+classmaps, as long as they share the limited 0..62 per-module-group
+_class_id range, without overlap.
+
+``#define DEBUG`` will enable all pr_debugs in scope, including any
+class'd ones.  This won't be reflected in the PARAM readback value,
+but the pr_debug callsites can be toggled into agreement with the
+param.
-- 
2.41.0



[PATCH v7c 09/24] dyndbg: silence debugs with no-change updates

2023-10-18 Thread Jim Cromie
check for actual changes before announcing them, declutter logs.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b0e11f6bfaa2..b07aab422604 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -591,7 +591,7 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
return nfound;
 }
 
-/* apply a new bitmap to the sys-knob's current bit-state */
+/* apply a new class-param setting */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
 unsigned long *new_bits, unsigned long 
*old_bits,
 const char *query_modname)
@@ -602,8 +602,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
- query_modname ?: "");
+   if (*new_bits != *old_bits)
+   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
 
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -618,8 +619,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
-   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
- query_modname ?: "");
+   if (*new_bits != *old_bits)
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
 
return matches;
 }
-- 
2.41.0



[PATCH v7c 16/24] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API

2023-10-18 Thread Jim Cromie
move the DYNDBG_CLASSMAP_PARAM macro from test-dynamic-debug.c into
the header, and refine it, by distinguishing the 2 use cases:

1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before

2.DYNDBG_CLASSMAP_PARAM
new user (test_dynamic_debug) doesn't need to share state,
decls a static long unsigned int to store the bitvec.

__DYNDBG_CLASSMAP_PARAM
   bottom layer - allocate,init a ddebug-class-param, module-param-cb.

Also clean up and improve comments in test-code, and add
MODULE_DESCRIPTIONs.

Signed-off-by: Jim Cromie 
---
---
 drivers/gpu/drm/drm_print.c |  8 ++
 include/drm/drm_print.h |  6 ++--
 include/linux/dynamic_debug.h   | 37 +++-
 lib/test_dynamic_debug.c| 50 +
 lib/test_dynamic_debug_submod.c |  9 +-
 5 files changed, 69 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index dabcfa0dd279..8f4b609353a5 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -69,12 +69,8 @@ DRM_CLASSMAP_DEFINE(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS,
"DRM_UT_DP",
"DRM_UT_DRMRES");
 
-static struct ddebug_class_param drm_debug_bitmap = {
-   .bits = &__drm_debug,
-   .flags = "p",
-   .map = _debug_classes,
-};
-module_param_cb(debug, _ops_dyndbg_classes, _debug_bitmap, 0600);
+DRM_CLASSMAP_PARAM_REF(debug, __drm_debug, drm_debug_classes, p);
+
 #endif
 
 void __drm_puts_coredump(struct drm_printer *p, const char *str)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 706afc97c79c..94d4f5500030 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -322,11 +322,13 @@ enum drm_debug_category {
 };
 
 #ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
-#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
-#define DRM_CLASSMAP_USE(name)   DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_DEFINE(...)   DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
+#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)DYNDBG_CLASSMAP_PARAM_REF(__VA_ARGS__)
 #else
 #define DRM_CLASSMAP_DEFINE(...)
 #define DRM_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)
 #endif
 
 static inline bool drm_debug_enabled_raw(enum drm_debug_category category)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 1b027be2cdc4..f182f95caabb 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -91,7 +91,7 @@ struct ddebug_class_map {
  * used to validate a "class FOO .." >control command on the module
  */
 #define DYNDBG_CLASSMAP_DEFINE(_var, _maptype, _base, ...) \
-   const char *_var##_classnames[] = { __VA_ARGS__ };  \
+   static const char *_var##_classnames[] = { __VA_ARGS__ };   \
struct ddebug_class_map __aligned(8) __used \
__section("__dyndbg_classes") _var = {  \
.mod = THIS_MODULE, \
@@ -145,6 +145,41 @@ struct ddebug_class_param {
const struct ddebug_class_map *map;
 };
 
+/**
+ * DYNDBG_CLASSMAP_PARAM - wrap a dyndbg-classmap with a controlling sys-param
+ * @_name  sysfs node name
+ * @_var   name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classes defined by the
+ * classmap.  Keeps bits in a private/static
+ */
+#define DYNDBG_CLASSMAP_PARAM(_name, _var, _flags) \
+   static unsigned long _name##_bvec;  \
+   __DYNDBG_CLASSMAP_PARAM(_name, _name##_bvec, _var, _flags)
+
+/**
+ * DYNDBG_CLASSMAP_PARAM_REF - wrap a dyndbg-classmap with a controlling 
sys-param
+ * @_name  sysfs node name
+ * @_bits  name of the module's unsigned long bit-vector, ex: __drm_debug
+ * @_var   name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classmap, keeping bitvec in user 
@_bits.
+ * This lets drm use __drm_debug elsewhere too.
+ */
+#define DYNDBG_CLASSMAP_PARAM_REF(_name, _bits, _var, _flags)  \
+   __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)
+
+#define __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)\
+   static struct ddebug_class_param _name##_##_flags = {   \
+   .bits = &(_bits),   \
+   .flags = #_flags,   \
+   .map = &(_var), \
+   };  \
+   module_param_cb(_name, _ops_dyndbg_classes,   \
+

[PATCH v7c 14/24] dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression

2023-10-18 Thread Jim Cromie
DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K
rule: "define once, refer many times".

When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond together when DRM.debug
categories are enabled.

Worse, it causes the CONFIG_DRM_USE_DYNAMIC_DEBUG=Y regression; 1st
drm.ko loads, and dyndbg initializes its DRM.debug callsites, then a
drm-driver loads, but too late - it missed the DRM.debug enablement.

So replace it with 2 macros:
  DYNDBG_CLASSMAP_DEFINE - invoked once from core - drm.ko
  DYNDBG_CLASSMAP_USE- from all drm drivers and helpers.

DYNDBG_CLASSMAP_DEFINE: based on DECLARE_DYNDBG_CLASSMAP, but now it
drops the static on the constructed classmap variable, and exports it
instead.

DYNDBG_CLASSMAP_USE: then refers to the exported var by name:
* used from drivers, helper-mods
* lets us drop the repetitive "classname" args
* fixes 2nd-defn problem
* creates a ddebug_class_user record in new __dyndbg_class_users section
  this allows ddebug_add_module(etal) to handle them per-module.

The distinction, and the usage record, allows dyndbg to initialize the
driver's DRM.debug callsites separately after it is modprobed.

Since DRM now needs updates to use the new macros, it also gets 2
wrappers: DRM_CLASSMAP_DEFINE, DRM_CLASSMAP_USE which declutter the
users by hiding the ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG.

To review, dyndbg's existing __dyndbg_classes[] section does:

. catalogs the classmaps defined by the module (or builtin modules)
. authorizes dyndbg to >control those class'd prdbgs for the module.
. DYNDBG_CLASSMAP_DEFINE(and old one) creates classmaps in this section.

This patch adds __dyndbg_class_users[] section:

. catalogs uses/references to the classmap definitions.
. authorizes dyndbg to >control those class'd prdbgs in ref'g module.
. DYNDBG_CLASSMAP_USE() creates classmap-user records in this section.

Now ddebug_add_module(etal) can handle classmap-uses like (and after)
classmaps; when a dependent module is loaded, its parent's kernel
params are scanned to find the param wired to dyndbg-param-ops, whose
classmap matches the one ref'd by the client.

To support this, theres a few data/header changes:

. new struct ddebug_class_user
  contains: user-module-name, 
  it records drm-driver's use of a classmap in the section, allowing lookup

struct ddebug_info gets 2 new fields to encapsulate the new section:
  class_users, num_class_users.
  set by dynamic_debug_init() for builtins.
  or by kernel/module/main:load_info() for loadable modules.

vmlinux.lds.h: new BOUNDED_SECTION for __dyndbg_class_users

dynamic_debug.c has 2 changes in ddebug_add_module(), ddebug_change():

ddebug_add_module() already calls ddebug_attach_module_classes()
to handle classmaps DEFINEd by a module, now it also calls
ddebug_attach_user_module_classes() to handle USEd classmaps.  To
avoid this work when possible, 1st scan the module's descriptors and
count the number of class'd pr_debugs.

ddebug_attach_user_module_classes() scans the module's class_users
section, follows the refs to the parent's classmap, and calls
ddebug_apply_params() on each.  It also avoids work by checking the
module's class-ct.

ddebug_apply_params(new fn):

It scans module's/builtin kernel-params, calls ddebug_match_apply_kparam
for each to find the params/sysfs-nodes which may be wired to a classmap.

ddebug_match_apply_kparam(new fn):

1st, it tests the kernel-param.ops is dyndbg's; this guarantees that
the attached arg is a struct ddebug_class_param, which has a ref to
the param's state, and to the classmap defining the param's handling.

2nd, it requires that the classmap ref'd by the kparam is the one
we're called for; modules can use many separate classmaps (as
test_dynamic_debug does).

Then apply the "parent" kparam's setting to the dependent module,
using ddebug_apply_class_bitmap().

ddebug_change(and callees) also gets adjustments:

ddebug_find_valid_class(): This does a search over the module's
classmaps, looking for the class FOO echo'd to >control.  So now it
searches over __dyndbg_class_users[] after __dyndbg_classes[].

ddebug_class_name(): return class-names for defined AND used classes.

test_dynamic_debug.c, test_dynamic_debug_submod.c:

This (already) demonstrates the 2 types of classmaps & sysfs-params,
following the 4-part recipe:

1. define an enum for the classmap: DRM.debug has DRM_UT_{CORE,KMS,...}
   multiple classes must share 0-62 classid space.
2. DYNDBG_CLASSMAP_DEFINE(.. DRM_UT_{CORE,KMS,...})
3. DYNDBG_CLASSMAP_PARAM* (classmap)
4. DYNDBG_CLASSMAP_USE()
   by _submod only, skipping 2,3

Move all the enum declarations together, to better explain how they
share the 0..62 class-id space available to a module (non-overlapping
subranges).

reorg macros 2,3 by name.  This gives a tabular format, making it easy
to see the pattern of repetition, and the points of change.

And 

[PATCH v7c 15/24] dyndbg: refactor ddebug_classparam_clamp_input

2023-10-18 Thread Jim Cromie
Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former.  It takes kernel-param arg, so it can complain
about "foo: bad input".

Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to validate inputs from parent's params, just like our own.
To support that reuse, alter ddebug_sync_classbits() and caller to
pass kp instead of kp->arg.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 70 ++---
 1 file changed, 47 insertions(+), 23 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index c9517d403e06..a6ee142668bf 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -653,6 +653,30 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
 
 #define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
 
+static void ddebug_class_param_clamp_input(unsigned long *inrep, const struct 
kernel_param *kp)
+{
+   const struct ddebug_class_param *dcp = kp->arg;
+   const struct ddebug_class_map *map = dcp->map;
+
+   switch (map->map_type) {
+   case DD_CLASS_TYPE_DISJOINT_BITS:
+   /* expect bits. mask and warn if too many */
+   if (*inrep & ~CLASSMAP_BITMASK(map->length)) {
+   pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx, 
masking\n",
+   KP_NAME(kp), *inrep, 
CLASSMAP_BITMASK(map->length));
+   *inrep &= CLASSMAP_BITMASK(map->length);
+   }
+   break;
+   case DD_CLASS_TYPE_LEVEL_NUM:
+   /* input is bitpos, of highest verbosity to be enabled */
+   if (*inrep > map->length) {
+   pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
+   KP_NAME(kp), *inrep, map->length);
+   *inrep = map->length;
+   }
+   break;
+   }
+}
 static int param_set_dyndbg_module_classes(const char *instr,
   const struct kernel_param *kp,
   const char *modnm)
@@ -671,26 +695,15 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
pr_err("expecting numeric input, not: %s > %s\n", instr, 
KP_NAME(kp));
return -EINVAL;
}
+   ddebug_class_param_clamp_input(, kp);
 
switch (map->map_type) {
case DD_CLASS_TYPE_DISJOINT_BITS:
-   /* expect bits. mask and warn if too many */
-   if (inrep & ~CLASSMAP_BITMASK(map->length)) {
-   pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx, 
masking\n",
-   KP_NAME(kp), inrep, 
CLASSMAP_BITMASK(map->length));
-   inrep &= CLASSMAP_BITMASK(map->length);
-   }
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
-   /* input is bitpos, of highest verbosity to be enabled */
-   if (inrep > map->length) {
-   pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
-   KP_NAME(kp), inrep, map->length);
-   inrep = map->length;
-   }
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
@@ -1157,16 +1170,27 @@ static const char * const ddebug_classmap_typenames[] = 
{
  ddebug_classmap_typenames[_cm->map_type]);\
})
 
-static void ddebug_sync_classbits(const struct ddebug_class_param *dcp, const 
char *modname)
+static void ddebug_sync_classbits(const struct kernel_param *kp, const char 
*modname)
 {
-   /* clamp initial bitvec, mask off hi-bits */
-   if (*dcp->bits & ~CLASSMAP_BITMASK(dcp->map->length)) {
-   *dcp->bits &= CLASSMAP_BITMASK(dcp->map->length);
-   v2pr_info("preset classbits: %lx\n", *dcp->bits);
+   struct ddebug_class_param *dcp = kp->arg;
+   unsigned long new_bits;
+
+   ddebug_class_param_clamp_input(dcp->bits, kp);
+
+   switch (dcp->map->map_type) {
+   case DD_CLASS_TYPE_DISJOINT_BITS:
+   v2pr_info("  %s: classbits: 0x%lx\n", KP_NAME(kp), *dcp->bits);
+   ddebug_apply_class_bitmap(dcp, dcp->bits, 0UL, modname);
+   break;
+   case DD_CLASS_TYPE_LEVEL_NUM:
+   new_bits = CLASSMAP_BITMASK(*dcp->lvl);
+   v2pr_info("  %s: lvl:%ld bits:0x%lx\n", KP_NAME(kp), *dcp->lvl, 
new_bits);
+   ddebug_apply_class_bitmap(dcp, _bits, 0UL, modname);
+   break;
+   default:
+   

[PATCH v7c 08/24] dyndbg: reduce verbose/debug clutter

2023-10-18 Thread Jim Cromie
currently, for verbose=3, these are logged (blank lines for clarity):

 dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
 dyndbg: split into words: "class" "DRM_UT_CORE" "+p"

 dyndbg: op='+'
 dyndbg: flags=0x1
 dyndbg: *flagsp=0x1 *maskp=0x

 dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 class=...
 dyndbg: no matches for query
 dyndbg: no-match: func="" file="" module="" format="" lineno=0-0 class=...
 dyndbg: processed 1 queries, with 0 matches, 0 errs

That is excessive, so this patch:
 - shrinks 3 lines of 2nd stanza to single line
 - drops 1st 2 lines of 3rd stanza
   3rd is like 1st, with result, not procedure.
   2nd is just status, retold in 4th, with more info.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b67c9b137447..b0e11f6bfaa2 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -266,9 +266,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(_lock);
 
-   if (!nfound && verbose)
-   pr_info("no matches for query\n");
-
return nfound;
 }
 
@@ -497,7 +494,6 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
pr_err("bad flag-op %c, at start of %s\n", *str, str);
return -EINVAL;
}
-   v3pr_info("op='%c'\n", op);
 
for (; *str ; ++str) {
for (i = ARRAY_SIZE(opt_array) - 1; i >= 0; i--) {
@@ -511,7 +507,6 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
return -EINVAL;
}
}
-   v3pr_info("flags=0x%x\n", modifiers->flags);
 
/* calculate final flags, mask based upon op */
switch (op) {
@@ -527,7 +522,7 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
modifiers->flags = 0;
break;
}
-   v3pr_info("*flagsp=0x%x *maskp=0x%x\n", modifiers->flags, 
modifiers->mask);
+   v3pr_info("op='%c' flags=0x%x maskp=0x%x\n", op, modifiers->flags, 
modifiers->mask);
 
return 0;
 }
@@ -537,7 +532,7 @@ static int ddebug_exec_query(char *query_string, const char 
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
 #define MAXWORDS 9
-   int nwords, nfound;
+   int nwords;
char *words[MAXWORDS];
 
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -555,10 +550,7 @@ static int ddebug_exec_query(char *query_string, const 
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
-   nfound = ddebug_change(, );
-   vpr_info_dq(, nfound ? "applied" : "no-match");
-
-   return nfound;
+   return ddebug_change(, );
 }
 
 /* handle multiple queries in query string, continue on error, return
-- 
2.41.0



[PATCH v7c 12/24] dyndbg: reduce verbose=3 messages in ddebug_add_module

2023-10-18 Thread Jim Cromie
The fn currently says "add-module", then "skipping" if the module has
no prdbgs.  Just check 1st and return quietly.

no functional change

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8beb98a831f5..45870a699507 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1242,11 +1242,10 @@ static int ddebug_add_module(struct _ddebug_info *di, 
const char *modname)
 {
struct ddebug_table *dt;
 
-   v3pr_info("add-module: %s.%d sites\n", modname, di->num_descs);
-   if (!di->num_descs) {
-   v3pr_info(" skip %s\n", modname);
+   if (!di->num_descs)
return 0;
-   }
+
+   v3pr_info("add-module: %s %d sites\n", modname, di->num_descs);
 
dt = kzalloc(sizeof(*dt), GFP_KERNEL);
if (dt == NULL) {
-- 
2.41.0



[PATCH v7c 11/24] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap

2023-10-18 Thread Jim Cromie
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn.  Disallow this.
And constify new_bits while here.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8158943b350d..8beb98a831f5 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -593,7 +593,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new class-param setting */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits,
+const unsigned long *new_bits,
+const unsigned long old_bits,
 const char *query_modname)
 {
 #define QUERY_SIZE 128
@@ -602,12 +603,12 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   if (*new_bits != *old_bits)
+   if (*new_bits != old_bits)
v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
 
for (bi = 0; bi < map->length; bi++) {
-   if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
+   if (test_bit(bi, new_bits) == test_bit(bi, _bits))
continue;
 
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
@@ -619,9 +620,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
-   if (*new_bits != *old_bits)
+   if (*new_bits != old_bits)
v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
 
return matches;
 }
@@ -678,7 +679,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits, NULL);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
*dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -688,7 +689,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits, NULL);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
old_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -742,7 +743,7 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
modnm);
+   totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -755,7 +756,7 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
modnm);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, old_bits, 
modnm);
*dcp->lvl = inrep;
break;
default:
-- 
2.41.0



[PATCH v7c 10/24] dyndbg: tighten ddebug_class_name() 1st arg type

2023-10-18 Thread Jim Cromie
Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b07aab422604..8158943b350d 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1117,12 +1117,12 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 #define class_in_range(class_id, map)  \
(class_id >= map->base && class_id < map->base + map->length)
 
-static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
+static const char *ddebug_class_name(struct ddebug_table *dt, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map = iter->table->classes;
-   int i, nc = iter->table->num_classes;
+   struct ddebug_class_map *map = dt->classes;
+   int i;
 
-   for (i = 0; i < nc; i++, map++)
+   for (i = 0; i < dt->num_classes; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1156,7 +1156,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
seq_puts(m, "\"");
 
if (dp->class_id != _DPRINTK_CLASS_DFLT) {
-   class = ddebug_class_name(iter, dp);
+   class = ddebug_class_name(iter->table, dp);
if (class)
seq_printf(m, " class:%s", class);
else
-- 
2.41.0



[PATCH v7c 07/24] dyndbg: drop NUM_TYPE_ARRAY

2023-10-18 Thread Jim Cromie
ARRAY_SIZE works here, since array decl is complete.

no functional change

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index b53217e4b711..8116d0a0d33a 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -106,11 +106,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base,  \
.map_type = _maptype,   \
-   .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+   .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames,   \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
 
 /* encapsulate linker provided built-in (or module) dyndbg data */
 struct _ddebug_info {
-- 
2.41.0



[PATCH v7c 05/24] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it

2023-10-18 Thread Jim Cromie
Add query_module param to ddebug_apply_class_bitmap().  This allows
its caller to update just one module, or all (as currently).  We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.

No functional change.

Signed-off-by: Jim Cromie 
---

after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.

bash-5.2# lsmod
Module  Size  Used by
i915 3133440  0
drm_buddy  20480  1 i915
ttm90112  1 i915
i2c_algo_bit   16384  1 i915
video  61440  1 i915
wmi32768  1 video
drm_display_helper200704  1 i915
drm_kms_helper208896  2 drm_display_helper,i915
drm   606208  5 
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344  2 drm_display_helper,i915
---
 lib/dynamic_debug.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a3be2e7c8c84..ba41fdeaaf98 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -601,7 +601,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new bitmap to the sys-knob's current bit-state */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits)
+unsigned long *new_bits, unsigned long 
*old_bits,
+const char *query_modname)
 {
 #define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -609,7 +610,8 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   v2pr_info("apply: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
+   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
+ query_modname ?: "");
 
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -618,12 +620,15 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
 test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
 
-   ct = ddebug_exec_queries(query, NULL);
+   ct = ddebug_exec_queries(query, query_modname);
matches += ct;
 
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
+ query_modname ?: "");
+
return matches;
 }
 
@@ -679,7 +684,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -689,7 +694,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -752,7 +757,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -765,7 +770,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
NULL);

[PATCH v7c 06/24] dyndbg: split param_set_dyndbg_classes to module/wrapper fns

2023-10-18 Thread Jim Cromie
rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new.  New arg allows caller to specify that only one module
is affected by a prdbgs update.

Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope of changes
made.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index ba41fdeaaf98..b67c9b137447 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -708,18 +708,9 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
return 0;
 }
 
-/**
- * param_set_dyndbg_classes - class FOO >control
- * @instr: string echo>d to sysfs, input depends on map_type
- * @kp:kp->arg has state: bits/lvl, map, map_type
- *
- * Enable/disable prdbgs by their class, as given in the arguments to
- * DECLARE_DYNDBG_CLASSMAP.  For LEVEL map-types, enforce relative
- * levels by bitpos.
- *
- * Returns: 0 or <0 if error.
- */
-int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+static int param_set_dyndbg_module_classes(const char *instr,
+  const struct kernel_param *kp,
+  const char *modnm)
 {
const struct ddebug_class_param *dcp = kp->arg;
const struct ddebug_class_map *map = dcp->map;
@@ -756,8 +747,8 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
KP_NAME(kp), inrep, 
CLASSMAP_BITMASK(map->length));
inrep &= CLASSMAP_BITMASK(map->length);
}
-   v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
NULL);
+   v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
+   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -770,7 +761,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
NULL);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
modnm);
*dcp->lvl = inrep;
break;
default:
@@ -779,6 +770,22 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
vpr_info("%s: total matches: %d\n", KP_NAME(kp), totct);
return 0;
 }
+
+/**
+ * param_set_dyndbg_classes - class FOO >control
+ * @instr: string echo>d to sysfs, input depends on map_type
+ * @kp:kp->arg has state: bits/lvl, map, map_type
+ *
+ * Enable/disable prdbgs by their class, as given in the arguments to
+ * DECLARE_DYNDBG_CLASSMAP.  For LEVEL map-types, enforce relative
+ * levels by bitpos.
+ *
+ * Returns: 0 or <0 if error.
+ */
+int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+{
+   return param_set_dyndbg_module_classes(instr, kp, NULL);
+}
 EXPORT_SYMBOL(param_set_dyndbg_classes);
 
 /**
-- 
2.41.0



[PATCH v7c 04/24] dyndbg: replace classmap list with a vector

2023-10-18 Thread Jim Cromie
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.

This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.

So this changes:

struct ddebug_class_map drops list-head link.

struct ddebug_table drops the list-head maps, and gets: classes &
num_classes for the start-addy and num_classes, placed to improve
struct packing.

The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.

The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.

Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.

no functional changes

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  1 -
 lib/dynamic_debug.c   | 61 ++-
 2 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 5231aaf361c4..b53217e4b711 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -83,7 +83,6 @@ enum class_map_type {
 };
 
 struct ddebug_class_map {
-   struct list_head link;
struct module *mod;
const char *mod_name;   /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b984ce338921..a3be2e7c8c84 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
 extern struct ddebug_class_map __stop___dyndbg_classes[];
 
 struct ddebug_table {
-   struct list_head link, maps;
+   struct list_head link;
const char *mod_name;
-   unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+   struct ddebug_class_map *classes;
+   unsigned int num_ddebugs, num_classes;
 };
 
 struct ddebug_query {
@@ -147,13 +148,15 @@ static void vpr_info_dq(const struct ddebug_query *query, 
const char *msg)
  query->first_lineno, query->last_lineno, query->class_string);
 }
 
+#define __outvar /* filled by callee */
 static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table 
const *dt,
- const char 
*class_string, int *class_id)
+   const char 
*class_string,
+   __outvar int *class_id)
 {
struct ddebug_class_map *map;
-   int idx;
+   int i, idx;
 
-   list_for_each_entry(map, >maps, link) {
+   for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -164,7 +167,6 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
 }
 
-#define __outvar /* filled by callee */
 /*
  * Search the tables for _ddebug's which match the given `query' and
  * apply the `flags' and `mask' to them.  Returns number of matching
@@ -,9 +1113,10 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 
 static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map;
+   struct ddebug_class_map *map = iter->table->classes;
+   int i, nc = iter->table->num_classes;
 
-   list_for_each_entry(map, >table->maps, link)
+   for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1197,30 +1200,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
 };
 
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
 {
struct ddebug_class_map *cm;
-   int i, j, ct = 0;
+   int i, nc = 0;
 
-   for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+   /*
+* Find this module's classmaps in a subrange/wholerange of
+* the builtin/modular classmap vector/section.  Save the start
+* and length of the subrange 

[PATCH v7c 02/24] dyndbg: reword "class unknown, " to "class:_UNKNOWN_"

2023-10-18 Thread Jim Cromie
This appears in the control-file to report an unknown class-name, which
indicates that the class_id is not authorized, and dyndbg will ignore
changes to it.  Generally, this means that a DYNDBG_CLASSMAP_DEFINE or
DYNDBG_CLASSMAP_USE is missing.

But the word "unknown" appears in quite a few prdbg formats, so thats
a suboptimal search term to find occurrences of the problem.  Thus
change it to "_UNKNOWN_" which properly shouts the condition.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 6fba6423cc10..ceb3067a5c83 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1151,7 +1151,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
if (class)
seq_printf(m, " class:%s", class);
else
-   seq_printf(m, " class unknown, _id:%d", dp->class_id);
+   seq_printf(m, " class:_UNKNOWN_ _id:%d", dp->class_id);
}
seq_puts(m, "\n");
 
-- 
2.41.0



[PATCH v7c 03/24] dyndbg: make ddebug_class_param union members same size

2023-10-18 Thread Jim Cromie
struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 2 +-
 lib/dynamic_debug.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 4fcbf4d4fd0a..5231aaf361c4 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -124,7 +124,7 @@ struct _ddebug_info {
 struct ddebug_class_param {
union {
unsigned long *bits;
-   unsigned int *lvl;
+   unsigned long *lvl;
};
char flags[8];
const struct ddebug_class_map *map;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index ceb3067a5c83..b984ce338921 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -796,7 +796,7 @@ int param_get_dyndbg_classes(char *buffer, const struct 
kernel_param *kp)
 
case DD_CLASS_TYPE_LEVEL_NAMES:
case DD_CLASS_TYPE_LEVEL_NUM:
-   return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl);
+   return scnprintf(buffer, PAGE_SIZE, "%ld\n", *dcp->lvl);
default:
return -1;
}
-- 
2.41.0



[PATCH v7c 01/24] test-dyndbg: fixup CLASSMAP usage error

2023-10-18 Thread Jim Cromie
more careful reading of test output reveals:

lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing 
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" 
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class 
unknown, _id:13

That last line is wrong, the HI class is declared.

But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param).  So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report.  I intentionally coded in an error, but
forgot to verify its detection and remove it.

RFC:

This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone.  As noted in test-mod comments:

 * Using the CLASSMAP api:
 * - classmaps must have corresponding enum
 * - enum symbols must match/correlate with class-name strings in the map.
 * - base must equal enum's 1st value
 * - multiple maps must set their base to share the 0-62 class_id space !!
 *   (build-bug-on tips welcome)

Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__.  Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.

[1] name changes later to DYNDBG_CLASSMAP_DEFINE

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
 DD_SYS_WRAP(disjoint_bits, T);
 
 /* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
 DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
 DD_SYS_WRAP(disjoint_names, p);
-- 
2.41.0



[PATCH v7c 00/24] fix DRM_USE_DYNAMIC_DEBUG=y regression

2023-10-18 Thread Jim Cromie


hi Jason, DRM-folk

(v7c now with all checkpatch fixes)

This patchest fixes the chicken-egg initialization problem in the 1st
version of ddebug-class-maps, that DRM-CI uncovered.

The root-problem was DECLARE_DYNDBG_CLASSMAP, which broke the K rule:
"define once, refer many".  In patch 14 it is replaced by:

 DYNDBG_CLASSMAP_DEFINE - define and export a struct ddebug_class_map
 DYNDBG_CLASSMAP_USE - ref the exported struct

test-dynamic-debug is also extended with a -submod.ko, in order to
recapitulate the drm & drivers initialization scenario.

They're on v6.6-rc6 now, and recently applied cleanly to drm-tip/drm-tip.

Ive been running recent revs on rc3+, on my desktop and laptop.

The final blocker was a missing __align(8) on the ddebug_class_user
record inserted by DYNDBG_CLASSMAP_USE.  This caused DRM=y (builtin
only) to have a corrupt record for drm_kms_helper (a builtin dependent).
Curiously, a clang build did not exhibit this problem.

Heres a part of dmesg, for a DRM=y kernel, booted with
 dynamic_debug.verbose=3 drm.debug=0x10

[0.466747] dyndbg: add-module: drm 406 sites
[0.467569] dyndbg: classes[0]: module:drm base:0 len:10 type:DISJOINT_BITS
[0.467743] dyndbg: module:drm attached 1 classes
[0.468557] dyndbg: builtin class: module:drm base:0 len:10 
type:DISJOINT_BITS
[0.468742] dyndbg:  found kp:drm.debug =0x10
[0.468743] dyndbg:   mapped to: module:drm base:0 len:10 type:DISJOINT_BITS
[0.469742] dyndbg:   drm.debug: classbits: 0x10
[0.470573] dyndbg: apply bitmap: 0x10 to: 0x0 for drm
[0.470743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm
[0.471743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p"
[0.472743] dyndbg: op='+' flags=0x1 maskp=0x
[0.473679] dyndbg: parsed: func="" file="" module="drm" format="" 
lineno=0-0 class=DRM_UT_ATOMIC
[0.473749] dyndbg: processed 1 queries, with 0 matches, 0 errs
[0.474742] dyndbg: bit_4: 0 matches on class: DRM_UT_ATOMIC -> 0x10
[0.475742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm
[0.476686] dyndbg: 406 debug prints in module drm
[0.476743] dyndbg: add-module: drm_kms_helper 93 sites
[0.477727] dyndbg: class_ref[0] drm_kms_helper -> drm module:drm base:0 
len:10 type:DISJOINT_BITS
[0.477743] dyndbg: builtin class: module:drm base:0 len:10 
type:DISJOINT_BITS
[0.478742] dyndbg:  found kp:drm.debug =0x10
[0.478743] dyndbg:   mapped to: module:drm base:0 len:10 type:DISJOINT_BITS
[0.479743] dyndbg:   drm.debug: classbits: 0x10
[0.480592] dyndbg: apply bitmap: 0x10 to: 0x0 for drm_kms_helper
[0.480743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm_kms_helper
[0.481743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p"
[0.482743] dyndbg: op='+' flags=0x1 maskp=0x
[0.483743] dyndbg: parsed: func="" file="" module="drm_kms_helper" 
format="" lineno=0-0 class=DRM_UT_ATOMIC
[0.484750] dyndbg: class-ref: drm_kms_helper.DRM_UT_ATOMIC  
module:drm_kms_helper nd:93 nc:0 nu:1
[0.485809] dyndbg: processed 1 queries, with 44 matches, 0 errs
[0.486742] dyndbg: bit_4: 44 matches on class: DRM_UT_ATOMIC -> 0x10
[0.487742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm_kms_helper
[0.488743] dyndbg: attach-client-module:  module:drm_kms_helper nd:93 nc:0 
nu:1
[0.489742] dyndbg:  93 debug prints in module drm_kms_helper

Widespread testing is appreciated.
I have scripts if anyone wants them.
lkp-robot reported success on dd-fix-7b, no report yet on 7c

Patches are also at https://github.com/jimc/linux/tree/dd-fix-7c

Jim Cromie (24):
  test-dyndbg: fixup CLASSMAP usage error
  dyndbg: reword "class unknown," to "class:_UNKNOWN_"
  dyndbg: make ddebug_class_param union members same size
  dyndbg: replace classmap list with a vector
  dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
  dyndbg: split param_set_dyndbg_classes to module/wrapper fns
  dyndbg: drop NUM_TYPE_ARRAY
  dyndbg: reduce verbose/debug clutter
  dyndbg: silence debugs with no-change updates
  dyndbg: tighten ddebug_class_name() 1st arg type
  dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
  dyndbg: reduce verbose=3 messages in ddebug_add_module
  dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
  dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression
  dyndbg: refactor ddebug_classparam_clamp_input
  dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
  dyndbg-doc: add classmap info to howto
  dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED
  dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP
  dyndbg: refactor *dynamic_emit_prefix
  dyndbg: change WARN_ON to WARN_ON_ONCE
  drm: use correct ccflags-y spelling
  drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
  drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

 .../admin-guide/dynamic-debug-howto.rst   |  60 ++-
 MAINTAINERS   |   2 +-
 drivers/gpu/drm/Kconfig   |   3 +-
 

Re: [PATCH v4 13/17] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-10-18 Thread Shyam Sundar S K



On 10/18/2023 9:37 PM, Christian König wrote:
> Am 18.10.23 um 17:47 schrieb Mario Limonciello:
>> On 10/18/2023 08:40, Christian König wrote:
>>>
>>>
>>> Am 18.10.23 um 11:28 schrieb Shyam Sundar S K:

 On 10/18/2023 2:50 PM, Ilpo Järvinen wrote:
> On Wed, 18 Oct 2023, Shyam Sundar S K wrote:
>
>> In order to provide GPU inputs to TA for the Smart PC solution
>> to work, we
>> need to have interface between the PMF driver and the AMDGPU
>> driver.
>>
>> Add the initial code path for get interface from AMDGPU.
>>
>> Co-developed-by: Mario Limonciello 
>> Signed-off-by: Mario Limonciello 
>> Signed-off-by: Shyam Sundar S K 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/Makefile |   2 +
>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h |   1 +
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c | 138
>> 
>>   drivers/platform/x86/amd/pmf/Kconfig    |   1 +
>>   drivers/platform/x86/amd/pmf/core.c |   1 +
>>   drivers/platform/x86/amd/pmf/pmf.h  |   3 +
>>   drivers/platform/x86/amd/pmf/spc.c  |  13 +++
>>   drivers/platform/x86/amd/pmf/tee-if.c   |  26 +
>>   include/linux/amd-pmf-io.h  |  35 ++
>>   9 files changed, 220 insertions(+)
>>   create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
>>   create mode 100644 include/linux/amd-pmf-io.h
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
>> b/drivers/gpu/drm/amd/amdgpu/Makefile
>> index 384b798a9bad..7fafccefbd7a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
>> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
>> @@ -86,6 +86,8 @@ amdgpu-$(CONFIG_PROC_FS) += amdgpu_fdinfo.o
>>   amdgpu-$(CONFIG_PERF_EVENTS) += amdgpu_pmu.o
>> +amdgpu-$(CONFIG_AMD_PMF) += amdgpu_pmf.o
>> +
>>   # add asic specific block
>>   amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o \
>>   dce_v8_0.o gfx_v7_0.o cik_sdma.o uvd_v4_2.o vce_v2_0.o
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index a79d53bdbe13..26ffa1b4fe57 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -50,6 +50,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
>> new file mode 100644
>> index ..ac981848df50
>> --- /dev/null
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
>> @@ -0,0 +1,138 @@
>> +/*
>> + * Copyright 2023 Advanced Micro Devices, Inc.
>> + *
>> + * Permission is hereby granted, free of charge, to any person
>> obtaining a
>> + * copy of this software and associated documentation files
>> (the "Software"),
>> + * to deal in the Software without restriction, including
>> without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute,
>> sublicense,
>> + * and/or sell copies of the Software, and to permit persons to
>> whom the
>> + * Software is furnished to do so, subject to the following
>> conditions:
>> + *
>> + * The above copyright notice and this permission notice shall
>> be included in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
>> KIND, EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>> EVENT SHALL
>> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY
>> CLAIM, DAMAGES OR
>> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>> OTHERWISE,
>> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
>> THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
> This is MIT, right? Add the required SPDX-License-Identifier line
> for it
> at the top of the file, thank you.
>
 all the files in drivers/gpu/drm/amd/amdgpu/* carry the same license
 text. So, have retained it to maintain uniformity.
>>>
>>> Please add the SPDX License Identifier for any file you add.

OK. I thought to keep it same like the other files. I will change this
to SPDX in the next revision.

>>>
>>> Apart from that the whole approach of attaching this directly to
>>> amdgpu looks extremely questionable to me.
>>>
>>
>> What's the long term outlook for things that are needed directly
>> from amdgpu?  Is there going to be more besides the backlight and
>> the display count/type?
> 
> Yeah, that goes into the same direction as my concern.

PMF is an APU only feature and will need inputs from multiple
subsystems (in this case its GPU) to send changing system information
to PMF TA (Trusted 

[PATCH v2 2/2] drm/uapi: add explicit virtgpu context debug name

2023-10-18 Thread Gurchetan Singh
There are two problems with the current method of determining the
virtio-gpu debug name.

1) TASK_COMM_LEN is defined to be 16 bytes only, and this is a
   Linux kernel idiom (see PR_SET_NAME + PR_GET_NAME). Though,
   Android/FreeBSD get around this via setprogname(..)/getprogname(..)
   in libc.

   On Android, names longer than 16 bytes are common.  For example,
   one often encounters a program like "com.android.systemui".

   The virtio-gpu spec allows the debug name to be up to 64 bytes, so
   ideally userspace should be able to set debug names up to 64 bytes.

2) The current implementation determines the debug name using whatever
   task initiated virtgpu.  This is could be a "RenderThread" of a
   larger program, when we actually want to propagate the debug name
   of the program.

To fix these issues, add a new CONTEXT_INIT param that allows userspace
to set the debug name when creating a context.

It takes a null-terminated C-string as the param value. The length of the
string (excluding the terminator) **should** be <= 64 bytes.  Otherwise,
the debug_name will be truncated to 64 bytes.

Link to open-source userspace:
https://android-review.googlesource.com/c/platform/hardware/google/gfxstream/+/2787176

Signed-off-by: Gurchetan Singh 
Reviewed-by: Josh Simonot 
---
v2: Fixes suggested by Dmitry Osipenko
- Squash implementation and UAPI change into one commit
- Avoid unnecessary casts
- Use bool when necessary
- Add case for when length of string exceeds DEBUG_NAME_MAX_LEN.

 drivers/gpu/drm/virtio/virtgpu_drv.h   |  5 +++
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 46 ++
 include/uapi/drm/virtgpu_drm.h |  2 ++
 3 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 96365a772f77..bb7d86a0c6a1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -58,6 +58,9 @@
 #define MAX_CAPSET_ID 63
 #define MAX_RINGS 64
 
+/* See virtio_gpu_ctx_create. One additional character for NULL terminator. */
+#define DEBUG_NAME_MAX_LEN 65
+
 struct virtio_gpu_object_params {
unsigned long size;
bool dumb;
@@ -274,6 +277,8 @@ struct virtio_gpu_fpriv {
uint64_t base_fence_ctx;
uint64_t ring_idx_mask;
struct mutex context_lock;
+   char debug_name[DEBUG_NAME_MAX_LEN];
+   bool explicit_debug_name;
 };
 
 /* virtgpu_ioctl.c */
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 8d13b17c215b..357d670361a0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -42,12 +42,19 @@
 static void virtio_gpu_create_context_locked(struct virtio_gpu_device *vgdev,
 struct virtio_gpu_fpriv *vfpriv)
 {
-   char dbgname[TASK_COMM_LEN];
+   if (vfpriv->explicit_debug_name) {
+   virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
+ vfpriv->context_init,
+ strlen(vfpriv->debug_name),
+ vfpriv->debug_name);
+   } else {
+   char dbgname[TASK_COMM_LEN];
 
-   get_task_comm(dbgname, current);
-   virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
- vfpriv->context_init, strlen(dbgname),
- dbgname);
+   get_task_comm(dbgname, current);
+   virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
+ vfpriv->context_init, 
strlen(dbgname),
+ dbgname);
+   }
 
vfpriv->context_created = true;
 }
@@ -107,6 +114,9 @@ static int virtio_gpu_getparam_ioctl(struct drm_device 
*dev, void *data,
case VIRTGPU_PARAM_SUPPORTED_CAPSET_IDs:
value = vgdev->capset_id_mask;
break;
+   case VIRTGPU_PARAM_EXPLICIT_DEBUG_NAME:
+   value = vgdev->has_context_init ? 1 : 0;
+   break;
default:
return -EINVAL;
}
@@ -580,7 +590,7 @@ static int virtio_gpu_context_init_ioctl(struct drm_device 
*dev,
return -EINVAL;
 
/* Number of unique parameters supported at this time. */
-   if (num_params > 3)
+   if (num_params > 4)
return -EINVAL;
 
ctx_set_params = memdup_user(u64_to_user_ptr(args->ctx_set_params),
@@ -642,6 +652,30 @@ static int virtio_gpu_context_init_ioctl(struct drm_device 
*dev,
 
vfpriv->ring_idx_mask = value;
break;
+   case VIRTGPU_CONTEXT_PARAM_DEBUG_NAME:
+   if (vfpriv->explicit_debug_name) {
+   ret = -EINVAL;
+   goto out_unlock;
+ 

[PATCH v2 1/2] drm/virtio: use uint64_t more in virtio_gpu_context_init_ioctl

2023-10-18 Thread Gurchetan Singh
drm_virtgpu_context_set_param defines both param and
value to be u64s.

Signed-off-by: Gurchetan Singh 
Reviewed-by: Josh Simonot 
Reviewed-by: Dmitry Osipenko 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index b24b11f25197..8d13b17c215b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -565,8 +565,8 @@ static int virtio_gpu_context_init_ioctl(struct drm_device 
*dev,
 void *data, struct drm_file *file)
 {
int ret = 0;
-   uint32_t num_params, i, param, value;
-   uint64_t valid_ring_mask;
+   uint32_t num_params, i;
+   uint64_t valid_ring_mask, param, value;
size_t len;
struct drm_virtgpu_context_set_param *ctx_set_params = NULL;
struct virtio_gpu_device *vgdev = dev->dev_private;
-- 
2.42.0.655.g421f12c284-goog



[PATCH 5/5] arm64: dts: rockchip: add Powkiddy RK2023

2023-10-18 Thread Chris Morgan
From: Chris Morgan 

Add support for the Powkiddy RK2023. The Powkiddy RK2023 is a handheld
gaming device with a 3.5 inch screen powered by the Rockchip RK3566
SoC. The device is almost identical to the Anbernic RG353P except it
lacks eMMC, a function button, a touch screen, no UART headers on the
board, and the panel has slightly different timings.

Signed-off-by: Chris Morgan 
---
 arch/arm64/boot/dts/rockchip/Makefile |   1 +
 .../dts/rockchip/rk3566-powkiddy-rk2023.dts   | 161 ++
 2 files changed, 162 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 3f01b429a3aa..9ef64cfb8392 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rk2023.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-radxa-cm3-io.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts 
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
new file mode 100644
index ..5740412f6b2b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include "rk3566-anbernic-rg353x.dtsi"
+
+/ {
+   model = "RK2023";
+   compatible = "powkiddy,rk2023", "rockchip,rk3566";
+
+   aliases {
+   mmc1 = 
+   mmc2 = 
+   mmc3 = 
+   };
+
+   battery: battery {
+   compatible = "simple-battery";
+   charge-full-design-microamp-hours = <3151000>;
+   charge-term-current-microamp = <30>;
+   constant-charge-current-max-microamp = <200>;
+   constant-charge-voltage-max-microvolt = <425>;
+   factory-internal-resistance-micro-ohms = <117000>;
+   voltage-max-design-microvolt = <4172000>;
+   voltage-min-design-microvolt = <340>;
+
+   ocv-capacity-celsius = <20>;
+   ocv-capacity-table-0 =  <4172000 100>, <4092000 95>, <4035000 
90>, <399 85>,
+   <3939000 80>, <3895000 75>, <3852000 
70>, <3807000 65>,
+   <3762000 60>, <3713000 55>, <3672000 
50>, <3647000 45>,
+   <3629000 40>, <3613000 35>, <3598000 
30>, <3578000 25>,
+   <355 20>, <3519000 15>, <3479000 
10>, <3438000 5>,
+   <340 0>;
+   };
+
+   /* Channels reversed for headphones. */
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "rk817_int";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,hp-det-gpio = < RK_PC6 
GPIO_ACTIVE_HIGH>;
+   simple-audio-card,mclk-fs = <256>;
+   simple-audio-card,widgets =
+   "Microphone", "Mic Jack",
+   "Headphone", "Headphones",
+   "Speaker", "Internal Speakers";
+   simple-audio-card,routing =
+   "MICL", "Mic Jack",
+   "Headphones", "HPOL",
+   "Headphones", "HPOR",
+   "Internal Speakers", "SPKO";
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   };
+
+   simple-audio-card,cpu {
+   sound-dai = <_8ch>;
+   };
+   };
+
+};
+
+/delete-node/ _keys;
+
+ {
+   /delete-property/ stdout-path;
+};
+
+ {
+   assigned-clocks = < CLK_RTC_32K>, < PLL_GPLL>,
+ < PLL_PPLL>, < PLL_VPLL>;
+   assigned-clock-rates = <32768>, <12>,
+ <2>, <11520>;
+};
+
+_keys_control {
+   button-r1 {
+   gpios = < RK_PB3 GPIO_ACTIVE_LOW>;
+   label = "TR";
+   linux,code = ;
+   };
+
+   button-r2 {
+   gpios = < RK_PB4 GPIO_ACTIVE_LOW>;
+   label = "TR2";
+   linux,code = ;
+   };
+};
+
+/delete-node/ &{/i2c@fdd4/regulator@40};
+
+ {
+   vdd_cpu: regulator@1c {
+   compatible = "tcs,tcs4525";
+   reg = <0x1c>;
+   fcs,suspend-voltage-selector = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <712500>;
+   

[PATCH 3/5] clk: rockchip: rk3568: Add PLL rate for 115.2MHz

2023-10-18 Thread Chris Morgan
From: Chris Morgan 

Add support for a PLL rate of 115.2MHz so that the Powkiddy RK2023 panel
can run at a requested 60hz (59.99, close enough).

I have confirmed this rate fits with all the constraints
listed in the TRM for the VPLL (as an integer PLL) in Part 1 "Chapter
2 Clock & Reset Unit (CRU)."

Signed-off-by: Chris Morgan 
---
 drivers/clk/rockchip/clk-rk3568.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3568.c 
b/drivers/clk/rockchip/clk-rk3568.c
index db713e1526cd..bfbcbb744327 100644
--- a/drivers/clk/rockchip/clk-rk3568.c
+++ b/drivers/clk/rockchip/clk-rk3568.c
@@ -79,6 +79,7 @@ static struct rockchip_pll_rate_table rk3568_pll_rates[] = {
RK3036_PLL_RATE(14850, 1, 99, 4, 4, 1, 0),
RK3036_PLL_RATE(13500, 2, 45, 4, 1, 1, 0),
RK3036_PLL_RATE(11900, 3, 119, 4, 2, 1, 0),
+   RK3036_PLL_RATE(11520, 1, 24, 5, 1, 1, 0),
RK3036_PLL_RATE(10800, 2, 45, 5, 1, 1, 0),
RK3036_PLL_RATE(10100, 1, 101, 6, 4, 1, 0),
RK3036_PLL_RATE(1, 1, 150, 6, 6, 1, 0),
-- 
2.34.1



[PATCH 2/5] drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support

2023-10-18 Thread Chris Morgan
From: Chris Morgan 

Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds.

Tested on my RG351V, RG353P, RG353V, and RK2023.

Signed-off-by: Chris Morgan 
---
 .../gpu/drm/panel/panel-newvision-nv3051d.c   | 56 +++
 1 file changed, 45 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c 
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index 79de6c886292..d24c51503d68 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_flags;
+   u32 mode_flags;
 };
 
 struct panel_nv3051d {
@@ -385,15 +386,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
 
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
-   dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
-   /*
-* The panel in the RG351V is identical to the 353P, except it
-* requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-*/
-   if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
-   dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+   dsi->mode_flags = ctx->panel_info->mode_flags;
 
drm_panel_init(>panel, >dev, _nv3051d_funcs,
   DRM_MODE_CONNECTOR_DSI);
@@ -481,18 +474,59 @@ static const struct drm_display_mode 
nv3051d_rgxx3_modes[] = {
},
 };
 
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+   {
+   .hdisplay   = 640,
+   .hsync_start= 640 + 40,
+   .hsync_end  = 640 + 40 + 2,
+   .htotal = 640 + 40 + 2 + 80,
+   .vdisplay   = 480,
+   .vsync_start= 480 + 18,
+   .vsync_end  = 480 + 18 + 2,
+   .vtotal = 480 + 18 + 2 + 4,
+   .clock  = 24150,
+   .flags  = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+   },
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
.display_modes = nv3051d_rgxx3_modes,
.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
.width_mm = 70,
.height_mm = 57,
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+   .display_modes = nv3051d_rgxx3_modes,
+   .num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+   .width_mm = 70,
+   .height_mm = 57,
+   .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+   .display_modes = nv3051d_rk2023_modes,
+   .num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+   .width_mm = 70,
+   .height_mm = 57,
+   .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
 };
 
 static const struct of_device_id newvision_nv3051d_of_match[] = {
-   { .compatible = "newvision,nv3051d", .data = _rgxx3_info },
+   { .compatible = "anbernic,rg351v-panel", .data = _rg351v_info },
+   { .compatible = "anbernic,rg353p-panel", .data = _rg353p_info },
+   { .compatible = "powkiddy,rk2023-panel", .data = _rk2023_info },
{ /* sentinel */ }
 };
+
 MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
 
 static struct mipi_dsi_driver newvision_nv3051d_driver = {
-- 
2.34.1



[PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023

2023-10-18 Thread Chris Morgan
From: Chris Morgan 

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and
powered by the Rockchip RK3566 SoC.

Signed-off-by: Chris Morgan 
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index a349bf4da6bc..a6612185a7ff 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -674,6 +674,11 @@ properties:
   - const: powkiddy,rgb30
   - const: rockchip,rk3566
 
+  - description: Powkiddy RK2023
+items:
+  - const: powkiddy,rk2023
+  - const: rockchip,rk3566
+
   - description: Radxa Compute Module 3(CM3)
 items:
   - enum:
-- 
2.34.1



[PATCH 1/5] dt-bindings: display: panel: Update NewVision NV3051D compatibles

2023-10-18 Thread Chris Morgan
From: Chris Morgan 

Update the NewVision NV3051D compatible strings by adding a new panel,
the powkiddy,rk2023-panel, and removing another entry, the
anbernic,rg353v-panel. The rg353v-panel is exactly identical to the
rg353p-panel and is not currently in use by any existing device tree.
The rk2023-panel is similar to the rg353p-panel but has slightly
different timings.

Signed-off-by: Chris Morgan 
---
 .../devicetree/bindings/display/panel/newvision,nv3051d.yaml| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml 
b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
index cce775a87f87..7a634fbc465e 100644
--- a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
+++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
@@ -21,7 +21,7 @@ properties:
   - enum:
   - anbernic,rg351v-panel
   - anbernic,rg353p-panel
-  - anbernic,rg353v-panel
+  - powkiddy,rk2023-panel
   - const: newvision,nv3051d
 
   reg: true
-- 
2.34.1



[PATCH 0/5] rockchip: Add Powkiddy RK2023

2023-10-18 Thread Chris Morgan
From: Chris Morgan 

Add support for the Powkiddy RK2023, which is extremely similar to
existing devices from Anbernic.

Chris Morgan (5):
  dt-bindings: display: panel: Update NewVision NV3051D compatibles
  drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support
  clk: rockchip: rk3568: Add PLL rate for 115.2MHz
  dt-bindings: arm: rockchip: Add Powkiddy RK2023
  arm64: dts: rockchip: add Powkiddy RK2023

 .../devicetree/bindings/arm/rockchip.yaml |   5 +
 .../display/panel/newvision,nv3051d.yaml  |   2 +-
 arch/arm64/boot/dts/rockchip/Makefile |   1 +
 .../dts/rockchip/rk3566-powkiddy-rk2023.dts   | 161 ++
 drivers/clk/rockchip/clk-rk3568.c |   1 +
 .../gpu/drm/panel/panel-newvision-nv3051d.c   |  56 --
 6 files changed, 214 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts

-- 
2.34.1



Re: [PATCH v6 7/7] drm/sched: Add a helper to queue TDR immediately

2023-10-18 Thread Luben Tuikov
On 2023-10-17 11:09, Matthew Brost wrote:
> Add a helper whereby a driver can invoke TDR immediately.
> 
> v2:
>  - Drop timeout args, rename function, use mod delayed work (Luben)
> v3:
>  - s/XE/Xe (Luben)
>  - present tense in commit message (Luben)
>  - Adjust comment for drm_sched_tdr_queue_imm (Luben)
> v4:
>  - Adjust commit message (Luben)
> 
> Cc: Luben Tuikov 
> Signed-off-by: Matthew Brost 

Reviewed-by: Luben Tuikov 

Yeah, this patch is very good now--thanks for updating it.

Regards,
Luben

> ---
>  drivers/gpu/drm/scheduler/sched_main.c | 18 +-
>  include/drm/gpu_scheduler.h|  1 +
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
> b/drivers/gpu/drm/scheduler/sched_main.c
> index ff2cfad54342..563a4f0f6956 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -431,7 +431,7 @@ static void drm_sched_start_timeout(struct 
> drm_gpu_scheduler *sched)
>  
>   if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
>   !list_empty(>pending_list))
> - queue_delayed_work(sched->timeout_wq, >work_tdr, 
> sched->timeout);
> + mod_delayed_work(sched->timeout_wq, >work_tdr, 
> sched->timeout);
>  }
>  
>  static void drm_sched_start_timeout_unlocked(struct drm_gpu_scheduler *sched)
> @@ -441,6 +441,22 @@ static void drm_sched_start_timeout_unlocked(struct 
> drm_gpu_scheduler *sched)
>   spin_unlock(>job_list_lock);
>  }
>  
> +/**
> + * drm_sched_tdr_queue_imm: - immediately start job timeout handler
> + *
> + * @sched: scheduler for which the timeout handling should be started.
> + *
> + * Start timeout handling immediately for the named scheduler.
> + */
> +void drm_sched_tdr_queue_imm(struct drm_gpu_scheduler *sched)
> +{
> + spin_lock(>job_list_lock);
> + sched->timeout = 0;
> + drm_sched_start_timeout(sched);
> + spin_unlock(>job_list_lock);
> +}
> +EXPORT_SYMBOL(drm_sched_tdr_queue_imm);
> +
>  /**
>   * drm_sched_fault - immediately start timeout handler
>   *
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 625ffe040de3..998b32b8d212 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -568,6 +568,7 @@ void drm_sched_entity_modify_sched(struct 
> drm_sched_entity *entity,
>   struct drm_gpu_scheduler **sched_list,
> unsigned int num_sched_list);
>  
> +void drm_sched_tdr_queue_imm(struct drm_gpu_scheduler *sched);
>  void drm_sched_job_cleanup(struct drm_sched_job *job);
>  void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched);
>  bool drm_sched_wqueue_ready(struct drm_gpu_scheduler *sched);

-- 
Regards,
Luben



RE: [PATCH v5 2/3] drm/i915/guc: Close deregister-context race against CT-loss

2023-10-18 Thread Gupta, Anshuman



> -Original Message-
> From: Teres Alexis, Alan Previn 
> Sent: Saturday, October 14, 2023 6:34 AM
> To: intel-...@lists.freedesktop.org
> Cc: Teres Alexis, Alan Previn ; dri-
> de...@lists.freedesktop.org; Vivi, Rodrigo ; Ceraolo
> Spurio, Daniele ; Harrison, John C
> ; Gupta, Anshuman
> ; Ursulin, Tvrtko ;
> Jana, Mousumi 
> Subject: [PATCH v5 2/3] drm/i915/guc: Close deregister-context race against
> CT-loss
> 
> If we are at the end of suspend or very early in resume its possible an async
> fence signal (via rcu_call) is triggered to free_engines which could lead us 
> to
> the execution of the context destruction worker (after a prior worker flush).
> 
> Thus, when suspending, insert rcu_barriers at the start of i915_gem_suspend
> (part of driver's suspend prepare) and again in i915_gem_suspend_late so
> that all such cases have completed and context destruction list isn't missing
> anything.
Acked-by: Anshuman Gupta 
For rcu barrier usage.
> 
> In destroyed_worker_func, close the race against CT-loss by checking that CT 
> is
> enabled before calling into deregister_destroyed_contexts.
> 
> Based on testing, guc_lrc_desc_unpin may still race and fail as we traverse 
> the
> GuC's context-destroy list because the CT could be disabled right before 
> calling
> GuC's CT send function.
> 
> We've witnessed this race condition once every ~6000-8000 suspend-resume
> cycles while ensuring workloads that render something onscreen is
> continuously started just before we suspend (and the workload is small
> enough to complete and trigger the queued engine/context free-up either
> very late in suspend or very early in resume).
> 
> In such a case, we need to unroll the entire process because guc-lrc-unpin
> takes a gt wakeref which only gets released in the G2H IRQ reply that never
> comes through in this corner case. Without the unroll, the taken wakeref is
> leaked and will cascade into a kernel hang later at the tail end of suspend 
> in this
> function:
> 
>intel_wakeref_wait_for_idle(>wakeref)
>(called by) - intel_gt_pm_wait_for_idle
>(called by) - wait_for_suspend
> 
> Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_- contexts
> if guc_lrc_desc_unpin fails due to CT send falure.
> When unrolling, keep the context in the GuC's destroy-list so it can get 
> picked
> up on the next destroy worker invocation (if suspend aborted) or get fully
> purged as part of a GuC sanitization (end of suspend) or a reset flow.
> 
> Signed-off-by: Alan Previn 
> Signed-off-by: Anshuman Gupta 
> Tested-by: Mousumi Jana 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ---
>  2 files changed, 80 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 0d812f4d787d..3b27218aabe2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -28,6 +28,13 @@ void i915_gem_suspend(struct drm_i915_private
> *i915)
>   GEM_TRACE("%s\n", dev_name(i915->drm.dev));
> 
>   intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
> + /*
> +  * On rare occasions, we've observed the fence completion triggers
> +  * free_engines asynchronously via rcu_call. Ensure those are done.
> +  * This path is only called on suspend, so it's an acceptable cost.
> +  */
> + rcu_barrier();
> +
>   flush_workqueue(i915->wq);
> 
>   /*
> @@ -160,6 +167,9 @@ void i915_gem_suspend_late(struct
> drm_i915_private *i915)
>* machine in an unusable condition.
>*/
> 
> + /* Like i915_gem_suspend, flush tasks staged from fence triggers */
> + rcu_barrier();
> +
>   for_each_gt(gt, i915, i)
>   intel_gt_suspend_late(gt);
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index a5b68f77e494..9806b33c8561 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -235,6 +235,13 @@ set_context_destroyed(struct intel_context *ce)
>   ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;  }
> 
> +static inline void
> +clr_context_destroyed(struct intel_context *ce) {
> + lockdep_assert_held(>guc_state.lock);
> + ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED; }
> +
>  static inline bool context_pending_disable(struct intel_context *ce)  {
>   return ce->guc_state.sched_state &
> SCHED_STATE_PENDING_DISABLE; @@ -612,6 +619,8 @@ static int
> guc_submission_send_busy_loop(struct intel_guc *guc,
>u32 g2h_len_dw,
>bool loop)
>  {
> + int ret;
> +
>   /*
>* We always loop when a send requires a reply (i.e. g2h_len_dw > 0),
>* so we don't handle the case where we don't get a reply because we

Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c

2023-10-18 Thread Zhao Liu
Hi Rodrigo and Tvrtko,

It seems this series is missed in v6.5.
This work should not be forgotten. Let me rebase and refresh the version.

Regards,
Zhao

On Mon, Apr 17, 2023 at 10:53:28AM -0400, Rodrigo Vivi wrote:
> Date: Mon, 17 Apr 2023 10:53:28 -0400
> From: Rodrigo Vivi 
> Subject: Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in
>  gem/i915_gem_execbuffer.c
> 
> On Mon, Apr 17, 2023 at 12:24:45PM +0100, Tvrtko Ursulin wrote:
> > 
> > On 14/04/2023 11:45, Zhao Liu wrote:
> > > Hi Tvrtko,
> > > 
> > > On Wed, Apr 12, 2023 at 04:45:13PM +0100, Tvrtko Ursulin wrote:
> > > 
> > > [snip]
> > > 
> > > > > 
> > > > > [snip]
> > > > > > However I am unsure if disabling pagefaulting is needed or not. 
> > > > > > Thomas,
> > > > > > Matt, being the last to touch this area, perhaps you could have a 
> > > > > > look?
> > > > > > Because I notice we have a fallback iomap path which still uses
> > > > > > io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local 
> > > > > > conversion is
> > > > > > safe, does the iomap side also needs converting to
> > > > > > io_mapping_map_local_wc? Or they have separate requirements?
> > > > > 
> > > > > AFAIK, the requirements for io_mapping_map_local_wc() are the same as 
> > > > > for
> > > > > kmap_local_page(): the kernel virtual address is _only_ valid in the 
> > > > > caller
> > > > > context, and map/unmap nesting must be done in stack-based ordering 
> > > > > (LIFO).
> > > > > 
> > > > > I think a follow up patch could safely switch to 
> > > > > io_mapping_map_local_wc() /
> > > > > io_mapping_unmap_local_wc since the address is local to context.
> > > > > 
> > > > > However, not being an expert, reading your note now I suspect that 
> > > > > I'm missing
> > > > > something. Can I ask why you think that page-faults disabling might be
> > > > > necessary?
> > > > 
> > > > I am not saying it is, was just unsure and wanted some people who 
> > > > worked on this code most recently to take a look and confirm.
> > > > 
> > > > I guess it will work since the copying is done like this anyway:
> > > > 
> > > > /*
> > > >  * This is the fast path and we cannot handle a 
> > > > pagefault
> > > >  * whilst holding the struct mutex lest the user pass 
> > > > in the
> > > >  * relocations contained within a mmaped bo. For in 
> > > > such a case
> > > >  * we, the page fault handler would call 
> > > > i915_gem_fault() and
> > > >  * we would try to acquire the struct mutex again. 
> > > > Obviously
> > > >  * this is bad and so lockdep complains vehemently.
> > > >  */
> > > > pagefault_disable();
> > > > copied = __copy_from_user_inatomic(r, urelocs, count * 
> > > > sizeof(r[0]));
> > > > pagefault_enable();
> > > > if (unlikely(copied)) {
> > > > remain = -EFAULT;
> > > > goto out;
> > > > }
> > > > 
> > > > Comment is a bit outdated since we don't use that global "struct mutex" 
> > > > any longer, but in any case, if there is a page fault on the mapping 
> > > > where we need to recurse into i915 again to satisfy if, we seem to have 
> > > > code already to handle it. So kmap_local conversion I *think* can't 
> > > > regress anything.
> > > 
> > > Thanks for your explanation!
> > > 
> > > > 
> > > > Patch to convert the io_mapping_map_atomic_wc can indeed come later.
> > > 
> > > Okay, I will also look at this.
> > > 
> > > > 
> > > > In terms of logistics - if we landed this series to out branch it would 
> > > > be queued only for 6.5. Would that work for you?
> > > 
> > > Yeah, it's ok for me. But could I ask, did I miss the 6.4 merge time?
> > 
> > Yes, but just because we failed to review and merge in time, not because you
> > did not provide patches in time.
> 
> It is worth mentioning that under drm we close the merge window earlier.
> Around -rc5.
> 
> So, Linus' merge window for 6.4 didn't happen yet. But our drm-next that
> is going to be sent there is already closed.
> 
> > 
> > Regards,
> > 
> > Tvrtko
> > 


Re: [PATCH v4 13/17] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-10-18 Thread Christian König

Am 18.10.23 um 17:47 schrieb Mario Limonciello:

On 10/18/2023 08:40, Christian König wrote:



Am 18.10.23 um 11:28 schrieb Shyam Sundar S K:


On 10/18/2023 2:50 PM, Ilpo Järvinen wrote:

On Wed, 18 Oct 2023, Shyam Sundar S K wrote:

In order to provide GPU inputs to TA for the Smart PC solution to 
work, we

need to have interface between the PMF driver and the AMDGPU driver.

Add the initial code path for get interface from AMDGPU.

Co-developed-by: Mario Limonciello 
Signed-off-by: Mario Limonciello 
Signed-off-by: Shyam Sundar S K 
---
  drivers/gpu/drm/amd/amdgpu/Makefile |   2 +
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c | 138 


  drivers/platform/x86/amd/pmf/Kconfig    |   1 +
  drivers/platform/x86/amd/pmf/core.c |   1 +
  drivers/platform/x86/amd/pmf/pmf.h  |   3 +
  drivers/platform/x86/amd/pmf/spc.c  |  13 +++
  drivers/platform/x86/amd/pmf/tee-if.c   |  26 +
  include/linux/amd-pmf-io.h  |  35 ++
  9 files changed, 220 insertions(+)
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
  create mode 100644 include/linux/amd-pmf-io.h

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile

index 384b798a9bad..7fafccefbd7a 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -86,6 +86,8 @@ amdgpu-$(CONFIG_PROC_FS) += amdgpu_fdinfo.o
  amdgpu-$(CONFIG_PERF_EVENTS) += amdgpu_pmu.o
+amdgpu-$(CONFIG_AMD_PMF) += amdgpu_pmf.o
+
  # add asic specific block
  amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o \
  dce_v8_0.o gfx_v7_0.o cik_sdma.o uvd_v4_2.o vce_v2_0.o
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h

index a79d53bdbe13..26ffa1b4fe57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -50,6 +50,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c

new file mode 100644
index ..ac981848df50
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright 2023 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person 
obtaining a
+ * copy of this software and associated documentation files (the 
"Software"),
+ * to deal in the Software without restriction, including without 
limitation
+ * the rights to use, copy, modify, merge, publish, distribute, 
sublicense,
+ * and/or sell copies of the Software, and to permit persons to 
whom the
+ * Software is furnished to do so, subject to the following 
conditions:

+ *
+ * The above copyright notice and this permission notice shall be 
included in

+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY 
KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO 
EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, 
DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR 
OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE 
USE OR

+ * OTHER DEALINGS IN THE SOFTWARE.
This is MIT, right? Add the required SPDX-License-Identifier line 
for it

at the top of the file, thank you.


all the files in drivers/gpu/drm/amd/amdgpu/* carry the same license
text. So, have retained it to maintain uniformity.


Please add the SPDX License Identifier for any file you add.

Apart from that the whole approach of attaching this directly to 
amdgpu looks extremely questionable to me.




What's the long term outlook for things that are needed directly from 
amdgpu?  Is there going to be more besides the backlight and the 
display count/type?


Yeah, that goes into the same direction as my concern.



At least for the display count I suppose one way that it could be 
"decoupled" from amdgpu is to use drm_for_each_connector_iter to 
iterate all the connectors and then count the connected ones.


And what if the number of connected displays change? How is amdgpu 
supposed to signal events like that?


This whole solution doesn't looks well thought through.

Regards,
Christian.




Regards,
Christian.




+ *
+ * Author: Shyam Sundar S K 
+ *
+ */

Remove the extra empty line at the end of the comment.


I just took the standard template for all the gpu files. Is that OK to
retain the blank line?

If not, I can remove it in the next version.

Rest all remarks I will address.

Thanks,
Shyam


+
+#include 
+#include "amdgpu.h"
+
+int amd_pmf_get_gfx_data(struct amd_gpu_pmf_data *pmf)
+{
+    struct drm_device *drm_dev = pci_get_drvdata(pmf->gpu_dev);
+    struct drm_mode_config *mode_config = _dev->mode_config;
+    struct amdgpu_device *adev = drm_to_adev(drm_dev);
+    

Re: [PATCH v4 13/17] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-10-18 Thread Mario Limonciello

On 10/18/2023 08:40, Christian König wrote:



Am 18.10.23 um 11:28 schrieb Shyam Sundar S K:


On 10/18/2023 2:50 PM, Ilpo Järvinen wrote:

On Wed, 18 Oct 2023, Shyam Sundar S K wrote:

In order to provide GPU inputs to TA for the Smart PC solution to 
work, we

need to have interface between the PMF driver and the AMDGPU driver.

Add the initial code path for get interface from AMDGPU.

Co-developed-by: Mario Limonciello 
Signed-off-by: Mario Limonciello 
Signed-off-by: Shyam Sundar S K 
---
  drivers/gpu/drm/amd/amdgpu/Makefile |   2 +
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c | 138 


  drivers/platform/x86/amd/pmf/Kconfig    |   1 +
  drivers/platform/x86/amd/pmf/core.c |   1 +
  drivers/platform/x86/amd/pmf/pmf.h  |   3 +
  drivers/platform/x86/amd/pmf/spc.c  |  13 +++
  drivers/platform/x86/amd/pmf/tee-if.c   |  26 +
  include/linux/amd-pmf-io.h  |  35 ++
  9 files changed, 220 insertions(+)
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
  create mode 100644 include/linux/amd-pmf-io.h

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile

index 384b798a9bad..7fafccefbd7a 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -86,6 +86,8 @@ amdgpu-$(CONFIG_PROC_FS) += amdgpu_fdinfo.o
  amdgpu-$(CONFIG_PERF_EVENTS) += amdgpu_pmu.o
+amdgpu-$(CONFIG_AMD_PMF) += amdgpu_pmf.o
+
  # add asic specific block
  amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o \
  dce_v8_0.o gfx_v7_0.o cik_sdma.o uvd_v4_2.o vce_v2_0.o
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h

index a79d53bdbe13..26ffa1b4fe57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -50,6 +50,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c

new file mode 100644
index ..ac981848df50
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright 2023 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person 
obtaining a
+ * copy of this software and associated documentation files (the 
"Software"),
+ * to deal in the Software without restriction, including without 
limitation
+ * the rights to use, copy, modify, merge, publish, distribute, 
sublicense,
+ * and/or sell copies of the Software, and to permit persons to 
whom the
+ * Software is furnished to do so, subject to the following 
conditions:

+ *
+ * The above copyright notice and this permission notice shall be 
included in

+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO 
EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, 
DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR 
OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE 
USE OR

+ * OTHER DEALINGS IN THE SOFTWARE.

This is MIT, right? Add the required SPDX-License-Identifier line for it
at the top of the file, thank you.


all the files in drivers/gpu/drm/amd/amdgpu/* carry the same license
text. So, have retained it to maintain uniformity.


Please add the SPDX License Identifier for any file you add.

Apart from that the whole approach of attaching this directly to amdgpu 
looks extremely questionable to me.




What's the long term outlook for things that are needed directly from 
amdgpu?  Is there going to be more besides the backlight and the display 
count/type?


At least for the display count I suppose one way that it could be 
"decoupled" from amdgpu is to use drm_for_each_connector_iter to iterate 
all the connectors and then count the connected ones.



Regards,
Christian.




+ *
+ * Author: Shyam Sundar S K 
+ *
+ */

Remove the extra empty line at the end of the comment.


I just took the standard template for all the gpu files. Is that OK to
retain the blank line?

If not, I can remove it in the next version.

Rest all remarks I will address.

Thanks,
Shyam


+
+#include 
+#include "amdgpu.h"
+
+int amd_pmf_get_gfx_data(struct amd_gpu_pmf_data *pmf)
+{
+    struct drm_device *drm_dev = pci_get_drvdata(pmf->gpu_dev);
+    struct drm_mode_config *mode_config = _dev->mode_config;
+    struct amdgpu_device *adev = drm_to_adev(drm_dev);
+    struct drm_connector_list_iter iter;
+    struct drm_connector *connector;
+    int i = 0;
+
+    /* Reset the count to zero */
+    pmf->display_count = 0;
+    if (!(adev->flags & AMD_IS_APU)) {
+    DRM_ERROR("PMF-AMDGPU interface not supported\n");
+    return -ENODEV;
+    }
+
+    

Re: [PATCH 1/1] drm/panel: st7703: Pick different reset sequence

2023-10-18 Thread Chris Morgan
On Sun, Oct 15, 2023 at 02:49:20PM +0200, Guido Günther wrote:
> Hi,
> On Sat, Feb 11, 2023 at 06:17:48PM +0100, Frank Oltmanns wrote:
> > From: Ondrej Jirman 
> > 
> > Switching to a different reset sequence, enabling IOVCC before enabling
> > VCC.
> > 
> > There also needs to be a delay after enabling the supplies and before
> > deasserting the reset. The datasheet specifies 1ms after the supplies
> > reach the required voltage. Use 10-20ms to also give the power supplies
> > some time to reach the required voltage, too.
> > 
> > This fixes intermittent panel initialization failures and screen
> > corruption during resume from sleep on panel xingbangda,xbd599 (e.g.
> > used in PinePhone).
> 
> Thanks, applied to drm-misc-next.
> Cheers,
>  -- Guido

Thank you. Probably too late, but this fixes problems I have with a
different ST7703 based panel.

Tested-by: Chris Morgan 

> 
> > 
> > Signed-off-by: Ondrej Jirman 
> > Signed-off-by: Frank Oltmanns 
> > Reported-by: Samuel Holland 
> > ---
> >  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 25 ++-
> >  1 file changed, 13 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
> > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > index 6747ca237ced..45695aa51f62 100644
> > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > @@ -411,29 +411,30 @@ static int st7703_prepare(struct drm_panel *panel)
> > return 0;
> >  
> > dev_dbg(ctx->dev, "Resetting the panel\n");
> > -   ret = regulator_enable(ctx->vcc);
> > +   gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> > +
> > +   ret = regulator_enable(ctx->iovcc);
> > if (ret < 0) {
> > -   dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> > +   dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
> > return ret;
> > }
> > -   ret = regulator_enable(ctx->iovcc);
> > +
> > +   ret = regulator_enable(ctx->vcc);
> > if (ret < 0) {
> > -   dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
> > -   goto disable_vcc;
> > +   dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> > +   regulator_disable(ctx->iovcc);
> > +   return ret;
> > }
> >  
> > -   gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> > -   usleep_range(20, 40);
> > +   /* Give power supplies time to stabilize before deasserting reset. */
> > +   usleep_range(1, 2);
> > +
> > gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> > -   msleep(20);
> > +   usleep_range(15000, 2);
> >  
> > ctx->prepared = true;
> >  
> > return 0;
> > -
> > -disable_vcc:
> > -   regulator_disable(ctx->vcc);
> > -   return ret;
> >  }
> >  
> >  static const u32 mantix_bus_formats[] = {
> > -- 
> > 2.39.1
> > 


[pull] drm/msm: drm-msm-next-2023-10-17 for v6.7 (resend)

2023-10-18 Thread Rob Clark
Hi Dave,

(resend as I missed dri-devel@ the first time)

This is the pull for v6.7, see below for description.  There are some
conflicts with drm-next and mm trees.  The resolution in linux-next
looks correct.  Also, just in case, I've pushed the drm-next merge
resolution to msm-next-merge-resolution branch in the same tree.  (And
can do the same for mm if needed.)  Ping me if any questions.


The following changes since commit 10f20628c9b8e924b8046e63b36b2cea4d2c85e4:

  drm/msm/dpu: fail dpu_plane_atomic_check() based on mdp clk limits
(2023-10-05 10:18:10 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-next-2023-10-17

for you to fetch changes up to b08d26dac1a1075c874f40ee02ec8ddc39e20146:

  drm/msm/a7xx: actually use a7xx state registers (2023-10-16 09:38:56 -0700)


Updates for v6.7

DP:
- use existing helpers for DPCD handling instead of open-coded functions
- set the subconnector type according to the plugged cable / dongle
  skip validity check for DP CTS EDID checksum

DPU:
- continued migration of feature flags to use core revision checks
- reworked interrupts code to use '0' as NO_IRQ, removed raw IRQ indices
  from log / trace output

gpu:
- a7xx support (a730, a740)
- fixes and additional speedbins for a635, a643

core:
- decouple msm_drv from kms to more cleanly support headless devices (like
  imx5+a2xx)


Dmitry Baryshkov (40):
  drm/msm/dpu: remove irq_idx argument from IRQ callbacks
  drm/msm/dpu: extract dpu_core_irq_is_valid() helper
  drm/msm/dpu: add helper to get IRQ-related data
  drm/msm/dpu: make the irq table size static
  drm/msm/dpu: stop using raw IRQ indices in the kernel output
  drm/msm/dpu: stop using raw IRQ indices in the kernel traces
  drm/msm/dpu: shift IRQ indices by 1
  drm/msm/dpu: inline _setup_pingpong_ops()
  drm/msm/dpu: enable PINGPONG TE operations only when supported by HW
  drm/msm/dpu: drop the DPU_PINGPONG_TE flag
  drm/msm/dpu: inline _setup_intf_ops()
  drm/msm/dpu: enable INTF TE operations only when supported by HW
  drm/msm/dpu: drop DPU_INTF_TE feature flag
  drm/msm/dpu: drop useless check from dpu_encoder_phys_cmd_te_rd_ptr_irq()
  drm/msm/dpu: move INTF tearing checks to dpu_encoder_phys_cmd_init
  drm/msm/dp: support setting the DP subconnector type
  drm/msm: allow passing struct msm_kms to msm_drv_probe()
  drm/msm/dpu: move resource allocation to the _probe function
  drm/msm/mdp4: move resource allocation to the _probe function
  drm/msm/mdp5: move resource allocation to the _probe function
  drm/msm/dsi: switch to devm_drm_bridge_add()
  drm/msm/hdmi: switch to devm_drm_bridge_add()
  drm/msm/dp: move pdev from struct dp_display_private to struct msm_dp
  drm/msm/dp: switch to devm_drm_bridge_add()
  drm/msm: remove msm_drm_private::bridges field
  drm/msm: drop pm ops from the headless msm driver
  drm/msm: rename msm_pm_prepare/complete to note the KMS nature
  drm/msm: remove shutdown callback from msm_platform_driver
  drm/msm: rename msm_drv_shutdown() to msm_kms_shutdown()
  drm/msm: switch to drmm_mode_config_init()
  drm/msm: only register 'kms' debug file if KMS is used
  drm/msm: make fb debugfs file available only in KMS case
  drm/msm: carve out KMS code from msm_drv.c
  drm/msm: fix fault injection support
  drm/msm/dsi: use correct lifetime device for devm_drm_bridge_add
  drm/msm/hdmi: use correct lifetime device for devm_drm_bridge_add
  drm/msm/dp: use correct lifetime device for devm_drm_bridge_add
  drm/msm/dsi: use msm_gem_kernel_put to free TX buffer
  drm/msm/dsi: free TX buffer in unbind
  drm/msm/a7xx: actually use a7xx state registers

Jani Nikula (1):
  drm/msm/dp: skip validity check for DP CTS EDID checksum

Jessica Zhang (4):
  drm/msm/dpu: Move setting of dpu_enc::wide_bus_en to atomic enable()
  drm/msm/dpu: Enable widebus for DSI INTF
  drm/msm/dsi: Add DATABUS_WIDEN MDP_CTRL2 bit
  drm/msm/dsi: Enable widebus for DSI

Konrad Dybcio (15):
  dt-bindings: display/msm/gmu: Add Adreno 7[34]0 GMU
  dt-bindings: display/msm/gmu: Allow passing QMP handle
  dt-bindings: display/msm/gpu: Allow A7xx SKUs
  drm/msm/a6xx: Add missing regs for A7XX
  drm/msm/a6xx: Add skeleton A7xx support
  drm/msm/a6xx: Send ACD state to QMP at GMU resume
  drm/msm/a6xx: Mostly implement A7xx gpu_state
  drm/msm/a6xx: Add A730 support
  drm/msm/a6xx: Add A740 support
  drm/msm/a6xx: Poll for GBIF unhalt status in hw_init
  drm/msm/adreno: Fix SM6375 GPU ID
  drm/msm/a6xx: Fix unknown speedbin case
  drm/msm/adreno: Add ZAP firmware name to A635
  drm/msm/adreno: Add A635 speedbin 0xac (A643)
  drm/msm/a6xx: Fix up 

Re: [PATCH] drm/nouveau: Fixing indentation and adding License Identifier tag

2023-10-18 Thread Bragatheswaran Manickavel



On 08/10/23 22:57, Bragatheswaran Manickavel wrote:

On running checkpatch.pl to nouveau_drm.h identified
few warnings. Fixing them in this patch

WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
+/*

WARNING: space prohibited between function name and open parenthesis '('
+#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE   DRM_IOW (DRM_COMMAND_BASE +
DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)

Signed-off-by: Bragatheswaran Manickavel 
---
  include/uapi/drm/nouveau_drm.h | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 8d7402c13e56..900ca4f1ebe5 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: MIT */
  /*
   * Copyright 2005 Stephane Marchesin.
   * All Rights Reserved.
@@ -448,15 +449,15 @@ struct drm_nouveau_svm_bind {
  
  #define DRM_IOCTL_NOUVEAU_GETPARAM   DRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_GETPARAM, struct drm_nouveau_getparam)

  #define DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_CHANNEL_ALLOC, struct drm_nouveau_channel_alloc)
-#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE   DRM_IOW (DRM_COMMAND_BASE + 
DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)
+#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE   DRM_IOW(DRM_COMMAND_BASE + 
DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)
  
  #define DRM_IOCTL_NOUVEAU_SVM_INIT   DRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_SVM_INIT, struct drm_nouveau_svm_init)

  #define DRM_IOCTL_NOUVEAU_SVM_BIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_SVM_BIND, struct drm_nouveau_svm_bind)
  
  #define DRM_IOCTL_NOUVEAU_GEM_NEWDRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_NEW, struct drm_nouveau_gem_new)

  #define DRM_IOCTL_NOUVEAU_GEM_PUSHBUFDRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_PUSHBUF, struct drm_nouveau_gem_pushbuf)
-#define DRM_IOCTL_NOUVEAU_GEM_CPU_PREP   DRM_IOW (DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_PREP, struct drm_nouveau_gem_cpu_prep)
-#define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI   DRM_IOW (DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_FINI, struct drm_nouveau_gem_cpu_fini)
+#define DRM_IOCTL_NOUVEAU_GEM_CPU_PREP   DRM_IOW(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_PREP, struct drm_nouveau_gem_cpu_prep)
+#define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI   DRM_IOW(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_FINI, struct drm_nouveau_gem_cpu_fini)
  #define DRM_IOCTL_NOUVEAU_GEM_INFO   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_INFO, struct drm_nouveau_gem_info)
  
  #define DRM_IOCTL_NOUVEAU_VM_INITDRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_VM_INIT, struct drm_nouveau_vm_init)


A Gentle remainder. Can someone please help in reviewing these changes ?

Thanks,
Bragathe



[bug report] drm: Warn about negative sizes when calculating scale factor

2023-10-18 Thread Dan Carpenter
drivers/gpu/drm/drm_rect.c
   134  static int drm_calc_scale(int src, int dst)
   135  {
   136  int scale = 0;
   137  
   138  if (WARN_ON(src < 0 || dst < 0))
^^^
These days, with automated fuzz testing, this WARN_ON() is problematic.
WARN() is considered a kernel bug, and pr_warn() is the hip new way to
alert the user about issues.

It should probably pr_warn_once() because this is easy to trigger.
There is a kunit test which triggers it:
drivers/gpu/drm/tests/drm_rect_test.c

Reported-by: Linux Kernel Functional Testing 

   139  return -EINVAL;
   140  
   141  if (dst == 0)
   142  return 0;
   143  
   144  if (src > (dst << 16))
   145  return DIV_ROUND_UP(src, dst);
   146  else
   147  scale = src / dst;
   148  
   149  return scale;
   150  }

The stack trace is:

[ 1297.757480] WARNING: CPU: 0 PID: 1555 at drivers/gpu/drm/drm_rect.c:138 
drm_rect_calc_hscale+0xcc/0xd8
[ 1297.758551] Modules linked in:
[ 1297.759247] CPU: 0 PID: 1555 Comm: kunit_try_catch Tainted: GB   
 N 6.5.1-rc1 #1
[ 1297.760085] Hardware name: Generic DT based system
[ 1297.760619]  unwind_backtrace from show_stack+0x18/0x1c
[ 1297.761257]  show_stack from dump_stack_lvl+0x58/0x70
[ 1297.761936]  dump_stack_lvl from __warn+0xa8/0x180
[ 1297.762536]  __warn from warn_slowpath_fmt+0x110/0x1dc
[ 1297.762901]  warn_slowpath_fmt from drm_rect_calc_hscale+0xcc/0xd8
[ 1297.763241]  drm_rect_calc_hscale from drm_test_rect_calc_hscale+0xb0/0x150
[ 1297.763608]  drm_test_rect_calc_hscale from 
kunit_generic_run_threadfn_adapter+0x2c/0x48
[ 1297.764020]  kunit_generic_run_threadfn_adapter from kthread+0x184/0x1a8
[ 1297.764384]  kthread from ret_from_fork+0x14/0x2c
[ 1297.764812] Exception stack(0xfa41bfb0 to 0xfa41bff8)
[ 1297.765470] bfa0:   
 
[ 1297.767825] bfc0:       
 
[ 1297.768452] bfe0:     0013 
[ 1297.769652] ---[ end trace  ]---

regards,
dan carpenter


Re: [PATCH v3] drm/i915: Flush WC GGTT only on required platforms

2023-10-18 Thread Nirmoy Das



On 10/18/2023 3:00 PM, Andi Shyti wrote:

Hi Nirmoy,


gen8_ggtt_invalidate() is only needed for limited set of platforms
where GGTT is mapped as WC. This was added as way to fix WC based GGTT in
commit 0f9b91c754b7 ("drm/i915: flush system agent TLBs on SNB") and
there are no reference in HW docs that forces us to use this on non-WC
backed GGTT.

This can also cause unwanted side-effects on XE_HP platforms where
GFX_FLSH_CNTL_GEN6 is not valid anymore.

v2: Add a func to detect wc ggtt detection (Ville)
v3: Improve commit log and add reference commit (Daniel)

Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")

I'm wondering if this is the right Fixes, though. Should this
rather be:

Fixes: 6266992cf105 ("drm/i915/gt: remove GRAPHICS_VER == 10")

Hard to find a real Fixes for this. I just want to backport this to dg2
where we can have unwanted side-effects.

yes, this piece of code has moved around enough so to make it
diffuclt to track its origin.

I think the one I found should be the correct one,


That just removes a graphics ver, not related to WC GGTT map or XE_HP.


  but the dg2
force probe removeal can also become a placeholder for DG2 fixes.


Yes, I have no better ideas too.


Regards,

Nirmoy



I won't complain.

Andi


Re: [PATCH -next] drm/amd/display: Simplify bool conversion

2023-10-18 Thread Alex Deucher
Applied.  Thanks!

On Tue, Oct 17, 2023 at 9:22 PM Yang Li  wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c:4802:84-89: 
> WARNING: conversion to bool not needed here
>
> Reported-by: Abaci Robot 
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6901
> Signed-off-by: Yang Li 
> ---
>  drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c 
> b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
> index 851db026f251..3296c078ff3e 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
> @@ -4799,7 +4799,7 @@ static void CalculateSurfaceSizeInMall(
> if (UseMALLForStaticScreen[k] == 
> dml_use_mall_static_screen_enable)
> TotalSurfaceSizeInMALL = TotalSurfaceSizeInMALL + 
> SurfaceSizeInMALL[k];
> }
> -   *ExceededMALLSize = (TotalSurfaceSizeInMALL <= MALLAllocatedForDCN * 
> 1024 * 1024 ? false : true);
> +   *ExceededMALLSize = (TotalSurfaceSizeInMALL > MALLAllocatedForDCN * 
> 1024 * 1024);
>  } // CalculateSurfaceSizeInMall
>
>  static void CalculateDETBufferSize(
> --
> 2.20.1.7.g153144c
>


Re: [PATCH -next] drm/amd/display: Remove unneeded semicolon

2023-10-18 Thread Alex Deucher
Applied.  Thanks!

On Tue, Oct 17, 2023 at 9:16 PM Yang Li  wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c:464:3-4: 
> Unneeded semicolon
>
> Reported-by: Abaci Robot 
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6900
> Signed-off-by: Yang Li 
> ---
>  drivers/gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c 
> b/drivers/gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c
> index 36baf35bb170..f45fbe820445 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c
> @@ -461,7 +461,7 @@ static void sort_pipes_for_splitting(struct 
> dc_plane_pipe_pool *pipes)
> swapped = false;
> }
>
> -   };
> +   }
> }
>  }
>
> --
> 2.20.1.7.g153144c
>


[GIT PULL] mediatek drm next for 6.7

2023-10-18 Thread Chun-Kuang Hu
Hi, Dave & Daniel:

This includes:

1. Add support MT8188 dsi function
2. Fix coverity issue with unintentional integer overflow
3. Add support MT8188 dp/edp function
4. Fix memory leak on ->get_edid callback audio detection
   and error path.
5. Add connector dynamic selection capability
6. MediaTek DDP GAMMA - 12-bit LUT support
7. mtk_dsi: Fix NO_EOT_PACKET settings/handling

Regards,
Chun-Kuang.

The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:

  Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git 
tags/mediatek-drm-next-6.7

for you to fetch changes up to 5855d422a6f250f3518f43b49092c8e87a5e42be:

  drm: mediatek: mtk_dsi: Fix NO_EOT_PACKET settings/handling (2023-10-18 
13:18:22 +)


Mediatek DRM Next for Linux 6.7

1. Add support MT8188 dsi function
2. Fix coverity issue with unintentional integer overflow
3. Add support MT8188 dp/edp function
4. Fix memory leak on ->get_edid callback audio detection
   and error path.
5. Add connector dynamic selection capability
6. MediaTek DDP GAMMA - 12-bit LUT support
7. mtk_dsi: Fix NO_EOT_PACKET settings/handling


AngeloGioacchino Del Regno (16):
  drm/mediatek: gamma: Reduce indentation in mtk_gamma_set_common()
  drm/mediatek: gamma: Support SoC specific LUT size
  drm/mediatek: gamma: Improve and simplify HW LUT calculation
  drm/mediatek: gamma: Enable the Gamma LUT table only after programming
  drm/mediatek: gamma: Use bitfield macros
  drm/mediatek: aal: Use bitfield macros
  drm/mediatek: De-commonize disp_aal/disp_gamma gamma_set functions
  drm/mediatek: gamma: Support multi-bank gamma LUT
  drm/mediatek: gamma: Add support for 12-bit LUT
  drm/mediatek: gamma: Add support for MT8195
  drm/mediatek: gamma: Make sure relay mode is disabled
  drm/mediatek: gamma: Program gamma LUT type for descending or rising
  drm/mediatek: aal: Add kerneldoc for struct mtk_disp_aal
  drm/mediatek: gamma: Add kerneldoc for struct mtk_disp_gamma
  drm/mediatek: aal: Compress of_device_id entries and add sentinel
  drm: mediatek: mtk_dsi: Fix NO_EOT_PACKET settings/handling

Jani Nikula (2):
  drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection
  drm/mediatek/dp: fix memory leak on ->get_edid callback error path

Jason-JH.Lin (12):
  drm/mediatek: Fix coverity issue with unintentional integer overflow
  drm/mediatek: Add mmsys_dev_num to mt8188 vdosys0 driver data
  drm/mediatek: Add crtc path enum for all_drm_priv array
  drm/mediatek: Fix using wrong drm private data to bind mediatek-drm
  drm/mediatek: Add encoder_index interface for mtk_ddp_comp_funcs
  drm/mediatek: Add connector dynamic selection capability
  drm/mediatek: dpi: Support dynamic connector selection
  drm/mediatek: dsi: Support dynamic connector selection
  drm/mediatek: Support dynamic selection of MT8188 VDOSYS0
  drm/mediatek: Fix iommu fault by swapping FBs after updating plane state
  drm/mediatek: Fix iommu fault during crtc enabling
  drm/mediatek: gamma: Adjust mtk_drm_gamma_set_common parameters

Shuijing Li (8):
  dt-bindings: display: mediatek: dsi: Add compatible for MediaTek MT8188
  drm/mediatek: dsi: Add dsi cmdq_ctl to send panel initial code
  drm/mediatek: Add mt8188 dsi compatible to mtk_dsi.c
  dt-bindings: display: mediatek: dp: Add compatible for MediaTek MT8188
  drm/mediatek: dp: Add the audio packet flag to mtk_dp_data struct
  drm/mediatek: dp: Add the audio divider to mtk_dp_data struct
  drm/mediatek: dp: Add support MT8188 dp/edp function
  drm/mediatek: dsi: Add mode_valid callback to DSI bridge

 .../bindings/display/mediatek/mediatek,dp.yaml |   2 +
 .../bindings/display/mediatek/mediatek,dsi.yaml|   1 +
 drivers/gpu/drm/mediatek/mtk_disp_aal.c|  86 -
 drivers/gpu/drm/mediatek/mtk_disp_drv.h|   5 +-
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c  | 203 +
 drivers/gpu/drm/mediatek/mtk_dp.c  |  42 -
 drivers/gpu/drm/mediatek/mtk_dp_reg.h  |  23 ++-
 drivers/gpu/drm/mediatek/mtk_dpi.c |   9 +
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  83 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h|   6 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c|  34 +++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h|  17 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  47 -
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |  15 +-
 drivers/gpu/drm/mediatek/mtk_drm_gem.c |   9 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c   |  41 -
 drivers/gpu/drm/mediatek/mtk_dsi.c 

Re: [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context

2023-10-18 Thread Hans de Goede
Hi Sean,

On 10/17/23 11:17, Sean Young wrote:
> Some drivers require sleeping, for example if the pwm device is connected
> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
> with the generated IR signal when sleeping occurs.
> 
> This patch makes it possible to use pwm when the driver does not sleep,
> by introducing the pwm_can_sleep() function.
> 
> Signed-off-by: Sean Young 

I have no objection to this patch by itself, but it seems a bit
of unnecessary churn to change all current callers of pwm_apply_state()
to a new API.

Why not just keep pwm_apply_state() as is and introduce a new
pwm_apply_state_atomic() for callers which want to apply state
in a case where sleeping is not allowed ?

Regards,

Hans



> ---
>  Documentation/driver-api/pwm.rst  | 16 +++-
>  .../gpu/drm/i915/display/intel_backlight.c|  6 +-
>  drivers/gpu/drm/solomon/ssd130x.c |  2 +-
>  drivers/hwmon/pwm-fan.c   |  8 +-
>  drivers/input/misc/da7280.c   |  4 +-
>  drivers/input/misc/pwm-beeper.c   |  4 +-
>  drivers/input/misc/pwm-vibra.c|  8 +-
>  drivers/leds/leds-pwm.c   |  2 +-
>  drivers/leds/rgb/leds-pwm-multicolor.c|  4 +-
>  drivers/media/rc/pwm-ir-tx.c  |  4 +-
>  drivers/platform/x86/lenovo-yogabook.c|  2 +-
>  drivers/pwm/core.c| 75 ++-
>  drivers/pwm/pwm-renesas-tpu.c |  1 -
>  drivers/pwm/pwm-twl-led.c |  2 +-
>  drivers/pwm/pwm-vt8500.c  |  2 +-
>  drivers/pwm/sysfs.c   | 10 +--
>  drivers/regulator/pwm-regulator.c |  4 +-
>  drivers/video/backlight/lm3630a_bl.c  |  2 +-
>  drivers/video/backlight/lp855x_bl.c   |  2 +-
>  drivers/video/backlight/pwm_bl.c  |  6 +-
>  drivers/video/fbdev/ssd1307fb.c   |  2 +-
>  include/linux/pwm.h   | 57 ++
>  22 files changed, 147 insertions(+), 76 deletions(-)
> 
> diff --git a/Documentation/driver-api/pwm.rst 
> b/Documentation/driver-api/pwm.rst
> index 3fdc95f7a1d15..a2fb5f8f6e1f8 100644
> --- a/Documentation/driver-api/pwm.rst
> +++ b/Documentation/driver-api/pwm.rst
> @@ -41,7 +41,15 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also 
> exist.
>  
>  After being requested, a PWM has to be configured using::
>  
> - int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
> + int pwm_apply_cansleep(struct pwm_device *pwm, struct pwm_state *state);
> +
> +If the PWM support atomic mode, which can be determined with::
> +
> +bool pwm_is_atomic(struct pwm_device *pwm);
> +
> +Then the PWM can be configured with::
> +
> + int pwm_apply(struct pwm_device *pwm, struct pwm_state *state);
>  
>  This API controls both the PWM period/duty_cycle config and the
>  enable/disable state.
> @@ -57,13 +65,13 @@ If supported by the driver, the signal can be optimized, 
> for example to improve
>  EMI by phase shifting the individual channels of a chip.
>  
>  The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
> -around pwm_apply_state() and should not be used if the user wants to change
> +around pwm_apply_cansleep() and should not be used if the user wants to 
> change
>  several parameter at once. For example, if you see pwm_config() and
>  pwm_{enable,disable}() calls in the same function, this probably means you
> -should switch to pwm_apply_state().
> +should switch to pwm_apply_cansleep().
>  
>  The PWM user API also allows one to query the PWM state that was passed to 
> the
> -last invocation of pwm_apply_state() using pwm_get_state(). Note this is
> +last invocation of pwm_apply_cansleep() using pwm_get_state(). Note this is
>  different to what the driver has actually implemented if the request cannot 
> be
>  satisfied exactly with the hardware in use. There is currently no way for
>  consumers to get the actually implemented settings.
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 2e8f17c045222..cf516190cde8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -274,7 +274,7 @@ static void ext_pwm_set_backlight(const struct 
> drm_connector_state *conn_state,
>   struct intel_panel *panel = 
> _intel_connector(conn_state->connector)->panel;
>  
>   pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
> - pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
> + pwm_apply_cansleep(panel->backlight.pwm, >backlight.pwm_state);
>  }
>  
>  static void
> @@ -427,7 +427,7 @@ static void ext_pwm_disable_backlight(const struct 
> drm_connector_state *old_conn
>   intel_backlight_set_pwm_level(old_conn_state, level);
>  
>   panel->backlight.pwm_state.enabled = 

Re: [PATCH -next] drm/amd/display: Remove duplicated include in dce110_hwseq.c

2023-10-18 Thread Alex Deucher
Applied.  Thanks!

On Tue, Oct 17, 2023 at 9:02 PM Yang Li  wrote:
>
> ./drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c: dce110_hwseq.h 
> is included more than once.
>
> Reported-by: Abaci Robot 
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6897
> Signed-off-by: Yang Li 
> ---
>  drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c 
> b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
> index 74602a5fd6dd..51e42cbb3cdb 100644
> --- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
> +++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
> @@ -65,8 +65,6 @@
>
>  #include "dcn10/dcn10_hwseq.h"
>
> -#include "dce110_hwseq.h"
> -
>  #define GAMMA_HW_POINTS_NUM 256
>
>  /*
> --
> 2.20.1.7.g153144c
>


  1   2   >