[PATCH] MAINTAINERS: drm: Remove myself as drm-bridge maintainer

[Archit Taneja]

I have moved on to other stuff for now. Haven't been able to make time
to review bridge related work. Andrzej has been doing it by himself
for a while now.

Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: Daniel Vetter 
Signed-off-by: Archit Taneja 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d9068ed4ee5..7ed01e227684 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4793,7 +4793,6 @@ F:Documentation/devicetree/bindings/display/atmel/
 T: git git://anongit.freedesktop.org/drm/drm-misc
 
 DRM DRIVERS FOR BRIDGE CHIPS
-M: Archit Taneja 
 M: Andrzej Hajda 
 R: Laurent Pinchart 
 S: Maintained
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 5/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver

[Archit Taneja]

t;dev, "error enabling panel (%d)\n", ret);
+}
+
+static int tc358764_attach(struct drm_bridge *bridge)
+{
+   struct tc358764 *ctx = bridge_to_tc358764(bridge);
+   struct drm_device *drm = bridge->dev;
+   int ret;
+
+   ctx->connector.polled = DRM_CONNECTOR_POLL_HPD;
+   ret = drm_connector_init(drm, >connector,
+_connector_funcs,
+DRM_MODE_CONNECTOR_LVDS);
+   if (ret) {
+   DRM_ERROR("Failed to initialize connector\n");
+   return ret;
+   }
+
+   drm_connector_helper_add(>connector,
+_connector_helper_funcs);
+   drm_mode_connector_attach_encoder(>connector, bridge->encoder);
+   drm_panel_attach(ctx->panel, >connector);
+   ctx->connector.funcs->reset(>connector);
+   drm_fb_helper_add_one_connector(drm->fb_helper, >connector);
+   drm_connector_register(>connector);


Aren't drm_connector_register()/unregister calls managed by the drm
core?

Otherwise:

Reviewed-by: Archit Taneja 

Thanks,
Archit


+
+   return 0;
+}
+
+static void tc358764_detach(struct drm_bridge *bridge)
+{
+   struct tc358764 *ctx = bridge_to_tc358764(bridge);
+   struct drm_device *drm = bridge->dev;
+
+   drm_connector_unregister(>connector);
+   drm_fb_helper_remove_one_connector(drm->fb_helper, >connector);
+   drm_panel_detach(ctx->panel);
+   ctx->panel = NULL;
+   drm_connector_unreference(>connector);
+}
+
+static const struct drm_bridge_funcs tc358764_bridge_funcs = {
+   .disable = tc358764_disable,
+   .post_disable = tc358764_post_disable,
+   .enable = tc358764_enable,
+   .pre_enable = tc358764_pre_enable,
+   .attach = tc358764_attach,
+   .detach = tc358764_detach,
+};
+
+static int tc358764_parse_dt(struct tc358764 *ctx)
+{
+   struct device *dev = ctx->dev;
+   int ret;
+
+   ctx->gpio_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(ctx->gpio_reset)) {
+   dev_err(dev, "no reset GPIO pin provided\n");
+   return PTR_ERR(ctx->gpio_reset);
+   }
+
+   ret = drm_of_find_panel_or_bridge(ctx->dev->of_node, 1, 0, >panel,
+ NULL);
+   if (ret && ret != -EPROBE_DEFER)
+   dev_err(dev, "cannot find panel (%d)\n", ret);
+
+   return ret;
+}
+
+static int tc358764_configure_regulators(struct tc358764 *ctx)
+{
+   int i, ret;
+
+   for (i = 0; i < ARRAY_SIZE(ctx->supplies); ++i)
+   ctx->supplies[i].supply = tc358764_supplies[i];
+
+   ret = devm_regulator_bulk_get(ctx->dev, ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+   if (ret < 0)
+   dev_err(ctx->dev, "failed to get regulators: %d\n", ret);
+
+   return ret;
+}
+
+static int tc358764_probe(struct mipi_dsi_device *dsi)
+{
+   struct device *dev = >dev;
+   struct tc358764 *ctx;
+   int ret;
+
+   ctx = devm_kzalloc(dev, sizeof(struct tc358764), GFP_KERNEL);
+   if (!ctx)
+   return -ENOMEM;
+
+   mipi_dsi_set_drvdata(dsi, ctx);
+
+   ctx->dev = dev;
+
+   dsi->lanes = 4;
+   dsi->format = MIPI_DSI_FMT_RGB888;
+   dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST
+   | MIPI_DSI_MODE_VIDEO_AUTO_VERT | MIPI_DSI_MODE_LPM;
+
+   ret = tc358764_parse_dt(ctx);
+   if (ret < 0)
+   return ret;
+
+   ret = tc358764_configure_regulators(ctx);
+   if (ret < 0)
+   return ret;
+
+   ctx->bridge.funcs = _bridge_funcs;
+   ctx->bridge.of_node = dev->of_node;
+
+   drm_bridge_add(>bridge);
+
+   ret = mipi_dsi_attach(dsi);
+   if (ret < 0) {
+   drm_bridge_remove(>bridge);
+   dev_err(dev, "failed to attach dsi\n");
+   }
+
+   return ret;
+}
+
+static int tc358764_remove(struct mipi_dsi_device *dsi)
+{
+   struct tc358764 *ctx = mipi_dsi_get_drvdata(dsi);
+
+   mipi_dsi_detach(dsi);
+   drm_bridge_remove(>bridge);
+
+   return 0;
+}
+
+static const struct of_device_id tc358764_of_match[] = {
+   { .compatible = "toshiba,tc358764" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, tc358764_of_match);
+
+static struct mipi_dsi_driver tc358764_driver = {
+   .probe = tc358764_probe,
+   .remove = tc358764_remove,
+   .driver = {
+   .name = "tc358764",
+   .owner = THIS_MODULE,
+   .of_match_table = tc358764_of_match,
+   },
+};
+module_mipi_dsi_driver(tc358764_driver);
+
+MODULE_AUTHOR("Andrzej Hajda ");
+MODULE_AUTHOR("Maciej Purski ");
+MODULE_DESCRIPTION("MIPI-DSI based Driver for TC358764 DSI/LVDS Bridge");
+MODULE_LICENSE("GPL v2");


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/msm/display: negative x/y in cursor move

[Archit Taneja]

On Wednesday 25 July 2018 08:40 PM, Carsten Behling wrote:

Hi,


Thanks for the patch. Could you tell how to reproduce this issue
on a db410c?

 >

I was playing with xrandr's --rotate and --reflect options to get
a rotated output, but wasn't able to generate negative x/y
co-ordinates. I'm using linaro's debian userspace, running lxqt.


I used Yocto Rocko from 96Boards

https://github.com/96boards/oe-rpb-manifest/tree/rocko

MACHINE=dragonboard-410c
DISTRO=rpb

rpb-desktop-image

Connect HDMI monitor and USB mouse, then

1.) Just boot. Wait for X-Server up.
2.) From my serial console:
      DISPLAY=:0.0 xrandr -o 2
3.) Try to move the mouse to the upper (the rotated lower) border.

Interesting to know that your debian user space is ok. The yocto X11 
configuration is very basic.

There may be a X11 configuration or extension that does the trick on Debian.


Thanks, I'll give this a try.

The patch looks good, anyway. Rob's queued it for msm-next.

Archit



Therefore, I asked the X11 people where to fix:

https://www.spinics.net/lists/xorg/msg58969.html

Best regards
-Carsten


2018-07-24 19:33 GMT+02:00 Archit Taneja <mailto:arch...@codeaurora.org>>:


Hi,

On Tuesday 17 July 2018 04:33 AM, Carsten Behling wrote:

modesetting X11 driver may provide negative x/y cordinates in
mdp5_crtc_cursor_move call when rotation is enabled.

Cursor buffer can overlap down to its negative width/height.

ROI has to be recalculated for negative x/y indicating using the
lower/right corner of the cursor buffer and hotspot must be set
in MDP5_LM_CURSOR_XY_SRC_Y MDP5_LM_CURSOR_XY_SRC_X.


Thanks for the patch. Could you tell how to reproduce this issue
on a db410c?

I was playing with xrandr's --rotate and --reflect options to get
a rotated output, but wasn't able to generate negative x/y
co-ordinates. I'm using linaro's debian userspace, running lxqt.

Thanks,
Archit



Signed-off-by: Carsten Behling mailto:carsten.behl...@gmail.com>>
---
Changes in v2:
- fixed format specifier in debug message

   drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 51
++-
   1 file changed, 43 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 10271359789e..a7f4a6688fec 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -65,7 +65,7 @@ struct mdp5_crtc {
                 struct drm_gem_object *scanout_bo;
                 uint64_t iova;
                 uint32_t width, height;
-               uint32_t x, y;
+               int x, y;
         } cursor;
   };
   #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
@@ -760,20 +760,31 @@ static void get_roi(struct drm_crtc *crtc,
uint32_t *roi_w, uint32_t *roi_h)
          * Cursor Region Of Interest (ROI) is a plane read from
cursor
          * buffer to render. The ROI region is determined by
the visibility of
          * the cursor point. In the default Cursor image the
cursor point will
-        * be at the top left of the cursor image, unless it is
specified
-        * otherwise using hotspot feature.
+        * be at the top left of the cursor image.
          *
+        * Without rotation:
          * If the cursor point reaches the right (xres - x <
cursor.width) or
          * bottom (yres - y < cursor.height) boundary of the
screen, then ROI
          * width and ROI height need to be evaluated to crop
the cursor image
          * accordingly.
          * (xres-x) will be new cursor width when x > (xres -
cursor.width)
          * (yres-y) will be new cursor height when y > (yres -
cursor.height)
+        *
+        * With rotation:
+        * We get negative x and/or y coordinates.
+        * (cursor.width - abs(x)) will be new cursor width when
x < 0
+        * (cursor.height - abs(y)) will be new cursor width
when y < 0
          */
-       *roi_w = min(mdp5_crtc->cursor.width, xres -
+       if (mdp5_crtc->cursor.x >= 0)
+               *roi_w = min(mdp5_crtc->cursor.width, xres -
                         mdp5_crtc->cursor.x);
-       *roi_h = min(mdp5_crtc->cursor.height, yres -
+       else
+               *roi_w = mdp5_crtc->cursor.width -
abs(mdp5_crtc->cursor.x);
+       if (mdp5_crtc->cursor.y >= 0)
+               *roi_h = min(mdp5_crtc->curso

Re: [PATCH v3 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Archit Taneja]

On Wednesday 11 July 2018 09:18 PM, Rob Herring wrote:

On Mon, Jul 09, 2018 at 02:37:51PM +0530, Archit Taneja wrote:

Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.

Reviewed-by: Philippe Cornu 
Reviewed-by: Sean Paul 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Archit Taneja 
---
  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80 ++
  1 file changed, 80 insertions(+)


Reviewed-by: Rob Herring 


queued to drm-misc-next.

Thanks,
Archit

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus

[Archit Taneja]

On Monday 09 July 2018 02:37 PM, Archit Taneja wrote:

Add a section that describes dt-bindings for peripherals that support
MIPI DSI, but have a different bus as the primary control bus, or no
control bus at all. Add an example for a peripheral with a non-DSI
control bus.

Reviewed-by: Rob Herring 
Reviewed-by: Boris Brezillon 
Reviewed-by: Philippe Cornu 
Reviewed-by: Sean Paul 
Signed-off-by: Archit Taneja 


queued to drm-misc-next.

Thanks,
Archit


---
  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 71 +++---
  1 file changed, 64 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 973c27273772..b7c5bf47403c 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -16,7 +16,7 @@ The following assumes that only a single peripheral is 
connected to a DSI
  host. Experience shows that this is true for the large majority of setups.
  
  DSI host

-
+
  
  In addition to the standard properties and those defined by the parent bus of

  a DSI host, the following properties apply to a node representing a DSI host.
@@ -30,11 +30,16 @@ Required properties:
different value here. See below.
  
  DSI peripheral

---
+==
  
-Peripherals are represented as child nodes of the DSI host's node. Properties

-described here apply to all DSI peripherals, but individual bindings may want
-to define additional, device-specific properties.
+Peripherals with DSI as control bus, or no control bus
+--
+
+Peripherals with the DSI bus as the primary control bus, or peripherals with
+no control bus but use the DSI bus to transmit pixel data are represented
+as child nodes of the DSI host's node. Properties described here apply to all
+DSI peripherals, but individual bindings may want to define additional,
+device-specific properties.
  
  Required properties:

  - reg: The virtual channel number of a DSI peripheral. Must be in the range
@@ -49,9 +54,25 @@ case two alternative representations can be chosen:
property is the number of the first virtual channel and the second cell is
the number of consecutive virtual channels.
  
-Example


+Peripherals with a different control bus
+
+
+There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
+primary control bus, but are also connected to a DSI bus (mostly for the data
+path). Connections between such peripherals and a DSI host can be represented
+using the graph bindings [1], [2].
+
+[1] Documentation/devicetree/bindings/graph.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
  
+Examples

+
+- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
+  with different virtual channel configurations.
+- (4) is an example of a peripheral on a I2C control bus connected to a
+  DSI host using of-graph bindings.
+
+1)
dsi-host {
...
  
@@ -67,6 +88,7 @@ Example

...
};
  
+2)

dsi-host {
...
  
@@ -82,6 +104,7 @@ Example

...
};
  
+3)

dsi-host {
...
  
@@ -96,3 +119,37 @@ Example
  
  		...

};
+
+4)
+   i2c-host {
+   ...
+
+   dsi-bridge@35 {
+   compatible = "...";
+   reg = <0x35>;
+
+   ports {
+   ...
+
+   port {
+   bridge_mipi_in: endpoint {
+   remote-endpoint = 
<_mipi_out>;
+   };
+   };
+   };
+   };
+   };
+
+   dsi-host {
+   ...
+
+   ports {
+   ...
+
+   port {
+   host_mipi_out: endpoint {
+   remote-endpoint = <_mipi_in>;
+   };
+   };
+   };
+   };


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/msm/display: negative x/y in cursor move

[Archit Taneja]

Hi,

On Tuesday 17 July 2018 04:33 AM, Carsten Behling wrote:

modesetting X11 driver may provide negative x/y cordinates in
mdp5_crtc_cursor_move call when rotation is enabled.

Cursor buffer can overlap down to its negative width/height.

ROI has to be recalculated for negative x/y indicating using the
lower/right corner of the cursor buffer and hotspot must be set
in MDP5_LM_CURSOR_XY_SRC_Y MDP5_LM_CURSOR_XY_SRC_X.


Thanks for the patch. Could you tell how to reproduce this issue
on a db410c?

I was playing with xrandr's --rotate and --reflect options to get
a rotated output, but wasn't able to generate negative x/y
co-ordinates. I'm using linaro's debian userspace, running lxqt.

Thanks,
Archit



Signed-off-by: Carsten Behling 
---
Changes in v2:
- fixed format specifier in debug message

  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 51 ++-
  1 file changed, 43 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 10271359789e..a7f4a6688fec 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -65,7 +65,7 @@ struct mdp5_crtc {
struct drm_gem_object *scanout_bo;
uint64_t iova;
uint32_t width, height;
-   uint32_t x, y;
+   int x, y;
} cursor;
  };
  #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
@@ -760,20 +760,31 @@ static void get_roi(struct drm_crtc *crtc, uint32_t 
*roi_w, uint32_t *roi_h)
 * Cursor Region Of Interest (ROI) is a plane read from cursor
 * buffer to render. The ROI region is determined by the visibility of
 * the cursor point. In the default Cursor image the cursor point will
-* be at the top left of the cursor image, unless it is specified
-* otherwise using hotspot feature.
+* be at the top left of the cursor image.
 *
+* Without rotation:
 * If the cursor point reaches the right (xres - x < cursor.width) or
 * bottom (yres - y < cursor.height) boundary of the screen, then ROI
 * width and ROI height need to be evaluated to crop the cursor image
 * accordingly.
 * (xres-x) will be new cursor width when x > (xres - cursor.width)
 * (yres-y) will be new cursor height when y > (yres - cursor.height)
+*
+* With rotation:
+* We get negative x and/or y coordinates.
+* (cursor.width - abs(x)) will be new cursor width when x < 0
+* (cursor.height - abs(y)) will be new cursor width when y < 0
 */
-   *roi_w = min(mdp5_crtc->cursor.width, xres -
+   if (mdp5_crtc->cursor.x >= 0)
+   *roi_w = min(mdp5_crtc->cursor.width, xres -
mdp5_crtc->cursor.x);
-   *roi_h = min(mdp5_crtc->cursor.height, yres -
+   else
+   *roi_w = mdp5_crtc->cursor.width - abs(mdp5_crtc->cursor.x);
+   if (mdp5_crtc->cursor.y >= 0)
+   *roi_h = min(mdp5_crtc->cursor.height, yres -
mdp5_crtc->cursor.y);
+   else
+   *roi_h = mdp5_crtc->cursor.height - abs(mdp5_crtc->cursor.y);
  }
  
  static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)

@@ -783,7 +794,7 @@ static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
struct mdp5_kms *mdp5_kms = get_kms(crtc);
const enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
uint32_t blendcfg, stride;
-   uint32_t x, y, width, height;
+   uint32_t x, y, src_x, src_y, width, height;
uint32_t roi_w, roi_h;
int lm;
  
@@ -800,6 +811,26 @@ static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
  
  	get_roi(crtc, _w, _h);
  
+	/* If cusror buffer overlaps due to rotation on the

+* upper or left screen border the pixel offset inside
+* the cursor buffer of the ROI is the positive overlap
+* distance.
+*/
+   if (mdp5_crtc->cursor.x < 0) {
+   src_x = abs(mdp5_crtc->cursor.x);
+   x = 0;
+   } else {
+   src_x = 0;
+   }
+   if (mdp5_crtc->cursor.y < 0) {
+   src_y = abs(mdp5_crtc->cursor.y);
+   y = 0;
+   } else {
+   src_y = 0;
+   }
+   DBG("%s: x=%u, y=%u roi_w=%u roi_h=%u src_x=%u src_y=%u",
+   crtc->name, x, y, roi_w, roi_h, src_x, src_y);
+
mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_STRIDE(lm), stride);
mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_FORMAT(lm),
MDP5_LM_CURSOR_FORMAT_FORMAT(CURSOR_FMT_ARGB));
@@ -812,6 +843,9 @@ static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_START_XY(lm),
MDP5_LM_CURSOR_START_XY_Y_START(y) |
MDP5_LM_CURSOR_START_XY_X_START(x));
+   mdp5_write(mdp5_kms, 

Re: [PATCH 11/21] drm/msm: higher values of pclk can exceed 32 bits when multiplied by a factor

[Archit Taneja]

On Monday 09 July 2018 11:01 PM, Sean Paul wrote:

From: Abhinav Kumar 

Make the pclk_rate u64 to accommodate higher pixel clock
rates.

Changes in v4:
  - fixed commit message

Signed-off-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 671039b7b75b..73587e731a23 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -669,7 +669,8 @@ static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host, 
bool is_dual_dsi)
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
u8 lanes = msm_host->lanes;
u32 bpp = dsi_get_bpp(msm_host->format);
-   u32 pclk_rate;
+   u64 pclk_rate;
+   u64 pclk_bpp;
  


Minor nit, I don't think we need to change pclk_rate to u64. A u32 can
hold up to a 2.14 Ghz pixel clock, which we're still quite far away
from in real life. u64 for pclk_bpp is right, though.

Thanks,
Archit


if (!mode) {
pr_err("%s: mode not set\n", __func__);
@@ -689,13 +690,15 @@ static int dsi_calc_clk_rate(struct msm_dsi_host 
*msm_host, bool is_dual_dsi)
if (is_dual_dsi)
pclk_rate /= 2;
  
+	pclk_bpp = pclk_rate * bpp;

if (lanes > 0) {
-   msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
+   do_div(pclk_bpp, (8 * lanes));
} else {
pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
-   msm_host->byte_clk_rate = (pclk_rate * bpp) / 8;
+   do_div(pclk_bpp, 8);
}
msm_host->pixel_clk_rate = pclk_rate;
+   msm_host->byte_clk_rate = pclk_bpp;
  
  	DBG("pclk=%d, bclk=%d", msm_host->pixel_clk_rate,

msm_host->byte_clk_rate);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH 09/21] drm/msm/mdp5: subclass msm_mdss for mdp5

[Archit Taneja]

On Monday 09 July 2018 11:01 PM, Sean Paul wrote:

From: Rajesh Yadav 

SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.

Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.

Add mdss helper interface (msm_mdss_funcs) to msm_mdss
base for mdp5/dpu mdss specific implementation calls.

This change subclasses msm_mdss for mdp5, dpu specific
changes will be done separately.


Reviewed-by: Archit Taneja 



Changes in v3:
- none

Changes in v2:
- fixed indentation for irq_domain_add_linear call (Sean Paul)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
[seanpaul rebased on msm-next and resolved conflicts]
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 154 --
  drivers/gpu/drm/msm/msm_drv.c |  22 +++-
  drivers/gpu/drm/msm/msm_kms.h |  17 ++-
  3 files changed, 109 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
index f2a0db7a8a03..1cc4e57f0226 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
@@ -20,12 +20,10 @@
  #include "msm_drv.h"
  #include "mdp5_kms.h"
  
-/*

- * If needed, this can become more specific: something like struct mdp5_mdss,
- * which contains a 'struct msm_mdss base' member.
- */
-struct msm_mdss {
-   struct drm_device *dev;
+#define to_mdp5_mdss(x) container_of(x, struct mdp5_mdss, base)
+
+struct mdp5_mdss {
+   struct msm_mdss base;
  
  	void __iomem *mmio, *vbif;
  
@@ -41,22 +39,22 @@ struct msm_mdss {

} irqcontroller;
  };
  
-static inline void mdss_write(struct msm_mdss *mdss, u32 reg, u32 data)

+static inline void mdss_write(struct mdp5_mdss *mdp5_mdss, u32 reg, u32 data)
  {
-   msm_writel(data, mdss->mmio + reg);
+   msm_writel(data, mdp5_mdss->mmio + reg);
  }
  
-static inline u32 mdss_read(struct msm_mdss *mdss, u32 reg)

+static inline u32 mdss_read(struct mdp5_mdss *mdp5_mdss, u32 reg)
  {
-   return msm_readl(mdss->mmio + reg);
+   return msm_readl(mdp5_mdss->mmio + reg);
  }
  
  static irqreturn_t mdss_irq(int irq, void *arg)

  {
-   struct msm_mdss *mdss = arg;
+   struct mdp5_mdss *mdp5_mdss = arg;
u32 intr;
  
-	intr = mdss_read(mdss, REG_MDSS_HW_INTR_STATUS);

+   intr = mdss_read(mdp5_mdss, REG_MDSS_HW_INTR_STATUS);
  
  	VERB("intr=%08x", intr);
  
@@ -64,7 +62,7 @@ static irqreturn_t mdss_irq(int irq, void *arg)

irq_hw_number_t hwirq = fls(intr) - 1;
  
  		generic_handle_irq(irq_find_mapping(

-   mdss->irqcontroller.domain, hwirq));
+   mdp5_mdss->irqcontroller.domain, hwirq));
intr &= ~(1 << hwirq);
}
  
@@ -84,19 +82,19 @@ static irqreturn_t mdss_irq(int irq, void *arg)
  
  static void mdss_hw_mask_irq(struct irq_data *irqd)

  {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
  
  	smp_mb__before_atomic();

-   clear_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   clear_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
  }
  
  static void mdss_hw_unmask_irq(struct irq_data *irqd)

  {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
  
  	smp_mb__before_atomic();

-   set_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   set_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
  }
  
@@ -109,13 +107,13 @@ static struct irq_chip mdss_hw_irq_chip = {

  static int mdss_hw_irqdomain_map(struct irq_domain *d, unsigned int irq,
 irq_hw_number_t hwirq)
  {
-   struct msm_mdss *mdss = d->host_data;
+   struct mdp5_mdss *mdp5_mdss = d->host_data;
  
  	if (!(VALID_IRQS & (1 << hwirq)))

return -EPERM;
  
  	irq_set_chip_and_handler(irq, _hw_irq_chip, handle_level_irq);

-   irq_set_chip_data(irq, mdss);
+   irq_set_chip_data(irq, mdp5_mdss);
  
  	return 0;

  }
@@ -126,90 +124,99 @@ static const struct irq_domain_ops mdss_hw_irqdomain_ops 
= {
  };
  
  
-static int mdss_irq_domain_init(struct msm_mdss *mdss)

+static int mdss_irq_domain_init(struct mdp5_mdss *mdp5_mdss)
  {
-   struct device *dev = mdss->dev->dev;
+   struct device *dev = mdp5_mdss->base.dev->dev;
struct irq_domain *d;
  
  	d = irq_domain_add_linear(dev->of_node, 32, _hw_irqdomain_ops,

- mdss);
+ mdp5_mdss);
if (!d) {

Re: [PATCH 07/21] drm/msm/dsi: initialize postdiv_lock before use for 10nm pll

[Archit Taneja]

On Monday 09 July 2018 11:01 PM, Sean Paul wrote:

From: Rajesh Yadav 

postdiv_lock spinlock was used before initialization
for 10nm pll. It causes following spin_bug:
"BUG: spinlock bad magic on CPU#0".
Initialize spinlock before its usage.


Reviewed-by: Archit Taneja 



Signed-off-by: Rajesh Yadav 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index c4c37a7df637..4c03f0b7343e 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -798,6 +798,8 @@ struct msm_dsi_pll *msm_dsi_pll_10nm_init(struct 
platform_device *pdev, int id)
return ERR_PTR(-ENOMEM);
}
  
+	spin_lock_init(_10nm->postdiv_lock);

+
pll = _10nm->base;
pll->min_rate = 10UL;
pll->max_rate = 35UL;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/21] drm/msm/dsi: adjust dsi timing for dual dsi mode

[Archit Taneja]

On Monday 09 July 2018 11:01 PM, Sean Paul wrote:

From: Chandan Uddaraju 

For dual dsi mode, the horizontal timing needs
to be divided by half since both the dsi controllers
will be driving this panel. Adjust the pixel clock and
DSI timing accordingly.


Reviewed-by: Archit Taneja 



Changes in V2:
--Removed Change-Id from the commit text tags.

Changes in V3:
--Instead of adjusting the DRM mode structure, divide
   the clocks and horizontal timings in DSI host just
   before configuring the values.

Signed-off-by: Chandan Uddaraju 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/msm/dsi/dsi.h |  6 ++-
  drivers/gpu/drm/msm/dsi/dsi_host.c| 55 +--
  drivers/gpu/drm/msm/dsi/dsi_manager.c |  7 ++--
  3 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a47acd..01c38f67d699 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -162,7 +162,8 @@ void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host 
*host,
  int msm_dsi_host_enable(struct mipi_dsi_host *host);
  int msm_dsi_host_disable(struct mipi_dsi_host *host);
  int msm_dsi_host_power_on(struct mipi_dsi_host *host,
-   struct msm_dsi_phy_shared_timings *phy_shared_timings);
+   struct msm_dsi_phy_shared_timings *phy_shared_timings,
+   bool is_dual_dsi);
  int msm_dsi_host_power_off(struct mipi_dsi_host *host);
  int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
struct drm_display_mode *mode);
@@ -175,7 +176,8 @@ int msm_dsi_host_set_src_pll(struct mipi_dsi_host *host,
struct msm_dsi_pll *src_pll);
  void msm_dsi_host_reset_phy(struct mipi_dsi_host *host);
  void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host *host,
-   struct msm_dsi_phy_clk_request *clk_req);
+   struct msm_dsi_phy_clk_request *clk_req,
+   bool is_dual_dsi);
  void msm_dsi_host_destroy(struct mipi_dsi_host *host);
  int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 2f1a2780658a..671039b7b75b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -118,6 +118,7 @@ struct msm_dsi_host {
struct clk *byte_intf_clk;
  
  	u32 byte_clk_rate;

+   u32 pixel_clk_rate;
u32 esc_clk_rate;
  
  	/* DSI v2 specific clocks */

@@ -511,7 +512,7 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
*msm_host)
goto error;
}
  
-	ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);

+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
goto error;
@@ -592,7 +593,7 @@ static int dsi_link_clk_enable_v2(struct msm_dsi_host 
*msm_host)
goto error;
}
  
-	ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);

+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
goto error;
@@ -662,7 +663,7 @@ static void dsi_link_clk_disable(struct msm_dsi_host 
*msm_host)
}
  }
  
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)

+static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host, bool is_dual_dsi)
  {
struct drm_display_mode *mode = msm_host->mode;
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
@@ -676,14 +677,28 @@ static int dsi_calc_clk_rate(struct msm_dsi_host 
*msm_host)
}
  
  	pclk_rate = mode->clock * 1000;

+
+   /*
+* For dual DSI mode, the current DRM mode has
+* the complete width of the panel. Since, the complete
+* panel is driven by two DSI controllers, the
+* the clock rates have to be split between
+* the two dsi controllers. Adjust the byte and
+* pixel clock rates for each dsi host accordingly.
+*/
+   if (is_dual_dsi)
+   pclk_rate /= 2;
+
if (lanes > 0) {
msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
} else {
pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
msm_host->byte_clk_rate = (pclk_rate * bpp) / 8;
}
+   msm_host->pixel_clk_rate = pclk_rate;
  
-	DBG("pclk=%d, bclk=%d", pclk_rate, msm_host->byte_clk_rate);

+   DBG("pclk=%d, bclk=%d", msm_host->pixel_clk_rate,
+   msm_host->byte_clk_rate);
  
  	msm_host->esc_clk_rate = clk_get_rate(

[PATCH v3 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus

[Archit Taneja]

Add a section that describes dt-bindings for peripherals that support
MIPI DSI, but have a different bus as the primary control bus, or no
control bus at all. Add an example for a peripheral with a non-DSI
control bus.

Reviewed-by: Rob Herring 
Reviewed-by: Boris Brezillon 
Reviewed-by: Philippe Cornu 
Reviewed-by: Sean Paul 
Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/display/mipi-dsi-bus.txt   | 71 +++---
 1 file changed, 64 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 973c27273772..b7c5bf47403c 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -16,7 +16,7 @@ The following assumes that only a single peripheral is 
connected to a DSI
 host. Experience shows that this is true for the large majority of setups.
 
 DSI host
-
+
 
 In addition to the standard properties and those defined by the parent bus of
 a DSI host, the following properties apply to a node representing a DSI host.
@@ -30,11 +30,16 @@ Required properties:
   different value here. See below.
 
 DSI peripheral
---
+==
 
-Peripherals are represented as child nodes of the DSI host's node. Properties
-described here apply to all DSI peripherals, but individual bindings may want
-to define additional, device-specific properties.
+Peripherals with DSI as control bus, or no control bus
+--
+
+Peripherals with the DSI bus as the primary control bus, or peripherals with
+no control bus but use the DSI bus to transmit pixel data are represented
+as child nodes of the DSI host's node. Properties described here apply to all
+DSI peripherals, but individual bindings may want to define additional,
+device-specific properties.
 
 Required properties:
 - reg: The virtual channel number of a DSI peripheral. Must be in the range
@@ -49,9 +54,25 @@ case two alternative representations can be chosen:
   property is the number of the first virtual channel and the second cell is
   the number of consecutive virtual channels.
 
-Example

+Peripherals with a different control bus
+
+
+There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
+primary control bus, but are also connected to a DSI bus (mostly for the data
+path). Connections between such peripherals and a DSI host can be represented
+using the graph bindings [1], [2].
+
+[1] Documentation/devicetree/bindings/graph.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
 
+Examples
+
+- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
+  with different virtual channel configurations.
+- (4) is an example of a peripheral on a I2C control bus connected to a
+  DSI host using of-graph bindings.
+
+1)
dsi-host {
...
 
@@ -67,6 +88,7 @@ Example
...
};
 
+2)
dsi-host {
...
 
@@ -82,6 +104,7 @@ Example
...
};
 
+3)
dsi-host {
...
 
@@ -96,3 +119,37 @@ Example
 
...
};
+
+4)
+   i2c-host {
+   ...
+
+   dsi-bridge@35 {
+   compatible = "...";
+   reg = <0x35>;
+
+   ports {
+   ...
+
+   port {
+   bridge_mipi_in: endpoint {
+   remote-endpoint = 
<_mipi_out>;
+   };
+   };
+   };
+   };
+   };
+
+   dsi-host {
+   ...
+
+   ports {
+   ...
+
+   port {
+   host_mipi_out: endpoint {
+   remote-endpoint = <_mipi_in>;
+   };
+   };
+   };
+   };
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/2] dt-bindings: mipi-dsi: dual-channel DSI bindings

[Archit Taneja]

DSI host controllers these days can be ganged together to drive larger
displays. Every SoC vendor supporting this is trying to add their own
DT property so that the corresponding drivers can identify that they
need to operate in the dual DSI mode. If we use the graph bindings, we
don't really need an additional DT property in the DSI host controller
to tell it that it's operating in dual-channel mode. It's something that
can be inferred from the bindings itself.

The first patch adds some explanation on how to deal with peripherals
that do DSI, but have a different control bus. This is something we've
already started using, but didn't have properly documented anywhere.

The second patch proposes bindings for DSI hosts/peripherals that
implement dual-channel DSI.

Changes in v3:
- Fixed a minor typo.
- Added Reviewed-by tags.
- Changed from RFC to PATCH.

Changes in v2:
- Incorported Rob's comments.

Archit Taneja (2):
  dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control
bus
  dt-bindings: mipi-dsi: Add dual-channel DSI related info

 .../devicetree/bindings/display/mipi-dsi-bus.txt   | 153 +++--
 1 file changed, 145 insertions(+), 8 deletions(-)

-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Archit Taneja]

Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.

Reviewed-by: Philippe Cornu 
Reviewed-by: Sean Paul 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80 ++
 1 file changed, 80 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index b7c5bf47403c..a336599f6c03 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,13 @@ Required properties:
 - #size-cells: Should be 0. There are cases where it makes sense to use a
   different value here. See below.
 
+Optional properties:
+- clock-master: boolean. Should be enabled if the host is being used in
+  conjunction with another DSI host to drive the same peripheral. Hardware
+  supporting such a configuration generally requires the data on both the 
busses
+  to be driven by the same clock. Only the DSI host instance controlling this
+  clock should contain this property.
+
 DSI peripheral
 ==
 
@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus 
(mostly for the data
 path). Connections between such peripherals and a DSI host can be represented
 using the graph bindings [1], [2].
 
+Peripherals that support dual channel DSI
+-
+
+Peripherals with higher bandwidth requirements can be connected to 2 DSI
+busses. Each DSI bus/channel drives some portion of the pixel data (generally
+left/right half of each line of the display, or even/odd lines of the display).
+The graph bindings should be used to represent the multiple DSI busses that are
+connected to this peripheral. Each DSI host's output endpoint can be linked to
+an input endpoint of the DSI peripheral.
+
 [1] Documentation/devicetree/bindings/graph.txt
 [2] Documentation/devicetree/bindings/media/video-interfaces.txt
 
@@ -71,6 +88,8 @@ Examples
   with different virtual channel configurations.
 - (4) is an example of a peripheral on a I2C control bus connected to a
   DSI host using of-graph bindings.
+- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
+  which uses I2C as its primary control bus.
 
 1)
dsi-host {
@@ -153,3 +172,64 @@ Examples
};
};
};
+
+5)
+   i2c-host {
+   dsi-bridge@35 {
+   compatible = "...";
+   reg = <0x35>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi0_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi1_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+   };
+
+   dsi0-host {
+   ...
+
+   /*
+* this DSI instance drives the clock for both the host
+* controllers
+*/
+   clock-master;
+
+   ports {
+   ...
+
+   port {
+   dsi0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   dsi1-host {
+   ...
+
+   ports {
+   ...
+
+   port {
+   dsi1_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: adv7511: Reset registers on hotplug

[Archit Taneja]

On Wednesday 04 July 2018 12:28 AM, Rob Clark wrote:

On Tue, Jul 3, 2018 at 12:56 PM, Sean Paul  wrote:

The bridge loses its hw state when the cable is unplugged. If we detect
this case in the hpd handler, reset its state.

Reported-by: Rob Clark 
Signed-off-by: Sean Paul 


Tested-by: Rob Clark 


---
This is the follow-up to "drm/msm: Disable mdp5 crtc when there are no
active planes". I incorrectly assumed the modeset was required from the
msm side, but Rob pointed out that he thought it might be a bridge
issue.


To elaborate, this is an atomic userspace (weston), when it sees the
display disconnected, it removes the planes from the CRTC but does not
disable the CRTC.  So drm/msm sets up the LM to scanout a solid color,
and leaves the encoder and dsi cranking along happily.  When
replugging the display, the atomic helpers see the CRTC is still
active and (correctly) doesn't do a full modeset.  So the bridge is
not re-configured/re-enabled.


The adv7511 connector's detect() op should have re-configured the
registers. I'm assuming it was never called after the cable is
plugged in again in the wetson usecase?

With this patch, in the case of fb emulation/X, I'm wondering if
we will end up trying to re-enable ADV7511 twice. First, in the new code
in adv7511_hpd_work(), and later in adv7511_detect() (i.e, the
connector's detect op).

I'm guessing the 'hpd' variable in the check in adv7511_detect() below
should ideally be false, and avoid us trying to configure the registers
again, but I'm not entirely sure.

if (status == connector_status_connected && hpd && adv7511->powered) {
regcache_mark_dirty(adv7511->regmap);
...

In any case:

Reviewed-by: Archit Taneja 



Arguably this perhaps isn't what weston *wanted* to do, but in the end
the bug is in the bridge.

We could possibly set the connector link_status to BAD as an
alternative.  But at least the build of weston I'm using atm doesn't
handle the link_status propery, this approach requires each atomic
userspace to handle this case.  Compared to Sean's approach which is
transparent to userspace, which seems attractive.

BR,
-R



  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 73021b388e12..dd3ff2f2cdce 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -429,6 +429,18 @@ static void adv7511_hpd_work(struct work_struct *work)
 else
 status = connector_status_disconnected;

+   /*
+* The bridge resets its registers on unplug. So when we get a plug
+* event and we're already supposed to be powered, cycle the bridge to
+* restore its state.
+*/
+   if (status == connector_status_connected &&
+   adv7511->connector.status == connector_status_disconnected &&
+   adv7511->powered) {
+   regcache_mark_dirty(adv7511->regmap);
+   adv7511_power_on(adv7511);
+   }
+
 if (adv7511->connector.status != status) {
 adv7511->connector.status = status;
 if (status == connector_status_disconnected)
--
Sean Paul, Software Engineer, Google / Chromium OS


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH] drm/msm/dsi: add only dsi nodes with a valid device to list

[Archit Taneja]

On Saturday 16 June 2018 11:35 AM, Abhinav Kumar wrote:

Before adding a DSI node to the private list check if the
node has a valid device connected to it through an endpoint.

This is required in cases where the chipset supports multiple
DSI hosts but only one of them is being used.

In the current implementation even inactive nodes get added
resulting in creation of redundant connectors.


Reviewed-by: Archit Taneja 



Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/dsi/dsi.c  |  6 +-
  drivers/gpu/drm/msm/dsi/dsi.h  |  1 +
  drivers/gpu/drm/msm/dsi/dsi_host.c | 10 ++
  3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index b744bcc..46a4906 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -120,7 +120,11 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
if (IS_ERR(msm_dsi))
return PTR_ERR(msm_dsi);
  
-	priv->dsi[msm_dsi->id] = msm_dsi;

+   /* Add only the host which has a device attached to it */
+   if (msm_dsi_has_valid_device(msm_dsi->host)) {
+   pr_info("id = %d has valid device\n", msm_dsi->id);
+   priv->dsi[msm_dsi->id] = msm_dsi;
+   }
  
  	return 0;

  }
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a..aa198ef 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -180,6 +180,7 @@ void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host 
*host,
  int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
  int msm_dsi_host_init(struct msm_dsi *msm_dsi);
+bool msm_dsi_has_valid_device(struct mipi_dsi_host *host);
  int msm_dsi_runtime_suspend(struct device *dev);
  int msm_dsi_runtime_resume(struct device *dev);
  
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c

index 2f1a278..25d65e5 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -470,6 +470,16 @@ static void dsi_bus_clk_disable(struct msm_dsi_host 
*msm_host)
clk_disable_unprepare(msm_host->bus_clks[i]);
  }
  
+bool msm_dsi_has_valid_device(struct mipi_dsi_host *host)

+{
+   struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+
+   if (msm_host->device_node)
+   return true;
+
+   return false;
+}
+
  int msm_dsi_runtime_suspend(struct device *dev)
  {
struct platform_device *pdev = to_platform_device(dev);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH] drm/msm/dsi: set encoder mode for DRM bridge explicitly

[Archit Taneja]

On Saturday 16 June 2018 11:26 AM, Abhinav Kumar wrote:

Currently, DRM bridge for DPU relies on the default video
mode setting to set the encoder mode.

Add an explicit call to set the encoder mode for bridges.


Reviewed-by: Archit Taneja 



Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/dsi/dsi_manager.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 4cb1cb6..0607ad0 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -836,6 +836,7 @@ void msm_dsi_manager_attach_dsi_device(int id, u32 
device_flags)
struct msm_drm_private *priv;
struct msm_kms *kms;
struct drm_encoder *encoder;
+   bool cmd_mode;
  
  	/*

 * drm_device pointer is assigned to msm_dsi only in the modeset_init
@@ -850,10 +851,11 @@ void msm_dsi_manager_attach_dsi_device(int id, u32 
device_flags)
priv = dev->dev_private;
kms = priv->kms;
encoder = msm_dsi_get_encoder(msm_dsi);
+   cmd_mode = !(device_flags &
+MIPI_DSI_MODE_VIDEO);
  
  	if (encoder && kms->funcs->set_encoder_mode)

-   if (!(device_flags & MIPI_DSI_MODE_VIDEO))
-   kms->funcs->set_encoder_mode(kms, encoder, true);
+   kms->funcs->set_encoder_mode(kms, encoder, cmd_mode);
  }
  
  int msm_dsi_manager_register(struct msm_dsi *msm_dsi)



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Archit Taneja]

On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote:

Hi Archit,

Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja:

On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:

Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:

On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:

Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:

Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.

Signed-off-by: Archit Taneja 


Looks like a great solution for that problem, so
Reviewed-by: Heiko Stuebner 

As I'm looking into that for my rk3399-scarlet device right now and
couldn't find this patchset in the kernel yet, is it planned to
merge or refresh these binding changes or were problems encountered.

At least an Ack/Review from Rob seems to be missing.


I forgot about these patches. Rob had reviewed the first one in
the set the second one still needed an Ack. I'll post a v3
that adds the Reviewed-bys and fixes a small typo.


very nice ... because it looks like yesterday I managed to make the
Rockchip dsi work in dual mode following this.

But one question came up, do you really want two input ports on the panel
side? I.e. hardware-wise, I guess the panel will have one 8-lane or so
input thatonly gets split up on the soc side onto 2 dsi controllers?


I think all dual DSI panels actually have 2 DSI controllers/parsers
within them, one on each port. The MIPI DSI spec doesn't support 8
lanes. Also, the pixels coming out of the host are distributed among
the lanes differently than what would have been the case with a
'theoretical' 8 lane receiver.

Other than that, some dual DSI panels only accept DSI commands on the
'master' port, where as others expect the same command to be sent across
both the ports.

Therefore, I think it's better to represent dual DSI panels having 2
DSI input ports.

Your DT looks good to me.


Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints
in one port for the dsi-links.



Sorry, I didn't notice you'd created two endpoints within a single port.

I don't think I'm particular about 2 ports vs 1 port with 2 endpoints.
They both seem okay to me as long as we follow it consistently. I'm
myself not 100% sure of how to figure where one should prefer endpoints
over ports. Maybe someone more familiar with the of graph bindings
could comment here.



The issue I see with using ports and not endpoints for dual-dsi links
is with distinguishing between input and output ports.

For a panel that's easy, as you every port will be an input port and if
you have 2, it's supposed dual-dsi. But for example I guess there might
exist some dual-dsi-to-something bridges, where you would end up
with say 3 (or even more) ports ... two dual-dsi inputs and 1 or more
outputs.


Okay, I get your point here. Although, even if the remote device had
exactly 2 ports. Is it safe to assume that port #0 is an input port and
port #1 is an output port? Is that the norm?

I've at least seen one device (toshiba,tc358767 bridge) that can 
actually take either DPI as input or DSI based on how you configure it.

There are 2 input ports here, port #0 for DSI and port #1 for DPI. Would
it have made sense here to have a single port and 2 endpoints here too?




While the following argument might not be 100% valid from a dt-purity
standpoint implementing this might get hairy for _any_ operating system,
as you will need each panel/bridge to tell what the ports are used for.


Yeah.



I.e. in my endpoint based mapping, right now I have this nice and generic
WIP function to parse the of_graph and get the master+slave nodes:

https://github.com/mmind/linux-rockchip/blob/tmp/rk3399-gru-bob-scarlet/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#L697
[0]


I'd tried out something locally before posting this patch, I don't have
the code for it, but I can describe the steps I took. This code expects
the panel/bridge to have 2 input ports.

1. DSI0 host driver looks up its output port, gets the remote endpoint,
and get this endpoint's parent (using
of_graph_get_remote_port_parent()). Keeps the parent device node in a
temp variable.

2. DSI1 host driver does the same thing.

3. DSI0 and DSI1 check whether their outputs are connected to the
same device. If so, they're in dual DSI mode. If not, they are
operating independently.

The positive of this approach is that we don't need to make any
assumptions about the panel/bridge's port numbers, which is great.
The negative is that our DSI controller instances now need to query
each other, which can be messy, but not too hard to implement.

I think the choice finally boils down to what makes more sense w.r.t
representing the HW correctly. We'd need Rob's comment on that.

Thanks,
Archit



So I guess my proposal would be to have one port for inputs

Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Archit Taneja]

On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:

Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:

On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:

Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:

Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.

Signed-off-by: Archit Taneja 


Looks like a great solution for that problem, so
Reviewed-by: Heiko Stuebner 

As I'm looking into that for my rk3399-scarlet device right now and
couldn't find this patchset in the kernel yet, is it planned to
merge or refresh these binding changes or were problems encountered.

At least an Ack/Review from Rob seems to be missing.


I forgot about these patches. Rob had reviewed the first one in
the set the second one still needed an Ack. I'll post a v3
that adds the Reviewed-bys and fixes a small typo.


very nice ... because it looks like yesterday I managed to make the Rockchip
dsi work in dual mode following this.

But one question came up, do you really want two input ports on the panel
side? I.e. hardware-wise, I guess the panel will have one 8-lane or so input
thatonly gets split up on the soc side onto 2 dsi controllers?


I think all dual DSI panels actually have 2 DSI controllers/parsers
within them, one on each port. The MIPI DSI spec doesn't support 8
lanes. Also, the pixels coming out of the host are distributed among
the lanes differently than what would have been the case with a
'theoretical' 8 lane receiver.

Other than that, some dual DSI panels only accept DSI commands on the
'master' port, where as others expect the same command to be sent across
both the ports.

Therefore, I think it's better to represent dual DSI panels having 2
DSI input ports.

Your DT looks good to me.

Thanks,
Archit



So right now I'm operating with a devicetree like

_dsi {
 status = "okay";
 clock-master;

 ports {
 mipi_out: port@1 {
 reg = <1>;

 mipi_out_panel: endpoint {
 remote-endpoint = <_in_panel>;
 };
 };
 };

 mipi_panel: panel@0 {
  compatible = "innolux,p097pfg";
 reg = <0>;
 backlight = <>;
 enable-gpios = < 25 GPIO_ACTIVE_HIGH>;
 pinctrl-names = "default";
 pinctrl-0 = <_rst_l>;

 port {
 #address-cells = <1>;
 #size-cells = <0>;

 mipi_in_panel: endpoint@0 {
 reg = <0>;
 remote-endpoint = <_out_panel>;
 };

 mipi1_in_panel: endpoint@1 {
 reg = <1>;
 remote-endpoint = <_out_panel>;
 };
 };
 };
};

_dsi1 {
 status = "okay";

 ports {
 mipi1_out: port@1 {
 reg = <1>;

 mipi1_out_panel: endpoint {
 remote-endpoint = <_in_panel>;
 };
 };
 };
};


I guess it is a matter of preference on what reflects the hardware
best, so maybe that's Robs call?


Heiko


---
v2:
- Specify that clock-master is a boolean property.
- Drop/add unit-address and #*-cells where applicable.

   .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80
   ++ 1 file changed, 80 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index
94fb72cb916f..7a3abbedb3fa 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt

@@ -29,6 +29,13 @@ Required properties:
   - #size-cells: Should be 0. There are cases where it makes sense to use
   a
   
 different value here. See below.


+Optional properties:
+- clock-master: boolean. Should be enabled if the host is being used in
+  conjunction with another DSI host to drive the same peripheral.
Hardware
+  supporting such a configuration generally requires the data on both
the busses +  to be driven by the same clock. Only the DSI host instance
controlling this +  clock should contain this property.
+

   DSI peripheral
   ==

@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI
bus (mostly for the data>>
   path). Connections between su

Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Archit Taneja]

On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:

Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:

Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.

Signed-off-by: Archit Taneja 


Looks like a great solution for that problem, so
Reviewed-by: Heiko Stuebner 

As I'm looking into that for my rk3399-scarlet device right now and
couldn't find this patchset in the kernel yet, is it planned to
merge or refresh these binding changes or were problems encountered.

At least an Ack/Review from Rob seems to be missing.



I forgot about these patches. Rob had reviewed the first one in
the set the second one still needed an Ack. I'll post a v3
that adds the Reviewed-bys and fixes a small typo.

Archit



Heiko


---
v2:
- Specify that clock-master is a boolean property.
- Drop/add unit-address and #*-cells where applicable.

  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80 ++
  1 file changed, 80 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 94fb72cb916f..7a3abbedb3fa 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,13 @@ Required properties:
  - #size-cells: Should be 0. There are cases where it makes sense to use a
different value here. See below.
  
+Optional properties:

+- clock-master: boolean. Should be enabled if the host is being used in
+  conjunction with another DSI host to drive the same peripheral. Hardware
+  supporting such a configuration generally requires the data on both the 
busses
+  to be driven by the same clock. Only the DSI host instance controlling this
+  clock should contain this property.
+
  DSI peripheral
  ==
  
@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus (mostly for the data

  path). Connections between such peripherals and a DSI host can be represented
  using the graph bindings [1], [2].
  
+Peripherals that support dual channel DSI

+-
+
+Peripherals with higher bandwidth requirements can be connected to 2 DSI
+busses. Each DSI bus/channel drives some portion of the pixel data (generally
+left/right half of each line of the display, or even/odd lines of the display).
+The graph bindings should be used to represent the multiple DSI busses that are
+connected to this peripheral. Each DSI host's output endpoint can be linked to
+an input endpoint of the DSI peripheral.
+
  [1] Documentation/devicetree/bindings/graph.txt
  [2] Documentation/devicetree/bindings/media/video-interfaces.txt
  
@@ -71,6 +88,8 @@ Examples

with different virtual channel configurations.
  - (4) is an example of a peripheral on a I2C control bus connected with to
a DSI host using of-graph bindings.
+- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
+  which uses I2C as its primary control bus.
  
  1)

dsi-host {
@@ -153,3 +172,64 @@ Examples
};
};
};
+
+5)
+   i2c-host {
+   dsi-bridge@35 {
+   compatible = "...";
+   reg = <0x35>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi0_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi1_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+   };
+
+   dsi0-host {
+   ...
+
+   /*
+* this DSI instance drives the clock for both the host
+* controllers
+*/
+   clock-master;
+
+   ports {
+   ...
+
+   port {
+   dsi0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   dsi1-host {
+   ...
+
+   ports {
+   ...
+
+  

Re: [PATCH v2 08/10] drm/bridge: tc358764: Add DSI to LVDS bridge driver

[Archit Taneja]

ct drm_bridge *bridge)
+{
+   struct tc358764 *ctx = bridge_to_tc358764(bridge);
+   int ret;
+
+   drm_panel_prepare(ctx->panel);
+
+   ret = drm_panel_enable(ctx->panel);
+   if (ret < 0)
+   pr_err("panel enable failed\n");
+
+   msleep(40);
+}
+
+static int tc358764_attach(struct drm_bridge *bridge)
+{
+   struct tc358764 *ctx = bridge_to_tc358764(bridge);
+   struct drm_device *drm = bridge->dev;
+   int ret;
+
+   if (!bridge->encoder) {
+   DRM_ERROR("Encoder not found\n");
+   return -ENODEV;
+   }
+
+   ctx->connector.polled = DRM_CONNECTOR_POLL_HPD;
+   ret = drm_connector_init(drm, >connector,
+_connector_funcs,
+DRM_MODE_CONNECTOR_LVDS);
+   if (ret) {
+   DRM_ERROR("Failed to initialize connector\n");
+   return ret;
+   }
+
+   drm_connector_helper_add(>connector,
+_connector_helper_funcs);
+
+   drm_mode_connector_attach_encoder(>connector, bridge->encoder);
+
+   if (ctx->panel)
+   drm_panel_attach(ctx->panel, >connector);
+
+   drm_atomic_helper_connector_reset(>connector);
+   drm_connector_register(>connector);
+
+   return 0;
+}
+
+static const struct drm_bridge_funcs tc358764_bridge_funcs = {
+   .disable = tc358764_disable,
+   .enable = tc358764_enable,
+   .pre_enable = tc358764_pre_enable,
+   .attach = tc358764_attach,
+};
+
+static struct device_node *tc358764_of_find_panel_node(struct device *dev)
+{
+   struct device_node *np, *ep;
+
+   ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, 0);
+   if (!ep) {
+   pr_err("faile to get endpoint\n");
+   return NULL;
+   }
+
+   np = of_graph_get_remote_port_parent(ep);
+
+   return np;
+}
+
+static int tc358764_parse_dt(struct tc358764 *ctx)
+{
+   struct device *dev = ctx->dev;
+   struct device_node *np = dev->of_node;
+   struct device_node *lvds;
+
+   ctx->gpio_reset = devm_gpiod_get_from_of_node(dev, np, "reset", 0,
+ GPIOD_OUT_LOW,
+ "tc358764-reset");
+   if (IS_ERR(ctx->gpio_reset)) {
+   dev_err(dev, "no reset GPIO pin provided\n");
+   return PTR_ERR(ctx->gpio_reset);
+   }
+
+   lvds = tc358764_of_find_panel_node(ctx->dev);
+   if (!lvds) {
+   dev_err(dev, "cannot find panel node\n");
+   return -EINVAL;
+   }
+
+   ctx->panel = of_drm_find_panel(lvds);
+   if (!ctx->panel) {
+   dev_err(dev, "panel not registered\n");
+   return -EPROBE_DEFER;
+   }
+
+   return 0;
+}
+
+static int tc358764_configure_regulators(struct tc358764 *ctx)
+{
+   int i, ret;
+
+   for (i = 0; i < ARRAY_SIZE(ctx->supplies); ++i)
+   ctx->supplies[i].supply = tc358764_supplies[i];
+
+   ret = devm_regulator_bulk_get(ctx->dev, ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+   if (ret < 0)
+   dev_err(ctx->dev, "failed to get regulators: %d\n", ret);
+
+   return ret;
+}
+
+static int tc358764_probe(struct mipi_dsi_device *dsi)
+{
+   struct device *dev = >dev;
+   struct tc358764 *ctx;
+   int ret;
+
+   ctx = devm_kzalloc(dev, sizeof(struct tc358764), GFP_KERNEL);
+   if (!ctx)
+   return -ENOMEM;
+
+   mipi_dsi_set_drvdata(dsi, ctx);
+
+   ctx->dev = dev;
+
+   dsi->lanes = 4;
+   dsi->format = MIPI_DSI_FMT_RGB888;
+   dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST
+   | MIPI_DSI_MODE_VIDEO_AUTO_VERT;


if you use the mipi_dsi_device_transfer() helper, I guess you'd need to
add the LPM flag here.

Looks good to me otherwise. Once the DT port issue is concluded:

Reviewed-by: Archit Taneja 


+
+   ret = tc358764_parse_dt(ctx);
+   if (ret < 0)
+   return ret;
+
+   ret = tc358764_configure_regulators(ctx);
+   if (ret < 0)
+   return ret;
+
+   ctx->bridge.funcs = _bridge_funcs;
+   ctx->bridge.of_node = dev->of_node;
+
+   drm_bridge_add(>bridge);
+
+   ret = mipi_dsi_attach(dsi);
+   if (ret < 0) {
+   drm_bridge_remove(>bridge);
+   dev_err(dev, "failed to attach dsi\n");
+   }
+
+   return ret;
+}
+
+static int tc358764_remove(struct mipi_dsi_device *dsi)
+{
+   struct tc358764 *ctx = mipi_dsi_get_drvdata(dsi);
+
+   tc358764_poweroff(ctx);
+
+   mipi_dsi_detach(dsi);
+   drm_bridge_remove(>bridge);
+

Re: [PATCH] drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense

[Archit Taneja]

On Wednesday 30 May 2018 03:13 PM, Neil Armstrong wrote:

The dw_hdmi_setup_rx_sense exported function should not use struct device
to recover the dw-hdmi context using drvdata, but take struct dw_hdmi
directly like other exported functions.

This caused a regression using Meson DRM on S905X since v4.17-rc1 :


Reviewed-by: Archit Taneja 



Internal error: Oops: 9607 [#1] PREEMPT SMP
[...]
CPU: 0 PID: 124 Comm: irq/32-dw_hdmi_ Not tainted 4.17.0-rc7 #2
Hardware name: Libre Technology CC (DT)
[...]
pc : osq_lock+0x54/0x188
lr : __mutex_lock.isra.0+0x74/0x530
[...]
Process irq/32-dw_hdmi_ (pid: 124, stack limit = 0xadf418cb)
Call trace:
   osq_lock+0x54/0x188
   __mutex_lock_slowpath+0x10/0x18
   mutex_lock+0x30/0x38
   __dw_hdmi_setup_rx_sense+0x28/0x98
   dw_hdmi_setup_rx_sense+0x10/0x18
   dw_hdmi_top_thread_irq+0x2c/0x50
   irq_thread_fn+0x28/0x68
   irq_thread+0x10c/0x1a0
   kthread+0x128/0x130
   ret_from_fork+0x10/0x18
  Code: 34000964 d00050a2 51000484 9135c042 (f864d844)
  ---[ end trace 945641e1fbbc07da ]---
  note: irq/32-dw_hdmi_[124] exited with preempt_count 1
  genirq: exiting task "irq/32-dw_hdmi_" (124) is an active IRQ thread (irq 32)

Fixes: eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
Signed-off-by: Neil Armstrong 
Tested-by: Koen Kooi 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 ---
  drivers/gpu/drm/meson/meson_dw_hdmi.c |  2 +-
  include/drm/bridge/dw_hdmi.h  |  2 +-
  3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ec8d000..3c136f2b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2077,7 +2077,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
  }
  
-void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)

+void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
  {
mutex_lock(>mutex);
  
@@ -2103,13 +2103,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)

}
mutex_unlock(>mutex);
  }
-
-void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
-{
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
-   __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
-}
  EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
  
  static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)

@@ -2145,9 +2138,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
 */
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
-   __dw_hdmi_setup_rx_sense(hdmi,
-phy_stat & HDMI_PHY_HPD,
-phy_stat & HDMI_PHY_RX_SENSE);
+   dw_hdmi_setup_rx_sense(hdmi,
+  phy_stat & HDMI_PHY_HPD,
+  phy_stat & HDMI_PHY_RX_SENSE);
  
  		if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)

cec_notifier_set_phys_addr(hdmi->cec_notifier,
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index a393095..c9ad456 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -529,7 +529,7 @@ static irqreturn_t dw_hdmi_top_thread_irq(int irq, void 
*dev_id)
if (stat & HDMITX_TOP_INTR_HPD_RISE)
hpd_connected = true;
  
-		dw_hdmi_setup_rx_sense(dw_hdmi->dev, hpd_connected,

+   dw_hdmi_setup_rx_sense(dw_hdmi->hdmi, hpd_connected,
   hpd_connected);
  
  		drm_helper_hpd_irq_event(dw_hdmi->encoder.dev);

diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index dd2a8cf..ccb5aa8 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -151,7 +151,7 @@ struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
 struct drm_encoder *encoder,
 const struct dw_hdmi_plat_data *plat_data);
  
-void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);

+void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense);
  
  void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);

  void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: adv7511: fix spelling of driver name in Kconfig

[Archit Taneja]

On Friday 27 April 2018 03:11 AM, Laurent Pinchart wrote:

Hi Peter,

Thank you for the patch.

On Friday, 27 April 2018 00:36:44 EEST Peter Rosin wrote:

Could perhaps prevent some confusion.


queued to drm-misc-next

Thanks,
Archit



Signed-off-by: Peter Rosin 


Reviewed-by: Laurent Pinchart 


---
  drivers/gpu/drm/bridge/adv7511/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
b/drivers/gpu/drm/bridge/adv7511/Kconfig index 592b9d2ec034..944e440c4fde
100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -1,5 +1,5 @@
  config DRM_I2C_ADV7511
-   tristate "AV7511 encoder"
+   tristate "ADV7511 encoder"
depends on OF
select DRM_KMS_HELPER
select REGMAP_I2C




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: drm: bridge: adv7511: Replace mdelay with usleep_range in adv7511_probe

[Archit Taneja]

On Friday 27 April 2018 03:46 AM, Laurent Pinchart wrote:

Hi Jia-Ju,

Thank you for the patch.

On Wednesday, 11 April 2018 11:33:42 EEST Jia-Ju Bai wrote:

adv7511_probe() is never called in atomic context.
This function is only set as ".probe" in struct i2c_driver.

Despite never getting called from atomic context, adv7511_probe()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.


Nice work ! Is the tool open-source ?


Signed-off-by: Jia-Ju Bai 
---
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index b2431ae..2cf7fa1
100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1054,7 +1054,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id) }

if (adv7511->gpio_pd) {
-   mdelay(5);
+   usleep_range(5000, 6000);
gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
}


The patch looks good to me.

Reviewed-by: Laurent Pinchart 


queued to drm-misc-next

Thanks,
Archit

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/5] dt-bindings: adv7511: Extend bindings to allow specifying slave map addresses

[Archit Taneja]

On Tuesday 13 February 2018 11:18 PM, Kieran Bingham wrote:

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.

Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.



Queued to drm-misc-next


Signed-off-by: Kieran Bingham 
Reviewed-by: Rob Herring 
Reviewed-by: Laurent Pinchart 
---
v2:
  - Fixed up reg: property description to account for multiple optional
addresses.
  - Minor reword to commit message to account for DT only change
  - Collected Robs RB tag

v3:
  - Split map register addresses into individual declarations.

v4:
  - Update commit title
  - Collect Laurent's RB tag
  - Fix nitpickings
  - Normalise I2C usage (I²C is harder to grep for)

  .../devicetree/bindings/display/bridge/adi,adv7511.txt | 18 --
  1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 0047b1394c70..2c887536258c 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -14,7 +14,13 @@ Required properties:
"adi,adv7513"
"adi,adv7533"
  
-- reg: I2C slave address

+- reg: I2C slave addresses
+  The ADV7511 internal registers are split into four pages exposed through
+  different I2C addresses, creating four register maps. Each map has it own
+  I2C address and acts as a standard slave device on the I2C bus. The main
+  address is mandatory, others are optional and revert to defaults if not
+  specified.
+
  
  The ADV7511 supports a large number of input data formats that differ by their

  color depth, color format, clock mode, bit justification and random
@@ -70,6 +76,9 @@ Optional properties:
rather than generate its own timings for HDMI output.
  - clocks: from common clock binding: reference to the CEC clock.
  - clock-names: from common clock binding: must be "cec".
+- reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are : "main", "edid", "cec", "packet"
  
  Required nodes:
  
@@ -88,7 +97,12 @@ Example
  
  	adv7511w: hdmi@39 {

compatible = "adi,adv7511w";
-   reg = <39>;
+   /*
+* The EDID page will be accessible on address 0x66 on the I2C
+* bus. All other maps continue to use their default addresses.
+*/
+   reg = <0x39>, <0x66>;
+   reg-names = "main", "edid";
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <_clock>;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/5] drm: adv7511: Add support for i2c_new_secondary_device

[Archit Taneja]

On Tuesday 13 February 2018 11:18 PM, Kieran Bingham wrote:

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.


Queued to drm-misc-next



Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
---
v2:
  - Update missing edid-i2c address setting
  - Split out DT bindings
  - Rename and move the I2C default addresses to their own section

v3:
  - No change

v4:
  - Change registration order of packet/cec to fix error path and
simplify code change.
  - Collect Laurent's RB tag

  drivers/gpu/drm/bridge/adv7511/adv7511.h |  6 
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 42 ++--
  2 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index d034b2cb5eee..73d8ccb97742 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -93,6 +93,11 @@
  #define ADV7511_REG_CHIP_ID_HIGH  0xf5
  #define ADV7511_REG_CHIP_ID_LOW   0xf6
  
+/* Hardware defined default addresses for I2C register maps */

+#define ADV7511_CEC_I2C_ADDR_DEFAULT   0x3c
+#define ADV7511_EDID_I2C_ADDR_DEFAULT  0x3f
+#define ADV7511_PACKET_I2C_ADDR_DEFAULT0x38
+
  #define ADV7511_CSC_ENABLEBIT(7)
  #define ADV7511_CSC_UPDATE_MODE   BIT(5)
  
@@ -321,6 +326,7 @@ enum adv7511_type {

  struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
+   struct i2c_client *i2c_packet;
struct i2c_client *i2c_cec;
  
  	struct regmap *regmap;

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index efa29db5fc2b..802bc433f54a 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -586,7 +586,7 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
/* Reading the EDID only works if the device is powered */
if (!adv7511->powered) {
unsigned int edid_i2c_addr =
-   (adv7511->i2c_main->addr << 1) + 4;
+   (adv7511->i2c_edid->addr << 1);
  
  		__adv7511_power_on(adv7511);
  
@@ -969,10 +969,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)

  {
int ret;
  
-	adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,

-adv->i2c_main->addr - 1);
+   adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
+   ADV7511_CEC_I2C_ADDR_DEFAULT);
if (!adv->i2c_cec)
-   return -ENOMEM;
+   return -EINVAL;
i2c_set_clientdata(adv->i2c_cec, adv);
  
  	adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,

@@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
struct adv7511_link_config link_config;
struct adv7511 *adv7511;
struct device *dev = >dev;
-   unsigned int main_i2c_addr = i2c->addr << 1;
-   unsigned int edid_i2c_addr = main_i2c_addr + 4;
unsigned int val;
int ret;
  
@@ -1153,23 +1151,34 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id)

if (ret)
goto uninit_regulators;
  
-	regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);

-   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
-main_i2c_addr - 0xa);
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
-main_i2c_addr - 2);
-
adv7511_packet_disable(adv7511, 0x);
  
-	adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);

+   adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
+   ADV7511_EDID_I2C_ADDR_DEFAULT);
if (!adv7511->i2c_edid) {
-   ret = -ENOMEM;
+   ret = -EINVAL;
goto uninit_regulators;
}
  
+	regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,

+adv7511->i2c_edid->addr << 1);
+
+   adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
+   ADV7511_PACKET_I2C_ADDR_DEFAULT);
+   if (!adv7511->i2c_packet) {
+   ret = -EINVAL;
+   goto err_i2c_unregister_edid;
+   }
+
+   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
+   

Re: [PATCH v6 1/2] drm/bridge: Add Cadence DSI driver

[Archit Taneja]

On Saturday 21 April 2018 11:50 AM, Boris Brezillon wrote:

Hi Archit,

On Sun, 15 Apr 2018 13:39:44 +0530
Archit Taneja <arch...@codeaurora.org> wrote:


+static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
+struct cdns_dphy_cfg *cfg,
+unsigned int dpi_htotal,
+unsigned int dpi_bpp,
+unsigned int dpi_hz,
+unsigned int dsi_htotal,
+unsigned int dsi_nlanes,
+unsigned int *dsi_hfp_ext)
+{
+   u64 dlane_bps, dlane_bps_max, fbdiv, fbdiv_max, adj_dsi_htotal;
+   unsigned long pll_ref_hz = clk_get_rate(dphy->pll_ref_clk);
+
+   memset(cfg, 0, sizeof(*cfg));
+
+   cfg->nlanes = dsi_nlanes;
+
+   if (pll_ref_hz < 960 || pll_ref_hz >= 15000)
+   return -EINVAL;
+   else if (pll_ref_hz < 1920)
+   cfg->pll_ipdiv = 1;
+   else if (pll_ref_hz < 3840)
+   cfg->pll_ipdiv = 2;
+   else if (pll_ref_hz < 7680)
+   cfg->pll_ipdiv = 4;
+   else
+   cfg->pll_ipdiv = 8;
+
+   /*
+* Make sure DSI htotal is aligned on a lane boundary when calculating
+* the expected data rate. This is done by extending HFP in case of
+* misalignment.
+*/
+   adj_dsi_htotal = dsi_htotal;
+   if (dsi_htotal % dsi_nlanes)
+   adj_dsi_htotal += dsi_nlanes - (dsi_htotal % dsi_nlanes);
+
+   dlane_bps = (u64)dpi_hz * adj_dsi_htotal;
+
+   /* data rate in bytes/sec is not an integer, refuse the mode. */
+   if (do_div(dlane_bps, dsi_nlanes * dpi_htotal))
+   return -EINVAL;
+
+   /* data rate was in bytes/sec, convert to bits/sec. */
+   dlane_bps *= 8;
+
+   if (dlane_bps > 25UL || dlane_bps < 16000UL)
+   return -EINVAL;
+   else if (dlane_bps >= 125000)
+   cfg->pll_opdiv = 1;
+   else if (dlane_bps >= 63000)
+   cfg->pll_opdiv = 2;
+   else if (dlane_bps >= 32000)
+   cfg->pll_opdiv = 4;
+   else if (dlane_bps >= 16000)
+   cfg->pll_opdiv = 8;
+
+   /*
+* Allow a deviation of 0.2% on the per-lane data rate to try to
+* recover a potential mismatch between DPI and PPI clks.
+*/
+   dlane_bps_max = dlane_bps + (dlane_bps / 500);


kbuild reported an error for 32 bit archs. I'm guessing it's because of
this divide above?


Yep, DIV_ROUND_UP_ULL() should fix the problem.





+
+   fbdiv_max = DIV_ROUND_DOWN_ULL((dlane_bps + (dlane_bps / 500)) * 2 *


You could use dlane_bps_max here instead.


Sure.



Otherwise,

Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Thanks for the review.

Does that mean I'm allowed to apply the patch to drm-misc-next myself
after fixing the div64 issue?


Sure, please go ahead.

Archit



Regards,

Boris


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v2 1/2] drm/panel: Add Truly NT35597 panel

[Archit Taneja]

Hi,

On Saturday 14 April 2018 12:55 PM, Abhinav Kumar wrote:

From: Archit Taneja <arch...@codeaurora.org>


You can drop DPU from the subject. Also, you'd need to add
Theirry Reading for panel related patches, and Rob Herring
for an Ack on the DT bindings.

I think you can change the author to yourself. You've had to
make plenty of changes to get this in upstream state. You
can keep my Signed-off-by, though.



Add support for Truly NT35597 panel used
in MSM reference platforms.


You can mention here that the panel supports both single
and dual DSI modes, and that we support only dual-DSI
mode for now.



Changes in v2:
- Renamed panel to truly,nt35597
- Added SPDX license
- Used endpoints instead of custom node
- Renamed and cleaned up power supplies

Signed-off-by: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhin...@codeaurora.org>
---
  .../devicetree/bindings/display/truly,nt35597.txt  |  47 ++
  drivers/gpu/drm/panel/Kconfig  |   7 +
  drivers/gpu/drm/panel/Makefile |   1 +
  drivers/gpu/drm/panel/panel-truly-nt35597.c| 597 +
  4 files changed, 652 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/display/truly,nt35597.txt
  create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c

diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt 
b/Documentation/devicetree/bindings/display/truly,nt35597.txt
new file mode 100644
index 000..22b6f19
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
@@ -0,0 +1,47 @@
+Truly model NT35597 1440x2560 DSI Panel
+
+Required properties:
+- compatible: should be "truly,nt35597"
+- vdda-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply
+- vdispp-supply: phandle of the regulator that provides the supply voltage
+  for positive LCD bias
+- vdispn-supply: phandle of the regulator that provides the supply voltage
+  for negative LCD bias
+- reset-gpios: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
+- mode-gpios: phandle of the gpio for choosing the mode of the display
+  for single DSI or Dual DSI
+  This should be low for dual DSI and high for single DSI mode
+- display-timings: Node for the Panel timings
+


You need to specify the of-graph bindings here. Especially, what port #
corresponds to master DSI, and what # for slave DSI.


+Example:
+
+   dsi@ae94000 {
+   panel@0 {
+   compatible = "truly,nt35597";
+   reg = <0>;
+   vdda-supply = <_l14>;
+   vdispp-supply = <_regulator>;
+   vdispn-supply = <_regulator>;
+   pinctrl-names = "default", "suspend";
+   pinctrl-0 = <_dsi_active>;
+   pinctrl-1 = <_dsi_suspend>;
+
+   reset-gpios = < 6 0>;
+   mode-gpios = < 52 0>;
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <268316138>;
+   hactive = <1440>;
+   vactie = <2560>;
+   hfront-porch = <200>;
+   hback-porch = <64>;
+   hsync-len = <32>;
+   vfront-porch = <8>;
+   vback-porch = <7>;
+   vsync-len = <1>;
+   };
+   };
+   };


The example should specify the port too.


+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 988048e..9f0c490 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -168,4 +168,11 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
  
+config DRM_PANEL_TRULY_NT35597_WQXGA

+   tristate "Truly WQXGA"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Truly NT35597 WQXGA Dual 
DSI
+ Video Mode panel
  endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3d2a88d..b5b4b60 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043

Re: [DPU PATCH v3 2/2] drm/msm/dsi: Use one connector for dual DSI mode

[Archit Taneja]

On Thursday 19 April 2018 01:15 AM, Chandan Uddaraju wrote:

Current DSI driver uses two connectors for dual DSI case even
though we only have one panel. Fix this by implementing one
connector/bridge for dual DSI use case. Use master DSI
controllers to register one connector/bridge.

Changes in V2:
 -Removed Change-Id from the commit text tags.
 -Remove extra parentheses

Changes in V3:
 -None


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Signed-off-by: Chandan Uddaraju <chand...@codeaurora.org>
---
  drivers/gpu/drm/msm/dsi/dsi.c |   3 +
  drivers/gpu/drm/msm/dsi/dsi.h |   1 +
  drivers/gpu/drm/msm/dsi/dsi_manager.c | 110 --
  3 files changed, 29 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index b744bcc..ff8164c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,6 +208,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
goto fail;
}
  
+	if (!msm_dsi_manager_validate_current_config(msm_dsi->id))

+   goto fail;
+
msm_dsi->encoder = encoder;
  
  	msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 01c38f6..c858e8e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -100,6 +100,7 @@ struct msm_dsi {
  void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
  int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
  void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
+bool msm_dsi_manager_validate_current_config(u8 id);
  
  /* msm dsi */

  static inline bool msm_dsi_device_connected(struct msm_dsi *msm_dsi)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3bb506b..2a11f82 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -306,67 +306,6 @@ static void dsi_mgr_connector_destroy(struct drm_connector 
*connector)
kfree(dsi_connector);
  }
  
-static void dsi_dual_connector_fix_modes(struct drm_connector *connector)

-{
-   struct drm_display_mode *mode, *m;
-
-   /* Only support left-right mode */
-   list_for_each_entry_safe(mode, m, >probed_modes, head) {
-   mode->clock >>= 1;
-   mode->hdisplay >>= 1;
-   mode->hsync_start >>= 1;
-   mode->hsync_end >>= 1;
-   mode->htotal >>= 1;
-   drm_mode_set_name(mode);
-   }
-}
-
-static int dsi_dual_connector_tile_init(
-   struct drm_connector *connector, int id)
-{
-   struct drm_display_mode *mode;
-   /* Fake topology id */
-   char topo_id[8] = {'M', 'S', 'M', 'D', 'U', 'D', 'S', 'I'};
-
-   if (connector->tile_group) {
-   DBG("Tile property has been initialized");
-   return 0;
-   }
-
-   /* Use the first mode only for now */
-   mode = list_first_entry(>probed_modes,
-   struct drm_display_mode,
-   head);
-   if (!mode)
-   return -EINVAL;
-
-   connector->tile_group = drm_mode_get_tile_group(
-   connector->dev, topo_id);
-   if (!connector->tile_group)
-   connector->tile_group = drm_mode_create_tile_group(
-   connector->dev, topo_id);
-   if (!connector->tile_group) {
-   pr_err("%s: failed to create tile group\n", __func__);
-   return -ENOMEM;
-   }
-
-   connector->has_tile = true;
-   connector->tile_is_single_monitor = true;
-
-   /* mode has been fixed */
-   connector->tile_h_size = mode->hdisplay;
-   connector->tile_v_size = mode->vdisplay;
-
-   /* Only support left-right mode */
-   connector->num_h_tile = 2;
-   connector->num_v_tile = 1;
-
-   connector->tile_v_loc = 0;
-   connector->tile_h_loc = (id == DSI_RIGHT) ? 1 : 0;
-
-   return 0;
-}
-
  static int dsi_mgr_connector_get_modes(struct drm_connector *connector)
  {
int id = dsi_mgr_connector_get_id(connector);
@@ -377,31 +316,15 @@ static int dsi_mgr_connector_get_modes(struct 
drm_connector *connector)
if (!panel)
return 0;
  
-	/* Since we have 2 connectors, but only 1 drm_panel in dual DSI mode,

-* panel should not attach to any connector.
-* Only temporarily attach panel to the current connector here,
-* to let panel set mode to this connector.
+   /*
+* In dual DSI mode, we have one connector that can be
+* attached to the drm_panel.
 */
drm_panel_attach(panel, conne

Re: [DPU PATCH v3 1/2] drm/msm/dsi: adjust dsi timing for dual dsi mode

[Archit Taneja]

On Thursday 19 April 2018 01:15 AM, Chandan Uddaraju wrote:

For dual dsi mode, the horizontal timing needs
to be divided by half since both the dsi controllers
will be driving this panel. Adjust the pixel clock and
DSI timing accordingly.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Changes in V2:
--Removed Change-Id from the commit text tags.

Changes in V3:
--Instead of adjusting the DRM mode structure, divide
   the clocks and horizontal timings in DSI host just
   before configuring the values.

Signed-off-by: Chandan Uddaraju <chand...@codeaurora.org>
---
  drivers/gpu/drm/msm/dsi/dsi.h |  6 ++--
  drivers/gpu/drm/msm/dsi/dsi_host.c| 55 ---
  drivers/gpu/drm/msm/dsi/dsi_manager.c |  7 +++--
  3 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a..01c38f6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -162,7 +162,8 @@ void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host 
*host,
  int msm_dsi_host_enable(struct mipi_dsi_host *host);
  int msm_dsi_host_disable(struct mipi_dsi_host *host);
  int msm_dsi_host_power_on(struct mipi_dsi_host *host,
-   struct msm_dsi_phy_shared_timings *phy_shared_timings);
+   struct msm_dsi_phy_shared_timings *phy_shared_timings,
+   bool is_dual_dsi);
  int msm_dsi_host_power_off(struct mipi_dsi_host *host);
  int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
struct drm_display_mode *mode);
@@ -175,7 +176,8 @@ int msm_dsi_host_set_src_pll(struct mipi_dsi_host *host,
struct msm_dsi_pll *src_pll);
  void msm_dsi_host_reset_phy(struct mipi_dsi_host *host);
  void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host *host,
-   struct msm_dsi_phy_clk_request *clk_req);
+   struct msm_dsi_phy_clk_request *clk_req,
+   bool is_dual_dsi);
  void msm_dsi_host_destroy(struct mipi_dsi_host *host);
  int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7a03a94..75d527e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -118,6 +118,7 @@ struct msm_dsi_host {
struct clk *byte_intf_clk;
  
  	u32 byte_clk_rate;

+   u32 pixel_clk_rate;
u32 esc_clk_rate;
  
  	/* DSI v2 specific clocks */

@@ -510,7 +511,7 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
*msm_host)
goto error;
}
  
-	ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);

+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
goto error;
@@ -591,7 +592,7 @@ static int dsi_link_clk_enable_v2(struct msm_dsi_host 
*msm_host)
goto error;
}
  
-	ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);

+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
goto error;
@@ -661,7 +662,7 @@ static void dsi_link_clk_disable(struct msm_dsi_host 
*msm_host)
}
  }
  
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)

+static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host, bool is_dual_dsi)
  {
struct drm_display_mode *mode = msm_host->mode;
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
@@ -675,14 +676,28 @@ static int dsi_calc_clk_rate(struct msm_dsi_host 
*msm_host)
}
  
  	pclk_rate = mode->clock * 1000;

+
+   /*
+* For dual DSI mode, the current DRM mode has
+* the complete width of the panel. Since, the complete
+* panel is driven by two DSI controllers, the
+* the clock rates have to be split between
+* the two dsi controllers. Adjust the byte and
+* pixel clock rates for each dsi host accordingly.
+*/
+   if (is_dual_dsi)
+   pclk_rate /= 2;
+
if (lanes > 0) {
msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
} else {
pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
msm_host->byte_clk_rate = (pclk_rate * bpp) / 8;
}
+   msm_host->pixel_clk_rate = pclk_rate;
  
-	DBG("pclk=%d, bclk=%d", pclk_rate, msm_host->byte_clk_rate);

+   DBG("pclk=%d, bclk=%d", msm_host->pixel_clk_rate,
+   msm_host->byte_clk_rate);
  
  	msm_host->esc_clk_rate = c

Re: [PATCH] drm: clarify adjusted_mode documentation for bridges

[Archit Taneja]

On Thursday 19 April 2018 09:20 PM, Philippe CORNU wrote:

Hi Archit & Andrzej,

May I ask you please a short review of this documentation update.
Many thanks
Philippe :-)

On 04/09/2018 05:24 PM, Philippe Cornu wrote:

This patch clarifies the adjusted_mode documentation
for bridges.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Signed-off-by: Philippe Cornu <philippe.co...@st.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
This patch follows discussions in:
- "drm: clarify adjusted_mode for a bridge connected to a crtc"
https://patchwork.freedesktop.org/patch/206801/
- "drm: bridge: Constify mode arguments to bridge .mode_set() operation"
https://patchwork.freedesktop.org/patch/215449/

   include/drm/drm_bridge.h | 16 
   include/drm/drm_crtc.h   | 11 +++
   2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7d632c6a9214 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -178,6 +178,22 @@ struct drm_bridge_funcs {
 * then this would be _encoder_helper_funcs.mode_set. The display
 * pipe (i.e.  clocks and timing signals) is off when this function is
 * called.
+*
+* The adjusted_mode parameter corresponds to the mode output by the 
CRTC
+* for the first bridge in the chain. It can be different from the mode
+* parameter that contains the desired mode for the connector at the end
+* of the bridges chain, for instance when the first bridge in the chain
+* performs scaling. The adjusted mode is mostly useful for the first
+* bridge in the chain and is likely irrelevant for the other bridges.
+*
+* For atomic drivers the adjusted_mode is the mode stored in
+* _crtc_state.adjusted_mode.
+*
+* NOTE:
+*
+* If a need arises to store and access modes adjusted for other 
locations
+* than the connection between the CRTC and the first bridge, the DRM
+* framework will have to be extended with DRM bridge states.
 */
void (*mode_set)(struct drm_bridge *bridge,
 struct drm_display_mode *mode,
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a2d81d2907a9..65f749a9e9d3 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -134,10 +134,13 @@ struct drm_crtc_state {
 *
 * Internal display timings which can be used by the driver to handle
 * differences between the mode requested by userspace in @mode and what
-* is actually programmed into the hardware. It is purely driver
-* implementation defined what exactly this adjusted mode means. Usually
-* it is used to store the hardware display timings used between the
-* CRTC and encoder blocks.
+* is actually programmed into the hardware.
+*
+* For drivers using drm_bridge, this stores the hardware display 
timings
+* used between the CRTC and the first bridge. For other drivers, the
+* meaning of the adjusted_mode field is purely driver implementation
+* defined information, and will usually be used to store the hardware
+* display timings used between the CRTC and encoder blocks.
 */
struct drm_display_mode adjusted_mode;
   

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU/DRM issue with DSI commands on msm 8916

[Archit Taneja]

On Wednesday 18 April 2018 01:58 PM, Daniel Mack wrote:

On Wednesday, April 18, 2018 10:06 AM, Archit Taneja wrote:

On Tuesday 17 April 2018 05:51 PM, Daniel Mack wrote:
Thanks for debugging this so thoroughly.


It shows an underlying problem in the msm driver's clock components
though, because without this patch, the clocks will be effectively
slightly off from what was requested. For instance, when
gcc_mdss_byte0_clk is configured to 5625 Hz by the msm drm driver,
the clk core will let the DSI PLL recalculate its actual rate which is
56246337 Hz. Hence, clk_set_rate() will always end up fiddling with the
knobs of that clock provider. That's what happens every time DSI
commands are sent, and that causes the image to flicker.


If I understood right, the main cause of the flicker is that we always
end up re-locking/reconfiguring the DSI PLL every time we send a command
(since dsi_link_clk_enable() is called in msm_dsi_host_xfer_prepare())?
The re-configuration results in a glitch on the DSI clock, which is
probably unacceptable for DSI Video mode transfer, especially for panels
that don't have their own timing generators, which rely entirely on
DSI clock lanes for scanning out the pixel data.

According to you, the reason why the reconfiguration happens is because
the DSI PLL was never set exactly to 56.25 Mhz in the first place, and
the core clock framework notices a difference in the requested rate and
the current rate (56.246 Mhz), and goes ahead to configure the PLL
again when it's not needed. And this was averted in the downstream
patch you mentioned as a side affect?


Yes, exactly.


The same problem applies to other clocks too. dsi0vco_clk for example
will be 449970703 rather than the requested 45000 etc.



One easy way to get around this would be to not try to set the clock
rates every time we try to send a command. We just enable/disable them.


Yes, that could work as well, but how about rounding the rates in the
callback that exists for that purpose? We're off by a fraction of a
permille only, after all.


Sorry, forgot to respond to that in your last mail. I wasn't fully
clear about how we'd do it.

Do you mean that we call clk_round_rate() on the byte and pixel
clocks in dsi_link_clk_enable_6g() after we set the rates?

Archit




Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU/DRM issue with DSI commands on msm 8916

[Archit Taneja]

Hi Daniel,

On Tuesday 17 April 2018 05:51 PM, Daniel Mack wrote:

(cc Stephen)

Hi Archit,

On Monday, April 16, 2018 07:06 PM, Daniel Mack wrote:

On Monday, April 09, 2018 03:08 PM, Archit Taneja wrote:

You could comment out the pm_runtime_put_sync() calls in
drivers/gpu/drm/msm/dsi/dsi_host.c, in case some registers got
reset during put_sync and weren't restored correctly after get_sync().


That was my first suspicion too, but unfortunately, that's not the culprit.
I think it would be good to comment out the put_sync() calls in

drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c and
drivers/gpu/drm/msm/msm_drv.c too, since there is a parent-child
hierarchy between DSI
and the top level MDSS block. Commenting out the put_syncs() just
in put_sync() might still result in the MDSS GDSC to switch off.


I spent some more time debugging this today and it turns out that
calling into dsi_link_clk_enable() from msm_dsi_host_xfer_prepare() is
already causing the drop-outs, even when no command buffers, DMA
transfers etc. are involved. I then drilled further down and it showed
that at least

   clk_set_rate(msm_host->byte_clk, msm_host->byte_clk_rate);

in dsi_link_clk_enable_6g() one of the culprits. If I don't touch the
clocks anymore after the initialization is done, everything is fine.


Okay, I finally found the bits between the two trees that make the
difference. It's a downstream patch that is included in the Linaro 4.9
branch but that's missing upstream and in their 4.14 branch:


https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/commit/?h=release/qcomlt-4.9=4ce2d6108d

What this patch does as a side-effect is that is sets the clock's actual
rate to the requested rate (core->rate = core->new_rate), and that fixes
the problem I'm seeing.



Thanks for debugging this so thoroughly.


It shows an underlying problem in the msm driver's clock components
though, because without this patch, the clocks will be effectively
slightly off from what was requested. For instance, when
gcc_mdss_byte0_clk is configured to 5625 Hz by the msm drm driver,
the clk core will let the DSI PLL recalculate its actual rate which is
56246337 Hz. Hence, clk_set_rate() will always end up fiddling with the
knobs of that clock provider. That's what happens every time DSI
commands are sent, and that causes the image to flicker.


If I understood right, the main cause of the flicker is that we always
end up re-locking/reconfiguring the DSI PLL every time we send a command
(since dsi_link_clk_enable() is called in msm_dsi_host_xfer_prepare())?
The re-configuration results in a glitch on the DSI clock, which is
probably unacceptable for DSI Video mode transfer, especially for panels
that don't have their own timing generators, which rely entirely on
DSI clock lanes for scanning out the pixel data.

According to you, the reason why the reconfiguration happens is because
the DSI PLL was never set exactly to 56.25 Mhz in the first place, and
the core clock framework notices a difference in the requested rate and 
the current rate (56.246 Mhz), and goes ahead to configure the PLL

again when it's not needed. And this was averted in the downstream
patch you mentioned as a side affect?




The same problem applies to other clocks too. dsi0vco_clk for example
will be 449970703 rather than the requested 45000 etc.



One easy way to get around this would be to not try to set the clock
rates every time we try to send a command. We just enable/disable them.
It would hide the real problem, though.


I guess a way to fix this properly would be to use
msm_dsi_pll_helper_clk_round_rate() to actually round the rates, but I'm
not sure.


Stephen,

Do you have any suggestions on how we can manage this? I.e we set a
clock rate, it goes through, but it's very slightly different than what
we asked for. The next time we try to set the same rate, the clock
provider driver goes through the whole ordeal of reconfiguring the
HW to reach to the same configuration.

Thanks,
Archit




Thanks,
Daniel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/2] drm/bridge: Add Cadence DSI driver

[Archit Taneja]

s_dphy *dphy,
+enum cdns_dphy_clk_lane_cfg cfg);
+   void (*set_pll_cfg)(struct cdns_dphy *dphy,
+   const struct cdns_dphy_cfg *cfg);
+   unsigned long (*get_wakeup_time_ns)(struct cdns_dphy *dphy);
+};
+
+struct cdns_dphy {
+   struct cdns_dphy_cfg cfg;
+   void __iomem *regs;
+   struct clk *psm_clk;
+   struct clk *pll_ref_clk;
+   const struct cdns_dphy_ops *ops;
+};
+
+struct cdns_dsi_input {
+   enum cdns_dsi_input_id id;
+   struct drm_bridge bridge;
+};
+
+struct cdns_dsi {
+   struct mipi_dsi_host base;
+   void __iomem *regs;
+   struct cdns_dsi_input input;
+   struct cdns_dsi_output output;
+   unsigned int direct_cmd_fifo_depth;
+   unsigned int rx_fifo_depth;
+   struct completion direct_cmd_comp;
+   struct clk *dsi_p_clk;
+   struct reset_control *dsi_p_rst;
+   struct clk *dsi_sys_clk;
+   bool link_initialized;
+   struct cdns_dphy *dphy;
+};
+
+static inline struct cdns_dsi *input_to_dsi(struct cdns_dsi_input *input)
+{
+   return container_of(input, struct cdns_dsi, input);
+}
+
+static inline struct cdns_dsi *to_cdns_dsi(struct mipi_dsi_host *host)
+{
+   return container_of(host, struct cdns_dsi, base);
+}
+
+static inline struct cdns_dsi_input *
+bridge_to_cdns_dsi_input(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct cdns_dsi_input, bridge);
+}
+
+static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
+struct cdns_dphy_cfg *cfg,
+unsigned int dpi_htotal,
+unsigned int dpi_bpp,
+unsigned int dpi_hz,
+unsigned int dsi_htotal,
+unsigned int dsi_nlanes,
+unsigned int *dsi_hfp_ext)
+{
+   u64 dlane_bps, dlane_bps_max, fbdiv, fbdiv_max, adj_dsi_htotal;
+   unsigned long pll_ref_hz = clk_get_rate(dphy->pll_ref_clk);
+
+   memset(cfg, 0, sizeof(*cfg));
+
+   cfg->nlanes = dsi_nlanes;
+
+   if (pll_ref_hz < 960 || pll_ref_hz >= 15000)
+   return -EINVAL;
+   else if (pll_ref_hz < 1920)
+   cfg->pll_ipdiv = 1;
+   else if (pll_ref_hz < 3840)
+   cfg->pll_ipdiv = 2;
+   else if (pll_ref_hz < 7680)
+   cfg->pll_ipdiv = 4;
+   else
+   cfg->pll_ipdiv = 8;
+
+   /*
+* Make sure DSI htotal is aligned on a lane boundary when calculating
+* the expected data rate. This is done by extending HFP in case of
+* misalignment.
+*/
+   adj_dsi_htotal = dsi_htotal;
+   if (dsi_htotal % dsi_nlanes)
+   adj_dsi_htotal += dsi_nlanes - (dsi_htotal % dsi_nlanes);
+
+   dlane_bps = (u64)dpi_hz * adj_dsi_htotal;
+
+   /* data rate in bytes/sec is not an integer, refuse the mode. */
+   if (do_div(dlane_bps, dsi_nlanes * dpi_htotal))
+   return -EINVAL;
+
+   /* data rate was in bytes/sec, convert to bits/sec. */
+   dlane_bps *= 8;
+
+   if (dlane_bps > 25UL || dlane_bps < 16000UL)
+   return -EINVAL;
+   else if (dlane_bps >= 125000)
+   cfg->pll_opdiv = 1;
+   else if (dlane_bps >= 63000)
+   cfg->pll_opdiv = 2;
+   else if (dlane_bps >= 32000)
+   cfg->pll_opdiv = 4;
+   else if (dlane_bps >= 16000)
+   cfg->pll_opdiv = 8;
+
+   /*
+* Allow a deviation of 0.2% on the per-lane data rate to try to
+* recover a potential mismatch between DPI and PPI clks.
+*/
+   dlane_bps_max = dlane_bps + (dlane_bps / 500);


kbuild reported an error for 32 bit archs. I'm guessing it's because of
this divide above?



+
+   fbdiv_max = DIV_ROUND_DOWN_ULL((dlane_bps + (dlane_bps / 500)) * 2 *


You could use dlane_bps_max here instead.

Otherwise,

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU/DRM issue with DSI commands on msm 8916

[Archit Taneja]

On Monday 09 April 2018 04:28 PM, Daniel Mack wrote:

Hi Archit,

Thanks a lot for your reply.

On Friday, April 06, 2018 01:25 PM, Archit Taneja wrote:

On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:

I'm having issues with the GPU/DRM drivers on a msm8916 based platform
which is very similar to the DragonBoard 410c. In my setup, a DSI
display is directly connected to the SoC, and the video link is stable.

However, when the host sends DCS commands down to the DSI panel (for
instance to set the backlight brightness), the image drops out, most of
the time only in terms of a short flicker, but sometimes it will
completely kill the image. In the latter case, only restarting the
Wayland compositor in userspace helps. This is also quite reproducible;
sending a NOP command once a second would give a visual flicker in 90%
of the cases, and it needs at most a minute to make the screen turn black.

The interesting thing is that this used to work in a v4.9 based version,
but it broke somewhere on the way to v4.14. Unfortunately, the platform
does not boot a vanilla kernel, so I can't really bisect this. We
currently depend on the Linaro downstream patches which can be found here:


The major change that happened between qcomlt-4.9 and qcomlt-4.14 from a
DSI point of view was probably the addition of runtime PM support.

The register configurations that are responsible for interleaving DCS
commands while video mode is still on should be the same.


Yeah, I think so too. I compared a lot of code but couldn't really find
anything either. At least, the command buffer contents and lengths are
identical.


You could comment out the pm_runtime_put_sync() calls in
drivers/gpu/drm/msm/dsi/dsi_host.c, in case some registers got
reset during put_sync and weren't restored correctly after get_sync().


That was my first suspicion too, but unfortunately, that's not the culprit.


I think it would be good to comment out the put_sync() calls in
drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c and 
drivers/gpu/drm/msm/msm_drv.c too, since there is a parent-child 
hierarchy between DSI

and the top level MDSS block. Commenting out the put_syncs() just
in put_sync() might still result in the MDSS GDSC to switch off.




Does your device initialize a splash screen in the bootloader?


It does, but that's the case for either of the two kernels. Do you think
that matters? And as you mention it - I'm building the driver as module,
because when built into the kernel, the msm driver fails to initialize
the hardware, and the console is flooded with the following message:


The bootloader may have configured some additional registers that the
DSI driver in the kernel doesn't touch. On 4.9, these registers would
have retained their state since we don't do any PM stuff. On 4.14, these
registers would probably lose their state, which results in a difference
in behavior. This can be avoided by commenting all the put_sync() calls
as mentioned above.



[   63.356837] dsi_err_worker: status=4


You could also compare the reg dumps between 4.9 and 4.14 by enabling
the config CONFIG_DRM_MSM_REGISTER_LOGGING and check if there are
any register configuration differences between the two.


I did that, and there a quite a number of changes, mostly because the
KMS bits have changed a lot. Given that I'm not too familiar with this
driver stack, I'm not sure what exactly to look at.


Mostly to check if there were any changes in the DSI register writes,
and maybe writes to the MDP5 INTF blocks.




One (rather unlikely) possibility I can think of is if somehow the
buffers used to send/receive DCS commands aren't mapped/unmapped
correctly. There have been some msm_gem changes, and the IOMMU driver
is new. That's the main reason why I'm wondering if the contents of the
DCS buffers somehow got corrupt.


That may well be, but I can't really see what's wrong in that area.
Which iommu driver are you referring to, exactly?


On 4.9, this driver is used:
drivers/iommu/qcom

On 4.14 we use:
drivers/iommu/qcom_iommu.c



Is the panel initialized using DCS
commands too?


Yes, and that works. The thing is that the commands do in fact reach the
panel and cause the desired effect, it's just that as a side effect, the
display very likely drops out when a command is sent. The registers that
are modified through msm_writel() by and between
msm_dsi_host_xfer_prepare() and msm_dsi_host_xfer_restore() are exactly
the same though. So it must be that some other part (the GPU or the
KMS?) doesn't like the fact that the DSI core mangles with the hardware
state in some way.


It seems unlikely that sending a DCS command via DSI core would affect
MDP or the GPU. It feels like sending the DCS commands is causing the
DSI lanes to be temporarily in an invalid state, resulting in the
flicker.



What hardware are all these changes developed and tested on, btw? I
guess it might be worth looking into differences between these platforms
and my own.


The releases are mostly tested

Re: [DPU PATCH 1/2] drm/panel: Add Truly Dual DSI video mode panel

[Archit Taneja]

Hi Abhinav,

Thanks for posting this driver. Some comments below.

On Saturday 07 April 2018 12:36 PM, Abhinav Kumar wrote:

From: Archit Taneja <arch...@codeaurora.org>

Add support for truly dual DSI video mode panel
panel used in MSM reference platforms >
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhin...@codeaurora.org>
---
  .../bindings/display/truly,dual_wqxga.txt  |  47 ++
  drivers/gpu/drm/panel/Kconfig  |   7 +
  drivers/gpu/drm/panel/Makefile |   1 +
  drivers/gpu/drm/panel/panel-truly-dual-dsi.c   | 530 +
  4 files changed, 585 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
  create mode 100644 drivers/gpu/drm/panel/panel-truly-dual-dsi.c

diff --git a/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt 
b/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
new file mode 100644
index 000..a1b24c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
@@ -0,0 +1,47 @@
+Truly model NT35597 1440x2560 DSI Panel
+
+Required properties:
+- compatible: should be "truly,dual_wqxga"


The compatible string, kernel config and the driver file should be based
on the panel model no. There can be many truly based panels that
support wqxga. Something like "truly,nt35597" would be better.


+- vdda-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply
+- lab-supply: phandle of the regulator that provides the supply voltage
+  for LCD bias
+- ibb-supply: phandle of the regulator that provides the supply voltage
+  for LCD bias


Both seem to have the same description. Aren't lab and ibb qualcomm
specific terms? Could we use the pin names specified in the panel's
data sheet?


+- reset-gpios: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
+- mode-gpios: phandle of the gpio for choosing the mode of the display
+  for single DSI or Dual DSI


Could we describe here how to use this gpio? I.e, whether we need to set
it to low for dual DSI, etc?


+- display-timings: Node for the Panel timings
+- link2: phandle to the secondary node of the panel


The link2 binding was a temporary hack we used. We should use the
of-graph bindings to represent the two DSI input ports of the panel.


+
+Example:
+
+   dsi@ae94000 {
+   panel@0 {
+   compatible = "truly,dual_wqxga";
+   reg = <0>;
+   link2 = <>;
+   vdda-supply = <_l14>;
+
+   pinctrl-names = "default", "suspend";
+   pinctrl-0 = <_dsi_active>;
+   pinctrl-1 = <_dsi_suspend>;
+
+   reset-gpios = < 6 0>;
+   mode-gpios = < 52 0>;
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <268316138>;
+   hactive = <1440>;
+   vactive = <2560>;
+   hfront-porch = <200>;
+   hback-porch = <64>;
+   hsync-len = <32>;
+   vfront-porch = <8>;
+   vback-porch = <7>;
+   vsync-len = <1>;
+   };
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 988048e..a63c3f7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -168,4 +168,11 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
  
+config DRM_PANEL_TRULY_WQXGA

+   tristate "Truly WQXGA"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Truly WQXGA Dual DSI
+ Video Mode panel
  endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3d2a88d..64891f6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TRULY_WQXGA) += panel-truly-dual-dsi.o
diff --git a/drivers/gpu/drm/pa

Re: [DPU PATCH 2/2] drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY

[Archit Taneja]

On Saturday 07 April 2018 01:20 PM, Abhinav Kumar wrote:

Currently the DSI PHY timings are hard-coded for a specific panel
for the 10nm PHY.

Replace this with the auto PHY timing calculator which can calculate
the PHY timings for any panel.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Signed-off-by: Abhinav Kumar <abhin...@codeaurora.org>
---
  drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 111 +
  drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   2 +
  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c |  28 
  3 files changed, 113 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8e9d5c2..5b42885 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -265,6 +265,117 @@ int msm_dsi_dphy_timing_calc_v2(struct 
msm_dsi_dphy_timing *timing,
return 0;
  }
  
+int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing *timing,

+  struct msm_dsi_phy_clk_request *clk_req)
+{
+   const unsigned long bit_rate = clk_req->bitclk_rate;
+   const unsigned long esc_rate = clk_req->escclk_rate;
+   s32 ui, ui_x8, lpx;
+   s32 tmax, tmin;
+   s32 pcnt0 = 50;
+   s32 pcnt1 = 50;
+   s32 pcnt2 = 10;
+   s32 pcnt3 = 30;
+   s32 pcnt4 = 10;
+   s32 pcnt5 = 2;
+   s32 coeff = 1000; /* Precision, should avoid overflow */
+   s32 hb_en, hb_en_ckln;
+   s32 temp;
+
+   if (!bit_rate || !esc_rate)
+   return -EINVAL;
+
+   timing->hs_halfbyte_en = 0;
+   hb_en = 0;
+   timing->hs_halfbyte_en_ckln = 0;
+   hb_en_ckln = 0;
+
+   ui = mult_frac(NSEC_PER_MSEC, coeff, bit_rate / 1000);
+   ui_x8 = ui << 3;
+   lpx = mult_frac(NSEC_PER_MSEC, coeff, esc_rate / 1000);
+
+   temp = S_DIV_ROUND_UP(38 * coeff, ui_x8);
+   tmin = max_t(s32, temp, 0);
+   temp = (95 * coeff) / ui_x8;
+   tmax = max_t(s32, temp, 0);
+   timing->clk_prepare = linear_inter(tmax, tmin, pcnt0, 0, false);
+
+
+   temp = 300 * coeff - (timing->clk_prepare << 3) * ui;
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = (tmin > 255) ? 511 : 255;
+   timing->clk_zero = linear_inter(tmax, tmin, pcnt5, 0, false);
+
+   tmin = DIV_ROUND_UP(60 * coeff + 3 * ui, ui_x8);
+   temp = 105 * coeff + 12 * ui - 20 * coeff;
+   tmax = (temp + 3 * ui) / ui_x8;
+   timing->clk_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
+
+   temp = S_DIV_ROUND_UP(40 * coeff + 4 * ui, ui_x8);
+   tmin = max_t(s32, temp, 0);
+   temp = (85 * coeff + 6 * ui) / ui_x8;
+   tmax = max_t(s32, temp, 0);
+   timing->hs_prepare = linear_inter(tmax, tmin, pcnt1, 0, false);
+
+   temp = 145 * coeff + 10 * ui - (timing->hs_prepare << 3) * ui;
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 255;
+   timing->hs_zero = linear_inter(tmax, tmin, pcnt4, 0, false);
+
+   tmin = DIV_ROUND_UP(60 * coeff + 4 * ui, ui_x8) - 1;
+   temp = 105 * coeff + 12 * ui - 20 * coeff;
+   tmax = (temp / ui_x8) - 1;
+   timing->hs_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
+
+   temp = 50 * coeff + ((hb_en << 2) - 8) * ui;
+   timing->hs_rqst = S_DIV_ROUND_UP(temp, ui_x8);
+
+   tmin = DIV_ROUND_UP(100 * coeff, ui_x8) - 1;
+   tmax = 255;
+   timing->hs_exit = linear_inter(tmax, tmin, pcnt2, 0, false);
+
+   temp = 50 * coeff + ((hb_en_ckln << 2) - 8) * ui;
+   timing->hs_rqst_ckln = S_DIV_ROUND_UP(temp, ui_x8);
+
+   temp = 60 * coeff + 52 * ui - 43 * ui;
+   tmin = DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 63;
+   timing->shared_timings.clk_post =
+   linear_inter(tmax, tmin, pcnt2, 0, false);
+
+   temp = 8 * ui + (timing->clk_prepare << 3) * ui;
+   temp += (((timing->clk_zero + 3) << 3) + 11) * ui;
+   temp += hb_en_ckln ? (((timing->hs_rqst_ckln << 3) + 4) * ui) :
+   (((timing->hs_rqst_ckln << 3) + 8) * ui);
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 63;
+   if (tmin > tmax) {
+   temp = linear_inter(tmax << 1, tmin, pcnt2, 0, false);
+   timing->shared_timings.clk_pre = temp >> 1;
+   timing->shared_timings.clk_pre_inc_by_2 = 1;
+   } else {
+   timing->shared_timings.clk_pre =
+   linear_inter(tmax, tmin, pcnt2, 0, false);
+   timing->shared_timings.clk_pre_inc_by_2 = 0;
+   }
+
+   timing->ta_go = 3;
+   timing->ta_sure = 0;
+   timing->ta_get = 4;
+
+   DBG("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d",
+   timing->shared_timings.clk_pre, timing->sh

Re: GPU/DRM issue with DSI commands on msm 8916

[Archit Taneja]

Hi,

On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:

Hi,

I'm having issues with the GPU/DRM drivers on a msm8916 based platform
which is very similar to the DragonBoard 410c. In my setup, a DSI
display is directly connected to the SoC, and the video link is stable.

However, when the host sends DCS commands down to the DSI panel (for
instance to set the backlight brightness), the image drops out, most of
the time only in terms of a short flicker, but sometimes it will
completely kill the image. In the latter case, only restarting the
Wayland compositor in userspace helps. This is also quite reproducible;
sending a NOP command once a second would give a visual flicker in 90%
of the cases, and it needs at most a minute to make the screen turn black.

The interesting thing is that this used to work in a v4.9 based version,
but it broke somewhere on the way to v4.14. Unfortunately, the platform
does not boot a vanilla kernel, so I can't really bisect this. We
currently depend on the Linaro downstream patches which can be found here:


The major change that happened between qcomlt-4.9 and qcomlt-4.14 from a 
DSI point of view was probably the addition of runtime PM support.


The register configurations that are responsible for interleaving DCS
commands while video mode is still on should be the same.

You could comment out the pm_runtime_put_sync() calls in
drivers/gpu/drm/msm/dsi/dsi_host.c, in case some registers got
reset during put_sync and weren't restored correctly after get_sync().

Does your device initialize a splash screen in the bootloader?

You could also compare the reg dumps between 4.9 and 4.14 by enabling
the config CONFIG_DRM_MSM_REGISTER_LOGGING and check if there are
any register configuration differences between the two.

One (rather unlikely) possibility I can think of is if somehow the
buffers used to send/receive DCS commands aren't mapped/unmapped
correctly. There have been some msm_gem changes, and the IOMMU driver
is new. That's the main reason why I'm wondering if the contents of the
DCS buffers somehow got corrupt. Is the panel initialized using DCS
commands too?

Thanks,
Archit




http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=release/qcomlt-4.9

http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=release/qcomlt-4.14

I've looked at the development that has happened in the area for some
time now, but I can't really pin-point any specific commit. Also, I
cherry-picked most of the patches to these drivers that came in after
v4.14, but that didn't help either.

Has this has been observed before? A pointer what to investigate on
would be very much appreciated. If there is any more information I can
provide, please let me know.


Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/6] drm/msm: Issue queued events when disabling crtc

[Archit Taneja]

On Thursday 29 March 2018 12:36 AM, Sean Paul wrote:

Ensure that any queued events are issued when disabling the crtc. This
avoids timeouts when we come back and wait for dependencies (like the
previous frame's flip_done).


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Changes in v2:
- None

Signed-off-by: Sean Paul <seanp...@chromium.org>
---
  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 76b96081916f..10271359789e 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -430,6 +430,7 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc *crtc,
struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
struct mdp5_kms *mdp5_kms = get_kms(crtc);
struct device *dev = _kms->pdev->dev;
+   unsigned long flags;
  
  	DBG("%s", crtc->name);
  
@@ -445,6 +446,14 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc *crtc,

mdp_irq_unregister(_kms->base, _crtc->err);
pm_runtime_put_sync(dev);
  
+	if (crtc->state->event && !crtc->state->active) {

+   WARN_ON(mdp5_crtc->event);
+   spin_lock_irqsave(_kms->dev->event_lock, flags);
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   crtc->state->event = NULL;
+   spin_unlock_irqrestore(_kms->dev->event_lock, flags);
+   }
+
mdp5_crtc->enabled = false;
  }
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/6] drm/msm: Mark the crtc->state->event consumed

[Archit Taneja]

On Thursday 29 March 2018 12:36 AM, Sean Paul wrote:

Don't leave the event != NULL once it's consumed, this is used a signal

s/used a/used as a ?

to the atomic helpers that the event will be handled by the driver.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Changes in v2:
- None

Cc: Jeykumar Sankaran <jsa...@codeaurora.org>
Signed-off-by: Sean Paul <seanp...@chromium.org>
---
  drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 +
  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index 6e5e1aa54ce1..b001699297c4 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -351,6 +351,7 @@ static void mdp4_crtc_atomic_flush(struct drm_crtc *crtc,
  
  	spin_lock_irqsave(>event_lock, flags);

mdp4_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
  
  	blend_setup(crtc);

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 9893e43ba6c5..76b96081916f 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -708,6 +708,7 @@ static void mdp5_crtc_atomic_flush(struct drm_crtc *crtc,
  
  	spin_lock_irqsave(>event_lock, flags);

mdp5_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
  
  	/*



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/6] drm/msm: Refactor complete_commit() to look more the helpers

[Archit Taneja]

On Thursday 29 March 2018 12:36 AM, Sean Paul wrote:

Factor out the commit_tail() portions of complete_commit() into a
separate function to facilitate moving to the atomic helpers in future
patches.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Changes in v2:
- None

Cc: Jeykumar Sankaran <jsa...@codeaurora.org>
Signed-off-by: Sean Paul <seanp...@chromium.org>
---
  drivers/gpu/drm/msm/msm_atomic.c | 25 -
  1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index e792158676aa..671a18ee977d 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -97,18 +97,12 @@ static void msm_atomic_wait_for_commit_done(struct 
drm_device *dev,
}
  }
  
-/* The (potentially) asynchronous part of the commit.  At this point

- * nothing can fail short of armageddon.
- */
-static void complete_commit(struct msm_commit *c, bool async)
+static void msm_atomic_commit_tail(struct drm_atomic_state *state)
  {
-   struct drm_atomic_state *state = c->state;
struct drm_device *dev = state->dev;
struct msm_drm_private *priv = dev->dev_private;
struct msm_kms *kms = priv->kms;
  
-	drm_atomic_helper_wait_for_fences(dev, state, false);

-
kms->funcs->prepare_commit(kms, state);
  
  	drm_atomic_helper_commit_modeset_disables(dev, state);

@@ -135,6 +129,19 @@ static void complete_commit(struct msm_commit *c, bool 
async)
drm_atomic_helper_cleanup_planes(dev, state);
  
  	kms->funcs->complete_commit(kms, state);

+}
+
+/* The (potentially) asynchronous part of the commit.  At this point
+ * nothing can fail short of armageddon.
+ */
+static void complete_commit(struct msm_commit *c)
+{
+   struct drm_atomic_state *state = c->state;
+   struct drm_device *dev = state->dev;
+
+   drm_atomic_helper_wait_for_fences(dev, state, false);
+
+   msm_atomic_commit_tail(state);
  
  	drm_atomic_state_put(state);
  
@@ -143,7 +150,7 @@ static void complete_commit(struct msm_commit *c, bool async)
  
  static void commit_worker(struct work_struct *work)

  {
-   complete_commit(container_of(work, struct msm_commit, work), true);
+   complete_commit(container_of(work, struct msm_commit, work));
  }
  
  /**

@@ -242,7 +249,7 @@ int msm_atomic_commit(struct drm_device *dev,
return 0;
}
  
-	complete_commit(c, false);

+   complete_commit(c);
  
  	return 0;
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/6] drm/msm: Use drm_private_obj/state instead of subclassing

[Archit Taneja]

On Thursday 29 March 2018 12:36 AM, Sean Paul wrote:

Now that we have private state handled by the core, we can use those
instead of rolling our own swap_state for private data.

Originally posted here: https://patchwork.freedesktop.org/patch/211361/

Changes in v2:
  - Use state->state in disp duplicate_state callback (Jeykumar)
Changes in v3:
  - Update comment describing msm_kms_state (Jeykumar)
Changes in v4:
  - Rebased on msm-next
  - Don't always use private state from atomic state (Archit)
  - Renamed some of the state accessors
  - Tested on mdp5 db410c
Changes in v5:
  - None

Cc: Jeykumar Sankaran <jsa...@codeaurora.org>
Cc: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Sean Paul <seanp...@chromium.org>
---
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c   | 77 ++-
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h   | 11 +--
  drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c | 12 ++-
  drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c  | 28 ---
  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c   | 19 +++--
  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.h   |  4 +-
  drivers/gpu/drm/msm/msm_atomic.c   | 37 -
  drivers/gpu/drm/msm/msm_drv.c  | 87 +-
  drivers/gpu/drm/msm/msm_drv.h  |  3 -
  drivers/gpu/drm/msm/msm_kms.h  | 21 --
  10 files changed, 183 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..366670043190 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -70,60 +70,62 @@ static int mdp5_hw_init(struct msm_kms *kms)
return 0;
  }
  
-struct mdp5_state *mdp5_get_state(struct drm_atomic_state *s)

+struct mdp5_state *mdp5_state_from_atomic(struct drm_atomic_state *state)
  {
-   struct msm_drm_private *priv = s->dev->dev_private;
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct msm_kms_state *state = to_kms_state(s);
-   struct mdp5_state *new_state;
-   int ret;
+   struct msm_kms_state *kms_state = msm_kms_state_from_atomic(state);
  
-	if (state->state)

-   return state->state;
+   if (IS_ERR_OR_NULL(kms_state))
+   return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
  
-	ret = drm_modeset_lock(_kms->state_lock, s->acquire_ctx);

-   if (ret)
-   return ERR_PTR(ret);
+   return kms_state->state;
+}
  
-	new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);

-   if (!new_state)
-   return ERR_PTR(-ENOMEM);
+struct mdp5_state *mdp5_state_from_dev(struct drm_device *dev)
+{
+   struct msm_kms_state *kms_state = msm_kms_state_from_dev(dev);
  
-	/* Copy state: */

-   new_state->hwpipe = mdp5_kms->state->hwpipe;
-   new_state->hwmixer = mdp5_kms->state->hwmixer;
-   if (mdp5_kms->smp)
-   new_state->smp = mdp5_kms->state->smp;
+   if (IS_ERR_OR_NULL(kms_state))
+   return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
  
-	state->state = new_state;

+   return kms_state->state;
+}
+
+static void *mdp5_duplicate_state(void *state)
+{
+   if (!state)
+   return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);
  
-	return new_state;

+   return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
  }
  
-static void mdp5_swap_state(struct msm_kms *kms, struct drm_atomic_state *state)

+static void mdp5_destroy_state(void *state)
  {
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
-   swap(to_kms_state(state)->state, mdp5_kms->state);
+   struct mdp5_state *mdp_state = (struct mdp5_state *)state;
+   kfree(mdp_state);
  }
  
-static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state *state)

+static void mdp5_prepare_commit(struct msm_kms *kms,
+   struct drm_atomic_state *old_state)
  {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+   struct mdp5_state *mdp5_state = mdp5_state_from_dev(mdp5_kms->dev);
struct device *dev = _kms->pdev->dev;
  
  	pm_runtime_get_sync(dev);
  
  	if (mdp5_kms->smp)

-   mdp5_smp_prepare_commit(mdp5_kms->smp, _kms->state->smp);
+   mdp5_smp_prepare_commit(mdp5_kms->smp, _state->smp);
  }
  
-static void mdp5_complete_commit(struct msm_kms *kms, struct drm_atomic_state *state)

+static void mdp5_complete_commit(struct msm_kms *kms,
+struct drm_atomic_state *old_state)
  {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+   struct mdp5_state *mdp5_state = mdp5_state_from_dev(mdp5_kms->dev);
struct device *dev = _kms->pdev->dev;
  
  	if (mdp5_kms->smp)

-   mdp5_smp_complete_commit(mdp5_kms->smp, _km

Re: [PATCH] drm/msm/dsi: use correct enum in dsi_get_cmd_fmt

[Archit Taneja]

On Tuesday 20 March 2018 02:56 AM, Stefan Agner wrote:

The function dsi_get_cmd_fmt returns enum dsi_cmd_dst_format,
use the correct enum value also for MIPI_DSI_FMT_RGB666/_PACKED.

This has been discovered using clang:
   drivers/gpu/drm/msm/dsi/dsi_host.c:743:35: warning: implicit conversion
 from enumeration type 'enum dsi_vid_dst_format' to different
 enumeration type 'enum dsi_cmd_dst_format' [-Wenum-conversion]
   case MIPI_DSI_FMT_RGB666:   return VID_DST_FORMAT_RGB666;
   ~~ ^

Signed-off-by: Stefan Agner <ste...@agner.ch>


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Archit


---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 0f7324a686ca..d729b2b4b66d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -740,7 +740,7 @@ static inline enum dsi_cmd_dst_format dsi_get_cmd_fmt(
switch (mipi_fmt) {
case MIPI_DSI_FMT_RGB888:   return CMD_DST_FORMAT_RGB888;
case MIPI_DSI_FMT_RGB666_PACKED:
-   case MIPI_DSI_FMT_RGB666:   return VID_DST_FORMAT_RGB666;
+   case MIPI_DSI_FMT_RGB666:   return CMD_DST_FORMAT_RGB666;
case MIPI_DSI_FMT_RGB565:   return CMD_DST_FORMAT_RGB565;
default:return CMD_DST_FORMAT_RGB888;
}


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/3] Cleanup excessive DSI host controller version checks

[Archit Taneja]

On Tuesday 20 March 2018 01:11 AM, Sibi S wrote:

This patch series aims to create and bind dsi host controller helper
functions to functionalities that vary across DSI v2, DSI 6G 1.x and
DSI 6G v2.0+ controllers. These functionalities are currently under
excessive version checks which is now replaced with the corresponding
helper function.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



V2:
   Removes command broadcast support for DSI 6G v2.0+ controllers from
   the patch series and incorporates all the suggested corrections
   


Sibi S (3):
   drm/msm/dsi: add dsi host helper functions support
   drm/msm/dsi: add implementation for helper functions
   drm/msm/dsi: replace version checks with helper functions

  drivers/gpu/drm/msm/dsi/dsi.h  |  16 ++
  drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  56 +-
  drivers/gpu/drm/msm/dsi/dsi_cfg.h  |  12 ++
  drivers/gpu/drm/msm/dsi/dsi_host.c | 362 +
  4 files changed, 280 insertions(+), 166 deletions(-)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v3] drm/msm: Use atomic private_obj instead of subclassing

[Archit Taneja]

Hi,

On Tuesday 20 March 2018 01:28 AM, Sean Paul wrote:

Instead of subclassing atomic state, store driver private data in
private_obj/state. This allows us to remove the swap_state driver hook
for mdp5 and get closer to using the atomic helpers entirely.

Changes in v2:
  - Use state->state in disp duplicate_state callback (Jeykumar)
Changes in v3:
  - Update comment describing msm_kms_state (Jeykumar)



One difference w.r.t the patchset
"drm/msm/mdp5: Use the new private_obj state" is that this
adds the atomic private_obj for all kms backends, whereas the one
I'd done originally just added it for mdp5, so this patch set
is better in that respect.

The other difference is how we 'get' the private state. In this patch,
the helper drm_atomic_get_private_obj_state() is used every time to
get the private object state.

I'd tried to do the same initially, but I noticed that
drm_atomic_get_private_obj_state() doesn't return the correct
state post swapping of states. So, instead of relying on the helper,
I created a helper called mdp5_get_existing_global_state() that
returns the desired state(the state pointer in msm_kms>state->base.state 
in this patch) in all funcs that are called post-swap.



You could read about the issue on the the thread: "[RFC 1/3] 
drm/msm/mdp5: Add global state as a private atomic object"


The problem was quite apparent with db410c, where SMP blocks are
assigned to planes. If the latest SMP state isn't referred when
configuring SMP registers, we see underruns immediately.

An easy way to reproduce this is to use modset on db410c. I think
it might occur with this patch too. It might be worth trying it
out.

Thanks,
Archit


Cc: Jeykumar Sankaran 
Reviewed-by: Jeykumar Sankaran 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 37 ++
  drivers/gpu/drm/msm/msm_atomic.c | 30 ---
  drivers/gpu/drm/msm/msm_drv.c| 65 ++--
  drivers/gpu/drm/msm/msm_drv.h|  4 +-
  drivers/gpu/drm/msm/msm_kms.h| 27 +-
  5 files changed, 94 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..f1a248419655 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -74,36 +74,32 @@ struct mdp5_state *mdp5_get_state(struct drm_atomic_state 
*s)
  {
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct msm_kms_state *state = to_kms_state(s);
-   struct mdp5_state *new_state;
+   struct msm_kms_state *kms_state;
int ret;
  
-	if (state->state)

-   return state->state;
-
ret = drm_modeset_lock(_kms->state_lock, s->acquire_ctx);
if (ret)
return ERR_PTR(ret);
  
-	new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);

-   if (!new_state)
-   return ERR_PTR(-ENOMEM);
+   kms_state = msm_kms_get_state(s);
+   if (IS_ERR_OR_NULL(kms_state))
+   return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
  
-	/* Copy state: */

-   new_state->hwpipe = mdp5_kms->state->hwpipe;
-   new_state->hwmixer = mdp5_kms->state->hwmixer;
-   if (mdp5_kms->smp)
-   new_state->smp = mdp5_kms->state->smp;
+   return kms_state->state;
+}
  
-	state->state = new_state;

+static void *mdp5_duplicate_state(void *state)
+{
+   if (!state)
+   return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);
  
-	return new_state;

+   return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
  }
  
-static void mdp5_swap_state(struct msm_kms *kms, struct drm_atomic_state *state)

+static void mdp5_destroy_state(void *state)
  {
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
-   swap(to_kms_state(state)->state, mdp5_kms->state);
+   struct mdp5_state *mdp_state = state;
+   kfree(mdp_state);
  }
  
  static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state *state)

@@ -229,7 +225,8 @@ static const struct mdp_kms_funcs kms_funcs = {
.irq = mdp5_irq,
.enable_vblank   = mdp5_enable_vblank,
.disable_vblank  = mdp5_disable_vblank,
-   .swap_state  = mdp5_swap_state,
+   .duplicate_state = mdp5_duplicate_state,
+   .destroy_state   = mdp5_destroy_state,
.prepare_commit  = mdp5_prepare_commit,
.complete_commit = mdp5_complete_commit,
.wait_for_crtc_commit_done = mdp5_wait_for_crtc_commit_done,
@@ -726,8 +723,6 @@ static void mdp5_destroy(struct platform_device *pdev)
  
  	if (mdp5_kms->rpm_enabled)

pm_runtime_disable(>dev);
-
-   kfree(mdp5_kms->state);
  }
  
  static int 

Re: [PATCH 1/2] dt-bindings: analogix-dp: Add backlight-pwm-passthru

[Archit Taneja]

On Friday 16 March 2018 08:26 AM, Alexandru M Stan wrote:

Documentation for the optional backlight-pwm-passthru property.
Tells the EDP panel to folow the input pwm frequency instead


s/folow/follow

It would be nice if we could add the details you mentioned in
patch #0 in either this or the next patch.


of generating its own.


This is one of those bindings which is more a knob than a HW property,
but I can't think of any easy way to figure this out in SW. So, I guess
it's okay to have.

One thing I was wondering about was whether this prop should belong to
the eDP controller or the eDP panel. I don't have any strong opinion
about it, though.

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit




Signed-off-by: Alexandru M Stan <ams...@chromium.org>
---

  Documentation/devicetree/bindings/display/bridge/analogix_dp.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 0c7473dd0e51..3c15242f6ce3 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -23,6 +23,10 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
  
  Optional properties for dp-controller:

+   -backlight-pwm-passthru:
+   Directly pass the PWM frequency applied to the BL_PWM_DIM
+   pin to the backlight current source. Done via
+   EDP_BACKLIGHT_MODE_SET_REGISTER on DPCD.
-force-hpd:
Indicate driver need force hpd when hpd detect failed, this
is used for some eDP screen which don't have hpd signal.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 21/36] drm/bridge: analogix_dp: Fix timeout of video streamclk config

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

The STRM_VALID bit in register ANALOGIX_DP_SYS_CTL_3 may be unstable,
so we may hit the error log "Timeout of video streamclk ok" since
checked this unstable bit.
In fact, we can go continue and the streamclk is ok if we wait enough time,
it does no effect on display.
Let's change this error to warn.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: Douglas Anderson <diand...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1f1cb624414d..d76e1652b1fd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -921,8 +921,9 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
done_count = 0;
}
if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "Timeout of video streamclk ok\n");
-   return -ETIMEDOUT;
+   dev_warn(dp->dev,
+"Ignoring timeout of video streamclk ok\n");
+   break;
}
  
  		usleep_range(1000, 1001);



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 23/36] drm/bridge: analogix_dp: Move fast link training detect to set_bridge

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang 

It's too early to detect fast link training, if other step after it
failed, we will set fast_link flag to 1, and retry set_bridge again. In
this case we will power down and power up panel power supply, and we
will do fast link training since we have set fast_link flag to 1. In
fact, we should do full link training now, not the fast link training.
So we should move the fast link detection at the end of set_bridge.


Is it possible to re-write this commit message? It's a bit hard to
follow.

Thanks,
Archit



Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 42 +-
  1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d76e1652b1fd..37b16643f14c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -601,7 +601,7 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
  {
int lane, lane_count, retval;
u32 reg;
-   u8 link_align, link_status[2], adjust_request[2], spread;
+   u8 link_align, link_status[2], adjust_request[2];
  
  	usleep_range(400, 401);
  
@@ -645,20 +645,6 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)

dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
  
-		retval = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD,

-  );
-   if (retval != 1) {
-   dev_err(dp->dev, "failed to read downspread %d\n",
-   retval);
-   dp->fast_train_enable = false;
-   } else {
-   dp->fast_train_enable =
-   (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
-   true : false;
-   }
-   dev_dbg(dp->dev, "fast link training %s\n",
-   dp->fast_train_enable ? "supported" : "unsupported");
-
dp->link_train.lt_state = FINISHED;
  
  		return 0;

@@ -996,6 +982,22 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void 
*arg)
return IRQ_HANDLED;
  }
  
+static int analogix_dp_fast_link_train_detection(struct analogix_dp_device *dp)

+{
+   int ret;
+   u8 spread;
+
+   ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, );
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to read downspread %d\n", ret);
+   return ret;
+   }
+   dp->fast_train_enable = !!(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
+   dev_dbg(dp->dev, "fast link training %s\n",
+   dp->fast_train_enable ? "supported" : "unsupported");
+   return 0;
+}
+
  static int analogix_dp_commit(struct analogix_dp_device *dp)
  {
int ret;
@@ -1038,8 +1040,16 @@ static int analogix_dp_commit(struct analogix_dp_device 
*dp)
if (ret)
return ret;
  
-	if (dp->psr_enable)

+   if (dp->psr_enable) {
ret = analogix_dp_enable_sink_psr(dp);
+   if (ret)
+   return ret;
+   }
+
+   /* Check whether panel supports fast training */
+   ret =  analogix_dp_fast_link_train_detection(dp);
+   if (ret)
+   dp->psr_enable = false;
  
  	return ret;

  }


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 24/36] drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: Douglas Anderson <diand...@chromium.org>

The current user of the analogix power_off is "analogix_dp-rockchip".
That driver does this:
- deactivate PSR
- turn off a clock

Both of these things (especially deactive PSR) should be done before
we turn the PHY power off and turn off analog power.  Let's move the
callback up.

Note that without this patch (and with
https://patchwork.kernel.org/patch/9553349/ [seanpaul: this patch was
not applied, but it seems like the race can still occur]), I experienced
an error in reboot testing where one thread was at:

   rockchip_drm_psr_deactivate
   rockchip_dp_powerdown
   analogix_dp_bridge_disable
   drm_bridge_disable

...and the other thread was at:

   analogix_dp_send_psr_spd
   analogix_dp_enable_psr
   analogix_dp_psr_set
   psr_flush_handler

The flush handler thread was finding AUX channel errors and eventually
reported "Failed to apply PSR", where I had a kgdb breakpoint. Presumably
the device would have eventually given up and shut down anyway, but it
seems better to fix the order to be more correct.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Kristian H. Kristensen <hoegsb...@chromium.org>
Signed-off-by: Douglas Anderson <diand...@chromium.org>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 37b16643f14c..eaf93cbd47a8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1337,12 +1337,13 @@ static void analogix_dp_bridge_disable(struct 
drm_bridge *bridge)
}
  
  	disable_irq(dp->irq);

-   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
-   phy_power_off(dp->phy);
  
  	if (dp->plat_data->power_off)

dp->plat_data->power_off(dp->plat_data);
  
+	analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);

+   phy_power_off(dp->phy);
+
clk_disable_unprepare(dp->clock);
  
  	pm_runtime_put_sync(dp->dev);



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 25/36] drm/bridge: analogix_dp: Properly log AUX CH errors

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: Douglas Anderson <diand...@chromium.org>

The code in analogix_dp_transfer() that was supposed to print out:
   AUX CH error happened

Was actually dead code. That's because the previous check (whether
the interrupt status indicated any errors) would have hit for all
errors anyway.

Let's combine the two error checks so we can actually see AUX CH
errors.  We'll also downgrade the message to a warning since some of
these types of errors might be expected for some displays.  If this
gets too noisy we can downgrade again to debug.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: 征增 王 <w...@rock-chips.com>
Signed-off-by: Douglas Anderson <diand...@chromium.org>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 13 +
  1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 4eae206ec31b..58e8a28e99aa 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1105,6 +1105,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 struct drm_dp_aux_msg *msg)
  {
u32 reg;
+   u32 status_reg;
u8 *buffer = msg->buffer;
unsigned int i;
int num_transferred = 0;
@@ -1193,16 +1194,12 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
  
  	/* Clear interrupt source for AUX CH access error */

reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   if (reg & AUX_ERR) {
+   status_reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
+   if ((reg & AUX_ERR) || (status_reg & AUX_STATUS_MASK)) {
writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
-   goto aux_error;
-   }
  
-	/* Check AUX CH error access status */

-   reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
-   if ((reg & AUX_STATUS_MASK)) {
-   dev_err(dp->dev, "AUX CH error happened: %d\n\n",
-   reg & AUX_STATUS_MASK);
+   dev_warn(dp->dev, "AUX CH error happened: %#x (%d)\n",
+status_reg & AUX_STATUS_MASK, !!(reg & AUX_ERR));
goto aux_error;
}
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 26/36] drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: Douglas Anderson <diand...@chromium.org>

The comments in analogix_dp_init_aux() claim that we're disabling aux
channel retries, but then right below it for Rockchip it sets them to
3.  If we actually need 3 retries for Rockchip then we could adjust
the comment, but it seems more likely that we want the same retry
behavior across all platforms.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: Stéphane Marchesin <marc...@chromium.org>
Cc: 征增 王 <w...@rock-chips.com>
Signed-off-by: Douglas Anderson <diand...@chromium.org>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 58e8a28e99aa..a5f2763d72e4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -481,15 +481,16 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
  
  	analogix_dp_reset_aux(dp);
  
-	/* Disable AUX transaction H/W retry */

+   /* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */
if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
-   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) |
- AUX_HW_RETRY_COUNT_SEL(3) |
- AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+   reg = 0;
else
-   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) |
- AUX_HW_RETRY_COUNT_SEL(0) |
- AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3);
+
+   /* Disable AUX transaction H/W retry */
+   reg |= AUX_HW_RETRY_COUNT_SEL(0) |
+  AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL);
  
  	/* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 22/36] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
Exynos:

on Exynos edp phy,
BIT 7   MASTER_VID_FUNC_EN_N
BIT 6   reserved
BIT 5   SLAVE_VID_FUNC_EN_N

on Rockchip edp phy,
BIT 7   reserved
BIT 6   RK_VID_CAP_FUNC_EN_N
BIT 5   RK_VID_FIFO_FUNC_EN_N

So, we should do some private operations to Rockchip.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: Tomasz Figa <tf...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++-
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |  2 ++
  2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 02ab1aaa9993..4eae206ec31b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
analogix_dp_stop_video(dp);
analogix_dp_enable_video_mute(dp, 0);
  
-	reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |

-   AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
-   HDCP_FUNC_EN_N | SW_FUNC_EN_N;
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+   reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
+   SW_FUNC_EN_N;
+   else
+   reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
+   AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
+   HDCP_FUNC_EN_N | SW_FUNC_EN_N;
+
writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
  
  	reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |

@@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp)
u32 reg;
  
  	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);

-   reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
-   reg |= MASTER_VID_FUNC_EN_N;
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+   reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
+   } else {
+   reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
+   reg |= MASTER_VID_FUNC_EN_N;
+   }
writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
  
  	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index b633a4a5082a..0cf27c731727 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -127,7 +127,9 @@
  
  /* ANALOGIX_DP_FUNC_EN_1 */

  #define MASTER_VID_FUNC_EN_N  (0x1 << 7)
+#define RK_VID_CAP_FUNC_EN_N   (0x1 << 6)
  #define SLAVE_VID_FUNC_EN_N   (0x1 << 5)
+#define RK_VID_FIFO_FUNC_EN_N  (0x1 << 5)
  #define AUD_FIFO_FUNC_EN_N(0x1 << 4)
  #define AUD_FUNC_EN_N (0x1 << 3)
  #define HDCP_FUNC_EN_N(0x1 << 2)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 20/36] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg
list.  We should use BIT_4 in ANALOGIX_DP_PD to control the pll power
instead of ANALOGIX_DP_PLL_CTL.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Douglas Anderson <diand...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 
  1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 7b7fd227e1f9..02ab1aaa9993 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -230,16 +230,20 @@ enum pll_status analogix_dp_get_pll_lock_status(struct 
analogix_dp_device *dp)
  void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool 
enable)
  {
u32 reg;
+   u32 mask = DP_PLL_PD;
+   u32 pd_addr = ANALOGIX_DP_PLL_CTL;
  
-	if (enable) {

-   reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   reg |= DP_PLL_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   } else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   reg &= ~DP_PLL_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+   pd_addr = ANALOGIX_DP_PD;
+   mask = RK_PLL_PD;
}
+
+   reg = readl(dp->reg_base + pd_addr);
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + pd_addr);
  }
  
  void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 19/36] drm/rockchip: Restore psr->state when enable/disable psr failed

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

If we failed disable psr, it would hang the display until next psr
cycle coming. So we should restore psr->state when it failed.



For the bridge part,

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Tomasz Figa <tf...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Douglas Anderson <diand...@chromium.org>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 +++-
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 10 +-
  drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 20 +---
  drivers/gpu/drm/rockchip/rockchip_drm_psr.h|  2 +-
  4 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index be6eddd0d0a7..1f1cb624414d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -153,8 +153,10 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
psr_vsc.DB1 = 0;
  
  	ret = drm_dp_dpcd_writeb(>aux, DP_SET_POWER, DP_SET_POWER_D0);

-   if (ret != 1)
+   if (ret != 1) {
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
+   return ret;
+   }
  
  	return analogix_dp_send_psr_spd(dp, _vsc, false);

  }
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 3e8bf79bea58..8c884f9ce713 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -77,13 +77,13 @@ struct rockchip_dp_device {
struct analogix_dp_plat_data plat_data;
  };
  
-static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)

+static int analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
  {
struct rockchip_dp_device *dp = to_dp(encoder);
int ret;
  
  	if (!analogix_dp_psr_enabled(dp->adp))

-   return;
+   return 0;
  
  	DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
  
@@ -91,13 +91,13 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)

 PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
DRM_DEV_ERROR(dp->dev, "line flag interrupt did not arrive\n");
-   return;
+   return -ETIMEDOUT;
}
  
  	if (enabled)

-   analogix_dp_enable_psr(dp->adp);
+   return analogix_dp_enable_psr(dp->adp);
else
-   analogix_dp_disable_psr(dp->adp);
+   return analogix_dp_disable_psr(dp->adp);
  }
  
  static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index b339ca943139..9376f4396b6b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -36,7 +36,7 @@ struct psr_drv {
  
  	struct delayed_work	flush_work;
  
-	void (*set)(struct drm_encoder *encoder, bool enable);

+   int (*set)(struct drm_encoder *encoder, bool enable);
  };
  
  static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)

@@ -93,19 +93,25 @@ static void psr_set_state_locked(struct psr_drv *psr, enum 
psr_state state)
return;
}
  
-	psr->state = state;

-
/* Actually commit the state change to hardware */
-   switch (psr->state) {
+   switch (state) {
case PSR_ENABLE:
-   psr->set(psr->encoder, true);
+   if (psr->set(psr->encoder, true))
+   return;
break;
  
  	case PSR_DISABLE:

case PSR_FLUSH:
-   psr->set(psr->encoder, false);
+   if (psr->set(psr->encoder, false))
+   return;
break;
+
+   default:
+   pr_err("%s: Unknown state %d\n", __func__, state);
+   return;
}
+
+   psr->state = state;
  }
  
  static void psr_set_state(struct psr_drv *psr, enum psr_state state)

@@ -229,7 +235,7 @@ EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
   * Zero on success, negative errno on failure.
   */
  int rockchip_drm_psr_register(struct drm_encoder *encoder,
-   void (*psr_set)(struct drm_encoder *, bool enable))
+   int (*psr_set)(str

Re: [PATCH v5 18/36] drm/bridge: analogix_dp: Reset aux channel if an error occurred

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: Lin Huang <h...@rock-chips.com>

AUX errors are caused by many different reasons. We may not know what
happened in aux channel on failure, so let's reset aux channel if some
errors occurred.

Cc: 征增 王 <w...@rock-chips.com>
Cc: Douglas Anderson <diand...@chromium.org>
Signed-off-by: Lin Huang <h...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index dee1ba109b5f..7b7fd227e1f9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -466,6 +466,10 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
reg = RPLY_RECEIV | AUX_ERR;
writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
  
+	analogix_dp_set_analog_power_down(dp, AUX_BLOCK, true);

+   usleep_range(10, 11);
+   analogix_dp_set_analog_power_down(dp, AUX_BLOCK, false);
+


Is this additional power on/off the analog power to the AUX block
required to reset it correctly? If so, could you mention that in the
commit message?


analogix_dp_reset_aux(dp);
  
  	/* Disable AUX transaction H/W retry */

@@ -1159,7 +1163,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 reg, !(reg & AUX_EN), 25, 500 * 1000);
if (ret) {
dev_err(dp->dev, "AUX CH enable timeout!\n");
-   return -ETIMEDOUT;
+   goto aux_error;
}
  
  	/* TODO: Wait for an interrupt instead of looping? */

@@ -1168,7 +1172,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 reg, reg & RPLY_RECEIV, 10, 20 * 1000);
if (ret) {
dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
-   return -ETIMEDOUT;
+   goto aux_error;
}
  
  	/* Clear interrupt source for AUX CH command reply */

@@ -1178,7 +1182,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
if (reg & AUX_ERR) {
writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
-   return -EREMOTEIO;
+   goto aux_error;
}
  
  	/* Check AUX CH error access status */

@@ -1186,7 +1190,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
if ((reg & AUX_STATUS_MASK)) {
dev_err(dp->dev, "AUX CH error happened: %d\n\n",
reg & AUX_STATUS_MASK);
-   return -EREMOTEIO;
+   goto aux_error;
}
  
  	if (msg->request & DP_AUX_I2C_READ) {

@@ -1212,4 +1216,10 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
msg->reply = DP_AUX_NATIVE_REPLY_ACK;
  
  	return num_transferred > 0 ? num_transferred : -EBUSY;

+
+aux_error:
+   /* if aux err happen, reset aux */
+   analogix_dp_init_aux(dp);
+
+   return -EREMOTEIO;


A couple of ETIMEDOUTs have been replaced with EREMOTEIOs after this
change. Maybe we set it the error no in ret and return ret?

With those changes,

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


  }


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 17/36] drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

There are some different bits between Rockchip and Exynos in register
"AUX_PD". This patch fixes the incorrect operations about it.


You mean the register ANALOGIX_DP_PHY_PD/ANALOGIX_DP_PD, right? AUX_PD
sounds like just one of the fields of the register.

With that,

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: Douglas Anderson <diand...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 117 --
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |   2 +
  2 files changed, 65 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index bb72f8b0e603..dee1ba109b5f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -248,76 +248,85 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
  {
u32 reg;
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+   u32 mask;
  
  	if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))

phy_pd_addr = ANALOGIX_DP_PD;
  
  	switch (block) {

case AUX_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= AUX_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~AUX_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+   mask = RK_AUX_PD;
+   else
+   mask = AUX_PD;
+
+   reg = readl(dp->reg_base + phy_pd_addr);
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH0_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH0_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH0_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH0_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH1_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH1_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH1_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH1_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH2_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH2_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH2_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH2_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH3_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + 

Re: [PATCH v5 16/36] drm/bridge: analogix_dp: Check dpcd write/read status

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: Lin Huang <h...@rock-chips.com>

We need to check the dpcd write/read return value to see whether the
write/read was successful



Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Kristian H. Kristensen <hoegsb...@chromium.org>
Signed-off-by: Lin Huang <h...@rock-chips.com>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Douglas Anderson <diand...@chromium.org>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 169 -
  1 file changed, 127 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1eed35f9eb8d..be6eddd0d0a7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -160,80 +160,137 @@ int analogix_dp_disable_psr(struct analogix_dp_device 
*dp)
  }
  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
  
-static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)

+static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
  {
unsigned char psr_version;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to get PSR version, disable it\n");
+   return ret;
+   }
  
-	drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);

dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
  
-	return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;

+   dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+
+   return 0;
  }
  
-static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)

+static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
  {
unsigned char psr_en;
+   int ret;
  
  	/* Disable psr function */

-   drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
+   ret = drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to get psr config\n");
+   goto end;
+   }
+
psr_en &= ~DP_PSR_ENABLE;
-   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to disable panel psr\n");
+   goto end;
+   }
  
  	/* Main-Link transmitter remains active during PSR active states */

psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
-   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to set panel psr\n");
+   goto end;
+   }
  
  	/* Enable psr function */

psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
 DP_PSR_CRC_VERIFICATION;
-   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to set panel psr\n");
+   goto end;
+   }
  
  	analogix_dp_enable_psr_crc(dp);

+
+   return 0;
+end:
+   dev_err(dp->dev, "enable psr fail, force to disable psr\n");
+   dp->psr_enable = false;
+
+   return ret;
  }
  
-static void

+static int
  analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
   bool enable)
  {
u8 data;
+   int ret;
  
-	drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );

+   ret = drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
+   if (ret != 1)
+   return ret;
  
  	if (enable)

-   drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
-  DP_LANE_COUNT_ENHANCED_FRAME_EN |
-   DPCD_LANE_COUNT_SET(data));
+   ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
+DP_LANE_COUNT_ENHANCED_FRAME_EN |
+DPCD_LANE_COUNT_SET(data));
else
-   drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
-  DPCD_LANE_COUNT_SET(data));
+   ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
+DPCD_LANE_CO

Re: [PATCH v5 15/36] drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

Enhanced mode is required by the eDP 1.2 specification, and not doing it
early could result in a period of time where we have a link transmitting
idle packets without it. Since there is no reason to disable it, we just
enable it at the beginning of link training and then keep it on all the
time.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: Tomasz Figa <tf...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6cbde8473f58..1eed35f9eb8d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -281,6 +281,8 @@ static int analogix_dp_link_start(struct analogix_dp_device 
*dp)
retval = drm_dp_dpcd_write(>aux, DP_LINK_BW_SET, buf, 2);
if (retval < 0)
return retval;
+   /* set enhanced mode if available */
+   analogix_dp_set_enhanced_mode(dp);
  
  	/* Set TX pre-emphasis to minimum */

for (lane = 0; lane < lane_count; lane++)
@@ -593,8 +595,6 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
dev_dbg(dp->dev, "fast link training %s\n",
dp->fast_train_enable ? "supported" : "unsupported");
  
-		/* set enhanced mode if available */

-   analogix_dp_set_enhanced_mode(dp);
dp->link_train.lt_state = FINISHED;
  
  		return 0;

@@ -940,8 +940,6 @@ static int analogix_dp_commit(struct analogix_dp_device *dp)
}
  
  	analogix_dp_enable_scramble(dp, 1);

-   analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
-   analogix_dp_enable_enhanced_mode(dp, 1);
  
  	analogix_dp_init_video(dp);

ret = analogix_dp_config_video(dp);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 14/36] drm/bridge: analogix_dp: Extend hpd check time to 100ms

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: Lin Huang <h...@rock-chips.com>

There was a 1ms delay to detect the hpd signal, which is too short to
detect a short pulse. This patch extends this delay to 100ms.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Stéphane Marchesin <marc...@chromium.org>
Cc: 征增 王 <w...@rock-chips.com>
Signed-off-by: Lin Huang <h...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3a222e7e46ee..6cbde8473f58 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -76,7 +76,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
  
  		timeout_loop++;

-   usleep_range(10, 11);
+   usleep_range(1000, 1100);
}
  
  	/*



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 13/36] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: Lin Huang <h...@rock-chips.com>

When panel is shut down, we should make sure edp can be disabled to avoid
undefined behavior.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: Stéphane Marchesin <marc...@chromium.org>
Signed-off-by: Lin Huang <h...@rock-chips.com>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 92fb9a072cb6..3a222e7e46ee 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1160,6 +1160,12 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
  
  	pm_runtime_get_sync(dp->dev);
  
+	ret = clk_prepare_enable(dp->clock);

+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+   goto out_dp_clk_pre;
+   }
+
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
  
@@ -1191,6 +1197,8 @@ static int analogix_dp_set_bridge(struct analogix_dp_device *dp)

phy_power_off(dp->phy);
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
+   clk_disable_unprepare(dp->clock);
+out_dp_clk_pre:
pm_runtime_put_sync(dp->dev);
  
  	return ret;

@@ -1233,11 +1241,14 @@ static void analogix_dp_bridge_disable(struct 
drm_bridge *bridge)
}
  
  	disable_irq(dp->irq);

+   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
phy_power_off(dp->phy);
  
  	if (dp->plat_data->power_off)

dp->plat_data->power_off(dp->plat_data);
  
+	clk_disable_unprepare(dp->clock);

+
pm_runtime_put_sync(dp->dev);
  
  	ret = analogix_dp_prepare_panel(dp, false, true);



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 12/36] drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

Following the correct power up sequence:
dp_pd=ff => dp_pd=7f => wait 10us => dp_pd=00



Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Stéphane Marchesin <marc...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |  3 +++
  2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index b47c5af43560..bb72f8b0e603 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -321,10 +321,16 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
break;
case POWER_ALL:
if (enable) {
-   reg = DP_PHY_PD | AUX_PD | CH3_PD | CH2_PD |
-   CH1_PD | CH0_PD;
+   reg = DP_ALL_PD;
writel(reg, dp->reg_base + phy_pd_addr);
} else {
+   reg = DP_ALL_PD;
+   writel(reg, dp->reg_base + phy_pd_addr);
+   usleep_range(10, 15);
+   reg &= ~DP_INC_BG;
+   writel(reg, dp->reg_base + phy_pd_addr);
+   usleep_range(10, 15);
+
writel(0x00, dp->reg_base + phy_pd_addr);
}
break;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 40200c652533..9602668669f4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -342,12 +342,15 @@
  #define DP_PLL_REF_BIT_1_2500V(0x7 << 0)
  
  /* ANALOGIX_DP_PHY_PD */

+#define DP_INC_BG  (0x1 << 7)
+#define DP_EXP_BG  (0x1 << 6)
  #define DP_PHY_PD (0x1 << 5)
  #define AUX_PD(0x1 << 4)
  #define CH3_PD(0x1 << 3)
  #define CH2_PD(0x1 << 2)
  #define CH1_PD(0x1 << 1)
  #define CH0_PD(0x1 << 0)
+#define DP_ALL_PD  (0xff)
  
  /* ANALOGIX_DP_PHY_TEST */

  #define MACRO_RST (0x1 << 5)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 11/36] drm/bridge: analogix_dp: Wait for HPD signal before configuring link

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker
must first detect that the HPD signal is asserted high by the Downstream
Device before establishing a link with it.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: Stéphane Marchesin <marc...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index c81733b8185e..92fb9a072cb6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1169,6 +1169,17 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
if (ret)
goto out_dp_init;
  
+	/*

+* According to DP spec v1.3 chap 3.5.1.2 Link Training,
+* We should first make sure the HPD signal is asserted high by device
+* when we want to establish a link with it.
+*/
+   ret = analogix_dp_detect_hpd(dp);
+   if (ret) {
+   DRM_ERROR("failed to get hpd single ret = %d\n", ret);
+   goto out_dp_init;
+   }
+
ret = analogix_dp_commit(dp);
if (ret)
goto out_dp_init;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 10/36] drm/bridge: analogix_dp: Retry bridge enable when it failed

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

When we enable bridge failed, we have to retry it, otherwise we would get
the abnormal display.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Stéphane Marchesin <marc...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 65 +-
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 +-
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  5 +-
  3 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index ea7a80a989c6..c81733b8185e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -43,8 +43,10 @@ struct bridge_init {
struct device_node *node;
  };
  
-static void analogix_dp_init_dp(struct analogix_dp_device *dp)

+static int analogix_dp_init_dp(struct analogix_dp_device *dp)
  {
+   int ret;
+
analogix_dp_reset(dp);
  
  	analogix_dp_swreset(dp);

@@ -56,10 +58,13 @@ static void analogix_dp_init_dp(struct analogix_dp_device 
*dp)
analogix_dp_enable_sw_function(dp);
  
  	analogix_dp_config_interrupt(dp);

-   analogix_dp_init_analog_func(dp);
+   ret = analogix_dp_init_analog_func(dp);
+   if (ret)
+   return ret;
  
  	analogix_dp_init_hpd(dp);

analogix_dp_init_aux(dp);
+   return 0;
  }
  
  static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)

@@ -918,7 +923,7 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void 
*arg)
return IRQ_HANDLED;
  }
  
-static void analogix_dp_commit(struct analogix_dp_device *dp)

+static int analogix_dp_commit(struct analogix_dp_device *dp)
  {
int ret;
  
@@ -928,11 +933,10 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)

DRM_ERROR("failed to disable the panel\n");
}
  
-	ret = readx_poll_timeout(analogix_dp_train_link, dp, ret, !ret, 100,

-DP_TIMEOUT_TRAINING_US * 5);
+   ret = analogix_dp_train_link(dp);
if (ret) {
dev_err(dp->dev, "unable to do link train, ret=%d\n", ret);
-   return;
+   return ret;
}
  
  	analogix_dp_enable_scramble(dp, 1);

@@ -953,6 +957,7 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
+   return 0;
  }
  
  /*

@@ -1149,12 +1154,9 @@ static void analogix_dp_bridge_pre_enable(struct 
drm_bridge *bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
  }
  
-static void analogix_dp_bridge_enable(struct drm_bridge *bridge)

+static int analogix_dp_set_bridge(struct analogix_dp_device *dp)
  {
-   struct analogix_dp_device *dp = bridge->driver_private;
-
-   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
-   return;
+   int ret;
  
  	pm_runtime_get_sync(dp->dev);
  
@@ -1162,11 +1164,46 @@ static void analogix_dp_bridge_enable(struct drm_bridge *bridge)

dp->plat_data->power_on(dp->plat_data);
  
  	phy_power_on(dp->phy);

-   analogix_dp_init_dp(dp);
+
+   ret = analogix_dp_init_dp(dp);
+   if (ret)
+   goto out_dp_init;
+
+   ret = analogix_dp_commit(dp);
+   if (ret)
+   goto out_dp_init;
+
enable_irq(dp->irq);
-   analogix_dp_commit(dp);
+   return 0;
  
-	dp->dpms_mode = DRM_MODE_DPMS_ON;

+out_dp_init:
+   phy_power_off(dp->phy);
+   if (dp->plat_data->power_off)
+   dp->plat_data->power_off(dp->plat_data);
+   pm_runtime_put_sync(dp->dev);
+
+   return ret;
+}
+
+static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   int timeout_loop = 0;
+
+   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
+   return;
+
+   while (timeout_loop < MAX_PLL_LOCK_LOOP) {
+   if (analogix_dp_set_bridge(dp) == 0) {
+   dp->dpms_mode = DRM_MODE_DPMS_ON;
+   return;
+   }
+   dev_err(dp->dev, "failed to set bridge, retry: %d\n",
+   timeout_loop);
+   timeout_loop++;
+   

Re: [PATCH v5 09/36] drm/bridge: analogix_dp: Don't use fast link training when panel just powered up

[Archit Taneja]

On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

Panel would reset its setting when it powers down. It would forget the last
succeeded link training setting. So we can't use the last successful link
training setting to do fast link training. Let's reset fast_train_enable in
analogix_dp_bridge_disable();



Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Stéphane Marchesin <marc...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
  2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f9661b410cb9..ea7a80a989c6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -579,14 +579,14 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
if (retval != 1) {
dev_err(dp->dev, "failed to read downspread %d\n",
retval);
-   dp->fast_train_support = false;
+   dp->fast_train_enable = false;
} else {
-   dp->fast_train_support =
+   dp->fast_train_enable =
(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
true : false;
}
dev_dbg(dp->dev, "fast link training %s\n",
-   dp->fast_train_support ? "supported" : "unsupported");
+   dp->fast_train_enable ? "supported" : "unsupported");
  
  		/* set enhanced mode if available */

analogix_dp_set_enhanced_mode(dp);
@@ -793,7 +793,7 @@ static int analogix_dp_fast_link_train(struct 
analogix_dp_device *dp)
  
  static int analogix_dp_train_link(struct analogix_dp_device *dp)

  {
-   if (dp->fast_train_support)
+   if (dp->fast_train_enable)
return analogix_dp_fast_link_train(dp);
  
  	return analogix_dp_full_link_train(dp, dp->video_info.max_lane_count,

@@ -1197,6 +1197,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
  
  	dp->psr_enable = false;

+   dp->fast_train_enable = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
  }
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h

index 6a96ef7e6934..403ff853464b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -173,7 +173,7 @@ struct analogix_dp_device {
int hpd_gpio;
boolforce_hpd;
boolpsr_enable;
-   boolfast_train_support;
+   boolfast_train_enable;
  
  	struct mutex		panel_lock;

boolpanel_is_modeset;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 08/36] drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: Lin Huang <h...@rock-chips.com>

We should check AUX_EN bit to confirm the AUX CH operation is completed.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Stéphane Marchesin <marc...@chromium.org>
Signed-off-by: Lin Huang <h...@rock-chips.com>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 25 +--
  1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 9df2f3ef000c..e78c861b9e06 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1073,9 +1073,9 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
  {
u32 reg;
u8 *buffer = msg->buffer;
-   int timeout_loop = 0;
unsigned int i;
int num_transferred = 0;
+   int ret;
  
  	/* Buffer size of AUX CH is 16 bytes */

if (WARN_ON(msg->size > 16))
@@ -1139,17 +1139,20 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
  
  	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
  
-	/* Is AUX CH command reply received? */

+   ret = readx_poll_timeout(readl, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2,
+reg, !(reg & AUX_EN), 25, 500 * 1000);
+   if (ret) {
+   dev_err(dp->dev, "AUX CH enable timeout!\n");
+   return -ETIMEDOUT;
+   }
+
/* TODO: Wait for an interrupt instead of looping? */
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   while (!(reg & RPLY_RECEIV)) {
-   timeout_loop++;
-   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "AUX CH command reply failed!\n");
-   return -ETIMEDOUT;
-   }
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   usleep_range(10, 11);
+   /* Is AUX CH command reply received? */
+   ret = readx_poll_timeout(readl, dp->reg_base + ANALOGIX_DP_INT_STA,
+reg, reg & RPLY_RECEIV, 10, 20 * 1000);
+   if (ret) {
+   dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
+   return -ETIMEDOUT;
}
  
  	/* Clear interrupt source for AUX CH command reply */



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 07/36] drm/bridge: analogix_dp: Move enable video into config_video()

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: Lin Huang 

We need to enable video before analogix_dp_is_video_stream_on(), so
we can get the right video stream status.

Cc: 征增 王 
Cc: Stéphane Marchesin 
Signed-off-by: Lin Huang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5a2e35dc41e3..f9661b410cb9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -819,11 +819,10 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
if (analogix_dp_is_slave_video_stream_clock_on(dp) == 0)
break;
if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "Timeout of video streamclk ok\n");
+   dev_err(dp->dev, "Timeout of slave video streamclk 
ok\n");
return -ETIMEDOUT;
}
-
-   usleep_range(1, 2);
+   usleep_range(1000, 1001);


Could we briefly explain in the commit message why we need to increase
the delay in the timeout loop? Is it a consequence of calling
analogix_dp_start_video() earlier, or is this the preferred time
mentioned in the specs?

Thanks,
Archit


}
  
  	/* Set to use the register calculated M/N video */

@@ -838,6 +837,9 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
/* Configure video slave mode */
analogix_dp_enable_video_master(dp, 0);
  
+	/* Enable video */

+   analogix_dp_start_video(dp);
+
timeout_loop = 0;
  
  	for (;;) {

@@ -948,9 +950,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to enable the panel\n");
}
  
-	/* Enable video */

-   analogix_dp_start_video(dp);
-
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

We currently wait for the panel to mirror our intended PSR state
before continuing on both PSR enter and PSR exit. This is really
only important to do when we're entering PSR, since we want to
be sure the last frame we pushed is being served from the panel's
internal fb before shutting down the soc blocks (vop/analogix).

This patch changes the behavior such that we only wait for the
panel to complete the PSR transition when we're entering PSR, and
to skip verification when we're exiting.



With the subject fix:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Cc: Stéphane Marchesin <marc...@chromium.org>
Cc: Sonny Rao <sonny...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 5 -
  3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 806c3878b3d6..5a2e35dc41e3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -125,7 +125,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
  
-	return analogix_dp_send_psr_spd(dp, _vsc);

+   return analogix_dp_send_psr_spd(dp, _vsc, true);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
  
@@ -151,7 +151,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)

if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
  
-	return analogix_dp_send_psr_spd(dp, _vsc);

+   return analogix_dp_send_psr_spd(dp, _vsc, false);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h

index 920607d7eb3e..6a96ef7e6934 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -253,7 +253,7 @@ void analogix_dp_enable_scrambling(struct 
analogix_dp_device *dp);
  void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
  void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
  int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc);
+struct edp_vsc_psr *vsc, bool blocking);
  ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c

index 005a3f7005d2..9df2f3ef000c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1007,7 +1007,7 @@ static ssize_t analogix_dp_get_psr_status(struct 
analogix_dp_device *dp)
  }
  
  int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,

-struct edp_vsc_psr *vsc)
+struct edp_vsc_psr *vsc, bool blocking)
  {
unsigned int val;
int ret;
@@ -1053,6 +1053,9 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
  
+	if (!blocking)

+   return 0;
+
ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
psr_status >= 0 &&
((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

We would meet a short black screen when exit PSR with the full link
training, In this case, we should use fast link train instead of full
link training.

Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 142 -
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   3 +
  2 files changed, 114 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index ee00d3d920e0..806c3878b3d6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -10,17 +10,18 @@
  * option) any later version.
  */
  
-#include 

-#include 
-#include 
  #include 
-#include 
+#include 
+#include 
+#include 
  #include 
+#include 
+#include 
+#include 
  #include 
  #include 
-#include 
-#include 
  #include 
+#include 


This re-ordering doesn't seem like it should be a part of this patch,
you can let it stay if it happens to cause conflicts with future
patches. Other than that:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit

  
  #include 

  #include 
@@ -35,6 +36,8 @@
  
  #define to_dp(nm)	container_of(nm, struct analogix_dp_device, nm)
  
+static const bool verify_fast_training;

+
  struct bridge_init {
struct i2c_client *client;
struct device_node *node;
@@ -528,7 +531,7 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
  {
int lane, lane_count, retval;
u32 reg;
-   u8 link_align, link_status[2], adjust_request[2];
+   u8 link_align, link_status[2], adjust_request[2], spread;
  
  	usleep_range(400, 401);
  
@@ -571,6 +574,20 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)

dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
  
+		retval = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD,

+  );
+   if (retval != 1) {
+   dev_err(dp->dev, "failed to read downspread %d\n",
+   retval);
+   dp->fast_train_support = false;
+   } else {
+   dp->fast_train_support =
+   (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
+   true : false;
+   }
+   dev_dbg(dp->dev, "fast link training %s\n",
+   dp->fast_train_support ? "supported" : "unsupported");
+
/* set enhanced mode if available */
analogix_dp_set_enhanced_mode(dp);
dp->link_train.lt_state = FINISHED;
@@ -627,10 +644,12 @@ static void analogix_dp_get_max_rx_lane_count(struct 
analogix_dp_device *dp,
*lane_count = DPCD_MAX_LANE_COUNT(data);
  }
  
-static void analogix_dp_init_training(struct analogix_dp_device *dp,

- enum link_lane_count_type max_lane,
- int max_rate)
+static int analogix_dp_full_link_train(struct analogix_dp_device *dp,
+  u32 max_lanes, u32 max_rate)
  {
+   int retval = 0;
+   bool training_finished = false;
+
/*
 * MACRO_RST must be applied after the PLL_LOCK to avoid
 * the DP inter pair skew issue for at least 10 us
@@ -656,18 +675,13 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
}
  
  	/* Setup TX lane count & rate */

-   if (dp->link_train.lane_count > max_lane)
-   dp->link_train.lane_count = max_lane;
+   if (dp->link_train.lane_count > max_lanes)
+   dp->link_train.lane_count = max_lanes;
if (dp->link_train.link_rate > max_rate)
dp->link_train.link_rate = max_rate;
  
  	/* All DP analog module power up */

analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);
-}
-
-static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
-{
-   int retval = 0, training_finished = 0;
  
  	dp->link_train.lt_state = START;
  
@@ -702,22 +716,88 @@ static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)

return retval;
  }
  
-static int analogix_dp_set_link_train(struct analogix_dp_device *dp,

- u32 count, u32 bwtype)
+static i

Re: [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: zain wang <w...@rock-chips.com>

There is a race between AUX CH bring-up and enabling bridge which will
cause link training to fail. To avoid hitting it, don't change psr state
while enabling the bridge.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Cc: Tomeu Vizoso <tomeu.viz...@collabora.com>
Cc: Sean Paul <seanp...@chromium.org>
Signed-off-by: zain wang <w...@rock-chips.com>
Signed-off-by: Caesar Wang <w...@rock-chips.com>
[seanpaul fixed up the commit message a bit and renamed *_supported to 
*_enabled]
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 ---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 +-
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  2 +-
  include/drm/bridge/analogix_dp.h   |  2 +-
  4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e738aa6de1af..ee00d3d920e0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,18 +98,18 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
  }
  
-int analogix_dp_psr_supported(struct analogix_dp_device *dp)

+int analogix_dp_psr_enabled(struct analogix_dp_device *dp)
  {
  
-	return dp->psr_support;

+   return dp->psr_enable;
  }
-EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
+EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
  
  int analogix_dp_enable_psr(struct analogix_dp_device *dp)

  {
struct edp_vsc_psr psr_vsc;
  
-	if (!dp->psr_support)

+   if (!dp->psr_enable)
return 0;
  
  	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */

@@ -131,7 +131,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
struct edp_vsc_psr psr_vsc;
int ret;
  
-	if (!dp->psr_support)

+   if (!dp->psr_enable)
return 0;
  
  	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */

@@ -871,8 +871,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
/* Enable video */
analogix_dp_start_video(dp);
  
-	dp->psr_support = analogix_dp_detect_sink_psr(dp);

-   if (dp->psr_support)
+   dp->psr_enable = analogix_dp_detect_sink_psr(dp);
+   if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
  }
  
@@ -1117,6 +1117,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)

if (ret)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
  
+	dp->psr_enable = false;

dp->dpms_mode = DRM_MODE_DPMS_OFF;
  }
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h

index b039b28d8fcc..e135a42cb19e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -170,7 +170,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
-   boolpsr_support;
+   boolpsr_enable;
  
  	struct mutex		panel_lock;

boolpanel_is_modeset;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 36334839a3f8..3e8bf79bea58 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -82,7 +82,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, 
bool enabled)
struct rockchip_dp_device *dp = to_dp(encoder);
int ret;
  
-	if (!analogix_dp_psr_supported(dp->adp))

+   if (!analogix_dp_psr_enabled(dp->adp))
return;
  
  	DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");

diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 711fff9b6803..e9a1116d2f8e 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -41,7 +41,7 @@ struct analogix_dp_plat_data {
 struct drm_connector *);
  };
  
-int analogix_dp_psr_supported(struct analogix_dp_device *dp);

+int analogix_dp_psr_enabled(struct analogix_dp_device *dp);
  int analogix_dp_enable_psr(struct analogix_dp_device *dp);
  int analogix_dp_disable_psr(struct analogix_dp_device *dp);
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: Yakir Yang <y...@rock-chips.com>

Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Cc: 征增 王 <w...@rock-chips.com>
Cc: Stéphane Marchesin <marc...@chromium.org>
Signed-off-by: Yakir Yang <y...@rock-chips.com>
[seanpaul changed timeout loop to a readx poll]
Signed-off-by: Sean Paul <seanp...@chromium.org>
Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  6 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 35 +++---
  3 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a693ab3078f0..e738aa6de1af 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -122,8 +122,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
  
-	analogix_dp_send_psr_spd(dp, _vsc);

-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
  
@@ -149,8 +148,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)

if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
  
-	analogix_dp_send_psr_spd(dp, _vsc);

-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h

index 5c6a28806129..b039b28d8fcc 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,8 @@
  #define MAX_CR_LOOP 5
  #define MAX_EQ_LOOP 5
  
+#define DP_TIMEOUT_PSR_LOOP_MS			300

+
  /* DP_MAX_LANE_COUNT */
  #define DPCD_ENHANCED_FRAME_CAP(x)(((x) >> 7) & 0x1)
  #define DPCD_MAX_LANE_COUNT(x)((x) & 0x1f)
@@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp);
  void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
  void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
  void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);
  ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c

index 303083ad28e3..005a3f7005d2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -10,10 +10,11 @@
   * option) any later version.
   */
  
-#include 

-#include 
  #include 
+#include 
  #include 
+#include 
+#include 
  
  #include 
  
@@ -992,10 +993,25 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp)

writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
  }
  
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,

- struct edp_vsc_psr *vsc)
+static ssize_t analogix_dp_get_psr_status(struct analogix_dp_device *dp)
+{
+   ssize_t val;
+   u8 status;
+
+   val = drm_dp_dpcd_readb(>aux, DP_PSR_STATUS, );
+   if (val < 0) {
+   dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
+   return val;
+   }
+   return status;
+}
+
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
  {
unsigned int val;
+   int ret;
+   ssize_t psr_status;
  
  	/* don't send info frame */

val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1036,6 +1052,17 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+   ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
+   psr_status >= 0 &&
+   ((vs

Re: [PATCH 4/5] drm/msm/dsi: implement 6G v2.0+ DSI command broadcast

[Archit Taneja]

On Monday 12 March 2018 06:53 PM, Sibi S wrote:

From: Archit Taneja <arch...@codeaurora.org>



I'm a bit uncertain about using this patch in its current state.
Some reasons below.


Add command broadcast support for DSI 6G v2.0+ controller
on SDM845

Signed-off-by: Sibi S <si...@codeaurora.org>
---
  drivers/gpu/drm/msm/dsi/dsi.h |  5 +++
  drivers/gpu/drm/msm/dsi/dsi_cfg.c | 14 +++-
  drivers/gpu/drm/msm/dsi/dsi_host.c| 62 ++--
  drivers/gpu/drm/msm/dsi/dsi_manager.c | 66 +++
  4 files changed, 143 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index dfa049d..22342c30 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -96,7 +96,9 @@ struct msm_dsi {
  struct drm_connector *msm_dsi_manager_connector_init(u8 id);
  struct drm_connector *msm_dsi_manager_ext_bridge_init(u8 id);
  int msm_dsi_manager_cmd_xfer(int id, const struct mipi_dsi_msg *msg);
+int msm_dsi_manager_cmd_xfer_6g_v2(int id, const struct mipi_dsi_msg *msg);
  bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base, u32 len);
+bool msm_dsi_manager_cmd_xfer_trigger_6g_v2(int id, u32 dma_base, u32 len);
  void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
  int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
  void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
@@ -152,6 +154,9 @@ static inline int msm_dsi_pll_set_usecase(struct 
msm_dsi_pll *pll,
  struct msm_dsi_host;
  int msm_dsi_host_xfer_prepare(struct mipi_dsi_host *host,
const struct mipi_dsi_msg *msg);
+int msm_dsi_host_xfer_prepare_6g_v2(struct mipi_dsi_host *host,
+   const struct mipi_dsi_msg *msg,
+   bool broadcast, bool master);
  void msm_dsi_host_xfer_restore(struct mipi_dsi_host *host,
const struct mipi_dsi_msg *msg);
  int msm_dsi_host_cmd_tx(struct mipi_dsi_host *host,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index dc51aaa..dcdfb1b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -157,6 +157,18 @@
.dma_base_get = dsi_dma_base_get_6g,
.calc_clk_rate = dsi_calc_clk_rate_6g,
  };
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
+   .link_clk_enable = dsi_link_clk_enable_6g,
+   .link_clk_disable = dsi_link_clk_disable_6g,
+   .clk_init_ver = dsi_clk_init_6g_v2,
+   .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+   .tx_buf_get = dsi_tx_buf_get_6g,
+   .tx_buf_put = dsi_tx_buf_put_6g,
+   .dma_base_get = dsi_dma_base_get_6g,
+   .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
  static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
{MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064,
_dsi_cfg, _dsi_v2_host_ops},
@@ -175,7 +187,7 @@
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1,
_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
-   _dsi_cfg, _dsi_6g_host_ops},
+   _dsi_cfg, _dsi_6g_v2_host_ops},
  };
  
  const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index b755b69..bd61cad 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1251,9 +1251,14 @@ static int dsi_cmd_dma_tx(struct msm_dsi_host *msm_host, 
int len)
reinit_completion(_host->dma_comp);
  
  	dsi_wait4video_eng_busy(msm_host);

+   if ((cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) &&
+   (cfg_hnd->minor < MSM_DSI_6G_VER_MINOR_V2_2_1))
+   triggered = msm_dsi_manager_cmd_xfer_trigger(msm_host->id,
+   dma_base, len);
+   else
+   triggered = msm_dsi_manager_cmd_xfer_trigger_6g_v2(
+ msm_host->id, dma_base, len);
  
-	triggered = msm_dsi_manager_cmd_xfer_trigger(

-   msm_host->id, dma_base, len);
if (triggered) {
ret = wait_for_completion_timeout(_host->dma_comp,
msecs_to_jiffies(200));
@@ -1602,13 +1607,21 @@ static ssize_t dsi_host_transfer(struct mipi_dsi_host 
*host,
const struct mipi_dsi_msg *msg)
  {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
int ret;
  
  	if (!msg || !msm_host->power_on)

return -EINVAL;
  
  	mutex_lock(_host->cmd_mutex);

-   ret = msm_dsi_manager_cmd_xf

Re: [PATCH 3/5] drm/msm/dsi: replace version checks with helper functions

[Archit Taneja]

On Monday 12 March 2018 06:53 PM, Sibi S wrote:

Replace version checks with the helper functions bound to
cfg_handler for DSI v2 and DSI 6G 1.x controllers



With the ops set up for DSI6G 2.x too:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


Signed-off-by: Sibi S <si...@codeaurora.org>
---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 242 +
  1 file changed, 29 insertions(+), 213 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index f7a066d..b755b69 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -426,19 +426,6 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
  
-	if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G &&

-   cfg_hnd->minor >= MSM_DSI_6G_VER_MINOR_V2_2_1) {
-   msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
-   if (IS_ERR(msm_host->byte_intf_clk)) {
-   ret = PTR_ERR(msm_host->byte_intf_clk);
-   pr_err("%s: can't find byte_intf clock. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-   } else {
-   msm_host->byte_intf_clk = NULL;
-   }
-
msm_host->byte_clk_src = clk_get_parent(msm_host->byte_clk);
if (!msm_host->byte_clk_src) {
ret = -ENODEV;
@@ -453,31 +440,8 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
  
-	if (cfg_hnd->major == MSM_DSI_VER_MAJOR_V2) {

-   msm_host->src_clk = msm_clk_get(pdev, "src");
-   if (IS_ERR(msm_host->src_clk)) {
-   ret = PTR_ERR(msm_host->src_clk);
-   pr_err("%s: can't find src clock. ret=%d\n",
-   __func__, ret);
-   msm_host->src_clk = NULL;
-   goto exit;
-   }
-
-   msm_host->esc_clk_src = clk_get_parent(msm_host->esc_clk);
-   if (!msm_host->esc_clk_src) {
-   ret = -ENODEV;
-   pr_err("%s: can't get esc clock parent. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-
-   msm_host->dsi_clk_src = clk_get_parent(msm_host->src_clk);
-   if (!msm_host->dsi_clk_src) {
-   ret = -ENODEV;
-   pr_err("%s: can't get src clock parent. ret=%d\n",
-   __func__, ret);
-   }
-   }
+   if (cfg_hnd->ops->clk_init_ver)
+   ret = cfg_hnd->ops->clk_init_ver(msm_host);
  exit:
return ret;
  }
@@ -681,16 +645,6 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
return ret;
  }
  
-static int dsi_link_clk_enable(struct msm_dsi_host *msm_host)

-{
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G)
-   return dsi_link_clk_enable_6g(msm_host);
-   else
-   return dsi_link_clk_enable_v2(msm_host);
-}
-
  void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
  {
clk_disable_unprepare(msm_host->esc_clk);
@@ -708,24 +662,6 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
  }
  
-static void dsi_link_clk_disable(struct msm_dsi_host *msm_host)

-{
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
-   clk_disable_unprepare(msm_host->esc_clk);
-   clk_disable_unprepare(msm_host->pixel_clk);
-   if (msm_host->byte_intf_clk)
-   clk_disable_unprepare(msm_host->byte_intf_clk);
-   clk_disable_unprepare(msm_host->byte_clk);
-   } else {
-   clk_disable_unprepare(msm_host->pixel_clk);
-   clk_disable_unprepare(msm_host->src_clk);
-   clk_disable_unprepare(msm_host->esc_clk);
-   clk_disable_unprepare(msm_host->byte_clk);
-   }
-}
-
  int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host)
  {
struct drm_display_mode *mode = msm_host->mode;
@@ -814,73 +750,6 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host)
return 0;
  }
  
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)

-{
-   struct drm_display_mode *mode = msm_host->mode;
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-   u8 lanes = msm_host->lanes;
-   u32 bpp = dsi_get_bpp(msm_host->format);
-   u32 pclk_rate;
-
-   if

Re: [Freedreno] [PATCH 2/5] drm/msm/dsi: add implementation for helper functions

[Archit Taneja]

On Monday 12 March 2018 06:53 PM, Sibi S wrote:

Add dsi host helper function implementation for DSI v2
and DSI 6G 1.x controllers

Signed-off-by: Sibi S 
---
  drivers/gpu/drm/msm/dsi/dsi.h  |  15 +++
  drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  44 +--
  drivers/gpu/drm/msm/dsi/dsi_host.c | 250 -
  3 files changed, 298 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 80be83e..dfa049d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -183,6 +183,21 @@ int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
  int msm_dsi_host_init(struct msm_dsi *msm_dsi);
  int msm_dsi_runtime_suspend(struct device *dev);
  int msm_dsi_runtime_resume(struct device *dev);
+int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
+int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
+int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
+void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
+void *dsi_tx_buf_get_v2(struct msm_dsi_host *msm_host);
+void dsi_tx_buf_put_6g(struct msm_dsi_host *msm_host);
+int dsi_dma_base_get_6g(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_dma_base_get_v2(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_clk_init_v2(struct msm_dsi_host *msm_host);
+int dsi_clk_init_6g_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host);
  
  /* dsi phy */

  struct msm_dsi_phy;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 0327bb5..dc51aaa 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -136,20 +136,46 @@
.num_dsi = 2,
  };
  
+const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {

+   .link_clk_enable = dsi_link_clk_enable_v2,
+   .link_clk_disable = dsi_link_clk_disable_v2,
+   .clk_init_ver = dsi_clk_init_v2,
+   .tx_buf_alloc = dsi_tx_buf_alloc_v2,
+   .tx_buf_get = dsi_tx_buf_get_v2,
+   .tx_buf_put = NULL,
+   .dma_base_get = dsi_dma_base_get_v2,
+   .calc_clk_rate = dsi_calc_clk_rate_v2,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_host_ops = {
+   .link_clk_enable = dsi_link_clk_enable_6g,
+   .link_clk_disable = dsi_link_clk_disable_6g,
+   .clk_init_ver = NULL,
+   .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+   .tx_buf_get = dsi_tx_buf_get_6g,
+   .tx_buf_put = dsi_tx_buf_put_6g,
+   .dma_base_get = dsi_dma_base_get_6g,
+   .calc_clk_rate = dsi_calc_clk_rate_6g,
+};


Could you introduce the host ops for SDM845 (i.e,
msm_dsi_6g_v2_host_ops) in this patch itself? It would be nice to
keep the DSI command broadcast code as a separate patch since it
probably needs to go through more iterations.

The ops approach looks good otherwise.

Thanks,
Archit


  static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
-   {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, _dsi_cfg},
+   {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064,
+   _dsi_cfg, _dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_2,
-   _apq8084_dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, _dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
+   _dsi_cfg, _dsi_6g_host_ops},
  };
  
  const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 

Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge

[Archit Taneja]

Hi,

On Friday 09 March 2018 07:21 PM, Jacopo Mondi wrote:

Hello,
after some discussion on the proposed bindings for generic lvds decoder and
Thine THC63LVD1024, I decided to drop the THC63 specific part and just live with
a transparent decoder that does not support any configuration from DT.

Dropping THC63 support to avoid discussion on how to better implement support
for a DRM bridge with 2 input ports and focus on LVDS mode propagation through
bridges as explained in v1 cover letter (for DRM people: please see [1] as why
I find difficult to implement support for bridges with multiple input endpoints)

Same base branch as v1, with same patches for V3M Eagle applied on top.
git://jmondi.org/linux v3m/v4.16-rc3/base

Thanks
j

v1 -> v2:
- Drop support for THC63LVD1024

[1] I had a quick at how to model a DRM bridge with multiple input
ports, and I see a blocker in how DRM identifies and matches bridges using
the devices node in place of the endpoint nodes.

As THC63LVD1024 supports up to 2 LVDS inputs and 2 LVDS outputs, I see only
a few ways to support that:
  1) register 2 drm bridges from the same driver (one for each input/output 
pair)
 but they would both be matches on the same device node when the preceding
 bridge calls "of_drm_find_bridge()".


I think this is the way to go. DRM doesn't say anywhere that we can't 
have 2 drm_bridge-s contained in a single device. About the issue with

of_drm_find_bridge(), if you set the 2 bridge's 'of_node' field to
the bridge1 and bridge2 nodes as shown below, wouldn't that suffice. 
From what I know, we don't necessarily need to set the bridge's of_node

to the device (i.e, thschip) itself.

thschip {
...
ports {
bridge1: port@0 {
...
};

bridge2: port@1 {
...
};
};
};


Thanks,
Archit


  2) register a single bridge with multiple "next bridges", but when the bridge
 gets attached I don't see a way on how to identify on which next bridge
 "drm_bridge_attach()" on, as it depends on the endpoint the current bridge
 has been attached on first, and we don't have that information.
  3) Register more instances of the same chip in DTS, one for each input/output
 pair. They gonna share supplies and gpios, and I don't like that.

I had a quick look at the currently in mainline bridges and none of them has
multiple input endpoints, except for HDMI audio endpoint, which I haven't found
in use in any DTS. I guess the problem has been already debated and maybe solved
in the past, so feel free to point me to other sources.

Jacopo Mondi (3):
   dt-bindings: display: bridge: Document LVDS to parallel decoder
   drm: bridge: Add LVDS decoder driver
   arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

  .../bindings/display/bridge/lvds-decoder.txt   |  42 ++
  arch/arm64/boot/dts/renesas/r8a77970-eagle.dts |  31 +++-
  drivers/gpu/drm/bridge/Kconfig |   8 ++
  drivers/gpu/drm/bridge/Makefile|   1 +
  drivers/gpu/drm/bridge/lvds-decoder.c  | 157 +
  5 files changed, 237 insertions(+), 2 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt
  create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c

--
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [[RFC]DPU PATCH] drm/msm/dsi: Use one connector for dual DSI mode

[Archit Taneja]

On Friday 02 March 2018 05:57 AM, chand...@codeaurora.org wrote:

On 2018-03-01 07:53, Sean Paul wrote:

On Wed, Feb 28, 2018 at 04:44:49PM -0800, Chandan Uddaraju wrote:

Current DSI driver uses two connectors for dual DSI case even
though we only have one panel. Fix this by implementing one
connector/bridge for dual DSI use case.

Current patch is not yet tested on dual-dsi setup.


This seems like something that might benefit from being part of a 
patch series
that can be tested end-to-end (ie: a patch series to add full dual-dsi 
support
to the dsi driver). It's kind of hard to see where things are going 
with just

this one small piece.



This is more like a initial patch to get early comments/suggestions
regarding this approach on the DSI upstream driver.
We are working on enabling dual-dsi using DPU with upstream dsi driver.
This change will be based on archit's dual DSI changes on SDM845.
Once we have verified, we will post all the relevant patches along with 
this one.


The approach of entirely bypassing msm_dsi_modeset_init() for DSI1 
sounds like a decent idea. However, this may not work well if we need to 
dynamically switch between dual DSI mode vs operating the 2 DSIs

independently. If we don't have this use case in mind, then we should
be okay.

Another approach could be to create 2 separate bridge/connectors for
irrespective of whether we are in dual DSI mode or not, but report one
of the pairs as unavailable (connector's detect() should report 
disconnected).






Signed-off-by: Chandan Uddaraju 
---
 drivers/gpu/drm/msm/dsi/dsi.c |   3 +
 drivers/gpu/drm/msm/dsi/dsi.h |   1 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 100 
+++---

 3 files changed, 24 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c 
b/drivers/gpu/drm/msm/dsi/dsi.c

index b744bcc..ff8164c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,6 +208,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, 
struct drm_device *dev,

 goto fail;
 }

+    if (!msm_dsi_manager_validate_current_config(msm_dsi->id))
+    goto fail;
+
 msm_dsi->encoder = encoder;

 msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h 
b/drivers/gpu/drm/msm/dsi/dsi.h

index 70d9a9a..2d9763f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -100,6 +100,7 @@ struct msm_dsi {
 void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
 int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
 void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
+bool msm_dsi_manager_validate_current_config(u8 id);

 /* msm dsi */
 static inline bool msm_dsi_device_connected(struct msm_dsi *msm_dsi)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c

index 4cb1cb6..bf92f25 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -305,67 +305,6 @@ static void dsi_mgr_connector_destroy(struct 
drm_connector *connector)

 kfree(dsi_connector);
 }

-static void dsi_dual_connector_fix_modes(struct drm_connector 
*connector)

-{
-    struct drm_display_mode *mode, *m;
-
-    /* Only support left-right mode */
-    list_for_each_entry_safe(mode, m, >probed_modes, head) {
-    mode->clock >>= 1;
-    mode->hdisplay >>= 1;
-    mode->hsync_start >>= 1;
-    mode->hsync_end >>= 1;
-    mode->htotal >>= 1;
-    drm_mode_set_name(mode);
-    }
-}
-
-static int dsi_dual_connector_tile_init(
-    struct drm_connector *connector, int id)
-{
-    struct drm_display_mode *mode;
-    /* Fake topology id */
-    char topo_id[8] = {'M', 'S', 'M', 'D', 'U', 'D', 'S', 'I'};
-
-    if (connector->tile_group) {
-    DBG("Tile property has been initialized");
-    return 0;
-    }
-
-    /* Use the first mode only for now */
-    mode = list_first_entry(>probed_modes,
-    struct drm_display_mode,
-    head);
-    if (!mode)
-    return -EINVAL;
-
-    connector->tile_group = drm_mode_get_tile_group(
-    connector->dev, topo_id);
-    if (!connector->tile_group)
-    connector->tile_group = drm_mode_create_tile_group(
-    connector->dev, topo_id);
-    if (!connector->tile_group) {
-    pr_err("%s: failed to create tile group\n", __func__);
-    return -ENOMEM;
-    }
-
-    connector->has_tile = true;
-    connector->tile_is_single_monitor = true;
-
-    /* mode has been fixed */
-    connector->tile_h_size = mode->hdisplay;
-    connector->tile_v_size = mode->vdisplay;
-
-    /* Only support left-right mode */
-    connector->num_h_tile = 2;
-    connector->num_v_tile = 1;
-
-    connector->tile_v_loc = 0;
-    connector->tile_h_loc = (id == DSI_RIGHT) ? 1 : 0;
-
-    return 0;
-}
-
 static int dsi_mgr_connector_get_modes(struct drm_connector 

Re: [PATCH] drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs

[Archit Taneja]

Hi,

On Tuesday 06 March 2018 03:23 PM, Neil Armstrong wrote:

Hi Architt,

On 23/02/2018 12:44, Neil Armstrong wrote:

The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
identified needing this workaround.
This patch adds the corresponding version to enable a single iteration for
this specific version.

Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based on 
device version")
Signed-off-by: Neil Armstrong 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40..f5018f9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1637,6 +1637,8 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 * (and possibly on the platform). So far only i.MX6Q (v1.30a) and
 * i.MX6DL (v1.31a) have been identified as needing the workaround, with
 * 4 and 1 iterations respectively.
+* The Amlogic Meson GX SoCs (v2.01a) have been identifies as needing
+* the workaround with a single iteration.


s/identifies/identified


 */
  
  	switch (hdmi->version) {

@@ -1644,6 +1646,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+   case 0x201a:
count = 1;
break;
default:



This fixes a long time issue on Amlogic SoCs, is it ok for you ?


Looks good to me. Feel free to queue it to drm-misc-next.

Thanks,
Archit



Thanks,
Neil


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: of: simplify component probe code

[Archit Taneja]

On Tuesday 06 March 2018 01:46 PM, Philipp Zabel wrote:

On Thu, 2018-02-22 at 21:22 +0200, Baruch Siach wrote:

Use positive logic for better readability. This also eliminates one
of_node_put() call, making the code shorter.

Signed-off-by: Baruch Siach 


Reviewed-by: Philipp Zabel 
Tested-by: Philipp Zabel 



queued to drm-misc-next after fixing a minor checkpatch
warning.

Thanks,
Archit


regards
Philipp


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

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 4c191c050e7d..fa354d14127b 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -122,12 +122,10 @@ int drm_of_component_probe(struct device *dev,
if (!port)
break;
  
-		if (!of_device_is_available(port->parent)) {

-   of_node_put(port);
-   continue;
-   }
+   if (of_device_is_available(port->parent))
+   drm_of_component_match_add(dev, , compare_of,
+   port);
  
-		drm_of_component_match_add(dev, , compare_of, port);

of_node_put(port);
}
  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Archit Taneja]

On Tuesday 27 February 2018 06:26 PM, Ville Syrjala wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
splitting the structure up into static and dynamic parts.

The static part will consist of subpixel_order, panel_orientation,
and bus_formats.

Actually I'm not sure where bus_formats & co. fit in all this. For some
drivers those seem to be static, even though they might fill them out
from .get_modes(). For other drivers this stuff even gets frobbed at
runtime, making it more some kind of a bastard encoder/connector state.
I'll just stick it into the static side so that the behaviour doesn't
change when I start clear out the entire dynamic state with memset().



[...]

  
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c

index b1ab4ab09532..abd0bce9c31e 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -174,7 +174,7 @@ static int sii902x_get_modes(struct drm_connector 
*connector)
kfree(edid);
}
  
-	ret = drm_display_info_set_bus_formats(>display_info,

+   ret = drm_display_info_set_bus_formats(>static_display_info,
   _format, 1);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 08ab7d6aea65..042ded9ca749 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1193,7 +1193,7 @@ static int tc_bridge_attach(struct drm_bridge *bridge)
if (tc->panel)
drm_panel_attach(tc->panel, >connector);
  
-	drm_display_info_set_bus_formats(>connector.display_info,

+   drm_display_info_set_bus_formats(>connector.static_display_info,
 _format, 1);
drm_mode_connector_attach_encoder(>connector, tc->bridge.encoder);
  


The sii902x driver sets the bus_formats in get_modes, but it's a fixed 
value and we may as well do it in bridge's attach op.


For the bridge drivers:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC

[Archit Taneja]

On Tuesday 20 February 2018 04:44 PM, Archit Taneja wrote:



On Tuesday 20 February 2018 03:59 PM, Thierry Reding wrote:

From: Thierry Reding <tred...@nvidia.com>

DRM_DUMB_VGA_DAC is a user-visible symbol. Selecting it can cause unmet
direct dependencies such as this (on i386, randconfig):

warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet 
direct dependencies (HAS_IOMEM && DRM && DRM_BRIDGE && OF)


This is because DRM_DUMB_VGA_DAC depends on OF while DRM_PL111 does not.
It does indirectly depend on OF via the ARM and ARM64 dependencies, but
since it can also be enabled under COMPILE_TEST, randconfig can find a
case where DRM_PL111 is selected without pulling in OF and not meeting
the dependency for DRM_DUMB_VGA_DAC.

Since select is "heavy handed", DRM_DUMB_VGA_DAC is going to be enabled
regardless of the above warning and causes the following build error:

../drivers/gpu/drm/bridge/dumb-vga-dac.c: In function 
'dumb_vga_probe':
../drivers/gpu/drm/bridge/dumb-vga-dac.c:207:13: error: 'struct 
drm_bridge' has no member named 'of_node'

  vga->bridge.of_node = pdev->dev.of_node;

See Documentation/kbuild/kconfig-language.txt, "reverse dependencies".


+Linus.

I guess this needs to go in drm-misc-fixes once it is updated to
4.16-rc2.


Looks like this was headed for 4.17, it isn't a part of 4.16. Queued to 
drm-misc-next.


Thanks,
Archit



Thanks,
Archit



Fixes: 49f81d80ab84 ("drm/pl111: Support handling bridge timings")
Reported-by: Randy Dunlap <rdun...@infradead.org>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Archit Taneja <arch...@codeaurora.org>
Cc: Eric Anholt <e...@anholt.net>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
  drivers/gpu/drm/pl111/Kconfig | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/Kconfig 
b/drivers/gpu/drm/pl111/Kconfig

index 82cb3e60ddc8..e5e2abd66491 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -8,7 +8,6 @@ config DRM_PL111
  select DRM_GEM_CMA_HELPER
  select DRM_BRIDGE
  select DRM_PANEL_BRIDGE
-    select DRM_DUMB_VGA_DAC
  select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
  help
    Choose this option for DRM support for the PL111 CLCD controller.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC

[Archit Taneja]

On Tuesday 20 February 2018 03:59 PM, Thierry Reding wrote:

From: Thierry Reding <tred...@nvidia.com>

DRM_DUMB_VGA_DAC is a user-visible symbol. Selecting it can cause unmet
direct dependencies such as this (on i386, randconfig):

warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet direct dependencies (HAS_IOMEM 
&& DRM && DRM_BRIDGE && OF)

This is because DRM_DUMB_VGA_DAC depends on OF while DRM_PL111 does not.
It does indirectly depend on OF via the ARM and ARM64 dependencies, but
since it can also be enabled under COMPILE_TEST, randconfig can find a
case where DRM_PL111 is selected without pulling in OF and not meeting
the dependency for DRM_DUMB_VGA_DAC.

Since select is "heavy handed", DRM_DUMB_VGA_DAC is going to be enabled
regardless of the above warning and causes the following build error:

../drivers/gpu/drm/bridge/dumb-vga-dac.c: In function 'dumb_vga_probe':
../drivers/gpu/drm/bridge/dumb-vga-dac.c:207:13: error: 'struct 
drm_bridge' has no member named 'of_node'
  vga->bridge.of_node = pdev->dev.of_node;

See Documentation/kbuild/kconfig-language.txt, "reverse dependencies".


+Linus.

I guess this needs to go in drm-misc-fixes once it is updated to
4.16-rc2.

Thanks,
Archit



Fixes: 49f81d80ab84 ("drm/pl111: Support handling bridge timings")
Reported-by: Randy Dunlap <rdun...@infradead.org>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Archit Taneja <arch...@codeaurora.org>
Cc: Eric Anholt <e...@anholt.net>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
  drivers/gpu/drm/pl111/Kconfig | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index 82cb3e60ddc8..e5e2abd66491 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -8,7 +8,6 @@ config DRM_PL111
select DRM_GEM_CMA_HELPER
select DRM_BRIDGE
select DRM_PANEL_BRIDGE
-   select DRM_DUMB_VGA_DAC
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
help
  Choose this option for DRM support for the PL111 CLCD controller.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

dw_hdmi shouldn't set drvdata since some drivers might need to store
it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
instead to store it in drvdata. This way drivers are responsible to
store and pass structure when needed.

Idea was taken from the following commit:
8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Cc: p.za...@pengutronix.de
Cc: narmstr...@baylibre.com
Cc: laurent.pinch...@ideasonboard.com
Cc: h...@rock-chips.com
Cc: he...@sntech.de
Acked-by: Neil Armstrong <narmstr...@baylibre.com>
Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net>
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 31 -
  drivers/gpu/drm/imx/dw_hdmi-imx.c   | 13 +---
  drivers/gpu/drm/meson/meson_dw_hdmi.c   | 14 +
  drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 12 +--
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +---
  include/drm/bridge/dw_hdmi.h| 13 ++--
  6 files changed, 60 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7d80f4b56683..f9802399cc0d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2543,8 +2543,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
  
-	platform_set_drvdata(pdev, hdmi);

-
return hdmi;
  
  err_iahb:

@@ -2594,25 +2592,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
  /* 
-
   * Probe/remove API, used from platforms based on the DRM bridge API.
   */
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
  {
struct dw_hdmi *hdmi;
  
  	hdmi = __dw_hdmi_probe(pdev, plat_data);

if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
  
  	drm_bridge_add(>bridge);
  
-	return 0;

+   return hdmi;
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_probe);
  
-void dw_hdmi_remove(struct platform_device *pdev)

+void dw_hdmi_remove(struct dw_hdmi *hdmi)
  {
-   struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(>bridge);
  
  	__dw_hdmi_remove(hdmi);

@@ -2622,31 +2618,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
  /* 
-
   * Bind/unbind API, used from platforms based on the component framework.
   */
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
  {
struct dw_hdmi *hdmi;
int ret;
  
  	hdmi = __dw_hdmi_probe(pdev, plat_data);

if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
  
  	ret = drm_bridge_attach(encoder, >bridge, NULL);

if (ret) {
-   dw_hdmi_remove(pdev);
+   dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-   return ret;
+   return ERR_PTR(ret);
}
  
-	return 0;

+   return hdmi;
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_bind);
  
-void dw_hdmi_unbind(struct device *dev)

+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
  {
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..fe6becdcc29e 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -25,6 +25,7 @@
  struct imx_hdmi {
struct device *dev;
struct drm_encoder encoder;
+   struct dw_hdmi *hdmi;
struct regmap *regmap;
  };
  
@@ -239,14 +240,18 @@ static int dw_hdmi_imx_bind(struct device *dev, struct device *master,

drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
  
-	ret = dw_hdmi_bind(pdev, encoder, plat_data);

+   platform_set_drvdata(pdev, hdmi);
+
+   hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
  
  	/*

 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
 * which would have called the encoder cleanup.  Do it manually.
 */
-   if (ret)
+   if (IS_ERR(hdmi->hdmi)) {
+   ret = PTR_ERR(

Re: [PATCH v5 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.

Functions exported here are actually not specific to Synopsys PHYs but
to DWC HDMI controller PHY interface. This means that even if the PHY is
completely custom, i.e. not designed by Synopsys, exported functions can
be useful.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net>
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +--
  drivers/gpu/drm/meson/meson_dw_hdmi.c |  8 +++---
  include/drm/bridge/dw_hdmi.h  | 11 
  3 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..7d80f4b56683 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi 
*hdmi, u8 enable)
 HDMI_PHY_CONF0_SVSRET_MASK);
  }
  
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
 HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
  
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
 HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
  
  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)

  {
@@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
  }
  
+void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)

+{
+   /* PHY reset. The reset signal is active high on Gen2 PHYs. */
+   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
+   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
+
+void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
+{
+   hdmi_phy_test_clear(hdmi, 1);
+   hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
+   hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
+
  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
  {
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
  
-	/* PHY reset. The reset signal is active high on Gen2 PHYs. */

-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
-   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+   dw_hdmi_phy_reset(hdmi);
  
  	hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
  
-	hdmi_phy_test_clear(hdmi, 1);

-   hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
-   HDMI_PHY_I2CM_SLAVE_ADDR);
-   hdmi_phy_test_clear(hdmi, 0);
+   dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
  
  	/* Write to the PHY as configured by the platform */

if (pdata->configure_phy)
@@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
void *data)
dw_hdmi_phy_power_off(hdmi);
  }
  
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,

- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data)
  {
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
  
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

-  bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+   bool force, bool disabled, bool rxsense)
  {
u8 old_mask = hdmi->phy_mask;
  
@@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy

Re: [PATCH v5 03/12] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.

Tests show that one iteration is enough.

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>


Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net>
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7ca14d7325b5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 * then write one of the FC registers several times.
 *
 * The number of iterations matters and depends on the HDMI TX revision
-* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
-* i.MX6DL (v1.31a) have been identified as needing the workaround, with
-* 4 and 1 iterations respectively.
+* (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+* (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+* as needing the workaround, with 4 iterations for v1.30a and 1
+* iteration for others.
 */
  
  	switch (hdmi->version) {

@@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+   case 0x132a:
count = 1;
break;
default:


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7] dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY

[Archit Taneja]

On 01/31/2018 09:50 PM, Rob Clark wrote:

On Wed, Jan 31, 2018 at 1:40 AM, Archit Taneja <arch...@codeaurora.org> wrote:



On 01/29/2018 10:45 PM, Rob Herring wrote:


On Wed, Jan 17, 2018 at 03:04:47PM +0530, Archit Taneja wrote:


Add the compatible string for 14nm DSI PHY (used in MSM8996/APQ8096).
  From 14nm PHY onwards, the "dsi_phy_regulator" reg-name is not required,
but "dsi_phy_lane" reg-name is. Update the doc to specify the reg-names
each PHY revision needs.

Cc: Rob Herring <r...@kernel.org>
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
   Documentation/devicetree/bindings/display/msm/dsi.txt | 13
+++--
   1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 9c3ad6bbb9f0..26a1796b7145 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -86,12 +86,19 @@ Required properties:
 * "qcom,dsi-phy-28nm-lp"
 * "qcom,dsi-phy-20nm"
 * "qcom,dsi-phy-28nm-8960"
-- reg: Physical base address and length of the registers of PLL, PHY and
PHY
-  regulator
+  * "qcom,dsi-phy-14nm"
+- reg: Physical base address and length of the registers of PLL, PHY.
Some
+  revisions require the PHY regulator base address, whereas others
require the
+  PHY lane base address. See below for each PHY revision.
   - reg-names: The names of register regions. The following regions are
required:
+  For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY:
 * "dsi_pll"
 * "dsi_phy"
 * "dsi_phy_regulator"
+  For DSI 14nm PHY:
+  * "dsi_pll"
+  * "dsi_phy"
+  * "dsi_phy_lane"
   - clock-cells: Must be 1. The DSI PHY block acts as a clock provider,
creating
 2 clocks: A byte clock (index 0), and a pixel clock (index 1).
   - power-domains: Should be < MDSS_GDSC>.
@@ -102,6 +109,8 @@ Required properties:
   - vddio-supply: phandle to vdd-io regulator device node
 For 20nm PHY:
   - vddio-supply: phandle to vdd-io regulator device node
+- vcca-supply: phandle to vcca regulator device node



Did you mean to add this?



Yes, I didn't intend it to be a part of this patch, but this supply is
indeed needed for the
20nm PHY. I'll move this to a separate patch.


actually, this looks correct, just formatted counter-intuitively by
git-format-patch..

vcca-supply for 20nm was introduced by "dt-bindings: display: msm/dsi:
Fix the PHY regulator supply props", but when 14nm phy is added in
this patch, it shows the addition of same line beneath 14nm PHY as an
addition above the line.

So I don't think it needs to be split up.


Oh yeah, you're right. I guess this is okay as is, then.

Thanks,
Archit



BR,
-R


Thanks,
Archit





+  For 14nm PHY:
   - vcca-supply: phandle to vcca regulator device node
 Optional properties:
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
hosted by The Linux Foundation



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7] dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY

[Archit Taneja]

On 01/29/2018 10:45 PM, Rob Herring wrote:

On Wed, Jan 17, 2018 at 03:04:47PM +0530, Archit Taneja wrote:

Add the compatible string for 14nm DSI PHY (used in MSM8996/APQ8096).
 From 14nm PHY onwards, the "dsi_phy_regulator" reg-name is not required,
but "dsi_phy_lane" reg-name is. Update the doc to specify the reg-names
each PHY revision needs.

Cc: Rob Herring <r...@kernel.org>
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
  Documentation/devicetree/bindings/display/msm/dsi.txt | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 9c3ad6bbb9f0..26a1796b7145 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -86,12 +86,19 @@ Required properties:
* "qcom,dsi-phy-28nm-lp"
* "qcom,dsi-phy-20nm"
* "qcom,dsi-phy-28nm-8960"
-- reg: Physical base address and length of the registers of PLL, PHY and PHY
-  regulator
+  * "qcom,dsi-phy-14nm"
+- reg: Physical base address and length of the registers of PLL, PHY. Some
+  revisions require the PHY regulator base address, whereas others require the
+  PHY lane base address. See below for each PHY revision.
  - reg-names: The names of register regions. The following regions are 
required:
+  For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY:
* "dsi_pll"
* "dsi_phy"
* "dsi_phy_regulator"
+  For DSI 14nm PHY:
+  * "dsi_pll"
+  * "dsi_phy"
+  * "dsi_phy_lane"
  - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating
2 clocks: A byte clock (index 0), and a pixel clock (index 1).
  - power-domains: Should be < MDSS_GDSC>.
@@ -102,6 +109,8 @@ Required properties:
  - vddio-supply: phandle to vdd-io regulator device node
For 20nm PHY:
  - vddio-supply: phandle to vdd-io regulator device node
+- vcca-supply: phandle to vcca regulator device node


Did you mean to add this?


Yes, I didn't intend it to be a part of this patch, but this supply is indeed 
needed for the
20nm PHY. I'll move this to a separate patch.

Thanks,
Archit




+  For 14nm PHY:
  - vcca-supply: phandle to vcca regulator device node
  
  Optional properties:

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read requests

[Archit Taneja]

On 01/26/2018 06:14 AM, Brian Norris wrote:

On Thu, Jan 25, 2018 at 11:37:59AM +0100, Philippe Cornu wrote:

The dcs/generic dsi read feature is not yet implemented so it
is important to warn the host_transfer() caller in case of
read operation requests.

Signed-off-by: Philippe Cornu 


Awesome, thanks.

Reviewed-by: Brian Norris 



Queued to drm-misc-next.

Thanks,
Archit


---
  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index daec7881be6d..72ecaeb40822 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -405,6 +405,12 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
struct mipi_dsi_packet packet;
int ret;
  
+	if (msg->rx_buf || msg->rx_len) {

+   /* TODO dw drv improvements: implement read feature */
+   dev_warn(dsi->dev, "read operations not yet implemented\n");
+   return -EINVAL;
+   }
+
ret = mipi_dsi_create_packet(, msg);
if (ret) {
dev_err(dsi->dev, "failed to create packet: %d\n", ret);
--
2.15.1



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value

[Archit Taneja]

On 01/26/2018 06:16 AM, Brian Norris wrote:

On Thu, Jan 25, 2018 at 11:38:00AM +0100, Philippe Cornu wrote:

The dw_mipi_dsi_host_transfer() must return the number of
bytes transmitted/received on success instead of 0.
Note: As the read feature is not implemented, only the
transmitted number of bytes is returned for the moment.

Signed-off-by: Philippe Cornu 


Assuming we're going with the current documented semantics (where we
return # of TX bytes for writes), then:

Reviewed-by: Brian Norris 

I believe Archit was suggesting maybe changing that sometime, but that's
no excuse for not matching documentation now.


Queued to drm-misc-next.

Thanks,
Archit




---
  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 72ecaeb40822..090bf62d1ea8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -419,7 +419,16 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
  
  	dw_mipi_message_config(dsi, msg);
  
-	return dw_mipi_dsi_write(dsi, );

+   ret = dw_mipi_dsi_write(dsi, );
+   if (ret)
+   return ret;
+
+   /*
+* TODO Only transmitted size is returned as actual driver does
+* not support dcs/generic reads. Please update return value when
+* delivering the read feature.
+*/
+   return packet.size;


You're really holding my hand here, I see :) Thanks I guess.


  }
  
  static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {

--
2.15.1



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set

[Archit Taneja]

On 01/26/2018 03:24 PM, Philippe CORNU wrote:

Hi Brian,
And a big thanks for your Tested-by

On 01/25/2018 11:47 PM, Brian Norris wrote:

On Thu, Jan 25, 2018 at 7:55 AM, Philippe Cornu  wrote:

The "adjusted_mode" clock value (ie the real pixel clock) is more
accurate than "mode" clock value (ie the panel/bridge requested
clock value). It offers a better preciseness for timing
computations and allows to reduce the extra dsi bandwidth in
burst mode (from ~20% to ~10-12%, hw platform dependant).

Signed-off-by: Philippe Cornu 
---
Note: This patch replaces "drm/bridge/synopsys: dsi: add optional pixel clock"


These two appear to be the same for my cases, but at least nothing breaks:



In drivers/gpu/drm/rockchip/rockchip_drm_vop.c function
vop_crtc_mode_fixup(), the adjusted_mode->clock (ie. vop px clk output =
dw dsi px clk input) is updated according to rockchip hw pll/dividers...

So you "may" have a different value in adjusted_mode->clock compare to
mode->clock. Maybe there is no difference for the panel you are using
because its px clock matches perfectly with rockchip hw pll/dividers...
or has been set to match with ;-)

I did a similar patch (see [1]) and it works "fine" on stm, the only
difference with the rockchip vop is that clk_round_rate() returns odd
values on stm so I used set/get_rate instead.

So now, both rockchip & stm crtc have an "adjusted_mode->clock" so it
makes sense to use it in dw dsi :)


Could you get the patch [1] queued on drm-misc-next? I can queue this patch
after it.

Thanks,
Archit



Philippe :-)

[1] https://patchwork.freedesktop.org/patch/200720/
"[PATCH] drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock"



Tested-by: Brian Norris 




___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Archit Taneja]

Hi,

On 01/22/2018 06:20 PM, Kieran Bingham wrote:

The ADV7511 has four 256-byte maps that can be accessed via the main I²C
ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.

Signed-off-by: Kieran Bingham 
---
  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 ++
  3 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 0047b1394c70..f6bb9f6d3f48 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -70,6 +70,9 @@ Optional properties:
rather than generate its own timings for HDMI output.
  - clocks: from common clock binding: reference to the CEC clock.
  - clock-names: from common clock binding: must be "cec".
+- reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are : "main", "edid", "cec", "packet"
  
  Required nodes:
  
@@ -88,7 +91,12 @@ Example
  
  	adv7511w: hdmi@39 {

compatible = "adi,adv7511w";
-   reg = <39>;
+   /*
+* The EDID page will be accessible on address 0x66 on the i2c
+* bus. All other maps continue to use their default addresses.
+*/
+   reg = <0x39 0x66>;
+   reg-names = "main", "edid";
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <_clock>;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index d034b2cb5eee..7d81ce3808e0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -53,8 +53,10 @@
  #define ADV7511_REG_POWER 0x41
  #define ADV7511_REG_STATUS0x42
  #define ADV7511_REG_EDID_I2C_ADDR 0x43
+#define ADV7511_REG_EDID_I2C_ADDR_DEFAULT  0x3f
  #define ADV7511_REG_PACKET_ENABLE10x44
  #define ADV7511_REG_PACKET_I2C_ADDR   0x45
+#define ADV7511_REG_PACKET_I2C_ADDR_DEFAULT0x38
  #define ADV7511_REG_DSD_ENABLE0x46
  #define ADV7511_REG_VIDEO_INPUT_CFG2  0x48
  #define ADV7511_REG_INFOFRAME_UPDATE  0x4a
@@ -89,6 +91,7 @@
  #define ADV7511_REG_TMDS_CLOCK_INV0xde
  #define ADV7511_REG_ARC_CTRL  0xdf
  #define ADV7511_REG_CEC_I2C_ADDR  0xe1
+#define ADV7511_REG_CEC_I2C_ADDR_DEFAULT   0x3c


Minor comment: The defines above make look like new register
defines. It would be nice to remove the "REG_" from them, and
place them somewhere after the register definitions.


  #define ADV7511_REG_CEC_CTRL  0xe2
  #define ADV7511_REG_CHIP_ID_HIGH  0xf5
  #define ADV7511_REG_CHIP_ID_LOW   0xf6
@@ -322,6 +325,7 @@ struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
struct i2c_client *i2c_cec;
+   struct i2c_client *i2c_packet;
  
  	struct regmap *regmap;

struct regmap *regmap_cec;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index efa29db5fc2b..7ec33837752b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -969,8 +969,8 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
  {
int ret;
  
-	adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,

-adv->i2c_main->addr - 1);


This patch avoids deriving the CEC/EDID map addresses from the main map. I think this would break 
what the original patch tried to do:


d25a4cbba4b9da7c2d674b2f8ecf84af1b24988e
"drm/bridge: adv7511: add support for the 2nd chip"

Maybe the default macros can be a function of the main address?



+   adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
+   ADV7511_REG_CEC_I2C_ADDR_DEFAULT);


Also, I'm a bit unclear on the default address values. For example, previously, 
the CEC
address was calculated as "adv->i2c_main->addr - 1", which is 0x38. The new 
CEC_I2C_ADDR_DEFAULT
define sets it to 0x3c.

Thanks,
Archit


if (!adv->i2c_cec)
return -ENOMEM;
i2c_set_clientdata(adv->i2c_cec, adv);
@@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)

Re: [PATCH 08/12] drm: msm: Use drm_atomic_helper_shutdown() to disable planes on removal

[Archit Taneja]

On 01/18/2018 03:25 AM, Laurent Pinchart wrote:

The plane cleanup handler currently calls drm_plane_helper_disable(),
which is a legacy helper function. Replace it with a call to
drm_atomic_helper_shutdown() at removal time.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 1 -
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 1 -
  drivers/gpu/drm/msm/msm_drv.c | 1 +
  3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index 7a1ad3af08e3..db356d22ef15 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -68,7 +68,6 @@ static void mdp4_plane_destroy(struct drm_plane *plane)
  {
struct mdp4_plane *mdp4_plane = to_mdp4_plane(plane);
  
-	drm_plane_helper_disable(plane);

drm_plane_cleanup(plane);
  
  	kfree(mdp4_plane);

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 29678876fc09..986684e33a03 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -46,7 +46,6 @@ static void mdp5_plane_destroy(struct drm_plane *plane)
  {
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
  
-	drm_plane_helper_disable(plane);

drm_plane_cleanup(plane);
  
  	kfree(mdp5_plane);

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d90ef1d78a1b..4ba48e5acbe9 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -233,6 +233,7 @@ static int msm_drm_uninit(struct device *dev)
if (fbdev && priv->fbdev)
msm_fbdev_free(ddev);
  #endif
+   drm_atomic_helper_shutdown(ddev);
drm_mode_config_cleanup(ddev);
  
  	pm_runtime_get_sync(dev);




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v2 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus

[Archit Taneja]

Add a section that describes dt-bindings for peripherals that support
MIPI DSI, but have a different bus as the primary control bus, or no
control bus at all. Add an example for a peripheral with a non-DSI
control bus.

Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
v2:
- Mentioned what to do if peripheral has no control bus
- Drop unit-address and #*-cells where applicable.

 .../devicetree/bindings/display/mipi-dsi-bus.txt   | 71 +++---
 1 file changed, 64 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 973c27273772..94fb72cb916f 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -16,7 +16,7 @@ The following assumes that only a single peripheral is 
connected to a DSI
 host. Experience shows that this is true for the large majority of setups.
 
 DSI host
-
+
 
 In addition to the standard properties and those defined by the parent bus of
 a DSI host, the following properties apply to a node representing a DSI host.
@@ -30,11 +30,16 @@ Required properties:
   different value here. See below.
 
 DSI peripheral
---
+==
 
-Peripherals are represented as child nodes of the DSI host's node. Properties
-described here apply to all DSI peripherals, but individual bindings may want
-to define additional, device-specific properties.
+Peripherals with DSI as control bus, or no control bus
+--
+
+Peripherals with the DSI bus as the primary control bus, or peripherals with
+no control bus but use the DSI bus to transmit pixel data are represented
+as child nodes of the DSI host's node. Properties described here apply to all
+DSI peripherals, but individual bindings may want to define additional,
+device-specific properties.
 
 Required properties:
 - reg: The virtual channel number of a DSI peripheral. Must be in the range
@@ -49,9 +54,25 @@ case two alternative representations can be chosen:
   property is the number of the first virtual channel and the second cell is
   the number of consecutive virtual channels.
 
-Example

+Peripherals with a different control bus
+
+
+There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
+primary control bus, but are also connected to a DSI bus (mostly for the data
+path). Connections between such peripherals and a DSI host can be represented
+using the graph bindings [1], [2].
+
+[1] Documentation/devicetree/bindings/graph.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
 
+Examples
+
+- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
+  with different virtual channel configurations.
+- (4) is an example of a peripheral on a I2C control bus connected with to
+  a DSI host using of-graph bindings.
+
+1)
dsi-host {
...
 
@@ -67,6 +88,7 @@ Example
...
};
 
+2)
dsi-host {
...
 
@@ -82,6 +104,7 @@ Example
...
};
 
+3)
dsi-host {
...
 
@@ -96,3 +119,37 @@ Example
 
...
};
+
+4)
+   i2c-host {
+   ...
+
+   dsi-bridge@35 {
+   compatible = "...";
+   reg = <0x35>;
+
+   ports {
+   ...
+
+   port {
+   bridge_mipi_in: endpoint {
+   remote-endpoint = 
<_mipi_out>;
+   };
+   };
+   };
+   };
+   };
+
+   dsi-host {
+   ...
+
+   ports {
+   ...
+
+   port {
+   host_mipi_out: endpoint {
+   remote-endpoint = <_mipi_in>;
+   };
+   };
+   };
+   };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Archit Taneja]

Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.

Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
v2:
- Specify that clock-master is a boolean property.
- Drop/add unit-address and #*-cells where applicable.

 .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80 ++
 1 file changed, 80 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 94fb72cb916f..7a3abbedb3fa 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,13 @@ Required properties:
 - #size-cells: Should be 0. There are cases where it makes sense to use a
   different value here. See below.
 
+Optional properties:
+- clock-master: boolean. Should be enabled if the host is being used in
+  conjunction with another DSI host to drive the same peripheral. Hardware
+  supporting such a configuration generally requires the data on both the 
busses
+  to be driven by the same clock. Only the DSI host instance controlling this
+  clock should contain this property.
+
 DSI peripheral
 ==
 
@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus 
(mostly for the data
 path). Connections between such peripherals and a DSI host can be represented
 using the graph bindings [1], [2].
 
+Peripherals that support dual channel DSI
+-
+
+Peripherals with higher bandwidth requirements can be connected to 2 DSI
+busses. Each DSI bus/channel drives some portion of the pixel data (generally
+left/right half of each line of the display, or even/odd lines of the display).
+The graph bindings should be used to represent the multiple DSI busses that are
+connected to this peripheral. Each DSI host's output endpoint can be linked to
+an input endpoint of the DSI peripheral.
+
 [1] Documentation/devicetree/bindings/graph.txt
 [2] Documentation/devicetree/bindings/media/video-interfaces.txt
 
@@ -71,6 +88,8 @@ Examples
   with different virtual channel configurations.
 - (4) is an example of a peripheral on a I2C control bus connected with to
   a DSI host using of-graph bindings.
+- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
+  which uses I2C as its primary control bus.
 
 1)
dsi-host {
@@ -153,3 +172,64 @@ Examples
};
};
};
+
+5)
+   i2c-host {
+   dsi-bridge@35 {
+   compatible = "...";
+   reg = <0x35>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi0_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi1_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+   };
+
+   dsi0-host {
+   ...
+
+   /*
+* this DSI instance drives the clock for both the host
+* controllers
+*/
+   clock-master;
+
+   ports {
+   ...
+
+   port {
+   dsi0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   dsi1-host {
+   ...
+
+   ports {
+   ...
+
+   port {
+   dsi1_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v2 0/2] dt-bindings: mipi-dsi: dual-channel DSI bindings

[Archit Taneja]

DSI host controllers these days can be ganged together to drive larger
displays. Every SoC vendor supporting this is trying to add their own
DT property so that the corresponding drivers can identify that they
need to operate in the dual DSI mode. If we use the graph bindings, we
don't really need an additional DT property in the DSI host controller
to tell it that it's operating in dual-channel mode. It's something that
can be inferred 

I don't know much about how dual-channel is implemented on anything apart
from MSM chipsets, but one thing that seems universal is that the clock
driving both the DSI controllers (and corresponding PHYs) should have the
same clock source. The DSI instance that drives this clock is generally
called the "master", and the other instance the "slave". A "clock-master"
DT property has been proposed for the same.

There are some open item(s) that aren't described in the mipi DSI/DCS
spec, but we might need to have either as bindings or some sort of DSI
flags:

- When sending commands over DSI to peripherals with 2 DSI channels,
  some peripherals seem to have a requirement that both the DSIs trigger
  the same command at the same time. Otherwise, the controller on the
  peripheral goes a bit nuts. Is this common to all peripherals? Or are
  there devices where we just need to send the DCS/generic commands to
  the "master" DSI channel?

- When trying to read something back from the panel (a DCS read command
  followed by a BTA etc.), should both the DSI controllers be listening
  for data, or only the master?

- Anything else?

The first patch adds some explanation on how to deal with peripherals
that do DSI, but have a different control bus. This is something we've
already started using, but didn't have properly documented anywhere.

The second patch proposes bindings for DSI hosts/peripherals that
implement dual-channel DSI. 

Changes in v2:
- Incorported Rob's comments.

Archit Taneja (2):
  dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control
bus
  dt-bindings: mipi-dsi: Add dual-channel DSI related info

 .../devicetree/bindings/display/mipi-dsi-bus.txt   | 153 +++--
 1 file changed, 145 insertions(+), 8 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] dt-bindings: display: msm/dsi: Add updates for SDM845

[Archit Taneja]

SDM845 uses a newer revision (v2.0+) of the 6G DSI controller. This
revision has another clock input at the block boundary called the byte
interface clock. Specify this new clock in the binding.

A 10nm DSI PHY is used along with the controller. Add a compatible
string for it and specify its base address/regulator supply needs.

Cc: Rob Herring <r...@kernel.org>
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 26a1796b7145..518e9cdf0d4b 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -20,6 +20,8 @@ Required properties:
   * "core"
   For DSIv2, we need an additional clock:
* "src"
+  For DSI6G v2.0 onwards, we need also need the clock:
+   * "byte_intf"
 - assigned-clocks: Parents of "byte" and "pixel" for the given platform.
 - assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided
   by a DSI PHY block. See [1] for details on clock bindings.
@@ -87,6 +89,7 @@ Required properties:
   * "qcom,dsi-phy-20nm"
   * "qcom,dsi-phy-28nm-8960"
   * "qcom,dsi-phy-14nm"
+  * "qcom,dsi-phy-10nm"
 - reg: Physical base address and length of the registers of PLL, PHY. Some
   revisions require the PHY regulator base address, whereas others require the
   PHY lane base address. See below for each PHY revision.
@@ -95,7 +98,7 @@ Required properties:
   * "dsi_pll"
   * "dsi_phy"
   * "dsi_phy_regulator"
-  For DSI 14nm PHY:
+  For DSI 14nm and 10nm PHYs:
   * "dsi_pll"
   * "dsi_phy"
   * "dsi_phy_lane"
@@ -112,6 +115,8 @@ Required properties:
 - vcca-supply: phandle to vcca regulator device node
   For 14nm PHY:
 - vcca-supply: phandle to vcca regulator device node
+  For 10nm PHY:
+- vdds-supply: phandle to vdds regulator device node
 
 Optional properties:
 - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7] drm/msm/dsi: Add byte_intf_clk

[Archit Taneja]

DSI6G v2.0+ blocks have a new clock input to them called
byte_intf_clk. It's rate is to be set as byte_clk / 2.

Within the clock controller (CC) subsystem, this clock is a
child/descendant of the byte_clk.

Set it up as an optional clock in the DSI host driver. Make sure
that we enable/set its rate only after we configure byte_clk.
This is required for the ancestor clocks in the CC to be
configured correctly.

Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7611fe014036..f675975c2655 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -115,6 +115,7 @@ struct msm_dsi_host {
struct clk *pixel_clk;
struct clk *byte_clk_src;
struct clk *pixel_clk_src;
+   struct clk *byte_intf_clk;
 
u32 byte_clk_rate;
u32 esc_clk_rate;
@@ -377,6 +378,14 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
 
+   msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
+   if (IS_ERR(msm_host->byte_intf_clk)) {
+   ret = PTR_ERR(msm_host->byte_intf_clk);
+   pr_debug("%s: can't find byte_intf clock. ret=%d\n",
+__func__, ret);
+   msm_host->byte_intf_clk = NULL;
+   }
+
msm_host->byte_clk_src = clk_get_parent(msm_host->byte_clk);
if (!msm_host->byte_clk_src) {
ret = -ENODEV;
@@ -502,6 +511,16 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
*msm_host)
goto error;
}
 
+   if (msm_host->byte_intf_clk) {
+   ret = clk_set_rate(msm_host->byte_intf_clk,
+  msm_host->byte_clk_rate / 2);
+   if (ret) {
+   pr_err("%s: Failed to set rate byte intf clk, %d\n",
+  __func__, ret);
+   goto error;
+   }
+   }
+
ret = clk_prepare_enable(msm_host->esc_clk);
if (ret) {
pr_err("%s: Failed to enable dsi esc clk\n", __func__);
@@ -520,8 +539,19 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
*msm_host)
goto pixel_clk_err;
}
 
+   if (msm_host->byte_intf_clk) {
+   ret = clk_prepare_enable(msm_host->byte_intf_clk);
+   if (ret) {
+   pr_err("%s: Failed to enable byte intf clk\n",
+  __func__);
+   goto byte_intf_clk_err;
+   }
+   }
+
return 0;
 
+byte_intf_clk_err:
+   clk_disable_unprepare(msm_host->pixel_clk);
 pixel_clk_err:
clk_disable_unprepare(msm_host->byte_clk);
 byte_clk_err:
@@ -615,6 +645,8 @@ static void dsi_link_clk_disable(struct msm_dsi_host 
*msm_host)
if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
clk_disable_unprepare(msm_host->esc_clk);
clk_disable_unprepare(msm_host->pixel_clk);
+   if (msm_host->byte_intf_clk)
+   clk_disable_unprepare(msm_host->byte_intf_clk);
clk_disable_unprepare(msm_host->byte_clk);
} else {
clk_disable_unprepare(msm_host->pixel_clk);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] dt-bindings: display: msm/dsi: Remove unused properties

[Archit Taneja]

"qcom,dsi-host-index" and "qcom,dsi-phy-index" DT props aren't
acceptable and have never been used in any DT files. Remove them.

Cc: Rob Herring <r...@kernel.org>
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 4 
 1 file changed, 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index a6671bd2c85a..457c688736be 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -7,8 +7,6 @@ Required properties:
 - reg: Physical base address and length of the registers of controller
 - reg-names: The names of register regions. The following regions are required:
   * "dsi_ctrl"
-- qcom,dsi-host-index: The ID of DSI controller hardware instance. This should
-  be 0 or 1, since we have 2 DSI controllers at most for now.
 - interrupts: The interrupt signal from the DSI block.
 - power-domains: Should be < MDSS_GDSC>.
 - clocks: Phandles to device clocks.
@@ -96,8 +94,6 @@ Required properties:
   * "dsi_phy_regulator"
 - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating
   2 clocks: A byte clock (index 0), and a pixel clock (index 1).
-- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
-  be 0 or 1, since we have 2 DSI PHYs at most for now.
 - power-domains: Should be < MDSS_GDSC>.
 - clocks: Phandles to device clocks. See [1] for details on clock bindings.
 - clock-names: the following clocks are required:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY

[Archit Taneja]

Add the compatible string for 14nm DSI PHY (used in MSM8996/APQ8096).
From 14nm PHY onwards, the "dsi_phy_regulator" reg-name is not required,
but "dsi_phy_lane" reg-name is. Update the doc to specify the reg-names
each PHY revision needs.

Cc: Rob Herring <r...@kernel.org>
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 9c3ad6bbb9f0..26a1796b7145 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -86,12 +86,19 @@ Required properties:
   * "qcom,dsi-phy-28nm-lp"
   * "qcom,dsi-phy-20nm"
   * "qcom,dsi-phy-28nm-8960"
-- reg: Physical base address and length of the registers of PLL, PHY and PHY
-  regulator
+  * "qcom,dsi-phy-14nm"
+- reg: Physical base address and length of the registers of PLL, PHY. Some
+  revisions require the PHY regulator base address, whereas others require the
+  PHY lane base address. See below for each PHY revision.
 - reg-names: The names of register regions. The following regions are required:
+  For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY:
   * "dsi_pll"
   * "dsi_phy"
   * "dsi_phy_regulator"
+  For DSI 14nm PHY:
+  * "dsi_pll"
+  * "dsi_phy"
+  * "dsi_phy_lane"
 - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating
   2 clocks: A byte clock (index 0), and a pixel clock (index 1).
 - power-domains: Should be < MDSS_GDSC>.
@@ -102,6 +109,8 @@ Required properties:
 - vddio-supply: phandle to vdd-io regulator device node
   For 20nm PHY:
 - vddio-supply: phandle to vdd-io regulator device node
+- vcca-supply: phandle to vcca regulator device node
+  For 14nm PHY:
 - vcca-supply: phandle to vcca regulator device node
 
 Optional properties:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] dt-bindings: display: msm/dsi: Fix the PHY regulator supply props

[Archit Taneja]

The PHY regulator supply names vary across different PHY versions.
Mention explicitly which PHYs require which supplies.

Cc: Rob Herring <r...@kernel.org>
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 457c688736be..9c3ad6bbb9f0 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -98,7 +98,11 @@ Required properties:
 - clocks: Phandles to device clocks. See [1] for details on clock bindings.
 - clock-names: the following clocks are required:
   * "iface"
+  For 28nm HPM/LP, 28nm 8960 PHYs:
 - vddio-supply: phandle to vdd-io regulator device node
+  For 20nm PHY:
+- vddio-supply: phandle to vdd-io regulator device node
+- vcca-supply: phandle to vcca regulator device node
 
 Optional properties:
 - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/msm/dsi: Use msm_clk_get in dsi_get_config

[Archit Taneja]

We try to get the interface clock in dsi_get_config early during DSI's
component bind. Try getting both the "iface" and "iface_clk" clock name
variants so that we are compatible with both new and legacy DT.

Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 0f7324a686ca..7611fe014036 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -214,7 +214,7 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
goto exit;
}
 
-   ahb_clk = clk_get(dev, "iface_clk");
+   ahb_clk = msm_clk_get(msm_host->pdev, "iface");
if (IS_ERR(ahb_clk)) {
pr_err("%s: cannot get interface clock\n", __func__);
goto put_gdsc;
@@ -225,7 +225,7 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
ret = regulator_enable(gdsc_reg);
if (ret) {
pr_err("%s: unable to enable gdsc\n", __func__);
-   goto put_clk;
+   goto put_gdsc;
}
 
ret = clk_prepare_enable(ahb_clk);
@@ -249,8 +249,6 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
 disable_gdsc:
regulator_disable(gdsc_reg);
pm_runtime_put_sync(dev);
-put_clk:
-   clk_put(ahb_clk);
 put_gdsc:
regulator_put(gdsc_reg);
 exit:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7] drm/msm/dsi: SDM845 DSI host controller and DT updates

[Archit Taneja]

This series adds some of the host controller changes needed for SDM845.\
The DT patches in the series do some minor clean ups and add missing
bindings for 14nm DSI PHY (8x96) and new bindings for 10nm PHY.

Archit Taneja (7):
  drm/msm/dsi: Use msm_clk_get in dsi_get_config
  drm/msm/dsi: Add SDM845 in dsi_cfg
  drm/msm/dsi: Add byte_intf_clk
  dt-bindings: display: msm/dsi: Remove unused properties
  dt-bindings: display: msm/dsi: Fix the PHY regulator supply props
  dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY
  dt-bindings: display: msm/dsi: Add updates for SDM845

 .../devicetree/bindings/display/msm/dsi.txt| 26 +++
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  | 19 +++
 drivers/gpu/drm/msm/dsi/dsi_cfg.h  |  1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c | 38 +++---
 4 files changed, 74 insertions(+), 10 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/7] drm/msm/dsi: Add SDM845 in dsi_cfg

[Archit Taneja]

SDM845 contains 2 DSI6G v2.2.1 host controllers. Add them in dsi_cfg.

Cc: Jordan Crouse <jcro...@codeaurora.org>
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
---
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 19 +++
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |  1 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 65c1dfbbe019..0327bb54b01b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -118,6 +118,24 @@ static const struct msm_dsi_config msm8996_dsi_cfg = {
.num_dsi = 2,
 };
 
+static const char * const dsi_sdm845_bus_clk_names[] = {
+   "iface", "bus",
+};
+
+static const struct msm_dsi_config sdm845_dsi_cfg = {
+   .io_offset = DSI_6G_REG_SHIFT,
+   .reg_cfg = {
+   .num = 1,
+   .regs = {
+   {"vdda", 21800, 4 },/* 1.2 V */
+   },
+   },
+   .bus_clk_names = dsi_sdm845_bus_clk_names,
+   .num_bus_clks = ARRAY_SIZE(dsi_sdm845_bus_clk_names),
+   .io_start = { 0xae94000, 0xae96000 },
+   .num_dsi = 2,
+};
+
 static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
{MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, _dsi_cfg},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
@@ -131,6 +149,7 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] 
= {
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, _dsi_cfg},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, _dsi_cfg},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1, _dsi_cfg},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, _dsi_cfg},
 };
 
 const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 00a5da2663c6..9cfdcf1c95d5 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -25,6 +25,7 @@
 #define MSM_DSI_6G_VER_MINOR_V1_3  0x1003
 #define MSM_DSI_6G_VER_MINOR_V1_3_10x10030001
 #define MSM_DSI_6G_VER_MINOR_V1_4_10x10040001
+#define MSM_DSI_6G_VER_MINOR_V2_2_10x20020001
 
 #define MSM_DSI_V2_VER_MINOR_8064  0x0
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel