Re: Jetson TK1 & HDMI output in mainline kernel

[Mikko Perttunen]

On 14.07.2017 20:30, Hans Verkuil wrote:

Hi Mikko, Thierry,

While setting up my Jetson TK1 using the mainline kernel I discovered that the 
HDMI output
didn't work.

After some more debugging I discovered that this commit 
404bfb78daf3bedafb0bfab24947059575cbea3d
(gpu: host1x: Add IOMMU support) was the culprit.

As far as I understand it host1x_probe() calls iommu_attach_device(), which in 
turn tries to
find the 'iommus' property in the DT. But the hdmi@5428 device has no such 
property and so
iommu_attach_device() returns -ENODEV and the host1x_probe fails.

After making this extremely ugly patch it all works again:

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 2c58a390123a..683f3a5f382a 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -186,6 +186,11 @@ static int host1x_probe(struct platform_device *pdev)
return -ENOMEM;

err = iommu_attach_device(host->domain, &pdev->dev);
+   if (err == -ENODEV) {
+   iommu_domain_free(host->domain);
+   host->domain = NULL;
+   goto no_mmu;
+   }
if (err)
goto fail_free_domain;

@@ -197,7 +202,7 @@ static int host1x_probe(struct platform_device *pdev)
 geometry->aperture_end >> order);
host->iova_end = geometry->aperture_end;
}
-
+no_mmu:
err = host1x_channel_list_init(&host->channel_list,
   host->info->nb_channels);
if (err) {

My plan is to use my Jetson TK1 to upstream the Tegra CEC driver that I wrote, 
but
a working HDMI output would help a lot :-)



Nice :)


I'm not sure if my analysis of the cause is correct, but if someone can take a 
look
then I would appreciate that!


Yeah, this was discovered independently on linux-tegra a few days ago - 
an almost identical patch is posted there as well but AFAIK not 
integrated yet. Hopefully we can get it integrated soon :)


Hopefully we can get a system to automatically run test suites on 
multiple chip generations - that would eliminate these sorts of mistakes.


Thanks,
Mikko



Regards,

Hans


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

[PATCH v6 5/7] dt-bindings: display: stm32: remove st-display-subsystem parent node requirement

[Philippe CORNU]

There is no need anymore to have a "st-display-subsystem" parent node
in the device tree for the ltdc.

Signed-off-by: Philippe CORNU 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt 
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
index 8e14769..90a8459 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -1,7 +1,6 @@
 * STMicroelectronics STM32 lcd-tft display controller
 
 - ltdc: lcd-tft display controller host
-  must be a sub-node of st-display-subsystem
   Required properties:
   - compatible: "st,stm32-ltdc"
   - reg: Physical base address of the IP registers and length of memory mapped 
region.
-- 
1.9.1

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

[PATCH v6 2/7] drm/stm: ltdc: Add panel-bridge support

[Philippe CORNU]

Add the panel-bridge support for both panels & bridges (used by DSI host &
HDMI/LVDS bridges).

Signed-off-by: Philippe CORNU 
Reviewed-by: Archit Taneja 
---
 drivers/gpu/drm/stm/Kconfig |   2 +-
 drivers/gpu/drm/stm/ltdc.c  | 210 
 drivers/gpu/drm/stm/ltdc.h  |   3 +-
 3 files changed, 38 insertions(+), 177 deletions(-)

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index 2c4817f..4b88223 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -4,7 +4,7 @@ config DRM_STM
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
-   select DRM_PANEL
+   select DRM_PANEL_BRIDGE
select VIDEOMODE_HELPERS
select FB_PROVIDE_GET_FB_UNMAPPED_AREA
default y
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 7f64d5a..e46b427 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -269,11 +269,6 @@ static inline struct ltdc_device *encoder_to_ltdc(struct 
drm_encoder *enc)
return (struct ltdc_device *)enc->dev->dev_private;
 }
 
-static inline struct ltdc_device *connector_to_ltdc(struct drm_connector *con)
-{
-   return (struct ltdc_device *)con->dev->dev_private;
-}
-
 static inline enum ltdc_pix_fmt to_ltdc_pixelformat(u32 drm_fmt)
 {
enum ltdc_pix_fmt pf;
@@ -815,130 +810,35 @@ static int ltdc_crtc_init(struct drm_device *ddev, 
struct drm_crtc *crtc)
  * DRM_ENCODER
  */
 
-static void ltdc_rgb_encoder_enable(struct drm_encoder *encoder)
-{
-   struct ltdc_device *ldev = encoder_to_ltdc(encoder);
-
-   DRM_DEBUG_DRIVER("\n");
-
-   drm_panel_prepare(ldev->panel);
-   drm_panel_enable(ldev->panel);
-}
-
-static void ltdc_rgb_encoder_disable(struct drm_encoder *encoder)
-{
-   struct ltdc_device *ldev = encoder_to_ltdc(encoder);
-
-   DRM_DEBUG_DRIVER("\n");
-
-   drm_panel_disable(ldev->panel);
-   drm_panel_unprepare(ldev->panel);
-}
-
-static const struct drm_encoder_helper_funcs ltdc_rgb_encoder_helper_funcs = {
-   .enable = ltdc_rgb_encoder_enable,
-   .disable = ltdc_rgb_encoder_disable,
-};
-
-static const struct drm_encoder_funcs ltdc_rgb_encoder_funcs = {
+static const struct drm_encoder_funcs ltdc_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
 
-static struct drm_encoder *ltdc_rgb_encoder_create(struct drm_device *ddev)
+static int ltdc_encoder_init(struct drm_device *ddev)
 {
+   struct ltdc_device *ldev = ddev->dev_private;
struct drm_encoder *encoder;
+   int ret;
 
encoder = devm_kzalloc(ddev->dev, sizeof(*encoder), GFP_KERNEL);
if (!encoder)
-   return NULL;
+   return -ENOMEM;
 
encoder->possible_crtcs = CRTC_MASK;
encoder->possible_clones = 0; /* No cloning support */
 
-   drm_encoder_init(ddev, encoder, base.id);
-
-   return encoder;
-}
-
-/*
- * DRM_CONNECTOR
- */
-
-static int ltdc_rgb_connector_get_modes(struct drm_connector *connector)
-{
-   struct drm_device *ddev = connector->dev;
-   struct ltdc_device *ldev = ddev->dev_private;
-   int ret = 0;
-
-   DRM_DEBUG_DRIVER("\n");
-
-   if (ldev->panel)
-   ret = drm_panel_get_modes(ldev->panel);
-
-   return ret < 0 ? 0 : ret;
-}
-
-static struct drm_connector_helper_funcs ltdc_rgb_connector_helper_funcs = {
-   .get_modes = ltdc_rgb_connector_get_modes,
-};
-
-static enum drm_connector_status
-ltdc_rgb_connector_detect(struct drm_connector *connector, bool force)
-{
-   struct ltdc_device *ldev = connector_to_ltdc(connector);
-
-   return ldev->panel ? connector_status_connected :
-  connector_status_disconnected;
-}
-
-static void ltdc_rgb_connector_destroy(struct drm_connector *connector)
-{
-   DRM_DEBUG_DRIVER("\n");
-
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static const struct drm_connector_funcs ltdc_rgb_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .detect = ltdc_rgb_connector_detect,
-   .destroy = ltdc_rgb_connector_destroy,
-   .reset = drm_atomic_helper_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-struct drm_connector *ltdc_rgb_connector_create(struct drm_device *ddev)
-{
-   struct drm_connector *connector;
-   int err;
-
-   connector = devm_kzallo

[PATCH v6 1/7] drm/stm: ltdc: Fix leak of px clk enable in some error paths

[Philippe CORNU]

The pixel clock gets enabled early during init, since it's required
in order to read registers. This pixel clock must be disabled if
errors during this init phase.

Signed-off-by: Eric Anholt 
Acked-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/ltdc.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5331760..7f64d5a 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1045,13 +1045,15 @@ int ltdc_load(struct drm_device *ddev)
 
if (of_address_to_resource(np, 0, &res)) {
DRM_ERROR("Unable to get resource\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err;
}
 
ldev->regs = devm_ioremap_resource(dev, &res);
if (IS_ERR(ldev->regs)) {
DRM_ERROR("Unable to get ltdc registers\n");
-   return PTR_ERR(ldev->regs);
+   ret = PTR_ERR(ldev->regs);
+   goto err;
}
 
for (i = 0; i < MAX_IRQ; i++) {
@@ -1064,7 +1066,7 @@ int ltdc_load(struct drm_device *ddev)
dev_name(dev), ddev);
if (ret) {
DRM_ERROR("Failed to register LTDC interrupt\n");
-   return ret;
+   goto err;
}
}
 
@@ -1079,7 +1081,7 @@ int ltdc_load(struct drm_device *ddev)
if (ret) {
DRM_ERROR("hardware identifier (0x%08x) not supported!\n",
  ldev->caps.hw_version);
-   return ret;
+   goto err;
}
 
DRM_INFO("ltdc hw version 0x%08x - ready\n", ldev->caps.hw_version);
-- 
1.9.1

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

[PATCH v6 3/7] dt-bindings: display: Add Synopsys DW MIPI DSI host controller

[Philippe CORNU]

This patch adds documentation of device tree bindings for the
Synopsys DesignWare MIPI DSI host controller.

Signed-off-by: Philippe CORNU 
Acked-by: Rob Herring 
---
 .../bindings/display/bridge/dw_mipi_dsi.txt| 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
new file mode 100644
index 000..b13adf3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
@@ -0,0 +1,32 @@
+Synopsys DesignWare MIPI DSI host controller
+
+
+This document defines device tree properties for the Synopsys DesignWare MIPI
+DSI host controller. It doesn't constitue a device tree binding specification
+by itself but is meant to be referenced by platform-specific device tree
+bindings.
+
+When referenced from platform device tree bindings the properties defined in
+this document are defined as follows. The platform device tree bindings are
+responsible for defining whether each optional property is used or not.
+
+- reg: Memory mapped base address and length of the DesignWare MIPI DSI
+  host controller registers. (mandatory)
+
+- clocks: References to all the clocks specified in the clock-names property
+  as specified in [1]. (mandatory)
+
+- clock-names:
+  - "pclk" is the peripheral clock for either AHB and APB. (mandatory)
+  - "px_clk" is the pixel clock for the DPI/RGB input. (optional)
+
+- resets: References to all the resets specified in the reset-names property
+  as specified in [2]. (optional)
+
+- reset-names: string reset name, must be "apb" if used. (optional)
+
+- panel or bridge node: see [3]. (mandatory)
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/reset/reset.txt
+[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
-- 
1.9.1

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

[PATCH v6 0/7] STM32 DSI HOST

[Philippe CORNU]

Version 6:
- bridge/synopsys/dw-mipi-dsi.c: drm_bridge_add update (Archit Taneja)

Version 5:
- bridge/synopsys/dw-mipi-dsi.c: Improve the direct call to panel
  bridge post_disable() & related comments (Archit Taneja)
- stm/ltdc.c: fix leak of pixel clock enable in some error
  paths (Eric Anholt)
- bindings/display/bridge/dw_mipi_dsi.txt: add pixel clock & remove
  "driver" (Rob Herring, Archit Taneja)
- bindings/display/st,stm32-ltdc.txt: remove "driver" (Rob Herring,
  Archit Taneja)

Version 4:
- bridge/synopsys/dw-mipi-dsi.c: Add panel-bridge support (-45 lines,
  but no so easy to do) and is_panel_bridge for a better clean up, add
  stm copyright/remove dpms_mode/remove drm_of.h/improve clk
  management/add mode_valid (thanks to comments of Archit Taneja), use
  "DesignWare" instead of "Designware (thanks to comments of Neil
  Armstrong)
- bridge/synopsys/Kconfig: Remove help section to hide it in menuconfig
  (thanks to comments of Archit Taneja)
- include/drm/bridge/dw_mipi_dsi.h: Remove drmP.h (thanks to comments
  of Archit Taneja)
- bindings/display/bridge/dw_mipi_dsi.txt: Improve optional property
  explanations (thanks to comments of Neil Armstrong)
- stm/ltdc.c: Add is_panel_bridge for a better clean up/remove
  drm_encoder_helper_add() (thanks to comments of Eric Anholt)
- stm/dw_mipi_dsi-stm.c: remove math64.h/use DRM_WARN/remove warnings
  (thanks to comments of Archit Taneja), minor alignment fix (thanks to
  comments of Neil Armstrong)
- bindings/display/st,stm32-ltdc.txt: use graph binding in the 
  example/improve ports usage doc (thanks to comments of Rob Herring),
  use "DSI" instead of "dsi" where relevant (thanks to comments of Neil
  Armstrong)

Version 3:
- stm/ltdc: Use panel-bridge (-170 lines), thanks to comments of Eric Anholt,
  Boris Brezillon, Archit Taneja & Andrzej Hajda.
- Synopsys dsi: Add dw_mipi_dsi.h (forgotten in v2), thanks to comments of
  Neil Armstrong.
- Synopsys dsi/dw-mipi-dsi.c: add dw_mipi_dsi_dphy_init() &
  dw_mipi_dsi_dphy_enable() to better manage DW phy-dedicated regs, remove
  dw_mipi_dsi_mode enum, remove stm32 patch for lpm, remove pllref (manage in
  the vendor phy) thanks to comments of Archit Taneja. Add mode_flags to phy
  parameters to better adjust lane mbps according to dsi burst and non burst
  modes todos in caps.
- stm/dw_mipi_dsi-stm.c: Add pllref management.
- dt-bindings/display/stm: Split dt-bindings patch in two (parent node
  removal/ dsi), add required nodes (port & panel/bridge), updates thanks to
  comments of Rob Herring.
- dt-bindings/display/Synopsys dsi: remove port as part of the vendor
  documentation, add panel/bridge node, update dt-bindings thanks to comments
  of Rob Herring.
- Add more people from Hisilicon & Rockchip.

Version 2:
- Add a generic Synopsys DesignWare MIPI DSI bridge driver following
  comments from Neil Armstrong & Archit Taneja.
- Use drm_of_find_panel_or_bridge() thanks to Eric Anholt comments
- Update dt-bindings thanks to Rob Herring comments

Version 1:
- Initial commit

The purpose of this set of patches is to add the mipi dsi host driver
to the stm32 family.

This mipi dsi host driver is based on the Rockchip version of the
Synopsys Designware mipi dsi driver (rockchip/dw-mipi-dsi.c)
modified for the stm32 family:
- replace Rockchip digital & phy specific extensions with stm32's ones.
- add a bridge

Philippe CORNU (7):
  drm/stm: ltdc: Fix leak of px clk enable in some error paths
  drm/stm: ltdc: Add panel-bridge support
  dt-bindings: display: Add Synopsys DW MIPI DSI host controller
  drm/bridge/synopsys: Add MIPI DSI host controller bridge
  dt-bindings: display: stm32: remove st-display-subsystem parent node
requirement
  dt-bindings: display: stm32: Add DSI controller
  drm/stm: Add STM32 DSI controller driver

 .../bindings/display/bridge/dw_mipi_dsi.txt|  32 +
 .../devicetree/bindings/display/st,stm32-ltdc.txt  | 105 ++-
 drivers/gpu/drm/bridge/synopsys/Kconfig|   6 +
 drivers/gpu/drm/bridge/synopsys/Makefile   |   2 +
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  | 981 +
 drivers/gpu/drm/stm/Kconfig|   9 +-
 drivers/gpu/drm/stm/Makefile   |   2 +
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c  | 352 
 drivers/gpu/drm/stm/ltdc.c | 220 +
 drivers/gpu/drm/stm/ltdc.h |   3 +-
 include/drm/bridge/dw_mipi_dsi.h   |  39 +
 11 files changed, 1568 insertions(+), 183 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
 create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 create mode 100644 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi.h

-- 
1.9.1

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

[PATCH v6 4/7] drm/bridge/synopsys: Add MIPI DSI host controller bridge

[Philippe CORNU]

Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.

Signed-off-by: Philippe CORNU 
---
 drivers/gpu/drm/bridge/synopsys/Kconfig   |   6 +
 drivers/gpu/drm/bridge/synopsys/Makefile  |   2 +
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 981 ++
 include/drm/bridge/dw_mipi_dsi.h  |  39 +
 4 files changed, 1028 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi.h

diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 53e78d0..a2fb939 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -22,3 +22,9 @@ config DRM_DW_HDMI_I2S_AUDIO
help
  Support the I2S Audio interface which is part of the Synopsys
  Designware HDMI block.
+
+config DRM_DW_MIPI_DSI
+   tristate
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL_BRIDGE
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 17aa7a6..5f57d36 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -3,3 +3,5 @@
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+
+obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw-mipi-dsi.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
new file mode 100644
index 000..36f5ccb
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -0,0 +1,981 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Modified by Philippe Cornu 
+ * This generic Synopsys DesignWare MIPI DSI host driver is based on the
+ * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DSI_VERSION0x00
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVIDSION(div)  (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVIDSION(div)  (((div) & 0xff) << 0)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VID(vid)   (((vid) & 0x3) << 0)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define EN18_LOOSELY   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define EN_CRC_RX  BIT(4)
+#define EN_ECC_RX  BIT(3)
+#define EN_BTA BIT(2)
+#define EN_EOTP_RX BIT(1)
+#define EN_EOTP_TX BIT(0)
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define FRAME_BTA_ACK  BIT(14)
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
+#define VID_MODE_TYPE_BURST0x2
+#define VID_MODE_TYPE_MASK 0x3
+
+#define DSI_VID_PKT_SIZE   0x3c
+#define VID_PKT_SIZE(p)(((p) & 0x3fff) << 0)
+#define VID_PKT_MAX_SIZE   0x3fff
+
+#define DSI_VID_HSA_TIME   0x48
+#define DSI_VID_HBP_TIME   0x4c
+#define DSI_VID_H

[PATCH v6 6/7] dt-bindings: display: stm32: Add DSI controller

[Philippe CORNU]

This patch adds documentation of device tree bindings for the STM32 DSI
controller based on the Synopsys DesignWare MIPI DSI host controller.

Signed-off-by: Philippe CORNU 
Reviewed-by: Neil Armstrong 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/st,stm32-ltdc.txt  | 104 -
 1 file changed, 103 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt 
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
index 90a8459..74b5ac7 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -12,8 +12,40 @@
   Required nodes:
 - Video port for RGB output.
 
-Example:
+* STMicroelectronics STM32 DSI controller specific extensions to Synopsys
+  DesignWare MIPI DSI host controller
 
+The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare MIPI
+DSI host controller. For all mandatory properties & nodes, please refer
+to the related documentation in [5].
+
+Mandatory properties specific to STM32 DSI:
+- #address-cells: Should be <1>.
+- #size-cells: Should be <0>.
+- compatible: "st,stm32-dsi".
+- clock-names:
+  - phy pll reference clock string name, must be "ref".
+- resets: see [5].
+- reset-names: see [5].
+
+Mandatory nodes specific to STM32 DSI:
+- ports: A node containing DSI input & output port nodes with endpoint
+  definitions as documented in [3] & [4].
+  - port@0: DSI input port node, connected to the ltdc rgb output port.
+  - port@1: DSI output port node, connected to a panel or a bridge input port.
+- panel or bridge node: A node containing the panel or bridge description as
+  documented in [6].
+  - port: panel or bridge port node, connected to the DSI output port (port@1).
+
+Note: You can find more documentation in the following references
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/reset/reset.txt
+[3] Documentation/devicetree/bindings/media/video-interfaces.txt
+[4] Documentation/devicetree/bindings/graph.txt
+[5] Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
+[6] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+
+Example 1: RGB panel
 / {
...
soc {
@@ -33,3 +65,73 @@ Example:
};
};
 };
+
+Example 2: DSI panel
+
+/ {
+   ...
+   soc {
+   ...
+   ltdc: display-controller@40016800 {
+   compatible = "st,stm32-ltdc";
+   reg = <0x40016800 0x200>;
+   interrupts = <88>, <89>;
+   resets = <&rcc STM32F4_APB2_RESET(LTDC)>;
+   clocks = <&rcc 1 CLK_LCD>;
+   clock-names = "lcd";
+
+   port {
+   ltdc_out_dsi: endpoint {
+   remote-endpoint = <&dsi_in>;
+   };
+   };
+   };
+
+
+   dsi: dsi@40016c00 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "st,stm32-dsi";
+   reg = <0x40016c00 0x800>;
+   clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>;
+   clock-names = "ref", "pclk";
+   resets = <&rcc STM32F4_APB2_RESET(DSI)>;
+   reset-names = "apb";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = 
<;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi_out: endpoint {
+   remote-endpoint = 
<&dsi_in_panel>;
+   };
+   };
+
+   };
+
+   panel-dsi@0 {
+   reg = <0>; /* dsi virtual channel (0..3) */
+   compatible = ...;
+   enable-gpios = ...;
+
+   port {
+   dsi_in_panel: endpoint {
+   remote-endpoint = <&dsi_out>;
+   };
+   };
+
+   };
+
+   };
+
+   };
+};
-- 
1.9.1

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

[PATCH v6 7/7] drm/stm: Add STM32 DSI controller driver

[Philippe CORNU]

Add the STM32 DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

Signed-off-by: Philippe CORNU 
Reviewed-by: Neil Armstrong 
Reviewed-by: Archit Taneja 
---
 drivers/gpu/drm/stm/Kconfig   |   7 +
 drivers/gpu/drm/stm/Makefile  |   2 +
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 352 ++
 3 files changed, 361 insertions(+)
 create mode 100644 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index 4b88223..f9462bc 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -14,3 +14,10 @@ config DRM_STM
  STMicroelectronics STM32 MCUs.
  To compile this driver as a module, choose M here: the module
  will be called stm-drm.
+
+config DRM_STM_DSI
+   tristate "STMicroelectronics specific extensions for Synopsys MIPI DSI"
+   depends on DRM_STM
+   select DRM_DW_MIPI_DSI
+   help
+ Choose this option for MIPI DSI support on STMicroelectronics SoC.
diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
index a09ecf4..d883adc 100644
--- a/drivers/gpu/drm/stm/Makefile
+++ b/drivers/gpu/drm/stm/Makefile
@@ -2,4 +2,6 @@ stm-drm-y := \
drv.o \
ltdc.o
 
+obj-$(CONFIG_DRM_STM_DSI) += dw_mipi_dsi-stm.o
+
 obj-$(CONFIG_DRM_STM) += stm-drm.o
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
new file mode 100644
index 000..16ae00e
--- /dev/null
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -0,0 +1,352 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu 
+ *  Yannick Fertre 
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* DSI wrapper register & bit definitions */
+/* Note: registers are named as in the Reference Manual */
+#define DSI_WCFGR  0x0400  /* Wrapper ConFiGuration Reg */
+#define WCFGR_DSIM BIT(0)  /* DSI Mode */
+#define WCFGR_COLMUX   GENMASK(3, 1)   /* COLor MUltipleXing */
+
+#define DSI_WCR0x0404  /* Wrapper Control Reg */
+#define WCR_DSIEN  BIT(3)  /* DSI ENable */
+
+#define DSI_WISR   0x040C  /* Wrapper Interrupt and Status Reg */
+#define WISR_PLLLS BIT(8)  /* PLL Lock Status */
+#define WISR_RRS   BIT(12) /* Regulator Ready Status */
+
+#define DSI_WPCR0  0x0418  /* Wrapper Phy Conf Reg 0 */
+#define WPCR0_UIX4 GENMASK(5, 0)   /* Unit Interval X 4 */
+#define WPCR0_TDDL BIT(16) /* Turn Disable Data Lanes */
+
+#define DSI_WRPCR  0x0430  /* Wrapper Regulator & Pll Ctrl Reg */
+#define WRPCR_PLLENBIT(0)  /* PLL ENable */
+#define WRPCR_NDIV GENMASK(8, 2)   /* pll loop DIVision Factor */
+#define WRPCR_IDF  GENMASK(14, 11) /* pll Input Division Factor */
+#define WRPCR_ODF  GENMASK(17, 16) /* pll Output Division Factor */
+#define WRPCR_REGENBIT(24) /* REGulator ENable */
+#define WRPCR_BGRENBIT(28) /* BandGap Reference ENable */
+#define IDF_MIN1
+#define IDF_MAX7
+#define NDIV_MIN   10
+#define NDIV_MAX   125
+#define ODF_MIN1
+#define ODF_MAX8
+
+/* dsi color format coding according to the datasheet */
+enum dsi_color {
+   DSI_RGB565_CONF1,
+   DSI_RGB565_CONF2,
+   DSI_RGB565_CONF3,
+   DSI_RGB666_CONF1,
+   DSI_RGB666_CONF2,
+   DSI_RGB888,
+};
+
+#define LANE_MIN_KBPS  31250
+#define LANE_MAX_KBPS  50
+
+/* Sleep & timeout for regulator on/off, pll lock/unlock & fifo empty */
+#define SLEEP_US   1000
+#define TIMEOUT_US 20
+
+struct dw_mipi_dsi_stm {
+   void __iomem *base;
+   struct clk *pllref_clk;
+};
+
+static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
+{
+   writel(val, dsi->base + reg);
+}
+
+static inline u32 dsi_read(struct dw_mipi_dsi_stm *dsi, u32 reg)
+{
+   return readl(dsi->base + reg);
+}
+
+static inline void dsi_set(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 mask)
+{
+   dsi_write(dsi, reg, dsi_read(dsi, reg) | mask);
+}
+
+static inline void dsi_clear(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 mask)
+{
+   dsi_write(dsi, reg, dsi_read(dsi, reg) & ~mask);
+}
+
+static inline void dsi_update_bits(struct dw_mipi_dsi_stm *dsi, u32 reg,
+  u32 mask, u32 val)
+{
+   dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
+}
+
+static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
+{
+   switch (fmt) {
+   case MIPI_DSI_FMT_RGB888:
+   return DSI_RGB888;
+   case MIPI_DSI_FMT_RGB666:
+   return DSI_RGB666_CONF2;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   return DSI_RGB666_CONF1;
+   case MIPI_DSI_FMT_RGB565:
+

Re: [PATCH v5 4/7] drm/bridge/synopsys: Add MIPI DSI host controller bridge

[Philippe CORNU]

On 07/12/2017 08:05 AM, Archit Taneja wrote:
> 
> 
> On 07/03/2017 02:11 PM, Philippe CORNU wrote:
>> Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
>> Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
>>
> 
> The patch looks good now. One thing that needs to be updated is to make
> drm_bridge_add() not return anything.

Hi Archit and many thanks for your review.
I have just sent a v6 version adding the drm_bridge_add() small fix.

> 
> The later patches in the series would be dependent on this patch, right?
yes

> Since the ST patches go via drm-misc too, we could either push all these
> together, or I could push the bridge driver to drm-misc-next, and the ST
> patches can be pushed after. Any preference? If not, I'll do the latter.
> 
> Archit
> 
The v6 version has been tested on today drm-misc-next branch (few 
minutes ago). You can push the entire serie as it is maybe the most 
simple solution. Or you can push "up to the synopsys part" and Benjamin 
& I will push the remaining part. In fact, it is up to you, simply tell 
us your preferred approach.

Once again, many thanks,
Philippe


>> Signed-off-by: Philippe CORNU 
>> ---
>>   drivers/gpu/drm/bridge/synopsys/Kconfig   |   6 +
>>   drivers/gpu/drm/bridge/synopsys/Makefile  |   2 +
>>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 979 
>> ++
>>   include/drm/bridge/dw_mipi_dsi.h  |  39 +
>>   4 files changed, 1026 insertions(+)
>>   create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>   create mode 100644 include/drm/bridge/dw_mipi_dsi.h
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
>> b/drivers/gpu/drm/bridge/synopsys/Kconfig
>> index 40d2827..f00ee26 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
>> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
>> @@ -21,3 +21,9 @@ config DRM_DW_HDMI_I2S_AUDIO
>>   help
>> Support the I2S Audio interface which is part of the Synopsys
>> Designware HDMI block.
>> +
>> +config DRM_DW_MIPI_DSI
>> +tristate
>> +select DRM_KMS_HELPER
>> +select DRM_MIPI_DSI
>> +select DRM_PANEL_BRIDGE
>> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
>> b/drivers/gpu/drm/bridge/synopsys/Makefile
>> index 17aa7a6..5f57d36 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
>> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
>> @@ -3,3 +3,5 @@
>>   obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>>   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>>   obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
>> +
>> +obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw-mipi-dsi.o
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> new file mode 100644
>> index 000..406000e
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -0,0 +1,979 @@
>> +/*
>> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>> + * Copyright (C) STMicroelectronics SA 2017
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * Modified by Philippe Cornu 
>> + * This generic Synopsys DesignWare MIPI DSI host driver is based on the
>> + * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define DSI_VERSION0x00
>> +#define DSI_PWR_UP0x04
>> +#define RESET0
>> +#define POWERUPBIT(0)
>> +
>> +#define DSI_CLKMGR_CFG0x08
>> +#define TO_CLK_DIVIDSION(div)(((div) & 0xff) << 8)
>> +#define TX_ESC_CLK_DIVIDSION(div)(((div) & 0xff) << 0)
>> +
>> +#define DSI_DPI_VCID0x0c
>> +#define DPI_VID(vid)(((vid) & 0x3) << 0)
>> +
>> +#define DSI_DPI_COLOR_CODING0x10
>> +#define EN18_LOOSELYBIT(8)
>> +#define DPI_COLOR_CODING_16BIT_10x0
>> +#define DPI_COLOR_CODING_16BIT_20x1
>> +#define DPI_COLOR_CODING_16BIT_30x2
>> +#define DPI_COLOR_CODING_18BIT_10x3
>> +#define DPI_COLOR_CODING_18BIT_20x4
>> +#define DPI_COLOR_CODING_24BIT0x5
>> +
>> +#define DSI_DPI_CFG_POL0x14
>> +#define COLORM_ACTIVE_LOWBIT(4)
>> +#define SHUTD_ACTIVE_LOWBIT(3)
>> +#define HSYNC_ACTIVE_LOWBIT(2)
>> +#define VSYNC_ACTIVE_LOWBIT(1)
>> +#define DATAEN_ACTIVE_LOWBIT(0)
>> +
>> +#define DSI_DPI_LP_CMD_TIM0x18
>> +#define OUTVACT_LPCMD_TIME(p)(((p) & 0xff) << 16)
>> +#define INVACT_LPCMD_TIME(p)((p) & 0xff)
>> +
>> +#define DSI_DBI_CFG  

Re: [PATCH v5 4/7] drm/bridge/synopsys: Add MIPI DSI host controller bridge

[Archit Taneja]

On 07/17/2017 01:24 PM, Philippe CORNU wrote:



On 07/12/2017 08:05 AM, Archit Taneja wrote:



On 07/03/2017 02:11 PM, Philippe CORNU wrote:

Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.



The patch looks good now. One thing that needs to be updated is to make
drm_bridge_add() not return anything.


Hi Archit and many thanks for your review.
I have just sent a v6 version adding the drm_bridge_add() small fix.



The later patches in the series would be dependent on this patch, right?

yes


Since the ST patches go via drm-misc too, we could either push all these
together, or I could push the bridge driver to drm-misc-next, and the ST
patches can be pushed after. Any preference? If not, I'll do the latter.

Archit


The v6 version has been tested on today drm-misc-next branch (few
minutes ago). You can push the entire serie as it is maybe the most
simple solution. Or you can push "up to the synopsys part" and Benjamin
& I will push the remaining part. In fact, it is up to you, simply tell
us your preferred approach.


Thanks. I'll push patches 1-4 after some build testing. You can push the rest
afterwards.

Thanks,
Archit



Once again, many thanks,
Philippe



Signed-off-by: Philippe CORNU 
---
   drivers/gpu/drm/bridge/synopsys/Kconfig   |   6 +
   drivers/gpu/drm/bridge/synopsys/Makefile  |   2 +
   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 979
++
   include/drm/bridge/dw_mipi_dsi.h  |  39 +
   4 files changed, 1026 insertions(+)
   create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
   create mode 100644 include/drm/bridge/dw_mipi_dsi.h

diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 40d2827..f00ee26 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -21,3 +21,9 @@ config DRM_DW_HDMI_I2S_AUDIO
   help
 Support the I2S Audio interface which is part of the Synopsys
 Designware HDMI block.
+
+config DRM_DW_MIPI_DSI
+tristate
+select DRM_KMS_HELPER
+select DRM_MIPI_DSI
+select DRM_PANEL_BRIDGE
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 17aa7a6..5f57d36 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -3,3 +3,5 @@
   obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
   obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+
+obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw-mipi-dsi.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
new file mode 100644
index 000..406000e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -0,0 +1,979 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Modified by Philippe Cornu 
+ * This generic Synopsys DesignWare MIPI DSI host driver is based on the
+ * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DSI_VERSION0x00
+#define DSI_PWR_UP0x04
+#define RESET0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG0x08
+#define TO_CLK_DIVIDSION(div)(((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVIDSION(div)(((div) & 0xff) << 0)
+
+#define DSI_DPI_VCID0x0c
+#define DPI_VID(vid)(((vid) & 0x3) << 0)
+
+#define DSI_DPI_COLOR_CODING0x10
+#define EN18_LOOSELYBIT(8)
+#define DPI_COLOR_CODING_16BIT_10x0
+#define DPI_COLOR_CODING_16BIT_20x1
+#define DPI_COLOR_CODING_16BIT_30x2
+#define DPI_COLOR_CODING_18BIT_10x3
+#define DPI_COLOR_CODING_18BIT_20x4
+#define DPI_COLOR_CODING_24BIT0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOWBIT(4)
+#define SHUTD_ACTIVE_LOWBIT(3)
+#define HSYNC_ACTIVE_LOWBIT(2)
+#define VSYNC_ACTIVE_LOWBIT(1)
+#define DATAEN_ACTIVE_LOWBIT(0)
+
+#define DSI_DPI_LP_CMD_TIM0x18
+#define OUTVACT_LPCMD_TIME(p)(((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)((p) & 0xff)
+
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG0x2c
+#define EN_CRC_RXBIT(4)
+#define EN_ECC_RXBIT(3)
+#define EN_BTA  

[PATCH v2 0/5] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[Caesar Wang]

This series patches supported the mail in devicetree and used the
thermal IPA by default.

Verified with kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch. ( The Linux version 4.12.0 for now).

The most rockchip SoCs will be supported with IPA mode for thermal
in later.

---

History version:
1. The first version found on
https://www.spinics.net/lists/arm-kernel/msg593118.html

Tested on Kevin board with bringing up ChromeOS.
OS VERSION:
CHROMEOS_RELEASE_DESCRIPTION=9693.1.0 (Official Build) dev-channel kevin 
test

BIOS VERSION:
Google_Kevin.8785.211.2017_06_20_1043

EC VERSION:
Build info:kevin_v1.10.217-24514961d 2017-07-03 07:46:36 wxt@nb

With the ARM's lastest mali driver TX011-SW-99002-r18p0-01rel0 on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel

From the bootup log:
localhost devfreq0 # dmesg |grep mali
[0.94] mali ff9a.gpu: GPU identified as 0x0860 r2p0 status 0
[0.940830] mali ff9a.gpu: Protected mode not available
[0.947334] mali ff9a.gpu: Using configured power model 
mali-simple-power-model, and fallback mali-simple-power-model
[0.960083] mali ff9a.gpu: Probed as mali0

localhost devfreq0 # pwd
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0
localhost devfreq0 # ls
available_frequencies  devicemin_freq  subsystemuevent
available_governorsgovernor  polling_interval  target_freq  userspace
cur_freq   max_freq  power trans_stat

localhost ff9a.gpu # ls
core_availability_policy  gpuinfo   modalias   
soft_job_timeout
core_mask js_scheduling_period  of_nodesubsystem
devfreq   js_timeouts   pm_poweroffuevent
drivermem_pool_max_size power
driver_override   mem_pool_size power_policy
dvfs_period   misc  reset_timeout
---

And for thermal with IPA.
Try to run 'md5sum /dev/zero &' and octane/benchmark scripts to go up the 
temperature.
From the scripts to have a look at the actual control.
"
while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp 
/sys/devices/system/cpu/cpu[0-5]/cpufreq/scaling_cur_freq 
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0/cur_freq;date;sleep .5; 
done &
"

-Caesar


Changes in v2:
As Heiko comments on https://patchwork.kernel.org/patch/9835939/
- interrupt-name use the lower case.
- use the correct compatible "arm,mali-t860"
- remove the clock name, since the mali only have one input clock.
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

Caesar Wang (5):
  dt-bindings: gpu: add the RK3399 mali for rockchip specifics
  dt-bindings: gpu: add a power_model optional properties for MALI
  arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
  arm64: dts: rockchip: enable the GPU for RK3399-GRU
  arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

 .../devicetree/bindings/gpu/arm,mali-midgard.txt   | 13 
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |  5 ++
 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi   | 33 ++
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi   | 33 ++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 74 --
 5 files changed, 125 insertions(+), 33 deletions(-)

-- 
2.7.4

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

[PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

[Caesar Wang]

This patch adds the MALI's power-model to set the IPA model to be used
for power management.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index a461e47..b616e6b 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -37,6 +37,18 @@ Optional properties:
 - operating-points-v2 : Refer to 
Documentation/devicetree/bindings/power/opp.txt
   for details.
 
+- power_model : Sets power model parameters. Note that this model was designed 
for the Juno
+   platform, and may not be suitable for other platforms. A 
structure containing :
+   - compatible: Should be arm,mali-simple-power-model
+   - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied
+ by v^2*f to calculate the dynamic power consumption.
+   - static-coefficient: Coefficient, in uW/V^3, which is multiplied by
+ v^3 to calculate the static power consumption.
+   - ts: An array containing coefficients for the temperature scaling
+ factor. This is used to scale the static power by a factor of
+ tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0],
+ and T = temperature in degrees.
+   - thermal-zone: A string identifying the thermal zone used for the GPU
 
 Example for a Mali-T760:
 
-- 
2.7.4

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

[PATCH v2 1/5] dt-bindings: gpu: add the RK3399 mali for rockchip specifics

[Caesar Wang]

RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
high-end graphics processors from ARM.

This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
support IPA of gpu thermal in later.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index d3b6e1a4..a461e47 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -17,6 +17,7 @@ Required properties:
   * which must be preceded by one of the following vendor specifics:
 + "amlogic,meson-gxm-mali"
 + "rockchip,rk3288-mali"
++ "rockchip,rk3399-mali"
 
 - reg : Physical base address of the device and length of the register area.
 
-- 
2.7.4

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

[PATCH] drm/nouveau/hwmon: Uninitialized variables in sysfs

[Dan Carpenter]

kstrtol() and friends can return -EINVAL or -ERANGE.  We have to test
for both, otherwise the value is possibly uninitialized.  Also in some
of these files we accidentally return "count" on error instead of a
negative error code.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 7c965648df80..5e75af91c446 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -68,9 +68,11 @@ nouveau_hwmon_set_temp1_auto_point1_temp(struct device *d,
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
long value;
+   int ret;
 
-   if (kstrtol(buf, 10, &value) == -EINVAL)
-   return count;
+   ret = kstrtol(buf, 10, &value);
+   if (ret)
+   return ret;
 
therm->attr_set(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST,
value / 1000);
@@ -101,9 +103,11 @@ nouveau_hwmon_set_temp1_auto_point1_temp_hyst(struct 
device *d,
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
long value;
+   int ret;
 
-   if (kstrtol(buf, 10, &value) == -EINVAL)
-   return count;
+   ret = kstrtol(buf, 10, &value);
+   if (ret)
+   return ret;
 
therm->attr_set(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST_HYST,
value / 1000);
@@ -156,8 +160,9 @@ nouveau_hwmon_set_pwm1_min(struct device *d, struct 
device_attribute *a,
long value;
int ret;
 
-   if (kstrtol(buf, 10, &value) == -EINVAL)
-   return -EINVAL;
+   ret = kstrtol(buf, 10, &value);
+   if (ret)
+   return ret;
 
ret = therm->attr_set(therm, NVKM_THERM_ATTR_FAN_MIN_DUTY, value);
if (ret < 0)
@@ -179,8 +184,9 @@ nouveau_hwmon_set_pwm1_max(struct device *d, struct 
device_attribute *a,
long value;
int ret;
 
-   if (kstrtol(buf, 10, &value) == -EINVAL)
-   return -EINVAL;
+   ret = kstrtol(buf, 10, &value);
+   if (ret)
+   return ret;
 
ret = therm->attr_set(therm, NVKM_THERM_ATTR_FAN_MAX_DUTY, value);
if (ret < 0)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/18] drm/sun4i: Add if statement instead of depends on

[Maxime Ripard]

On Fri, Jul 14, 2017 at 11:09:07AM +0800, Chen-Yu Tsai wrote:
> On Thu, Jul 13, 2017 at 10:12 PM, Maxime Ripard
>  wrote:
> > The depends on relationship is obvious, and using an if statement will
> > propagate it to every option without the need for each and every one of
> > them to define it.
> >
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 04/18] drm/sun4i: Remove useless atomic_check

[Maxime Ripard]

On Fri, Jul 14, 2017 at 11:15:18AM +0800, Chen-Yu Tsai wrote:
> On Thu, Jul 13, 2017 at 10:12 PM, Maxime Ripard
>  wrote:
> > The atomic_check callback is optional, and we don't implement anything in
> > some parts of our drivers. Let's remove it.
> >
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH] drm/etnaviv: select CMA and DMA_CMA if available

[Lucas Stach]

Am Sonntag, den 16.07.2017, 16:29 +0100 schrieb Russell King - ARM
Linux:
> On Fri, Jul 14, 2017 at 04:38:01PM +0200, Lucas Stach wrote:
> > While this is no build dependency, etnaviv will only work correctly on most
> > systems if CMA and DMA_CMA are enabled. Select both options if available to
> > avoid users ending up with a non-working GPU due to a lacking kernel config.
> 
> How does merely selecting CMA solve this problem?  Does CMA guarantee
> that GPU command buffers will always be allocated in the lower 2G of
> physical address space?

No, but CMA guarantees that commandbuffers will be allocated from the
region and with the default CMA configuration dma_get_required_mask()
will return the correct location of the CMA area, so we can move the
linear memory window accordingly.
There are no guarantees, but at least with a CMA area no larger than 2GB
things will work for the average user, which is a lot better than
leaving them with a non-working GPU due to a simple missing kernel
configuration option.

Regards,
Lucas

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

Re: [PATCH] drm/etnaviv: select CMA and DMA_CMA if available

[Lucas Stach]

Am Freitag, den 14.07.2017, 11:32 -0700 schrieb Joshua Clayton:
> On Friday, July 14, 2017 7:38:01 AM PDT Lucas Stach wrote:
> > While this is no build dependency, etnaviv will only work correctly on most
> > systems if CMA and DMA_CMA are enabled. Select both options if available to
> > avoid users ending up with a non-working GPU due to a lacking kernel config.
> > 
> > Signed-off-by: Lucas Stach 
> > ---
> >  drivers/gpu/drm/etnaviv/Kconfig | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/etnaviv/Kconfig
> > b/drivers/gpu/drm/etnaviv/Kconfig index 71cee4e9fefb..38b477b5fbf9 100644
> > --- a/drivers/gpu/drm/etnaviv/Kconfig
> > +++ b/drivers/gpu/drm/etnaviv/Kconfig
> > @@ -10,6 +10,8 @@ config DRM_ETNAVIV
> > select IOMMU_API
> > select IOMMU_SUPPORT
> > select WANT_DEV_COREDUMP
> > +   select CMA if HAVE_DMA_CONTIGUOUS
> > +   select DMA_CMA if HAVE_DMA_CONTIGUOUS
> > help
> >   DRM driver for Vivante GPUs.
> IIRC, This at least half solves it.
> Does the user of systems with > 2 GiB  need to explicitly specify cma size 
> for 
> it to work?

No, we move the linear memory window to the location of the CMA area,
which means as long as the user doesn't explicitly specify a CMA size
> 2GB things will just work.

Regards,
Lucas

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

Re: [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support

[Hans Verkuil]

Hi Russell,

On 09/06/17 16:10, Russell King - ARM Linux wrote:
> On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
>> Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
>> not used, but a custom one, so this notifier is actually useful for
>> this platform and maybe others.
> 
> Is the CEC controller configured into dw-hdmi (is the config bit set?)
> I'm just wondering if we're going to end up with two CEC drivers trying
> to bind to the same notifier.
> 
>> Should we really wait until I push the Amlogic AO CEC driver ? Having a
>> notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
> 
> It sounds like this adds additional information that has been missing
> from the review of my patches - and I suspect changes Hans' comments.
> So, I'll wait, it seems pointless to try and update the patches when
> it's not clear how to proceed due to other dependencies, especially
> when it means that their existing state is what's required (I'm pleased
> that I've held off modifying the patches so far.)
> 
> If that means having to wait another kernel revision, then I guess that's
> what will have to happen.

Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.

I've already Acked patches 1-3. I had some comments for patch 4, so that
needs a bit more work.

Note that there is now a cec_transmit_attempt_done() helper function that
will simplify your code.

Regards,

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

Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock

[Maxime Ripard]

Hi Mark,

On Thu, Jul 13, 2017 at 05:01:42PM +0100, Mark Brown wrote:
> On Thu, Jul 13, 2017 at 04:12:56PM +0200, Maxime Ripard wrote:
> 
> > This might be problematic if the clock to enable is stored in another node.
> > Let's add a function that allows to attach a clock that has already been
> > retrieved to a regmap in order to fix this.
> 
> What is the use case for this?

This is useful when the clock you want to be handled by the regmap is
not described in the device node that probed the driver, but one of
its subnode, or an another node entirely.

We're in the latter case, where we have two controllers in the DT, but
are driven by the same driver. We'll create two regmaps, but one will
not have the proper of_node used to retrieve the clock.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 17/18] arm: dts: sun8i: Add BananaPI M2-Magic DTS

[Maxime Ripard]

On Fri, Jul 14, 2017 at 12:40:19PM +0800, Chen-Yu Tsai wrote:
> On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
>  wrote:
> > The Bananapi M2-Magic is a board with an A33, a USB host and USB OTG
> > connectors, and 8GB eMMC, an AP6212 WiFi/Bluetooth chip and connectors for
> > DSI, CSI and GPIOs.
> >
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Chen-Yu Tsai 

Applied, thanks!

> Has BPI publicly released the schematics and/or FEX file yet?

I don't think they did yet.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH] drm/i915: Consistently use enum pipe for PCH transcoders

[Daniel Vetter]

On Fri, Jul 14, 2017 at 06:04:03PM -0700, Matthias Kaehlcke wrote:
> The current code uses two different enum types for PCH transcoders and
> performs implicit conversions between the two types. This is error prone
> and causes clang to raise warnings like this:
> 
> drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
>   from enumeration type 'enum pipe' to different enumeration type
>   'enum transcoder' [-Wenum-conversion]
> intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
> 
> Consistently use the type enum pipe for PCH transcoders.
> 
> Signed-off-by: Matthias Kaehlcke 

Thanks for respinning. Unfortunately it doesn't apply cleanly to
drm-intel-next-queued, and I don't have a clang setup ready to confirm I
didn't screw up anything. Can you pls rebase?

Thanks a lot.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_irq.c| 10 +-
>  drivers/gpu/drm/i915/intel_display.c   | 24 ++--
>  drivers/gpu/drm/i915/intel_drv.h   |  6 +++---
>  drivers/gpu/drm/i915/intel_fifo_underrun.c |  6 +++---
>  4 files changed, 21 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 190f6aa5d15e..7960d2170750 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2132,10 +2132,10 @@ static void ibx_irq_handler(struct drm_i915_private 
> *dev_priv, u32 pch_iir)
>   DRM_DEBUG_DRIVER("PCH transcoder CRC error interrupt\n");
>  
>   if (pch_iir & SDE_TRANSA_FIFO_UNDER)
> - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
> + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
>  
>   if (pch_iir & SDE_TRANSB_FIFO_UNDER)
> - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
> + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
>  }
>  
>  static void ivb_err_int_handler(struct drm_i915_private *dev_priv)
> @@ -2169,13 +2169,13 @@ static void cpt_serr_int_handler(struct 
> drm_i915_private *dev_priv)
>   DRM_ERROR("PCH poison interrupt\n");
>  
>   if (serr_int & SERR_INT_TRANS_A_FIFO_UNDERRUN)
> - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
> + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
>  
>   if (serr_int & SERR_INT_TRANS_B_FIFO_UNDERRUN)
> - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
> + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
>  
>   if (serr_int & SERR_INT_TRANS_C_FIFO_UNDERRUN)
> - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_C);
> + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_C);
>  
>   I915_WRITE(SERR_INT, serr_int);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 9106ea32b048..21a8fea46ad9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1782,7 +1782,7 @@ static void lpt_enable_pch_transcoder(struct 
> drm_i915_private *dev_priv,
>  
>   /* FDI must be feeding us bits for PCH ports */
>   assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
> - assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> + assert_fdi_rx_enabled(dev_priv, PIPE_A);
>  
>   /* Workaround: set timing override bit. */
>   val = I915_READ(TRANS_CHICKEN2(PIPE_A));
> @@ -1858,16 +1858,16 @@ void lpt_disable_pch_transcoder(struct 
> drm_i915_private *dev_priv)
>   I915_WRITE(TRANS_CHICKEN2(PIPE_A), val);
>  }
>  
> -enum transcoder intel_crtc_pch_transcoder(struct intel_crtc *crtc)
> +enum pipe intel_crtc_pch_transcoder(struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>  
>   WARN_ON(!crtc->config->has_pch_encoder);
>  
>   if (HAS_PCH_LPT(dev_priv))
> - return TRANSCODER_A;
> + return PIPE_A;
>   else
> - return (enum transcoder) crtc->pipe;
> + return crtc->pipe;
>  }
>  
>  /**
> @@ -1906,7 +1906,7 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
>   if (crtc->config->has_pch_encoder) {
>   /* if driving the PCH, we need FDI enabled */
>   assert_fdi_rx_pll_enabled(dev_priv,
> -   (enum pipe) 
> intel_crtc_pch_transcoder(crtc));
> +   
> intel_crtc_pch_transcoder(crtc));
>   assert_fdi_tx_pll_enabled(dev_priv,
> (enum pipe) cpu_transcoder);
>   }
> @@ -4573,7 +4573,7 @@ static void lpt_pch_enable(const struct 
> intel_crtc_state *crtc_state)
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>  
> - assert_pch_transcoder_dis

[Bug 101787] colours all messed up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101787

--- Comment #2 from Julien Isorce  ---
Can you attach output of dmesg as suggested by the error message (and the dmesg
output just after boot) and also output when setting GST_DEBUG=6
Does it work with older fedora/mesa/kernel (i.e. regression) ?

You can try to compare with:

gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse ! vaapih264dec !
capsfilter caps="video/x-raw(memory:VASurface)" ! vaapih264enc ! qtmux !
filesink location=res.mp4

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Lukas Wunner]

On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:
> Regarding the SMC, there's actually only one key that consistently seems to 
> have
> a different value whether the display is on or off:
> 
> --- blank 2017-05-05 08:40:53.694565045 +0200
> +++ non_blank 2017-05-05 08:40:53.702565066 +0200
> @@ -143,7 +143,7 @@
>MSWR  [ui8 ]  0 (bytes 00)
>MVBO  [hex_]  (bytes ff ff)
>MVDC  [bin_]  (bytes 00)
> -  MVDS  [bin_]  (bytes 08)
> +  MVDS  [bin_]  (bytes 0a)
>MVE1  [si8 ]  (bytes 0d)
>MVE5  [si8 ]  (bytes 0b)
>MVHR  [flag]  (bytes 01)
> 
> However, even with my modified SmcDumpKeys.c which I can use to enable TDM, I
> cannot write to that key. Since other MV__ keys control the display, too, it
> would make sense that that is related to the display state, but it seems to 
> be a
> read-only key :-/
> 
> Running out of ideas again... any suggestions?

Sorry for the delay Florian.  Commit 564d8a2cf3ab by Mario Kleiner (+cc)
landed in Linus' tree last week and is included in 4.13-rc1.  It is
supposed to fix black screen issues with the iMac10,1 that you're also
using, though in Mario's case they seem to occur upon boot, rather than
on suspend, still might be worth a try:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=564d8a2cf3abf16575af48bdc3e86e92ee8a617d

Thanks,

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

[Bug 196297] nouveau 0000:03:00.0: disp: outp 03:0006:0f42: link training failed

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196297

sun.nagara...@gmail.com changed:

   What|Removed |Added

  Component|Video(DRI - non Intel)  |Console/Framebuffers

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Don't complain too much about struct_mutex.

[Peter Zijlstra]

On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote:
> A more complete solution would be to do the mutex_init in the drm core
> only for legacy drivers, plus add it to each modern driver that still
> needs it, which would also give each its own lockdep key. Trying to do
> that dynamically doesn't work, because lockdep requires it's keys to
> be statically allocated.

Would something like the below work? Its not pretty, but would give each
user of drm_dev_init() its own key.




diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 37b8ad3e30d8..06cc32012728 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -478,9 +478,10 @@ static void drm_fs_inode_free(struct inode *inode)
  * RETURNS:
  * 0 on success, or error code on failure.
  */
-int drm_dev_init(struct drm_device *dev,
-struct drm_driver *driver,
-struct device *parent)
+int __drm_dev_init(struct drm_device *dev,
+  struct drm_driver *driver,
+  struct device *parent,
+  struct lock_class_key *key)
 {
int ret;
 
@@ -496,7 +497,7 @@ int drm_dev_init(struct drm_device *dev,
 
spin_lock_init(&dev->buf_lock);
spin_lock_init(&dev->event_lock);
-   mutex_init(&dev->struct_mutex);
+   __mutex_init(&dev->struct_mutex, "&dev->struct_mutex", key);
mutex_init(&dev->filelist_mutex);
mutex_init(&dev->ctxlist_mutex);
mutex_init(&dev->master_mutex);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 53b98321df9b..cda11e97024e 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -531,9 +531,17 @@ void drm_printk(const char *level, unsigned int category,
const char *format, ...);
 extern unsigned int drm_debug;
 
-int drm_dev_init(struct drm_device *dev,
-struct drm_driver *driver,
-struct device *parent);
+int __drm_dev_init(struct drm_device *dev,
+  struct drm_driver *driver,
+  struct device *parent,
+  struct lock_class_key *key);
+
+#define drm_dev_init(_dev, _driver, _parent)   \
+({ \
+   static struct lock_class_key __key; \
+   __drm_dev_init((_dev), (_driver), (_parent), &__key);   \
+})
+
 void drm_dev_fini(struct drm_device *dev);
 
 struct drm_device *drm_dev_alloc(struct drm_driver *driver,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Fix leak in disable_all

[Maarten Lankhorst]

Op 15-07-17 om 11:31 schreef Daniel Vetter:
> The legacy plane->fb pointer is refcounted by calling
> drm_atomic_clean_old_fb().
>
> In practice this isn't a real problem because:
> - The caller in the i915 gpu reset code restores the original state
>   again, which means the plane->fb pointer won't change, hence can't
>   leak.
> - Drivers using drm_atomic_helper_shutdown call the fbdev cleanup
>   first, and that usually cleans up the fb through
>   drm_remove_framebuffer, which does this correctly.
> - Without fbdev the only framebuffers are from userspace, and those
>   get cleaned up (again using drm_remove_framebuffer) befor the driver
>   can even be unloaded.
>
> But in i915 I've switched the cleanup sequence around so that the
> _shutdown() calls happens after the drm_remove_framebuffer(), which is
> how I discovered this issue.
>
> v2: My analysis why the current code was ok for gpu reset and
> suspend/resume was correct, but then I totally failed to realize that
> we better keep this symmetric. Thanksfully CI noticed that for
> balance, a refcounting bug must exist at 2 places if previously there
> was no issue ...
>
> v3: Don't be lazy and compute the plane_mask in
> commit_duplicated_state properly too, instead of just using ~0U.
>
> Cc: martin.pe...@free.fr
> Cc: ch...@chris-wilson.co.uk
> Acked-by: Dave Airlie  (v1)
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index b07fc30372d3..545328a9a769 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2726,6 +2726,7 @@ int drm_atomic_helper_disable_all(struct drm_device 
> *dev,
>   struct drm_plane *plane;
>   struct drm_crtc_state *crtc_state;
>   struct drm_crtc *crtc;
> + unsigned plane_mask = 0;
>   int ret, i;
>  
>   state = drm_atomic_state_alloc(dev);
> @@ -2768,10 +2769,14 @@ int drm_atomic_helper_disable_all(struct drm_device 
> *dev,
>   goto free;
>  
>   drm_atomic_set_fb_for_plane(plane_state, NULL);
> + plane_mask |= BIT(drm_plane_index(plane));
> + plane->old_fb = plane->fb;
>   }
>  
>   ret = drm_atomic_commit(state);
>  free:
> + if (plane_mask)
> + drm_atomic_clean_old_fb(dev, plane_mask, ret);
>   drm_atomic_state_put(state);
>   return ret;
>  }
> @@ -2902,11 +2907,16 @@ int drm_atomic_helper_commit_duplicated_state(struct 
> drm_atomic_state *state,
>   struct drm_connector_state *new_conn_state;
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *new_crtc_state;
> + unsigned plane_mask = 0;
> + struct drm_device *dev = state->dev;
> + int ret;
>  
>   state->acquire_ctx = ctx;
>  
> - for_each_new_plane_in_state(state, plane, new_plane_state, i)
> + for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> + plane_mask |= BIT(drm_plane_index(plane));
We should really add a drm_plane_mask/drm_connector_mask at some point, to 
complement drm_crtc_mask.
>   state->planes[i].old_state = plane->state;
> + }
>  
>   for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
>   state->crtcs[i].old_state = crtc->state;
> @@ -2914,7 +2924,11 @@ int drm_atomic_helper_commit_duplicated_state(struct 
> drm_atomic_state *state,
>   for_each_new_connector_in_state(state, connector, new_conn_state, i)
>   state->connectors[i].old_state = connector->state;
>  
> - return drm_atomic_commit(state);
> + ret = drm_atomic_commit(state);
> + if (plane_mask)
> + drm_atomic_clean_old_fb(dev, plane_mask, ret);
Kill the if () part, and make it unconditional? On second thought, I should 
have done the same in drm_framebuffer.c
> + return ret;
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
>  


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

Re: drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

[Jani Nikula]

On Mon, 17 Jul 2017, David Binderman  wrote:
> Hello there,

Hello. No need to include LKML for stuff like this. But Cc'd the folks
from the broken commit.

> drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean 
> expression with an integer other than 0 or 1.
>
> Source code is
>
> else if ((ddb_allocation && ddb_allocation /
> fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 1)

Broken by

commit d555cb5827d603244969e08444340e3db78c8a37
Author: Kumar, Mahesh 
Date:   Wed May 17 17:28:29 2017 +0530

drm/i915/skl+: use linetime latency if ddb size is not available

The broken code has since been removed by bb9d85f6e9de ("drm/i915/skl:
New ddb allocation algorithm") but restored by 9a30a26122c3 ("Revert
"drm/i915/skl: New ddb allocation algorithm""). *sigh*.

Mahesh et al, please figure it out.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 13/14] drm: stm: remove dead code and pointless local lut storage

[Philippe CORNU]

On 07/13/2017 06:25 PM, Peter Rosin wrote:
> The redundant fb helper .load_lut is no longer used, and can not
> work right without also providing the fb helpers .gamma_set and
> .gamma_get thus rendering the code in this driver suspect.
> 
> Just remove the dead code.
> 
> Acked-by: Daniel Vetter 
> Signed-off-by: Peter Rosin 


Acked-by: Philippe Cornu 

Note: we will update stm32 clut support after your patch. Many thanks.

> ---
>   drivers/gpu/drm/stm/ltdc.c | 12 
>   drivers/gpu/drm/stm/ltdc.h |  1 -
>   2 files changed, 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 533176015cbb..3e95b4d1f4cc 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -375,17 +375,6 @@ static irqreturn_t ltdc_irq(int irq, void *arg)
>* DRM_CRTC
>*/
>   
> -static void ltdc_crtc_load_lut(struct drm_crtc *crtc)
> -{
> - struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> - unsigned int i, lay;
> -
> - for (lay = 0; lay < ldev->caps.nb_layers; lay++)
> - for (i = 0; i < 256; i++)
> - reg_write(ldev->regs, LTDC_L1CLUTWR + lay * LAY_OFS,
> -   ldev->clut[i]);
> -}
> -
>   static void ltdc_crtc_atomic_enable(struct drm_crtc *crtc,
>   struct drm_crtc_state *old_state)
>   {
> @@ -525,7 +514,6 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc *crtc,
>   }
>   
>   static struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
> - .load_lut = ltdc_crtc_load_lut,
>   .mode_set_nofb = ltdc_crtc_mode_set_nofb,
>   .atomic_flush = ltdc_crtc_atomic_flush,
>   .atomic_enable = ltdc_crtc_atomic_enable,
> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> index d7a9c736ac1e..620caabf 100644
> --- a/drivers/gpu/drm/stm/ltdc.h
> +++ b/drivers/gpu/drm/stm/ltdc.h
> @@ -27,7 +27,6 @@ struct ltdc_device {
>   struct drm_panel *panel;
>   struct mutex err_lock;  /* protecting error_status */
>   struct ltdc_caps caps;
> - u32 clut[256];  /* color look up table */
>   u32 error_status;
>   u32 irq_status;
>   };
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/dsi: Calculate link clock rates with updated dsi->lanes

[Archit Taneja]

After the commit mentioned below, we start computing the byte and pixel
clocks (dsi_calc_clk_rate) in the DSI bridge's mode_set() op. The
calculation involves the number of DSI lanes being used by the
downstream bridge/panel.

If the downstream bridge/panel tries to change the number of DSI lanes
(as done in the ADV7533 driver) in its mode_set() op, then our DSI
host driver will not have the correct number of lanes when computing
byte/pixel clocks.

Fix this by delaying the clock rate calculation in the DSI bridge
enable path. In particular, compute the clock rates in
msm_dsi_host_get_phy_clk_req().

This fixes the DSI host error interrupts seen when we try to switch
between modes that require different number of lanes (4 to 3 lanes, or
vice versa) on db410c. The error interrupts occur since the byte/pixel
clock rates aren't according to what the DSI video mode timing engine
expects.

Fixes: b62aa70a98c5 ("drm/msm/dsi: Move PHY operations out of host")
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 9e9c5696bc03..c7b612c3d771 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -2137,6 +2137,13 @@ void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host 
*host,
struct msm_dsi_phy_clk_request *clk_req)
 {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+   int ret;
+
+   ret = dsi_calc_clk_rate(msm_host);
+   if (ret) {
+   pr_err("%s: unable to calc clk rate, %d\n", __func__, ret);
+   return;
+   }
 
clk_req->bitclk_rate = msm_host->byte_clk_rate * 8;
clk_req->escclk_rate = msm_host->esc_clk_rate;
@@ -2280,7 +2287,6 @@ int msm_dsi_host_set_display_mode(struct mipi_dsi_host 
*host,
struct drm_display_mode *mode)
 {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
-   int ret;
 
if (msm_host->mode) {
drm_mode_destroy(msm_host->dev, msm_host->mode);
@@ -2293,12 +2299,6 @@ int msm_dsi_host_set_display_mode(struct mipi_dsi_host 
*host,
return -ENOMEM;
}
 
-   ret = dsi_calc_clk_rate(msm_host);
-   if (ret) {
-   pr_err("%s: unable to calc clk rate, %d\n", __func__, ret);
-   return ret;
-   }
-
return 0;
 }
 
-- 
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

Re: drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

[Mahesh Kumar]

Hi,


On Monday 17 July 2017 03:22 PM, Jani Nikula wrote:

On Mon, 17 Jul 2017, David Binderman  wrote:

Hello there,

Hello. No need to include LKML for stuff like this. But Cc'd the folks
from the broken commit.


drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean 
expression with an integer other than 0 or 1.

Source code is

 else if ((ddb_allocation && ddb_allocation /
 fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 1)

ddb_allocation being integer was intentional.
Other than that code has improper parentheses as well.
intention was if ddb_allocation is not 0 & (ddb_allocation / 
plane_blocks_per_line >= 1) then execute the condition.

it should have been
else if (ddb_allocation && (ddb_allocation / 
fixed_16_16_to_u32_round_up(plane_blocks_per_line) >= 1))


will post a fix.

thanks.

-Mahesh

Broken by

commit d555cb5827d603244969e08444340e3db78c8a37
Author: Kumar, Mahesh 
Date:   Wed May 17 17:28:29 2017 +0530

 drm/i915/skl+: use linetime latency if ddb size is not available

The broken code has since been removed by bb9d85f6e9de ("drm/i915/skl:
New ddb allocation algorithm") but restored by 9a30a26122c3 ("Revert
"drm/i915/skl: New ddb allocation algorithm""). *sigh*.

Mahesh et al, please figure it out.


BR,
Jani.




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

Re: drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

[Maarten Lankhorst]

Op 17-07-17 om 12:32 schreef Mahesh Kumar:
> Hi,
>
>
> On Monday 17 July 2017 03:22 PM, Jani Nikula wrote:
>> On Mon, 17 Jul 2017, David Binderman  wrote:
>>> Hello there,
>> Hello. No need to include LKML for stuff like this. But Cc'd the folks
>> from the broken commit.
>>
>>> drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean 
>>> expression with an integer other than 0 or 1.
>>>
>>> Source code is
>>>
>>>  else if ((ddb_allocation && ddb_allocation /
>>>  fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 1)
> ddb_allocation being integer was intentional.
> Other than that code has improper parentheses as well.
> intention was if ddb_allocation is not 0 & (ddb_allocation / 
> plane_blocks_per_line >= 1) then execute the condition.
> it should have been
> else if (ddb_allocation && (ddb_allocation / 
> fixed_16_16_to_u32_round_up(plane_blocks_per_line) >= 1))
>
> will post a fix.
>
> thanks.
>
> -Mahesh
>> Broken by
>>
>> commit d555cb5827d603244969e08444340e3db78c8a37
>> Author: Kumar, Mahesh 
>> Date:   Wed May 17 17:28:29 2017 +0530
>>
>>  drm/i915/skl+: use linetime latency if ddb size is not available
>>
>> The broken code has since been removed by bb9d85f6e9de ("drm/i915/skl:
>> New ddb allocation algorithm") but restored by 9a30a26122c3 ("Revert
>> "drm/i915/skl: New ddb allocation algorithm""). *sigh*.
>>
>> Mahesh et al, please figure it out.
>>
>>
>> BR,
>> Jani.
>>
>>
>
Would this work?

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 78b9acfc64c0..b9b3d8d45016 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4681,8 +4681,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
(plane_bytes_per_line / 512 < 1))
selected_result = method2;
-   else if ((ddb_allocation && ddb_allocation /
-   fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 
1)
+   else if (ddb_allocation >=
+fixed_16_16_to_u32_round_up(plane_blocks_per_line))
selected_result = min_fixed_16_16(method1, method2);
else if (latency >= linetime_us)
selected_result = min_fixed_16_16(method1, method2);

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

Re: drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

[Mahesh Kumar]

Hi,


On Monday 17 July 2017 04:01 PM, Maarten Lankhorst wrote:

Op 17-07-17 om 12:32 schreef Mahesh Kumar:

Hi,


On Monday 17 July 2017 03:22 PM, Jani Nikula wrote:

On Mon, 17 Jul 2017, David Binderman  wrote:

Hello there,

Hello. No need to include LKML for stuff like this. But Cc'd the folks
from the broken commit.


drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean 
expression with an integer other than 0 or 1.

Source code is

  else if ((ddb_allocation && ddb_allocation /
  fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 1)

ddb_allocation being integer was intentional.
Other than that code has improper parentheses as well.
intention was if ddb_allocation is not 0 & (ddb_allocation / plane_blocks_per_line 
>= 1) then execute the condition.
it should have been
 else if (ddb_allocation && (ddb_allocation / 
fixed_16_16_to_u32_round_up(plane_blocks_per_line) >= 1))

will post a fix.

thanks.

-Mahesh

Broken by

commit d555cb5827d603244969e08444340e3db78c8a37
Author: Kumar, Mahesh 
Date:   Wed May 17 17:28:29 2017 +0530

  drm/i915/skl+: use linetime latency if ddb size is not available

The broken code has since been removed by bb9d85f6e9de ("drm/i915/skl:
New ddb allocation algorithm") but restored by 9a30a26122c3 ("Revert
"drm/i915/skl: New ddb allocation algorithm""). *sigh*.

Mahesh et al, please figure it out.


BR,
Jani.



Would this work?

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 78b9acfc64c0..b9b3d8d45016 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4681,8 +4681,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
(plane_bytes_per_line / 512 < 1))
selected_result = method2;
-   else if ((ddb_allocation && ddb_allocation /
-   fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 
1)
+   else if (ddb_allocation >=
+fixed_16_16_to_u32_round_up(plane_blocks_per_line))

yes, this would even simplify the condition :)
-Mahesh

selected_result = min_fixed_16_16(method1, method2);
else if (latency >= linetime_us)
selected_result = min_fixed_16_16(method1, method2);



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

Re: [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support

[Hans Verkuil]

On 17/07/17 11:05, Russell King - ARM Linux wrote:
> On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
>> Hi Russell,
>>
>> On 09/06/17 16:10, Russell King - ARM Linux wrote:
>>> On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
 Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
 not used, but a custom one, so this notifier is actually useful for
 this platform and maybe others.
>>>
>>> Is the CEC controller configured into dw-hdmi (is the config bit set?)
>>> I'm just wondering if we're going to end up with two CEC drivers trying
>>> to bind to the same notifier.
>>>
 Should we really wait until I push the Amlogic AO CEC driver ? Having a
 notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
>>>
>>> It sounds like this adds additional information that has been missing
>>> from the review of my patches - and I suspect changes Hans' comments.
>>> So, I'll wait, it seems pointless to try and update the patches when
>>> it's not clear how to proceed due to other dependencies, especially
>>> when it means that their existing state is what's required (I'm pleased
>>> that I've held off modifying the patches so far.)
>>>
>>> If that means having to wait another kernel revision, then I guess that's
>>> what will have to happen.
>>
>> Can you respin your patch series, keeping the notifier support? The CEC
>> kernel config handling has been cleaned up (just select CEC_CORE and
>> CEC_NOTIFIER) so you should be good to go.
> 
> Not yet - the change to the way you're dealing with Kconfig in CEC is
> fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
> support.
> 
> As a result of these Kconfig changes, dw-hdmi-cec now fails if:
> 
> 1. You build the CEC part as a module
> 2. You build the HDMI part into the kernel
> 
> This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
> gets built, results in the stubs in the notifier code being used, rather
> than the real functions.  This in turn causes the CEC part to never
> receive a physical address, which is therefore non-functional.
> 
> I did have a patch to fix this, but it was never committed, and I got
> busy with other stuff (so it ended up being git reset --hard away.)
> 

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

Re: [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support

[Hans Verkuil]

On 17/07/17 11:05, Russell King - ARM Linux wrote:
> On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
>> Hi Russell,
>>
>> On 09/06/17 16:10, Russell King - ARM Linux wrote:
>>> On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
 Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
 not used, but a custom one, so this notifier is actually useful for
 this platform and maybe others.
>>>
>>> Is the CEC controller configured into dw-hdmi (is the config bit set?)
>>> I'm just wondering if we're going to end up with two CEC drivers trying
>>> to bind to the same notifier.
>>>
 Should we really wait until I push the Amlogic AO CEC driver ? Having a
 notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
>>>
>>> It sounds like this adds additional information that has been missing
>>> from the review of my patches - and I suspect changes Hans' comments.
>>> So, I'll wait, it seems pointless to try and update the patches when
>>> it's not clear how to proceed due to other dependencies, especially
>>> when it means that their existing state is what's required (I'm pleased
>>> that I've held off modifying the patches so far.)
>>>
>>> If that means having to wait another kernel revision, then I guess that's
>>> what will have to happen.
>>
>> Can you respin your patch series, keeping the notifier support? The CEC
>> kernel config handling has been cleaned up (just select CEC_CORE and
>> CEC_NOTIFIER) so you should be good to go.
> 
> Not yet - the change to the way you're dealing with Kconfig in CEC is
> fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
> support.
> 
> As a result of these Kconfig changes, dw-hdmi-cec now fails if:
> 
> 1. You build the CEC part as a module
> 2. You build the HDMI part into the kernel
> 
> This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
> gets built, results in the stubs in the notifier code being used, rather
> than the real functions.  This in turn causes the CEC part to never
> receive a physical address, which is therefore non-functional.
> 
> I did have a patch to fix this, but it was never committed, and I got
> busy with other stuff (so it ended up being git reset --hard away.)
> 

This is more a DRM_DW_HDMI issue than a CEC issue IMHO.

This will fix this:

config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER <<

config DRM_DW_HDMI_CEC
tristate "Synopsis Designware CEC interface"
depends on DRM_DW_HDMI
select CEC_CORE
select CEC_NOTIFIER
help
  Support the CE interface which is part of the Synopsis
  Designware HDMI block.

This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
used instead (as is apparently the case for amlogic), then the

select CEC_CORE if CEC_NOTIFIER

line ensures that CONFIG_CEC_CORE has the right m/y value.

Regards,

Hans

PS: Sorry for the empty reply earlier: I accidentally pressed 'Send' too soon 
:-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: select CEC_CORE if CEC_NOTIFIER

[Hans Verkuil]

If the s5p-cec driver is a module and the drm exynos driver is built-in, then
the CEC core will be a module also, causing the CEC notifier to fail (will be
compiled as empty functions).

To prevent this select CEC_CORE if CEC_NOTIFIER is set to ensure the CEC core
is also built into the kernel.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d185347c64c..305dc3d4ff77 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -75,6 +75,7 @@ config DRM_EXYNOS_DP
 config DRM_EXYNOS_HDMI
bool "HDMI"
depends on DRM_EXYNOS_MIXER || DRM_EXYNOS5433_DECON
+   select CEC_CORE if CEC_NOTIFIER
help
  Choose this option if you want to use Exynos HDMI for DRM.

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

[PATCH] drm/sti: select CEC_CORE if CEC_NOTIFIER

[Hans Verkuil]

If the stih-cec driver is a module and the drm sti driver is built-in, then
the CEC core will be a module also, causing the CEC notifier to fail (will be
compiled as empty functions).

To prevent this select CEC_CORE if CEC_NOTIFIER is set to ensure the CEC core
is also built into the kernel.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd72865feac..0eab3cb59fc5 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -8,5 +8,6 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
+   select CEC_CORE if CEC_NOTIFIER
help
  Choose this option to enable DRM on STM stiH4xx chipset
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()

[Imre Deak]

On Thu, May 12, 2016 at 04:00:40PM +0300, Imre Deak wrote:
> In case of an unknown broadcast message is sent mstb will remain unset,
> so check for this.
> 
> CC: Dave Airlie 
> Signed-off-by: Imre Deak 

Could someone review 2/3 and 3/3 in this patchset? 1/3 was NAK'd and
otherwise isn't needed anymore.

Thanks,
Imre

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 12c0ab3..412b9ca 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2334,7 +2334,9 @@ static int drm_dp_mst_handle_up_req(struct 
> drm_dp_mst_topology_mgr *mgr)
>   DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n", 
> msg.u.resource_stat.port_number, msg.u.resource_stat.available_pbn);
>   }
>  
> - drm_dp_put_mst_branch_device(mstb);
> + if (mstb)
> + drm_dp_put_mst_branch_device(mstb);
> +
>   memset(&mgr->up_req_recv, 0, sizeof(struct 
> drm_dp_sideband_msg_rx));
>   }
>   return ret;
> -- 
> 2.5.0
> 
> ___
> 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 2/4] drm/bridge: dw-hdmi: add cec notifier support

[Hans Verkuil]

On 17/07/17 14:05, Russell King - ARM Linux wrote:
> On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
>> On 17/07/17 11:05, Russell King - ARM Linux wrote:
>>> On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
 Hi Russell,

 On 09/06/17 16:10, Russell King - ARM Linux wrote:
> On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
>> Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
>> not used, but a custom one, so this notifier is actually useful for
>> this platform and maybe others.
>
> Is the CEC controller configured into dw-hdmi (is the config bit set?)
> I'm just wondering if we're going to end up with two CEC drivers trying
> to bind to the same notifier.
>
>> Should we really wait until I push the Amlogic AO CEC driver ? Having a
>> notifier in the DW-HDMI driver won't harm anybody since it *will be 
>> used*.
>
> It sounds like this adds additional information that has been missing
> from the review of my patches - and I suspect changes Hans' comments.
> So, I'll wait, it seems pointless to try and update the patches when
> it's not clear how to proceed due to other dependencies, especially
> when it means that their existing state is what's required (I'm pleased
> that I've held off modifying the patches so far.)
>
> If that means having to wait another kernel revision, then I guess that's
> what will have to happen.

 Can you respin your patch series, keeping the notifier support? The CEC
 kernel config handling has been cleaned up (just select CEC_CORE and
 CEC_NOTIFIER) so you should be good to go.
>>>
>>> Not yet - the change to the way you're dealing with Kconfig in CEC is
>>> fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
>>> support.
>>>
>>> As a result of these Kconfig changes, dw-hdmi-cec now fails if:
>>>
>>> 1. You build the CEC part as a module
>>> 2. You build the HDMI part into the kernel
>>>
>>> This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
>>> gets built, results in the stubs in the notifier code being used, rather
>>> than the real functions.  This in turn causes the CEC part to never
>>> receive a physical address, which is therefore non-functional.
>>>
>>> I did have a patch to fix this, but it was never committed, and I got
>>> busy with other stuff (so it ended up being git reset --hard away.)
>>>
>>
>> This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
>>
>> This will fix this:
>>
>> config DRM_DW_HDMI
>> tristate
>> select DRM_KMS_HELPER
>> select REGMAP_MMIO
>> select CEC_CORE if CEC_NOTIFIER  <<
>>
>> config DRM_DW_HDMI_CEC
>> tristate "Synopsis Designware CEC interface"
>> depends on DRM_DW_HDMI
>> select CEC_CORE
>> select CEC_NOTIFIER
>> help
>>   Support the CE interface which is part of the Synopsis
>>   Designware HDMI block.
>>
>> This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
>> used instead (as is apparently the case for amlogic), then the
>>
>>  select CEC_CORE if CEC_NOTIFIER
>>
>> line ensures that CONFIG_CEC_CORE has the right m/y value.
> 
> I disagree with this approach.
> 
> If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
> that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
> through dw-hdmi, even though we haven't asked for the CEC part to be
> enabled.

If CEC_NOTIFIER is enabled by a CEC driver, then CEC_CORE will also be
enabled (without CEC_CORE that driver wouldn't compile, obviously).

So I don't see the problem. All the select...if does is make sure that
the CEC_CORE can be reached from the HDMI driver if someone enabled the
CEC notifier (and thus CEC_CORE).

> You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
> with it, because that's basically what this boils down to.

That makes no sense.

If CEC_NOTIFIER is set, then both the CEC driver and the HDMI driver have to
select CEC_CORE to ensure the right dependency. If CEC_NOTIFIER is not set,
then only the CEC driver has to select CEC_CORE. In that case the CEC code
is typically either integrated into the HDMI driver or it is a standalone
device like the USB pulse8-cec driver.

Regards,

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

[Bug 101575] Lockup for executing trivial-tess-gs_no-gs-inputs.shader_test

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101575

--- Comment #3 from Hi-Angel  ---
Some more info: for hard lockup SysRq and network stops working. I managed to
get a trace for hard lockup using netconsole before network disappeared. An
interesting part may be "Wait for MC idle timedout !" — I never saw it before.

[ 3943.482116] radeon :01:00.0: ring 0 stalled for more than
10030msec
[ 3943.482135] radeon :01:00.0: GPU lockup (current fence id
0x00026550 last fence id 0x0002657b on ring 0)
[ 3943.482214] radeon :01:00.0: failed to get a new IB (-35)
[ 3943.482269] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to get ib
!
[ 3943.489601] radeon :01:00.0: Saved 1474 dwords of commands on
ring 0.
[ 3943.489623] radeon :01:00.0: GPU softreset: 0x009D
[ 3943.489629] radeon :01:00.0:   GRBM_STATUS   =
0xA0631CA0
[ 3943.489634] radeon :01:00.0:   GRBM_STATUS_SE0   =
0x1803
[ 3943.489639] radeon :01:00.0:   GRBM_STATUS_SE1   =
0x0007
[ 3943.489644] radeon :01:00.0:   SRBM_STATUS   =
0x200046C0
[ 3943.489649] radeon :01:00.0:   SRBM_STATUS2  =
0x
[ 3943.489654] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 =
0x0100
[ 3943.489660] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 =
0x00011000
[ 3943.489665] radeon :01:00.0:   R_00867C_CP_BUSY_STAT =
0x00068402
[ 3943.489670] radeon :01:00.0:   R_008680_CP_STAT  =
0x80870243
[ 3943.489675] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   =
0x60C83146
[ 3943.497932] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B
[ 3943.498011] radeon :01:00.0: SRBM_SOFT_RESET=0x00108100
[ 3943.499187] radeon :01:00.0:   GRBM_STATUS   =
0xC0003828
[ 3943.499196] radeon :01:00.0:   GRBM_STATUS_SE0   =
0x8007
[ 3943.499202] radeon :01:00.0:   GRBM_STATUS_SE1   =
0x0007
[ 3943.499207] radeon :01:00.0:   SRBM_STATUS   =
0x2CC0
[ 3943.499212] radeon :01:00.0:   SRBM_STATUS2  =
0x
[ 3943.499218] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 =
0x
[ 3943.499223] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 =
0x
[ 3943.499228] radeon :01:00.0:   R_00867C_CP_BUSY_STAT =
0x
[ 3943.499233] radeon :01:00.0:   R_008680_CP_STAT  =
0x
[ 3943.499239] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   =
0x44C83D57
[ 3943.499261] radeon :01:00.0: GPU reset succeeded, trying to
resume
[ 3943.499355] radeon :01:00.0: GPU softreset: 0x0001
[ 3943.499361] radeon :01:00.0:   GRBM_STATUS   =
0xC0003828
[ 3943.499366] radeon :01:00.0:   GRBM_STATUS_SE0   =
0x8007
[ 3943.499371] radeon :01:00.0:   GRBM_STATUS_SE1   =
0x0007
[ 3943.499376] radeon :01:00.0:   SRBM_STATUS   =
0x2CC0
[ 3943.499381] radeon :01:00.0:   SRBM_STATUS2  =
0x
[ 3943.499386] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 =
0x
[ 3943.499392] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 =
0x
[ 3943.499397] radeon :01:00.0:   R_00867C_CP_BUSY_STAT =
0x
[ 3943.499402] radeon :01:00.0:   R_008680_CP_STAT  =
0x
[ 3943.499407] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   =
0x44C83D57
[ 3943.880423] radeon :01:00.0: Wait for MC idle timedout !
[ 3943.880432] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6A
[ 3943.881600] radeon :01:00.0:   GRBM_STATUS   =
0xC0003828
[ 3943.881603] radeon :01:00.0:   GRBM_STATUS_SE0   =
0x8007
[ 3943.881606] radeon :01:00.0:   GRBM_STATUS_SE1   =
0x0007
[ 3943.881609] radeon :01:00.0:   SRBM_STATUS   =
0x2CC0
[ 3943.881612] radeon :01:00.0:   SRBM_STATUS2  =
0x
[ 3943.881615] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 =
0x
[ 3943.881618] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 =
0x
[ 3943.881621] radeon :01:00.0:   R_00867C_CP_BUSY_STAT =
0x
[ 3943.881625] radeon :01:00.0:   R_008680_CP_STAT  =
0x
[ 3943.881628] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   =
0x44C83D57

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

[Sinclair Yeh]

On Fri, Jul 14, 2017 at 10:28:29PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 14, 2017 at 9:23 PM, Linus Torvalds
>  wrote:
> > On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
> >  wrote:
> >>
> >> NAK. This takes unintentionally insane code and turns it intentionally
> >> insane. Any non-zero return is considered an error.
> >>
> >> The right fix is almost certainly to just return -EINVAL unconditionally.

Correct.  I'll fix this.

> >
> > Btw, this is why I hate compiler warning fix patch series. Even when
> > they don't actually break the code (and sometimes they do that too),
> > they can actually end up making the code worse.
> 
> I generally agree, and this is also why I held up sending patches for the
> -Wformat warnings until you brought those up. I also frequently send
> patches for recently introduced warnings, which tend to have a better
> chance of getting reviewed by the person that just introduced the code,
> to catch this kind of mistake in my patches.
> 
> I also regularly run into cases where I send a correct patch and find
> that another broken patch has been applied the following day ;-)
> 
> > The *intent* of that code was to return zero for the CAP_SYS_ADMIN.
> > But the code has never done that in its lifetime and nobody ever
> > noticed, so clearly the code shouldn't even have tried.
> 
> Makes sense, yes. In this case, the review process has failed as
> well, as one of the maintainers even gave an Ack on the wrong patch,
> and then the patch got dropped without any feedback.

I've done some digging and noticed that my -fixes pull request
didn't get picked up last December.  It's most likely because I
initially made an address typo in the original request, and then
followed it up with a direct email with the correct address.

Sinclair


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

[PATCH v3 0/3] Add support for the otm8009a dsi panel

[Philippe CORNU]

Version 3:
- panel-orisetech-otm8009a.c: Remove a FIXME (Andrzej Hajda)
- panel/Makefile & Kconfig: Alphabetical order (Andrzej Hajda)

Version 2:
- panel-orisetech-otm8009a.c: Add Manufacturer Command Set defines,
  add new macro for handling address shifting, improve reset
  sequence, use more mipi dcs helpers (Andrzej Hajda)
- dt-bindings/display/panel/orisetech,otm8009a.txt: Fix reset gpio
  active level in the example (Andrzej Hajda), Add an "Optional
  Properties" section (Rob Herring).

Version 1:
- Initial commit

The purpose of this patch is to add support for the Orise Tech
otm8009a 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode).
This LCD panel is used in several STM32 boards.

Philippe CORNU (3):
  dt-bindings: Add vendor prefix for Orise Technology
  dt-bindings: display: panel: Add support for Orise Tech otm8009a dsi
panel
  drm/panel: Add support for otm8009a panel driver

 .../bindings/display/panel/orisetech,otm8009a.txt  |  21 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/gpu/drm/panel/Kconfig  |   9 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c   | 491 +
 5 files changed, 523 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
 create mode 100755 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c

-- 
1.9.1

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

[PATCH v3 1/3] dt-bindings: Add vendor prefix for Orise Technology

[Philippe CORNU]

Orise Technology is headquartered in Taiwan and specializes
in manufacture of Flat Panel Display Driver IC and Flat Panel
Display Controller IC.

Signed-off-by: Philippe CORNU 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 834554f..4121b8a 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -235,6 +235,7 @@ ontat   On Tat Industrial Company
 opencores  OpenCores.org
 option Option NV
 ORCL   Oracle Corporation
+orisetech  Orise Technology
 ortustech  Ortus Technology Co., Ltd.
 ovti   OmniVision Technologies
 oxsemi Oxford Semiconductor, Ltd.
-- 
1.9.1

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

[PATCH v3 3/3] drm/panel: Add support for otm8009a panel driver

[Philippe CORNU]

This patch adds Orise Tech otm8009a 3.97" 480x800 TFT LCD
panel driver (MIPI-DSI video mode). The panel backlight is
managed through the DSI link. This panel driver is used in
several STM32 boards.

Signed-off-by: Philippe CORNU 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/Kconfig|   9 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 491 +++
 3 files changed, 501 insertions(+)
 create mode 100755 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d84a031..b7fffc7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -63,6 +63,15 @@ config DRM_PANEL_LG_LG4573
  Say Y here if you want to enable support for LG4573 RGB panel.
  To compile this driver as a module, choose M here.
 
+config DRM_PANEL_ORISETECH_OTM8009A
+   tristate "Orise Technology otm8009a 480x800 dsi 2dl panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Orise Technology
+ otm8009a 480x800 dsi 2dl panel.
+
 config DRM_PANEL_PANASONIC_VVX10F034N00
tristate "Panasonic VVX10F034N00 1920x1200 video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 9f6610d..51995b9 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
+obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
new file mode 100755
index 000..c189cd6
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu 
+ *  Yannick Fertre 
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "orisetech_otm8009a"
+
+#define OTM8009A_BACKLIGHT_DEFAULT 240
+#define OTM8009A_BACKLIGHT_MAX 255
+
+/* Manufacturer Command Set */
+#define MCS_ADRSFT 0x  /* Address Shift Function */
+#define MCS_PANSET 0xB3A6  /* Panel Type Setting */
+#define MCS_SD_CTRL0xC0A2  /* Source Driver Timing Setting */
+#define MCS_P_DRV_M0xC0B4  /* Panel Driving Mode */
+#define MCS_OSC_ADJ0xC181  /* Oscillator Adjustment for Idle/Normal mode */
+#define MCS_RGB_VID_SET0xC1A1  /* RGB Video Mode Setting */
+#define MCS_SD_PCH_CTRL0xC480  /* Source Driver Precharge Control */
+#define MCS_NO_DOC10xC48A  /* Command not documented */
+#define MCS_PWR_CTRL1  0xC580  /* Power Control Setting 1 */
+#define MCS_PWR_CTRL2  0xC590  /* Power Control Setting 2 for Normal Mode */
+#define MCS_PWR_CTRL4  0xC5B0  /* Power Control Setting 4 for DC Voltage */
+#define MCS_PANCTRLSET10xCB80  /* Panel Control Setting 1 */
+#define MCS_PANCTRLSET20xCB90  /* Panel Control Setting 2 */
+#define MCS_PANCTRLSET30xCBA0  /* Panel Control Setting 3 */
+#define MCS_PANCTRLSET40xCBB0  /* Panel Control Setting 4 */
+#define MCS_PANCTRLSET50xCBC0  /* Panel Control Setting 5 */
+#define MCS_PANCTRLSET60xCBD0  /* Panel Control Setting 6 */
+#define MCS_PANCTRLSET70xCBE0  /* Panel Control Setting 7 */
+#define MCS_PANCTRLSET80xCBF0  /* Panel Control Setting 8 */
+#define MCS_PANU2D10xCC80  /* Panel U2D Setting 1 */
+#define MCS_PANU2D20xCC90  /* Panel U2D Setting 2 */
+#define MCS_PANU2D30xCCA0  /* Panel U2D Setting 3 */
+#define MCS_PAND2U10xCCB0  /* Panel D2U Setting 1 */
+#define MCS_PAND2U20xCCC0  /* Panel D2U Setting 2 */
+#define MCS_PAND2U30xCCD0  /* Panel D2U Setting 3 */
+#define MCS_GOAVST 0xCE80  /* GOA VST Setting */
+#define MCS_GOACLKA1   0xCEA0  /* GOA CLKA1 Setting */
+#define MCS_GOACLKA3   0xCEB0  /* GOA CLKA3 Setting */
+#define MCS_GOAECLK0xCFC0  /* GOA ECLK Setting */
+#define MCS_NO_DOC20xCFD0  /* Command not documented */
+#define MCS_GVDDSET0xD800  /* GVDD/NGVDD */
+#define MCS_VCOMDC 0xD900  /* VCOM Voltage Setting */
+#define MCS_GMCT2_2P   0xE100  /* Gamma Correction 2.2+ Setting */
+#define MCS_GMCT2_2N   0xE200  /* Gamma Correction 2.2- Setting */
+#define MCS_NO_DOC30xF5B6  /* Command

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99851

--- Comment #50 from erhar...@mailbox.org ---
Any news on this? Just tried kernel 4.12.2 which is still affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/3] dt-bindings: display: panel: Add support for Orise Tech otm8009a dsi panel

[Philippe CORNU]

The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using
a MIPI-DSI video interface. Its backlight is managed through the DSI link.

Signed-off-by: Philippe CORNU 
Acked-by: Rob Herring 
---
 .../bindings/display/panel/orisetech,otm8009a.txt   | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt 
b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
new file mode 100644
index 000..6862028
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
@@ -0,0 +1,21 @@
+Orise Tech OTM8009A 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode)
+
+The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using
+a MIPI-DSI video interface. Its backlight is managed through the DSI link.
+
+Required properties:
+  - compatible: "orisetech,otm8009a"
+  - reg: the virtual channel number of a DSI peripheral
+
+Optional properties:
+  - reset-gpios: a GPIO spec for the reset pin (active low).
+
+Example:
+&dsi {
+   ...
+   panel@0 {
+   compatible = "orisetech,otm8009a";
+   reg = <0>;
+   reset-gpios = <&gpioh 7 GPIO_ACTIVE_LOW>;
+   };
+};
-- 
1.9.1

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

Re: [PATCH v2 3/3] drm/panel: Add support for otm8009a panel driver

[Philippe CORNU]

On 07/12/2017 04:12 PM, Andrzej Hajda wrote:
> On 10.07.2017 11:02, Philippe CORNU wrote:
>> This patch adds Orise Tech otm8009a 3.97" 480x800 TFT LCD
>> panel driver (MIPI-DSI video mode). The panel backlight is
>> managed through the DSI link. This panel driver is used in
>> several STM32 boards.
>>
>> Signed-off-by: Philippe CORNU 
>> ---
>>   drivers/gpu/drm/panel/Kconfig|   9 +
>>   drivers/gpu/drm/panel/Makefile   |   1 +
>>   drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 489 
>> +++
>>   3 files changed, 499 insertions(+)
>>   create mode 100755 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index d84a031..c1c9291 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -117,4 +117,13 @@ 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_ORISETECH_OTM8009A
>> +tristate "Orise Tech otm8009a 480p dsi 2dl video mode panel"
>> +depends on OF
>> +depends on DRM_MIPI_DSI
>> +depends on BACKLIGHT_CLASS_DEVICE
>> +help
>> +  Say Y here if you want to enable support for Orise Tech OTM8009A
>> +  480x800 DSI panel
>> +
>>   endmenu
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index 9f6610d..ac798f3 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -10,3 +10,4 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += 
>> panel-samsung-s6e8aa0.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_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
>> \ No newline at end of file
> 
> Alphabetical order and new line at EOF.
> 

Dear Andrzej,
Many thanks for your code review.
Makefile & Kconfig are now fixed in v3 following your comments.

>> diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
>> b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
>> new file mode 100755
>> index 000..2a3ce47
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
>> @@ -0,0 +1,489 @@
>> +/*
>> + * Copyright (C) STMicroelectronics SA 2017
>> + *
>> + * Authors: Philippe Cornu 
>> + *  Yannick Fertre 
>> + *
>> + * License terms:  GNU General Public License (GPL), version 2
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define DRV_NAME "orisetech_otm8009a"
>> +
>> +#define OTM8009A_BACKLIGHT_DEFAULT  240
>> +#define OTM8009A_BACKLIGHT_MAX  255
>> +
>> +/* Manufacturer Command Set */
>> +#define MCS_ADRSFT  0x  /* Address Shift Function */
>> +#define MCS_PANSET  0xB3A6  /* Panel Type Setting */
>> +#define MCS_SD_CTRL 0xC0A2  /* Source Driver Timing Setting */
>> +#define MCS_P_DRV_M 0xC0B4  /* Panel Driving Mode */
>> +#define MCS_OSC_ADJ 0xC181  /* Oscillator Adjustment for Idle/Normal mode */
>> +#define MCS_RGB_VID_SET 0xC1A1  /* RGB Video Mode Setting */
>> +#define MCS_SD_PCH_CTRL 0xC480  /* Source Driver Precharge Control */
>> +#define MCS_NO_DOC1 0xC48A  /* Command not documented */
>> +#define MCS_PWR_CTRL1   0xC580  /* Power Control Setting 1 */
>> +#define MCS_PWR_CTRL2   0xC590  /* Power Control Setting 2 for Normal 
>> Mode */
>> +#define MCS_PWR_CTRL4   0xC5B0  /* Power Control Setting 4 for DC 
>> Voltage */
>> +#define MCS_PANCTRLSET1 0xCB80  /* Panel Control Setting 1 */
>> +#define MCS_PANCTRLSET2 0xCB90  /* Panel Control Setting 2 */
>> +#define MCS_PANCTRLSET3 0xCBA0  /* Panel Control Setting 3 */
>> +#define MCS_PANCTRLSET4 0xCBB0  /* Panel Control Setting 4 */
>> +#define MCS_PANCTRLSET5 0xCBC0  /* Panel Control Setting 5 */
>> +#define MCS_PANCTRLSET6 0xCBD0  /* Panel Control Setting 6 */
>> +#define MCS_PANCTRLSET7 0xCBE0  /* Panel Control Setting 7 */
>> +#define MCS_PANCTRLSET8 0xCBF0  /* Panel Control Setting 8 */
>> +#define MCS_PANU2D1 0xCC80  /* Panel U2D Setting 1 */
>> +#define MCS_PANU2D2 0xCC90  /* Panel U2D Setting 2 */
>> +#define MCS_PANU2D3 0xCCA0  /* Panel U2D Setting 3 */
>> +#define MCS_PAND2U1 0xCCB0  /* Panel D2U Setting 1 */
>> +#define MCS_PAND2U2 0xCCC0  /* Panel D2U Setting 2 */
>> +#define MCS_PAND2U3 0xCCD0  /* Panel D2U Setting 3 */
>> +#define MCS_GOAVST  0xCE80  /* GOA VST Setting */
>> +#define MCS_GOACLKA10xCEA0  /* GOA CLKA1 Setting */
>> +#define MCS_GOACLKA30xCEB0  /* GOA CLKA3 Setting */
>> +#define MCS_GOAECLK 0xCFC0  /* GOA ECLK Setting */
>> +#define MCS_NO_DOC2 0xCFD0  /* Command not documented */
>> +#define MCS_GVDDSET 0xD800  /* GVDD/NGVDD */
>> +#define MCS_VCOMDC  0xD900  /* VCOM Voltage Set

Re: [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.

[Archit Taneja]

On 07/15/2017 04:31 AM, Eric Anholt wrote:

Archit Taneja  writes:


On 06/29/2017 04:09 PM, Andrzej Hajda wrote:

On 29.06.2017 07:03, Archit Taneja wrote:


On 06/28/2017 01:28 AM, Eric Anholt wrote:

When a mipi_dsi_host is registered, the DT is walked to find any child
nodes with compatible strings.  Those get registered as DSI devices,
and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes.

There is one special case currently, the adv7533 bridge, where the
bridge probes on I2C, and during the bridge attach step it looks up
the mipi_dsi_host and registers the mipi_dsi_device (for its own stub
mipi_dsi_driver).

For the Raspberry Pi panel, though, we also need to attach on I2C (our
control bus), but don't have a bridge driver.  The lack of a bridge's
attach() step like adv7533 uses means that we aren't able to delay the
mipi_dsi_device creation until the mipi_dsi_host is present.

To fix this, we extend mipi_dsi_device_register_full() to allow being
called with a NULL host, which puts the device on a queue waiting for
a host to appear.  When a new host is registered, we fill in the host
value and finish the device creation process.

This is quite a nice idea. The only bothering thing is the info.of_node usage
varies between child nodes (mipi_dsi_devs) and non-child nodes (i2c control
bus).

For DSI children expressed in DT, the of_node in info holds the DT node
corresponding to the DSI child itself. For non-DT ones, this patch assumes
that info.of_node stores the DSI host DT node. I think it should be okay as
long as we mention the usage in a comment somewhere. The other option is to
have a new info.host_node field to keep a track of the host DT node.


Field abuse is not a biggest issue.

This patch changes totally semantic of mipi_dsi_device_register_full.
Currently semantic of *_device_register* function is to create and add
device to existing bus, ie after return we have device attached to bus,
so it can be instantly used. With this change function can return some
unattached device, without warranty it will be ever attached - kind of
hidden deferring. Such change looks for me quite dangerous, even if it
looks convenient in this case.

As discussed in other thread more appealing solution for me would be:
1. host creates dsi bus, but doesn't call component_add as it does not
have all required resources.
2. host waits for all required dsi devs attached, gets registered panels
or bridges and calls component_add after that.
3. in bind phase it has all it needs, hasn't it?


This seems like it would work, but would require KMS drivers to restructure
themselves around this approach. For KMS drivers that don't even use the
component stuff, it might be asking too much.

We could maybe consider Eric's patch as an intermediate solution, we should
definitely put WARN_ON(!dsi->host) like checks for all the existing
mipi_dsi_*() API.


Could you clarify which entrypoints you'd like a warning on?  Is it just
"everything that gets the host ops"?


Sorry, all API was a bad suggestion.

I think a warning and early bail in mipi_dsi_attach() should be sufficient.
A panel/bridge DSI device shouldn't use any other API if it hasn't called
mipi_dsi_attach().

Thanks,
Archit





--
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 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

[Hans Verkuil]

On 14/07/17 11:36, Arnd Bergmann wrote:
> v4l2_subdev_call is a macro returning whatever the callback return
> type is, usually 'int'. With gcc-7 and ccache, this can lead to
> many wanings like:
> 
> media/platform/pxa_camera.c: In function 'pxa_mbus_build_fmts_xlate':
> media/platform/pxa_camera.c:766:27: error: ?: using integer constants in 
> boolean context [-Werror=int-in-bool-context]
>   while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, &code)) {
> media/atomisp/pci/atomisp2/atomisp_cmd.c: In function 'atomisp_s_ae_window':
> media/atomisp/pci/atomisp2/atomisp_cmd.c:6414:52: error: ?: using integer 
> constants in boolean context [-Werror=int-in-bool-context]
>   if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
> 
> The best workaround I could come up with is to change all the
> callers that use the return code from v4l2_subdev_call() in an
> 'if' or 'while' condition.
> 
> In case of simple 'if' checks, adding a temporary variable is
> usually ok, and sometimes this can be used to propagate or
> print an error code, so I do that.
> 
> For the 'while' loops, I ended up adding an otherwise useless
> comparison with zero, which unfortunately makes the code a little
> uglied.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/pci/cx18/cx18-ioctl.c  |  6 --
>  drivers/media/pci/saa7146/mxb.c  |  5 +++--
>  drivers/media/platform/atmel/atmel-isc.c |  4 ++--
>  drivers/media/platform/atmel/atmel-isi.c |  4 ++--
>  drivers/media/platform/blackfin/bfin_capture.c   |  4 ++--
>  drivers/media/platform/omap3isp/ispccdc.c|  5 +++--
>  drivers/media/platform/pxa_camera.c  |  3 ++-
>  drivers/media/platform/rcar-vin/rcar-core.c  |  2 +-
>  drivers/media/platform/rcar-vin/rcar-dma.c   |  4 +++-
>  drivers/media/platform/soc_camera/soc_camera.c   |  4 ++--
>  drivers/media/platform/stm32/stm32-dcmi.c|  4 ++--
>  drivers/media/platform/ti-vpe/cal.c  |  6 --
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 13 +++--
>  13 files changed, 37 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/media/pci/cx18/cx18-ioctl.c 
> b/drivers/media/pci/cx18/cx18-ioctl.c
> index 80b902b12a78..1803f28fc501 100644
> --- a/drivers/media/pci/cx18/cx18-ioctl.c
> +++ b/drivers/media/pci/cx18/cx18-ioctl.c
> @@ -188,6 +188,7 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
> void *fh,
>  {
>   struct cx18 *cx = fh2id(fh)->cx;
>   struct v4l2_sliced_vbi_format *vbifmt = &fmt->fmt.sliced;
> + int ret;
>  
>   /* sane, V4L2 spec compliant, defaults */
>   vbifmt->reserved[0] = 0;
> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
> void *fh,
>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
>* fmt->fmt.sliced under valid calling conditions
>*/
> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced))
> - return -EINVAL;
> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced);
> + if (ret)
> + return ret;

Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
wouldn't
break something.

>  
>   vbifmt->service_set = cx18_get_service_set(vbifmt);
>   return 0;



> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> index 97093baf28ac..fe56a037f065 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> @@ -6405,19 +6405,20 @@ int atomisp_s_ae_window(struct atomisp_sub_device 
> *asd,
>   struct atomisp_device *isp = asd->isp;
>   /* Coverity CID 298071 - initialzize struct */
>   struct v4l2_subdev_selection sel = { 0 };
> + int ret;
>  
>   sel.r.left = arg->x_left;
>   sel.r.top = arg->y_top;
>   sel.r.width = arg->x_right - arg->x_left + 1;
>   sel.r.height = arg->y_bottom - arg->y_top + 1;
>  
> - if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
> -  pad, set_selection, NULL, &sel)) {
> - dev_err(isp->dev, "failed to call sensor set_selection.\n");
> - return -EINVAL;
> - }
> + ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
> +pad, set_selection, NULL, &sel);
> + if (ret)
> + dev_err(isp->dev, "failed to call sensor set_selection: %d\n",
> + ret);

Same here: just keep the 'return -EINVAL'.

>  
> - return 0;
> + return ret;
>  }
>  
>  int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
> 

This is all very hackish, though. I'm not terribly keen on this patch. It's not
clear to me *why* these warnings appear in your setup.

Regards,

   

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

[Arnd Bergmann]

On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil  wrote:
> On 14/07/17 11:36, Arnd Bergmann wrote:
>> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
>> void *fh,
>>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
>>* fmt->fmt.sliced under valid calling conditions
>>*/
>> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced))
>> - return -EINVAL;
>> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced);
>> + if (ret)
>> + return ret;
>
> Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
> wouldn't
> break something.

I think Dan was recommending the opposite here, if I understood you
both correctly:
he said we should propagate the error code unless we know it's wrong, while you
want to keep the current behavior to avoid introducing changes ;-)

I guess in either case, looking at the callers more carefully would be
a good idea.

>> - return 0;
>> + return ret;
>>  }
>>
>>  int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
>>
>
> This is all very hackish, though. I'm not terribly keen on this patch. It's 
> not
> clear to me *why* these warnings appear in your setup.

it's possible that this only happened with 'ccache', which first preprocesses
the source and the passes it with v4l2_subdev_call expanded into the
compiler. This means the line looks like

if ((!(cx->sd_av) ? -ENODEV :
(((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ?
   (cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)),
&fmt->fmt.sliced) :
   -ENOIOCTLCMD))

The compiler now complains about the sub-expression that it sees for
cx->sd_av==NULL:

   if (-ENODEV)

which it considers nonsense because it is always true and the value gets
ignored.

Let me try again without ccache for now and see what warnings remain.
We can find a solution for those first, and then decide how to deal with
ccache.

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

[PATCH] drm/i915: Explicit the connector name for DP link training result

[Paul Kocialkowski]

This adds the connector name when printing a debug message about the DP
link training result. It is useful to figure out what connector is
failing when multiple DP connectors are used.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index b79c1c0e404c..75a411c94ce5 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -321,13 +321,15 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
if (!intel_dp_link_training_channel_equalization(intel_dp))
goto failure_handling;
 
-   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
- intel_dp->link_rate, intel_dp->lane_count);
+   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d 
for connector %s",
+ intel_dp->link_rate, intel_dp->lane_count,
+ intel_connector->base.name);
return;
 
  failure_handling:
-   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
- intel_dp->link_rate, intel_dp->lane_count);
+   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d 
for connector %s",
+ intel_dp->link_rate, intel_dp->lane_count,
+ intel_connector->base.name);
if (!intel_dp_get_link_train_fallback_values(intel_dp,
 intel_dp->link_rate,
 intel_dp->lane_count))
-- 
2.13.2

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

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

[Dan Carpenter]

On Mon, Jul 17, 2017 at 04:26:23PM +0200, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil  wrote:
> > On 14/07/17 11:36, Arnd Bergmann wrote:
> >> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file 
> >> *file, void *fh,
> >>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
> >>* fmt->fmt.sliced under valid calling conditions
> >>*/
> >> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced))
> >> - return -EINVAL;
> >> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, 
> >> &fmt->fmt.sliced);
> >> + if (ret)
> >> + return ret;
> >
> > Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
> > wouldn't
> > break something.
> 
> I think Dan was recommending the opposite here, if I understood you
> both correctly:
> he said we should propagate the error code unless we know it's wrong, while 
> you
> want to keep the current behavior to avoid introducing changes ;-)
> 

I don't know the subsystem rules at all, so don't listen to me.

regards,
dan carpenter

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

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

[Hans Verkuil]

On 17/07/17 16:26, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil  wrote:
>> On 14/07/17 11:36, Arnd Bergmann wrote:
>>> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
>>> void *fh,
>>>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
>>>* fmt->fmt.sliced under valid calling conditions
>>>*/
>>> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced))
>>> - return -EINVAL;
>>> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, 
>>> &fmt->fmt.sliced);
>>> + if (ret)
>>> + return ret;
>>
>> Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
>> wouldn't
>> break something.
> 
> I think Dan was recommending the opposite here, if I understood you
> both correctly:
> he said we should propagate the error code unless we know it's wrong, while 
> you
> want to keep the current behavior to avoid introducing changes ;-)
> 
> I guess in either case, looking at the callers more carefully would be
> a good idea.

The subtle problem here is that v4l2_subdev_call will return -ENOIOCTLCMD if
ops->vbi->g_sliced_fmt == NULL, which typically is not returned to userspace
but either ignored or replaced by another error. It indicates that the
sub device doesn't implement this operation, and it depends on the context
and the operation whether or not that is to be considered an error.

I have no clue what is expected here, without digging deep in the code.

Better to keep it as-is. It really isn't important to waste time on this.

> 
>>> - return 0;
>>> + return ret;
>>>  }
>>>
>>>  int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
>>>
>>
>> This is all very hackish, though. I'm not terribly keen on this patch. It's 
>> not
>> clear to me *why* these warnings appear in your setup.
> 
> it's possible that this only happened with 'ccache', which first preprocesses
> the source and the passes it with v4l2_subdev_call expanded into the
> compiler. This means the line looks like
> 
> if ((!(cx->sd_av) ? -ENODEV :
> (((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ?
>(cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)),
> &fmt->fmt.sliced) :
>-ENOIOCTLCMD))
> 
> The compiler now complains about the sub-expression that it sees for
> cx->sd_av==NULL:
> 
>if (-ENODEV)
> 
> which it considers nonsense because it is always true and the value gets
> ignored.
> 
> Let me try again without ccache for now and see what warnings remain.
> We can find a solution for those first, and then decide how to deal with
> ccache.

Sounds good.

I'm OK with applying this if there is no other way to prevent these warnings.

Regards,

Hans

> 
> Arnd
> 


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

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

[Hans Verkuil]

On 17/07/17 16:26, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil  wrote:
>> On 14/07/17 11:36, Arnd Bergmann wrote:
>>> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
>>> void *fh,
>>>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
>>>* fmt->fmt.sliced under valid calling conditions
>>>*/
>>> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced))
>>> - return -EINVAL;
>>> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, 
>>> &fmt->fmt.sliced);
>>> + if (ret)
>>> + return ret;
>>
>> Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
>> wouldn't
>> break something.
> 
> I think Dan was recommending the opposite here, if I understood you
> both correctly:
> he said we should propagate the error code unless we know it's wrong, while 
> you
> want to keep the current behavior to avoid introducing changes ;-)
> 
> I guess in either case, looking at the callers more carefully would be
> a good idea.

The subtle problem here is that v4l2_subdev_call will return -ENOIOCTLCMD if
ops->vbi->g_sliced_fmt == NULL, which typically is not returned to userspace
but either ignored or replaced by another error. It indicates that the
sub device doesn't implement this operation, and it depends on the context
and the operation whether or not that is to be considered an error.

I have no clue what is expected here, without digging deep in the code.

Better to keep it as-is. It really isn't important to waste time on this.

> 
>>> - return 0;
>>> + return ret;
>>>  }
>>>
>>>  int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
>>>
>>
>> This is all very hackish, though. I'm not terribly keen on this patch. It's 
>> not
>> clear to me *why* these warnings appear in your setup.
> 
> it's possible that this only happened with 'ccache', which first preprocesses
> the source and the passes it with v4l2_subdev_call expanded into the
> compiler. This means the line looks like
> 
> if ((!(cx->sd_av) ? -ENODEV :
> (((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ?
>(cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)),
> &fmt->fmt.sliced) :
>-ENOIOCTLCMD))
> 
> The compiler now complains about the sub-expression that it sees for
> cx->sd_av==NULL:
> 
>if (-ENODEV)
> 
> which it considers nonsense because it is always true and the value gets
> ignored.
> 
> Let me try again without ccache for now and see what warnings remain.
> We can find a solution for those first, and then decide how to deal with
> ccache.

Sounds good.

I'm OK with applying this if there is no other way to prevent these warnings.

Regards,

Hans

> 
> Arnd
> 


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

[Bug 98924] [AMDGPU][SI] R9 m265x doesn't work with experimental kernel driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98924

Stefano Cipriani  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Stefano Cipriani  ---
The GPU now works with AMDGPU driver on latest linux master. Playing some
Rocket League I had a couple of crashes, but the game was just updated so I
don't know if it was the kernel. Anyways, marking as fixed as it works now.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/sti: select CEC_CORE if CEC_NOTIFIER

[Benjamin Gaignard]

2017-07-17 13:50 GMT+02:00 Hans Verkuil :
> If the stih-cec driver is a module and the drm sti driver is built-in, then
> the CEC core will be a module also, causing the CEC notifier to fail (will be
> compiled as empty functions).
>
> To prevent this select CEC_CORE if CEC_NOTIFIER is set to ensure the CEC core
> is also built into the kernel.
>
> Signed-off-by: Hans Verkuil 

Thanks,

Acked-by: Benjamin Gaignard 

> ---
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index acd72865feac..0eab3cb59fc5 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -8,5 +8,6 @@ config DRM_STI
> select DRM_PANEL
> select FW_LOADER
> select SND_SOC_HDMI_CODEC if SND_SOC
> +   select CEC_CORE if CEC_NOTIFIER
> help
>   Choose this option to enable DRM on STM stiH4xx chipset



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Don't complain too much about struct_mutex.

[Daniel Vetter]

On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra  wrote:
> On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote:
>> A more complete solution would be to do the mutex_init in the drm core
>> only for legacy drivers, plus add it to each modern driver that still
>> needs it, which would also give each its own lockdep key. Trying to do
>> that dynamically doesn't work, because lockdep requires it's keys to
>> be statically allocated.
>
> Would something like the below work? Its not pretty, but would give each
> user of drm_dev_init() its own key.

We're very close to getting rid of struct_mutex, neither nouveau.ko
nor i915.ko use it, and only about 4 drivers really still need it (out
of about 30+). I think the minimal patch is enough, and then not
initializing the mutex to prevent more users croping up again in the
future.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/mxsfb: Use gem_free_object_unlocked

[Daniel Vetter]

CMA helpers are struct_mutex free, and so is the mxsfb itself. And
that's the only valid reason for using gem_free_object. Please read
the kerneldoc for this stuff :-)

Signed-off-by: Daniel Vetter 
Cc: Marek Vasut 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 1853557fef46..a34f41ce3599 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -334,7 +334,7 @@ static struct drm_driver mxsfb_driver = {
.irq_uninstall  = mxsfb_irq_preinstall,
.enable_vblank  = mxsfb_enable_vblank,
.disable_vblank = mxsfb_disable_vblank,
-   .gem_free_object= drm_gem_cma_free_object,
+   .gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
.dumb_create= drm_gem_cma_dumb_create,
.dumb_map_offset= drm_gem_cma_dumb_map_offset,
-- 
2.13.2

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

[PATCH 3/3] drm/zte: Use gem_free_object_unlocked

[Daniel Vetter]

CMA helpers are struct_mutex free, and so is the mxsfb itself. And
that's the only valid reason for using gem_free_object. Please read
the kerneldoc for this stuff :-)

Signed-off-by: Daniel Vetter 
Cc: Shawn Guo 
---
 drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index fe1aa5315e19..c983cdfa1e34 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -59,7 +59,7 @@ static struct drm_driver zx_drm_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
   DRIVER_ATOMIC,
.lastclose = zx_drm_lastclose,
-   .gem_free_object = drm_gem_cma_free_object,
+   .gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
.dumb_create = drm_gem_cma_dumb_create,
.dumb_map_offset = drm_gem_cma_dumb_map_offset,
-- 
2.13.2

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

[PATCH 2/3] drm/pl111: Use gem_free_object_unlocked

[Daniel Vetter]

CMA helpers are struct_mutex free, and so is the mxsfb itself. And
that's the only valid reason for using gem_free_object. Please read
the kerneldoc for this stuff :-)

Signed-off-by: Daniel Vetter 
Cc: Eric Anholt 
---
 drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index ac8771be70b0..8907bc261ab2 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -161,7 +161,7 @@ static struct drm_driver pl111_drm_driver = {
.dumb_create = drm_gem_cma_dumb_create,
.dumb_destroy = drm_gem_dumb_destroy,
.dumb_map_offset = drm_gem_cma_dumb_map_offset,
-   .gem_free_object = drm_gem_cma_free_object,
+   .gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
 
.enable_vblank = pl111_enable_vblank,
-- 
2.13.2

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

[Bug 196197] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196197

--- Comment #9 from Andreas Brogle (an...@ok.de) ---
Hello,

same problem with a ATI Radeon HD3450 graphics card (RV620).
Maybe the problem is mainboard specific, it is a TYAN S3992-E.

Life must go on.
Have installed a NVIDIA card now. That is working fine with the nouveau driver.

Greetings, Andreas

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Fix leak in disable_all

[Daniel Vetter]

On Mon, Jul 17, 2017 at 11:39:56AM +0200, Maarten Lankhorst wrote:
> Op 15-07-17 om 11:31 schreef Daniel Vetter:
> > The legacy plane->fb pointer is refcounted by calling
> > drm_atomic_clean_old_fb().
> >
> > In practice this isn't a real problem because:
> > - The caller in the i915 gpu reset code restores the original state
> >   again, which means the plane->fb pointer won't change, hence can't
> >   leak.
> > - Drivers using drm_atomic_helper_shutdown call the fbdev cleanup
> >   first, and that usually cleans up the fb through
> >   drm_remove_framebuffer, which does this correctly.
> > - Without fbdev the only framebuffers are from userspace, and those
> >   get cleaned up (again using drm_remove_framebuffer) befor the driver
> >   can even be unloaded.
> >
> > But in i915 I've switched the cleanup sequence around so that the
> > _shutdown() calls happens after the drm_remove_framebuffer(), which is
> > how I discovered this issue.
> >
> > v2: My analysis why the current code was ok for gpu reset and
> > suspend/resume was correct, but then I totally failed to realize that
> > we better keep this symmetric. Thanksfully CI noticed that for
> > balance, a refcounting bug must exist at 2 places if previously there
> > was no issue ...
> >
> > v3: Don't be lazy and compute the plane_mask in
> > commit_duplicated_state properly too, instead of just using ~0U.
> >
> > Cc: martin.pe...@free.fr
> > Cc: ch...@chris-wilson.co.uk
> > Acked-by: Dave Airlie  (v1)
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 18 --
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index b07fc30372d3..545328a9a769 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2726,6 +2726,7 @@ int drm_atomic_helper_disable_all(struct drm_device 
> > *dev,
> > struct drm_plane *plane;
> > struct drm_crtc_state *crtc_state;
> > struct drm_crtc *crtc;
> > +   unsigned plane_mask = 0;
> > int ret, i;
> >  
> > state = drm_atomic_state_alloc(dev);
> > @@ -2768,10 +2769,14 @@ int drm_atomic_helper_disable_all(struct drm_device 
> > *dev,
> > goto free;
> >  
> > drm_atomic_set_fb_for_plane(plane_state, NULL);
> > +   plane_mask |= BIT(drm_plane_index(plane));
> > +   plane->old_fb = plane->fb;
> > }
> >  
> > ret = drm_atomic_commit(state);
> >  free:
> > +   if (plane_mask)
> > +   drm_atomic_clean_old_fb(dev, plane_mask, ret);
> > drm_atomic_state_put(state);
> > return ret;
> >  }
> > @@ -2902,11 +2907,16 @@ int 
> > drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state,
> > struct drm_connector_state *new_conn_state;
> > struct drm_crtc *crtc;
> > struct drm_crtc_state *new_crtc_state;
> > +   unsigned plane_mask = 0;
> > +   struct drm_device *dev = state->dev;
> > +   int ret;
> >  
> > state->acquire_ctx = ctx;
> >  
> > -   for_each_new_plane_in_state(state, plane, new_plane_state, i)
> > +   for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> > +   plane_mask |= BIT(drm_plane_index(plane));
> We should really add a drm_plane_mask/drm_connector_mask at some point, to 
> complement drm_crtc_mask.
> > state->planes[i].old_state = plane->state;
> > +   }
> >  
> > for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > state->crtcs[i].old_state = crtc->state;
> > @@ -2914,7 +2924,11 @@ int drm_atomic_helper_commit_duplicated_state(struct 
> > drm_atomic_state *state,
> > for_each_new_connector_in_state(state, connector, new_conn_state, i)
> > state->connectors[i].old_state = connector->state;
> >  
> > -   return drm_atomic_commit(state);
> > +   ret = drm_atomic_commit(state);
> > +   if (plane_mask)
> > +   drm_atomic_clean_old_fb(dev, plane_mask, ret);
> Kill the if () part, and make it unconditional? On second thought, I should 
> have done the same in drm_framebuffer.c

I'd prefer to not bikeshed this stuff too much and just go with what we do
everywhere else (i.e. rmfb code and atomic commit) for consistency.
clean_old_fb is definitely a horrible function with misleading kerneldoc
on top, and I think the best way to clean that up would be to:

- Move the plane_mask computation in drm_atmic_commit and also put the
  clean_old_fb call in there. Maybe give it a more descriptive name like
  update_legacy_fb or whatever. Unexport them.

- This would break the compat helpers, where drm_atomic_commit must not
  update the legacy refcounts, because for set_config, page_flip and the
  plane hooks the core does that already. Create a
  drm_atomic_commit_legacy for these.

But since one of my patches caused an existing issue to pop up as a
regression, and this series fixes it, I'd like to first get the minimal
fix in through drm-

Re: [PATCH 3/3] drm: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()

[Lyude Paul]

Looks good to me.

Reviewed-by: Lyude 

On Mon, 2017-07-17 at 15:10 +0300, Imre Deak wrote:
> On Thu, May 12, 2016 at 04:00:40PM +0300, Imre Deak wrote:
> > In case of an unknown broadcast message is sent mstb will remain
> > unset,
> > so check for this.
> > 
> > CC: Dave Airlie 
> > Signed-off-by: Imre Deak 
> 
> Could someone review 2/3 and 3/3 in this patchset? 1/3 was NAK'd and
> otherwise isn't needed anymore.
> 
> Thanks,
> Imre
> 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 12c0ab3..412b9ca 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2334,7 +2334,9 @@ static int drm_dp_mst_handle_up_req(struct
> > drm_dp_mst_topology_mgr *mgr)
> > DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn
> > %d\n", msg.u.resource_stat.port_number,
> > msg.u.resource_stat.available_pbn);
> > }
> >  
> > -   drm_dp_put_mst_branch_device(mstb);
> > +   if (mstb)
> > +   drm_dp_put_mst_branch_device(mstb);
> > +
> > memset(&mgr->up_req_recv, 0, sizeof(struct
> > drm_dp_sideband_msg_rx));
> > }
> > return ret;
> > -- 
> > 2.5.0
> > 
> > ___
> > 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

[Bug 101787] colours all messed up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101787

--- Comment #3 from 247  ---
Created attachment 132735
  --> https://bugs.freedesktop.org/attachment.cgi?id=132735&action=edit
this is the dmesg file...

this is the dmesg file...i will post dmesg after boot and other thing you
requested in a moment...

and to answer your question, yes it was perfectly working in fedora 25...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101787] colours all messed up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101787

--- Comment #4 from 247  ---
Created attachment 132737
  --> https://bugs.freedesktop.org/attachment.cgi?id=132737&action=edit
dmesg gst debug_6

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101787] colours all messed up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101787

--- Comment #5 from 247  ---
Created attachment 132738
  --> https://bugs.freedesktop.org/attachment.cgi?id=132738&action=edit
dmesg after boot

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101787] colours all messed up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101787

--- Comment #6 from 247  ---
inserted all you requested...also, inputting your command in terminal results
in "wrong pipeline, no vaapih264enc"

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vgem: add compat_ioctl support

[Daniel Vetter]

On Fri, Jul 14, 2017 at 08:12:12PM -0700, Brian Norris wrote:
> DRM drivers should supply a compat version if they're going to provide
> an ioctl implementation at all. This can confuse 32-bit user space on a
> 64-bit system.
> 
> Signed-off-by: Brian Norris 

Thanks, applied.
-Daniel

> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 9fee38a942c4..3835656e2baf 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -220,6 +220,7 @@ static const struct file_operations vgem_driver_fops = {
>   .poll   = drm_poll,
>   .read   = drm_read,
>   .unlocked_ioctl = drm_ioctl,
> + .compat_ioctl   = drm_compat_ioctl,
>   .release= drm_release,
>  };
>  
> -- 
> 2.13.2.932.g7449e964c-goog
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101787] colours all messed up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101787

--- Comment #7 from Julien Isorce  ---
Thx for the logs but I do not see anything that could be associated to "radeon:
The kernel rejected CS, see dmesg for more information (-22)" in the first
dmesg attached.

Also about GST_DEBUG=6, do:   GST_DEBUG=6 transmageddon &> gst_debug.log
then do trigger the transcoding that generates the error above.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Don't complain too much about struct_mutex.

[Peter Zijlstra]

On Mon, Jul 17, 2017 at 05:06:42PM +0200, Daniel Vetter wrote:
> On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra  wrote:
> > On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote:
> >> A more complete solution would be to do the mutex_init in the drm core
> >> only for legacy drivers, plus add it to each modern driver that still
> >> needs it, which would also give each its own lockdep key. Trying to do
> >> that dynamically doesn't work, because lockdep requires it's keys to
> >> be statically allocated.
> >
> > Would something like the below work? Its not pretty, but would give each
> > user of drm_dev_init() its own key.
> 
> We're very close to getting rid of struct_mutex, neither nouveau.ko
> nor i915.ko use it, and only about 4 drivers really still need it (out
> of about 30+). I think the minimal patch is enough, and then not
> initializing the mutex to prevent more users croping up again in the
> future.

Whatever you want of course. I was just going by that one paragraphy I
quoted :-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

[Christian König]

Am 17.07.2017 um 05:36 schrieb Dave Airlie:

I can take a look at it, I just won't have time until next week most likely.

I've taken a look, and it's seemingly more complicated than I'm
expecting I'd want to land in Mesa before 17.2 ships, I'd really
prefer to just push the new libdrm_amdgpu api from this patch. If I
have to port all the current radv code to the new API, I'll most
definitely get something wrong.

Adding the new API so far looks like
https://cgit.freedesktop.org/~airlied/drm/log/?h=drm-amdgpu-cs-submit-raw

https://cgit.freedesktop.org/~airlied/drm/commit/?h=drm-amdgpu-cs-submit-raw&id=e7f85d0ca617fa41e72624780c9035df132e23c4
being the API, and whether it should take a uint32_t context id or
context handle left as an open question in the last patch in the
series.


I would stick with the context handle, as far as I can see there isn't 
any value in using the uint32_t for this.


We just want to be able to send arbitrary chunks down into the kernel 
without libdrm_amdgpu involvement and/or the associated overhead of the 
extra loop and the semaphore handling.


So your "amdgpu/cs: add new raw cs submission interface just taking 
chunks" patch looks fine to me as far as I can tell.


As far as I can see the "amdgpu: refactor semaphore handling" patch is 
actually incorrect. We must hole the mutex while sending the CS down to 
the kernel, or otherwise "context->last_seq" won't be accurate.



However to hook this into radv or radeonsi will take a bit of
rewriting of a lot of code that is probably a bit more fragile than
I'd like for this sort of surgery at this point.


Again, I can move over the existing Mesa stuff if you like.


I'd actually suspect if we do want to proceed with this type of
interface, we might be better doing it all in common mesa code, and
maybe bypassing libdrm_amdgpu altogether, which I suppose the API I've
written here is mostly already doing.


I want to stick with the other interfaces for now. No need to make it 
more complicated than it already is.


Only the CS stuff is the most performance critical and thing we have 
right now.


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

Re: [PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

[Christian König]

Am 14.07.2017 um 21:44 schrieb Felix Kuehling:

On 17-07-14 06:08 AM, Christian König wrote:

Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
[SNIP]

+result += bytes;
+buf = (uint8_t *)buf + bytes;
+pos += bytes;
+len -= bytes;
+if (pos >= (nodes->start + nodes->size) << PAGE_SHIFT) {
+++nodes;
+pos = (nodes->start << PAGE_SHIFT);

... Here I handle crossing a node boundary. Yes, I actually added this
case to my kfdtest unit test and made sure it works, along with all odd
alignments that the code above handles.


Ah, I see. Sorry totally missed that chunk. In this case the patch is 
Acked-by: Christian König 


Regards,
Christian.



Regards,
   Felix


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

Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

[Marek Olšák]

On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie  wrote:
>>
>> I can take a look at it, I just won't have time until next week most likely.
>
> I've taken a look, and it's seemingly more complicated than I'm
> expecting I'd want to land in Mesa before 17.2 ships, I'd really
> prefer to just push the new libdrm_amdgpu api from this patch. If I
> have to port all the current radv code to the new API, I'll most
> definitely get something wrong.
>
> Adding the new API so far looks like
> https://cgit.freedesktop.org/~airlied/drm/log/?h=drm-amdgpu-cs-submit-raw
>
> https://cgit.freedesktop.org/~airlied/drm/commit/?h=drm-amdgpu-cs-submit-raw&id=e7f85d0ca617fa41e72624780c9035df132e23c4
> being the API, and whether it should take a uint32_t context id or
> context handle left as an open question in the last patch in the
> series.
>
> However to hook this into radv or radeonsi will take a bit of
> rewriting of a lot of code that is probably a bit more fragile than
> I'd like for this sort of surgery at this point.
>
> I'd actually suspect if we do want to proceed with this type of
> interface, we might be better doing it all in common mesa code, and
> maybe bypassing libdrm_amdgpu altogether, which I suppose the API I've
> written here is mostly already doing.

Well, we plan to stop using the BO list ioctl. The interface has
bo_list_handle in it. Will we just set it to 0 when add the chunk for
the inlined buffer list i.e. what radeon has?

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

Re: [PATCH v2 5/5] dt-bindings: display: fill Documents for series of vop

[Rob Herring]

On Wed, Jul 12, 2017 at 10:04:02AM +0800, Mark Yao wrote:
> Changes in v2:
> - rename rk322x to rk3228(Heiko Stübner)

This goes below '---' and you need a commit msg here. Also, it is not 
clear in the subject this is for Rockchip.


> Signed-off-by: Mark Yao 
> ---
>  Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 
>  1 file changed, 4 insertions(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

[Christian König]

Am 17.07.2017 um 19:22 schrieb Marek Olšák:

On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie  wrote:

I can take a look at it, I just won't have time until next week most likely.

I've taken a look, and it's seemingly more complicated than I'm
expecting I'd want to land in Mesa before 17.2 ships, I'd really
prefer to just push the new libdrm_amdgpu api from this patch. If I
have to port all the current radv code to the new API, I'll most
definitely get something wrong.

Adding the new API so far looks like
https://cgit.freedesktop.org/~airlied/drm/log/?h=drm-amdgpu-cs-submit-raw

https://cgit.freedesktop.org/~airlied/drm/commit/?h=drm-amdgpu-cs-submit-raw&id=e7f85d0ca617fa41e72624780c9035df132e23c4
being the API, and whether it should take a uint32_t context id or
context handle left as an open question in the last patch in the
series.

However to hook this into radv or radeonsi will take a bit of
rewriting of a lot of code that is probably a bit more fragile than
I'd like for this sort of surgery at this point.

I'd actually suspect if we do want to proceed with this type of
interface, we might be better doing it all in common mesa code, and
maybe bypassing libdrm_amdgpu altogether, which I suppose the API I've
written here is mostly already doing.

Well, we plan to stop using the BO list ioctl. The interface has
bo_list_handle in it. Will we just set it to 0 when add the chunk for
the inlined buffer list i.e. what radeon has?


Yeah, exactly that was my thinking as well.

Christian.


Marek



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

Re: [PATCH 1/3] drm/mxsfb: Use gem_free_object_unlocked

[Eric Anholt]

Daniel Vetter  writes:

> CMA helpers are struct_mutex free, and so is the mxsfb itself. And
> that's the only valid reason for using gem_free_object. Please read
> the kerneldoc for this stuff :-)

I'm sure all of these came from copy and paste, not the docs.  That
said, the CMA docs currently say:

 * Drivers using the CMA helpers should set this as their
 * &drm_driver.gem_free_object callback.

If you drop the complaint about us reading the docs, the series is:

Reviewed-by: Eric Anholt 


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

Re: [PATCH 11/18] dt-bindings: display: Add Allwinner MIPI-DSI bindings

[Rob Herring]

On Thu, Jul 13, 2017 at 04:13:06PM +0200, Maxime Ripard wrote:
> The Allwinner SoCs usually come with a DSI encoder. Add a binding for it.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 85 +++-
>  1 file changed, 85 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> new file mode 100644
> index ..2e7c5aa7020f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> @@ -0,0 +1,85 @@
> +Allwinner A31 DSI Encoder
> +=
> +
> +The DSI pipeline consists of two separate blocks: the DSI controller
> +itself, and its associated D-PHY.
> +
> +DSI Encoder
> +---
> +
> +The DSI Encoder generates the DSI signal from the TCON's.
> +
> +Required properties:
> +  - compatible: value must be one of:
> +* allwinner,sun6i-a31-mipi-dsi
> +  - reg: base address and size of memory-mapped region
> +  - interrupts: interrupt associated to this IP
> +  - clocks: phandles to the clocks feeding the DSI encoder
> +* bus: the DSI interface clock
> +* mod: the DSI module clock
> +  - clock-names: the clock names mentioned above
> +  - phys: phandle to the D-PHY
> +  - phy-names: must be "dphy"
> +  - resets: phandle to the reset controller driving the encoder
> +
> +  - ports: A ports node with endpoint definitions as defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +port should be the input endpoint, usually coming from the
> +associated TCON.

Output port for bridge/panel?

> +
> +D-PHY
> +-
> +
> +Required properties:
> +  - compatible: value must be one of:
> +* allwinner,sun6i-a31-mipi-dphy
> +  - reg: base address and size of memory-mapped region
> +  - clocks: phandles to the clocks feeding the DSI encoder
> +* bus: the DSI interface clock
> +* mod: the DSI module clock
> +  - clock-names: the clock names mentioned above
> +  - resets: phandle to the reset controller driving the encoder
> +
> +Example:
> +
> +dsi0: dsi@01ca {

Drop the leading 0.

> + compatible = "allwinner,sun6i-a31-mipi-dsi";
> + reg = <0x01ca 0x1000>;
> + interrupts = ;
> + clocks = <&ccu CLK_BUS_MIPI_DSI>,
> +  <&ccu CLK_DSI_SCLK>;
> + clock-names = "bus", "mod";
> + resets = <&ccu RST_BUS_MIPI_DSI>;
> + phys = <&dphy0>;
> + phy-names = "dphy";

> + #address-cells = <1>;
> + #size-cells = <0>;

Not needed.

> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dsi0_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + dsi0_in_tcon0: endpoint@0 {
> + reg = <0>;

Don't need reg when there's only 1 endpoint.

> + remote-endpoint = <&tcon0_out_dsi0>;
> + };
> + };
> + };
> +};
> +
> +dphy0: d-phy@01ca1000 {

Drop leading 0.

> + compatible = "allwinner,sun6i-a31-mipi-dphy";
> + reg = <0x01ca1000 0x1000>;
> + clocks = <&ccu CLK_BUS_MIPI_DSI>,
> +  <&ccu CLK_DSI_DPHY>;
> + clock-names = "bus", "mod";
> + resets = <&ccu RST_BUS_MIPI_DSI>;

> + #address-cells = <1>;
> + #size-cells = <0>;

For what?

> + #phy-cells = <0>;
> +};
> -- 
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/18] dt-bindings: panel: Add Huarui LHR050H41 panel documentation

[Rob Herring]

On Thu, Jul 13, 2017 at 04:13:09PM +0200, Maxime Ripard wrote:
> The LHR050H41 is a 1280x700 4-lanes DSI panel.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/panel/huarui,lhr050h41.txt | 19 
> +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/huarui,lhr050h41.txt

Other than the question about the vendor name,

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

[Bug 196337] [amdgpu][carrizo] Re-enable GFX PG breaks Carrizo

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196337

Johannes Hirte (johannes.hi...@datenkhaos.de) changed:

   What|Removed |Added

Summary|Re-enable GFX PG breaks |[amdgpu][carrizo] Re-enable
   |Carrizo |GFX PG breaks Carrizo

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Return correct EDP voltage swing table for 0.85V

[Pandiyan, Dhinakaran]

Looks like a typo in 

cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.")

but Cc'ing Rodrigo, Clint to make sure this wasn't a workaround.

-DK


On Mon, 2017-07-17 at 11:21 -0700, Matthias Kaehlcke wrote:
> For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
> Use the correct table.
> 
> The error was pointed out by this clang warning:
> 
> drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
>   'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
>   [-Wunneeded-internal-declaration]
> static const struct cnl_ddi_buf_trans cnl_ddi_translations_edp_0_85V[] = {
> 
> Signed-off-by: Matthias Kaehlcke 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index efb13582dc73..6fa02e6a7a9b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1873,7 +1873,7 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
>   if (dev_priv->vbt.edp.low_vswing) {
>   if (voltage == VOLTAGE_INFO_0_85V) {
>   *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_85V);
> - return cnl_ddi_translations_dp_0_85V;
> + return cnl_ddi_translations_edp_0_85V;
>   } else if (voltage == VOLTAGE_INFO_0_95V) {
>   *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_95V);
>   return cnl_ddi_translations_edp_0_95V;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Return correct EDP voltage swing table for 0.85V

[Manasi Navare]

This makes sense, it should have returned the edp ddi buf translation
table as per the Bspec.
Please add this to the commit message:
Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")

After that,
Reviewed-by: Manasi Navare 

Manasi


On Mon, Jul 17, 2017 at 11:21:27AM -0700, Matthias Kaehlcke wrote:
> For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
> Use the correct table.
> 
> The error was pointed out by this clang warning:
> 
> drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
>   'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
>   [-Wunneeded-internal-declaration]
> static const struct cnl_ddi_buf_trans cnl_ddi_translations_edp_0_85V[] = {
> 
> Signed-off-by: Matthias Kaehlcke 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index efb13582dc73..6fa02e6a7a9b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1873,7 +1873,7 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
>   if (dev_priv->vbt.edp.low_vswing) {
>   if (voltage == VOLTAGE_INFO_0_85V) {
>   *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_85V);
> - return cnl_ddi_translations_dp_0_85V;
> + return cnl_ddi_translations_edp_0_85V;
>   } else if (voltage == VOLTAGE_INFO_0_95V) {
>   *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_95V);
>   return cnl_ddi_translations_edp_0_95V;
> -- 
> 2.13.2.932.g7449e964c-goog
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] dt-bindings: document the tegra CEC bindings

[Rob Herring]

On Sat, Jul 15, 2017 at 02:47:50PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This documents the binding for the Tegra CEC module.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/tegra-cec.txt| 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt 
> b/Documentation/devicetree/bindings/media/tegra-cec.txt
> new file mode 100644
> index ..ba0b6071acaa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/tegra-cec.txt
> @@ -0,0 +1,26 @@
> +* Tegra HDMI CEC driver

Bindings are for h/w, not drivers...

> +The HDMI CEC module is present in Tegra SoCs and its purpose is to
> +handle communication between HDMI connected devices over the CEC bus.
> +
> +Required properties:
> +  - compatible : value should be one of the following:
> + "nvidia,tegra114-cec"
> + "nvidia,tegra124-cec"
> + "nvidia,tegra210-cec"
> +  - reg : Physical base address of the IP registers and length of memory
> +   mapped region.
> +  - interrupts : HDMI CEC interrupt number to the CPU.
> +  - clocks : from common clock binding: handle to HDMI CEC clock.
> +  - clock-names : from common clock binding: must contain "cec",
> +   corresponding to ithe entry in the clocks property.

s/ithe/the/

> +  - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
> +
> +Example:
> +
> +tegra_cec {

cec@70015000

> + compatible = "nvidia,tegra124-cec";
> + reg = <0x0 0x70015000 0x0 0x1000>;
> + interrupts = ;
> + clocks = <&tegra_car TEGRA124_CLK_CEC>;
> + clock-names = "cec";
> -- 
> 2.11.0
> 
> ___
> 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 v2 1/5] dt-bindings: gpu: add the RK3399 mali for rockchip specifics

[Rob Herring]

On Mon, Jul 17, 2017 at 04:14:27PM +0800, Caesar Wang wrote:
> RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
> high-end graphics processors from ARM.
> 
> This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
> support IPA of gpu thermal in later.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

[Rob Herring]

On Mon, Jul 17, 2017 at 04:14:28PM +0800, Caesar Wang wrote:
> This patch adds the MALI's power-model to set the IPA model to be used
> for power management.

What's IPA? India Pale Ale or Intermediate Physical Address?

> 
> Signed-off-by: Caesar Wang 
> ---
> 
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
> b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> index a461e47..b616e6b 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -37,6 +37,18 @@ Optional properties:
>  - operating-points-v2 : Refer to 
> Documentation/devicetree/bindings/power/opp.txt
>for details.
>  
> +- power_model : Sets power model parameters. Note that this model was 
> designed for the Juno
> + platform, and may not be suitable for other platforms. A 
> structure containing :
> + - compatible: Should be arm,mali-simple-power-model
> + - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied
> +   by v^2*f to calculate the dynamic power consumption.
> + - static-coefficient: Coefficient, in uW/V^3, which is multiplied by
> +   v^3 to calculate the static power consumption.
> + - ts: An array containing coefficients for the temperature scaling
> +   factor. This is used to scale the static power by a factor of
> +   tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0],
> +   and T = temperature in degrees.
> + - thermal-zone: A string identifying the thermal zone used for the GPU

This can all easily be implied by the compatible string. I'm not 
inclined to accept something Mali specific here.

This looks *very* precise, but I'd be surprised if these values are any 
more than magic values (at least the dynamic coef) adjusted until the 
desired power/performance requirements are achieved. To put it another 
way, why don't we have similar values for CPUs? 

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

Re: Linux: Smooth splashscreen with system having weston with drm-backend

[Daniel Stone]

Hi Matt,

On 17 July 2017 at 20:39, Matt Hoosier  wrote:
> Also beware that the DRM backend of Weston will aggressively set the mode
> before you have any chance to paint user-defined content of your own in a
> Wayland client program. So there will still be some window of time during
> which your early splashscreen disappears and no specific application content
> replaces it.

Funnily enough, I'd say it's aggressively delayed. ;) It makes sure to
wait until the shell (usually desktop-shell) signals 'ready'. The 3.0
alpha just released should delay the modeset even further, to avoid a
flicker to black.

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

Re: [PATCH] drm/rockchip: cdn-dp: send audio infoframe to sink

[Sean Paul]

On Sat, Jul 15, 2017 at 07:00:18PM +0800, Chris Zhong wrote:
> Some DP/HDMI sink need to receive the audio infoframe to play sound,
> especially some multi-channel AV receiver, they need the
> channel_allocation from infoframe to config the speakers. Send the
> audio infoframe via SDP will make them work properly.
> 
> Signed-off-by: Chris Zhong 

Hi Chris,
Thanks for the patch, please see comments below.

> ---
> 
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 20 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 19 +++
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  |  6 ++
>  3 files changed, 45 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index 9b0b058..e59ca47 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -802,6 +802,7 @@ static int cdn_dp_audio_hw_params(struct device *dev,  
> void *data,
>   .sample_rate = params->sample_rate,
>   .channels = params->channels,
>   };
> + u8 buffer[14];

Why 14?

I think you should probably have buffer[HDMI_AUDIO_INFOFRAME_SIZE +
SDP_HEADER_SIZE] so the reader knows how you arrived at this value.

>   int ret;
>  
>   mutex_lock(&dp->lock);
> @@ -823,6 +824,25 @@ static int cdn_dp_audio_hw_params(struct device *dev,  
> void *data,
>   goto out;
>   }
>  
> + memset(buffer, 0, sizeof(buffer));
> +
> + ret = hdmi_audio_infoframe_pack(¶ms->cea, buffer, sizeof(buffer));
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to pack audio infoframe: %d\n", ret);
> + goto out;
> + }
> +
> + /*
> +  * Change the infoframe header to SDP header per DP 1.3 spec, Table
> +  * 2-98.
> +  */
> + buffer[0] = 0;
> + buffer[1] = HDMI_INFOFRAME_TYPE_AUDIO;
> + buffer[2] = 0x1b;
> + buffer[3] = 0x48;

Instead of doing this, consider splitting up hdmi_audio_infoframe_pack into
hdmi_audio_infoframe_pack and hdmi_audio_infoframe_pack_payload. The first
function does everything, while the second just packs the payload, then you can
set the SDP header independently.

> +
> + cdn_dp_sdp_write(dp, 0, buffer, sizeof(buffer));
> +
>   ret = cdn_dp_audio_config(dp, &audio);
>   if (!ret)
>   dp->audio_info = audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index b14d211..8907db0 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -951,6 +951,25 @@ static void cdn_dp_audio_config_spdif(struct 
> cdn_dp_device *dp)
>   clk_set_rate(dp->spdif_clk, CDN_DP_SPDIF_CLK);
>  }
>  
> +void cdn_dp_sdp_write(struct cdn_dp_device *dp, int entry_id, u8 *buf, u32 
> len)
> +{
> + int idx;
> + u32 *packet = (u32 *)buf;
> + u32 length = len / 4;

length and len are pretty terrible names, it would be quite easy to use the
wrong one. Consider more descriptive names (ie: buf_len and num_packets).

> + u8 type = buf[1];

Check for len < 0?

> +
> + for (idx = 0; idx < length; idx++)
> + writel(cpu_to_le32(*packet++), dp->regs + SOURCE_PIF_DATA_WR);
> +
> + writel(entry_id, dp->regs + SOURCE_PIF_WR_ADDR);
> +
> + writel(F_HOST_WR, dp->regs + SOURCE_PIF_WR_REQ);
> +
> + writel(PIF_PKT_TYPE_VALID | F_PACKET_TYPE(type) | entry_id,
> +dp->regs + SOURCE_PIF_PKT_ALLOC_REG);
> + writel(PIF_PKT_ALLOC_WR_EN, dp->regs + SOURCE_PIF_PKT_ALLOC_WR_EN);
> +}
> +
>  int cdn_dp_audio_config(struct cdn_dp_device *dp, struct audio_info *audio)
>  {
>   int ret;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> index c4bbb4a83..6ec0e81 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> @@ -424,6 +424,11 @@
>  /* Reference cycles when using lane clock as reference */
>  #define LANE_REF_CYC 0x8000
>  
> +#define F_HOST_WRBIT(0)
> +#define PIF_PKT_ALLOC_WR_EN  BIT(0)
> +#define PIF_PKT_TYPE_VALID   (3 << 16)
> +#define F_PACKET_TYPE(x) (((x) & 0xff) << 8)

Can you tuck these #defines under the definition of SOURCE_PIF_PKT_ALLOC_REG, so
we know which register they apply to?

> +
>  enum voltage_swing_level {
>   VOLTAGE_LEVEL_0,
>   VOLTAGE_LEVEL_1,
> @@ -478,5 +483,6 @@ int cdn_dp_set_video_status(struct cdn_dp_device *dp, int 
> active);
>  int cdn_dp_config_video(struct cdn_dp_device *dp);
>  int cdn_dp_audio_stop(struct cdn_dp_device *dp, struct audio_info *audio);
>  int cdn_dp_audio_mute(struct cdn_dp_device *dp, bool enable);
> +void cdn_dp_sdp_write(struct cdn_dp_device *dp, int entry_id, u8 *buf, u32 
> len);
>  int cdn_dp_audio_config(struct cdn_dp_device *dp, struct audio_info *audio);
>  #endif /* _CDN_DP_REG_H */
> -- 
> 2.6.3
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_

[PATCH v2] drm/i915: Return correct EDP voltage swing table for 0.85V

[Matthias Kaehlcke]

For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
Use the correct table.

The error was pointed out by this clang warning:

drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
  'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
  [-Wunneeded-internal-declaration]
static const struct cnl_ddi_buf_trans cnl_ddi_translations_edp_0_85V[] = {

Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Signed-off-by: Matthias Kaehlcke 
Reviewed-by: Manasi Navare 
---
Changes in v2:
- Added 'Fixes' tag
- Added Reviewed-by: Manasi Navare 

 drivers/gpu/drm/i915/intel_ddi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index efb13582dc73..6fa02e6a7a9b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1873,7 +1873,7 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
if (dev_priv->vbt.edp.low_vswing) {
if (voltage == VOLTAGE_INFO_0_85V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_85V);
-   return cnl_ddi_translations_dp_0_85V;
+   return cnl_ddi_translations_edp_0_85V;
} else if (voltage == VOLTAGE_INFO_0_95V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_95V);
return cnl_ddi_translations_edp_0_95V;
-- 
2.13.2.932.g7449e964c-goog

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

[PATCH 3/3] drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback

[Jose Abreu]

Currently we expect that clock driver produces the exact same value
as we are requiring. There can, and will, be some deviation
however so we need to take that into account instead of just
rejecting the mode.

According to the HDMI spec we have a max of +-0.5% for the pixel clock
frequency deviation. Lets take that into an advantage and use it to
calculate how much deviation we can support.

Signed-off-by: Jose Abreu 
Acked-by: Alexey Brodkin 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 1859dd3..55c5d5b 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -69,12 +69,13 @@ static enum drm_mode_status arc_pgu_crtc_mode_valid(struct 
drm_crtc *crtc,
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
long rate, clk_rate = mode->clock * 1000;
+   long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */
 
rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return MODE_NOCLOCK;
+   if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0))
+   return MODE_OK;
 
-   return MODE_OK;
+   return MODE_NOCLOCK;
 }
 
 static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
-- 
1.9.1


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

[PATCH 1/3] drm: arcpgu: Fix mmap() callback

[Jose Abreu]

Now that ARC properly supports DMA mmap() we can use the standard
CMA helper to map dumb buffers. This makes ARC PGU works with
standard DRM consumer applications like, for example, mpv/mplayer
via DRM. While at it, use the DEFINE_DRM_GEM_CMA_FOPS() helper.

This fixes the use of dumb buffers.

Signed-off-by: Jose Abreu 
Fixes: 0c4250e7b15e ("drm: Add support of ARC PGU display controller")
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 24 +---
 1 file changed, 1 insertion(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 3e43a5d..20ab68f 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -48,29 +48,7 @@ static void arcpgu_setup_mode_config(struct drm_device *drm)
drm->mode_config.funcs = &arcpgu_drm_modecfg_funcs;
 }
 
-static int arcpgu_gem_mmap(struct file *filp, struct vm_area_struct *vma)
-{
-   int ret;
-
-   ret = drm_gem_mmap(filp, vma);
-   if (ret)
-   return ret;
-
-   vma->vm_page_prot = pgprot_noncached(vm_get_page_prot(vma->vm_flags));
-   return 0;
-}
-
-static const struct file_operations arcpgu_drm_ops = {
-   .owner = THIS_MODULE,
-   .open = drm_open,
-   .release = drm_release,
-   .unlocked_ioctl = drm_ioctl,
-   .compat_ioctl = drm_compat_ioctl,
-   .poll = drm_poll,
-   .read = drm_read,
-   .llseek = no_llseek,
-   .mmap = arcpgu_gem_mmap,
-};
+DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
 
 static void arcpgu_lastclose(struct drm_device *drm)
 {
-- 
1.9.1


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

[PATCH 0/2] ASoC: hdmi-codec: Allow driver to restrict sample size

[srinivas . kandagatla]

From: Srinivas Kandagatla 

This patch adds option to allow hdmi-codec drivers to restrict
the audio sample size based on the values that are suppored in hardware.

First patch is adding that formats option to hdmi_codec_pdata and
second patch is a fix in adv7511 codec driver which only supports
16 and 24 bit samples.

Srinivas Kandagatla (2):
  ASoC: hdmi-codec: Allow drivers to restrict sample sizes.
  drm/bridge: adv7511: restrict audio sample sizes

 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 2 ++
 include/sound/hdmi-codec.h | 1 +
 sound/soc/codecs/hdmi-codec.c  | 3 +++
 3 files changed, 6 insertions(+)

-- 
2.11.0

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

Re: [PATCH] drm/etnaviv: select CMA and DMA_CMA if available

[Russell King - ARM Linux]

On Fri, Jul 14, 2017 at 04:38:01PM +0200, Lucas Stach wrote:
> While this is no build dependency, etnaviv will only work correctly on most
> systems if CMA and DMA_CMA are enabled. Select both options if available to
> avoid users ending up with a non-working GPU due to a lacking kernel config.

How does merely selecting CMA solve this problem?  Does CMA guarantee
that GPU command buffers will always be allocated in the lower 2G of
physical address space?

I suspect that's what you hope will happen, rather than a guarantee.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

DRM module unload and empty modesetting

[Jose Abreu]

Hi Daniel, all,

So, I was playing around with arcpgu and I found a bug at module
unloading. I corrected it and tested (using a 4.12 kernel) and I
got a nice WARNING from DRM core at unloading (instead of the old
NULL pointer I got :D). I debugged it and found out that an empty
modesetting (i.e. a mode with no clock) was being set by the core
and validated with crtc->atomic_check() callback. At arcpgu we
are expecting the clock value to be valid and > 0 so we were
rejecting the empty modesetting which caused the core to not set
the final mode before unloading.

I guess then it's expectable that atomic_check()/mode_valid()
callbacks can be called with an empty mode, right? Is this
documented anywhere?

Also, do we really need to call atomic check in this case? I
mean, its an empty modesetting and the mode is not valid so it
should be rejected, no?

Also notice that this error doesn't happen with 4.13 because we
switched to crtc->mode_valid() callback which instead is only
called if a full crtc/encoder/connector pipeline is set, which in
the case of unloading is not.

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support

[Russell King - ARM Linux]

On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
> On 17/07/17 11:05, Russell King - ARM Linux wrote:
> > On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
> >> Hi Russell,
> >>
> >> On 09/06/17 16:10, Russell King - ARM Linux wrote:
> >>> On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
>  Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
>  not used, but a custom one, so this notifier is actually useful for
>  this platform and maybe others.
> >>>
> >>> Is the CEC controller configured into dw-hdmi (is the config bit set?)
> >>> I'm just wondering if we're going to end up with two CEC drivers trying
> >>> to bind to the same notifier.
> >>>
>  Should we really wait until I push the Amlogic AO CEC driver ? Having a
>  notifier in the DW-HDMI driver won't harm anybody since it *will be 
>  used*.
> >>>
> >>> It sounds like this adds additional information that has been missing
> >>> from the review of my patches - and I suspect changes Hans' comments.
> >>> So, I'll wait, it seems pointless to try and update the patches when
> >>> it's not clear how to proceed due to other dependencies, especially
> >>> when it means that their existing state is what's required (I'm pleased
> >>> that I've held off modifying the patches so far.)
> >>>
> >>> If that means having to wait another kernel revision, then I guess that's
> >>> what will have to happen.
> >>
> >> Can you respin your patch series, keeping the notifier support? The CEC
> >> kernel config handling has been cleaned up (just select CEC_CORE and
> >> CEC_NOTIFIER) so you should be good to go.
> > 
> > Not yet - the change to the way you're dealing with Kconfig in CEC is
> > fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
> > support.
> > 
> > As a result of these Kconfig changes, dw-hdmi-cec now fails if:
> > 
> > 1. You build the CEC part as a module
> > 2. You build the HDMI part into the kernel
> > 
> > This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
> > gets built, results in the stubs in the notifier code being used, rather
> > than the real functions.  This in turn causes the CEC part to never
> > receive a physical address, which is therefore non-functional.
> > 
> > I did have a patch to fix this, but it was never committed, and I got
> > busy with other stuff (so it ended up being git reset --hard away.)
> > 
> 
> This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
> 
> This will fix this:
> 
> config DRM_DW_HDMI
> tristate
> select DRM_KMS_HELPER
> select REGMAP_MMIO
> select CEC_CORE if CEC_NOTIFIER   <<
> 
> config DRM_DW_HDMI_CEC
> tristate "Synopsis Designware CEC interface"
> depends on DRM_DW_HDMI
> select CEC_CORE
> select CEC_NOTIFIER
> help
>   Support the CE interface which is part of the Synopsis
>   Designware HDMI block.
> 
> This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
> used instead (as is apparently the case for amlogic), then the
> 
>   select CEC_CORE if CEC_NOTIFIER
> 
> line ensures that CONFIG_CEC_CORE has the right m/y value.

I disagree with this approach.

If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
through dw-hdmi, even though we haven't asked for the CEC part to be
enabled.

You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
with it, because that's basically what this boils down to.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] ASoC: hdmi-codec: Allow drivers to restrict sample sizes.

[srinivas . kandagatla]

From: Srinivas Kandagatla 

Currently hdmi client drivers does have means to limit the
sample sizes that it can only support. Having formats parameter
option would solve this.

This issue was noticed on DB410c board when adv7511 hdmi codec driver
failed to play a 32 bits audio samples, as it does not support them.

Signed-off-by: Srinivas Kandagatla 
---
 include/sound/hdmi-codec.h| 1 +
 sound/soc/codecs/hdmi-codec.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index 9483c55f871b..89fc4cce5785 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -104,6 +104,7 @@ struct hdmi_codec_pdata {
uint i2s:1;
uint spdif:1;
int max_i2s_channels;
+   u64 formats;
void *data;
 };
 
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 22ed0dc88f0a..1ece73f4be92 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -780,6 +780,9 @@ static int hdmi_codec_probe(struct platform_device *pdev)
hcp->daidrv[i] = hdmi_i2s_dai;
hcp->daidrv[i].playback.channels_max =
hcd->max_i2s_channels;
+
+   if (hcd->formats)
+   hcp->daidrv[i].playback.formats = hcd->formats;
i++;
}
 
-- 
2.11.0

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

[PATCH] drm/i915: Return correct EDP voltage swing table for 0.85V

[Matthias Kaehlcke]

For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
Use the correct table.

The error was pointed out by this clang warning:

drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
  'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
  [-Wunneeded-internal-declaration]
static const struct cnl_ddi_buf_trans cnl_ddi_translations_edp_0_85V[] = {

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/i915/intel_ddi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index efb13582dc73..6fa02e6a7a9b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1873,7 +1873,7 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
if (dev_priv->vbt.edp.low_vswing) {
if (voltage == VOLTAGE_INFO_0_85V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_85V);
-   return cnl_ddi_translations_dp_0_85V;
+   return cnl_ddi_translations_edp_0_85V;
} else if (voltage == VOLTAGE_INFO_0_95V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_95V);
return cnl_ddi_translations_edp_0_95V;
-- 
2.13.2.932.g7449e964c-goog

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

[PATCH 0/3] arcpgu: Fixes and improvements

[Jose Abreu]

Hi all,

Two fixes and an improvement for arcpgu. I've sent this patches in separate
but I've now collected them all to ease the review.

Best regards,
Jose Miguel Abreu

Jose Abreu (3):
  drm: arcpgu: Fix mmap() callback
  drm: arcpgu: Fix module unload
  drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback

Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 

 drivers/gpu/drm/arc/arcpgu_crtc.c |  7 ---
 drivers/gpu/drm/arc/arcpgu_drv.c  | 26 ++
 2 files changed, 6 insertions(+), 27 deletions(-)

-- 
1.9.1


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

[PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders

[Matthias Kaehlcke]

The current code uses in some instances enum transcoder for PCH
transcoders and enum pipe in others. This is error prone and clang
raises warnings like this:

drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
  from enumeration type 'enum pipe' to different enumeration type
  'enum transcoder' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);

Consistently use the type enum pipe for PCH transcoders.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v2:
- rebased on drm-intel/drm-intel-next-queued

 drivers/gpu/drm/i915/i915_irq.c| 10 +-
 drivers/gpu/drm/i915/intel_display.c   | 24 ++--
 drivers/gpu/drm/i915/intel_drv.h   |  6 +++---
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  6 +++---
 4 files changed, 21 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1d33cea01a1b..0b6f310101ee 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2086,10 +2086,10 @@ static void ibx_irq_handler(struct drm_i915_private 
*dev_priv, u32 pch_iir)
DRM_DEBUG_DRIVER("PCH transcoder CRC error interrupt\n");
 
if (pch_iir & SDE_TRANSA_FIFO_UNDER)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
 
if (pch_iir & SDE_TRANSB_FIFO_UNDER)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
 }
 
 static void ivb_err_int_handler(struct drm_i915_private *dev_priv)
@@ -2123,13 +2123,13 @@ static void cpt_serr_int_handler(struct 
drm_i915_private *dev_priv)
DRM_ERROR("PCH poison interrupt\n");
 
if (serr_int & SERR_INT_TRANS_A_FIFO_UNDERRUN)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
 
if (serr_int & SERR_INT_TRANS_B_FIFO_UNDERRUN)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
 
if (serr_int & SERR_INT_TRANS_C_FIFO_UNDERRUN)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_C);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_C);
 
I915_WRITE(SERR_INT, serr_int);
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bb9c9c3c391f..5c7054c3be0e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1777,7 +1777,7 @@ static void lpt_enable_pch_transcoder(struct 
drm_i915_private *dev_priv,
 
/* FDI must be feeding us bits for PCH ports */
assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
-   assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
+   assert_fdi_rx_enabled(dev_priv, PIPE_A);
 
/* Workaround: set timing override bit. */
val = I915_READ(TRANS_CHICKEN2(PIPE_A));
@@ -1853,16 +1853,16 @@ void lpt_disable_pch_transcoder(struct drm_i915_private 
*dev_priv)
I915_WRITE(TRANS_CHICKEN2(PIPE_A), val);
 }
 
-enum transcoder intel_crtc_pch_transcoder(struct intel_crtc *crtc)
+enum pipe intel_crtc_pch_transcoder(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 
WARN_ON(!crtc->config->has_pch_encoder);
 
if (HAS_PCH_LPT(dev_priv))
-   return TRANSCODER_A;
+   return PIPE_A;
else
-   return (enum transcoder) crtc->pipe;
+   return crtc->pipe;
 }
 
 /**
@@ -1901,7 +1901,7 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
if (crtc->config->has_pch_encoder) {
/* if driving the PCH, we need FDI enabled */
assert_fdi_rx_pll_enabled(dev_priv,
- (enum pipe) 
intel_crtc_pch_transcoder(crtc));
+ 
intel_crtc_pch_transcoder(crtc));
assert_fdi_tx_pll_enabled(dev_priv,
  (enum pipe) cpu_transcoder);
}
@@ -4579,7 +4579,7 @@ static void lpt_pch_enable(const struct intel_crtc_state 
*crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
 
-   assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
+   assert_pch_transcoder_disabled(dev_priv, PIPE_A);
 
lpt_program_iclkip(crtc);
 
@ -5347,8 +5347,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
return;
 
if (intel_crtc->config->has_pch_encoder)
-   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
-  

[PATCH 2/3] drm: arcpgu: Fix module unload

[Jose Abreu]

At module unload we are expecting a struct drm_device but at
probing we are not setting it right. Fix this and correct the
arcpgu module unload.

Signed-off-by: Jose Abreu 
Fixes: 0c4250e7b15e ("drm: Add support of ARC PGU display controller")
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 20ab68f..8abc987 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -120,7 +120,7 @@ static int arcpgu_load(struct drm_device *drm)
return -ENODEV;
}
 
-   platform_set_drvdata(pdev, arcpgu);
+   platform_set_drvdata(pdev, drm);
return 0;
 }
 
-- 
1.9.1


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

Re: [RFC 1/3] clk: inherit display clocks enabled by bootloader

[Nayak, Rajendra]

On 7/14/2017 4:13 PM, Rob Clark wrote:

On Fri, Jul 14, 2017 at 12:52 AM, Rajendra Nayak  wrote:

Hi Rob,

On 07/11/2017 11:50 PM, Rob Clark wrote:

The goal here is to support inheriting a display setup by bootloader,
although there may also be some non-display related use-cases.

Rough idea is to add a flag for clks and power domains that might
already be enabled when kernel starts, and make corresponding fixups
to clk enable/prepare_count and power-domain state so that these are
not automatically disabled late in boot.

If bootloader is enabling display, and kernel is using efifb before
real display driver is loaded (potentially from kernel module after
userspace starts, in a typical distro kernel), we don't want to kill
the clocks and power domains that are used by the display before
userspace starts.

Second part is for drm/msm to check if display related clocks are
enabled when it is loaded, and if so read back hw state to sync
existing display state w/ software state, and skip the initial
clk_enable's and otherwise fixing up clk/regulator/etc ref counts
(skipping the normal display-enable codepaths), therefore inheriting
the enable done by bootloader.

Obviously this should be split up into multiple patches and many
TODOs addressed.  But I guess this is enough for now to start
discussing the approach, and in particular how drm and clock/pd
drivers work together to handle handover from bootloader.

The CLK_INHERIT_BOOTLOADER and related gsdc flag should only be set
on leaf nodes.
---


[]..


diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index d523991c945f..90b698c910d0 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -11,6 +11,7 @@
   * GNU General Public License for more details.
   */

+#include 
  #include 
  #include 
  #include 
@@ -258,6 +259,33 @@ int qcom_cc_really_probe(struct platform_device *pdev,
   if (ret)
   return ret;

+ /* Check which of clocks that we inherit state from bootloader
+  * are enabled, and fixup enable/prepare state (as well as that
+  * of it's parents).
+  *
+  * TODO can we assume that parents coming from another clk
+  * driver are already registered?
+  */
+ for (i = 0; i < num_clks; i++) {
+ struct clk_hw *hw;
+
+ if (!rclks[i])
+ continue;
+
+ hw = &rclks[i]->hw;
+
+ if (!(hw->init->flags & CLK_INHERIT_BOOTLOADER))
+ continue;
+
+ if (!clk_is_enabled_regmap(hw))
+ continue;
+
+ dev_dbg(dev, "%s is enabled from bootloader!\n",
+   hw->init->name);
+
+ clk_inherit_enabled(hw->clk);


how about just calling a clk_prepare_enable(hw->clk) instead of adding a new 
API?
The flag could also be something qcom specific and then we avoid having to add
anything in generic CCF code and its all handled in the qcom clock drivers.


Hmm, I could try that..  I *guess* it doesn't hurt to enable an
already enabled clk..


yes, ideally it shouldn't hurt.



beyond that, I wonder if this is something that other platforms would
want, so maybe I should be doing the check for enabled in CCF core?
If not, making this a qcom specific flag makes sense.


I think most previous attempts to solve this were done trying to keep
it very generic and they didn't go too far.
So I was thinking maybe we could deal with it within qcom drivers for
now, and if others come up with something similar, then look to
consolidate at a generic CCF level.




+ }
+
   reset = &cc->reset;
   reset->rcdev.of_node = dev->of_node;
   reset->rcdev.ops = &qcom_reset_ops;


[] ..


diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index a4f3580587b7..440d819b2d9d 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -291,6 +291,12 @@ static int gdsc_init(struct gdsc *sc)
   if ((sc->flags & VOTABLE) && on)
   gdsc_enable(&sc->pd);

+ if ((sc->flags & INHERIT_BL) && on) {
+ pr_debug("gdsc: %s is enabled from bootloader!\n", sc->pd.name);
+ gdsc_enable(&sc->pd);
+ sc->pd.flags |= GENPD_FLAG_ALWAYS_ON;


Would this not prevent the powerdomain from ever getting disabled?


Yeah, this is a hack, because I couldn't figure out something better.
The problem is that gdsc/powerdomain doesn't have it's own
enable_count but this is tracked at the device level (afaict.. maybe
I'm miss-understanding something).  I guess we could add our own
enable_count within gdsc?  Suggestions welcome, since I don't know
these parts of the code so well.


One way to deal with it would be to tell the genpd core, that the gdsc
isn't really enabled, so it does not go ahead and disable it thinking
its unused.

Once the display driver comes up, it runtime enables/disables it.
I am guessing, if the bootloader turns on the gdsc, there will also
be a kernel driver to handle it.

So I am basically s