[PATCH] drm/amdgpu: resolve s3 hang for r7340

2022-03-27 Thread Zhenneng Li
This is a workaround for s3 hang for r7340(amdgpu).
When we test s3 with r7340 on arm64 platform, graphics card will hang up,
the error message are as follows:
Mar  4 01:14:11 greatwall-GW-XX-XXX kernel: [1.599374][ 7] [  T291] 
amdgpu :02:00.0: fb0: amdgpudrmfb frame buffer device
Mar  4 01:14:11 greatwall-GW-XX-XXX kernel: [1.612869][ 7] [  T291] 
[drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR* late_init of IP block 
 failed -22
Mar  4 01:14:11 greatwall-GW-XX-XXX kernel: [1.623392][ 7] [  T291] 
amdgpu :02:00.0: amdgpu_device_ip_late_init failed
Mar  4 01:14:11 greatwall-GW-XX-XXX kernel: [1.630696][ 7] [  T291] 
amdgpu :02:00.0: Fatal error during GPU init
Mar  4 01:14:11 greatwall-GW-XX-XXX kernel: [1.637477][ 7] [  T291] 
[drm] amdgpu: finishing device.

Change-Id: I5048b3894c0ca9faf2f4847ddab61f9eb17b4823
Signed-off-by: Zhenneng Li 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 3987ecb24ef4..1eced991b5b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2903,6 +2903,8 @@ static void 
amdgpu_device_delayed_init_work_handler(struct work_struct *work)
container_of(work, struct amdgpu_device, 
delayed_init_work.work);
int r;
 
+   mdelay(1);
+
r = amdgpu_ib_ring_tests(adev);
if (r)
DRM_ERROR("ib ring test failed (%d).\n", r);
-- 
2.25.1



[PATCH] drm/i915: avoid concurrent writes to aux_inv

2022-03-27 Thread fei . yang
From: Fei Yang 

GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With the MMIO remap feature, we can actually set bit 17 of MI_LRI
instruction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.

Bspec: 45728

v2: Invalidate AUX table for indirect context as well.

Cc: Stuart Summers 
Cc: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Signed-off-by: Fei Yang 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 48 
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h |  4 +-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 12 +
 4 files changed, 26 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 36148887c699..8178be083b42 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -6,7 +6,6 @@
 #include "gen8_engine_cs.h"
 #include "i915_drv.h"
 #include "intel_gpu_commands.h"
-#include "intel_gt_regs.h"
 #include "intel_lrc.h"
 #include "intel_ring.h"
 
@@ -165,33 +164,9 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
 }
 
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
+u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
 {
-   static const i915_reg_t vd[] = {
-   GEN12_VD0_AUX_NV,
-   GEN12_VD1_AUX_NV,
-   GEN12_VD2_AUX_NV,
-   GEN12_VD3_AUX_NV,
-   };
-
-   static const i915_reg_t ve[] = {
-   GEN12_VE0_AUX_NV,
-   GEN12_VE1_AUX_NV,
-   };
-
-   if (engine->class == VIDEO_DECODE_CLASS)
-   return vd[engine->instance];
-
-   if (engine->class == VIDEO_ENHANCEMENT_CLASS)
-   return ve[engine->instance];
-
-   GEM_BUG_ON("unknown aux_inv reg\n");
-   return INVALID_MMIO_REG;
-}
-
-static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
-{
-   *cs++ = MI_LOAD_REGISTER_IMM(1);
+   *cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg);
*cs++ = AUX_INV;
*cs++ = MI_NOOP;
@@ -293,10 +268,12 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
if (mode & EMIT_INVALIDATE) {
cmd += 2;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915)) {
+   if (!HAS_FLAT_CCS(rq->engine->i915) &&
+   (rq->engine->class == VIDEO_DECODE_CLASS ||
+rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
aux_inv = rq->engine->mask & ~BIT(BCS0);
if (aux_inv)
-   cmd += 2 * hweight32(aux_inv) + 2;
+   cmd += 4;
}
}
 
@@ -329,15 +306,10 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
*cs++ = 0; /* value */
 
if (aux_inv) { /* hsdes: 1809175790 */
-   struct intel_engine_cs *engine;
-   unsigned int tmp;
-
-   *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
-   for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
-   *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
-   *cs++ = AUX_INV;
-   }
-   *cs++ = MI_NOOP;
+   if (rq->engine->class == VIDEO_DECODE_CLASS)
+   cs = gen12_emit_aux_table_inv(GEN12_VD0_AUX_NV, cs);
+   else
+   cs = gen12_emit_aux_table_inv(GEN12_VE0_AUX_NV, cs);
}
 
if (mode & EMIT_INVALIDATE)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index cc6e21d3662a..94f589e73d10 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -10,7 +10,7 @@
 #include 
 
 #include "i915_gem.h" /* GEM_BUG_ON */
-
+#include "intel_gt_regs.h"
 #include "intel_gpu_commands.h"
 
 struct i915_request;
@@ -38,6 +38,8 @@ u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *rq, 
u32 *cs);
 u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs);
 u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs);
 
+u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs);
+
 static inline u32 *
 __gen8_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, u32 offset)
 {
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 

[PATCH v13 6/6] MAINTAINERS: add maintainers for DRM LSDC driver

2022-03-27 Thread Sui Jingfeng
 This patch add myself as maintainer

 My company email is 
 my personal email is <15330273...@189.cn>

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 10476280acb8..21184d8577f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6487,6 +6487,15 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: drivers/gpu/drm/lima/
 F: include/uapi/drm/lima_drm.h
 
+DRM DRIVERS FOR LOONGSON
+M: suijingfeng 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+W: https://www.loongson.cn/
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/loongson/
+F: drivers/gpu/drm/loongson/
+
 DRM DRIVERS FOR MEDIATEK
 M: Chun-Kuang Hu 
 M: Philipp Zabel 
-- 
2.25.1



[PATCH v13 5/6] drm/loongson: add drm driver for loongson display controller

2022-03-27 Thread Sui Jingfeng
There is a display controller in loongson's LS2K1000 SoC and LS7A1000
bridge chip, the display controller is a PCI device in those chips. It
has two display pipes but with only one hardware cursor. Each way has
a DVO interface which provide RGB888 signals, vertical & horizontal
synchronisations, data enable and the pixel clock. Each CRTC is able to
scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
2048x2048 according to the hardware spec. Loongson display controllers
are simple which require scanout buffers to be physically contiguous.

For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
which is typically 64MB or more. In this case, VRAM helper based driver
is intend to be used even through the DC can scanout form system memory.

While LS2K1000 is a SoC which is a typically UMA device, only system
memory is available. Therefore CMA helper based driver is intend to be
used. It is possible to use VRAM helper based driver on LS2K1000 by
carving out part of system memory as VRAM though.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space, They are used to emulate two way i2c.
One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
GPIO hardwared, they grab i2c adapter from other module, either general
purpose GPIO emulated i2c or hardware i2c adapter.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
+--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
  +---+  +--+

The above picture give a simple usage of LS7A1000, note that the encoder
is not necessary adv7125 or tfp410, other candicates can be ch7034b,
sil9022, ite66121 and lt8618 etc.

By design, the code was written in a NOT fully DT dependent way.

v2: Fixup warnings reported by kernel test robot

v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
more details about lsdc.

v4:
   1) Add dts required and explain why device tree is required.
   2) Give more description about lsdc and VRAM helper based driver.
   3) Fix warnings reported by kernel test robot.
   4) Introduce stride_alignment member into struct lsdc_chip_desc, the
  stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.

v5:
   1) Using writel and readl replace writeq and readq, to fix kernel test
  robot report build error on other archtecture.
   2) Set default fb format to XRGB at crtc reset time.

v6:
   1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
   2) Explain why tiny drm driver is not suitable for us.
   3) Give a short description of the trival dirty update implement based
  on CMA helper.

v7:
   1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
   2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
   3) Remove lsdc_pixpll_print(), part of it move to debugfs.
   4) Set prefer_shadow to true if vram based driver is in using.
   5) Replace double blank lines with single line in all files.
   6) Verbose cmd line parameter is replaced with drm_dbg()
   7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
   8) Get edid from dtb support is removed as suggested by Maxime Ripard
   9) Fix typos and various improvement

v8:
   1) Drop damage update implement and its command line.
   2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
   3) Deduce DC's identification from its compatible property.
   4) Drop the board specific dts patch.
   5) Add documention about the display controller device node.

v9:
   1) Fix the warnings reported by checkpatch script and fix typos

v10:
   1) Pass `make dt_binding_check` validation
   2) Fix warnings reported by kernel test robot

v11:
   1) Convert the driver to use drm bridge and of graph framework.
   2) Dump register value support through debugfs.
   3) Select DRM_TTM and DRM_TTM_HELPER in Kconfig which fix linkage
  problem when built it into the kernel.
   4) Non 64 pixel(256 bytes aligned) horiziontal resolutons got
  supported by hacking, default is disabled, enable it by using
  'loongson.relax_alignment=1' on kernel cmd line.
   5) Various improvement as required by Maxime.

v12:
   1) Add gammma support, it is broken because hardware engineer
  does not implement 

[PATCH v13 4/6] MIPS: Loongson64: defconfig: enable display bridge drivers

2022-03-27 Thread Sui Jingfeng
ls3A4000 evb board ship with adv7123 and tfp410 while ls2k1000 PI board
use a DPI panel from FORLINX company and a sii9022 HDMI transmitter.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 arch/mips/configs/loongson2k_defconfig | 5 +
 arch/mips/configs/loongson3_defconfig  | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/mips/configs/loongson2k_defconfig 
b/arch/mips/configs/loongson2k_defconfig
index e948ca487e2d..0a97c332a5c3 100644
--- a/arch/mips/configs/loongson2k_defconfig
+++ b/arch/mips/configs/loongson2k_defconfig
@@ -243,6 +243,11 @@ CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_DRM=y
 CONFIG_DRM_RADEON=y
+CONFIG_DRM_DISPLAY_CONNECTOR=m
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_SII902X=m
+CONFIG_DRM_SIMPLE_BRIDGE=m
+CONFIG_DRM_TI_TFP410=m
 CONFIG_FB_RADEON=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=m
diff --git a/arch/mips/configs/loongson3_defconfig 
b/arch/mips/configs/loongson3_defconfig
index 25ecd15bc952..35e2fc998768 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -280,6 +280,11 @@ CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_DRM=y
 CONFIG_DRM_RADEON=m
+CONFIG_DRM_DISPLAY_CONNECTOR=m
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_SII902X=m
+CONFIG_DRM_SIMPLE_BRIDGE=m
+CONFIG_DRM_TI_TFP410=m
 CONFIG_DRM_QXL=y
 CONFIG_DRM_VIRTIO_GPU=y
 CONFIG_FB=y
-- 
2.25.1



[PATCH v13 3/6] dt-bindings: display: Add Loongson display controller

2022-03-27 Thread Sui Jingfeng
Add DT bindings and simple usages for Loongson display controller
found in LS7A1000 bridge chip and LS2k1000 SoC.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 .../loongson/loongson,display-controller.yaml | 321 ++
 1 file changed, 321 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml

diff --git 
a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
 
b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
new file mode 100644
index ..34060ed55a25
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
@@ -0,0 +1,321 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree 
Bindings
+
+maintainers:
+  - Sui Jingfeng 
+
+description: |+
+
+  Loongson display controllers are simple which require scanout buffers
+  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
+  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
+  with a dedicated video RAM which is 64MB or more, precise size can be
+  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
+  chip.
+
+  LSDC has two display pipes, each way has a DVO interface which provide
+  RGB888 signals, vertical & horizontal synchronisations, data enable and
+  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
+  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
+
+  For LS7A1000, there are 4 dedicated GPIOs whose control register is
+  located at the DC register space. They are used to emulate two way i2c,
+  One for DVO0, another for DVO1.
+
+  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
+  general purpose GPIO emulated i2c or hardware i2c in the SoC.
+
+  LSDC's display pipeline have several components as below description,
+
+  The display controller in LS7A1000:
+ ___ _
+|---|   | |
+|  CRTC0 --> | DVO0 > Encoder0 ---> Connector0 ---> | Monitor |
+|  _   _ ---|^ ^|_|
+| | | | |---|| |
+| |_| |_|| i2c0 <+-+
+|---|
+|   DC IN LS7A1000  |
+|  _   _ ---|
+| | | | || i2c1 <+-+
+| |_| |_|---|| | _
+|---|| || |
+|  CRTC1 --> | DVO1 > Encoder1 ---> Connector1 ---> |  Panel  |
+|---|   |_|
+|___|
+
+  Simple usage of LS7A1000 with LS3A4000 CPU:
+
++--+++
+| DDR4 ||  +---+ |
++--+|  | PCIe Root complex |   LS7A1000  |
+   || MC0   |  +--++-+++ |
+  +--+  HT 3.0  | || ||  |
+  | LS3A4000 |<>| +---++---+  +--++--+ +-+   +--+
+  |   CPU|<>| | GC1000 |  | LSDC |<--->| DDR3 MC |<->| VRAM |
+  +--+  | ++  +-+--+-+ +-+   +--+
+   || MC1   +---|--|-+
++--+|  |
+| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
++--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
+  +---+  +--+
+
+  The display controller in LS2K1000/LS2K0500:
+ ___ _
+|---|   | |
+|  CRTC0 --> | DVO0 > Encoder0 ---> Connector0 ---> | Monitor |
+|  _   _ ---|^  ^   |_|
+| | | | |   ||  |
+| |_| |_|   | +--+  |
+|   <>| i2c0 |<-+
+|   DC IN LS2K1000  | +--+
+|  _   _| +--+
+| | | | |   <>| i2c1 |--+
+| |_| |_|   | +--+  |_
+|---||  |   | |
+|  CRTC1 --> | DVO1 > Encoder1 ---> Connector1 ---> |  Panel  |
+|---|   |_|
+|___|
+
+properties:
+  $nodename:
+pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
+
+  

[PATCH v13 2/6] MIPS: Loongson64: introduce board specific dts and add model property

2022-03-27 Thread Sui Jingfeng
This patch introduce three board specific dts and assign different
model property to them according to the board name on the top overlay
of the PCB.

The model property added is used to provide board specific information,
mips kernel use it as machine name. For example:

$ cat /proc/cpuinfo

system type : Generic Loongson64 System
machine : LX-6901  < notice here
processor   : 0
cpu model   : ICT Loongson-3 V0.1  FPU V0.1
BogoMIPS: 3594.02
tlb_entries : 2112
isa : mips64r2
ASEs implemented: vz msa loongson-ext2
...

1) ls3A4000 evaluation board

  The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
  mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 slot,
  therefore can play with discrete graphics card.

  While the integrated display copntroller is equipped with a VGA output
  and a DVI output, the VGA is connect to the DVO0 output port of the
  display controller, the DVI is connected to DVO1 output port of the
  display controller.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
+--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
  +---+  +--+

2) lemote A1901 motherboard

  This board is made by LEMOTE corporation, it has two name, one is
  LX-6901, another is A1901. This board has only one VGA output which
  is connected to the DVO1 of the display controller.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |   DVO0 is not get used |  |  DVO1   +---+
+--+   <+  +>|ADV7125|---> VGA
 +---+

3) ls2k1000 pai evaluation board

  ls2k1000 is a two core 1.0Ghz Mips64r2 compatible SoC, desprite very
  slow, lacking i2c driver support, various display dridge drivers can
  only be tested on it. We still try to provide a minimal support.
   ___   
  |---| ||
  |  CRTC0 --> | DVO0 > | 1024x600 DPI Panel |
  |  _   _ ---|  | Which panel to use   ||
  | | | | |   |  | with this board is a  ___
  | |_| |_|   |  | choice of the user   |   |
  |   |  +> | 800x480 DPI Panel |
  |   DC In LS2K1000  | |___|
  |  _   _| +--+
  | | | | |   <>| i2c1 |---+
  | |_| |_|   | +--+   |
  |   || <--- config   | DDC   _
  |---|+-+ |  | |
  |  CRTC1 --> | DVO1 ---> | sii9022 | --> HDMI connector --> | Monitor |
  |---|+-+|_|
  |___|

  The sii9022 HDMI transmitter working in transparent mode, because the
  PCB designer make the board working in this way. In this case the EDID
  is read from the monitor directly, not through sii9022's ddc channel.
  The i2c0 is not get used by lsdc driver for this board.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 arch/mips/boot/dts/loongson/Makefile  |   4 +
 arch/mips/boot/dts/loongson/lemote_a1901.dts  |  96 
 .../boot/dts/loongson/ls2k1000_pai_udb.dts| 107 ++
 .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 138 ++
 4 files changed, 345 insertions(+)
 create mode 100644 arch/mips/boot/dts/loongson/lemote_a1901.dts
 create mode 100644 

[PATCH v13 1/6] MIPS: Loongson64: dts: update the display controller device node

2022-03-27 Thread Sui Jingfeng
The display controller is a pci device, it is used in ls2k1000 SoC and
LS7A1000 bridge. Its PCI vendor id is 0x0014, its PCI device id is 0x7a06.
In order to let the driver to know which chip the DC is contained in,
the compatible of the display controller is named according to the chip's
name.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space. They are used to emulate i2c for reading
edid from the monitor. One for DVO0, another for DVO1.

LS2K1000 and LS2K0500 SoC don't have such GPIOs, they grab i2c adapter
from other module, either general purpose GPIO emulated i2c or hardware
i2c adapter.

This patch add common part of the DC device node only, it does not contain
ports device note. As it is for the generic, boards only with transparent
encoders should works simply by inherit from this.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 .../boot/dts/loongson/loongson64-2k1000.dtsi  |  8 +++
 arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 24 +++
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi 
b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
index 8143a6e3..2ecb5a232f22 100644
--- a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
+++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
@@ -198,6 +198,14 @@ sata@8,0 {
interrupt-parent = <>;
};
 
+   lsdc: display-controller@6,0 {
+   compatible = "loongson,ls2k1000-dc";
+
+   reg = <0x3000 0x0 0x0 0x0 0x0>;
+   interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <>;
+   };
+
pci_bridge@9,0 {
compatible = "pci0014,7a19.0",
   "pci0014,7a19",
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi 
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index 2f45fce2cdc4..1d3fe73b31d5 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -160,15 +160,29 @@ gpu@6,0 {
interrupt-parent = <>;
};
 
-   dc@6,1 {
-   compatible = "pci0014,7a06.0",
-  "pci0014,7a06",
-  "pciclass03",
-  "pciclass0300";
+   lsdc: display-controller@6,1 {
+   compatible = "loongson,ls7a1000-dc";
 
reg = <0x3100 0x0 0x0 0x0 0x0>;
interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c6: i2c@6 {
+   compatible = "loongson,gpio-i2c";
+   loongson,sda = <0>;
+   loongson,scl = <1>;
+   loongson,nr = <6>;
+   };
+
+   i2c7: i2c@7 {
+   compatible = "loongson,gpio-i2c";
+   loongson,sda = <2>;
+   loongson,scl = <3>;
+   loongson,nr = <7>;
+   };
};
 
hda@7,0 {
-- 
2.25.1



Re: [PATCH v12 3/6] dt-bindings: display: Add Loongson display controller

2022-03-27 Thread Sui Jingfeng



On 2022/3/27 22:02, Rob Herring wrote:

On Sun, 27 Mar 2022 19:38:43 +0800, Sui Jingfeng wrote:

Add DT bindings and simple usages for Loongson display controller
found in LS7A1000 bridges chip and LS2k1000 SoC.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
  .../loongson/loongson,display-controller.yaml | 322 ++
  1 file changed, 322 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml


My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.example.dt.yaml:
 display-controller@6,1: 'ports' is a required property
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1609879

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


It is my fault, remove the ports from the required will fix this,

I run make dt_binding_check before made it optional.

 I will resend the patch.



Re: [PATCH] dispnv50: atom: fix an incorrect NULL check on list iterator

2022-03-27 Thread Xiaomeng Tong
on Sun, 27 Mar 2022 16:59:28 +0100, Emil Velikov wrote:
> On Sun, 27 Mar 2022 at 08:39, Xiaomeng Tong  wrote:
> >
> > The bug is here:
> > return encoder;
> >
> > The list iterator value 'encoder' will *always* be set and non-NULL
> > by drm_for_each_encoder_mask(), so it is incorrect to assume that the
> > iterator value will be NULL if the list is empty or no element found.
> > Otherwise it will bypass some NULL checks and lead to invalid memory
> > access passing the check.
> >
> > To fix this bug, just return 'encoder' when found, otherwise return
> > NULL.
> >
> 
> Isn't this covered by the upcoming list* iterator rework [1] or is
> this another iterator glitch?

Actually, it is a part of the upcoming work.

> IMHO we should be looking at fixing the implementation and not the
> hundreds of users through the kernel.
>
> HTH
> -Emil
> [1] https://lwn.net/Articles/887097/

Yes, you are right. This has also been taken into account by the upcoming
list iterator rework to avoid a lot uesr' changes as much as possible.

However, this patch is fixing a potential bug caused by incorrect use of
list iterator outside the loop, which can not be fixed by the implementation
itself.

--
Xiaomeng Tong


Re: [PATCH v12 3/6] dt-bindings: display: Add Loongson display controller

2022-03-27 Thread Sui Jingfeng



On 2022/3/27 20:54, Jiaxun Yang wrote:



在 2022/3/27 12:38, Sui Jingfeng 写道:

Add DT bindings and simple usages for Loongson display controller
found in LS7A1000 bridges chip and LS2k1000 SoC.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>

[...]

+
+  - |
+    #include 
+    bus {
+
+    #address-cells = <3>;
+    #size-cells = <2>;
+    #interrupt-cells = <2>;
+
+    display-controller@6,1 {
+    compatible = "loongson,ls7a1000-dc";
+    reg = <0x3100 0x0 0x0 0x0 0x0>;
+    interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
+
+    #address-cells = <1>;
+    #size-cells = <0>;
+
+    i2c@6 {
+    compatible = "loongson,gpio-i2c";
+    reg = <0x1650 0x0020>;

Hi Jingfeng,

Thanks for your patch.

Just curious about what is this "reg" for?


Hi, Jiaxun

Thanks for you take valuable time to review my patch.

Without it make dt_binding_check generate warnings:

Documentation/devicetree/bindings/display/loongson/loongson,display-controller.example.dts:65.23-73.19: 
Warning (unit_address_vs_reg): 
/example-1/bus/display-controller@6,1/i2c@6: node has a unit name, but 
no reg or ranges property


reg are the control register offset and size of the dedicate GPIO, they 
are not get used by the driver currently,


put in there just for silence the warning .



+    loongson,nr = <6>;

Why nr start from 6?



Bus number greater than 6 is safe  because ls7a1000 bridge have 6 hardware I2C controller integrated. but 
the driver for it is not upstream yet. To avoid potential conflict with the bus number of the hardware I2C driver.


In the future, if someone contribute the hardware I2C driver to upstream,
you don't need change it. Let me give you an example to show what it will be:

aliases {
i2c0 = 
i2c1 = 
i2c2 = 
i2c3 = 
i2c4 = 
i2c5 = 
i2c6 = 
i2c7 = 
};

i2c0: i2c@1009 {
compatible = "loongson,ls-i2c";
reg = <0x1009 0x8>;
interrupts = <73>;
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <0>;
};


i2c1: i2c@10090100 {
compatible = "loongson,ls-i2c";
reg = <0x10090100 0x8>;
interrupts = <73>;
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <0>;
};

i2c2: i2c@10090200 {
compatible = "loongson,ls-i2c";
reg = <0x10090200 0x8>;
interrupts = <73>;
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <0>;
};

i2c3: i2c@10090300 {
compatible = "loongson,ls-i2c";
reg = <0x10090300 0x8>;
interrupts = <73>;
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <0>;
};

i2c4: i2c@10090400 {
compatible = "loongson,ls-i2c";
reg = <0x10090400 0x8>;
interrupts = <73>;
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <0>;
};

i2c5: i2c@10090500 {
compatible = "loongson,ls-i2c";
reg = <0x10090500 0x8>;
interrupts = <73>;
interrupt-parent = <>;
#address-cells = <1>;
#size-cells = <0>;
};


The approach you are handling I2C seems to be wired..



It is not wired,  you can change it to 0 or 1 it you like currently,

you can even remove loongson,nr = <6> and loongson,nr = <7>,

then the i2c core driver will automatically  allocate one for you.

It is very flexible actually.


Actually you can reference how network subsystem is handling
MDIO controller built-in into Ethernet controller [1] in this case. It is
basically the same problem.

[1]: 
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/net/snps,dwmac.yaml


Thanks.
- Jiaxun


+    loongson,sda = <0>;
+    loongson,scl = <1>;
+    loongson,udelay = <5>;
+    loongson,timeout = <2200>;
+    };
+
+    i2c@7 {
+    compatible = "loongson,gpio-i2c";
+    reg = <0x1650 0x0020>;
+    loongson,nr = <7>;
+    loongson,sda = <2>;
+    loongson,scl = <3>;
+    loongson,udelay = <5>;
+    loongson,timeout = <2200>;
+    };
+
+    ports {
+    #address-cells = <1>;
+    #size-cells = <0>;
+    port@0 {
+    reg = <0>;
+    endpoint {
+    

RE: [PATCH v2 3/25] drm/amdgpu: Disable ABM when AC mode

2022-03-27 Thread Lin, Tsung-hua (Ryan)
[AMD Official Use Only]

Hi Harry,

I have been reminded to do some modifications to the patch format. So the 3/25 
it's the date I resent the mail v2.
If the mail title usage is not correct, please let me know.

And about the questions:
" This file lives in DC, which is shared code between Windows and Linux. We 
cannot directly use adev here. Any information needs to go through DC structs."
- I use the adev here because I just reference the code I found in the 
same function. 

 +  if (strcmp(entry->device_class, "battery") == 0) {  
   < I added.
 +  adev->pm.ac_power = power_supply_is_system_supplied() > 0;
 +  }
 +
if (strcmp(entry->device_class, ACPI_AC_CLASS) == 0) {  
< I found.
if (power_supply_is_system_supplied() > 0)
DRM_DEBUG_DRIVER("pm: AC\n");

-And the reason why I need to add another comparison is that the string 
of the device_class I got is always "battery" when I plug/unplug the ac cable.
 It never reports "ac_adapter" to me. So I add the "battery" line to do 
that.


"I seem to remember someone saying that ABM gets disabled on Windows when we're 
in AC mode. Have you checked with our Windows guys about this? I feel we're 
re-inventing the wheel here for no good reason."

-Yes, I have asked the Windows guys and they told me the ABM should be 
disabled in AC mode. But seems we don’t have this function on Linux, so I 
implemented this to disable ABM in AC mode.

Thanks,
Ryan Lin.


-Original Message-
From: Wentland, Harry  
Sent: Friday, March 25, 2022 10:46 PM
To: Lin, Tsung-hua (Ryan) ; Li, Sun peng (Leo) 
; Deucher, Alexander ; Koenig, 
Christian ; david1.z...@amd.com; airl...@linux.ie; 
dan...@ffwll.ch; seanp...@chromium.org; b...@basnieuwenhuizen.nl; Kazlauskas, 
Nicholas ; sas...@kernel.org; 
markyac...@google.com; victorchengchi...@amd.com; 
ching-shih...@amd.corp-partner.google.com; Siqueira, Rodrigo 
; ddavenp...@chromium.org; 
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
linux-ker...@vger.kernel.org; Li, Leon 
Subject: Re: [PATCH v2 3/25] drm/amdgpu: Disable ABM when AC mode



On 2022-03-25 00:05, Ryan Lin wrote:
> Disable ABM feature when the system is running on AC mode to get the 
> more perfect contrast of the display.

It says patch 3 out of 25. Are there other patches? If so, I can't find them in 
my mailbox and neither can patchwork 
https://patchwork.freedesktop.org/series/101767/
 
> Signed-off-by: Ryan Lin 
> 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  |  4 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  1 +
>  drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c | 58 ---
>  drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h   |  1 +
>  4 files changed, 42 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> index c560c1ab62ecb..bc8bb9aad2e36 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> @@ -822,6 +822,10 @@ static int amdgpu_acpi_event(struct notifier_block *nb,
>   struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, 
> acpi_nb);
>   struct acpi_bus_event *entry = (struct acpi_bus_event *)data;
>  
> + if (strcmp(entry->device_class, "battery") == 0) {
> + adev->pm.ac_power = power_supply_is_system_supplied() > 0;
> + }
> +
>   if (strcmp(entry->device_class, ACPI_AC_CLASS) == 0) {
>   if (power_supply_is_system_supplied() > 0)
>   DRM_DEBUG_DRIVER("pm: AC\n");
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index abfcc1304ba0c..3a0afe7602727 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3454,6 +3454,7 @@ int amdgpu_device_init(struct amdgpu_device 
> *adev,
>  
>   adev->gfx.gfx_off_req_count = 1;
>   adev->pm.ac_power = power_supply_is_system_supplied() > 0;
> + adev->pm.old_ac_power = true;
>  
>   atomic_set(>throttling_logging_enabled, 1);
>   /*
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
> index 54a1408c8015c..478a734b66926 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
> @@ -23,6 +23,8 @@
>   *
>   */
>  
> +#include 
> +#include "amdgpu.h"
>  #include "dmub_abm.h"
>  #include "dce_abm.h"
>  #include "dc.h"
> @@ -51,6 +53,7 @@
>  #define DISABLE_ABM_IMMEDIATELY 255
>  
>  
> +extern uint amdgpu_dm_abm_level;
>  
>  static void dmub_abm_enable_fractional_pwm(struct dc_context *dc)  { 
> @@ -117,28 +120,6 @@ static void dmub_abm_init(struct abm *abm, uint32_t 
> backlight)
>   dmub_abm_enable_fractional_pwm(abm->ctx);
>  }
>  
> -static unsigned int 

RE: [PATCH] fbdev: defio: fix the pagelist corruption

2022-03-27 Thread Liu, Chuansheng
Hi Paul,

> -Original Message-
> From: dri-devel  On Behalf Of Paul
> Menzel
> Sent: Saturday, March 26, 2022 4:11 PM
> To: Liu, Chuansheng 
> Cc: linux-fb...@vger.kernel.org; del...@gmx.de; dri-
> de...@lists.freedesktop.org; tzimmerm...@suse.de; jay...@intworks.biz
> Subject: Re: [PATCH] fbdev: defio: fix the pagelist corruption
> 
> Dear Chuansheng,
> 
> 
> Am 17.03.22 um 06:46 schrieb Chuansheng Liu:
> > Easily hit the below list corruption:
> > ==
> > list_add corruption. prev->next should be next (c0ceb090), but
> > was ec604507edc8. (prev=ec604507edc8).
> > WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26
> > __list_add_valid+0x53/0x80
> > CPU: 65 PID: 3959 Comm: fbdev Tainted: G U
> > RIP: 0010:__list_add_valid+0x53/0x80
> > Call Trace:
> >   
> >   fb_deferred_io_mkwrite+0xea/0x150
> >   do_page_mkwrite+0x57/0xc0
> >   do_wp_page+0x278/0x2f0
> >   __handle_mm_fault+0xdc2/0x1590
> >   handle_mm_fault+0xdd/0x2c0
> >   do_user_addr_fault+0x1d3/0x650
> >   exc_page_fault+0x77/0x180
> >   ? asm_exc_page_fault+0x8/0x30
> >   asm_exc_page_fault+0x1e/0x30
> > RIP: 0033:0x7fd98fc8fad1
> > ==
> >
> > Figure out the race happens when one process is adding >lru into
> > the pagelist tail in fb_deferred_io_mkwrite(), another process is
> > re-initializing the same >lru in fb_deferred_io_fault(), which is
> > not protected by the lock.
> >
> > This fix is to init all the page lists one time during initialization,
> > it not only fixes the list corruption, but also avoids INIT_LIST_HEAD()
> > redundantly.
> >
> > Fixes: 105a940416fc ("fbdev/defio: Early-out if page is already
> > enlisted")
> > Cc: Thomas Zimmermann 
> > Signed-off-by: Chuansheng Liu 
> > ---
> >   drivers/video/fbdev/core/fb_defio.c | 9 -
> >   1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/fbdev/core/fb_defio.c
> b/drivers/video/fbdev/core/fb_defio.c
> > index 98b0f23bf5e2..eafb66ca4f28 100644
> > --- a/drivers/video/fbdev/core/fb_defio.c
> > +++ b/drivers/video/fbdev/core/fb_defio.c
> > @@ -59,7 +59,6 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault
> *vmf)
> > printk(KERN_ERR "no mapping available\n");
> >
> > BUG_ON(!page->mapping);
> > -   INIT_LIST_HEAD(>lru);
> > page->index = vmf->pgoff;
> >
> > vmf->page = page;
> > @@ -220,6 +219,8 @@ static void fb_deferred_io_work(struct work_struct
> *work)
> >   void fb_deferred_io_init(struct fb_info *info)
> >   {
> > struct fb_deferred_io *fbdefio = info->fbdefio;
> > +   struct page *page;
> > +   int i;
> >
> > BUG_ON(!fbdefio);
> > mutex_init(>lock);
> > @@ -227,6 +228,12 @@ void fb_deferred_io_init(struct fb_info *info)
> > INIT_LIST_HEAD(>pagelist);
> > if (fbdefio->delay == 0) /* set a default of 1 s */
> > fbdefio->delay = HZ;
> > +
> > +   /* initialize all the page lists one time */
> > +   for (i = 0; i < info->fix.smem_len; i += PAGE_SIZE) {
> > +   page = fb_deferred_io_page(info, i);
> > +   INIT_LIST_HEAD(>lru);
> > +   }
> >   }
> >   EXPORT_SYMBOL_GPL(fb_deferred_io_init);
> >
> Applying your patch on top of current Linus’ master branch, tty0 is
> unusable and looks frozen. Sometimes network card still works, sometimes
> not.

I don't see how the patch would cause below BUG call stack, need some time to
debug. Just few comments:
1. Will the system work well without this patch?
2. When you are sure the patch causes the regression you saw, please get free 
to submit
one reverted patch, thanks : )

> 
>  $ git log --oneline -nodecorate -2
>  1b351a77ed33 (HEAD -> linus) fbdev: defio: fix the pagelist corruption
>  52d543b5497c (origin/master, origin/HEAD) Merge tag
> 'for-linus-5.17-1' of https://github.com/cminyard/linux-ipmi
> 
> ```
> [5.256996] raw:   
> 
> [5.269582] page dumped because: VM_BUG_ON_PAGE(compound &&
> compound_order(page) != order)
> [5.279507] [ cut here ]
> [5.286406] kernel BUG at mm/page_alloc.c:1326!
> [5.291814] invalid opcode:  [#1] PREEMPT SMP
> [5.296350] CPU: 0 PID: 167 Comm: systemd-udevd Not tainted
> 5.17.0-10753-g1b351a77ed33 #300
> [5.304670] Hardware name: ASUS F2A85-M_PRO/F2A85-M_PRO, BIOS
> 4.16-337-gb87986e67b 03/25/2022
> [5.313163] RIP: 0010:free_pcp_prepare+0x295/0x400
> [5.317930] Code: 00 01 00 75 0b 48 8b 45 08 45 31 ff a8 01 74 4b 48
> 8b 45 00 a9 00 00 01 00 75 22 48 c7 c6 68 30 11 96 48 89 ef e8 cb 29 fd
> ff <0f> 0b 48 89 ef 41 83 c6 01 e8 bd f5 ff ff e9 2e fe ff ff 0f 1f 44
> [5.336650] RSP: 0018:a6634062f9c0 EFLAGS: 00010246
> [5.341849] RAX: 004e RBX: e4be8000 RCX:
> 
> [5.348957] RDX:  RSI: 96136a37 RDI:
> 
> [5.356063] RBP: e4be840c R08:  R09:
> dfff
> [5.363170] R10: a6634062f7f0 R11: 9652c4a8 

Re: linux-next: build warning after merge of the drm-misc tree

2022-03-27 Thread Stephen Rothwell
Hi Andrey,

On Tue, 1 Mar 2022 22:26:12 -0500 Andrey Grodzovsky  
wrote:
>
> On 2022-03-01 20:31, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Thu, 20 Jan 2022 14:26:39 +1100 Stephen Rothwell  
> > wrote:  
> >> On Wed, 17 Nov 2021 13:49:26 +1100 Stephen Rothwell 
> >>  wrote:  
> >>> After merging the drm-misc tree, today's linux-next build (htmldocs)
> >>> produced this warning:
> >>>
> >>> include/drm/gpu_scheduler.h:316: warning: Function parameter or member 
> >>> 'work' not described in 'drm_sched_job'
> >>>
> >>> Introduced by commit
> >>>
> >>>542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes") 
> >>>  
> >> I am still seeing this warning.  
> > I am still seeing this warning.
> >  
> Please check you have commit c7703ce38c1e Andrey Grodzovsky   3 weeks ago    
> drm/amdgpu: Fix htmldoc warning

I do have commit c7703ce38c1e (in fact it is in Linus' tree), but that
commit does not address the warning above.  I am still (as of Friday)
getting that warning.

-- 
Cheers,
Stephen Rothwell


pgpWrSosTX5t2.pgp
Description: OpenPGP digital signature


Re: [PATCH] tilcdc: tilcdc_external: fix an incorrect NULL check on list iterator

2022-03-27 Thread Jyri Sarha

On 2022-03-27 9:15, Xiaomeng Tong wrote:

The bug is here:
if (!encoder) {

The list iterator value 'encoder' will *always* be set and non-NULL
by list_for_each_entry(), so it is incorrect to assume that the
iterator value will be NULL if the list is empty or no element
is found.

To fix the bug, use a new variable 'iter' as the list iterator,
while use the original variable 'encoder' as a dedicated pointer
to point to the found element.

Cc: sta...@vger.kernel.org
Fixes: ec9eab097a500 ("drm/tilcdc: Add drm bridge support for
attaching drm bridge drivers")
Signed-off-by: Xiaomeng Tong 


Thanks for the patch. Good catch.

Reviewed-by: Jyri Sarha 
Tested-by: Jyri Sarha 

I'll apply this to drm-misc-next in couple of days.

Best regards,
Jyri


---
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 7594cf6e186e..3b86d002ef62 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -60,11 +60,13 @@ struct drm_connector
*tilcdc_encoder_find_connector(struct drm_device *ddev,
 int tilcdc_add_component_encoder(struct drm_device *ddev)
 {
struct tilcdc_drm_private *priv = ddev->dev_private;
-   struct drm_encoder *encoder;
+   struct drm_encoder *encoder = NULL, *iter;

-   list_for_each_entry(encoder, >mode_config.encoder_list, head)
-   if (encoder->possible_crtcs & (1 << priv->crtc->index))
+   list_for_each_entry(iter, >mode_config.encoder_list, head)
+   if (iter->possible_crtcs & (1 << priv->crtc->index)) {
+   encoder = iter;
break;
+   }

if (!encoder) {
dev_err(ddev->dev, "%s: No suitable encoder found\n", __func__);


[PATCH v9 21/22] drm/mediatek: change the aux retries times when receiving AUX_DEFER

2022-03-27 Thread Guillaume Ranquet
From: Jitao Shi 

DP 1.4a Section 2.8.7.1.5.6.1:
A DP Source device shall retry at least seven times upon receiving
AUX_DEFER before giving up the AUX transaction.

Aux should retry to send msg whether how many bytes.

Signed-off-by: Jitao Shi 
Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_dp.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index e099491cc6a4..7a197c4a7143 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2016,7 +2016,7 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux 
*mtk_aux,
bool is_read;
u8 request;
size_t accessed_bytes = 0;
-   int retry = 3, ret = 0;
+   int retry, ret = 0;
 
mtk_dp = container_of(mtk_aux, struct mtk_dp, aux);
 
@@ -2050,14 +2050,21 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux 
*mtk_aux,
}
 
if (msg->size == 0) {
-   ret = mtk_dp_aux_do_transfer(mtk_dp, is_read, request,
-msg->address + accessed_bytes,
-msg->buffer + accessed_bytes, 0);
+   retry = 32;
+   while (retry--) {
+   ret = mtk_dp_aux_do_transfer(mtk_dp, is_read, request,
+msg->address + 
accessed_bytes,
+msg->buffer + 
accessed_bytes, 0);
+   if (ret == 0)
+   break;
+   usleep_range(500, 600);
+   }
} else {
while (accessed_bytes < msg->size) {
size_t to_access =
min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES,
  msg->size - accessed_bytes);
+   retry = 32;
while (retry--) {
ret = mtk_dp_aux_do_transfer(mtk_dp,
 is_read, request,
@@ -2066,7 +2073,7 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux 
*mtk_aux,
 to_access);
if (ret == 0)
break;
-   usleep_range(50, 100);
+   usleep_range(500, 600);
}
if (!retry || ret) {
drm_info(mtk_dp->drm_dev,
-- 
2.34.1



[PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver

2022-03-27 Thread Guillaume Ranquet
From: Markus Schneider-Pargmann 

This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.

It supports the mt8195, the embedded DisplayPort units. It offers
DisplayPort 1.4 with up to 4 lanes.

The driver shares its iomap range with the mtk-dp-phy driver using
the regmap/syscon facility.

This driver is based on an initial version by
Jason-JH.Lin .

Signed-off-by: Markus Schneider-Pargmann 
Signed-off-by: Guillaume Ranquet 
Reported-by: kernel test robot 
---
 drivers/gpu/drm/mediatek/Kconfig   |8 +
 drivers/gpu/drm/mediatek/Makefile  |2 +
 drivers/gpu/drm/mediatek/mtk_dp.c  | 2221 
 drivers/gpu/drm/mediatek/mtk_dp_reg.h  |  568 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |1 +
 6 files changed, 2801 insertions(+)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
 create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h

diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 2976d21e9a34..03ffa9b896c3 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
select PHY_MTK_HDMI
help
  DRM/KMS HDMI driver for Mediatek SoCs
+
+config MTK_DPTX_SUPPORT
+   tristate "DRM DPTX Support for Mediatek SoCs"
+   depends on DRM_MEDIATEK
+   select PHY_MTK_DP
+   select DRM_DP_HELPER
+   help
+ DRM/KMS Display Port driver for Mediatek SoCs.
diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index 29098d7c8307..d86a6406055e 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
  mtk_hdmi_ddc.o
 
 obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
+
+obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
new file mode 100644
index ..7cd8459cf719
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -0,0 +1,2221 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Copyright (c) 2021 BayLibre
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_dp_reg.h"
+
+#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
+#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
+
+//TODO: platform/device data or dts?
+#define MTK_DP_MAX_LANES 4
+#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3
+
+#define MTK_DP_TBC_BUF_READ_START_ADDR 0x08
+
+#define MTK_DP_TRAIN_RETRY_LIMIT 8
+#define MTK_DP_TRAIN_MAX_ITERATIONS 5
+
+#define MTK_DP_AUX_WRITE_READ_WAIT_TIME_US 20
+
+#define MTK_DP_DP_VERSION_11 0x11
+
+enum mtk_dp_state {
+   MTK_DP_STATE_INITIAL,
+   MTK_DP_STATE_IDLE,
+   MTK_DP_STATE_PREPARE,
+   MTK_DP_STATE_NORMAL,
+};
+
+enum mtk_dp_train_state {
+   MTK_DP_TRAIN_STATE_STARTUP = 0,
+   MTK_DP_TRAIN_STATE_CHECKCAP,
+   MTK_DP_TRAIN_STATE_CHECKEDID,
+   MTK_DP_TRAIN_STATE_TRAINING_PRE,
+   MTK_DP_TRAIN_STATE_TRAINING,
+   MTK_DP_TRAIN_STATE_NORMAL,
+   MTK_DP_TRAIN_STATE_DPIDLE,
+};
+
+struct mtk_dp_timings {
+   struct videomode vm;
+
+   u16 htotal;
+   u16 vtotal;
+   u8 frame_rate;
+   u32 pix_rate_khz;
+};
+
+struct mtk_dp_train_info {
+   bool tps3;
+   bool tps4;
+   bool sink_ssc;
+   bool cable_plugged_in;
+   bool cable_state_change;
+   bool cr_done;
+   bool eq_done;
+
+   /* link_rate is in multiple of 0.27Gbps */
+   int link_rate;
+   int lane_count;
+
+   u8  irq_status;
+   int check_cap_count;
+};
+
+/* Same values as used by the DP Spec for MISC0 bits 1 and 2 */
+enum mtk_dp_color_format {
+   MTK_DP_COLOR_FORMAT_RGB_444 = 0,
+   MTK_DP_COLOR_FORMAT_YUV_422 = 1,
+   MTK_DP_COLOR_FORMAT_YUV_444 = 2,
+   MTK_DP_COLOR_FORMAT_YUV_420 = 3,
+   MTK_DP_COLOR_FORMAT_YONLY = 4,
+   MTK_DP_COLOR_FORMAT_RAW = 5,
+   MTK_DP_COLOR_FORMAT_RESERVED = 6,
+   MTK_DP_COLOR_FORMAT_DEFAULT = MTK_DP_COLOR_FORMAT_RGB_444,
+   MTK_DP_COLOR_FORMAT_UNKNOWN = 15,
+};
+
+/* Multiple of 0.27Gbps */
+enum mtk_dp_linkrate {
+   MTK_DP_LINKRATE_RBR = 0x6,
+   MTK_DP_LINKRATE_HBR = 0xA,
+   MTK_DP_LINKRATE_HBR2 = 0x14,
+   MTK_DP_LINKRATE_HBR25 = 0x19,
+   MTK_DP_LINKRATE_HBR3 = 0x1E,
+};
+
+/* Same values as used for DP Spec MISC0 bits 5,6,7 */
+enum mtk_dp_color_depth {
+   MTK_DP_COLOR_DEPTH_6BIT = 0,
+   MTK_DP_COLOR_DEPTH_8BIT = 1,
+   MTK_DP_COLOR_DEPTH_10BIT = 2,
+   MTK_DP_COLOR_DEPTH_12BIT = 3,
+   MTK_DP_COLOR_DEPTH_16BIT = 4,
+   MTK_DP_COLOR_DEPTH_UNKNOWN = 5,
+};
+
+struct mtk_dp_info {
+   

[PATCH v9 12/22] drm/mediatek: dpi: move swap_shift to SoC config

2022-03-27 Thread Guillaume Ranquet
Add flexibility by moving the swap shift value to SoC specific config

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 6eeda222a973..6d4d8c6ec47d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -131,6 +131,7 @@ struct mtk_dpi_conf {
u32 dimension_mask;
/* HSIZE and VSIZE mask (no shift) */
u32 hvsize_mask;
+   u32 channel_swap_shift;
const struct mtk_dpi_yc_limit *limit;
 };
 
@@ -349,7 +350,8 @@ static void mtk_dpi_config_channel_swap(struct mtk_dpi *dpi,
break;
}
 
-   mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, val << CH_SWAP, CH_SWAP_MASK);
+   mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, val << 
dpi->conf->channel_swap_shift,
+CH_SWAP_MASK);
 }
 
 static void mtk_dpi_config_yuv422_enable(struct mtk_dpi *dpi, bool enable)
@@ -821,6 +823,7 @@ static const struct mtk_dpi_conf mt8173_conf = {
.swap_input_support = true,
.dimension_mask = HPW_MASK,
.hvsize_mask = HSIZE_MASK,
+   .channel_swap_shift = CH_SWAP,
.limit = _dpi_limit,
 };
 
@@ -835,6 +838,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.swap_input_support = true,
.dimension_mask = HPW_MASK,
.hvsize_mask = HSIZE_MASK,
+   .channel_swap_shift = CH_SWAP,
.limit = _dpi_limit,
 };
 
@@ -848,6 +852,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.swap_input_support = true,
.dimension_mask = HPW_MASK,
.hvsize_mask = HSIZE_MASK,
+   .channel_swap_shift = CH_SWAP,
.limit = _dpi_limit,
 };
 
@@ -861,6 +866,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.swap_input_support = true,
.dimension_mask = HPW_MASK,
.hvsize_mask = HSIZE_MASK,
+   .channel_swap_shift = CH_SWAP,
.limit = _dpi_limit,
 };
 
-- 
2.34.1



[PATCH v9 22/22] drm/mediatek: DP audio support for mt8195

2022-03-27 Thread Guillaume Ranquet
This patch adds audio support to the DP driver for mt8195 with up to 8
channels.

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_dp.c | 712 +-
 1 file changed, 693 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 7a197c4a7143..a033e6d62e15 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -123,9 +123,16 @@ enum mtk_dp_color_depth {
MTK_DP_COLOR_DEPTH_UNKNOWN = 5,
 };
 
+struct mtk_dp_audio_cfg {
+   int sample_rate;
+   int word_length_bits;
+   int channels;
+};
+
 struct mtk_dp_info {
enum mtk_dp_color_depth depth;
enum mtk_dp_color_format format;
+   struct mtk_dp_audio_cfg audio_caps;
struct mtk_dp_timings timings;
 };
 
@@ -165,13 +172,19 @@ struct mtk_dp {
struct clk *dp_tx_clk;
 
bool enabled;
+   bool audio_enable;
 
bool has_fec;
/* Protects the mtk_dp struct */
struct mutex dp_lock;
 
+   /* Protects the plugged_cb as it's used in both bridge ops and audio */
+   struct mutex update_plugged_status_lock;
+
hdmi_codec_plugged_cb plugged_cb;
struct device *codec_dev;
+   /* Protects the eld data as it's used in both bridge ops and audio */
+   struct mutex eld_lock;
u8 connector_eld[MAX_ELD_BYTES];
struct drm_connector *conn;
bool need_debounce;
@@ -505,15 +518,317 @@ static int mtk_dp_pg_disable(struct mtk_dp *mtk_dp)
return ret;
 }
 
+static int mtk_dp_audio_setup_channels(struct mtk_dp *mtk_dp,
+  struct mtk_dp_audio_cfg *cfg)
+{
+   int ret;
+   u32 channel_enable_bits;
+
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC1_P0_3324,
+   AUDIO_SOURCE_MUX_DP_ENC1_P0_DPRX,
+  AUDIO_SOURCE_MUX_DP_ENC1_P0_MASK, ret, out);
+
+   /* audio channel count change reset */
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC1_P0_33F4, BIT(9), BIT(9), ret, 
out);
+
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC1_P0_3304,
+   AU_PRTY_REGEN_DP_ENC1_P0_MASK,
+  AU_PRTY_REGEN_DP_ENC1_P0_MASK, ret, out);
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC1_P0_3304,
+   AU_CH_STS_REGEN_DP_ENC1_P0_MASK,
+  AU_CH_STS_REGEN_DP_ENC1_P0_MASK, ret, out);
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC1_P0_3304,
+   AUDIO_SAMPLE_PRSENT_REGEN_DP_ENC1_P0_MASK,
+  AUDIO_SAMPLE_PRSENT_REGEN_DP_ENC1_P0_MASK, ret, out);
+
+   switch (cfg->channels) {
+   case 2:
+   channel_enable_bits = AUDIO_2CH_SEL_DP_ENC0_P0_MASK |
+ AUDIO_2CH_EN_DP_ENC0_P0_MASK;
+   break;
+   case 8:
+   default:
+   channel_enable_bits = AUDIO_8CH_SEL_DP_ENC0_P0_MASK |
+ AUDIO_8CH_EN_DP_ENC0_P0_MASK;
+   break;
+   }
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC0_P0_3088,
+   channel_enable_bits | AU_EN_DP_ENC0_P0_MASK,
+  AUDIO_2CH_SEL_DP_ENC0_P0_MASK | 
AUDIO_2CH_EN_DP_ENC0_P0_MASK |
+  AUDIO_8CH_SEL_DP_ENC0_P0_MASK |
+  AUDIO_8CH_EN_DP_ENC0_P0_MASK | 
AU_EN_DP_ENC0_P0_MASK, ret, out);
+
+   /* audio channel count change reset */
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC1_P0_33F4, 0, BIT(9), ret, out);
+
+   /* enable audio reset */
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC1_P0_33F4, BIT(0), BIT(0), ret, 
out);
+
+out:
+   return ret;
+}
+
+static int mtk_dp_audio_channel_status_set(struct mtk_dp *mtk_dp,
+  struct mtk_dp_audio_cfg *cfg)
+{
+   int ret;
+   struct snd_aes_iec958 iec = { 0 };
+
+   switch (cfg->sample_rate) {
+   case 32000:
+   iec.status[3] = IEC958_AES3_CON_FS_32000;
+   break;
+   case 44100:
+   iec.status[3] = IEC958_AES3_CON_FS_44100;
+   break;
+   case 48000:
+   iec.status[3] = IEC958_AES3_CON_FS_48000;
+   break;
+   case 88200:
+   iec.status[3] = IEC958_AES3_CON_FS_88200;
+   break;
+   case 96000:
+   iec.status[3] = IEC958_AES3_CON_FS_96000;
+   break;
+   case 192000:
+   iec.status[3] = IEC958_AES3_CON_FS_192000;
+   break;
+   default:
+   iec.status[3] = IEC958_AES3_CON_FS_NOTID;
+   break;
+   }
+
+   switch (cfg->word_length_bits) {
+   case 16:
+   iec.status[4] = IEC958_AES4_CON_WORDLEN_20_16;
+   break;
+   case 20:
+   iec.status[4] = IEC958_AES4_CON_WORDLEN_20_16 |
+   IEC958_AES4_CON_MAX_WORDLEN_24;
+  

[PATCH v9 16/22] drm/meditek: dpi: Add matrix_sel helper

2022-03-27 Thread Guillaume Ranquet
Add a mtk_dpi_matrix_sel() helper to update the DPI_MATRIX_SET
register depending on the color format.

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 8198d3cf23ac..82f97c687652 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -385,6 +385,25 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi 
*dpi)
mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
 }
 
+static void mtk_dpi_matrix_sel(struct mtk_dpi *dpi, enum 
mtk_dpi_out_color_format format)
+{
+   u32 matrix_sel = 0;
+
+   switch (format) {
+   case MTK_DPI_COLOR_FORMAT_YCBCR_422:
+   case MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL:
+   case MTK_DPI_COLOR_FORMAT_YCBCR_444:
+   case MTK_DPI_COLOR_FORMAT_YCBCR_444_FULL:
+   case MTK_DPI_COLOR_FORMAT_XV_YCC:
+   if (dpi->mode.hdisplay <= 720)
+   matrix_sel = 0x2;
+   break;
+   default:
+   break;
+   }
+   mtk_dpi_mask(dpi, DPI_MATRIX_SET, matrix_sel, INT_MATRIX_SEL_MASK);
+}
+
 static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
enum mtk_dpi_out_color_format format)
 {
@@ -392,6 +411,7 @@ static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
(format == MTK_DPI_COLOR_FORMAT_YCBCR_444_FULL)) {
mtk_dpi_config_yuv422_enable(dpi, false);
mtk_dpi_config_csc_enable(dpi, true);
+   mtk_dpi_matrix_sel(dpi, format);
if (dpi->conf->swap_input_support)
mtk_dpi_config_swap_input(dpi, false);
mtk_dpi_config_channel_swap(dpi, MTK_DPI_OUT_CHANNEL_SWAP_BGR);
@@ -399,6 +419,7 @@ static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
   (format == MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL)) {
mtk_dpi_config_yuv422_enable(dpi, true);
mtk_dpi_config_csc_enable(dpi, true);
+   mtk_dpi_matrix_sel(dpi, format);
if (dpi->conf->swap_input_support)
mtk_dpi_config_swap_input(dpi, true);
mtk_dpi_config_channel_swap(dpi, MTK_DPI_OUT_CHANNEL_SWAP_RGB);
-- 
2.34.1



[PATCH v9 08/22] drm/mediatek: dpi: implement a CK/DE pol toggle in SoC config

2022-03-27 Thread Guillaume Ranquet
Adds a bit of flexibility to support SoCs without CK/DE pol support

Signed-off-by: Guillaume Ranquet 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 4746eb342567..545a1337cc89 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -125,6 +125,7 @@ struct mtk_dpi_conf {
bool edge_sel_en;
const u32 *output_fmts;
u32 num_output_fmts;
+   bool is_ck_de_pol;
const struct mtk_dpi_yc_limit *limit;
 };
 
@@ -211,13 +212,20 @@ static void mtk_dpi_config_pol(struct mtk_dpi *dpi,
   struct mtk_dpi_polarities *dpi_pol)
 {
unsigned int pol;
+   unsigned int mask;
 
-   pol = (dpi_pol->ck_pol == MTK_DPI_POLARITY_RISING ? 0 : CK_POL) |
- (dpi_pol->de_pol == MTK_DPI_POLARITY_RISING ? 0 : DE_POL) |
- (dpi_pol->hsync_pol == MTK_DPI_POLARITY_RISING ? 0 : HSYNC_POL) |
+   mask = HSYNC_POL | VSYNC_POL;
+   pol = (dpi_pol->hsync_pol == MTK_DPI_POLARITY_RISING ? 0 : HSYNC_POL) |
  (dpi_pol->vsync_pol == MTK_DPI_POLARITY_RISING ? 0 : VSYNC_POL);
-   mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, pol,
-CK_POL | DE_POL | HSYNC_POL | VSYNC_POL);
+   if (dpi->conf->is_ck_de_pol) {
+   mask |= CK_POL | DE_POL;
+   pol |= (dpi_pol->ck_pol == MTK_DPI_POLARITY_RISING ?
+   0 : CK_POL) |
+  (dpi_pol->de_pol == MTK_DPI_POLARITY_RISING ?
+   0 : DE_POL);
+   }
+
+   mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, pol, mask);
 }
 
 static void mtk_dpi_config_3d(struct mtk_dpi *dpi, bool en_3d)
@@ -799,6 +807,7 @@ static const struct mtk_dpi_conf mt8173_conf = {
.max_clock_khz = 30,
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
+   .is_ck_de_pol = true,
.limit = _dpi_limit,
 };
 
@@ -809,6 +818,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.max_clock_khz = 15,
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
+   .is_ck_de_pol = true,
.limit = _dpi_limit,
 };
 
@@ -818,6 +828,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.max_clock_khz = 10,
.output_fmts = mt8183_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
+   .is_ck_de_pol = true,
.limit = _dpi_limit,
 };
 
@@ -827,6 +838,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.max_clock_khz = 15,
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
+   .is_ck_de_pol = true,
.limit = _dpi_limit,
 };
 
-- 
2.34.1



[PATCH v9 15/22] drm/mediatek: dpi: Add dpintf support

2022-03-27 Thread Guillaume Ranquet
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.

This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
 - Some features/functional components are not available for dpintf
   which are now excluded from code execution once is_dpintf is set
 - dpintf can and needs to choose between different clockdividers based
   on the clockspeed. This is done by choosing a different clock parent.
 - There are two additional clocks that need to be managed. These are
   only set for dpintf and will be set to NULL if not supplied. The
   clk_* calls handle these as normal clocks then.
 - Some register contents differ slightly between the two components. To
   work around this I added register bits/masks with a DPINTF_ prefix
   and use them where different.

Based on a separate driver for dpintf created by
Jason-JH.Lin .

Signed-off-by: Markus Schneider-Pargmann 
Signed-off-by: Guillaume Ranquet 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 78 ++---
 drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 38 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  8 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  5 +-
 include/linux/soc/mediatek/mtk-mmsys.h  |  2 +
 6 files changed, 120 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index eb969c5c5c2e..8198d3cf23ac 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -126,6 +126,7 @@ struct mtk_dpi_conf {
const u32 *output_fmts;
u32 num_output_fmts;
bool is_ck_de_pol;
+   bool is_dpintf;
bool swap_input_support;
/* Mask used for HWIDTH, HPORCH, VSYNC_WIDTH and VSYNC_PORCH (no shift) 
*/
u32 dimension_mask;
@@ -498,11 +499,11 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 
vm.pixelclock = pll_rate / factor;
if ((dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_LE) ||
-   (dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_BE))
+(dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_BE)) {
clk_set_rate(dpi->pixel_clk, vm.pixelclock * 2);
-   else
+   } else {
clk_set_rate(dpi->pixel_clk, vm.pixelclock);
-
+   }
 
vm.pixelclock = clk_get_rate(dpi->pixel_clk);
 
@@ -515,9 +516,15 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
MTK_DPI_POLARITY_FALLING : MTK_DPI_POLARITY_RISING;
dpi_pol.vsync_pol = vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ?
MTK_DPI_POLARITY_FALLING : MTK_DPI_POLARITY_RISING;
-   hsync.sync_width = vm.hsync_len;
-   hsync.back_porch = vm.hback_porch;
-   hsync.front_porch = vm.hfront_porch;
+   if (dpi->conf->is_dpintf) {
+   hsync.sync_width = vm.hsync_len / 4;
+   hsync.back_porch = vm.hback_porch / 4;
+   hsync.front_porch = vm.hfront_porch / 4;
+   } else {
+   hsync.sync_width = vm.hsync_len;
+   hsync.back_porch = vm.hback_porch;
+   hsync.front_porch = vm.hfront_porch;
+   }
hsync.shift_half_line = false;
vsync_lodd.sync_width = vm.vsync_len;
vsync_lodd.back_porch = vm.vback_porch;
@@ -559,13 +566,20 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
mtk_dpi_config_channel_limit(dpi);
mtk_dpi_config_bit_num(dpi, dpi->bit_num);
mtk_dpi_config_channel_swap(dpi, dpi->channel_swap);
-   mtk_dpi_config_yc_map(dpi, dpi->yc_map);
mtk_dpi_config_color_format(dpi, dpi->color_format);
-   mtk_dpi_config_2n_h_fre(dpi);
-   mtk_dpi_dual_edge(dpi);
-   mtk_dpi_config_disable_edge(dpi);
+   if (dpi->conf->is_dpintf) {
+   mtk_dpi_mask(dpi, DPI_CON, DPINTF_INPUT_2P_EN,
+DPINTF_INPUT_2P_EN);
+   } else {
+   mtk_dpi_config_yc_map(dpi, dpi->yc_map);
+   mtk_dpi_config_2n_h_fre(dpi);
+   mtk_dpi_dual_edge(dpi);
+   mtk_dpi_config_disable_edge(dpi);
+   }
mtk_dpi_sw_reset(dpi, false);
 
+   mtk_dpi_enable(dpi);
+
return 0;
 }
 
@@ -642,7 +656,10 @@ static int mtk_dpi_bridge_atomic_check(struct drm_bridge 
*bridge,
dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
-   dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
+   if (out_bus_format == MEDIA_BUS_FMT_YUYV8_1X16)
+   dpi->color_format = MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL;
+   else
+   dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
 
return 0;
 }
@@ -801,6 +818,16 @@ static unsigned int mt8183_calculate_factor(int clock)
return 2;
 }
 
+static unsigned 

[PATCH v9 20/22] drm/mediatek: add hpd debounce

2022-03-27 Thread Guillaume Ranquet
From: Jitao Shi 

>From the DP spec 1.4a chapter 3.3, upstream devices should implement
HPD signal de-bouncing on an external connection.
A period of 100ms should be used to detect an HPD connect event.
To cover these cases, HPD de-bounce should be implemented only after
HPD low has been detected for at least 100ms.

Therefore,
1. If HPD is low (which means plugging out) for longer than 100ms:
   we need to do de-bouncing (which means we need to wait for 100ms).
2. If HPD low is for less than 100ms:
   we don't need to care about the de-bouncing.

In this patch, we start a 100ms timer and use a need_debounce boolean
to implement the feature.

Two cases when HPD is high:
1. If the timer is expired (>100ms):
   - need_debounce is true.
   - When HPD high (plugging event comes), need_debounce will be true
 and then we need to do de-bouncing (wait for 100ms).
2. If the timer is not expired (<100ms):
   - need_debounce is false.
   - When HPD high (plugging event comes), need_debounce will be false
 and no need to do de-bouncing.

HPD___ __
  ||<-  100ms   ->
  ||
  <-  100ms   ->

Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected.

The change has been successfully tested with the following devices:
- Dell Adapter - USB-C to HDMI
- Acer 1in1 HDMI dongle
- Ugreen 1in1 HDMI dongle
- innowatt HDMI + USB3 hub
- Acer 2in1 HDMI dongle
- Apple 3in1 HDMI dongle (A2119)
- J5Create 3in1 HDMI dongle (JAC379)

Tested-by: Rex-BC Chen 
Reviewed-by: Rex-BC Chen 
Signed-off-by: Jitao Shi 
Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_dp.c | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 9e532408f12e..e099491cc6a4 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -174,6 +174,33 @@ struct mtk_dp {
struct device *codec_dev;
u8 connector_eld[MAX_ELD_BYTES];
struct drm_connector *conn;
+   bool need_debounce;
+   struct timer_list debounce_timer;
+};
+
+enum mtk_dp_sdp_type {
+   MTK_DP_SDP_NONE = 0x00,
+   MTK_DP_SDP_ACM = 0x01,
+   MTK_DP_SDP_ISRC = 0x02,
+   MTK_DP_SDP_AVI = 0x03,
+   MTK_DP_SDP_AUI = 0x04,
+   MTK_DP_SDP_SPD = 0x05,
+   MTK_DP_SDP_MPEG = 0x06,
+   MTK_DP_SDP_NTSC = 0x07,
+   MTK_DP_SDP_VSP = 0x08,
+   MTK_DP_SDP_VSC = 0x09,
+   MTK_DP_SDP_EXT = 0x0A,
+   MTK_DP_SDP_PPS0 = 0x0B,
+   MTK_DP_SDP_PPS1 = 0x0C,
+   MTK_DP_SDP_PPS2 = 0x0D,
+   MTK_DP_SDP_PPS3 = 0x0E,
+   MTK_DP_SDP_DRM = 0x10,
+   MTK_DP_SDP_MAX_NUM
+};
+
+struct mtk_dp_sdp_packet {
+   enum mtk_dp_sdp_type type;
+   struct dp_sdp sdp;
 };
 
 static bool mtk_dp_is_edp(struct mtk_dp *mtk_dp)
@@ -1812,6 +1839,9 @@ static irqreturn_t mtk_dp_hpd_event_thread(int hpd, void 
*dev)
if (event < 0)
return IRQ_HANDLED;
 
+   if (mtk_dp->need_debounce && mtk_dp->train_info.cable_plugged_in)
+   msleep(100);
+
if (mtk_dp->drm_dev) {
dev_info(mtk_dp->dev, "drm_helper_hpd_irq_event\n");
drm_helper_hpd_irq_event(mtk_dp->bridge.dev);
@@ -1890,6 +1920,11 @@ static irqreturn_t mtk_dp_hpd_isr_handler(struct mtk_dp 
*mtk_dp)
}
train_info->cable_state_change = true;
 
+   if (!train_info->cable_plugged_in) {
+   mod_timer(_dp->debounce_timer, jiffies + 
msecs_to_jiffies(100) - 1);
+   mtk_dp->need_debounce = false;
+   }
+
return IRQ_WAKE_THREAD;
 }
 
@@ -2337,6 +2372,13 @@ static const struct drm_bridge_funcs mtk_dp_bridge_funcs 
= {
.detect = mtk_dp_bdg_detect,
 };
 
+static void mtk_dp_debounce_timer(struct timer_list *t)
+{
+   struct mtk_dp *mtk_dp = from_timer(mtk_dp, t, debounce_timer);
+
+   mtk_dp->need_debounce = true;
+}
+
 static int mtk_dp_probe(struct platform_device *pdev)
 {
struct mtk_dp *mtk_dp;
@@ -2394,6 +2436,9 @@ static int mtk_dp_probe(struct platform_device *pdev)
mtk_dp->bridge.of_node = dev->of_node;
mtk_dp->bridge.type = DRM_MODE_CONNECTOR_eDP;
 
+   mtk_dp->need_debounce = true;
+   timer_setup(_dp->debounce_timer, mtk_dp_debounce_timer, 0);
+
mtk_dp->bridge.ops =
DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_HPD;
drm_bridge_add(_dp->bridge);
@@ -2413,6 +2458,7 @@ static int mtk_dp_remove(struct platform_device *pdev)
struct mtk_dp *mtk_dp = platform_get_drvdata(pdev);
 
mtk_dp_video_mute(mtk_dp, true);
+   del_timer_sync(_dp->debounce_timer);
 
pm_runtime_disable(>dev);
 
-- 
2.34.1



[PATCH v9 19/22] drm/mediatek: Add mt8195 External DisplayPort support

2022-03-27 Thread Guillaume Ranquet
This patch adds External DisplayPort support to the mt8195 eDP driver.

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_dp.c | 301 +++---
 1 file changed, 278 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 7cd8459cf719..9e532408f12e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -176,6 +176,11 @@ struct mtk_dp {
struct drm_connector *conn;
 };
 
+static bool mtk_dp_is_edp(struct mtk_dp *mtk_dp)
+{
+   return mtk_dp->next_bridge;
+}
+
 static struct mtk_dp *mtk_dp_from_bridge(struct drm_bridge *b)
 {
return container_of(b, struct mtk_dp, bridge);
@@ -741,6 +746,47 @@ static int mtk_dp_fec_enable(struct mtk_dp *mtk_dp, bool 
enable)
   FEC_EN_DP_TRANS_P0_MASK);
 }
 
+static u32 mtk_dp_swirq_get_clear(struct mtk_dp *mtk_dp)
+{
+   int ret;
+
+   u32 irq_status = mtk_dp_read(mtk_dp, MTK_DP_TRANS_P0_35D0) &
+SW_IRQ_FINAL_STATUS_DP_TRANS_P0_MASK;
+
+   if (irq_status) {
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_TRANS_P0_35C8, irq_status,
+   SW_IRQ_CLR_DP_TRANS_P0_MASK, ret, out);
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_TRANS_P0_35C8, 0,
+   SW_IRQ_CLR_DP_TRANS_P0_MASK, ret, out);
+   }
+
+   return irq_status;
+
+out:
+   return ret;
+}
+
+static u32 mtk_dp_hwirq_get_clear(struct mtk_dp *mtk_dp)
+{
+   int ret;
+
+   u8 irq_status = (mtk_dp_read(mtk_dp, MTK_DP_TRANS_P0_3418) &
+IRQ_STATUS_DP_TRANS_P0_MASK) >>
+   IRQ_STATUS_DP_TRANS_P0_SHIFT;
+
+   if (irq_status) {
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_TRANS_P0_3418, irq_status,
+   IRQ_CLR_DP_TRANS_P0_MASK, ret, out);
+   MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_TRANS_P0_3418, 0,
+   IRQ_CLR_DP_TRANS_P0_MASK, ret, out);
+   }
+
+   return irq_status;
+
+out:
+   return ret;
+}
+
 static int mtk_dp_hwirq_enable(struct mtk_dp *mtk_dp, bool enable)
 {
u32 val = 0;
@@ -932,26 +978,49 @@ static int mtk_dp_get_calibration_data(struct mtk_dp 
*mtk_dp)
return PTR_ERR(buf);
}
 
-   cal_data->glb_bias_trim =
-   check_cal_data_valid(1, 0x1e, (buf[3] >> 27) & 0x1f, 0xf);
-   cal_data->clktx_impse =
-   check_cal_data_valid(1, 0xe, (buf[0] >> 9) & 0xf, 0x8);
-   cal_data->ln_tx_impsel_pmos[0] =
-   check_cal_data_valid(1, 0xe, (buf[2] >> 28) & 0xf, 0x8);
-   cal_data->ln_tx_impsel_nmos[0] =
-   check_cal_data_valid(1, 0xe, (buf[2] >> 24) & 0xf, 0x8);
-   cal_data->ln_tx_impsel_pmos[1] =
-   check_cal_data_valid(1, 0xe, (buf[2] >> 20) & 0xf, 0x8);
-   cal_data->ln_tx_impsel_nmos[1] =
-   check_cal_data_valid(1, 0xe, (buf[2] >> 16) & 0xf, 0x8);
-   cal_data->ln_tx_impsel_pmos[2] =
-   check_cal_data_valid(1, 0xe, (buf[2] >> 12) & 0xf, 0x8);
-   cal_data->ln_tx_impsel_nmos[2] =
-   check_cal_data_valid(1, 0xe, (buf[2] >> 8) & 0xf, 0x8);
-   cal_data->ln_tx_impsel_pmos[3] =
-   check_cal_data_valid(1, 0xe, (buf[2] >> 4) & 0xf, 0x8);
-   cal_data->ln_tx_impsel_nmos[3] =
-   check_cal_data_valid(1, 0xe, buf[2] & 0xf, 0x8);
+   if (mtk_dp_is_edp(mtk_dp)) {
+   cal_data->glb_bias_trim =
+   check_cal_data_valid(1, 0x1e, (buf[3] >> 27) & 0x1f, 
0xf);
+   cal_data->clktx_impse =
+   check_cal_data_valid(1, 0xe, (buf[0] >> 9) & 0xf, 0x8);
+   cal_data->ln_tx_impsel_pmos[0] =
+   check_cal_data_valid(1, 0xe, (buf[2] >> 28) & 0xf, 0x8);
+   cal_data->ln_tx_impsel_nmos[0] =
+   check_cal_data_valid(1, 0xe, (buf[2] >> 24) & 0xf, 0x8);
+   cal_data->ln_tx_impsel_pmos[1] =
+   check_cal_data_valid(1, 0xe, (buf[2] >> 20) & 0xf, 0x8);
+   cal_data->ln_tx_impsel_nmos[1] =
+   check_cal_data_valid(1, 0xe, (buf[2] >> 16) & 0xf, 0x8);
+   cal_data->ln_tx_impsel_pmos[2] =
+   check_cal_data_valid(1, 0xe, (buf[2] >> 12) & 0xf, 0x8);
+   cal_data->ln_tx_impsel_nmos[2] =
+   check_cal_data_valid(1, 0xe, (buf[2] >> 8) & 0xf, 0x8);
+   cal_data->ln_tx_impsel_pmos[3] =
+   check_cal_data_valid(1, 0xe, (buf[2] >> 4) & 0xf, 0x8);
+   cal_data->ln_tx_impsel_nmos[3] =
+   check_cal_data_valid(1, 0xe, buf[2] & 0xf, 0x8);
+   } else {
+   cal_data->glb_bias_trim =
+   check_cal_data_valid(1, 0x1e, (buf[0] >> 27) & 0x1f, 
0xf);
+   cal_data->clktx_impse =
+  

[PATCH v9 09/22] drm/mediatek: dpi: implement a swap_input toggle in SoC config

2022-03-27 Thread Guillaume Ranquet
Adds a bit of flexibility to support SoCs without swap_input support

Signed-off-by: Guillaume Ranquet 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 545a1337cc89..454f8563efae 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -126,6 +126,7 @@ struct mtk_dpi_conf {
const u32 *output_fmts;
u32 num_output_fmts;
bool is_ck_de_pol;
+   bool swap_input_support;
const struct mtk_dpi_yc_limit *limit;
 };
 
@@ -378,18 +379,21 @@ static void mtk_dpi_config_color_format(struct mtk_dpi 
*dpi,
(format == MTK_DPI_COLOR_FORMAT_YCBCR_444_FULL)) {
mtk_dpi_config_yuv422_enable(dpi, false);
mtk_dpi_config_csc_enable(dpi, true);
-   mtk_dpi_config_swap_input(dpi, false);
+   if (dpi->conf->swap_input_support)
+   mtk_dpi_config_swap_input(dpi, false);
mtk_dpi_config_channel_swap(dpi, MTK_DPI_OUT_CHANNEL_SWAP_BGR);
} else if ((format == MTK_DPI_COLOR_FORMAT_YCBCR_422) ||
   (format == MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL)) {
mtk_dpi_config_yuv422_enable(dpi, true);
mtk_dpi_config_csc_enable(dpi, true);
-   mtk_dpi_config_swap_input(dpi, true);
+   if (dpi->conf->swap_input_support)
+   mtk_dpi_config_swap_input(dpi, true);
mtk_dpi_config_channel_swap(dpi, MTK_DPI_OUT_CHANNEL_SWAP_RGB);
} else {
mtk_dpi_config_yuv422_enable(dpi, false);
mtk_dpi_config_csc_enable(dpi, false);
-   mtk_dpi_config_swap_input(dpi, false);
+   if (dpi->conf->swap_input_support)
+   mtk_dpi_config_swap_input(dpi, false);
mtk_dpi_config_channel_swap(dpi, MTK_DPI_OUT_CHANNEL_SWAP_RGB);
}
 }
@@ -808,6 +812,7 @@ static const struct mtk_dpi_conf mt8173_conf = {
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
.is_ck_de_pol = true,
+   .swap_input_support = true,
.limit = _dpi_limit,
 };
 
@@ -819,6 +824,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
.is_ck_de_pol = true,
+   .swap_input_support = true,
.limit = _dpi_limit,
 };
 
@@ -829,6 +835,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.output_fmts = mt8183_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
.is_ck_de_pol = true,
+   .swap_input_support = true,
.limit = _dpi_limit,
 };
 
@@ -839,6 +846,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
.is_ck_de_pol = true,
+   .swap_input_support = true,
.limit = _dpi_limit,
 };
 
-- 
2.34.1



[PATCH v9 10/22] drm/mediatek: dpi: move dimension mask to SoC config

2022-03-27 Thread Guillaume Ranquet
Add flexibility by moving the dimension mask to the SoC config

Signed-off-by: Guillaume Ranquet 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 454f8563efae..bf098f36a466 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -127,6 +127,8 @@ struct mtk_dpi_conf {
u32 num_output_fmts;
bool is_ck_de_pol;
bool swap_input_support;
+   /* Mask used for HWIDTH, HPORCH, VSYNC_WIDTH and VSYNC_PORCH (no shift) 
*/
+   u32 dimension_mask;
const struct mtk_dpi_yc_limit *limit;
 };
 
@@ -156,30 +158,30 @@ static void mtk_dpi_disable(struct mtk_dpi *dpi)
 static void mtk_dpi_config_hsync(struct mtk_dpi *dpi,
 struct mtk_dpi_sync_param *sync)
 {
-   mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH,
-sync->sync_width << HPW, HPW_MASK);
-   mtk_dpi_mask(dpi, DPI_TGEN_HPORCH,
-sync->back_porch << HBP, HBP_MASK);
+   mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH, sync->sync_width << HPW,
+dpi->conf->dimension_mask << HPW);
+   mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->back_porch << HBP,
+dpi->conf->dimension_mask << HBP);
mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->front_porch << HFP,
-HFP_MASK);
+dpi->conf->dimension_mask << HFP);
 }
 
 static void mtk_dpi_config_vsync(struct mtk_dpi *dpi,
 struct mtk_dpi_sync_param *sync,
 u32 width_addr, u32 porch_addr)
 {
-   mtk_dpi_mask(dpi, width_addr,
-sync->sync_width << VSYNC_WIDTH_SHIFT,
-VSYNC_WIDTH_MASK);
mtk_dpi_mask(dpi, width_addr,
 sync->shift_half_line << VSYNC_HALF_LINE_SHIFT,
 VSYNC_HALF_LINE_MASK);
+   mtk_dpi_mask(dpi, width_addr,
+sync->sync_width << VSYNC_WIDTH_SHIFT,
+dpi->conf->dimension_mask << VSYNC_WIDTH_SHIFT);
mtk_dpi_mask(dpi, porch_addr,
 sync->back_porch << VSYNC_BACK_PORCH_SHIFT,
-VSYNC_BACK_PORCH_MASK);
+dpi->conf->dimension_mask << VSYNC_BACK_PORCH_SHIFT);
mtk_dpi_mask(dpi, porch_addr,
 sync->front_porch << VSYNC_FRONT_PORCH_SHIFT,
-VSYNC_FRONT_PORCH_MASK);
+dpi->conf->dimension_mask << VSYNC_FRONT_PORCH_SHIFT);
 }
 
 static void mtk_dpi_config_vsync_lodd(struct mtk_dpi *dpi,
@@ -813,6 +815,7 @@ static const struct mtk_dpi_conf mt8173_conf = {
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
.is_ck_de_pol = true,
.swap_input_support = true,
+   .dimension_mask = HPW_MASK,
.limit = _dpi_limit,
 };
 
@@ -825,6 +828,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
.is_ck_de_pol = true,
.swap_input_support = true,
+   .dimension_mask = HPW_MASK,
.limit = _dpi_limit,
 };
 
@@ -836,6 +840,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
.is_ck_de_pol = true,
.swap_input_support = true,
+   .dimension_mask = HPW_MASK,
.limit = _dpi_limit,
 };
 
@@ -847,6 +852,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
.is_ck_de_pol = true,
.swap_input_support = true,
+   .dimension_mask = HPW_MASK,
.limit = _dpi_limit,
 };
 
-- 
2.34.1



[PATCH v9 13/22] drm/mediatek: dpi: move the yuv422_en_bit to SoC config

2022-03-27 Thread Guillaume Ranquet
Add flexibility by moving the yuv422 en bit to SoC specific config

Signed-off-by: Guillaume Ranquet 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 6d4d8c6ec47d..40254cd9d168 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -132,6 +132,7 @@ struct mtk_dpi_conf {
/* HSIZE and VSIZE mask (no shift) */
u32 hvsize_mask;
u32 channel_swap_shift;
+   u32 yuv422_en_bit;
const struct mtk_dpi_yc_limit *limit;
 };
 
@@ -356,7 +357,8 @@ static void mtk_dpi_config_channel_swap(struct mtk_dpi *dpi,
 
 static void mtk_dpi_config_yuv422_enable(struct mtk_dpi *dpi, bool enable)
 {
-   mtk_dpi_mask(dpi, DPI_CON, enable ? YUV422_EN : 0, YUV422_EN);
+   mtk_dpi_mask(dpi, DPI_CON, enable ? dpi->conf->yuv422_en_bit : 0,
+dpi->conf->yuv422_en_bit);
 }
 
 static void mtk_dpi_config_csc_enable(struct mtk_dpi *dpi, bool enable)
@@ -824,6 +826,7 @@ static const struct mtk_dpi_conf mt8173_conf = {
.dimension_mask = HPW_MASK,
.hvsize_mask = HSIZE_MASK,
.channel_swap_shift = CH_SWAP,
+   .yuv422_en_bit = YUV422_EN,
.limit = _dpi_limit,
 };
 
@@ -839,6 +842,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.dimension_mask = HPW_MASK,
.hvsize_mask = HSIZE_MASK,
.channel_swap_shift = CH_SWAP,
+   .yuv422_en_bit = YUV422_EN,
.limit = _dpi_limit,
 };
 
@@ -853,6 +857,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.dimension_mask = HPW_MASK,
.hvsize_mask = HSIZE_MASK,
.channel_swap_shift = CH_SWAP,
+   .yuv422_en_bit = YUV422_EN,
.limit = _dpi_limit,
 };
 
@@ -867,6 +872,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.dimension_mask = HPW_MASK,
.hvsize_mask = HSIZE_MASK,
.channel_swap_shift = CH_SWAP,
+   .yuv422_en_bit = YUV422_EN,
.limit = _dpi_limit,
 };
 
-- 
2.34.1



[PATCH v9 11/22] drm/mediatek: dpi: move hvsize_mask to SoC config

2022-03-27 Thread Guillaume Ranquet
Add flexibility by moving the hvsize mask to SoC specific config

Signed-off-by: Guillaume Ranquet 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index bf098f36a466..6eeda222a973 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -129,6 +129,8 @@ struct mtk_dpi_conf {
bool swap_input_support;
/* Mask used for HWIDTH, HPORCH, VSYNC_WIDTH and VSYNC_PORCH (no shift) 
*/
u32 dimension_mask;
+   /* HSIZE and VSIZE mask (no shift) */
+   u32 hvsize_mask;
const struct mtk_dpi_yc_limit *limit;
 };
 
@@ -243,8 +245,10 @@ static void mtk_dpi_config_interface(struct mtk_dpi *dpi, 
bool inter)
 
 static void mtk_dpi_config_fb_size(struct mtk_dpi *dpi, u32 width, u32 height)
 {
-   mtk_dpi_mask(dpi, DPI_SIZE, width << HSIZE, HSIZE_MASK);
-   mtk_dpi_mask(dpi, DPI_SIZE, height << VSIZE, VSIZE_MASK);
+   mtk_dpi_mask(dpi, DPI_SIZE, width << HSIZE,
+dpi->conf->hvsize_mask << HSIZE);
+   mtk_dpi_mask(dpi, DPI_SIZE, height << VSIZE,
+dpi->conf->hvsize_mask << VSIZE);
 }
 
 static void mtk_dpi_config_channel_limit(struct mtk_dpi *dpi)
@@ -816,6 +820,7 @@ static const struct mtk_dpi_conf mt8173_conf = {
.is_ck_de_pol = true,
.swap_input_support = true,
.dimension_mask = HPW_MASK,
+   .hvsize_mask = HSIZE_MASK,
.limit = _dpi_limit,
 };
 
@@ -829,6 +834,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.is_ck_de_pol = true,
.swap_input_support = true,
.dimension_mask = HPW_MASK,
+   .hvsize_mask = HSIZE_MASK,
.limit = _dpi_limit,
 };
 
@@ -841,6 +847,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.is_ck_de_pol = true,
.swap_input_support = true,
.dimension_mask = HPW_MASK,
+   .hvsize_mask = HSIZE_MASK,
.limit = _dpi_limit,
 };
 
@@ -853,6 +860,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.is_ck_de_pol = true,
.swap_input_support = true,
.dimension_mask = HPW_MASK,
+   .hvsize_mask = HSIZE_MASK,
.limit = _dpi_limit,
 };
 
-- 
2.34.1



[PATCH v9 14/22] drm/mediatek: dpi: move the csc_enable bit to SoC config

2022-03-27 Thread Guillaume Ranquet
Add flexibility by moving the csc_enable bit to SoC specific config

Signed-off-by: Guillaume Ranquet 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 40254cd9d168..eb969c5c5c2e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -133,6 +133,7 @@ struct mtk_dpi_conf {
u32 hvsize_mask;
u32 channel_swap_shift;
u32 yuv422_en_bit;
+   u32 csc_enable_bit;
const struct mtk_dpi_yc_limit *limit;
 };
 
@@ -363,7 +364,8 @@ static void mtk_dpi_config_yuv422_enable(struct mtk_dpi 
*dpi, bool enable)
 
 static void mtk_dpi_config_csc_enable(struct mtk_dpi *dpi, bool enable)
 {
-   mtk_dpi_mask(dpi, DPI_CON, enable ? CSC_ENABLE : 0, CSC_ENABLE);
+   mtk_dpi_mask(dpi, DPI_CON, enable ? dpi->conf->csc_enable_bit : 0,
+dpi->conf->csc_enable_bit);
 }
 
 static void mtk_dpi_config_swap_input(struct mtk_dpi *dpi, bool enable)
@@ -827,6 +829,7 @@ static const struct mtk_dpi_conf mt8173_conf = {
.hvsize_mask = HSIZE_MASK,
.channel_swap_shift = CH_SWAP,
.yuv422_en_bit = YUV422_EN,
+   .csc_enable_bit = CSC_ENABLE,
.limit = _dpi_limit,
 };
 
@@ -843,6 +846,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.hvsize_mask = HSIZE_MASK,
.channel_swap_shift = CH_SWAP,
.yuv422_en_bit = YUV422_EN,
+   .csc_enable_bit = CSC_ENABLE,
.limit = _dpi_limit,
 };
 
@@ -858,6 +862,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.hvsize_mask = HSIZE_MASK,
.channel_swap_shift = CH_SWAP,
.yuv422_en_bit = YUV422_EN,
+   .csc_enable_bit = CSC_ENABLE,
.limit = _dpi_limit,
 };
 
@@ -873,6 +878,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.hvsize_mask = HSIZE_MASK,
.channel_swap_shift = CH_SWAP,
.yuv422_en_bit = YUV422_EN,
+   .csc_enable_bit = CSC_ENABLE,
.limit = _dpi_limit,
 };
 
-- 
2.34.1



[PATCH v9 17/22] phy: phy-mtk-dp: Add driver for DP phy

2022-03-27 Thread Guillaume Ranquet
From: Markus Schneider-Pargmann 

This is a new driver that supports the integrated DisplayPort phy for
mediatek SoCs, especially the mt8195. The phy is integrated into the
DisplayPort controller and will be created by the mtk-dp driver. This
driver expects a struct regmap to be able to work on the same registers
as the DisplayPort controller. It sets the device data to be the struct
phy so that the DisplayPort controller can easily work with it.

The driver does not have any devicetree bindings because the datasheet
does not list the controller and the phy as distinct units.

The interaction with the controller can be covered by the configure
callback of the phy framework and its displayport parameters.

Signed-off-by: Markus Schneider-Pargmann 
Signed-off-by: Guillaume Ranquet 
---
 MAINTAINERS   |   1 +
 drivers/phy/mediatek/Kconfig  |   8 ++
 drivers/phy/mediatek/Makefile |   1 +
 drivers/phy/mediatek/phy-mtk-dp.c | 201 ++
 4 files changed, 211 insertions(+)
 create mode 100644 drivers/phy/mediatek/phy-mtk-dp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4cc47b2dbdc9..bfca96469d80 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6604,6 +6604,7 @@ L:linux-media...@lists.infradead.org (moderated 
for non-subscribers)
 S: Supported
 F: Documentation/devicetree/bindings/display/mediatek/
 F: drivers/gpu/drm/mediatek/
+F: drivers/phy/mediatek/phy-mtk-dp.c
 F: drivers/phy/mediatek/phy-mtk-hdmi*
 F: drivers/phy/mediatek/phy-mtk-mipi*
 
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 55f8e6c048ab..f7ec86059049 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -55,3 +55,11 @@ config PHY_MTK_MIPI_DSI
select GENERIC_PHY
help
  Support MIPI DSI for Mediatek SoCs.
+
+config PHY_MTK_DP
+   tristate "MediaTek DP-PHY Driver"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on OF
+   select GENERIC_PHY
+   help
+ Support DisplayPort PHY for Mediatek SoCs.
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index ace660fbed3a..4ba1e0650434 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -3,6 +3,7 @@
 # Makefile for the phy drivers.
 #
 
+obj-$(CONFIG_PHY_MTK_DP)   += phy-mtk-dp.o
 obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
 obj-$(CONFIG_PHY_MTK_UFS)  += phy-mtk-ufs.o
 obj-$(CONFIG_PHY_MTK_XSPHY)+= phy-mtk-xsphy.o
diff --git a/drivers/phy/mediatek/phy-mtk-dp.c 
b/drivers/phy/mediatek/phy-mtk-dp.c
new file mode 100644
index ..e5c5494f3636
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-dp.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek DisplayPort PHY driver
+ *
+ * Copyright (c) 2021 BayLibre
+ * Author: Markus Schneider-Pargmann 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PHY_OFFSET 0x1000
+
+#define MTK_DP_PHY_DIG_PLL_CTL_1   (PHY_OFFSET + 0x14)
+#define TPLL_SSC_ENBIT(3)
+
+#define MTK_DP_PHY_DIG_BIT_RATE(PHY_OFFSET + 0x3C)
+#define BIT_RATE_RBR   0
+#define BIT_RATE_HBR   1
+#define BIT_RATE_HBR2  2
+#define BIT_RATE_HBR3  3
+
+#define MTK_DP_PHY_DIG_SW_RST  (PHY_OFFSET + 0x38)
+#define DP_GLB_SW_RST_PHYD BIT(0)
+
+#define MTK_DP_LANE0_DRIVING_PARAM_3   (PHY_OFFSET + 0x138)
+#define MTK_DP_LANE1_DRIVING_PARAM_3   (PHY_OFFSET + 0x238)
+#define MTK_DP_LANE2_DRIVING_PARAM_3   (PHY_OFFSET + 0x338)
+#define MTK_DP_LANE3_DRIVING_PARAM_3   (PHY_OFFSET + 0x438)
+#define XTP_LN_TX_LCTXC0_SW0_PRE0_DEFAULT  BIT(4)
+#define XTP_LN_TX_LCTXC0_SW0_PRE1_DEFAULT  ((BIT(2) | BIT(4)) << 8)
+#define XTP_LN_TX_LCTXC0_SW0_PRE2_DEFAULT  GENMASK(20, 19)
+#define XTP_LN_TX_LCTXC0_SW0_PRE3_DEFAULT  GENMASK(29, 29)
+#define DRIVING_PARAM_3_DEFAULT
(XTP_LN_TX_LCTXC0_SW0_PRE0_DEFAULT | \
+
XTP_LN_TX_LCTXC0_SW0_PRE1_DEFAULT | \
+
XTP_LN_TX_LCTXC0_SW0_PRE2_DEFAULT | \
+
XTP_LN_TX_LCTXC0_SW0_PRE3_DEFAULT)
+
+#define XTP_LN_TX_LCTXC0_SW1_PRE0_DEFAULT  GENMASK(4, 3)
+#define XTP_LN_TX_LCTXC0_SW1_PRE1_DEFAULT  GENMASK(12, 9)
+#define XTP_LN_TX_LCTXC0_SW1_PRE2_DEFAULT  ((BIT(2) | BIT(5)) << 16)
+#define XTP_LN_TX_LCTXC0_SW2_PRE0_DEFAULT  GENMASK(29, 29)
+#define DRIVING_PARAM_4_DEFAULT
(XTP_LN_TX_LCTXC0_SW1_PRE0_DEFAULT | \
+
XTP_LN_TX_LCTXC0_SW1_PRE1_DEFAULT | \
+
XTP_LN_TX_LCTXC0_SW1_PRE2_DEFAULT | \
+

[PATCH v9 06/22] video/hdmi: Add audio_infoframe packing for DP

2022-03-27 Thread Guillaume Ranquet
From: Markus Schneider-Pargmann 

Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.

This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp().
hdmi_audio_infoframe_pack_only() is split into two parts. One of them
packs the payload only and can be used for HDMI and DP.

Signed-off-by: Markus Schneider-Pargmann 
Signed-off-by: Guillaume Ranquet 
---
 drivers/video/hdmi.c   | 82 ++
 include/drm/dp/drm_dp_helper.h |  2 +
 include/linux/hdmi.h   |  7 ++-
 3 files changed, 71 insertions(+), 20 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 947be761dfa4..5f50237554ed 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -21,6 +21,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -381,12 +382,34 @@ static int hdmi_audio_infoframe_check_only(const struct 
hdmi_audio_infoframe *fr
  *
  * Returns 0 on success or a negative error code on failure.
  */
-int hdmi_audio_infoframe_check(struct hdmi_audio_infoframe *frame)
+int hdmi_audio_infoframe_check(const struct hdmi_audio_infoframe *frame)
 {
return hdmi_audio_infoframe_check_only(frame);
 }
 EXPORT_SYMBOL(hdmi_audio_infoframe_check);
 
+static void
+hdmi_audio_infoframe_pack_payload(const struct hdmi_audio_infoframe *frame,
+ u8 *buffer)
+{
+   u8 channels;
+
+   if (frame->channels >= 2)
+   channels = frame->channels - 1;
+   else
+   channels = 0;
+
+   buffer[0] = ((frame->coding_type & 0xf) << 4) | (channels & 0x7);
+   buffer[1] = ((frame->sample_frequency & 0x7) << 2) |
+(frame->sample_size & 0x3);
+   buffer[2] = frame->coding_type_ext & 0x1f;
+   buffer[3] = frame->channel_allocation;
+   buffer[4] = (frame->level_shift_value & 0xf) << 3;
+
+   if (frame->downmix_inhibit)
+   buffer[4] |= BIT(7);
+}
+
 /**
  * hdmi_audio_infoframe_pack_only() - write HDMI audio infoframe to binary 
buffer
  * @frame: HDMI audio infoframe
@@ -404,7 +427,6 @@ EXPORT_SYMBOL(hdmi_audio_infoframe_check);
 ssize_t hdmi_audio_infoframe_pack_only(const struct hdmi_audio_infoframe 
*frame,
   void *buffer, size_t size)
 {
-   unsigned char channels;
u8 *ptr = buffer;
size_t length;
int ret;
@@ -420,28 +442,13 @@ ssize_t hdmi_audio_infoframe_pack_only(const struct 
hdmi_audio_infoframe *frame,
 
memset(buffer, 0, size);
 
-   if (frame->channels >= 2)
-   channels = frame->channels - 1;
-   else
-   channels = 0;
-
ptr[0] = frame->type;
ptr[1] = frame->version;
ptr[2] = frame->length;
ptr[3] = 0; /* checksum */
 
-   /* start infoframe payload */
-   ptr += HDMI_INFOFRAME_HEADER_SIZE;
-
-   ptr[0] = ((frame->coding_type & 0xf) << 4) | (channels & 0x7);
-   ptr[1] = ((frame->sample_frequency & 0x7) << 2) |
-(frame->sample_size & 0x3);
-   ptr[2] = frame->coding_type_ext & 0x1f;
-   ptr[3] = frame->channel_allocation;
-   ptr[4] = (frame->level_shift_value & 0xf) << 3;
-
-   if (frame->downmix_inhibit)
-   ptr[4] |= BIT(7);
+   hdmi_audio_infoframe_pack_payload(frame,
+ ptr + HDMI_INFOFRAME_HEADER_SIZE);
 
hdmi_infoframe_set_checksum(buffer, length);
 
@@ -479,6 +486,43 @@ ssize_t hdmi_audio_infoframe_pack(struct 
hdmi_audio_infoframe *frame,
 }
 EXPORT_SYMBOL(hdmi_audio_infoframe_pack);
 
+/**
+ * hdmi_audio_infoframe_pack_for_dp - Pack a HDMI Audio infoframe for 
DisplayPort
+ *
+ * @frame:  HDMI Audio infoframe
+ * @sdp:secondary data packet for display port. This is filled with the
+ * appropriate: data
+ * @dp_version: Display Port version to be encoded in the header
+ *
+ * Packs a HDMI Audio Infoframe to be sent over Display Port. This function
+ * fills the secondary data packet to be used for Display Port.
+ *
+ * Return: Number of total written bytes or a negative errno on failure.
+ */
+ssize_t
+hdmi_audio_infoframe_pack_for_dp(const struct hdmi_audio_infoframe *frame,
+struct dp_sdp *sdp, u8 dp_version)
+{
+   int ret;
+
+   ret = hdmi_audio_infoframe_check(frame);
+   if (ret)
+   return ret;
+
+   memset(sdp->db, 0, sizeof(sdp->db));
+
+   /* Secondary-data packet header */
+   sdp->sdp_header.HB0 = 0;
+   sdp->sdp_header.HB1 = frame->type;
+   sdp->sdp_header.HB2 = DP_SDP_AUDIO_INFOFRAME_HB2;
+   sdp->sdp_header.HB3 = (dp_version & 0x3f) << 2;
+
+   hdmi_audio_infoframe_pack_payload(frame, sdp->db);
+
+   return frame->length + 4;
+}
+EXPORT_SYMBOL(hdmi_audio_infoframe_pack_for_dp);
+
 /**
  * hdmi_vendor_infoframe_init() - initialize an HDMI vendor infoframe
  * 

[PATCH v9 03/22] dt-bindings: mediatek, dp_phy: Add Display Port PHY binding

2022-03-27 Thread Guillaume Ranquet
This phy controller is embedded in the Display Port Controller on mt8195 SoCs.

Signed-off-by: Guillaume Ranquet 
---
 .../bindings/phy/mediatek,dp-phy.yaml | 43 +++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/mediatek,dp-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/mediatek,dp-phy.yaml 
b/Documentation/devicetree/bindings/phy/mediatek,dp-phy.yaml
new file mode 100644
index ..1f5ffca4e140
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,dp-phy.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2022 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,dp-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Display Port PHY
+
+maintainers:
+  - CK Hu 
+  - Jitao shi 
+
+description: |
+  Device tree bindings for the Mediatek (embedded) Display Port PHY
+  present on some Mediatek SoCs.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt8195-dp-phy
+
+  mediatek,dp-syscon:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: Phandle to the Display Port node.
+
+  "#phy-cells":
+const: 0
+
+required:
+  - compatible
+  - mediatek,dp-syscon
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+dp_phy: dp-phy {
+  compatible = "mediatek,mt8195-dp-phy";
+  mediatek,dp-syscon = <_tx>;
+  #phy-cells = <0>;
+};
-- 
2.34.1



[PATCH v9 04/22] drm/edid: Convert cea_sad helper struct to kernelDoc

2022-03-27 Thread Guillaume Ranquet
Signed-off-by: Guillaume Ranquet 
---
 include/drm/drm_edid.h | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 144c495b99c4..5d4d840b9904 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -359,12 +359,17 @@ struct edid {
 
 #define EDID_PRODUCT_ID(e) ((e)->prod_code[0] | ((e)->prod_code[1] << 8))
 
-/* Short Audio Descriptor */
+/* struct cea_sad - Short Audio Descriptor.
+   @format: See HDMI_AUDIO_CODING_TYPE_*.
+   @channels: max number of channels - 1.
+   @freq: See CEA_SAD_FREQ_*.
+   @byte2: meaning depends on format.
+*/
 struct cea_sad {
u8 format;
-   u8 channels; /* max number of channels - 1 */
+   u8 channels;
u8 freq;
-   u8 byte2; /* meaning depends on format */
+   u8 byte2;
 };
 
 struct drm_encoder;
-- 
2.34.1



[PATCH v9 07/22] drm/mediatek: dpi: move dpi limits to SoC config

2022-03-27 Thread Guillaume Ranquet
Add flexibility by moving the dpi limits to the SoC specific config

Signed-off-by: Guillaume Ranquet 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 4554e2de1430..4746eb342567 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -125,6 +125,7 @@ struct mtk_dpi_conf {
bool edge_sel_en;
const u32 *output_fmts;
u32 num_output_fmts;
+   const struct mtk_dpi_yc_limit *limit;
 };
 
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -235,9 +236,10 @@ static void mtk_dpi_config_fb_size(struct mtk_dpi *dpi, 
u32 width, u32 height)
mtk_dpi_mask(dpi, DPI_SIZE, height << VSIZE, VSIZE_MASK);
 }
 
-static void mtk_dpi_config_channel_limit(struct mtk_dpi *dpi,
-struct mtk_dpi_yc_limit *limit)
+static void mtk_dpi_config_channel_limit(struct mtk_dpi *dpi)
 {
+   const struct mtk_dpi_yc_limit *limit = dpi->conf->limit;
+
mtk_dpi_mask(dpi, DPI_Y_LIMIT, limit->y_bottom << Y_LIMINT_BOT,
 Y_LIMINT_BOT_MASK);
mtk_dpi_mask(dpi, DPI_Y_LIMIT, limit->y_top << Y_LIMINT_TOP,
@@ -449,7 +451,6 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
 static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
struct drm_display_mode *mode)
 {
-   struct mtk_dpi_yc_limit limit;
struct mtk_dpi_polarities dpi_pol;
struct mtk_dpi_sync_param hsync;
struct mtk_dpi_sync_param vsync_lodd = { 0 };
@@ -484,11 +485,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
dev_dbg(dpi->dev, "Got  PLL %lu Hz, pixel clock %lu Hz\n",
pll_rate, vm.pixelclock);
 
-   limit.c_bottom = 0x0010;
-   limit.c_top = 0x0FE0;
-   limit.y_bottom = 0x0010;
-   limit.y_top = 0x0FE0;
-
dpi_pol.ck_pol = MTK_DPI_POLARITY_FALLING;
dpi_pol.de_pol = MTK_DPI_POLARITY_RISING;
dpi_pol.hsync_pol = vm.flags & DISPLAY_FLAGS_HSYNC_HIGH ?
@@ -536,7 +532,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
else
mtk_dpi_config_fb_size(dpi, vm.hactive, vm.vactive);
 
-   mtk_dpi_config_channel_limit(dpi, );
+   mtk_dpi_config_channel_limit(dpi);
mtk_dpi_config_bit_num(dpi, dpi->bit_num);
mtk_dpi_config_channel_swap(dpi, dpi->channel_swap);
mtk_dpi_config_yc_map(dpi, dpi->yc_map);
@@ -790,12 +786,20 @@ static const u32 mt8183_output_fmts[] = {
MEDIA_BUS_FMT_RGB888_2X12_BE,
 };
 
+static const struct mtk_dpi_yc_limit mtk_dpi_limit = {
+   .c_bottom = 0x0010,
+   .c_top = 0x0FE0,
+   .y_bottom = 0x0010,
+   .y_top = 0x0FE0,
+};
+
 static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
.max_clock_khz = 30,
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
+   .limit = _dpi_limit,
 };
 
 static const struct mtk_dpi_conf mt2701_conf = {
@@ -805,6 +809,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.max_clock_khz = 15,
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
+   .limit = _dpi_limit,
 };
 
 static const struct mtk_dpi_conf mt8183_conf = {
@@ -813,6 +818,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.max_clock_khz = 10,
.output_fmts = mt8183_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
+   .limit = _dpi_limit,
 };
 
 static const struct mtk_dpi_conf mt8192_conf = {
@@ -821,6 +827,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.max_clock_khz = 15,
.output_fmts = mt8173_output_fmts,
.num_output_fmts = ARRAY_SIZE(mt8173_output_fmts),
+   .limit = _dpi_limit,
 };
 
 static int mtk_dpi_probe(struct platform_device *pdev)
-- 
2.34.1



[PATCH v9 05/22] drm/edid: Add cea_sad helpers for freq/length

2022-03-27 Thread Guillaume Ranquet
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.

For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.

Signed-off-by: Markus Schneider-Pargmann 
Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/drm_edid.c | 74 ++
 include/drm/drm_edid.h | 14 
 2 files changed, 88 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cc7bd58369df..eeceae4411ba 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4758,6 +4758,80 @@ int drm_edid_to_speaker_allocation(struct edid *edid, u8 
**sadb)
 }
 EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
 
+/**
+ * drm_cea_sad_get_sample_rate - Extract the sample rate from cea_sad
+ * @sad: Pointer to the cea_sad struct
+ *
+ * Extracts the cea_sad frequency field and returns the sample rate in Hz.
+ *
+ * Return: Sample rate in Hz or a negative errno if parsing failed.
+ */
+int drm_cea_sad_get_sample_rate(const struct cea_sad *sad)
+{
+   switch (sad->freq) {
+   case DRM_CEA_SAD_FREQ_32KHZ:
+   return 32000;
+   case DRM_CEA_SAD_FREQ_44KHZ:
+   return 44100;
+   case DRM_CEA_SAD_FREQ_48KHZ:
+   return 48000;
+   case DRM_CEA_SAD_FREQ_88KHZ:
+   return 88200;
+   case DRM_CEA_SAD_FREQ_96KHZ:
+   return 96000;
+   case DRM_CEA_SAD_FREQ_176KHZ:
+   return 176400;
+   case DRM_CEA_SAD_FREQ_192KHZ:
+   return 192000;
+   default:
+   return -EINVAL;
+   }
+}
+EXPORT_SYMBOL(drm_cea_sad_get_sample_rate);
+
+static bool drm_cea_sad_is_uncompressed(const struct cea_sad *sad)
+{
+   switch (sad->format) {
+   case HDMI_AUDIO_CODING_TYPE_STREAM:
+   case HDMI_AUDIO_CODING_TYPE_PCM:
+   return true;
+   default:
+   return false;
+   }
+}
+
+/**
+ * drm_cea_sad_get_uncompressed_word_length - Extract word length
+ * @sad: Pointer to the cea_sad struct
+ *
+ * Extracts the cea_sad byte2 field and returns the word length for an
+ * uncompressed stream.
+ *
+ * Note: This function may only be called for uncompressed audio.
+ *
+ * Return: Word length in bits or a negative errno if parsing failed.
+ */
+int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad *sad)
+{
+   if (!drm_cea_sad_is_uncompressed(sad)) {
+   DRM_WARN("Unable to get the uncompressed word length for a 
compressed format: %u\n",
+sad->format);
+   return -EINVAL;
+   }
+
+   switch (sad->byte2) {
+   case DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT:
+   return 16;
+   case DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT:
+   return 20;
+   case DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT:
+   return 24;
+   default:
+   return -EINVAL;
+   }
+}
+EXPORT_SYMBOL(drm_cea_sad_get_uncompressed_word_length);
+
 /**
  * drm_av_sync_delay - compute the HDMI/DP sink audio-video sync delay
  * @connector: connector associated with the HDMI/DP sink
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 5d4d840b9904..ebd00ecae205 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -372,6 +372,18 @@ struct cea_sad {
u8 byte2;
 };
 
+#define DRM_CEA_SAD_FREQ_32KHZ  BIT(0)
+#define DRM_CEA_SAD_FREQ_44KHZ  BIT(1)
+#define DRM_CEA_SAD_FREQ_48KHZ  BIT(2)
+#define DRM_CEA_SAD_FREQ_88KHZ  BIT(3)
+#define DRM_CEA_SAD_FREQ_96KHZ  BIT(4)
+#define DRM_CEA_SAD_FREQ_176KHZ BIT(5)
+#define DRM_CEA_SAD_FREQ_192KHZ BIT(6)
+
+#define DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT BIT(0)
+#define DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT BIT(1)
+#define DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT BIT(2)
+
 struct drm_encoder;
 struct drm_connector;
 struct drm_connector_state;
@@ -379,6 +391,8 @@ struct drm_display_mode;
 
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
 int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
+int drm_cea_sad_get_sample_rate(const struct cea_sad *sad);
+int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad *sad);
 int drm_av_sync_delay(struct drm_connector *connector,
  const struct drm_display_mode *mode);
 
-- 
2.34.1



[PATCH v9 02/22] dt-bindings: mediatek,dp: Add Display Port binding

2022-03-27 Thread Guillaume Ranquet
From: Markus Schneider-Pargmann 

This controller is present on several mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible field is added.

The controller can have two forms, as a normal display port and as an
embedded display port.

Signed-off-by: Markus Schneider-Pargmann 
Signed-off-by: Guillaume Ranquet 
---
 .../display/mediatek/mediatek,dp.yaml | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
new file mode 100644
index ..802cc406c72b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,dp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Display Port Controller
+
+maintainers:
+  - CK Hu 
+  - Jitao shi 
+
+description: |
+  Device tree bindings for the Mediatek (embedded) Display Port controller
+  present on some Mediatek SoCs.
+
+properties:
+  compatible:
+items:
+  - const: mediatek,mt8195-dp-tx
+  - const: syscon
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: faxi clock
+
+  clock-names:
+items:
+  - const: faxi
+
+  phys:
+maxItems: 1
+
+  phy-names:
+items:
+  - const: dp
+
+  power-domains:
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input endpoint of the controller, usually dp_intf
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output endpoint of the controller
+
+required:
+  - port@0
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+edp_tx: edisplay-port-tx@1c50 {
+compatible = "mediatek,mt8195-dp-tx","syscon";
+reg = <0 0x1c50 0 0x8000>;
+interrupts = ;
+power-domains = < MT8195_POWER_DOMAIN_EPD_TX>;
+pinctrl-names = "default";
+pinctrl-0 = <_pin>;
+phys = <_phy>;
+phy-names = "dp";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+edp_in: endpoint {
+remote-endpoint = <_intf0_out>;
+};
+};
+port@1 {
+reg = <1>;
+edp_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
-- 
2.34.1



[PATCH v9 01/22] dt-bindings: mediatek,dpi: Add DP_INTF compatible

2022-03-27 Thread Guillaume Ranquet
From: Markus Schneider-Pargmann 

DP_INTF is similar to DPI but does not have the exact same feature set
or register layouts.

DP_INTF is the sink of the display pipeline that is connected to the
DisplayPort controller and encoder unit. It takes the same clocks as
DPI.

Signed-off-by: Markus Schneider-Pargmann 
Signed-off-by: Guillaume Ranquet 
Reviewed-by: Rob Herring 
---
 .../bindings/display/mediatek/mediatek,dpi.yaml   | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index dd2896a40ff0..2dba80ad3b18 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -4,16 +4,16 @@
 $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: mediatek DPI Controller Device Tree Bindings
+title: mediatek DPI/DP_INTF Controller
 
 maintainers:
   - CK Hu 
   - Jitao shi 
 
 description: |
-  The Mediatek DPI function block is a sink of the display subsystem and
-  provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
-  output bus.
+  The Mediatek DPI and DP_INTF function blocks are a sink of the display
+  subsystem and provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a
+  parallel output bus.
 
 properties:
   compatible:
@@ -23,6 +23,7 @@ properties:
   - mediatek,mt8173-dpi
   - mediatek,mt8183-dpi
   - mediatek,mt8192-dpi
+  - mediatek,mt8195-dpintf
 
   reg:
 maxItems: 1
@@ -54,7 +55,7 @@ properties:
 $ref: /schemas/graph.yaml#/properties/port
 description:
   Output port node. This port should be connected to the input port of an
-  attached HDMI or LVDS encoder chip.
+  attached HDMI, LVDS or DisplayPort encoder chip.
 
 required:
   - compatible
-- 
2.34.1



[PATCH 00/22] drm/mediatek: Add mt8195 DisplayPort driver

2022-03-27 Thread Guillaume Ranquet
this series is built around the DisplayPort driver. The dpi/dpintf
driver and the added helper functions are required for the DisplayPort
driver to work.

This v9 is not quite ready yet, as project constraints forces me to
publish v9 this week, I'm sorry if it's not standard practice.

Moreover, it is still un-tested on a recent kernel.
The integration kernel we are using is still based on 5.10... but we
are actively working on bringing up a mt8195 integration branch on 5.17.
The patches have been rebased on top of next-20220301 and have been
tested to build sucessfully (no functional testing).

Changes from v8:
- The DP-Phy now has its own dt-bindings and now shares a regmap using the
  syscon facility with the DP driver.
- hot plug detection has been removed from the Embedded Display Port.
  patch and moved to the patch adding External Display Port support.
- started working on better error handling for the mtk_dp driver.
- rebased on linux-next.
- removal of tvd pll clocks re-introduced by mistake.
- various coding style fixes.

Things that are in my todolist for v10:
- fixing the train_handler in the mtk_dp driver, as I haven't been able
  to reproduce locally (hopefully migrating to running the tests on a
  more recent kernel will help)
- explaining the various sleep/delays introduced in the drivers
- explaining some of the differences between mt8195 and "legacy"
- retrieve CK/DE support from panel driver instead of hardcoding it into
  the dpi driver.
- better error handling/reporting in mtk_dp
- look into re-implementing mtk_dp_aux_transfer() using drm_dp_dpcd_read and
  drm_dp_dpcd_write as suggested by Rex.

Older revisions:
RFC - 
https://lore.kernel.org/linux-mediatek/20210816192523.1739365-1-...@baylibre.com/
v1  - 
https://lore.kernel.org/linux-mediatek/20210906193529.718845-1-...@baylibre.com/
v2  - 
https://lore.kernel.org/linux-mediatek/20210920084424.231825-1-...@baylibre.com/
v3  - 
https://lore.kernel.org/linux-mediatek/20211001094443.2770169-1-...@baylibre.com/
v4  - 
https://lore.kernel.org/linux-mediatek/20211011094624.3416029-1-...@baylibre.com/
v5  - https://lore.kernel.org/all/20211021092707.3562523-1-...@baylibre.com/
v6  - 
https://lore.kernel.org/linux-mediatek/2020130623.20553-1-granq...@baylibre.com/
v7  - 
https://lore.kernel.org/linux-mediatek/20211217150854.2081-1-granq...@baylibre.com/
v8  - 
https://lore.kernel.org/linux-mediatek/20220218145437.18563-1-granq...@baylibre.com/

Functional dependencies are:
- Add Mediatek Soc DRM (vdosys0) support for mt8195
  https://lore.kernel.org/all/20211026155911.17651-1-jason-jh@mediatek.com/
- Add MediaTek SoC DRM (vdosys1) support for mt8195
  https://lore.kernel.org/all/20211029075203.17093-1-nancy@mediatek.com/

Guillaume Ranquet (15):
  dt-bindings: mediatek,dp_phy: Add Display Port PHY binding
  drm/edid: Convert cea_sad helper struct to kernelDoc
  drm/edid: Add cea_sad helpers for freq/length
  drm/mediatek: dpi: move dpi limits to SoC config
  drm/mediatek: dpi: implement a CK/DE pol toggle in SoC config
  drm/mediatek: dpi: implement a swap_input toggle in SoC config
  drm/mediatek: dpi: move dimension mask to SoC config
  drm/mediatek: dpi: move hvsize_mask to SoC config
  drm/mediatek: dpi: move swap_shift to SoC config
  drm/mediatek: dpi: move the yuv422_en_bit to SoC config
  drm/mediatek: dpi: move the csc_enable bit to SoC config
  drm/mediatek: dpi: Add dpintf support
  drm/meditek: dpi: Add matrix_sel helper
  drm/mediatek: Add mt8195 External DisplayPort support
  drm/mediatek: DP audio support for mt8195

Jitao Shi (2):
  drm/mediatek: add hpd debounce
  drm/mediatek: change the aux retries times when receiving AUX_DEFER

Markus Schneider-Pargmann (5):
  dt-bindings: mediatek,dpi: Add DP_INTF compatible
  dt-bindings: mediatek,dp: Add Display Port binding
  video/hdmi: Add audio_infoframe packing for DP
  phy: phy-mtk-dp: Add driver for DP phy
  drm/mediatek: Add mt8195 Embedded DisplayPort driver

 .../display/mediatek/mediatek,dp.yaml |   97 +
 .../display/mediatek/mediatek,dpi.yaml|   11 +-
 .../bindings/phy/mediatek,dp-phy.yaml |   43 +
 MAINTAINERS   |1 +
 drivers/gpu/drm/drm_edid.c|   74 +
 drivers/gpu/drm/mediatek/Kconfig  |8 +
 drivers/gpu/drm/mediatek/Makefile |2 +
 drivers/gpu/drm/mediatek/mtk_dp.c | 3204 +
 drivers/gpu/drm/mediatek/mtk_dp_reg.h |  568 +++
 drivers/gpu/drm/mediatek/mtk_dpi.c|  222 +-
 drivers/gpu/drm/mediatek/mtk_dpi_regs.h   |   38 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |8 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   |1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c|6 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h|1 +
 drivers/phy/mediatek/Kconfig  |8 +
 drivers/phy/mediatek/Makefile |1 +
 drivers/phy/mediatek/phy-mtk-dp.c |  

[PATCH 4/4] drm/msm/adreno: add support for a730

2022-03-27 Thread Jonathan Marek
Based on a6xx_gpu.c, stripped down and updated for a7xx based on the
downstream driver. Implements the minimum to be able to submit commands to
the GPU and use it for userspace driver development. Notably this doesn't
implement support for the GMU (this means that the clock driver needs to
support the GPU core clock and turning on the GX rail, which is normally
offloaded to the GMU).

Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/adreno/a7xx_gpu.c   | 777 
 drivers/gpu/drm/msm/adreno/a7xx_gpu.h   |  26 +
 drivers/gpu/drm/msm/adreno/adreno_device.c  |  12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   3 +-
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h |  20 +-
 drivers/gpu/drm/msm/msm_ringbuffer.h|   1 +
 7 files changed, 820 insertions(+), 20 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a7xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a7xx_gpu.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index e9cc7d8ac301e..b91e543e42265 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -16,6 +16,7 @@ msm-y := \
adreno/a6xx_gpu.o \
adreno/a6xx_gmu.o \
adreno/a6xx_hfi.o \
+   adreno/a7xx_gpu.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a7xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a7xx_gpu.c
new file mode 100644
index 0..16bdce21b06f2
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a7xx_gpu.c
@@ -0,0 +1,777 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2022 The Linux Foundation. All rights reserved. */
+
+#include "msm_gem.h"
+#include "msm_mmu.h"
+#include "msm_gpu_trace.h"
+#include "a7xx_gpu.h"
+
+#include 
+
+extern bool hang_debug;
+
+#define GPU_PAS_ID 13
+
+static inline bool _a7xx_check_idle(struct msm_gpu *gpu)
+{
+   /* Check that the CX master is idle */
+   if (gpu_read(gpu, REG_A7XX_RBBM_STATUS) & 
~A7XX_RBBM_STATUS_CPAHBBUSYCXMASTER)
+   return false;
+
+   return !(gpu_read(gpu, REG_A7XX_RBBM_INT_0_STATUS) & 
A7XX_RBBM_INT_0_MASK_HANGDETECTINTERRUPT);
+}
+
+static bool a7xx_idle(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
+{
+   /* wait for CP to drain ringbuffer: */
+   if (!adreno_idle(gpu, ring))
+   return false;
+
+   if (spin_until(_a7xx_check_idle(gpu))) {
+   DRM_ERROR("%s: %ps: timeout waiting for GPU to idle: status 
%8.8X irq %8.8X rptr/wptr %d/%d\n",
+   gpu->name, __builtin_return_address(0),
+   gpu_read(gpu, REG_A7XX_RBBM_STATUS),
+   gpu_read(gpu, REG_A7XX_RBBM_INT_0_STATUS),
+   gpu_read(gpu, REG_A7XX_CP_RB_RPTR),
+   gpu_read(gpu, REG_A7XX_CP_RB_WPTR));
+   return false;
+   }
+
+   return true;
+}
+
+static void a7xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
+{
+   struct msm_ringbuffer *ring = submit->ring;
+   unsigned int i;
+
+   OUT_PKT7(ring, CP_THREAD_CONTROL, 1);
+   OUT_RING(ring, CP_SET_THREAD_BOTH);
+
+   OUT_PKT7(ring, CP_SET_MARKER, 1);
+   OUT_RING(ring, 0x101); /* IFPC disable */
+
+   OUT_PKT7(ring, CP_SET_MARKER, 1);
+   OUT_RING(ring, 0x00d); /* IB1LIST start */
+
+   /* Submit the commands */
+   for (i = 0; i < submit->nr_cmds; i++) {
+   switch (submit->cmd[i].type) {
+   case MSM_SUBMIT_CMD_IB_TARGET_BUF:
+   break;
+   case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
+   if (gpu->cur_ctx_seqno == submit->queue->ctx->seqno)
+   break;
+   fallthrough;
+   case MSM_SUBMIT_CMD_BUF:
+   OUT_PKT7(ring, CP_INDIRECT_BUFFER_PFE, 3);
+   OUT_RING(ring, lower_32_bits(submit->cmd[i].iova));
+   OUT_RING(ring, upper_32_bits(submit->cmd[i].iova));
+   OUT_RING(ring, submit->cmd[i].size);
+   break;
+   }
+   }
+
+   OUT_PKT7(ring, CP_SET_MARKER, 1);
+   OUT_RING(ring, 0x00e); /* IB1LIST end */
+
+   OUT_PKT7(ring, CP_THREAD_CONTROL, 1);
+   OUT_RING(ring, CP_SET_THREAD_BR);
+
+   OUT_PKT7(ring, CP_EVENT_WRITE, 1);
+   OUT_RING(ring, CCU_INVALIDATE_DEPTH);
+
+   OUT_PKT7(ring, CP_EVENT_WRITE, 1);
+   OUT_RING(ring, CCU_INVALIDATE_COLOR);
+
+   OUT_PKT7(ring, CP_THREAD_CONTROL, 1);
+   OUT_RING(ring, CP_SET_THREAD_BV);
+
+   /*
+* Make sure the timestamp is committed once BV pipe is
+* completely done with this submission.
+*/
+   OUT_PKT7(ring, CP_EVENT_WRITE, 4);
+   OUT_RING(ring, CACHE_CLEAN | BIT(27));
+   OUT_RING(ring, lower_32_bits(rbmemptr(ring, bv_fence)));
+   OUT_RING(ring, upper_32_bits(rbmemptr(ring, 

[PATCH 3/4] drm/msm/adreno: update headers

2022-03-27 Thread Jonathan Marek
Adds a7xx changes for the kernel driver.

Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/adreno/a7xx.xml.h   | 666 
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h |  63 +-
 2 files changed, 716 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a7xx.xml.h

diff --git a/drivers/gpu/drm/msm/adreno/a7xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a7xx.xml.h
new file mode 100644
index 0..45ef4289ac52b
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a7xx.xml.h
@@ -0,0 +1,666 @@
+#ifndef A7XX_XML
+#define A7XX_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://github.com/freedreno/envytools/
+git clone https://github.com/freedreno/envytools.git
+
+The rules-ng-ng source files this header was generated from are:
+- freedreno/registers/adreno.xml (627 bytes, from 
2022-03-27 15:04:47)
+- freedreno/registers/freedreno_copyright.xml(   1572 bytes, from 
2020-11-18 00:17:12)
+- freedreno/registers/adreno/a2xx.xml(  90810 bytes, from 
2021-08-06 17:44:41)
+- freedreno/registers/adreno/adreno_common.xml   (  14631 bytes, from 
2022-03-27 14:52:08)
+- freedreno/registers/adreno/adreno_pm4.xml  (  70334 bytes, from 
2022-03-27 20:01:26)
+- freedreno/registers/adreno/a3xx.xml(  84231 bytes, from 
2021-08-27 13:03:56)
+- freedreno/registers/adreno/a4xx.xml( 113474 bytes, from 
2022-03-22 19:23:46)
+- freedreno/registers/adreno/a5xx.xml( 149512 bytes, from 
2022-03-21 16:05:18)
+- freedreno/registers/adreno/a6xx.xml( 184954 bytes, from 
2022-03-22 19:23:46)
+- freedreno/registers/adreno/a6xx_gmu.xml(  11331 bytes, from 
2021-08-06 17:44:41)
+- freedreno/registers/adreno/a7xx.xml(  20004 bytes, from 
2022-03-27 20:01:42)
+- freedreno/registers/adreno/ocmem.xml   (   1773 bytes, from 
2020-11-18 00:17:12)
+- freedreno/registers/adreno/adreno_control_regs.xml (   6038 bytes, from 
2022-03-22 19:23:46)
+- freedreno/registers/adreno/adreno_pipe_regs.xml(   2924 bytes, from 
2022-03-22 19:23:46)
+
+Copyright (C) 2013-2022 by the following authors:
+- Rob Clark  (robclark)
+- Ilia Mirkin  (imirkin)
+
+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 (including the
+next paragraph) 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 OWNER(S) AND/OR ITS SUPPLIERS 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.
+*/
+
+
+enum a7xx_event {
+   CCU_INVALIDATE_DEPTH = 24,
+   CCU_INVALIDATE_COLOR = 25,
+   CCU_RESOLVE_CLEAN = 26,
+   CCU_FLUSH_DEPTH = 28,
+   CCU_FLUSH_COLOR = 29,
+   CCU_RESOLVE = 30,
+   CCU_END_RESOLVE_GROUP = 31,
+   CCU_CLEAN_DEPTH = 32,
+   CCU_CLEAN_COLOR = 33,
+   CACHE_RESET = 48,
+   CACHE_CLEAN = 49,
+   CACHE_FLUSH7 = 50,
+   CACHE_INVALIDATE7 = 51,
+};
+
+#define REG_A7XX_RBBM_GBIF_CLIENT_QOS_CNTL 0x0011
+
+#define REG_A7XX_RBBM_GBIF_HALT
0x0016
+
+#define REG_A7XX_RBBM_GBIF_HALT_ACK0x0017
+
+#define REG_A7XX_RBBM_INTERFACE_HANG_INT_CNTL  0x001f
+
+#define REG_A7XX_RBBM_INT_CLEAR_CMD0x0037
+
+#define REG_A7XX_RBBM_INT_0_MASK   0x0038
+#define A7XX_RBBM_INT_0_MASK_GPUIDLE   0x0001
+#define A7XX_RBBM_INT_0_MASK_AHBERROR  0x0002
+#define A7XX_RBBM_INT_0_MASK_CPIPCINT0 0x0010
+#define A7XX_RBBM_INT_0_MASK_CPIPCINT1 0x0020
+#define A7XX_RBBM_INT_0_MASK_ATBASYNCFIFOOVERFLOW  0x0040
+#define A7XX_RBBM_INT_0_MASK_GPCERROR  0x0080
+#define A7XX_RBBM_INT_0_MASK_SWINTERRUPT   0x0100
+#define A7XX_RBBM_INT_0_MASK_HWERROR   0x0200
+#define A7XX_RBBM_INT_0_MASK_CCU_CLEAN_DEPTH_TS

[PATCH 2/4] drm/msm/adreno: use a single register offset for gpu_read64/gpu_write64

2022-03-27 Thread Jonathan Marek
The high half of 64-bit registers is always at +1 offset, so change these
helpers to be more convenient by removing the unnecessary argument.

Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  3 +--
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 27 -
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c   |  4 +--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   | 25 ++-
 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c |  3 +--
 drivers/gpu/drm/msm/msm_gpu.h   | 12 -
 6 files changed, 27 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 0c6b2a6d0b4c9..da5e18bd74a45 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -606,8 +606,7 @@ static int a4xx_pm_suspend(struct msm_gpu *gpu) {
 
 static int a4xx_get_timestamp(struct msm_gpu *gpu, uint64_t *value)
 {
-   *value = gpu_read64(gpu, REG_A4XX_RBBM_PERFCTR_CP_0_LO,
-   REG_A4XX_RBBM_PERFCTR_CP_0_HI);
+   *value = gpu_read64(gpu, REG_A4XX_RBBM_PERFCTR_CP_0_LO);
 
return 0;
 }
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 407f50a15faa4..1916cb759cd5c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -605,11 +605,9 @@ static int a5xx_ucode_init(struct msm_gpu *gpu)
a5xx_ucode_check_version(a5xx_gpu, a5xx_gpu->pfp_bo);
}
 
-   gpu_write64(gpu, REG_A5XX_CP_ME_INSTR_BASE_LO,
-   REG_A5XX_CP_ME_INSTR_BASE_HI, a5xx_gpu->pm4_iova);
+   gpu_write64(gpu, REG_A5XX_CP_ME_INSTR_BASE_LO, a5xx_gpu->pm4_iova);
 
-   gpu_write64(gpu, REG_A5XX_CP_PFP_INSTR_BASE_LO,
-   REG_A5XX_CP_PFP_INSTR_BASE_HI, a5xx_gpu->pfp_iova);
+   gpu_write64(gpu, REG_A5XX_CP_PFP_INSTR_BASE_LO, a5xx_gpu->pfp_iova);
 
return 0;
 }
@@ -868,8 +866,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
 * memory rendering at this point in time and we don't want to block off
 * part of the virtual memory space.
 */
-   gpu_write64(gpu, REG_A5XX_RBBM_SECVID_TSB_TRUSTED_BASE_LO,
-   REG_A5XX_RBBM_SECVID_TSB_TRUSTED_BASE_HI, 0x);
+   gpu_write64(gpu, REG_A5XX_RBBM_SECVID_TSB_TRUSTED_BASE_LO, 0x);
gpu_write(gpu, REG_A5XX_RBBM_SECVID_TSB_TRUSTED_SIZE, 0x);
 
/* Put the GPU into 64 bit by default */
@@ -908,8 +905,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
return ret;
 
/* Set the ringbuffer address */
-   gpu_write64(gpu, REG_A5XX_CP_RB_BASE, REG_A5XX_CP_RB_BASE_HI,
-   gpu->rb[0]->iova);
+   gpu_write64(gpu, REG_A5XX_CP_RB_BASE, gpu->rb[0]->iova);
 
/*
 * If the microcode supports the WHERE_AM_I opcode then we can use that
@@ -936,7 +932,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
}
 
gpu_write64(gpu, REG_A5XX_CP_RB_RPTR_ADDR,
-   REG_A5XX_CP_RB_RPTR_ADDR_HI, shadowptr(a5xx_gpu, 
gpu->rb[0]));
+   shadowptr(a5xx_gpu, gpu->rb[0]));
} else if (gpu->nr_rings > 1) {
/* Disable preemption if WHERE_AM_I isn't available */
a5xx_preempt_fini(gpu);
@@ -1239,9 +1235,9 @@ static void a5xx_fault_detect_irq(struct msm_gpu *gpu)
gpu_read(gpu, REG_A5XX_RBBM_STATUS),
gpu_read(gpu, REG_A5XX_CP_RB_RPTR),
gpu_read(gpu, REG_A5XX_CP_RB_WPTR),
-   gpu_read64(gpu, REG_A5XX_CP_IB1_BASE, REG_A5XX_CP_IB1_BASE_HI),
+   gpu_read64(gpu, REG_A5XX_CP_IB1_BASE),
gpu_read(gpu, REG_A5XX_CP_IB1_BUFSZ),
-   gpu_read64(gpu, REG_A5XX_CP_IB2_BASE, REG_A5XX_CP_IB2_BASE_HI),
+   gpu_read64(gpu, REG_A5XX_CP_IB2_BASE),
gpu_read(gpu, REG_A5XX_CP_IB2_BUFSZ));
 
/* Turn off the hangcheck timer to keep it from bothering us */
@@ -1427,8 +1423,7 @@ static int a5xx_pm_suspend(struct msm_gpu *gpu)
 
 static int a5xx_get_timestamp(struct msm_gpu *gpu, uint64_t *value)
 {
-   *value = gpu_read64(gpu, REG_A5XX_RBBM_ALWAYSON_COUNTER_LO,
-   REG_A5XX_RBBM_ALWAYSON_COUNTER_HI);
+   *value = gpu_read64(gpu, REG_A5XX_RBBM_ALWAYSON_COUNTER_LO);
 
return 0;
 }
@@ -1465,8 +1460,7 @@ static int a5xx_crashdumper_run(struct msm_gpu *gpu,
if (IS_ERR_OR_NULL(dumper->ptr))
return -EINVAL;
 
-   gpu_write64(gpu, REG_A5XX_CP_CRASH_SCRIPT_BASE_LO,
-   REG_A5XX_CP_CRASH_SCRIPT_BASE_HI, dumper->iova);
+   gpu_write64(gpu, REG_A5XX_CP_CRASH_SCRIPT_BASE_LO, dumper->iova);
 
gpu_write(gpu, REG_A5XX_CP_CRASH_DUMP_CNTL, 1);
 
@@ -1670,8 +1664,7 @@ static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
if (pm_runtime_get_if_in_use(>pdev->dev) == 0)
return 0;
 
-   busy_cycles = gpu_read64(gpu, 

[PATCH 1/4] drm/msm/adreno: move a6xx CP_PROTECT macros to common code

2022-03-27 Thread Jonathan Marek
These will be used by a7xx, so move them to common code. A6XX_ prefix is
kept because the generic ADRENO_ is already in use.

Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h   | 17 -
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  6 ++
 2 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 86e0a7c3fe6df..d117c1589f2af 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -36,23 +36,6 @@ struct a6xx_gpu {
 
 #define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
 
-/*
- * Given a register and a count, return a value to program into
- * REG_CP_PROTECT_REG(n) - this will block both reads and writes for _len
- * registers starting at _reg.
- */
-#define A6XX_PROTECT_NORDWR(_reg, _len) \
-   ((1 << 31) | \
-   (((_len) & 0x3FFF) << 18) | ((_reg) & 0x3))
-
-/*
- * Same as above, but allow reads over the range. For areas of mixed use (such
- * as performance counters) this allows us to protect a much larger range with 
a
- * single register
- */
-#define A6XX_PROTECT_RDONLY(_reg, _len) \
-   _len) & 0x3FFF) << 18) | ((_reg) & 0x3))
-
 static inline bool a6xx_has_gbif(struct adreno_gpu *gpu)
 {
if(adreno_is_a630(gpu))
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 0490c5fbb7803..55c5433a4ea18 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -416,6 +416,10 @@ static inline uint32_t get_wptr(struct msm_ringbuffer 
*ring)
((1 << 30) | (1 << 29) | \
((ilog2((_len)) & 0x1F) << 24) | (((_reg) << 2) & 0xF))
 
+#define A6XX_PROTECT_NORDWR(_reg, _len) \
+   ((1 << 31) | \
+   (((_len) & 0x3FFF) << 18) | ((_reg) & 0x3))
+
 /*
  * Same as above, but allow reads over the range. For areas of mixed use (such
  * as performance counters) this allows us to protect a much larger range with 
a
@@ -425,6 +429,8 @@ static inline uint32_t get_wptr(struct msm_ringbuffer *ring)
((1 << 29) \
((ilog2((_len)) & 0x1F) << 24) | (((_reg) << 2) & 0xF))
 
+#define A6XX_PROTECT_RDONLY(_reg, _len) \
+   _len) & 0x3FFF) << 18) | ((_reg) & 0x3))
 
 #define gpu_poll_timeout(gpu, addr, val, cond, interval, timeout) \
readl_poll_timeout((gpu)->mmio + ((addr) << 2), val, cond, \
-- 
2.26.1



[PATCH 0/4] drm/msm/adreno: add support for a730

2022-03-27 Thread Jonathan Marek
Based on a6xx_gpu.c, stripped down and updated for a7xx based on the
downstream driver. Implements the minimum to be able to submit commands to
the GPU and use it for userspace driver development. Notably this doesn't
implement support for the GMU (this means that the clock driver needs to
support the GPU core clock and turning on the GX rail, which is normally
offloaded to the GMU).

Register updates: 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15602

Jonathan Marek (4):
  drm/msm/adreno: move a6xx CP_PROTECT macros to common code
  drm/msm/adreno: use a single register offset for
gpu_read64/gpu_write64
  drm/msm/adreno: update headers
  drm/msm/adreno: add support for a730

 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |   3 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  27 +-
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c   |   4 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  25 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h   |  17 -
 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c |   3 +-
 drivers/gpu/drm/msm/adreno/a7xx.xml.h   | 666 +
 drivers/gpu/drm/msm/adreno/a7xx_gpu.c   | 777 
 drivers/gpu/drm/msm/adreno/a7xx_gpu.h   |  26 +
 drivers/gpu/drm/msm/adreno/adreno_device.c  |  12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   9 +-
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h |  45 +-
 drivers/gpu/drm/msm/msm_gpu.h   |  12 +-
 drivers/gpu/drm/msm/msm_ringbuffer.h|   1 +
 15 files changed, 1550 insertions(+), 78 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a7xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a7xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a7xx_gpu.h

-- 
2.26.1



Re: [PATCH v5 3/3] drm/panel : innolux-ej030na and abt-y030xx067a : add .enable and .disable

2022-03-27 Thread Sam Ravnborg
Hi Christophe,

On Mon, Mar 21, 2022 at 03:42:08PM +0100, Christophe Branchereau wrote:
> Sorry I meant "sleep out" not "sleep in" obviously
> 
> On Mon, Mar 21, 2022 at 3:39 PM Christophe Branchereau
>  wrote:
> >
> > Following the introduction of bridge_atomic_enable in the ingenic
> > drm driver, the crtc is enabled between .prepare and .enable, if
> > it exists. Add it so the backlight is only enabled after the crtc is, to
> > avoid graphical issues.
> >
> > As we're moving the "sleep in" command out of the init sequence
> > into .enable for the ABT, we need to switch the regmap cache
> > to REGCACHE_FLAT to be able to use regmap_set_bits, given this
> > panel registers are write-ony and read as 0.
> >
> > On Mon, Mar 21, 2022 at 3:21 PM Paul Cercueil  wrote:
> > >
> > > Hi Christophe,
> > >
> > > Le lun., mars 21 2022 at 14:36:51 +0100, Christophe Branchereau
> > >  a écrit :
> > > > Following the introduction of bridge_atomic_enable in the ingenic
> > > > drm driver, the crtc is enabled between .prepare and .enable, if
> > > > it exists.
> > > >
> > > > Add it so the backlight is only enabled after the crtc is, to avoid
> > > > graphical issues.
> > > >
> > > > Signed-off-by: Christophe Branchereau 
> > >
> > > Didn't Sam acked it?
No, that was the new driver, already replied.

For these changes - with the updated changelog:
Acked-by: Sam Ravnborg 


Re: [PATCH v5 2/3] drm/panel: Add panel driver for NewVision NV3052C based LCDs

2022-03-27 Thread Sam Ravnborg
Hi Christophe

On Mon, Mar 21, 2022 at 02:36:50PM +0100, Christophe Branchereau wrote:
> This driver supports the NewVision NV3052C based LCDs. Right now, it
> only supports the LeadTek LTK035C5444T 2.4" 640x480 TFT LCD panel, which
> can be found in the Anbernic RG-350M handheld console.
> 
> Signed-off-by: Christophe Branchereau 
Please add:
Reviewed-by: Sam Ravnborg 

from the previous review round.

Sam


Re: [PATCH] dispnv50: atom: fix an incorrect NULL check on list iterator

2022-03-27 Thread Emil Velikov
On Sun, 27 Mar 2022 at 08:39, Xiaomeng Tong  wrote:
>
> The bug is here:
> return encoder;
>
> The list iterator value 'encoder' will *always* be set and non-NULL
> by drm_for_each_encoder_mask(), so it is incorrect to assume that the
> iterator value will be NULL if the list is empty or no element found.
> Otherwise it will bypass some NULL checks and lead to invalid memory
> access passing the check.
>
> To fix this bug, just return 'encoder' when found, otherwise return
> NULL.
>

Isn't this covered by the upcoming list* iterator rework [1] or is
this another iterator glitch?
IMHO we should be looking at fixing the implementation and not the
hundreds of users through the kernel.

HTH
-Emil
[1] https://lwn.net/Articles/887097/


Re: [PATCH] device: fix missing check on list iterator

2022-03-27 Thread Guenter Roeck

On 3/26/22 23:59, Xiaomeng Tong wrote:

On Sat, 26 Mar 2022 22:38:05 -0700, Guenter Roeck  wrote:

@@ -103,11 +103,16 @@ nvkm_control_mthd_pstate_attr(struct nvkm_control *ctrl, 
void *data, u32 size)
return -EINVAL;
   
   	if (args->v0.state != NVIF_CONTROL_PSTATE_ATTR_V0_STATE_CURRENT) {

-   list_for_each_entry(pstate, >states, head) {
-   if (i++ == args->v0.state)
+   list_for_each_entry(iter, >states, head) {
+   if (i++ == args->v0.state) {
+   pstate = iter;


Is iter and the assignment really necessary ? Unless I am missing something,
list_for_each_entry() always assigns pos (pstate/iter), even if the list is
empty. If nothing is found, pstate would be NULL at the end, so


the pstate will not be NULL at the end! so the assignment is necessary!
#define list_for_each_entry(pos, head, member)  \
 for (pos = __container_of((head)->next, pos, member);   \
  >member != (head);\
  pos = __container_of(pos->member.next, pos, member))




Uuh, yes, you are correct. Sorry for the noise.

Guenter



[PATCH v13 6/6] MAINTAINERS: add maintainers for DRM LSDC driver

2022-03-27 Thread Sui Jingfeng
 This patch add myself as maintainer

 My company email is 
 my personal email is <15330273...@189.cn>

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 10476280acb8..21184d8577f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6487,6 +6487,15 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: drivers/gpu/drm/lima/
 F: include/uapi/drm/lima_drm.h
 
+DRM DRIVERS FOR LOONGSON
+M: suijingfeng 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+W: https://www.loongson.cn/
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/loongson/
+F: drivers/gpu/drm/loongson/
+
 DRM DRIVERS FOR MEDIATEK
 M: Chun-Kuang Hu 
 M: Philipp Zabel 
-- 
2.25.1



[PATCH v13 5/6] drm/loongson: add drm driver for loongson display controller

2022-03-27 Thread Sui Jingfeng
There is a display controller in loongson's LS2K1000 SoC and LS7A1000
bridge chip, the display controller is a PCI device in those chips. It
has two display pipes but with only one hardware cursor. Each way has
a DVO interface which provide RGB888 signals, vertical & horizontal
synchronisations, data enable and the pixel clock. Each CRTC is able to
scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
2048x2048 according to the hardware spec. Loongson display controllers
are simple which require scanout buffers to be physically contiguous.

For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
which is typically 64MB or more. In this case, VRAM helper based driver
is intend to be used even through the DC can scanout form system memory.

While LS2K1000 is a SoC which is a typically UMA device, only system
memory is available. Therefore CMA helper based driver is intend to be
used. It is possible to use VRAM helper based driver on LS2K1000 by
carving out part of system memory as VRAM though.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space, They are used to emulate two way i2c.
One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
GPIO hardwared, they grab i2c adapter from other module, either general
purpose GPIO emulated i2c or hardware i2c adapter.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
+--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
  +---+  +--+

The above picture give a simple usage of LS7A1000, note that the encoder
is not necessary adv7125 or tfp410, other candicates can be ch7034b,
sil9022, ite66121 and lt8618 etc.

By design, the code was written in a NOT fully DT dependent way.

v2: Fixup warnings reported by kernel test robot

v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
more details about lsdc.

v4:
   1) Add dts required and explain why device tree is required.
   2) Give more description about lsdc and VRAM helper based driver.
   3) Fix warnings reported by kernel test robot.
   4) Introduce stride_alignment member into struct lsdc_chip_desc, the
  stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.

v5:
   1) Using writel and readl replace writeq and readq, to fix kernel test
  robot report build error on other archtecture.
   2) Set default fb format to XRGB at crtc reset time.

v6:
   1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
   2) Explain why tiny drm driver is not suitable for us.
   3) Give a short description of the trival dirty update implement based
  on CMA helper.

v7:
   1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
   2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
   3) Remove lsdc_pixpll_print(), part of it move to debugfs.
   4) Set prefer_shadow to true if vram based driver is in using.
   5) Replace double blank lines with single line in all files.
   6) Verbose cmd line parameter is replaced with drm_dbg()
   7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
   8) Get edid from dtb support is removed as suggested by Maxime Ripard
   9) Fix typos and various improvement

v8:
   1) Drop damage update implement and its command line.
   2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
   3) Deduce DC's identification from its compatible property.
   4) Drop the board specific dts patch.
   5) Add documention about the display controller device node.

v9:
   1) Fix the warnings reported by checkpatch script and fix typos

v10:
   1) Pass `make dt_binding_check` validation
   2) Fix warnings reported by kernel test robot

v11:
   1) Convert the driver to use drm bridge and of graph framework.
   2) Dump register value support through debugfs.
   3) Select DRM_TTM and DRM_TTM_HELPER in Kconfig which fix linkage
  problem when built it into the kernel.
   4) Non 64 pixel(256 bytes aligned) horiziontal resolutons got
  supported by hacking, default is disabled, enable it by using
  'loongson.relax_alignment=1' on kernel cmd line.
   5) Various improvement as required by Maxime.

v12:
   1) Add gammma support, it is broken because hardware engineer
  does not implement 

[PATCH v13 2/6] MIPS: Loongson64: introduce board specific dts and add model property

2022-03-27 Thread Sui Jingfeng
This patch introduce three board specific dts and assign different
model property to them according to the board name on the top overlay
of the PCB.

The model property added is used to provide board specific information,
mips kernel use it as machine name. For example:

$ cat /proc/cpuinfo

system type : Generic Loongson64 System
machine : LX-6901  < notice here
processor   : 0
cpu model   : ICT Loongson-3 V0.1  FPU V0.1
BogoMIPS: 3594.02
tlb_entries : 2112
isa : mips64r2
ASEs implemented: vz msa loongson-ext2
...

1) ls3A4000 evaluation board

  The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
  mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 slot,
  therefore can play with discrete graphics card.

  While the integrated display copntroller is equipped with a VGA output
  and a DVI output, the VGA is connect to the DVO0 output port of the
  display controller, the DVI is connected to DVO1 output port of the
  display controller.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
+--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
  +---+  +--+

2) lemote A1901 motherboard

  This board is made by LEMOTE corporation, it has two name, one is
  LX-6901, another is A1901. This board has only one VGA output which
  is connected to the DVO1 of the display controller.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |   DVO0 is not get used |  |  DVO1   +---+
+--+   <+  +>|ADV7125|---> VGA
 +---+

3) ls2k1000 pai evaluation board

  ls2k1000 is a two core 1.0Ghz Mips64r2 compatible SoC, desprite very
  slow, lacking i2c driver support, various display dridge drivers can
  only be tested on it. We still try to provide a minimal support.
   ___   
  |---| ||
  |  CRTC0 --> | DVO0 > | 1024x600 DPI Panel |
  |  _   _ ---|  | Which panel to use   ||
  | | | | |   |  | with this board is a  ___
  | |_| |_|   |  | choice of the user   |   |
  |   |  +> | 800x480 DPI Panel |
  |   DC In LS2K1000  | |___|
  |  _   _| +--+
  | | | | |   <>| i2c1 |---+
  | |_| |_|   | +--+   |
  |   || <--- config   | DDC   _
  |---|+-+ |  | |
  |  CRTC1 --> | DVO1 ---> | sii9022 | --> HDMI connector --> | Monitor |
  |---|+-+|_|
  |___|

  The sii9022 HDMI transmitter working in transparent mode, because the
  PCB designer make the board working in this way. In this case the EDID
  is read from the monitor directly, not through sii9022's ddc channel.
  The i2c0 is not get used by lsdc driver for this board.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 arch/mips/boot/dts/loongson/Makefile  |   4 +
 arch/mips/boot/dts/loongson/lemote_a1901.dts  |  96 
 .../boot/dts/loongson/ls2k1000_pai_udb.dts| 107 ++
 .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 138 ++
 4 files changed, 345 insertions(+)
 create mode 100644 arch/mips/boot/dts/loongson/lemote_a1901.dts
 create mode 100644 

[PATCH v13 3/6] dt-bindings: display: Add Loongson display controller

2022-03-27 Thread Sui Jingfeng
Add DT bindings and simple usages for Loongson display controller
found in LS7A1000 bridge chip and LS2k1000 SoC.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 .../loongson/loongson,display-controller.yaml | 321 ++
 1 file changed, 321 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml

diff --git 
a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
 
b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
new file mode 100644
index ..34060ed55a25
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
@@ -0,0 +1,321 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree 
Bindings
+
+maintainers:
+  - Sui Jingfeng 
+
+description: |+
+
+  Loongson display controllers are simple which require scanout buffers
+  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
+  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
+  with a dedicated video RAM which is 64MB or more, precise size can be
+  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
+  chip.
+
+  LSDC has two display pipes, each way has a DVO interface which provide
+  RGB888 signals, vertical & horizontal synchronisations, data enable and
+  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
+  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
+
+  For LS7A1000, there are 4 dedicated GPIOs whose control register is
+  located at the DC register space. They are used to emulate two way i2c,
+  One for DVO0, another for DVO1.
+
+  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
+  general purpose GPIO emulated i2c or hardware i2c in the SoC.
+
+  LSDC's display pipeline have several components as below description,
+
+  The display controller in LS7A1000:
+ ___ _
+|---|   | |
+|  CRTC0 --> | DVO0 > Encoder0 ---> Connector0 ---> | Monitor |
+|  _   _ ---|^ ^|_|
+| | | | |---|| |
+| |_| |_|| i2c0 <+-+
+|---|
+|   DC IN LS7A1000  |
+|  _   _ ---|
+| | | | || i2c1 <+-+
+| |_| |_|---|| | _
+|---|| || |
+|  CRTC1 --> | DVO1 > Encoder1 ---> Connector1 ---> |  Panel  |
+|---|   |_|
+|___|
+
+  Simple usage of LS7A1000 with LS3A4000 CPU:
+
++--+++
+| DDR4 ||  +---+ |
++--+|  | PCIe Root complex |   LS7A1000  |
+   || MC0   |  +--++-+++ |
+  +--+  HT 3.0  | || ||  |
+  | LS3A4000 |<>| +---++---+  +--++--+ +-+   +--+
+  |   CPU|<>| | GC1000 |  | LSDC |<--->| DDR3 MC |<->| VRAM |
+  +--+  | ++  +-+--+-+ +-+   +--+
+   || MC1   +---|--|-+
++--+|  |
+| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
++--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
+  +---+  +--+
+
+  The display controller in LS2K1000/LS2K0500:
+ ___ _
+|---|   | |
+|  CRTC0 --> | DVO0 > Encoder0 ---> Connector0 ---> | Monitor |
+|  _   _ ---|^  ^   |_|
+| | | | |   ||  |
+| |_| |_|   | +--+  |
+|   <>| i2c0 |<-+
+|   DC IN LS2K1000  | +--+
+|  _   _| +--+
+| | | | |   <>| i2c1 |--+
+| |_| |_|   | +--+  |_
+|---||  |   | |
+|  CRTC1 --> | DVO1 > Encoder1 ---> Connector1 ---> |  Panel  |
+|---|   |_|
+|___|
+
+properties:
+  $nodename:
+pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
+
+  

[PATCH v13 0/6] drm/loongson: add drm driver for loongson display controller

2022-03-27 Thread Sui Jingfeng
There is a display controller in loongson's LS2K1000 SoC and LS7A1000
bridge chip, the display controller is a PCI device in those chips. It
has two display pipes but with only one hardware cursor. Each way has
a DVO interface which provide RGB888 signals, vertical & horizontal
synchronisations, data enable and the pixel clock. Each CRTC is able to
scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
2048x2048 according to the hardware spec. Loongson display controllers
are simple which require scanout buffers to be physically contiguous.

For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
which is typically 64MB or more. In this case, VRAM helper based driver
is intend to be used even through the DC can scanout form system memory.

While LS2K1000 is a SoC which is a typically UMA device, only system
memory is available. Therefore CMA helper based driver is intend to be
used. It is possible to use VRAM helper based driver on LS2K1000 by
carving out part of system memory as VRAM though.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space, They are used to emulate two way i2c.
One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
GPIO hardwared, they grab i2c adapter from other module, either general
purpose GPIO emulated i2c or hardware i2c adapter.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
+--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
  +---+  +--+

The above picture give a simple usage of LS7A1000, note that the encoder
is not necessary adv7125 or tfp410, other candicates can be ch7034b,
sil9022, ite66121 and lt8618 etc.

By design, the code was written in a NOT fully DT dependent way.

v2: Fixup warnings reported by kernel test robot

v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
more details about lsdc.

v4:
   1) Add dts required and explain why device tree is required.
   2) Give more description about lsdc and VRAM helper based driver.
   3) Fix warnings reported by kernel test robot.
   4) Introduce stride_alignment member into struct lsdc_chip_desc, the
  stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.

v5:
   1) Using writel and readl replace writeq and readq, to fix kernel test
  robot report build error on other archtecture.
   2) Set default fb format to XRGB at crtc reset time.

v6:
   1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
   2) Explain why tiny drm driver is not suitable for us.
   3) Give a short description of the trival dirty update implement based
  on CMA helper.

v7:
   1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
   2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
   3) Remove lsdc_pixpll_print(), part of it move to debugfs.
   4) Set prefer_shadow to true if vram based driver is in using.
   5) Replace double blank lines with single line in all files.
   6) Verbose cmd line parameter is replaced with drm_dbg()
   7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
   8) Get edid from dtb support is removed as suggested by Maxime Ripard
   9) Fix typos and various improvement

v8:
   1) Drop damage update implement and its command line.
   2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
   3) Deduce DC's identification from its compatible property.
   4) Drop the board specific dts patch.
   5) Add documention about the display controller device node.

v9:
   1) Fix the warnings reported by checkpatch script and fix typos

v10:
   1) Pass `make dt_binding_check` validation
   2) Fix warnings reported by kernel test robot

v11:
   1) Convert the driver to use drm bridge and of graph framework.
   2) Dump register value support through debugfs.
   3) Select DRM_TTM and DRM_TTM_HELPER in Kconfig which fix linkage
  problem when built it into the kernel.
   4) Non 64 pixel(256 bytes aligned) horiziontal resolutons got
  supported by hacking, default is disabled, enable it by using
  'loongson.relax_alignment=1' on kernel cmd line.
   5) Various improvement as required by Maxime.

v12:
   1) Add gammma support, it is broken because hardware engineer
  does not implement 

[PATCH v13 1/6] MIPS: Loongson64: dts: update the display controller device node

2022-03-27 Thread Sui Jingfeng
The display controller is a pci device, it is used in ls2k1000 SoC and
LS7A1000 bridge. Its PCI vendor id is 0x0014, its PCI device id is 0x7a06.
In order to let the driver to know which chip the DC is contained in,
the compatible of the display controller is named according to the chip's
name.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space. They are used to emulate i2c for reading
edid from the monitor. One for DVO0, another for DVO1.

LS2K1000 and LS2K0500 SoC don't have such GPIOs, they grab i2c adapter
from other module, either general purpose GPIO emulated i2c or hardware
i2c adapter.

This patch add common part of the DC device node only, it does not contain
ports device note. As it is for the generic, boards only with transparent
encoders should works simply by inherit from this.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 .../boot/dts/loongson/loongson64-2k1000.dtsi  |  8 +++
 arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 24 +++
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi 
b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
index 8143a6e3..2ecb5a232f22 100644
--- a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
+++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
@@ -198,6 +198,14 @@ sata@8,0 {
interrupt-parent = <>;
};
 
+   lsdc: display-controller@6,0 {
+   compatible = "loongson,ls2k1000-dc";
+
+   reg = <0x3000 0x0 0x0 0x0 0x0>;
+   interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <>;
+   };
+
pci_bridge@9,0 {
compatible = "pci0014,7a19.0",
   "pci0014,7a19",
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi 
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index 2f45fce2cdc4..1d3fe73b31d5 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -160,15 +160,29 @@ gpu@6,0 {
interrupt-parent = <>;
};
 
-   dc@6,1 {
-   compatible = "pci0014,7a06.0",
-  "pci0014,7a06",
-  "pciclass03",
-  "pciclass0300";
+   lsdc: display-controller@6,1 {
+   compatible = "loongson,ls7a1000-dc";
 
reg = <0x3100 0x0 0x0 0x0 0x0>;
interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c6: i2c@6 {
+   compatible = "loongson,gpio-i2c";
+   loongson,sda = <0>;
+   loongson,scl = <1>;
+   loongson,nr = <6>;
+   };
+
+   i2c7: i2c@7 {
+   compatible = "loongson,gpio-i2c";
+   loongson,sda = <2>;
+   loongson,scl = <3>;
+   loongson,nr = <7>;
+   };
};
 
hda@7,0 {
-- 
2.25.1



Re: [PATCH v12 3/6] dt-bindings: display: Add Loongson display controller

2022-03-27 Thread Rob Herring
On Sun, 27 Mar 2022 19:38:43 +0800, Sui Jingfeng wrote:
> Add DT bindings and simple usages for Loongson display controller
> found in LS7A1000 bridges chip and LS2k1000 SoC.
> 
> Signed-off-by: Sui Jingfeng <15330273...@189.cn>
> ---
>  .../loongson/loongson,display-controller.yaml | 322 ++
>  1 file changed, 322 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.example.dt.yaml:
 display-controller@6,1: 'ports' is a required property
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1609879

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.



Re: [PATCH v12 5/6] drm/loongson: add drm driver for loongson display controller

2022-03-27 Thread kernel test robot
Hi Sui,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on robh/for-next linus/master v5.17 next-20220325]
[cannot apply to mripard/sunxi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/intel-lab-lkp/linux/commits/Sui-Jingfeng/drm-loongson-add-drm-driver-for-loongson-display-controller/20220327-194016
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: parisc-randconfig-r003-20220327 
(https://download.01.org/0day-ci/archive/20220327/202203272117.q6tmwbfo-...@intel.com/config)
compiler: hppa-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/e90d831d05f2c1b5631fd706fb449e83e64f632c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Sui-Jingfeng/drm-loongson-add-drm-driver-for-loongson-display-controller/20220327-194016
git checkout e90d831d05f2c1b5631fd706fb449e83e64f632c
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
O=build_dir ARCH=parisc SHELL=/bin/bash drivers/gpu/drm/loongson/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/loongson/lsdc_debugfs.c:149: warning: This comment starts 
>> with '/**', but isn't a kernel-doc comment. Refer 
>> Documentation/doc-guide/kernel-doc.rst
* vram debugfs related ...


vim +149 drivers/gpu/drm/loongson/lsdc_debugfs.c

   147  
   148  /**
 > 149   * vram debugfs related ...
   150   */
   151  static int lsdc_vram_mm_show(struct seq_file *m, void *data)
   152  {
   153  struct drm_info_node *node = (struct drm_info_node *)m->private;
   154  struct drm_vram_mm *vmm = node->minor->dev->vram_mm;
   155  struct ttm_resource_manager *man = ttm_manager_type(>bdev, 
TTM_PL_VRAM);
   156  struct drm_printer p = drm_seq_file_printer(m);
   157  
   158  ttm_resource_manager_debug(man, );
   159  return 0;
   160  }
   161  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp


Re: [PATCH v12 3/6] dt-bindings: display: Add Loongson display controller

2022-03-27 Thread Jiaxun Yang




在 2022/3/27 12:38, Sui Jingfeng 写道:

Add DT bindings and simple usages for Loongson display controller
found in LS7A1000 bridges chip and LS2k1000 SoC.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>

[...]

+
+  - |
+#include 
+bus {
+
+#address-cells = <3>;
+#size-cells = <2>;
+#interrupt-cells = <2>;
+
+display-controller@6,1 {
+compatible = "loongson,ls7a1000-dc";
+reg = <0x3100 0x0 0x0 0x0 0x0>;
+interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+i2c@6 {
+compatible = "loongson,gpio-i2c";
+reg = <0x1650 0x0020>;

Hi Jingfeng,

Thanks for your patch.

Just curious about what is this "reg" for?

+loongson,nr = <6>;

Why nr start from 6?

The approach you are handling I2C seems to be wired..

Actually you can reference how network subsystem is handling
MDIO controller built-in into Ethernet controller [1] in this case. It is
basically the same problem.

[1]: 
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/net/snps,dwmac.yaml


Thanks.
- Jiaxun


+loongson,sda = <0>;
+loongson,scl = <1>;
+loongson,udelay = <5>;
+loongson,timeout = <2200>;
+};
+
+i2c@7 {
+compatible = "loongson,gpio-i2c";
+reg = <0x1650 0x0020>;
+loongson,nr = <7>;
+loongson,sda = <2>;
+loongson,scl = <3>;
+loongson,udelay = <5>;
+loongson,timeout = <2200>;
+};
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+endpoint {
+remote-endpoint = <_encoder_in>;
+};
+};
+
+port@1 {
+reg = <1>;
+endpoint {
+remote-endpoint = <_encoder_in>;
+};
+};
+};
+};
+};
+
+  - |
+#include 
+bus {
+
+#address-cells = <3>;
+#size-cells = <2>;
+#interrupt-cells = <2>;
+
+display-controller@6,0 {
+compatible = "loongson,ls2k1000-dc";
+reg = <0x3100 0x0 0x0 0x0 0x0>;
+interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+endpoint {
+remote-endpoint = <_in>;
+};
+};
+
+port@1 {
+reg = <1>;
+endpoint {
+remote-endpoint = <_encoder_in>;
+};
+};
+};
+};
+};
+...




[PATCH v12 6/6] MAINTAINERS: add maintainers for DRM LSDC driver

2022-03-27 Thread Sui Jingfeng
 This patch add myself as maintainer

 My company email is 
 my personal email is <15330273...@189.cn>

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 10476280acb8..21184d8577f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6487,6 +6487,15 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: drivers/gpu/drm/lima/
 F: include/uapi/drm/lima_drm.h
 
+DRM DRIVERS FOR LOONGSON
+M: suijingfeng 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+W: https://www.loongson.cn/
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/loongson/
+F: drivers/gpu/drm/loongson/
+
 DRM DRIVERS FOR MEDIATEK
 M: Chun-Kuang Hu 
 M: Philipp Zabel 
-- 
2.25.1



[PATCH v12 4/6] MIPS: Loongson64: defconfig: enable display bridge drivers

2022-03-27 Thread Sui Jingfeng
ls3A4000 evb board ship with adv7123 and tfp410 while ls2k1000 PI board
use a DPI panel from FORLINX company and a sii9022 HDMI transmitter.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 arch/mips/configs/loongson2k_defconfig | 5 +
 arch/mips/configs/loongson3_defconfig  | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/mips/configs/loongson2k_defconfig 
b/arch/mips/configs/loongson2k_defconfig
index e948ca487e2d..0a97c332a5c3 100644
--- a/arch/mips/configs/loongson2k_defconfig
+++ b/arch/mips/configs/loongson2k_defconfig
@@ -243,6 +243,11 @@ CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_DRM=y
 CONFIG_DRM_RADEON=y
+CONFIG_DRM_DISPLAY_CONNECTOR=m
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_SII902X=m
+CONFIG_DRM_SIMPLE_BRIDGE=m
+CONFIG_DRM_TI_TFP410=m
 CONFIG_FB_RADEON=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=m
diff --git a/arch/mips/configs/loongson3_defconfig 
b/arch/mips/configs/loongson3_defconfig
index 25ecd15bc952..35e2fc998768 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -280,6 +280,11 @@ CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_DRM=y
 CONFIG_DRM_RADEON=m
+CONFIG_DRM_DISPLAY_CONNECTOR=m
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_SII902X=m
+CONFIG_DRM_SIMPLE_BRIDGE=m
+CONFIG_DRM_TI_TFP410=m
 CONFIG_DRM_QXL=y
 CONFIG_DRM_VIRTIO_GPU=y
 CONFIG_FB=y
-- 
2.25.1



[PATCH v12 5/6] drm/loongson: add drm driver for loongson display controller

2022-03-27 Thread Sui Jingfeng
There is a display controller in loongson's LS2K1000 SoC and LS7A1000
bridge chip, the display controller is a PCI device in those chips. It
has two display pipes but with only one hardware cursor. Each way has
a DVO interface which provide RGB888 signals, vertical & horizontal
synchronisations, data enable and the pixel clock. Each CRTC is able to
scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
2048x2048 according to the hardware spec. Loongson display controllers
are simple which require scanout buffers to be physically contiguous.

For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
which is typically 64MB or more. In this case, VRAM helper based driver
is intend to be used even through the DC can scanout form system memory.

While LS2K1000 is a SoC which is a typically UMA device, only system
memory is available. Therefore CMA helper based driver is intend to be
used. It is possible to use VRAM helper based driver on LS2K1000 by
carving out part of system memory as VRAM though.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space, They are used to emulate two way i2c.
One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
GPIO hardwared, they grab i2c adapter from other module, either general
purpose GPIO emulated i2c or hardware i2c adapter.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
+--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
  +---+  +--+

The above picture give a simple usage of LS7A1000, note that the encoder
is not necessary adv7125 or tfp410, other candicates can be ch7034b,
sil9022, ite66121 and lt8618 etc.

By design, the code was written in a NOT fully DT dependent way.

v2: Fixup warnings reported by kernel test robot

v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
more details about lsdc.

v4:
   1) Add dts required and explain why device tree is required.
   2) Give more description about lsdc and VRAM helper based driver.
   3) Fix warnings reported by kernel test robot.
   4) Introduce stride_alignment member into struct lsdc_chip_desc, the
  stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.

v5:
   1) Using writel and readl replace writeq and readq, to fix kernel test
  robot report build error on other archtecture.
   2) Set default fb format to XRGB at crtc reset time.

v6:
   1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
   2) Explain why tiny drm driver is not suitable for us.
   3) Give a short description of the trival dirty update implement based
  on CMA helper.

v7:
   1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
   2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
   3) Remove lsdc_pixpll_print(), part of it move to debugfs.
   4) Set prefer_shadow to true if vram based driver is in using.
   5) Replace double blank lines with single line in all files.
   6) Verbose cmd line parameter is replaced with drm_dbg()
   7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
   8) Get edid from dtb support is removed as suggested by Maxime Ripard
   9) Fix typos and various improvement

v8:
   1) Drop damage update implement and its command line.
   2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
   3) Deduce DC's identification from its compatible property.
   4) Drop the board specific dts patch.
   5) Add documention about the display controller device node.

v9:
   1) Fix the warnings reported by checkpatch script and fix typos

v10:
   1) Pass `make dt_binding_check` validation
   2) Fix warnings reported by kernel test robot

v11:
   1) Convert the driver to use drm bridge and of graph framework.
   2) Dump register value support through debugfs.
   3) Select DRM_TTM and DRM_TTM_HELPER in Kconfig which fix linkage
  problem when built it into the kernel.
   4) Non 64 pixel(256 bytes aligned) horiziontal resolutons got
  supported by hacking, default is disabled, enable it by using
  'loongson.relax_alignment=1' on kernel cmd line.
   5) Various improvement as required by Maxime.

v12:
   1) Add gammma support, it is broken because hardware engineer
  does not implement 

[PATCH v12 3/6] dt-bindings: display: Add Loongson display controller

2022-03-27 Thread Sui Jingfeng
Add DT bindings and simple usages for Loongson display controller
found in LS7A1000 bridges chip and LS2k1000 SoC.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 .../loongson/loongson,display-controller.yaml | 322 ++
 1 file changed, 322 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml

diff --git 
a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
 
b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
new file mode 100644
index ..b380602036f5
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
@@ -0,0 +1,322 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree 
Bindings
+
+maintainers:
+  - Sui Jingfeng 
+
+description: |+
+
+  Loongson display controllers are simple which require scanout buffers
+  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
+  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
+  with a dedicated video RAM which is 64MB or more, precise size can be
+  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
+  chip.
+
+  LSDC has two display pipes, each way has a DVO interface which provide
+  RGB888 signals, vertical & horizontal synchronisations, data enable and
+  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
+  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
+
+  For LS7A1000, there are 4 dedicated GPIOs whose control register is
+  located at the DC register space. They are used to emulate two way i2c,
+  One for DVO0, another for DVO1.
+
+  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
+  general purpose GPIO emulated i2c or hardware i2c in the SoC.
+
+  LSDC's display pipeline have several components as below description,
+
+  The display controller in LS7A1000:
+ ___ _
+|---|   | |
+|  CRTC0 --> | DVO0 > Encoder0 ---> Connector0 ---> | Monitor |
+|  _   _ ---|^ ^|_|
+| | | | |---|| |
+| |_| |_|| i2c0 <+-+
+|---|
+|   DC IN LS7A1000  |
+|  _   _ ---|
+| | | | || i2c1 <+-+
+| |_| |_|---|| | _
+|---|| || |
+|  CRTC1 --> | DVO1 > Encoder1 ---> Connector1 ---> |  Panel  |
+|---|   |_|
+|___|
+
+  Simple usage of LS7A1000 with LS3A4000 CPU:
+
++--+++
+| DDR4 ||  +---+ |
++--+|  | PCIe Root complex |   LS7A1000  |
+   || MC0   |  +--++-+++ |
+  +--+  HT 3.0  | || ||  |
+  | LS3A4000 |<>| +---++---+  +--++--+ +-+   +--+
+  |   CPU|<>| | GC1000 |  | LSDC |<--->| DDR3 MC |<->| VRAM |
+  +--+  | ++  +-+--+-+ +-+   +--+
+   || MC1   +---|--|-+
++--+|  |
+| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
++--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
+  +---+  +--+
+
+  The display controller in LS2K1000/LS2K0500:
+ ___ _
+|---|   | |
+|  CRTC0 --> | DVO0 > Encoder0 ---> Connector0 ---> | Monitor |
+|  _   _ ---|^  ^   |_|
+| | | | |   ||  |
+| |_| |_|   | +--+  |
+|   <>| i2c0 |<-+
+|   DC IN LS2K1000  | +--+
+|  _   _| +--+
+| | | | |   <>| i2c1 |--+
+| |_| |_|   | +--+  |_
+|---||  |   | |
+|  CRTC1 --> | DVO1 > Encoder1 ---> Connector1 ---> |  Panel  |
+|---|   |_|
+|___|
+
+properties:
+  $nodename:
+pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
+
+  

[PATCH v12 2/6] MIPS: Loongson64: introduce board specific dts and add model property

2022-03-27 Thread Sui Jingfeng
This patch introduce three board specific dts and assign different
model property to them according to the board name on the top overlay
of the PCB.

The model property added is used to provide board specific information,
mips kernel use it as machine name. For example:

$ cat /proc/cpuinfo

system type : Generic Loongson64 System
machine : LX-6901  < notice here
processor   : 0
cpu model   : ICT Loongson-3 V0.1  FPU V0.1
BogoMIPS: 3594.02
tlb_entries : 2112
isa : mips64r2
ASEs implemented: vz msa loongson-ext2
...

1) ls3A4000 evaluation board

  The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
  mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 slot,
  therefore can play with discrete graphics card.

  While the integrated display copntroller is equipped with a VGA output
  and a DVI output, the VGA is connect to the DVO0 output port of the
  display controller, the DVI is connected to DVO1 output port of the
  display controller.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
+--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
  +---+  +--+

2) lemote A1901 motherboard

  This board is made by LEMOTE corporation, it has two name, one is
  LX-6901, another is A1901. This board has only one VGA output which
  is connected to the DVO1 of the display controller.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |   DVO0 is not get used |  |  DVO1   +---+
+--+   <+  +>|ADV7125|---> VGA
 +---+

3) ls2k1000 pai evaluation board

  ls2k1000 is a two core 1.0Ghz Mips64r2 compatible SoC, desprite very
  slow, lacking i2c driver support, various display dridge drivers can
  only be tested on it. We still try to provide a minimal support.
   ___   
  |---| ||
  |  CRTC0 --> | DVO0 > | 1024x600 DPI Panel |
  |  _   _ ---|  | Which panel to use   ||
  | | | | |   |  | with this board is a  ___
  | |_| |_|   |  | choice of the user   |   |
  |   |  +> | 800x480 DPI Panel |
  |   DC In LS2K1000  | |___|
  |  _   _| +--+
  | | | | |   <>| i2c1 |---+
  | |_| |_|   | +--+   |
  |   || <--- config   | DDC   _
  |---|+-+ |  | |
  |  CRTC1 --> | DVO1 ---> | sii9022 | --> HDMI connector --> | Monitor |
  |---|+-+|_|
  |___|

  The sii9022 HDMI transmitter working in transparent mode, because the
  PCB designer make the board working in this way. In this case the EDID
  is read from the monitor directly, not through sii9022's ddc channel.
  The i2c0 is not get used by lsdc driver for this board.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 arch/mips/boot/dts/loongson/Makefile  |   4 +
 arch/mips/boot/dts/loongson/lemote_a1901.dts  |  96 
 .../boot/dts/loongson/ls2k1000_pai_udb.dts| 107 ++
 .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 138 ++
 4 files changed, 345 insertions(+)
 create mode 100644 arch/mips/boot/dts/loongson/lemote_a1901.dts
 create mode 100644 

[PATCH v12 1/6] MIPS: Loongson64: dts: update the display controller device node

2022-03-27 Thread Sui Jingfeng
The display controller is a pci device, it is used in ls2k1000 SoC and
LS7A1000 bridge. Its PCI vendor id is 0x0014, its PCI device id is 0x7a06.
In order to let the driver to know which chip the DC is contained in,
the compatible of the display controller is named according to the chip's
name.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space. They are used to emulate i2c for reading
edid from the monitor. One for DVO0, another for DVO1.

LS2K1000 and LS2K0500 SoC don't have such GPIOs, they grab i2c adapter
from other module, either general purpose GPIO emulated i2c or hardware
i2c adapter.

This patch add common part of the DC device node only, it does not contain
ports device note. As it is for the generic, boards only with transparent
encoders should works simply by inherit from this.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 .../boot/dts/loongson/loongson64-2k1000.dtsi  |  8 +++
 arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 24 +++
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi 
b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
index 8143a6e3..2ecb5a232f22 100644
--- a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
+++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
@@ -198,6 +198,14 @@ sata@8,0 {
interrupt-parent = <>;
};
 
+   lsdc: display-controller@6,0 {
+   compatible = "loongson,ls2k1000-dc";
+
+   reg = <0x3000 0x0 0x0 0x0 0x0>;
+   interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <>;
+   };
+
pci_bridge@9,0 {
compatible = "pci0014,7a19.0",
   "pci0014,7a19",
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi 
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index 2f45fce2cdc4..1d3fe73b31d5 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -160,15 +160,29 @@ gpu@6,0 {
interrupt-parent = <>;
};
 
-   dc@6,1 {
-   compatible = "pci0014,7a06.0",
-  "pci0014,7a06",
-  "pciclass03",
-  "pciclass0300";
+   lsdc: display-controller@6,1 {
+   compatible = "loongson,ls7a1000-dc";
 
reg = <0x3100 0x0 0x0 0x0 0x0>;
interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c6: i2c@6 {
+   compatible = "loongson,gpio-i2c";
+   loongson,sda = <0>;
+   loongson,scl = <1>;
+   loongson,nr = <6>;
+   };
+
+   i2c7: i2c@7 {
+   compatible = "loongson,gpio-i2c";
+   loongson,sda = <2>;
+   loongson,scl = <3>;
+   loongson,nr = <7>;
+   };
};
 
hda@7,0 {
-- 
2.25.1



[PATCH v12 0/6] drm/loongson: add drm driver for loongson display controller

2022-03-27 Thread Sui Jingfeng
There is a display controller in loongson's LS2K1000 SoC and LS7A1000
bridge chip, the display controller is a PCI device in those chips. It
has two display pipes but with only one hardware cursor. Each way has
a DVO interface which provide RGB888 signals, vertical & horizontal
synchronisations, data enable and the pixel clock. Each CRTC is able to
scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
2048x2048 according to the hardware spec. Loongson display controllers
are simple which require scanout buffers to be physically contiguous.

For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
which is typically 64MB or more. In this case, VRAM helper based driver
is intend to be used even through the DC can scanout form system memory.

While LS2K1000 is a SoC which is a typically UMA device, only system
memory is available. Therefore CMA helper based driver is intend to be
used. It is possible to use VRAM helper based driver on LS2K1000 by
carving out part of system memory as VRAM though.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space, They are used to emulate two way i2c.
One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
GPIO hardwared, they grab i2c adapter from other module, either general
purpose GPIO emulated i2c or hardware i2c adapter.

+--++---+
| DDR4 ||  +---+|
+--+|  | PCIe Root complex |   LS7A1000 |
   || MC0   |  +--++-+++|
  +--+  HT 3.0  | || || |
  | LS3A4000 |<>| +---++---+  +--++--++-+   +--+
  |   CPU|<>| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +--+  | ++  +-+--+-++-+   +--+
   || MC1   +---|--|+
+--+|  |
| DDR4 |  +---+   DVO0  |  |  DVO1   +--+
+--+   VGA <--|ADV7125|<+  +>|TFP410|--> DVI/HDMI
  +---+  +--+

The above picture give a simple usage of LS7A1000, note that the encoder
is not necessary adv7125 or tfp410, other candicates can be ch7034b,
sil9022, ite66121 and lt8618 etc.

v2: Fixup warnings reported by kernel test robot

v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
more details about lsdc.

v4:
   1) Add dts required and explain why device tree is required.
   2) Give more description about lsdc and VRAM helper based driver.
   3) Fix warnings reported by kernel test robot.
   4) Introduce stride_alignment member into struct lsdc_chip_desc, the
  stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.

v5:
   1) Using writel and readl replace writeq and readq, to fix kernel test
  robot report build error on other archtecture.
   2) Set default fb format to XRGB at crtc reset time.

v6:
   1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
   2) Explain why tiny drm driver is not suitable for us.
   3) Give a short description of the trival dirty update implement based
  on CMA helper.

v7:
   1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
   2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
   3) Remove lsdc_pixpll_print(), part of it move to debugfs.
   4) Set prefer_shadow to true if vram based driver is in using.
   5) Replace double blank lines with single line in all files.
   6) Verbose cmd line parameter is replaced with drm_dbg()
   7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
   8) Get edid from dtb support is removed as suggested by Maxime Ripard
   9) Fix typos and various improvement

v8:
   1) Drop damage update implement and its command line.
   2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
   3) Deduce DC's identification from its compatible property.
   4) Drop the board specific dts patch.
   5) Add documention about the display controller device node.

v9:
   1) Fix the warnings reported by checkpatch script and fix typos

v10:
   1) Pass `make dt_binding_check` validation
   2) Fix warnings reported by kernel test robot

v11:
   1) Convert the driver to use drm bridge and of graph framework.
   2) Dump register value support through debugfs.
   3) Select DRM_TTM and DRM_TTM_HELPER in Kconfig which fix linkage
  problem when built it into the kernel.
   4) Non 64 pixel(256 bytes aligned) horiziontal resolutons got
  supported by hacking, default is disabled, enable it by using
  'loongson.relax_alignment=1' on kernel cmd line.
   5) Various improvement as required by Maxime.

v12:
   1) Add gammma support, it is broken because hardware engineer
  does not implement this correctly. Using 'loongson.gamma=1' on
  the kernel cmd line 

Re: [PATCH v5 2/5] phy: Add LVDS configuration options

2022-03-27 Thread Liu Ying
Hi Kishon, Vinod,

On Thu, 2021-06-10 at 17:38 +0800, Liu Ying wrote:
> Hi Kishon, Vinod,
> 
> Any follow-up comments/suggestions based on my previous reply?
> Or, perhaps, just keep the patch as-is to support the generic lvds
> phy
> configuration structure?

Ping... Any follow-up comments/suggestions please?

This series is flying for more than one year and is blocking the series
of adding DRM bridge drivers for the LVDS display pipeline on i.MX8qxp
SoC.

IMHO, the generic lvds phy configuration structure is useful to custom
drivers.  Shall we keep the patch as-is?

I may rebase this series as patch 1/1 for nwl-dsi driver needs to keep
updated with the latest nwl-dsi driver.

Two more comments below...

> 
> Thanks,
> Liu Ying
> 
> On Thu, 2021-04-01 at 16:36 +0800, Liu Ying wrote:
> > Hi Kishon,
> > 
> > First of all, thanks for your review.
> > 
> > On Wed, 2021-03-31 at 19:02 +0530, Kishon Vijay Abraham I wrote:
> > > Hi,
> > > 
> > > On 25/03/21 2:30 pm, Liu Ying wrote:
> > > > This patch allows LVDS PHYs to be configured through
> > > > the generic functions and through a custom structure
> > > > added to the generic union.
> > > > 
> > > > The parameters added here are based on common LVDS PHY
> > > > implementation practices.  The set of parameters
> > > > should cover all potential users.
> > > > 
> > > > Cc: Kishon Vijay Abraham I 
> > > > Cc: Vinod Koul 
> > > > Cc: NXP Linux Team 
> > > > Signed-off-by: Liu Ying 
> > > > ---
> > > > v4->v5:
> > > > * Align kernel-doc style to include/linux/phy/phy.h. (Vinod)
> > > > * Trivial tweaks.
> > > > * Drop Robert's R-b tag.
> > > > 
> > > > v3->v4:
> > > > * Add Robert's R-b tag.
> > > > 
> > > > v2->v3:
> > > > * No change.
> > > > 
> > > > v1->v2:
> > > > * No change.
> > > > 
> > > >  include/linux/phy/phy-lvds.h | 32
> > > > 
> > > >  include/linux/phy/phy.h  |  4 
> > > >  2 files changed, 36 insertions(+)
> > > >  create mode 100644 include/linux/phy/phy-lvds.h
> > > > 
> > > > diff --git a/include/linux/phy/phy-lvds.h
> > > > b/include/linux/phy/phy-lvds.h
> > > > new file mode 100644
> > > > index ..7a2f474
> > > > --- /dev/null
> > > > +++ b/include/linux/phy/phy-lvds.h
> > > > @@ -0,0 +1,32 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +/*
> > > > + * Copyright 2020 NXP
> > > > + */
> > > > +
> > > > +#ifndef __PHY_LVDS_H_
> > > > +#define __PHY_LVDS_H_
> > > > +
> > > > +/**
> > > > + * struct phy_configure_opts_lvds - LVDS configuration set
> > > > + * @bits_per_lane_and_dclk_cycle:  Number of bits per data
> > > > lane and
> > > > + * differential clock
> > > > cycle.
> > > 
> > > phy_set_bus_width() instead?
> > 
> > This member aims to configure the number of bits transmitted during
> > a
> > period of time(a clock cycle). It doesn't sound like a concept of
> > 'bus
> > width'?
> > 
> > > > + * @differential_clk_rate: Clock rate, in Hertz,
> > > > of the LVDS
> > > > + * differential clock.
> > > 
> > > Please use clk API's to get rate.
> > 
> > I like your idea. But, this rate is likely runtime-configurable,
> > e.g.,
> > a LVDS to HDMI chip is connected. It seems that there is no
> > appropriate
> > driver to set the rate by calling clk_set_rate() then?

It doesn't seem to be reasonable to use clk API's to get the rate,
since the phy should generate the clock signal(act as a clk provider).
If the phy drivers do act as a clk provider to register a clk for the
differential clk, the phy drivers still need some way to know the clk
rate. 'assigned-clock-rates' DT property cannot provide the rate
because the rate is likely runtime-configurable like I mentioned. So,
it looks like the differential_clk_rate member is the appropriate way
to provide the rate.  

> > 
> > > > + * @lanes: Number of active,
> > > > consecutive,
> > > > + * data lanes, starting
> > > > from lane 0,
> > > > + * used for the
> > > > transmissions.
> > > > + * @is_slave:  Boolean, true if the
> > > > phy is a slave
> > > > + * which works together
> > > > with a master
> > > > + * phy to support dual
> > > > link transmission,
> > > > + * otherwise a regular phy
> > > > or a master phy.
> > > 
> > > For parameters that are known at design time, it doesn't have to
> > > be
> > > passed from consumer driver. So all these parameters do they
> > > really have
> > > to be passed at runtime?
> > 
> > Yes for all, perhaps. Details below:
> > 
> > 1) bits_per_lane_and_dclk_cycle
> > i.MX8qxp LVDS phy can only do 7, while i.MX8qm LVDS phy(a different
> > IP)
> > can do either 7 or 10(configurable by setting a phy register).
> > 
> > 2) differential_clk_rate
> > It's likely runtime-configurable, as I 

[PATCH] clk: base: fix an incorrect NULL check on list iterator

2022-03-27 Thread Xiaomeng Tong
The bug is here:
if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
return cstate;

The list iterator value 'cstate' will *always* be set and non-NULL
by list_for_each_entry_from_reverse(), so it is incorrect to assume
that the iterator value will be unchanged if the list is empty or no
element is found (In fact, it will be a bogus pointer to an invalid
structure object containing the HEAD). Also it missed a NULL check
at callsite and may lead to invalid memory access after that.

To fix this bug, just return 'encoder' when found, otherwise return
NULL. And add the NULL check.

Cc: sta...@vger.kernel.org
Fixes: 1f7f3d91ad38a ("drm/nouveau/clk: Respect voltage limits in 
nvkm_cstate_prog")
Signed-off-by: Xiaomeng Tong 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index 57199be082fd..c2b5cc5f97ed 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -135,10 +135,10 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
nvkm_pstate *pstate,
 
list_for_each_entry_from_reverse(cstate, >list, head) {
if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
-   break;
+   return cstate;
}
 
-   return cstate;
+   return NULL;
 }
 
 static struct nvkm_cstate *
@@ -169,6 +169,8 @@ nvkm_cstate_prog(struct nvkm_clk *clk, struct nvkm_pstate 
*pstate, int cstatei)
if (!list_empty(>list)) {
cstate = nvkm_cstate_get(clk, pstate, cstatei);
cstate = nvkm_cstate_find_best(clk, pstate, cstate);
+   if (!cstate)
+   return -EINVAL;
} else {
cstate = >base;
}
-- 
2.17.1



[PATCH] dispnv50: atom: fix an incorrect NULL check on list iterator

2022-03-27 Thread Xiaomeng Tong
The bug is here:
return encoder;

The list iterator value 'encoder' will *always* be set and non-NULL
by drm_for_each_encoder_mask(), so it is incorrect to assume that the
iterator value will be NULL if the list is empty or no element found.
Otherwise it will bypass some NULL checks and lead to invalid memory
access passing the check.

To fix this bug, just return 'encoder' when found, otherwise return
NULL.

Cc: sta...@vger.kernel.org
Fixes: 12885ecbfe62d ("drm/nouveau/kms/nvd9-: Add CRC support")
Signed-off-by: Xiaomeng Tong 
---
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  6 +++---
 drivers/gpu/drm/nouveau/dispnv50/crc.c  | 27 -
 2 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h 
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index 3d82b3c67dec..93f8f4f64578 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -160,14 +160,14 @@ nv50_head_atom_get(struct drm_atomic_state *state, struct 
drm_crtc *crtc)
 static inline struct drm_encoder *
 nv50_head_atom_get_encoder(struct nv50_head_atom *atom)
 {
-   struct drm_encoder *encoder = NULL;
+   struct drm_encoder *encoder;
 
/* We only ever have a single encoder */
drm_for_each_encoder_mask(encoder, atom->state.crtc->dev,
  atom->state.encoder_mask)
-   break;
+   return encoder;
 
-   return encoder;
+   return NULL;
 }
 
 #define nv50_wndw_atom(p) container_of((p), struct nv50_wndw_atom, state)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c 
b/drivers/gpu/drm/nouveau/dispnv50/crc.c
index 29428e770f14..b834e8a9ae77 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crc.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c
@@ -390,9 +390,18 @@ void nv50_crc_atomic_check_outp(struct nv50_atom *atom)
struct nv50_head_atom *armh = nv50_head_atom(old_crtc_state);
struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
struct nv50_outp_atom *outp_atom;
-   struct nouveau_encoder *outp =
-   nv50_real_outp(nv50_head_atom_get_encoder(armh));
-   struct drm_encoder *encoder = >base.base;
+   struct nouveau_encoder *outp;
+   struct drm_encoder *encoder, *enc;
+
+   enc = nv50_head_atom_get_encoder(armh);
+   if (!enc)
+   continue;
+
+   outp = nv50_real_outp(enc);
+   if (!outp)
+   continue;
+
+   encoder = >base.base;
 
if (!asyh->clr.crc)
continue;
@@ -443,8 +452,16 @@ void nv50_crc_atomic_set(struct nv50_head *head,
struct drm_device *dev = crtc->dev;
struct nv50_crc *crc = >crc;
const struct nv50_crc_func *func = nv50_disp(dev)->core->func->crc;
-   struct nouveau_encoder *outp =
-   nv50_real_outp(nv50_head_atom_get_encoder(asyh));
+   struct nouveau_encoder *outp;
+   struct drm_encoder *encoder;
+
+   encoder = nv50_head_atom_get_encoder(asyh);
+   if (!encoder)
+   return;
+
+   outp = nv50_real_outp(encoder);
+   if (!outp)
+   return;
 
func->set_src(head, outp->or, nv50_crc_source_type(outp, asyh->crc.src),
  >ctx[crc->ctx_idx]);
-- 
2.17.1



[PATCH] dpu1: dpu_encoder: fix a missing check on list iterator

2022-03-27 Thread Xiaomeng Tong
The bug is here:
 cstate = to_dpu_crtc_state(drm_crtc->state);

For the drm_for_each_crtc(), just like list_for_each_entry(),
the list iterator 'drm_crtc' will point to a bogus position
containing HEAD if the list is empty or no element is found.
This case must be checked before any use of the iterator,
otherwise it will lead to a invalid memory access.

To fix this bug, use a new variable 'iter' as the list iterator,
while use the origin variable 'drm_crtc' as a dedicated pointer
to point to the found element.

Cc: sta...@vger.kernel.org
Fixes: b107603b4ad0f ("drm/msm/dpu: map mixer/ctl hw blocks in encoder modeset")
Signed-off-by: Xiaomeng Tong 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1e648db439f9..d3fdb18e96f9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -965,7 +965,7 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
struct dpu_kms *dpu_kms;
struct list_head *connector_list;
struct drm_connector *conn = NULL, *conn_iter;
-   struct drm_crtc *drm_crtc;
+   struct drm_crtc *drm_crtc = NULL, *iter;
struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
@@ -1007,9 +1007,14 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
return;
}
 
-   drm_for_each_crtc(drm_crtc, drm_enc->dev)
-   if (drm_crtc->state->encoder_mask & drm_encoder_mask(drm_enc))
+   drm_for_each_crtc(iter, drm_enc->dev)
+   if (iter->state->encoder_mask & drm_encoder_mask(drm_enc)) {
+   drm_crtc = iter;
break;
+   }
+
+   if (!drm_crtc)
+   return;
 
/* Query resource that have been reserved in atomic check step. */
num_pp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
-- 
2.17.1



Re: [ PATCH ] Documentation: fixed doc-build warnings

2022-03-27 Thread Greg KH
On Sat, Mar 26, 2022 at 05:22:55PM +0530, kushagra...@outlook.com wrote:
> >From 9a9918b051d5709b5e14ca8afa29f3ef644b8688 Mon Sep 17 00:00:00 2001
> From: Kushagra Verma 
> Date: Sat, 26 Mar 2022 16:43:15 +0530
> Subject: [PATCH] Documentation: fixed doc-build warnings

This should not be in the body of the email, please fix :(

> 
>This patch fixes the following (and 2 other) doc-build warnings:
>   1. ./include/linux/dcache.h:308: warning: expecting prototype for dget, 
> dget_dlock(). Prototype was for dget_dlock() instead
> 
>   2. ./include/linux/fscache.h:268: warning: Excess function parameter 
> 'object' description in 'fscache_use_cookie'
> 
>   3 ./include/linux/fscache.h:285: warning: Excess function parameter 
> 'object' description in 'fscache_unuse_cookie'
> 
>   4. ./drivers/gpu/drm/drm_format_helper.c:640: warning: Excess function 
> parameter 'src' description in 'drm_fb_xrgb_to_mono_reversed'

This needs to be split up into one-patch-per-subsystem and can not be
taken as-is.

thanks,

greg k-h


Re: [PATCH] device: fix missing check on list iterator

2022-03-27 Thread Xiaomeng Tong
On Sat, 26 Mar 2022 22:38:05 -0700, Guenter Roeck  wrote:
> > @@ -103,11 +103,16 @@ nvkm_control_mthd_pstate_attr(struct nvkm_control 
> > *ctrl, void *data, u32 size)
> > return -EINVAL;
> >   
> > if (args->v0.state != NVIF_CONTROL_PSTATE_ATTR_V0_STATE_CURRENT) {
> > -   list_for_each_entry(pstate, >states, head) {
> > -   if (i++ == args->v0.state)
> > +   list_for_each_entry(iter, >states, head) {
> > +   if (i++ == args->v0.state) {
> > +   pstate = iter;
> 
> Is iter and the assignment really necessary ? Unless I am missing something,
> list_for_each_entry() always assigns pos (pstate/iter), even if the list is
> empty. If nothing is found, pstate would be NULL at the end, so

the pstate will not be NULL at the end! so the assignment is necessary!
#define list_for_each_entry(pos, head, member)  \
for (pos = __container_of((head)->next, pos, member);   \
 >member != (head);\
 pos = __container_of(pos->member.next, pos, member))

--
Xiaomeng Tong


[PATCH] tilcdc: tilcdc_external: fix an incorrect NULL check on list iterator

2022-03-27 Thread Xiaomeng Tong
The bug is here:
if (!encoder) {

The list iterator value 'encoder' will *always* be set and non-NULL
by list_for_each_entry(), so it is incorrect to assume that the
iterator value will be NULL if the list is empty or no element
is found.

To fix the bug, use a new variable 'iter' as the list iterator,
while use the original variable 'encoder' as a dedicated pointer
to point to the found element.

Cc: sta...@vger.kernel.org
Fixes: ec9eab097a500 ("drm/tilcdc: Add drm bridge support for attaching drm 
bridge drivers")
Signed-off-by: Xiaomeng Tong 
---
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 7594cf6e186e..3b86d002ef62 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -60,11 +60,13 @@ struct drm_connector *tilcdc_encoder_find_connector(struct 
drm_device *ddev,
 int tilcdc_add_component_encoder(struct drm_device *ddev)
 {
struct tilcdc_drm_private *priv = ddev->dev_private;
-   struct drm_encoder *encoder;
+   struct drm_encoder *encoder = NULL, *iter;
 
-   list_for_each_entry(encoder, >mode_config.encoder_list, head)
-   if (encoder->possible_crtcs & (1 << priv->crtc->index))
+   list_for_each_entry(iter, >mode_config.encoder_list, head)
+   if (iter->possible_crtcs & (1 << priv->crtc->index)) {
+   encoder = iter;
break;
+   }
 
if (!encoder) {
dev_err(ddev->dev, "%s: No suitable encoder found\n", __func__);
-- 
2.17.1