[Bug 93548] Grid Autosport causes a hard system crash

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEEDINFO|RESOLVED

-- 
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: [PATCHv3 0/2] drm/bridge/adv7511: add CEC support

[Archit Taneja]

On 10/07/2017 04:16 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.



queued to drm-misc-next.

Thanks,
Archit


Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S

Regards,

Hans

Changes since v2:
- A small rewording of the 'clocks' property description in the bindings
   as per Sergei's comment.

Changes since v1:
- Incorporate Archit's comments:
use defines for irq masks
combine the adv7511/33 regmap_configs
adv7511_cec_init now handles dt parsing & CEC registration
- Use the new (4.14) CEC_CAP_DEFAULTS define

Hans Verkuil (2):
   dt-bindings: adi,adv7511.txt: document cec clock
   drm: adv7511/33: add HDMI CEC support

  .../bindings/display/bridge/adi,adv7511.txt|   4 +
  drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  43 ++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 337 +
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 116 ++-
  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  38 +--
  7 files changed, 489 insertions(+), 58 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] Simplify panel bridge cleanup

[Archit Taneja]

On 10/02/2017 03:02 PM, Benjamin Gaignard wrote:

The goal of this series is to simplify driver code when they need to clean up
a previously allocated panel bridge.
Few drivers have "is_panel_bridge" flag to be able to distinguish a
drm_panel_bridge from "simple" drm_bridge.
To remove this flag I propose to
- let drm_panel_bridge_remove() check if the bridge provided in parameter is
   really a drm_panel_bridge.
- add drm_of_panel_bridge_remove() to remove a bridge given DT port and
   endpoint
Finally that allow to remove drm_bridge structure and "is_panel_bridge" flag
from stm driver internal structure.

version 2:
- does the same for vc4 and dw-mipi-dsi

For the series:

Reviewed-by: Archit Taneja 

Feel free to queue to drm-misc-next.

Thanks,
Archit



Benjamin Gaignard (5):
   drm/bridge: make drm_panel_bridge_remove more robust
   drm/drm_of: add drm_of_panel_bridge_remove function
   drm/stm: ltdc: remove bridge from driver internal structure
   drm/vc4: remove bridge from driver internal structure
   drm/bridge/synopsys: dsi :remove is_panel_bridge

  drivers/gpu/drm/bridge/panel.c| 10 +++-
  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c |  5 +---
  drivers/gpu/drm/drm_of.c  | 33 +++
  drivers/gpu/drm/stm/ltdc.c| 16 -
  drivers/gpu/drm/stm/ltdc.h|  2 --
  drivers/gpu/drm/vc4/vc4_dpi.c | 17 +-
  include/drm/drm_of.h  |  8 +++
  7 files changed, 62 insertions(+), 29 deletions(-)



--
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 1/2] drm/msm/dsi: Use correct pm_runtime_put variant during host_init

[Archit Taneja]

On 10/06/2017 07:32 PM, Daniel Vetter wrote:

On Fri, Oct 06, 2017 at 04:27:06PM +0530, Archit Taneja wrote:

The DSI runtime PM suspend/resume callbacks check whether
msm_host->cfg_hnd is non-NULL before trying to enable the bus clocks.
This is done to accommodate early calls to these functions that may
happen before the bus clocks are even initialized.

Calling pm_runtime_put_autosuspend() in dsi_host_init() can result in
racy behaviour since msm_host->cfg_hnd is set very soon after. If the
suspend callback happens too late, we end up trying to disable clocks
that were never enabled, resulting in a bunch of WARN_ON splats.


Sounds like the correct fix here is to block autosuspend until after
everything is set up, including bus clocks. This patch just makes the race
harder to hit in practice ...


Thanks for the review. pm_runtime_put_sync() ensures that the suspend handler
is called in the same context as that of the caller, right? msm_host->cfg_hnd
is set to a non-NULL value only when we return from dsi_get_config(). The race
would never happen in this case.

This call is a one time thing during DSI probe, we do a pm_runtime_get_sync()
just so that we can read the block revision number. Once we have the revision
number, we look at an internal table which maintains IP version specific
resources, like what bus clocks to get, etc. Having pm_runtime_put_autosuspend()
here didn't help much anyway.

Archit



-Daniel



Use pm_runtime_put_sync() so that the suspend callback is called
immediately.

Reported-by: Nicolas Dechesne 
Signed-off-by: Archit Taneja 
---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index dbb31a014419..deaf869374ea 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -248,7 +248,7 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
clk_disable_unprepare(ahb_clk);
  disable_gdsc:
regulator_disable(gdsc_reg);
-   pm_runtime_put_autosuspend(dev);
+   pm_runtime_put_sync(dev);
  put_clk:
clk_put(ahb_clk);
  put_gdsc:
--
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




--
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

[PATCH v4 08/11] drm/sun4i: hdmi: Add A31 specific DDC register definitions

[Chen-Yu Tsai]

The DDC block for the HDMI controller is different on the A31.

This patch adds the register definitions.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 3057e31219f6..ee42ae7e5a21 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -153,6 +153,37 @@
 
 #define SUN4I_HDMI_DDC_FIFO_SIZE   16
 
+/* A31 specific */
+#define SUN6I_HDMI_DDC_CTRL_REG0x500
+#define SUN6I_HDMI_DDC_CTRL_RESET  BIT(31)
+#define SUN6I_HDMI_DDC_CTRL_START_CMD  BIT(27)
+#define SUN6I_HDMI_DDC_CTRL_SDA_ENABLE BIT(6)
+#define SUN6I_HDMI_DDC_CTRL_SCL_ENABLE BIT(4)
+#define SUN6I_HDMI_DDC_CTRL_ENABLE BIT(0)
+
+#define SUN6I_HDMI_DDC_CMD_REG 0x508
+#define SUN6I_HDMI_DDC_CMD_BYTE_COUNT(count)   ((count) << 16)
+/* command types in lower 3 bits are the same as sun4i */
+
+#define SUN6I_HDMI_DDC_ADDR_REG0x50c
+#define SUN6I_HDMI_DDC_ADDR_SEGMENT(seg)   (((seg) & 0xff) << 24)
+#define SUN6I_HDMI_DDC_ADDR_EDDC(addr) (((addr) & 0xff) << 16)
+#define SUN6I_HDMI_DDC_ADDR_OFFSET(off)(((off) & 0xff) << 8)
+#define SUN6I_HDMI_DDC_ADDR_SLAVE(addr)(((addr) & 0xff) << 1)
+
+#define SUN6I_HDMI_DDC_INT_STATUS_REG  0x514
+#define SUN6I_HDMI_DDC_INT_STATUS_TIMEOUT  BIT(8)
+/* lower 8 bits are the same as sun4i */
+
+#define SUN6I_HDMI_DDC_FIFO_CTRL_REG   0x518
+#define SUN6I_HDMI_DDC_FIFO_CTRL_CLEAR BIT(15)
+/* lower 9 bits are the same as sun4i */
+
+#define SUN6I_HDMI_DDC_CLK_REG 0x520
+/* DDC CLK bit fields are the same, but the formula is not */
+
+#define SUN6I_HDMI_DDC_FIFO_DATA_REG   0x580
+
 enum sun4i_hdmi_pkt_type {
SUN4I_HDMI_PKT_AVI = 2,
SUN4I_HDMI_PKT_END = 15,
-- 
2.14.2

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

[PATCH v4 05/11] drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent

[Chen-Yu Tsai]

On SoCs with two display pipelines, it is possible that the two
pipelines are active at the same time, with potentially incompatible
dot clocks.

Let the HDMI encoder's TMDS clock go through all of its parents when
calculating possible clock rates. This allows usage of the second video
PLL as its parent.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 53 -
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index 5cf2527bffc8..e8d4c311b80d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -67,11 +67,11 @@ static unsigned long sun4i_tmds_calc_divider(unsigned long 
rate,
 static int sun4i_tmds_determine_rate(struct clk_hw *hw,
 struct clk_rate_request *req)
 {
-   struct clk_hw *parent;
+   struct clk_hw *parent = NULL;
unsigned long best_parent = 0;
unsigned long rate = req->rate;
int best_div = 1, best_half = 1;
-   int i, j;
+   int i, j, p;
 
/*
 * We only consider PLL3, since the TCON is very likely to be
@@ -79,32 +79,37 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
 * clock, so we should not need to do anything.
 */
 
-   parent = clk_hw_get_parent_by_index(hw, 0);
-   if (!parent)
-   return -EINVAL;
-
-   for (i = 1; i < 3; i++) {
-   for (j = 1; j < 16; j++) {
-   unsigned long ideal = rate * i * j;
-   unsigned long rounded;
-
-   rounded = clk_hw_round_rate(parent, ideal);
-
-   if (rounded == ideal) {
-   best_parent = rounded;
-   best_half = i;
-   best_div = j;
-   goto out;
-   }
-
-   if (abs(rate - rounded / i) <
-   abs(rate - best_parent / best_div)) {
-   best_parent = rounded;
-   best_div = i;
+   for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
+   parent = clk_hw_get_parent_by_index(hw, p);
+   if (!parent)
+   continue;
+
+   for (i = 1; i < 3; i++) {
+   for (j = 1; j < 16; j++) {
+   unsigned long ideal = rate * i * j;
+   unsigned long rounded;
+
+   rounded = clk_hw_round_rate(parent, ideal);
+
+   if (rounded == ideal) {
+   best_parent = rounded;
+   best_half = i;
+   best_div = j;
+   goto out;
+   }
+
+   if (abs(rate - rounded / i) <
+   abs(rate - best_parent / best_div)) {
+   best_parent = rounded;
+   best_div = i;
+   }
}
}
}
 
+   if (!parent)
+   return -EINVAL;
+
 out:
req->rate = best_parent / best_half / best_div;
req->best_parent_rate = best_parent;
-- 
2.14.2

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

[PATCH v4 10/11] ARM: dts: sun6i: Add device node for HDMI controller

[Chen-Yu Tsai]

Now that we support the HDMI controller on the A31 SoC, we can add it
to the device tree.

This adds a device node for the HDMI controller, and the of_graph nodes
connecting it to the 2 TCONs.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 55 
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 93209cda28db..48b2382a18a9 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -289,6 +289,12 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+   tcon0_out_hdmi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<_in_tcon0>;
+   allwinner,tcon-channel = <1>;
+   };
};
};
};
@@ -331,6 +337,12 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+   tcon1_out_hdmi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<_in_tcon1>;
+   allwinner,tcon-channel = <1>;
+   };
};
};
};
@@ -411,6 +423,49 @@
#size-cells = <0>;
};
 
+   hdmi: hdmi@01c16000 {
+   compatible = "allwinner,sun6i-a31-hdmi";
+   reg = <0x01c16000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_AHB1_HDMI>, < CLK_HDMI>,
+< CLK_HDMI_DDC>,
+< CLK_PLL_VIDEO0_2X>,
+< CLK_PLL_VIDEO1_2X>;
+   clock-names = "ahb", "mod", "ddc", "pll-0", "pll-1";
+   resets = < RST_AHB1_HDMI>;
+   reset-names = "ahb";
+   dma-names = "ddc-tx", "ddc-rx", "audio-tx";
+   dmas = < 13>, < 13>, < 14>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hdmi_in_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_hdmi>;
+   };
+
+   hdmi_in_tcon1: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<_out_hdmi>;
+   };
+   };
+
+   hdmi_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
usb_otg: usb@01c19000 {
compatible = "allwinner,sun6i-a31-musb";
reg = <0x01c19000 0x0400>;
-- 
2.14.2

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

[PATCH v4 11/11] ARM: dts: sun6i: Enable HDMI support on some A31/A31s devices

[Chen-Yu Tsai]

All the A31/A31s devices I own have some kind of HDMI connector wired
to the dedicated HDMI pins on the SoC:

  - A31 Hummingbird (standard HDMI connector, display already enabled)
  - Sinlinx SinA31s (standard HDMI connector)
  - MSI Primo81 tablet (micro HDMI connector)

Enable the display pipeline (if needed) and HDMI output for them.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 21 +
 arch/arm/boot/dts/sun6i-a31s-primo81.dts| 25 +
 arch/arm/boot/dts/sun6i-a31s-sina31s.dts| 25 +
 3 files changed, 71 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 9ecb5f0b3f83..19e382a11297 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -62,6 +62,17 @@
stdout-path = "serial0:115200n8";
};
 
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+
vga-connector {
compatible = "vga-connector";
 
@@ -162,6 +173,16 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts 
b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
index 4c10123509c4..0cdb38ab3377 100644
--- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -52,17 +52,42 @@
 / {
model = "MSI Primo81 tablet";
compatible = "msi,primo81", "allwinner,sun6i-a31s";
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "c";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
 };
 
  {
cpu-supply = <_dcdc3>;
 };
 
+ {
+   status = "okay";
+};
+
  {
/* rtl8188etv wifi is connected here */
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
  {
/* pull-ups and device VDDIO use AXP221 DLDO3 */
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts 
b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
index b3d98222bd81..298476485bb4 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
@@ -53,6 +53,17 @@
stdout-path = "serial0:115200n8";
};
 
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -90,6 +101,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
/* USB 2.0 4 port hub IC */
status = "okay";
@@ -112,6 +127,16 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.14.2

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

[PATCH v4 04/11] drm/sun4i: hdmi: create a regmap for later use

[Chen-Yu Tsai]

The HDMI driver is written with readl/writel I/O to the registers.
However, to support the A31 variant, which has a different layout
for the DDC registers, it was recommended to use regfields to have
a cleaner implementation. To use regfields, we need to create an
underlying regmap.

This patch only adds the regmap. It does not convert the existing
driver accesses to use regmap.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  1 +
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 15 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index a1f8cba251a2..aef157d3b659 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -163,6 +163,7 @@ struct sun4i_hdmi {
struct device   *dev;
 
void __iomem*base;
+   struct regmap   *regmap;
 
/* Parent clocks */
struct clk  *bus_clk;
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 3cf1a6932fac..5ab811cda00e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sun4i_backend.h"
 #include "sun4i_crtc.h"
@@ -267,6 +268,13 @@ static const struct cec_pin_ops sun4i_hdmi_cec_pin_ops = {
 };
 #endif
 
+static const struct regmap_config sun4i_hdmi_regmap_config = {
+   .reg_bits   = 32,
+   .val_bits   = 32,
+   .reg_stride = 4,
+   .max_register   = 0x580,
+};
+
 static int sun4i_hdmi_bind(struct device *dev, struct device *master,
   void *data)
 {
@@ -321,6 +329,13 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
goto err_disable_mod_clk;
}
 
+   hdmi->regmap = devm_regmap_init_mmio(dev, hdmi->base,
+_hdmi_regmap_config);
+   if (IS_ERR(hdmi->regmap)) {
+   dev_err(dev, "Couldn't create HDMI encoder regmap\n");
+   return PTR_ERR(hdmi->regmap);
+   }
+
ret = sun4i_tmds_create(hdmi);
if (ret) {
dev_err(dev, "Couldn't create the TMDS clock\n");
-- 
2.14.2

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

[PATCH v4 07/11] drm/sun4i: hdmi: Add support for controller hardware variants

[Chen-Yu Tsai]

The HDMI controller found in earlier Allwinner SoCs have slight
differences between the A10, A10s, and the A31:

  - Need different initial values for the PLL related registers

  - Different behavior of the DDC and TMDS clocks

  - Different register layout for the DDC portion

  - Separate DDC parent clock on the A31

  - Explicit reset control

For the A31, the HDMI TMDS clock has a different value offset for
the divider. The HDMI DDC block is different from the one in the
other SoCs. As far as the DDC clock goes, it has no pre-divider,
as it is clocked from a slower parent clock, not the TMDS clock.
The divider offset from the register value is different. And the
clock control register is at a different offset.

A new variant data structure is created to store pointers to the
above functions, structures, and the different initial values.
Another flag notates whether there is a separate DDC parent clock.
If not, the TMDS clock is passed to the DDC clock create function,
as before.

Regmap fields are used to deal with the different register layout
of the DDC block.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi.h  |  72 +
 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c  |  38 +++--
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c  | 112 +++---
 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c  | 227 
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c |  17 ++-
 5 files changed, 369 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index aef157d3b659..3057e31219f6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -157,6 +158,55 @@ enum sun4i_hdmi_pkt_type {
SUN4I_HDMI_PKT_END = 15,
 };
 
+struct sun4i_hdmi_variant {
+   bool has_ddc_parent_clk;
+   bool has_reset_control;
+
+   u32 pad_ctrl0_init_val;
+   u32 pad_ctrl1_init_val;
+   u32 pll_ctrl_init_val;
+
+   struct reg_field ddc_clk_reg;
+   u8 ddc_clk_pre_divider;
+   u8 ddc_clk_m_offset;
+
+   u8 tmds_clk_div_offset;
+
+   /* Register fields for I2C adapter */
+   struct reg_fieldfield_ddc_en;
+   struct reg_fieldfield_ddc_start;
+   struct reg_fieldfield_ddc_reset;
+   struct reg_fieldfield_ddc_addr_reg;
+   struct reg_fieldfield_ddc_slave_addr;
+   struct reg_fieldfield_ddc_int_mask;
+   struct reg_fieldfield_ddc_int_status;
+   struct reg_fieldfield_ddc_fifo_clear;
+   struct reg_fieldfield_ddc_fifo_rx_thres;
+   struct reg_fieldfield_ddc_fifo_tx_thres;
+   struct reg_fieldfield_ddc_byte_count;
+   struct reg_fieldfield_ddc_cmd;
+   struct reg_fieldfield_ddc_sda_en;
+   struct reg_fieldfield_ddc_sck_en;
+
+   /* DDC FIFO register offset */
+   u32 ddc_fifo_reg;
+
+   /*
+* DDC FIFO threshold boundary conditions
+*
+* This is used to cope with the threshold boundary condition
+* being slightly different on sun5i and sun6i.
+*
+* On sun5i the threshold is exclusive, i.e. does not include,
+* the value of the threshold. ( > for RX; < for TX )
+* On sun6i the threshold is inclusive, i.e. includes, the
+* value of the threshold. ( >= for RX; <= for TX )
+*/
+   boolddc_fifo_thres_incl;
+
+   boolddc_fifo_has_dir;
+};
+
 struct sun4i_hdmi {
struct drm_connectorconnector;
struct drm_encoder  encoder;
@@ -165,9 +215,13 @@ struct sun4i_hdmi {
void __iomem*base;
struct regmap   *regmap;
 
+   /* Reset control */
+   struct reset_control*reset;
+
/* Parent clocks */
struct clk  *bus_clk;
struct clk  *mod_clk;
+   struct clk  *ddc_parent_clk;
struct clk  *pll0_clk;
struct clk  *pll1_clk;
 
@@ -177,10 +231,28 @@ struct sun4i_hdmi {
 
struct i2c_adapter  *i2c;
 
+   /* Regmap fields for I2C adapter */
+   struct regmap_field *field_ddc_en;
+   struct regmap_field *field_ddc_start;
+   struct regmap_field *field_ddc_reset;
+   struct regmap_field *field_ddc_addr_reg;
+   struct regmap_field *field_ddc_slave_addr;
+   struct regmap_field *field_ddc_int_mask;
+   struct regmap_field *field_ddc_int_status;
+   struct regmap_field *field_ddc_fifo_clear;
+   struct regmap_field *field_ddc_fifo_rx_thres;
+   struct regmap_field *field_ddc_fifo_tx_thres;
+   struct regmap_field *field_ddc_byte_count;
+   struct 

[PATCH v4 03/11] drm/sun4i: hdmi: Disable clks in bind function error path and unbind function

[Chen-Yu Tsai]

The HDMI driver enables the bus and mod clocks in the bind function, but
does not disable them if it then bails our due to any errors. Neither
does it disable the clocks in the unbind function.

Fix this by adding a proper error path to the bind function, and
clk_disable_unprepare calls to the unbind function.

Also rename the err_cleanup_connector label to err_cleanup_encoder,
since it is the encoder that gets cleaned up.

Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 9ea6cd5a1370..3cf1a6932fac 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -302,26 +302,29 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
hdmi->mod_clk = devm_clk_get(dev, "mod");
if (IS_ERR(hdmi->mod_clk)) {
dev_err(dev, "Couldn't get the HDMI mod clock\n");
-   return PTR_ERR(hdmi->mod_clk);
+   ret = PTR_ERR(hdmi->mod_clk);
+   goto err_disable_bus_clk;
}
clk_prepare_enable(hdmi->mod_clk);
 
hdmi->pll0_clk = devm_clk_get(dev, "pll-0");
if (IS_ERR(hdmi->pll0_clk)) {
dev_err(dev, "Couldn't get the HDMI PLL 0 clock\n");
-   return PTR_ERR(hdmi->pll0_clk);
+   ret = PTR_ERR(hdmi->pll0_clk);
+   goto err_disable_mod_clk;
}
 
hdmi->pll1_clk = devm_clk_get(dev, "pll-1");
if (IS_ERR(hdmi->pll1_clk)) {
dev_err(dev, "Couldn't get the HDMI PLL 1 clock\n");
-   return PTR_ERR(hdmi->pll1_clk);
+   ret = PTR_ERR(hdmi->pll1_clk);
+   goto err_disable_mod_clk;
}
 
ret = sun4i_tmds_create(hdmi);
if (ret) {
dev_err(dev, "Couldn't create the TMDS clock\n");
-   return ret;
+   goto err_disable_mod_clk;
}
 
writel(SUN4I_HDMI_CTRL_ENABLE, hdmi->base + SUN4I_HDMI_CTRL_REG);
@@ -362,7 +365,7 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
ret = sun4i_hdmi_i2c_create(dev, hdmi);
if (ret) {
dev_err(dev, "Couldn't create the HDMI I2C adapter\n");
-   return ret;
+   goto err_disable_mod_clk;
}
 
drm_encoder_helper_add(>encoder,
@@ -422,6 +425,10 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
drm_encoder_cleanup(>encoder);
 err_del_i2c_adapter:
i2c_del_adapter(hdmi->i2c);
+err_disable_mod_clk:
+   clk_disable_unprepare(hdmi->mod_clk);
+err_disable_bus_clk:
+   clk_disable_unprepare(hdmi->bus_clk);
return ret;
 }
 
@@ -434,6 +441,8 @@ static void sun4i_hdmi_unbind(struct device *dev, struct 
device *master,
drm_connector_cleanup(>connector);
drm_encoder_cleanup(>encoder);
i2c_del_adapter(hdmi->i2c);
+   clk_disable_unprepare(hdmi->mod_clk);
+   clk_disable_unprepare(hdmi->bus_clk);
 }
 
 static const struct component_ops sun4i_hdmi_ops = {
-- 
2.14.2

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

[PATCH v4 02/11] drm/sun4i: tcon: Add support for demuxing TCON output on A31

[Chen-Yu Tsai]

On systems with 2 TCONs such as the A31, it is possible to demux the
output of the TCONs to one encoder.

Add support for this for the A31.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 75124043d655..68751b999877 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -112,6 +112,27 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
bool enable)
 }
 EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
 
+/*
+ * This function is a helper for TCON output muxing. The TCON output
+ * muxing control register in earlier SoCs (without the TCON TOP block)
+ * are located in TCON0. This helper returns a pointer to TCON0's
+ * sun4i_tcon structure, or NULL if not found.
+ */
+static struct sun4i_tcon *sun4i_get_tcon0(struct drm_device *drm)
+{
+   struct sun4i_drv *drv = drm->dev_private;
+   struct sun4i_tcon *tcon;
+
+   list_for_each_entry(tcon, >tcon_list, list)
+   if (tcon->id == 0)
+   return tcon;
+
+   dev_warn(drm->dev,
+"TCON0 not found, display output muxing may not work\n");
+
+   return NULL;
+}
+
 void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
struct drm_encoder *encoder)
 {
@@ -777,6 +798,31 @@ static int sun5i_a13_tcon_set_mux(struct sun4i_tcon *tcon,
return regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val);
 }
 
+static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
+ struct drm_encoder *encoder)
+{
+   struct sun4i_tcon *tcon0 = sun4i_get_tcon0(encoder->dev);
+   u32 shift;
+
+   if (!tcon0)
+   return -EINVAL;
+
+   switch (encoder->encoder_type) {
+   case DRM_MODE_ENCODER_TMDS:
+   /* HDMI */
+   shift = 8;
+   break;
+   default:
+   /* TODO A31 has MIPI DSI but A31s does not */
+   return -EINVAL;
+   }
+
+   regmap_update_bits(tcon0->regs, SUN4I_TCON_MUX_CTRL_REG,
+  0x3 << shift, tcon->id << shift);
+
+   return 0;
+}
+
 static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
.has_channel_1  = true,
.set_mux= sun5i_a13_tcon_set_mux,
@@ -785,6 +831,7 @@ static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
 static const struct sun4i_tcon_quirks sun6i_a31_quirks = {
.has_channel_1  = true,
.needs_de_be_mux= true,
+   .set_mux= sun6i_tcon_set_mux,
 };
 
 static const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
-- 
2.14.2

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

[PATCH v4 06/11] dt-bindings: display: sun4i: Add binding for A31 HDMI controller

[Chen-Yu Tsai]

The HDMI controller in the A31 SoC is slightly different from the
earlier version. In addition to the TMDS clock and DDC controls,
this version now takes a second DDC clock input.

Add a compatible string for it, and add the DDC clock input to the
list of clocks required.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 92441086caba..46df3b78ae9e 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -41,14 +41,17 @@ CEC. It is one end of the pipeline.
 Required properties:
   - compatible: value must be one of:
 * allwinner,sun5i-a10s-hdmi
+* allwinner,sun6i-a31-hdmi
   - reg: base address and size of memory-mapped region
   - interrupts: interrupt associated to this IP
   - clocks: phandles to the clocks feeding the HDMI encoder
 * ahb: the HDMI interface clock
 * mod: the HDMI module clock
+* ddc: the HDMI ddc clock (A31 only)
 * pll-0: the first video PLL
 * pll-1: the second video PLL
   - clock-names: the clock names mentioned above
+  - resets: phandle to the reset control for the HDMI encoder (A31 only)
   - dmas: phandles to the DMA channels used by the HDMI encoder
 * ddc-tx: The channel for DDC transmission
 * ddc-rx: The channel for DDC reception
-- 
2.14.2

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

[PATCH v4 00/11] drm/sun4i: hdmi: Support HDMI controller on A31

[Chen-Yu Tsai]

Hi everyone,

This is v4 of my A31 HDMI support series. The DTS patches depend on
the patch "clk: sunxi-ng: sun6i: Export video PLLs" alreay merged.
The DRM patches depend on "regmap: add iopoll-like polling macro for
regmap_field" already merged on a topic branch in the regmap repository.

Changes since v3:

- Renamed sun4i_get_first_tcon() to sun4i_get_tcon0()

- Made sun4i_get_tcon0() return NULL when it fails, and
  sun6i_tcon_set_mux() will error out if that happens.

- Removed has_unknown_mux field in tcon_quirks structure,
  as its function is replaced by the per-soc muxing function
  pointer.

- Dropped clk and regmap patches that were merged.

Changes since v2:

- TCON muxing moved into functions for each platform, with pointers
  to them in the TCON quirks structure.

- CCU "hdmi-ddc" clock renamed to "ddc".

- Added Maxime's acks.

Changes since v1:

- Core changes to sun4i-drm to support two display pipelines
  have been merged into drm-misc and thus dropped from this
  version

- Reworked DDC variant support onto new exposed I2C interface bits.

- Reworked DDC variant support to use regmap_fields.

- Patches to add variant support to various (TMDS, DDC, HDMI
  controller) sub-blocks have been merged into one patch.

This series adds support for the HDMI controller found on Allwinner
A31/A31s SoCs. It builds upon Maxime's work that added support for
the HDMI controller on the Allwinner A10s SoC.

The HDMI controllers in the older generation Allwinner SoCs is very
similar. The A10/A10s/A20 all have the same hardware block, with the
A10 having slightly different initial configuration values. The A31's
variant splits out the DDC parent clock, has different formulas for
the DDC and TMDS clocks, and a different register layout for the DDC
block. Also, it does not expose the CEC pins outside of the SoC, which
is unfortunate.

Patch 1 moves the existing TCON muxing code for the A13 into a separate
function, pointed to by by function pointer in the quirks structure.
The existing sun4i_tcon_set_mux() function calls the function pointer
if it is set.

Patch 2 adds support for the TCON demuxing feature on the A31. This is
needed if the user wants to output through HDMI from the second display
pipeline.

Patch 3 adds proper error path cleanup to the HDMI driver.

Patch 4 adds a regmap for the HDMI driver, to be used in a subsequent
patch.

Patch 5 allows the HDMI TMDS clock to use the second PLL as its parent,
in case the first PLL is driving an incompatible dot clock.

Patch 6 adds the A31 HDMI controller variant to the device tree binding.

Patch 7 adds support for different variants of the HDMI controller
hardware, with the differences mentioned in the beginning of this
letter.

Patch 8 adds defines for the A31 specific DDC register offsets.

Patch 9 adds support for the A31's HDMI controller variant.

Patch 10 adds a device node for the HDMI controller on the A31.

Patch 11 enable HDMI video output on three boards that I have.


I also had simultaneous output on both display pipelines on the SinA31s,
one with an LCD panel and the other using HDMI. After boot, both screens
showed a proper console. The HDMI screen had higher resolution, so the
console was limited to the upper left corner.

Note that this series does not deal with conflicting pixel clocks.

As I still don't have a freedesktop.org account [1] to access drm-misc,
Maxime will have to apply the patches for me.


Regards
ChenYu


[1] https://bugs.freedesktop.org/show_bug.cgi?id=102920

Chen-Yu Tsai (11):
  drm/sun4i: tcon: Add variant callback for TCON output muxing
  drm/sun4i: tcon: Add support for demuxing TCON output on A31
  drm/sun4i: hdmi: Disable clks in bind function error path and unbind
function
  drm/sun4i: hdmi: create a regmap for later use
  drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent
  dt-bindings: display: sun4i: Add binding for A31 HDMI controller
  drm/sun4i: hdmi: Add support for controller hardware variants
  drm/sun4i: hdmi: Add A31 specific DDC register definitions
  drm/sun4i: hdmi: Add support for A31's HDMI controller
  ARM: dts: sun6i: Add device node for HDMI controller
  ARM: dts: sun6i: Enable HDMI support on some A31/A31s devices

 .../bindings/display/sunxi/sun4i-drm.txt   |   3 +
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts|  21 ++
 arch/arm/boot/dts/sun6i-a31.dtsi   |  55 +
 arch/arm/boot/dts/sun6i-a31s-primo81.dts   |  25 +++
 arch/arm/boot/dts/sun6i-a31s-sina31s.dts   |  25 +++
 drivers/gpu/drm/sun4i/sun4i_hdmi.h | 107 ++
 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c |  38 +++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 204 +++---
 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 227 +++--
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c|  68 +++---
 drivers/gpu/drm/sun4i/sun4i_tcon.c

[PATCH v4 09/11] drm/sun4i: hdmi: Add support for A31's HDMI controller

[Chen-Yu Tsai]

The HDMI controller found in the A31 SoCs is slightly different
from the one already supported, which is found in the A10s:

  - Need different initial values for the PLL related registers

  - Different behavior of the DDC and TMDS clocks

  - Different register layout for the DDC portion

  - Separate DDC parent clock

This patch adds support for it.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  3 ++
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 58 ++
 2 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index ee42ae7e5a21..9b97da39927e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -59,10 +59,13 @@
 #define SUN4I_HDMI_PAD_CTRL0_TXEN  BIT(23)
 
 #define SUN4I_HDMI_PAD_CTRL1_REG   0x204
+#define SUN4I_HDMI_PAD_CTRL1_UNKNOWN   BIT(24) /* set on A31 */
 #define SUN4I_HDMI_PAD_CTRL1_AMP_OPT   BIT(23)
 #define SUN4I_HDMI_PAD_CTRL1_AMPCK_OPT BIT(22)
 #define SUN4I_HDMI_PAD_CTRL1_EMP_OPT   BIT(20)
 #define SUN4I_HDMI_PAD_CTRL1_EMPCK_OPT BIT(19)
+#define SUN4I_HDMI_PAD_CTRL1_PWSCK BIT(18)
+#define SUN4I_HDMI_PAD_CTRL1_PWSDT BIT(17)
 #define SUN4I_HDMI_PAD_CTRL1_REG_DEN   BIT(15)
 #define SUN4I_HDMI_PAD_CTRL1_REG_DENCK BIT(14)
 #define SUN4I_HDMI_PAD_CTRL1_REG_EMP(n)(((n) & 7) << 10)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 114cbe60b3e6..027b5608dbe6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -324,6 +324,63 @@ static const struct sun4i_hdmi_variant sun5i_variant = {
.ddc_fifo_has_dir   = true,
 };
 
+static const struct sun4i_hdmi_variant sun6i_variant = {
+   .has_ddc_parent_clk = true,
+   .has_reset_control  = true,
+   .pad_ctrl0_init_val = 0xff |
+ SUN4I_HDMI_PAD_CTRL0_TXEN |
+ SUN4I_HDMI_PAD_CTRL0_CKEN |
+ SUN4I_HDMI_PAD_CTRL0_PWENG |
+ SUN4I_HDMI_PAD_CTRL0_PWEND |
+ SUN4I_HDMI_PAD_CTRL0_PWENC |
+ SUN4I_HDMI_PAD_CTRL0_LDODEN |
+ SUN4I_HDMI_PAD_CTRL0_LDOCEN,
+   .pad_ctrl1_init_val = SUN4I_HDMI_PAD_CTRL1_REG_AMP(6) |
+ SUN4I_HDMI_PAD_CTRL1_REG_EMP(4) |
+ SUN4I_HDMI_PAD_CTRL1_REG_DENCK |
+ SUN4I_HDMI_PAD_CTRL1_REG_DEN |
+ SUN4I_HDMI_PAD_CTRL1_EMPCK_OPT |
+ SUN4I_HDMI_PAD_CTRL1_EMP_OPT |
+ SUN4I_HDMI_PAD_CTRL1_PWSDT |
+ SUN4I_HDMI_PAD_CTRL1_PWSCK |
+ SUN4I_HDMI_PAD_CTRL1_AMPCK_OPT |
+ SUN4I_HDMI_PAD_CTRL1_AMP_OPT |
+ SUN4I_HDMI_PAD_CTRL1_UNKNOWN,
+   .pll_ctrl_init_val  = SUN4I_HDMI_PLL_CTRL_VCO_S(8) |
+ SUN4I_HDMI_PLL_CTRL_CS(3) |
+ SUN4I_HDMI_PLL_CTRL_CP_S(10) |
+ SUN4I_HDMI_PLL_CTRL_S(4) |
+ SUN4I_HDMI_PLL_CTRL_VCO_GAIN(4) |
+ SUN4I_HDMI_PLL_CTRL_SDIV2 |
+ SUN4I_HDMI_PLL_CTRL_LDO2_EN |
+ SUN4I_HDMI_PLL_CTRL_LDO1_EN |
+ SUN4I_HDMI_PLL_CTRL_HV_IS_33 |
+ SUN4I_HDMI_PLL_CTRL_PLL_EN,
+
+   .ddc_clk_reg= REG_FIELD(SUN6I_HDMI_DDC_CLK_REG, 0, 6),
+   .ddc_clk_pre_divider= 1,
+   .ddc_clk_m_offset   = 2,
+
+   .tmds_clk_div_offset= 1,
+
+   .field_ddc_en   = REG_FIELD(SUN6I_HDMI_DDC_CTRL_REG, 0, 0),
+   .field_ddc_start= REG_FIELD(SUN6I_HDMI_DDC_CTRL_REG, 27, 27),
+   .field_ddc_reset= REG_FIELD(SUN6I_HDMI_DDC_CTRL_REG, 31, 31),
+   .field_ddc_addr_reg = REG_FIELD(SUN6I_HDMI_DDC_ADDR_REG, 1, 31),
+   .field_ddc_slave_addr   = REG_FIELD(SUN6I_HDMI_DDC_ADDR_REG, 1, 7),
+   .field_ddc_int_status   = REG_FIELD(SUN6I_HDMI_DDC_INT_STATUS_REG, 0, 
8),
+   .field_ddc_fifo_clear   = REG_FIELD(SUN6I_HDMI_DDC_FIFO_CTRL_REG, 18, 
18),
+   .field_ddc_fifo_rx_thres = REG_FIELD(SUN6I_HDMI_DDC_FIFO_CTRL_REG, 4, 
7),
+   .field_ddc_fifo_tx_thres = REG_FIELD(SUN6I_HDMI_DDC_FIFO_CTRL_REG, 0, 
3),
+   .field_ddc_byte_count   = REG_FIELD(SUN6I_HDMI_DDC_CMD_REG, 16, 25),
+   .field_ddc_cmd  = REG_FIELD(SUN6I_HDMI_DDC_CMD_REG, 0, 2),
+   .field_ddc_sda_en   = 

[PATCH v4 01/11] drm/sun4i: tcon: Add variant callback for TCON output muxing

[Chen-Yu Tsai]

Different SoCs have different muxing options and values for the TCON
outputs. Instead of stuffing every possibility in sun4i_tcon_set_mux(),
add a callback pointer to sun4i_tcon_quirks that each TCON variant
can use to provide muxing support.

The current muxing options in sun4i_tcon_set_mux() for sun5i-a13 are
moved to a new sun5i-specific callback function.

Since the new callback replaces what the .has_unknown_mux field in
tcon quirks did in the past, the field is removed.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 44 +++---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  6 +-
 2 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e853dfe51389..75124043d655 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -14,9 +14,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -112,23 +115,13 @@ EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
 void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
struct drm_encoder *encoder)
 {
-   u32 val;
-
-   if (!tcon->quirks->has_unknown_mux)
-   return;
+   int ret = -ENOTSUPP;
 
-   if (channel != 1)
-   return;
-
-   if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC)
-   val = 1;
-   else
-   val = 0;
+   if (tcon->quirks->set_mux)
+   ret = tcon->quirks->set_mux(tcon, encoder);
 
-   /*
-* FIXME: Undocumented bits
-*/
-   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val);
+   DRM_DEBUG_DRIVER("Muxing encoder %s to CRTC %s: %d\n",
+encoder->name, encoder->crtc->name, ret);
 }
 EXPORT_SYMBOL(sun4i_tcon_set_mux);
 
@@ -767,9 +760,26 @@ static int sun4i_tcon_remove(struct platform_device *pdev)
return 0;
 }
 
+/* platform specific TCON muxing callbacks */
+static int sun5i_a13_tcon_set_mux(struct sun4i_tcon *tcon,
+ struct drm_encoder *encoder)
+{
+   u32 val;
+
+   if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC)
+   val = 1;
+   else
+   val = 0;
+
+   /*
+* FIXME: Undocumented bits
+*/
+   return regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val);
+}
+
 static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
-   .has_unknown_mux = true,
-   .has_channel_1  = true,
+   .has_channel_1  = true,
+   .set_mux= sun5i_a13_tcon_set_mux,
 };
 
 static const struct sun4i_tcon_quirks sun6i_a31_quirks = {
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 5a219d1ccc26..d9e1357cc8ae 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -145,10 +145,14 @@
 
 #define SUN4I_TCON_MAX_CHANNELS2
 
+struct sun4i_tcon;
+
 struct sun4i_tcon_quirks {
-   boolhas_unknown_mux; /* sun5i has undocumented mux */
boolhas_channel_1;  /* a33 does not have channel 1 */
boolneeds_de_be_mux; /* sun6i needs mux to select backend */
+
+   /* callback to handle tcon muxing options */
+   int (*set_mux)(struct sun4i_tcon *, struct drm_encoder *);
 };
 
 struct sun4i_tcon {
-- 
2.14.2

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

Re: [PATCH v2 1/3] dt-bindings: Add document for rockchip RGB output interface

[Sandy Huang]

在 2017/10/9 21:05, Rob Herring 写道:

On Mon, Oct 9, 2017 at 3:06 AM, Sandy Huang  wrote:

Hi rob,
 Thanks for your reply.

在 2017/10/4 5:56, Rob Herring 写道:


On Fri, Sep 22, 2017 at 11:00:26AM +0800, Sandy Huang wrote:


This path add support rv1108 rgb output interface driver.

Signed-off-by: Sandy Huang 
---
Changes in v2:
   1. rename rockchip,rgb-mode to rgb-mode;



You can't just drop the vendor. This needs to be documented in a common
place that others will find and use. See panel-common.txt or
panel-dpi.txt.

Alternatively, you could just drop it and let the panel compatible imply
what the mode is.



ok, get it, i will move the rgb-mode to panel and describe it at
panel-rgb.txt. the patches will be send soon later.


Don't create yet another common panel file. We already have
panel-dpi.txt which is for digital parallel interface.
The panel-rgb.txt define different rgb output format and timing, this is 

the detail info: https://patchwork.kernel.org/patch/9992241/
do you think this need move to panel-dpi.txt?

Rob





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

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

[Laura Abbott]

On 10/09/2017 03:08 PM, Mark Brown wrote:
> On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
> 
>> Anyway, to move this forward I think we need to see a proof of concept
>> of using selinux to protect access to specific heaps.
> 
> Aren't Unix permissions enough with separate files or am I
> misunderstanding what you're looking to see a proof of concept for?
> 

The goal is to be able to restrict heap access to certain services
and selinux groups on Android so straight unix permissions aren't
sufficient.

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

[drm-intel:for-linux-next-fixes 7/7] drivers/gpu/drm/i915/i915_gem_evict.c:318:31: error: implicit declaration of function 'i915_vma_has_userfault'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
head:   72872c99b6dbc80362965cd30489c849f0663140
commit: 72872c99b6dbc80362965cd30489c849f0663140 [7/7] drm/i915: Check 
PIN_NONFAULT overlaps in evict_for_node
config: x86_64-randconfig-x018-201741 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 72872c99b6dbc80362965cd30489c849f0663140
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_gem_evict.c: In function 'i915_gem_evict_for_node':
>> drivers/gpu/drm/i915/i915_gem_evict.c:318:31: error: implicit declaration of 
>> function 'i915_vma_has_userfault' [-Werror=implicit-function-declaration]
  if (flags & PIN_NONFAULT && i915_vma_has_userfault(vma)) {
  ^~
   Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
   Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:variable_test_bit
   Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
   Cyclomatic Complexity 1 include/linux/list.h:__list_add_valid
   Cyclomatic Complexity 1 include/linux/list.h:__list_del_entry_valid
   Cyclomatic Complexity 2 include/linux/list.h:__list_add
   Cyclomatic Complexity 1 include/linux/list.h:list_add
   Cyclomatic Complexity 1 include/linux/list.h:__list_del
   Cyclomatic Complexity 2 include/linux/list.h:__list_del_entry
   Cyclomatic Complexity 1 include/linux/list.h:list_del
   Cyclomatic Complexity 1 include/linux/list.h:list_move
   Cyclomatic Complexity 1 include/linux/list.h:list_empty
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_read
   Cyclomatic Complexity 1 include/linux/lockdep.h:lock_is_held
   Cyclomatic Complexity 1 include/linux/jump_label.h:static_key_count
   Cyclomatic Complexity 2 include/linux/jump_label.h:static_key_false
   Cyclomatic Complexity 2 include/linux/cpumask.h:cpumask_check
   Cyclomatic Complexity 1 include/linux/cpumask.h:cpumask_test_cpu
   Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_add
   Cyclomatic Complexity 1 
arch/x86/include/asm/preempt.h:__preempt_count_dec_and_test
   Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_read_lock_sched_notrace
   Cyclomatic Complexity 2 
include/linux/rcupdate.h:rcu_read_unlock_sched_notrace
   Cyclomatic Complexity 2 include/linux/kref.h:kref_put
   Cyclomatic Complexity 1 include/drm/drm_mm.h:drm_mm_node_allocated
   Cyclomatic Complexity 1 include/drm/drm_gem.h:__drm_gem_object_put
   Cyclomatic Complexity 1 include/drm/drm_gem.h:__drm_gem_object_unreference
   Cyclomatic Complexity 1 
drivers/gpu/drm/i915/i915_gem_request.h:i915_gem_active_isset
   Cyclomatic Complexity 1 
drivers/gpu/drm/i915/i915_gem_object.h:i915_gem_object_put
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_get_active
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_is_active
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_pin_count
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_is_pinned
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:__i915_vma_pin
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:__i915_vma_unpin
   Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_unpin
   Cyclomatic Complexity 6 
drivers/gpu/drm/i915/i915_trace.h:trace_i915_gem_evict
   Cyclomatic Complexity 6 
drivers/gpu/drm/i915/i915_trace.h:trace_i915_gem_evict_vm
   Cyclomatic Complexity 6 
drivers/gpu/drm/i915/i915_trace.h:trace_i915_gem_evict_node
   Cyclomatic Complexity 2 
drivers/gpu/drm/i915/i915_drv.h:i915_gem_drain_freed_objects
   Cyclomatic Complexity 4 drivers/gpu/drm/i915/i915_gem_evict.c:ggtt_is_idle
   Cyclomatic Complexity 1 
drivers/gpu/drm/i915/selftests/i915_gem_evict.c:mock_color_adjust
   Cyclomatic Complexity 4 drivers/gpu/drm/i915/i915_gem_evict.c:mark_free
   Cyclomatic Complexity 3 drivers/gpu/drm/i915/i915_gem_evict.c:ggtt_flush
   Cyclomatic Complexity 9 
drivers/gpu/drm/i915/selftests/i915_gem_evict.c:populate_ggtt
   Cyclomatic Complexity 9 
drivers/gpu/drm/i915/selftests/i915_gem_evict.c:cleanup_objects
   Cyclomatic Complexity 5 
drivers/gpu/drm/i915/selftests/i915_gem_evict.c:igt_overcommit
   Cyclomatic Complexity 4 
drivers/gpu/drm/i915/selftests/i915_gem_evict.c:unpin_ggtt
   Cyclomatic Complexity 34 
drivers/gpu/drm/i915/i915_gem_evict.c:i915_gem_evict_something
   Cyclomatic Complexity 4 
drivers/gpu/drm/i915/selftests/i915_gem_evict.c:igt_evict_something
   Cyclomatic Complexity 29 
drivers/gpu/drm/i915/i915_gem_evict.c:i915_gem_evict_for_node
   Cyclomatic Complexity 7 
drivers/gpu/drm/i915/selftests/i915_gem_evict.c:igt_evict_for_cache_color
   Cyclomatic Complexity 4 

[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

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

--- Comment #7 from higu...@gmx.net ---
I tried to downgrade the kernel to 4.11, 4.10 and 4.9 and i failed to enable
DRI_PRIME on the dedicated card, always with the same error. I then tried to
downgrade the mesa and libdrm to the distro original version and also, failed
to enabled the card...

So yes, the card worked in the past with DynPwr, but now i'm unable to enable
it... Maybe some other update, firmware, whatever is also messing this. I do
recall being able to boot one older kernel and have the card working, but
booting with the more recent, it failed... all this around june

I will try to boot from a liveCD, to try to get it working again and try to
understand what else is causing this.

Anyway, using runpm=0 works and the problems seems to be always with the
kernel/atombios being unable to re-enable the card after shut it down

-- 
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

[drm-intel:for-linux-next-fixes 7/7] drivers/gpu/drm/i915/i915_gem_evict.c:318:3: note: in expansion of macro 'if'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
head:   72872c99b6dbc80362965cd30489c849f0663140
commit: 72872c99b6dbc80362965cd30489c849f0663140 [7/7] drm/i915: Check 
PIN_NONFAULT overlaps in evict_for_node
config: x86_64-randconfig-x011-201741 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 72872c99b6dbc80362965cd30489c849f0663140
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from drivers/gpu/drm/i915/i915_gem_evict.c:29:
   drivers/gpu/drm/i915/i915_gem_evict.c: In function 'i915_gem_evict_for_node':
   drivers/gpu/drm/i915/i915_gem_evict.c:318:31: error: implicit declaration of 
function 'i915_vma_has_userfault' [-Werror=implicit-function-declaration]
  if (flags & PIN_NONFAULT && i915_vma_has_userfault(vma)) {
  ^
   include/linux/compiler.h:156:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/i915_gem_evict.c:318:3: note: in expansion of macro 'if'
  if (flags & PIN_NONFAULT && i915_vma_has_userfault(vma)) {
  ^~
   cc1: some warnings being treated as errors

vim +/if +318 drivers/gpu/drm/i915/i915_gem_evict.c

   236  
   237  /**
   238   * i915_gem_evict_for_vma - Evict vmas to make room for binding a new 
one
   239   * @vm: address space to evict from
   240   * @target: range (and color) to evict for
   241   * @flags: additional flags to control the eviction algorithm
   242   *
   243   * This function will try to evict vmas that overlap the target node.
   244   *
   245   * To clarify: This is for freeing up virtual address space, not for 
freeing
   246   * memory in e.g. the shrinker.
   247   */
   248  int i915_gem_evict_for_node(struct i915_address_space *vm,
   249  struct drm_mm_node *target,
   250  unsigned int flags)
   251  {
   252  LIST_HEAD(eviction_list);
   253  struct drm_mm_node *node;
   254  u64 start = target->start;
   255  u64 end = start + target->size;
   256  struct i915_vma *vma, *next;
   257  bool check_color;
   258  int ret = 0;
   259  
   260  lockdep_assert_held(>i915->drm.struct_mutex);
   261  GEM_BUG_ON(!IS_ALIGNED(start, I915_GTT_PAGE_SIZE));
   262  GEM_BUG_ON(!IS_ALIGNED(end, I915_GTT_PAGE_SIZE));
   263  
   264  trace_i915_gem_evict_node(vm, target, flags);
   265  
   266  /* Retire before we search the active list. Although we have
   267   * reasonable accuracy in our retirement lists, we may have
   268   * a stray pin (preventing eviction) that can only be resolved 
by
   269   * retiring.
   270   */
   271  if (!(flags & PIN_NONBLOCK))
   272  i915_gem_retire_requests(vm->i915);
   273  
   274  check_color = vm->mm.color_adjust;
   275  if (check_color) {
   276  /* Expand search to cover neighbouring guard pages (or 
lack!) */
   277  if (start)
   278  start -= I915_GTT_PAGE_SIZE;
   279  
   280  /* Always look at the page afterwards to avoid the 
end-of-GTT */
   281  end += I915_GTT_PAGE_SIZE;
   282  }
   283  GEM_BUG_ON(start >= end);
   284  
   285  drm_mm_for_each_node_in_range(node, >mm, start, end) {
   286  /* If we find any non-objects (!vma), we cannot evict 
them */
   287  if (node->color == I915_COLOR_UNEVICTABLE) {
   288  ret = -ENOSPC;
   289  break;
   290  }
   291  
   292  GEM_BUG_ON(!node->allocated);
   293  vma = container_of(node, typeof(*vma), node);
   294  
   295  /* If we are using coloring to insert guard pages 
between
   296   * different cache domains within the address space, we 
have
   297   * to check whether the objects on either side of our 
range
   298   * abutt and conflict. If they are in conflict, then we 
evict
   299   * those as well to make room for our guard pages.
   300   */
   301  if (check_color) {
   302  if (node->start + node->size == 

[pull] amdgpu pre-reqs for stoney ACP audio support

[Alex Deucher]

Hi Dave, Mark,

This branch against Linus' master contains the 3 pre-requisite patches
for Stoney ACP audio.  Mark needs these patches to apply the rest of the
Stoney ACP patch set on the audio side.  Please pull.

Thanks!

The following changes since commit 68ebe3cbe786a954481d6ded0dc83f7d551640bf:

  Merge tag 'nfs-for-4.14-3' of 
git://git.linux-nfs.org/projects/trondmy/linux-nfs (2017-10-09 10:55:37 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux linus-acp-prereq

for you to fetch changes up to 1e4448648333a8fb7830a7a4b76c86e160a79b1e:

  drm/amdgpu Moving amdgpu asic types to a separate file (2017-10-09 17:54:24 
-0400)


Akshu Agrawal (1):
  drm/amdgpu Moving amdgpu asic types to a separate file

Vijendar Mukunda (2):
  drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data
  ASoC: AMD: Added asic_type as ACP DMA driver platform data

 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c  |  2 ++
 drivers/gpu/drm/amd/include/amd_shared.h | 29 ++
 include/drm/amd_asic_type.h  | 52 
 sound/soc/amd/acp-pcm-dma.c  |  8 ++---
 sound/soc/amd/acp.h  |  7 +
 5 files changed, 65 insertions(+), 33 deletions(-)
 create mode 100644 include/drm/amd_asic_type.h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

[Mark Brown]

On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:

> Anyway, to move this forward I think we need to see a proof of concept
> of using selinux to protect access to specific heaps.

Aren't Unix permissions enough with separate files or am I
misunderstanding what you're looking to see a proof of concept for?


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

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

[Laura Abbott]

On 10/05/2017 06:06 AM, Benjamin Gaignard wrote:
> 2017-10-04 12:17 GMT+02:00 Mark Brown :
>> On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:
>>
>>> It is entirely possible and easy in android/ueventd to create those nodes
>>> under "/dev/ion/".  (assuming the heap 'subsystem' for these new devices 
>>> will
>>> point to 'ion').
> 
> I think it is the same problem than for webcam under v4l framework.
> Each time you plug a webcam you got a v4l node but android/uevent rules
> the plug order doesn't have impact.
> The same think will happen for ion nodes it may be even easier because
> the heap will always being created in the smae order for a given product
> configuration.
> 

Relying on the heap being created in the same order seems troublesome.
If for some reason it changes in the kernel we might break something
in userspace.

Anyway, to move this forward I think we need to see a proof of concept
of using selinux to protect access to specific heaps.

Thanks,
Laura

>>
>> The reason I didn't say /dev/ion/foo initially is that if people want to
>> keep the existing /dev/ion around for compatibility reasons then the
>> /dev/ion name isn't available which might cause issues.  Otherwise just
>> dumping everything under a directory (perhaps with a different name) was
>> my first thought as well.
>>
>>> (Also FWIW, the SELinux permissions are also possible with the current ion
>>> implementation by adding rules to disallow specific ioctls instead of adding
>>> permissions to access device node as this change would do)
>>
>> AIUI the request is to limit access to specific heaps, and obviously not
>> everyone wants to deal with SELinux at all.

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

[Bug 103142] R600g+sb: optimizer apparently stuck in an endless loop

[bugzilla-daemon]

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

--- Comment #2 from Gert Wollny  ---
In summary, the optimizer gets stuck in an  infinite loop in schedule_alu,
because prepare_alu_group() does not find a proper scheduling.

-- 
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 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14

[bugzilla-daemon]

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

--- Comment #6 from Hadrien  ---
I tried Phoronix kernel image from Alex Deucher's drm-next-4.15-dc Git branch.
I still get the same problem with and without amdgpu.dc=1.

Oct  9 21:29:12 c18 kernel: [   32.199451] [drm:amdgpu_vce_ring_test_ring
[amdgpu]] *ERROR* amdgpu: ring 14 test failed
Oct  9 21:29:12 c18 kernel: [   32.199461] [drm:amdgpu_resume_phase2 [amdgpu]]
*ERROR* resume of IP block  failed -110
Oct  9 21:29:12 c18 kernel: [   32.199471] [drm:amdgpu_device_resume [amdgpu]]
*ERROR* amdgpu_resume failed (-110).
Oct  9 21:29:12 c18 kernel: [   32.199474] dpm_run_callback():
pci_pm_resume+0x0/0xa0 returns -110
Oct  9 21:29:12 c18 kernel: [   32.199474] PM: Device :01:00.0 failed to
resume async: error -110
Oct  9 21:29:12 c18 kernel: [   32.199498] PM: resume of devices complete after
539.171 msecs

I've been looking at the changelog of kernel 4.12.6 but there isn't much
changes in amdgpu. Maybe there are changes in another impacting amdgpu? I have
these errors before amdgpu errors:

Oct  9 21:29:12 c18 kernel: [   32.035186] ACPI Error: [DSSP] Namespace lookup
failure, AE_NOT_FOUND (20170531/psargs-364)
Oct  9 21:29:12 c18 kernel: [   32.035188] ACPI Error: Method parse/execution
failed \_SB.PCI0.SAT0.PRT0._GTF, AE_NOT_FOUND (20170531/psparse-550)
Oct  9 21:29:12 c18 kernel: [   32.035206] ata6: SATA link down (SStatus 4
SControl 300)
Oct  9 21:29:12 c18 kernel: [   32.035225] ata2: SATA link down (SStatus 4
SControl 300)
Oct  9 21:29:12 c18 kernel: [   32.035231] ata1.00: supports DRM functions and
may not be fully accessible
Oct  9 21:29:12 c18 kernel: [   32.035901] ata1.00: disabling queued TRIM
support
Oct  9 21:29:12 c18 kernel: [   32.037457] ACPI Error: [DSSP] Namespace lookup
failure, AE_NOT_FOUND (20170531/psargs-364)
Oct  9 21:29:12 c18 kernel: [   32.037459] ACPI Error: Method parse/execution
failed \_SB.PCI0.SAT0.PRT0._GTF, AE_NOT_FOUND (20170531/psparse-550)
Oct  9 21:29:12 c18 kernel: [   32.037531] ata1.00: supports DRM functions and
may not be fully accessible
Oct  9 21:29:12 c18 kernel: [   32.038084] ata1.00: disabling queued TRIM
support
Oct  9 21:29:12 c18 kernel: [   32.038704] ACPI Error: [DSSP] Namespace lookup
failure, AE_NOT_FOUND (20170531/psargs-364)
Oct  9 21:29:12 c18 kernel: [   32.038706] ACPI Error: Method parse/execution
failed \_SB.PCI0.SAT0.PRT4._GTF, AE_NOT_FOUND (20170531/psparse-550)
Oct  9 21:29:12 c18 kernel: [   32.039418] ata1.00: configured for UDMA/133
Oct  9 21:29:12 c18 kernel: [   32.055252] ata4: SATA link down (SStatus 4
SControl 300)
Oct  9 21:29:12 c18 kernel: [   32.082715] ACPI Error: [DSSP] Namespace lookup
failure, AE_NOT_FOUND (20170531/psargs-364)
Oct  9 21:29:12 c18 kernel: [   32.082718] ACPI Error: Method parse/execution
failed \_SB.PCI0.SAT0.PRT4._GTF, AE_NOT_FOUND (20170531/psparse-550)
Oct  9 21:29:12 c18 kernel: [   32.114002] ata5.00: configured for UDMA/133

-- 
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: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

[Sean Paul]

On Mon, Oct 9, 2017 at 4:59 AM, Daniel Vetter  wrote:
> On Sun, Oct 08, 2017 at 03:43:35PM +0100, Chris Wilson wrote:
>> Quoting Harsha Sharma (2017-10-08 15:04:07)
>> > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device 
>> > *dev,
>> > ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8;
>> > ifbdev->fb = fb;
>> >
>> > -   drm_framebuffer_reference(>fb->base);
>> > +   drm_framebuffer_put(>fb->base);
>>
>> Whoops.
>
> Hm yeah, how did this happen? Does cocci really do this, or is that an
> accident from manually fixing stuff up?


Running the spatch from the commit message gives me the correct substitution:
@@ -627,7 +627,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8;
ifbdev->fb = fb;

-   drm_framebuffer_reference(>fb->base);
+   drm_framebuffer_get(>fb->base);

/* Final pass to check if any active pipes don't have fbs */
for_each_crtc(dev, crtc) {


Probably just finger slip since this is the last chunk before the
omitted selftests changes.

Harsha: the "better" way to omit the selftests without hand tuning the
patch would be to run the cocci spatch on i915 as normal, and then run
"git checkout -- drivers/gpu/drm/i915/selftests/" before committing.
It's dangerous to edit patches by hand, or to misrepresent a patch as
being the result of a cocci spatch when it's not.

Sean



> -Daniel
> --
> 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

Re: [Outreachy kernel] Re: [PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*

[Sean Paul]

On Mon, Sep 25, 2017 at 3:38 AM, Thierry Reding
 wrote:
> On Sun, Sep 24, 2017 at 10:13:57PM +0530, Harsha Sharma wrote:
>> Replace all occurences of dev_info/err/dbg with DRM_DEV_INFO/
>> ERROR/DEBUG as we have DRM_DEV_* variants of drm print macros
>> Done using following coccinelle semantic patch
>>
>> @r@
>> @@
>>
>> (
>> -dev_info
>> +DRM_DEV_INFO
>> |
>> -dev_err
>> +DRM_DEV_ERROR
>> |
>> -dev_dbg
>> +DRM_DEV_DEBUG
>> )
>>
>> Signed-off-by: Harsha Sharma 
>> ---
>> Changes in v2:
>>  -Break line over 80 characters
>>  -Changes in comments not required
>
> Please don't do this. Most of the functions that you're trying to
> replace here are not DRM_DEV_*() for a very specific reason: none of
> them have anything to do with DRM/KMS in particular. This is important,
> in my opinion, because these messages are very device-specific and the
> additional information added by the DRM format string aren't useful in
> the context.

Hey Thierry,
It's likely not useful to a tegra expert such as yourself. However,
when I'm switching between platforms or providing log-parsing
instructions, it's very useful to say "grep for drm". Without the
common drm prefix, the reader needs to know they're looking for
tegra-sor, tegra-dc, etc as well.

Not a big deal, I just wanted to provide color for why someone might want this.

>
> Perhaps the only ones I consider to be good candidates for this
> conversion are the ones in drivers/gpu/drm/tegra/fb.c because they deal
> with the DRM fbdev setup and hence are not device specific. And even in
> those cases I'm not sure we gain very much by this conversion,
> especially since most of the replacements now end up having to split up
> argument lists.
>
> Sorry if this isn't documented anywhere. I also suspect other driver
> maintainers will be less picky about this sort of thing, so you might
> have more luck there.

I think the TODO entry states that contributors should check with the
driver maintainers before taking on this work, so it is documented :)

Sean


>
> Thierry
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170925073841.GA12494%40ulmo.fritz.box.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and bw codes

[Deucher, Alexander]

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@intel.com]
> Sent: Monday, October 09, 2017 5:30 AM
> To: intel-...@lists.freedesktop.org
> Cc: jani.nik...@intel.com; Deucher, Alexander; Thierry Reding; Rob Clark;
> Sean Paul; Manasi Navare; dri-devel@lists.freedesktop.org
> Subject: [PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and
> bw codes
> 
> Falling back to the lowest value is likely the only thing we can do, but
> doing it silently seems like a bad thing to do. Catch it early and make
> loud noises.
> 
> Cc: Alex Deucher 
> Cc: Thierry Reding 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: Manasi Navare 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jani Nikula 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 08af8d6b844b..dca21b5a03ec 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -137,8 +137,10 @@
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  u8 drm_dp_link_rate_to_bw_code(int link_rate)
>  {
>   switch (link_rate) {
> - case 162000:
>   default:
> + WARN(1, "unknown DP link rate %d, using %x\n", link_rate,
> +  DP_LINK_BW_1_62);
> + case 162000:
>   return DP_LINK_BW_1_62;
>   case 27:
>   return DP_LINK_BW_2_7;
> @@ -151,8 +153,9 @@ EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
>  int drm_dp_bw_code_to_link_rate(u8 link_bw)
>  {
>   switch (link_bw) {
> - case DP_LINK_BW_1_62:
>   default:
> + WARN(1, "unknown DP link bw code %x, using 162000\n",
> link_bw);
> + case DP_LINK_BW_1_62:
>   return 162000;
>   case DP_LINK_BW_2_7:
>   return 27;
> --
> 2.11.0

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

Re: [PATCH v2 4/5] drm/vc4: remove bridge from driver internal structure

[Eric Anholt]

Benjamin Gaignard  writes:

> With a call to drm_of_panel_bridge_remove() we could remove
> the bridge without store it in vc4_dpi internal driver structure.
>
> Signed-off-by: Benjamin Gaignard 

Reviewed-by: Eric Anholt 

Thanks for doing this cleanup!


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

Re: [RESEND PATCH v5] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

[Krzysztof Kozlowski]

On Mon, Oct 09, 2017 at 09:39:38AM +0200, Maciej Purski wrote:
> Add HDMI and Sil9234 MHL converter to Trats2 board.
> Following in SoC devices have been enabled:
> - HDMI (HDMI signal encoder),
> - Mixer (video buffer scanout device),
> - I2C_5 bus (used for HDMI DDC)
> - I2C_8 bus (used for HDMI_PHY control).
> 
> Based on previous work by:
> Tomasz Stanislawski 
> 
> Signed-off-by: Maciej Purski 
> Reviewed-by: Andrzej Hajda 
> ---
>  arch/arm/boot/dts/exynos4412-trats2.dts | 111 
> 
>  1 file changed, 111 insertions(+)
> 

Thanks, applied.

Best regards,
Krzysztof

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

[Bug 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related

[bugzilla-daemon]

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

--- Comment #2 from Andy Furniss  ---
Created attachment 134767
  --> https://bugs.freedesktop.org/attachment.cgi?id=134767=edit
bad on latest 4.15-wip cpu still different but not as obvious.

-- 
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 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related

[bugzilla-daemon]

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

--- Comment #1 from Andy Furniss  ---
Created attachment 134766
  --> https://bugs.freedesktop.org/attachment.cgi?id=134766=edit
bad on previous 4.15 kernel cpu load different.

All tests done with both CPUs and GPU forced to perf.

-- 
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 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related

[bugzilla-daemon]

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

Bug ID: 103175
   Summary: R9285 Unreal tournament perf regression with agd5f
4.15-wip kernels possibly CPU related
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: adf.li...@gmail.com

Created attachment 134765
  --> https://bugs.freedesktop.org/attachment.cgi?id=134765=edit
good perf gallium hud on 4.14 kernel.

R9285 Tonga, Compared to older kernels I have a perf regression with latest
4.14.0-rc3 based and previous 4.13-rc5 based agd5f 4.15-wip kernels.

This doesn't seem to affect other things like xonotic or unigine demos.

Issue = on fixes 4.14 and other older kernels I've tried, the game is OK ish
perf wise, 25-60 fps.

On 4.15-wip its 10fps. Using HUD one obvious difference is that the slow case
is only mostly using one cpu core, on a good kernel all 4 of my old phenom 2 x4
are used - possible red herring of course, I'll upload some screenshots.

The game is pre-alpha and doesn't always render properly - but it was vaguely
playable fps wise until this kernel.

-- 
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 v2] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

[Gustavo Padovan]

2017-10-09 Chris Wilson :

> Quoting John Einar Reitan (2017-10-09 14:49:36)
> > sync_file_ioctl_fence_info has a race between filling the status
> > of the underlying fences and the overall status of the sync_file.
> > If fence transitions in the time frame between its sync_fill_fence_info
> > and the later dma_fence_is_signaled for the sync_file, the returned
> > information is inconsistent showing non-signaled underlying fences but
> > an overall signaled state.
> > 
> > This patch changes sync_file_ioctl_fence_info to track what has been
> > encoded and using that as the overall sync_file status.
> > 
> > Tested-by: Vamsidhar Reddy Gaddam 
> > Signed-off-by: John Einar Reitan 
> > Cc: Sumit Semwal 
> > Cc: Gustavo Padovan 
> > Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Chris Wilson 

Pushed to drm-misc-fixes.

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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

[Keith Packard]

Daniel Vetter  writes:

> I just figured that -modesetting would be the simplest domenstration
> vehicle, since the vulkan patches don't look ready yet. I need fully
> reviewed userspace before we can land any kernel stuff. Doing
> the quick modesetting conversion would unblock.

I've provided a patch for the modesetting driver and the preliminary
bits are merged, leaving only a fairly straightforward addition of the
new ioctls to that code. I'm not sure how to make more progress there at
this point; that code would need testing, and it requires a hand-patched
kernel to test.

I also posted IGT tests for the new functionality, again, getting those
reviewed and tested depends on someone willing to build a patched
kernel. Dave Airlie has started trying to get that done.

>> (regarding FIRST_PIXEL_OUT):
>>
>> If the timestamp is the only important thing, it sounds like the kernel
>> already satisfies that, which is cool.
>
> Would be good to confirm that. If it's not, we have a problem.

Michel Dänzer says that the timestamp provided is computed to be
first_pixel_out for all hardware. Given that, I suggest we specify that
in the documentation and remove this bit from the API.

Seem reasonable?

-- 
-keith


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

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

[Ville Syrjälä]

On Mon, Oct 09, 2017 at 05:24:29PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2017-10-09 17:18:17)
> > On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote:
> > > Quoting ville.syrj...@linux.intel.com (2016-04-01 19:48:50)
> > > > From: Ville Syrjälä 
> > > > 
> > > > Eliminate the duplicate code for pipe timing readout in
> > > > intel_crtc_mode_get() by using the functions we use for the normal state
> > > > readout.
> > > > 
> > > > v2: Store dotclock in adjusted_mode instead of the final mode
> > > > 
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: Rob Kramer 
> > > > Cc: Daniel Vetter 
> > > > Signed-off-by: Ville Syrjälä 
> > > Reviewed-by: Chris Wilson 
> > 
> > Thanks for the review. Patches pushed to dinq.
> > 
> > > 
> > > Fixes a pipe-state warn for me,
> > > Tested-by: Chris Wilson 
> > 
> > However, now that I look at the code again I'm not 100% sure why this
> > fixed anything. The readout still seems to fail at fully populating the
> > mode flags. I'll post a more thorough solution that simply calls the
> > normal state readout hooks for the crtc and encoder...
> 
> The first patch fixed up the implied A,B transcoder mixup. I just tested
> both patches together. Do you want me to double check if it was just the
> first patch that silenced the warnings? I'm just happy to have a clean
> boot!

I think the first patch should have been a nop for you since 845g only has
the one pipe.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/2] staging: ion: simplify ioctl args checking function

[Laura Abbott]

On 10/09/2017 02:21 AM, Benjamin Gaignard wrote:
> 2017-09-27 15:20 GMT+02:00 Benjamin Gaignard :
>> Make arguments checking more easy to read.
>>
> 
> Hi Laura,
> 
> Even if we don't have found a solution for the second patch I believe
> this one could be useful.
> May I ask you your point of view on those few lines ?
> 
> Benjamin
> 

Yes, this looks better.

Acked-by: Laura Abbott 

>> Signed-off-by: Benjamin Gaignard 
>> ---
>>  drivers/staging/android/ion/ion-ioctl.c | 11 +--
>>  1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion-ioctl.c 
>> b/drivers/staging/android/ion/ion-ioctl.c
>> index d9f8b14..e26b786 100644
>> --- a/drivers/staging/android/ion/ion-ioctl.c
>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>> @@ -27,19 +27,18 @@ union ion_ioctl_arg {
>>
>>  static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
>>  {
>> -   int ret = 0;
>> -
>> switch (cmd) {
>> case ION_IOC_HEAP_QUERY:
>> -   ret = arg->query.reserved0 != 0;
>> -   ret |= arg->query.reserved1 != 0;
>> -   ret |= arg->query.reserved2 != 0;
>> +   if (arg->query.reserved0 ||
>> +   arg->query.reserved1 ||
>> +   arg->query.reserved2)
>> +   return -EINVAL;
>> break;
>> default:
>> break;
>> }
>>
>> -   return ret ? -EINVAL : 0;
>> +   return 0;
>>  }
>>
>>  /* fix up the cases where the ioctl direction bits are incorrect */
>> --
>> 2.7.4
>>
> 
> 
> 

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

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

[Chris Wilson]

Quoting Ville Syrjälä (2017-10-09 17:18:17)
> On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote:
> > Quoting ville.syrj...@linux.intel.com (2016-04-01 19:48:50)
> > > From: Ville Syrjälä 
> > > 
> > > Eliminate the duplicate code for pipe timing readout in
> > > intel_crtc_mode_get() by using the functions we use for the normal state
> > > readout.
> > > 
> > > v2: Store dotclock in adjusted_mode instead of the final mode
> > > 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Rob Kramer 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Ville Syrjälä 
> > Reviewed-by: Chris Wilson 
> 
> Thanks for the review. Patches pushed to dinq.
> 
> > 
> > Fixes a pipe-state warn for me,
> > Tested-by: Chris Wilson 
> 
> However, now that I look at the code again I'm not 100% sure why this
> fixed anything. The readout still seems to fail at fully populating the
> mode flags. I'll post a more thorough solution that simply calls the
> normal state readout hooks for the crtc and encoder...

The first patch fixed up the implied A,B transcoder mixup. I just tested
both patches together. Do you want me to double check if it was just the
first patch that silenced the warnings? I'm just happy to have a clean
boot!
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Dynamically adding a PCI subfunction

[Christian König]

Am 09.10.2017 um 17:57 schrieb Ilia Mirkin:

On Mon, Oct 9, 2017 at 11:45 AM, Christian König
 wrote:

Am 09.10.2017 um 16:41 schrieb Ilia Mirkin:

Hello,

As a bit of background, all NVIDIA GPUs since GT215 have an audio
subfunction for HDMI(/DP) audio to be sent to the sink. This generally
works.

However some, especially laptop, devices come up with that function
disabled. We have a quirk to enable it when coming back from runpm,
but that doesn't help the init case. Basically we have to write a bit
to the PCI config space:


https://github.com/torvalds/linux/blob/v4.12/drivers/gpu/drm/nouveau/nouveau_drm.c#L783

(MMIO 0x88000 is an alias for the PCI config space)

This works for runtime pm resume, since the device was originally
there and we just have to make sure the underlying device agrees with
it, but when it's missing on boot, we have to convince linux that it
exists, bind a driver, etc.

What's the best way of going about doing that?


Sounds similar to my work about resizing BARs.

I would just try to enable the device and then trigger a rescan of the BUS
where it is attached (similar to echo 1 >
/sys/bus/pci/devices/$pci_id_of_your_bus/rescan).

There is certainly a function in the PCI subsystem you just need to call for
that.

I'm not exactly familiar with the pci subsystem. I know that hotplug
is a thing, at least in theory. I figured it'd be something related to
that, since this is in essence a random device appearing on the bus
after the initial scan. Is a bus rescan safe on a fully initialized
system?

Either way, some specific functions to call or look at would be great.


Well I would just try to use pci_rescan_bus(), as far as I know that 
should be save even when devices are already configured.


Christian.



Cheers,

   -ilia



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

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

[Ville Syrjälä]

On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote:
> Quoting ville.syrj...@linux.intel.com (2016-04-01 19:48:50)
> > From: Ville Syrjälä 
> > 
> > Eliminate the duplicate code for pipe timing readout in
> > intel_crtc_mode_get() by using the functions we use for the normal state
> > readout.
> > 
> > v2: Store dotclock in adjusted_mode instead of the final mode
> > 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Rob Kramer 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> Reviewed-by: Chris Wilson 

Thanks for the review. Patches pushed to dinq.

> 
> Fixes a pipe-state warn for me,
> Tested-by: Chris Wilson 

However, now that I look at the code again I'm not 100% sure why this
fixed anything. The readout still seems to fail at fully populating the
mode flags. I'll post a more thorough solution that simply calls the
normal state readout hooks for the crtc and encoder...

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH hwc] drm_hwcomposer: fix return values for ValidateDisplay

[Rob Herring]

According to the API documentation, if we've set num_types, then the
return value should be HWC2::Error::HasChanges.

Signed-off-by: Rob Herring 
---
 drmhwctwo.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index 89399bf1ba33..0f258770a8bb 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -701,7 +701,7 @@ HWC2::Error DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t 
*num_types,
 break;
 }
   }
-  return HWC2::Error::None;
+  return *num_types ? HWC2::Error::HasChanges : HWC2::Error::None;
 }
 
 HWC2::Error DrmHwcTwo::HwcLayer::SetCursorPosition(int32_t x, int32_t y) {
-- 
2.11.0

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

Re: Dynamically adding a PCI subfunction

[Ilia Mirkin]

On Mon, Oct 9, 2017 at 11:45 AM, Christian König
 wrote:
> Am 09.10.2017 um 16:41 schrieb Ilia Mirkin:
>>
>> Hello,
>>
>> As a bit of background, all NVIDIA GPUs since GT215 have an audio
>> subfunction for HDMI(/DP) audio to be sent to the sink. This generally
>> works.
>>
>> However some, especially laptop, devices come up with that function
>> disabled. We have a quirk to enable it when coming back from runpm,
>> but that doesn't help the init case. Basically we have to write a bit
>> to the PCI config space:
>>
>>
>> https://github.com/torvalds/linux/blob/v4.12/drivers/gpu/drm/nouveau/nouveau_drm.c#L783
>>
>> (MMIO 0x88000 is an alias for the PCI config space)
>>
>> This works for runtime pm resume, since the device was originally
>> there and we just have to make sure the underlying device agrees with
>> it, but when it's missing on boot, we have to convince linux that it
>> exists, bind a driver, etc.
>>
>> What's the best way of going about doing that?
>
>
> Sounds similar to my work about resizing BARs.
>
> I would just try to enable the device and then trigger a rescan of the BUS
> where it is attached (similar to echo 1 >
> /sys/bus/pci/devices/$pci_id_of_your_bus/rescan).
>
> There is certainly a function in the PCI subsystem you just need to call for
> that.

I'm not exactly familiar with the pci subsystem. I know that hotplug
is a thing, at least in theory. I figured it'd be something related to
that, since this is in essence a random device appearing on the bus
after the initial scan. Is a bus rescan safe on a fully initialized
system?

Either way, some specific functions to call or look at would be great.

Cheers,

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

[PATCH] drm/ttm: don't use compound pages for now

[Christian König]

From: Christian König 

We need to figure out first how to correctly map them into the CPU page tables.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index e5ef10d..96ad129 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -913,6 +913,7 @@ static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt 
*ttm_dma, bool huge)
if (huge) {
gfp_flags |= GFP_TRANSHUGE;
gfp_flags &= ~__GFP_MOVABLE;
+   gfp_flags &= ~__GFP_COMP;
}
 
return gfp_flags;
-- 
2.7.4

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

Re: Dynamically adding a PCI subfunction

[Christian König]

Am 09.10.2017 um 16:41 schrieb Ilia Mirkin:

Hello,

As a bit of background, all NVIDIA GPUs since GT215 have an audio
subfunction for HDMI(/DP) audio to be sent to the sink. This generally
works.

However some, especially laptop, devices come up with that function
disabled. We have a quirk to enable it when coming back from runpm,
but that doesn't help the init case. Basically we have to write a bit
to the PCI config space:

https://github.com/torvalds/linux/blob/v4.12/drivers/gpu/drm/nouveau/nouveau_drm.c#L783

(MMIO 0x88000 is an alias for the PCI config space)

This works for runtime pm resume, since the device was originally
there and we just have to make sure the underlying device agrees with
it, but when it's missing on boot, we have to convince linux that it
exists, bind a driver, etc.

What's the best way of going about doing that?


Sounds similar to my work about resizing BARs.

I would just try to enable the device and then trigger a rescan of the 
BUS where it is attached (similar to echo 1 > 
/sys/bus/pci/devices/$pci_id_of_your_bus/rescan).


There is certainly a function in the PCI subsystem you just need to call 
for that.


Regards,
Christian.



Thanks,

   -ilia
___
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 v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

[Noralf Trønnes]

Den 09.10.2017 11.06, skrev Daniel Thompson:

On 06/10/17 19:01, Noralf Trønnes wrote:


Den 03.10.2017 11.04, skrev Daniel Vetter:

On Tue, Oct 03, 2017 at 09:51:49AM +0100, Daniel Thompson wrote:

On 03/10/17 09:03, Daniel Vetter wrote:

On Mon, Oct 02, 2017 at 12:00:54PM +0300, Jani Nikula wrote:
On Mon, 02 Oct 2017, Daniel Thompson  
wrote:
So I'm coming to this patchset cold but can you explain *why* 
something
wants to call of_find_backlight_by_node() when there is no 
backlight

support enabled. Why isn't the code that called is conditional on
BACKLIGHT_CLASS_DEVICE?

The undefined symbol issue is a pain but to be honest I'd rather 
solve
the use of undefined symbols by avoiding declaring them; this 
making

them into compile errors rather than link errors.

Typically the kernel header files define static inline stubs of the
functions when the actual functions aren't configured/built. The 
code
using the functions looks the same regardless of the config 
option, and

handles the -ENODEV or NULL or whatever returns from the stubs
gracefully. With the inlines, the compiler can usually throw out 
much of

the code anyway.

In this regard, the backlight interface is an exception, forcing the
callers to wrap the code around 
IS_ENABLED(BACKLIGHT_CLASS_DEVICE), not

the rule.
fwiw, I think it'd be great if we can move backlight over to the 
common

pattern, like everyone else. It's pretty big pain as-is ...
For sure, after Jani's mail yesterday I looked at the GMA500 driver 
and
concluded I didn't want code related to backlight having to look 
like that!


Currently the three main patterns of use are:

  1. Standalone drivers simple depend on BACKLIGHT_CLASS_DEVICE,
  2. Some compound drivers select BACKLIGHT_CLASS_DEVICE (the AMD DRM
 driver is an example of this),
  3. Other compound drivers perform heroics with the pre-processor.

The main reason I'm not just agreeing straight away is that, to 
adopt the
static inline pattern for the whole API, we have to believe that #3 
above is
desirable. Given the size and scope of the compound drivers in #3 
above, I

don't entirely understand why they want to avoid the select.
People love to over-configure their kernels and shave off a few 
bytes. And
big gpu drivers might have backlight support, but not always need it 
(e.g.

if you run without a panel as e.g. a tv set-top-box). Same with e.g. a
driver that supports both OF/DT and pci to find its devices.

On the desktop gpu driver side we don't really subscribe to this 
idea of
making everything optional, hence select (mostly), except select is 
a huge

pain. On the mobile/soc gpu side, #3 seems to be the desired outcome.
Doing static inline helpers for backlights would make both easier 
(since

in the end for desktop you just get a distro kernel that enables
everything anyway).

So yeah, imo if you think backlight should be a Kconfig, then it should
have static inline dummy functions to make life simpler for 
everyone. Only
exception are pure driver-only subsystem code which aren't ever 
called by
anything outside of your subsystem. But since the point of the 
backlight
subsystem is to provide backlight support to other drivers (there's 
still

the dream that we don't offload this onto userspace, that just doesn't
work well) we really should have these static inline helpers.


I suggest we put all the backlight subsystem only functionality we need,
into the backlight subsystem :-)
I've put together a suggestion below and I've deliberately dropped the
of_ infix in backlight_get() to make room for possible future additions
that can make it possible to set the connection between device and
backlight using platform table or ACPI, fashioned after gpiolib.


Looks good to me.

If I've read this right, other sub-systems can use these symbols with 
or without BACKLIGHT_CLASS_DEVICE and still compile OK?




The code haven't seen a compiler, but that's the idea.

Noralf.



Daniel.





include/linux/backlight.h:

/**
  * backlight_enable - Enable backlight
  * @bd: the backlight device to enable
  */
static inline int backlight_enable(struct backlight_device *bd)
{
 if (!bd)
     return 0;

 bd->props.power = FB_BLANK_UNBLANK;
 bd->props.state &= ~BL_CORE_FBBLANK;

 return backlight_update_status(bd);
}

/**
  * backlight_disable - Disable backlight
  * @bd: the backlight device to disable
  */
static inline int backlight_disable(struct backlight_device *bd)
{
 if (!bd)
     return 0;

 bd->props.power = FB_BLANK_POWERDOWN;
 bd->props.state |= BL_CORE_FBBLANK;

 return backlight_update_status(bd);
}

/**
  * backlight_put - Drop backlight reference
  * @bd: the backlight device to put
  */
static inline void backlight_put(struct backlight_device *bd)
{
 if (bd)
     put_device(bd->dev);
}

#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
struct backlight_device *backlight_get(struct device *dev);
struct backlight_device 

[Bug 93301] ns2_linux32: radeon VM fault on Hawaii (+mmap errors)

[bugzilla-daemon]

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

Nicolai Hähnle  changed:

   What|Removed |Added

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

--- Comment #30 from Nicolai Hähnle  ---
This seems to be fixed. If the high memory use is still an issue some place, it
seems best to open a new bug.

-- 
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

Dynamically adding a PCI subfunction

[Ilia Mirkin]

Hello,

As a bit of background, all NVIDIA GPUs since GT215 have an audio
subfunction for HDMI(/DP) audio to be sent to the sink. This generally
works.

However some, especially laptop, devices come up with that function
disabled. We have a quirk to enable it when coming back from runpm,
but that doesn't help the init case. Basically we have to write a bit
to the PCI config space:

https://github.com/torvalds/linux/blob/v4.12/drivers/gpu/drm/nouveau/nouveau_drm.c#L783

(MMIO 0x88000 is an alias for the PCI config space)

This works for runtime pm resume, since the device was originally
there and we just have to make sure the underlying device agrees with
it, but when it's missing on boot, we have to convince linux that it
exists, bind a driver, etc.

What's the best way of going about doing that?

Thanks,

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

[Bug 196615] amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

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

--- Comment #19 from klavkala...@gmail.com ---
The code is still there in 4.14-rc4.

-- 
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 hwc] drm_hwcomposer: use upstream DRM_MODE_{ROTATE, REFLECT} defines

[Robert Foss]

Hey Thierry,

On Sat, 2017-10-07 at 01:29 +0200, Thierry Reding wrote:
> On Fri, Oct 06, 2017 at 04:46:48PM -0500, Rob Herring wrote:
> > The DRM_REFLECT_* and DRM_ROTATE_* defines were not upstream, but
> > now
> > they are. Convert to using the upstream version which are defined
> > as a
> > bit mask rather than a bit position.
> > 
> > Signed-off-by: Rob Herring 
> > ---
> >  drmdisplaycompositor.cpp | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> Reviewed-by: Thierry Reding 

I pushed this patch, but I slightly bungled it, and missed appending
your r-b to the commit message. Sorry about that.


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

Re: [PATCH hwc] drm_hwcomposer: remove NVIDIA importer

[Robert Foss]

Hey again,

Just pushed this patch.


Rob.

On Mon, 2017-10-09 at 15:58 +0200, Robert Foss wrote:
> Hey Thierry,
> 
> On Mon, 2017-10-09 at 15:07 +0200, Thierry Reding wrote:
> > On Fri, Oct 06, 2017 at 05:02:03PM -0500, Rob Herring wrote:
> > > There's no opensource implementation for the NVIDIA gralloc
> > > implementation,
> > > so remove it as it is not testable.
> > > 
> > > As all of the gralloc perform() operations are specific to it,
> > > they
> > > can be
> > > removed, too.
> > > 
> > > Signed-off-by: Rob Herring 
> > > ---
> > >  Android.mk  |   5 -
> > >  drmhwcgralloc.h |  33 -
> > >  platformnv.cpp  | 374 --
> > > --
> > > 
> > >  3 files changed, 412 deletions(-)
> > >  delete mode 100644 platformnv.cpp
> > 
> > This is in agreement with other parts of the open source graphics
> > stack,
> > so:
> > 
> > Acked-by: Thierry Reding 
> > 
> > If anyone wants to revive this, they'd have to provide an open
> > source
> > implementation of gralloc first, and then this commit could always
> > be
> > reverted.
> > 
> > Thierry
> 
> Excellent, thanks for the quick reply.
> 
> 
> Rob.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc] drm_hwcomposer: remove NVIDIA importer

[Robert Foss]

Hey Thierry,

On Mon, 2017-10-09 at 15:07 +0200, Thierry Reding wrote:
> On Fri, Oct 06, 2017 at 05:02:03PM -0500, Rob Herring wrote:
> > There's no opensource implementation for the NVIDIA gralloc
> > implementation,
> > so remove it as it is not testable.
> > 
> > As all of the gralloc perform() operations are specific to it, they
> > can be
> > removed, too.
> > 
> > Signed-off-by: Rob Herring 
> > ---
> >  Android.mk  |   5 -
> >  drmhwcgralloc.h |  33 -
> >  platformnv.cpp  | 374 
> > 
> >  3 files changed, 412 deletions(-)
> >  delete mode 100644 platformnv.cpp
> 
> This is in agreement with other parts of the open source graphics
> stack,
> so:
> 
> Acked-by: Thierry Reding 
> 
> If anyone wants to revive this, they'd have to provide an open source
> implementation of gralloc first, and then this commit could always be
> reverted.
> 
> Thierry

Excellent, thanks for the quick reply.


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

Re: [PATCH v2] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

[Chris Wilson]

Quoting John Einar Reitan (2017-10-09 14:49:36)
> sync_file_ioctl_fence_info has a race between filling the status
> of the underlying fences and the overall status of the sync_file.
> If fence transitions in the time frame between its sync_fill_fence_info
> and the later dma_fence_is_signaled for the sync_file, the returned
> information is inconsistent showing non-signaled underlying fences but
> an overall signaled state.
> 
> This patch changes sync_file_ioctl_fence_info to track what has been
> encoded and using that as the overall sync_file status.
> 
> Tested-by: Vamsidhar Reddy Gaddam 
> Signed-off-by: John Einar Reitan 
> Cc: Sumit Semwal 
> Cc: Gustavo Padovan 
> Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

[John Einar Reitan]

sync_file_ioctl_fence_info has a race between filling the status
of the underlying fences and the overall status of the sync_file.
If fence transitions in the time frame between its sync_fill_fence_info
and the later dma_fence_is_signaled for the sync_file, the returned
information is inconsistent showing non-signaled underlying fences but
an overall signaled state.

This patch changes sync_file_ioctl_fence_info to track what has been
encoded and using that as the overall sync_file status.

Tested-by: Vamsidhar Reddy Gaddam 
Signed-off-by: John Einar Reitan 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: dri-devel@lists.freedesktop.org
---

Changes since v1 (thanks Chris Wilson):
- Replaced an unneeded local variable by writing directly to the struct

 drivers/dma-buf/sync_file.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 66fb40d0ebdb..03830634e141 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -383,7 +383,7 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
return err;
 }
 
-static void sync_fill_fence_info(struct dma_fence *fence,
+static int sync_fill_fence_info(struct dma_fence *fence,
 struct sync_fence_info *info)
 {
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
@@ -399,6 +399,8 @@ static void sync_fill_fence_info(struct dma_fence *fence,
test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, >flags) ?
ktime_to_ns(fence->timestamp) :
ktime_set(0, 0);
+
+   return info->status;
 }
 
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
@@ -424,8 +426,12 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
 * sync_fence_info and return the actual number of fences on
 * info->num_fences.
 */
-   if (!info.num_fences)
+   if (!info.num_fences) {
+   info.status = dma_fence_is_signaled(sync_file->fence);
goto no_fences;
+   } else {
+   info.status = 1;
+   }
 
if (info.num_fences < num_fences)
return -EINVAL;
@@ -435,8 +441,10 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (!fence_info)
return -ENOMEM;
 
-   for (i = 0; i < num_fences; i++)
-   sync_fill_fence_info(fences[i], _info[i]);
+   for (i = 0; i < num_fences; i++) {
+   int status = sync_fill_fence_info(fences[i], _info[i]);
+   info.status = info.status <= 0 ? info.status : status;
+   }
 
if (copy_to_user(u64_to_user_ptr(info.sync_fence_info), fence_info,
 size)) {
@@ -446,7 +454,6 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
 
 no_fences:
sync_file_get_name(sync_file, info.name, sizeof(info.name));
-   info.status = dma_fence_is_signaled(sync_file->fence);
info.num_fences = num_fences;
 
if (copy_to_user((void __user *)arg, , sizeof(info)))
-- 
2.13.6

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

Re: [PATCH hwc] drm_hwcomposer: remove NVIDIA importer

[Thierry Reding]

On Fri, Oct 06, 2017 at 05:02:03PM -0500, Rob Herring wrote:
> There's no opensource implementation for the NVIDIA gralloc implementation,
> so remove it as it is not testable.
> 
> As all of the gralloc perform() operations are specific to it, they can be
> removed, too.
> 
> Signed-off-by: Rob Herring 
> ---
>  Android.mk  |   5 -
>  drmhwcgralloc.h |  33 -
>  platformnv.cpp  | 374 
> 
>  3 files changed, 412 deletions(-)
>  delete mode 100644 platformnv.cpp

This is in agreement with other parts of the open source graphics stack,
so:

Acked-by: Thierry Reding 

If anyone wants to revive this, they'd have to provide an open source
implementation of gralloc first, and then this commit could always be
reverted.

Thierry


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

Re: [PATCH v2 1/3] dt-bindings: Add document for rockchip RGB output interface

[Rob Herring]

On Mon, Oct 9, 2017 at 3:06 AM, Sandy Huang  wrote:
> Hi rob,
> Thanks for your reply.
>
> 在 2017/10/4 5:56, Rob Herring 写道:
>>
>> On Fri, Sep 22, 2017 at 11:00:26AM +0800, Sandy Huang wrote:
>>>
>>> This path add support rv1108 rgb output interface driver.
>>>
>>> Signed-off-by: Sandy Huang 
>>> ---
>>> Changes in v2:
>>>   1. rename rockchip,rgb-mode to rgb-mode;
>>
>>
>> You can't just drop the vendor. This needs to be documented in a common
>> place that others will find and use. See panel-common.txt or
>> panel-dpi.txt.
>>
>> Alternatively, you could just drop it and let the panel compatible imply
>> what the mode is.
>>
>>
> ok, get it, i will move the rgb-mode to panel and describe it at
> panel-rgb.txt. the patches will be send soon later.

Don't create yet another common panel file. We already have
panel-dpi.txt which is for digital parallel interface.

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

[Bug 103168] [CI] igt@prime_mmap_coherency@write-and-fail - fai - Failed assertion: !(!stale)

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

  Component|DRM/Intel   |IGT
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org

--- Comment #1 from Chris Wilson  ---
Just a silliness in the test to assume it was able to hit the cache coherency
issue.

-- 
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 103138] [regression, vega] BUG: Bad page state in process gnome-shell pfn:77cc33

[bugzilla-daemon]

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

--- Comment #4 from Christian König  ---
Created attachment 134764
  --> https://bugs.freedesktop.org/attachment.cgi?id=134764=edit
Possible fix

No problem, does the attached patch help?

-- 
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 hwc] platformdrmgeneric: get the gralloc usage directly from the handle

[Robert Foss]

Hey Rob,

I tested the patch on the imx6/etnaviv platform, and it all works.
So I pushed the patch with t-b && r-b tags attached.


Rob.

On Fri, 2017-10-06 at 17:20 -0500, Rob Herring wrote:
> There's no point in using a gralloc perform() op to retrieve the
> usage as
> it is already stored in the handle like width, height, format, etc.
> So just
> copy it to the hwc_drm_bo_t and get it directly.
> 
> Signed-off-by: Rob Herring 
> ---
> I was a bit quick on the trigger with the previous patch. This one is
> a 
> dependency for it.
> 
>  drmhwcgralloc.h| 1 +
>  hwcutils.cpp   | 8 ++--
>  platformdrmgeneric.cpp | 1 +
>  3 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drmhwcgralloc.h b/drmhwcgralloc.h
> index 765c8979d2df..c4a42eaf1c54 100644
> --- a/drmhwcgralloc.h
> +++ b/drmhwcgralloc.h
> @@ -56,6 +56,7 @@ typedef struct hwc_drm_bo {
>    uint32_t width;
>    uint32_t height;
>    uint32_t format; /* DRM_FORMAT_* from drm_fourcc.h */
> +  uint32_t usage;
>    uint32_t pitches[4];
>    uint32_t offsets[4];
>    uint32_t gem_handles[4];
> diff --git a/hwcutils.cpp b/hwcutils.cpp
> index 00915757469e..53a7d82889b8 100644
> --- a/hwcutils.cpp
> +++ b/hwcutils.cpp
> @@ -159,12 +159,8 @@ int DrmHwcLayer::ImportBuffer(Importer
> *importer,
>    if (ret)
>  return ret;
>  
> -  ret = gralloc->perform(gralloc, GRALLOC_MODULE_PERFORM_GET_USAGE,
> - handle.get(), _buffer_usage);
> -  if (ret) {
> -ALOGE("Failed to get usage for buffer %p (%d)", handle.get(),
> ret);
> -return ret;
> -  }
> +  gralloc_buffer_usage = buffer.operator->()->usage;
> +
>    return 0;
>  }
>  
> diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
> index aa3d0faee7c0..741d42b6ac33 100644
> --- a/platformdrmgeneric.cpp
> +++ b/platformdrmgeneric.cpp
> @@ -116,6 +116,7 @@ int
> DrmGenericImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t
> *bo) {
>    bo->width = gr_handle->width;
>    bo->height = gr_handle->height;
>    bo->format = ConvertHalFormatToDrm(gr_handle->format);
> +  bo->usage = gr_handle->usage;
>    bo->pitches[0] = gr_handle->stride;
>    bo->gem_handles[0] = gem_handle;
>    bo->offsets[0] = 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()

[Maarten Lankhorst]

Op 09-10-17 om 08:46 schreef Jeffy Chen:
> Kmemleak reported memory leak after suspend and resume:
> unreferenced object 0xffc0e31d8880 (size 128):
>   comm "bash", pid 181, jiffies 4294763583 (age 24.694s)
>   hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 00 20 a2 eb c0 ff ff ff  . ..
> 01 00 00 00 00 00 00 00 80 87 1d e3 c0 ff ff ff  
>   backtrace:
> [] __save_stack_trace+0x48/0x6c
> [] create_object+0x138/0x254
> [] kmemleak_alloc+0x58/0x8c
> [] kmem_cache_alloc_trace+0x188/0x254
> [] drm_atomic_state_alloc+0x3c/0x88
> [] drm_atomic_helper_duplicate_state+0x28/0x158
> [] drm_atomic_helper_suspend+0x5c/0xf0
>
> Problem here is that we are duplicating the drm_atomic_state in
> drm_atomic_helper_suspend(), but not unreference it in the resume path.
>
> Fixes: 1494276000db ("drm/atomic-helper: Implement subsystem-level 
> suspend/resume")
> Signed-off-by: Jeffy Chen 
> ---
>
> Changes in v2:
> Unref duplicated drm_atomic_state in drm_atomic_helper_resume() instead
> of specific drivers.
>
>  drivers/gpu/drm/drm_atomic_helper.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 01c34bc5b5b0..4a262380c631 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>   drm_modeset_backoff();
>   }
>  
> + drm_atomic_state_put(state);
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
>  

Reviewed-by: Maarten Lankhorst 
Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Cc:  # v4.10+

and pushed, thanks for finding it. :)

The bug is probably older than that commit, but only happened on failure paths 
before. If resume fails we probably have bigger issues than leaking some memory.

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

Re: [PATCH hwc] drm_hwcomposer: remove NVIDIA importer

[Robert Foss]

Hey Rob,

+Thierry

This looks good to me, does anyone have a strong opinion the other way?
I'll let this one soak for a day or two more.


Rob.

On Fri, 2017-10-06 at 17:02 -0500, Rob Herring wrote:
> There's no opensource implementation for the NVIDIA gralloc
> implementation,
> so remove it as it is not testable.
> 
> As all of the gralloc perform() operations are specific to it, they
> can be
> removed, too.
> 
> Signed-off-by: Rob Herring 
> ---
>  Android.mk  |   5 -
>  drmhwcgralloc.h |  33 -
>  platformnv.cpp  | 374 --
> --
>  3 files changed, 412 deletions(-)
>  delete mode 100644 platformnv.cpp
> 
> diff --git a/Android.mk b/Android.mk
> index 99bbcac3e984..d7dc6782e1e0 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -71,7 +71,6 @@ LOCAL_SRC_FILES := \
>   hwcutils.cpp \
>   platform.cpp \
>   platformdrmgeneric.cpp \
> - platformnv.cpp \
>   separate_rects.cpp \
>   virtualcompositorworker.cpp \
>   vsyncworker.cpp
> @@ -80,11 +79,7 @@ LOCAL_CPPFLAGS += \
>   -DHWC2_USE_CPP11 \
>   -DHWC2_INCLUDE_STRINGIFICATION
>  
> -ifeq ($(strip $(BOARD_DRM_HWCOMPOSER_BUFFER_IMPORTER)),nvidia-
> gralloc)
> -LOCAL_CPPFLAGS += -DUSE_NVIDIA_IMPORTER
> -else
>  LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
> -endif
>  
>  LOCAL_MODULE := hwcomposer.drm
>  LOCAL_MODULE_TAGS := optional
> diff --git a/drmhwcgralloc.h b/drmhwcgralloc.h
> index c4a42eaf1c54..759746a67949 100644
> --- a/drmhwcgralloc.h
> +++ b/drmhwcgralloc.h
> @@ -19,39 +19,6 @@
>  
>  #include 
>  
> -enum {
> -  /* perform(const struct gralloc_module_t *mod,
> -   *    int op,
> -   *    int drm_fd,
> -   *    buffer_handle_t buffer,
> -   *    struct hwc_drm_bo *bo);
> -   */
> -  GRALLOC_MODULE_PERFORM_DRM_IMPORT = 0xffeeff00,
> -
> -  /* perform(const struct gralloc_module_t *mod,
> -   *    int op,
> -   *    buffer_handle_t buffer,
> -   *    void (*free_callback)(void *),
> -   *    void *priv);
> -   */
> -  GRALLOC_MODULE_PERFORM_SET_IMPORTER_PRIVATE = 0xffeeff01,
> -
> -  /* perform(const struct gralloc_module_t *mod,
> -   *    int op,
> -   *    buffer_handle_t buffer,
> -   *    void (*free_callback)(void *),
> -   *    void **priv);
> -   */
> -  GRALLOC_MODULE_PERFORM_GET_IMPORTER_PRIVATE = 0xffeeff02,
> -
> -  /* perform(const struct gralloc_module_t *mod,
> -   * int op,
> -   * buffer_handle_t buffer,
> -   * int *usage);
> -   */
> -  GRALLOC_MODULE_PERFORM_GET_USAGE = 0xffeeff03,
> -};
> -
>  typedef struct hwc_drm_bo {
>    uint32_t width;
>    uint32_t height;
> diff --git a/platformnv.cpp b/platformnv.cpp
> deleted file mode 100644
> index e7b6be3430a8..
> --- a/platformnv.cpp
> +++ /dev/null
> @@ -1,374 +0,0 @@
> -/*
> - * Copyright (C) 2015 The Android Open Source Project
> - *
> - * Licensed under the Apache License, Version 2.0 (the "License");
> - * you may not use this file except in compliance with the License.
> - * You may obtain a copy of the License at
> - *
> - *  http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing,
> software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> - * See the License for the specific language governing permissions
> and
> - * limitations under the License.
> - */
> -
> -#define LOG_TAG "hwc-platform-nv"
> -
> -#include "drmresources.h"
> -#include "platform.h"
> -#include "platformnv.h"
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -
> -#ifndef EGL_NATIVE_HANDLE_ANDROID_NVX
> -#define EGL_NATIVE_HANDLE_ANDROID_NVX 0x322A
> -#endif
> -
> -namespace android {
> -
> -#ifdef USE_NVIDIA_IMPORTER
> -// static
> -Importer *Importer::CreateInstance(DrmResources *drm) {
> -  NvImporter *importer = new NvImporter(drm);
> -  if (!importer)
> -return NULL;
> -
> -  int ret = importer->Init();
> -  if (ret) {
> -ALOGE("Failed to initialize the nv importer %d", ret);
> -delete importer;
> -return NULL;
> -  }
> -  return importer;
> -}
> -#endif
> -
> -NvImporter::NvImporter(DrmResources *drm) : drm_(drm) {
> -}
> -
> -NvImporter::~NvImporter() {
> -}
> -
> -int NvImporter::Init() {
> -  int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
> -  (const hw_module_t **)_);
> -  if (ret) {
> -ALOGE("Failed to open gralloc module %d", ret);
> -return ret;
> -  }
> -
> -  if (strcasecmp(gralloc_->common.author, "NVIDIA"))
> -ALOGW("Using non-NVIDIA gralloc module: %s/%s\n", gralloc_-
> >common.name,
> -  gralloc_->common.author);
> -
> -  return 0;
> -}
> -
> -
> -EGLImageKHR NvImporter::ImportImage(EGLDisplay egl_display,
> buffer_handle_t handle) {
> -  return eglCreateImageKHR(
> -  egl_display, EGL_NO_CONTEXT, EGL_NATIVE_HANDLE_ANDROID_NVX,
> -  (EGLClientBuffer)handle, NULL /* 

Re: [PATCH hwc] drm_hwcomposer: use upstream DRM_MODE_{ROTATE,REFLECT} defines

[Robert Foss]

Hey Rob,

This looks good to me, added r-b and pushed.


Rob.

On Fri, 2017-10-06 at 16:46 -0500, Rob Herring wrote:
> The DRM_REFLECT_* and DRM_ROTATE_* defines were not upstream, but now
> they are. Convert to using the upstream version which are defined as
> a
> bit mask rather than a bit position.
> 
> Signed-off-by: Rob Herring 
> ---
>  drmdisplaycompositor.cpp | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index a07d3588d1f5..036a45e8b88b 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -572,15 +572,15 @@ int
> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition
> *display_comp,
>  
>    rotation = 0;
>    if (layer.transform & DrmHwcTransform::kFlipH)
> -rotation |= 1 << DRM_REFLECT_X;
> +rotation |= DRM_MODE_REFLECT_X;
>    if (layer.transform & DrmHwcTransform::kFlipV)
> -rotation |= 1 << DRM_REFLECT_Y;
> +rotation |= DRM_MODE_REFLECT_Y;
>    if (layer.transform & DrmHwcTransform::kRotate90)
> -rotation |= 1 << DRM_ROTATE_90;
> +rotation |= DRM_MODE_ROTATE_90;
>    else if (layer.transform & DrmHwcTransform::kRotate180)
> -rotation |= 1 << DRM_ROTATE_180;
> +rotation |= DRM_MODE_ROTATE_180;
>    else if (layer.transform & DrmHwcTransform::kRotate270)
> -rotation |= 1 << DRM_ROTATE_270;
> +rotation |= DRM_MODE_ROTATE_270;
>  
>    if (fence_fd < 0) {
>  int prop_id = plane->in_fence_fd_property().id();
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] headers: sync DRM_MODE_ROTATE/REFLECT defines from kernel v4.14-rc1

[Robert Foss]

Hey Rob,

This looks good to me, feel free to add my r-b.


Rob.

On Fri, 2017-10-06 at 16:31 -0500, Rob Herring wrote:
> Add the new DRM_MODE_ROTATE_* and DRM_MODE_REFLECT_* defines from
> v4.14-rc1
> kernel.
> 
> Signed-off-by: Rob Herring 
> ---
>  include/drm/drm_mode.h | 47
> +++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index 080779785eb8..e01f129c0204 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -119,6 +119,53 @@ extern "C" {
>  #define DRM_MODE_LINK_STATUS_GOOD0
>  #define DRM_MODE_LINK_STATUS_BAD 1
>  
> +/*
> + * DRM_MODE_ROTATE_
> + *
> + * Signals that a drm plane is been rotated  degrees in
> counter
> + * clockwise direction.
> + *
> + * This define is provided as a convenience, looking up the property
> id
> + * using the name->prop id lookup is the preferred method.
> + */
> +#define DRM_MODE_ROTATE_0   (1<<0)
> +#define DRM_MODE_ROTATE_90  (1<<1)
> +#define DRM_MODE_ROTATE_180 (1<<2)
> +#define DRM_MODE_ROTATE_270 (1<<3)
> +
> +/*
> + * DRM_MODE_ROTATE_MASK
> + *
> + * Bitmask used to look for drm plane rotations.
> + */
> +#define DRM_MODE_ROTATE_MASK (\
> + DRM_MODE_ROTATE_0  | \
> + DRM_MODE_ROTATE_90  | \
> + DRM_MODE_ROTATE_180 | \
> + DRM_MODE_ROTATE_270)
> +
> +/*
> + * DRM_MODE_REFLECT_
> + *
> + * Signals that the contents of a drm plane is reflected in the
>  axis,
> + * in the same way as mirroring.
> + *
> + * This define is provided as a convenience, looking up the property
> id
> + * using the name->prop id lookup is the preferred method.
> + */
> +#define DRM_MODE_REFLECT_X  (1<<4)
> +#define DRM_MODE_REFLECT_Y  (1<<5)
> +
> +/*
> + * DRM_MODE_REFLECT_MASK
> + *
> + * Bitmask used to look for drm plane reflections.
> + */
> +#define DRM_MODE_REFLECT_MASK (\
> + DRM_MODE_REFLECT_X | \
> + DRM_MODE_REFLECT_Y)
> +
> +
>  struct drm_mode_modeinfo {
>   __u32 clock;
>   __u16 hdisplay;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [dim PATCH] dim: allow a space separated list of URLs for each repo in drm_tip_repos

[Daniel Stone]

Hey,

On 9 October 2017 at 11:30, Jani Nikula  wrote:
> On Tue, 03 Oct 2017, Jani Nikula  wrote:
>> I merged this last week with Daniel's IRC ack. We'll need to give people
>> a little bit of time before updating nightly.conf. Sorry for the
>> inconvenience in the mean time.
>
> Andrzej, all the bits and pieces for this have been pushed, so https://
> should just work for all repos *except* Dave's drm tree. I don't know
> why, but [1] doesn't advertize https for it.

Probably because it's not linked in from his public_html? He'd need to
do that, and also make sure that git-update-server-info was run in a
hook somewhere too.

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

Re: [PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and bw codes

[Thierry Reding]

On Mon, Oct 09, 2017 at 12:29:57PM +0300, Jani Nikula wrote:
> Falling back to the lowest value is likely the only thing we can do, but
> doing it silently seems like a bad thing to do. Catch it early and make
> loud noises.
> 
> Cc: Alex Deucher 
> Cc: Thierry Reding 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: Manasi Navare 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 08af8d6b844b..dca21b5a03ec 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -137,8 +137,10 @@ EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  u8 drm_dp_link_rate_to_bw_code(int link_rate)
>  {
>   switch (link_rate) {
> - case 162000:
>   default:
> + WARN(1, "unknown DP link rate %d, using %x\n", link_rate,
> +  DP_LINK_BW_1_62);
> + case 162000:
>   return DP_LINK_BW_1_62;
>   case 27:
>   return DP_LINK_BW_2_7;
> @@ -151,8 +153,9 @@ EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
>  int drm_dp_bw_code_to_link_rate(u8 link_bw)
>  {
>   switch (link_bw) {
> - case DP_LINK_BW_1_62:
>   default:
> + WARN(1, "unknown DP link bw code %x, using 162000\n", link_bw);

Nit: "DP link BW" because it is an abbreviation. Otherwise looks good:

Reviewed-by: Thierry Reding 


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

Re: [dim PATCH] dim: allow a space separated list of URLs for each repo in drm_tip_repos

[Jani Nikula]

On Tue, 03 Oct 2017, Jani Nikula  wrote:
> I merged this last week with Daniel's IRC ack. We'll need to give people
> a little bit of time before updating nightly.conf. Sorry for the
> inconvenience in the mean time.

Andrzej, all the bits and pieces for this have been pushed, so https://
should just work for all repos *except* Dave's drm tree. I don't know
why, but [1] doesn't advertize https for it.

BR,
Jani.


[1] https://cgit.freedesktop.org/~airlied/linux/

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

[drm-intel:for-linux-next 18/27] drivers/gpu//drm/i915/i915_gem_gtt.c:1087: error: 'iter' is used uninitialized in this function

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   a883241c3922000b21b58b5740c55badfe09940f
commit: 0a03852e049af91da9ae70326c44bb5d9b0d377a [18/27] drm/i915: support 2M 
pages for the 48b PPGTT
config: x86_64-randconfig-b0-10091604 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 0a03852e049af91da9ae70326c44bb5d9b0d377a
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   drivers/gpu//drm/i915/i915_gem_gtt.c: In function 'intel_ppat_get':
   drivers/gpu//drm/i915/i915_gem_gtt.c:2969: error: 'entry' may be used 
uninitialized in this function
   drivers/gpu//drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_insert_3lvl':
   drivers/gpu//drm/i915/i915_gem_gtt.c:1007: error: 'iter.sg' is used 
uninitialized in this function
   drivers/gpu//drm/i915/i915_gem_gtt.c:1008: error: 'iter.dma' may be used 
uninitialized in this function
   drivers/gpu//drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_insert_4lvl':
>> drivers/gpu//drm/i915/i915_gem_gtt.c:1087: error: 'iter' is used 
>> uninitialized in this function

vim +/iter +1087 drivers/gpu//drm/i915/i915_gem_gtt.c

0a03852e0 Matthew Auld   2017-10-06  1078  
894ccebee Chris Wilson   2017-02-15  1079  static void 
gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
4a234c5fa Matthew Auld   2017-06-22  1080  
struct i915_vma *vma,
894ccebee Chris Wilson   2017-02-15  1081  enum 
i915_cache_level cache_level,
894ccebee Chris Wilson   2017-02-15  1082  u32 
unused)
894ccebee Chris Wilson   2017-02-15  1083  {
894ccebee Chris Wilson   2017-02-15  1084   struct i915_hw_ppgtt *ppgtt = 
i915_vm_to_ppgtt(vm);
894ccebee Chris Wilson   2017-02-15  1085   struct sgt_dma iter = {
4a234c5fa Matthew Auld   2017-06-22  1086   .sg = vma->pages->sgl,
894ccebee Chris Wilson   2017-02-15 @1087   .dma = 
sg_dma_address(iter.sg),
894ccebee Chris Wilson   2017-02-15  1088   .max = iter.dma + 
iter.sg->length,
894ccebee Chris Wilson   2017-02-15  1089   };
894ccebee Chris Wilson   2017-02-15  1090   struct 
i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
0a03852e0 Matthew Auld   2017-10-06  1091  
0a03852e0 Matthew Auld   2017-10-06  1092   if (vma->page_sizes.sg > 
I915_GTT_PAGE_SIZE) {
0a03852e0 Matthew Auld   2017-10-06  1093   
gen8_ppgtt_insert_huge_entries(vma, pdps, , cache_level);
0a03852e0 Matthew Auld   2017-10-06  1094   } else {
4a234c5fa Matthew Auld   2017-06-22  1095   struct gen8_insert_pte 
idx = gen8_insert_pte(vma->node.start);
894ccebee Chris Wilson   2017-02-15  1096  
0a03852e0 Matthew Auld   2017-10-06  1097   while 
(gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++],
0a03852e0 Matthew Auld   2017-10-06  1098   
 , , cache_level))
9e89f9ee3 Chris Wilson   2017-02-25  1099   
GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4);
f9b5b782c Michel Thierry 2015-07-30  1100   }
0a03852e0 Matthew Auld   2017-10-06  1101  }
f9b5b782c Michel Thierry 2015-07-30  1102  

:: The code at line 1087 was first introduced by commit
:: 894ccebee2b0e606ba9638d20dd87b33568482d7 drm/i915: Micro-optimise 
gen8_ppgtt_insert_entries()

:: TO: Chris Wilson 
:: CC: Chris Wilson 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/etnaviv: remove unnecessary clock stabilization delay

[Philipp Zabel]

There is no reason to wait for clock stabilization here, as the clock
framework guarantees that PLL clock sources are stable before clk_enable
returns.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 9f7999552cc31..561a955ee4022 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -449,9 +449,6 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
 
control = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
 
-   /* Wait for stable clock.  Vivante's code waited for 1ms */
-   usleep_range(1000, 1);
-
/* isolate the GPU. */
control |= VIVS_HI_CLOCK_CONTROL_ISOLATE_GPU;
gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, control);
-- 
2.11.0

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

[PATCH 1/2] drm/etnaviv: reduce reset delay

[Philipp Zabel]

After reset assertion, we only have to wait for the reset signals to
propagate through the GPU before deasserting the reset again. A few
hundred clock cycles should be more than enough. Replace the msleep(1),
which can actually take about 30 ms on i.MX6Q in some configurations,
with an usleep_range of a few microseconds. If the delay was too short,
the FE would not be idle afterwards, and the reset would be retried.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index fc9a6a83dfc77..9f7999552cc31 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -461,7 +461,7 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, control);
 
/* wait for reset. */
-   msleep(1);
+   usleep_range(10, 20);
 
/* reset soft reset bit. */
control &= ~VIVS_HI_CLOCK_CONTROL_SOFT_RESET;
-- 
2.11.0

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

[PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and bw codes

[Jani Nikula]

Falling back to the lowest value is likely the only thing we can do, but
doing it silently seems like a bad thing to do. Catch it early and make
loud noises.

Cc: Alex Deucher 
Cc: Thierry Reding 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: Manasi Navare 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_dp_helper.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 08af8d6b844b..dca21b5a03ec 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -137,8 +137,10 @@ EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 u8 drm_dp_link_rate_to_bw_code(int link_rate)
 {
switch (link_rate) {
-   case 162000:
default:
+   WARN(1, "unknown DP link rate %d, using %x\n", link_rate,
+DP_LINK_BW_1_62);
+   case 162000:
return DP_LINK_BW_1_62;
case 27:
return DP_LINK_BW_2_7;
@@ -151,8 +153,9 @@ EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
 int drm_dp_bw_code_to_link_rate(u8 link_bw)
 {
switch (link_bw) {
-   case DP_LINK_BW_1_62:
default:
+   WARN(1, "unknown DP link bw code %x, using 162000\n", link_bw);
+   case DP_LINK_BW_1_62:
return 162000;
case DP_LINK_BW_2_7:
return 27;
-- 
2.11.0

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

Re: [PATCH v5 1/2] staging: ion: simplify ioctl args checking function

[Benjamin Gaignard]

2017-09-27 15:20 GMT+02:00 Benjamin Gaignard :
> Make arguments checking more easy to read.
>

Hi Laura,

Even if we don't have found a solution for the second patch I believe
this one could be useful.
May I ask you your point of view on those few lines ?

Benjamin

> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/staging/android/ion/ion-ioctl.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion-ioctl.c 
> b/drivers/staging/android/ion/ion-ioctl.c
> index d9f8b14..e26b786 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -27,19 +27,18 @@ union ion_ioctl_arg {
>
>  static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
>  {
> -   int ret = 0;
> -
> switch (cmd) {
> case ION_IOC_HEAP_QUERY:
> -   ret = arg->query.reserved0 != 0;
> -   ret |= arg->query.reserved1 != 0;
> -   ret |= arg->query.reserved2 != 0;
> +   if (arg->query.reserved0 ||
> +   arg->query.reserved1 ||
> +   arg->query.reserved2)
> +   return -EINVAL;
> break;
> default:
> break;
> }
>
> -   return ret ? -EINVAL : 0;
> +   return 0;
>  }
>
>  /* fix up the cases where the ioctl direction bits are incorrect */
> --
> 2.7.4
>



-- 
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 v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

[Daniel Thompson]

On 06/10/17 19:01, Noralf Trønnes wrote:


Den 03.10.2017 11.04, skrev Daniel Vetter:

On Tue, Oct 03, 2017 at 09:51:49AM +0100, Daniel Thompson wrote:

On 03/10/17 09:03, Daniel Vetter wrote:

On Mon, Oct 02, 2017 at 12:00:54PM +0300, Jani Nikula wrote:
On Mon, 02 Oct 2017, Daniel Thompson  
wrote:
So I'm coming to this patchset cold but can you explain *why* 
something

wants to call of_find_backlight_by_node() when there is no backlight
support enabled. Why isn't the code that called is conditional on
BACKLIGHT_CLASS_DEVICE?

The undefined symbol issue is a pain but to be honest I'd rather 
solve

the use of undefined symbols by avoiding declaring them; this making
them into compile errors rather than link errors.

Typically the kernel header files define static inline stubs of the
functions when the actual functions aren't configured/built. The code
using the functions looks the same regardless of the config option, 
and

handles the -ENODEV or NULL or whatever returns from the stubs
gracefully. With the inlines, the compiler can usually throw out 
much of

the code anyway.

In this regard, the backlight interface is an exception, forcing the
callers to wrap the code around IS_ENABLED(BACKLIGHT_CLASS_DEVICE), 
not

the rule.

fwiw, I think it'd be great if we can move backlight over to the common
pattern, like everyone else. It's pretty big pain as-is ...

For sure, after Jani's mail yesterday I looked at the GMA500 driver and
concluded I didn't want code related to backlight having to look like 
that!


Currently the three main patterns of use are:

  1. Standalone drivers simple depend on BACKLIGHT_CLASS_DEVICE,
  2. Some compound drivers select BACKLIGHT_CLASS_DEVICE (the AMD DRM
 driver is an example of this),
  3. Other compound drivers perform heroics with the pre-processor.

The main reason I'm not just agreeing straight away is that, to adopt 
the
static inline pattern for the whole API, we have to believe that #3 
above is
desirable. Given the size and scope of the compound drivers in #3 
above, I

don't entirely understand why they want to avoid the select.
People love to over-configure their kernels and shave off a few bytes. 
And
big gpu drivers might have backlight support, but not always need it 
(e.g.

if you run without a panel as e.g. a tv set-top-box). Same with e.g. a
driver that supports both OF/DT and pci to find its devices.

On the desktop gpu driver side we don't really subscribe to this idea of
making everything optional, hence select (mostly), except select is a 
huge

pain. On the mobile/soc gpu side, #3 seems to be the desired outcome.
Doing static inline helpers for backlights would make both easier (since
in the end for desktop you just get a distro kernel that enables
everything anyway).

So yeah, imo if you think backlight should be a Kconfig, then it should
have static inline dummy functions to make life simpler for everyone. 
Only

exception are pure driver-only subsystem code which aren't ever called by
anything outside of your subsystem. But since the point of the backlight
subsystem is to provide backlight support to other drivers (there's still
the dream that we don't offload this onto userspace, that just doesn't
work well) we really should have these static inline helpers.


I suggest we put all the backlight subsystem only functionality we need,
into the backlight subsystem :-)
I've put together a suggestion below and I've deliberately dropped the
of_ infix in backlight_get() to make room for possible future additions
that can make it possible to set the connection between device and
backlight using platform table or ACPI, fashioned after gpiolib.


Looks good to me.

If I've read this right, other sub-systems can use these symbols with or 
without BACKLIGHT_CLASS_DEVICE and still compile OK?



Daniel.





include/linux/backlight.h:

/**
  * backlight_enable - Enable backlight
  * @bd: the backlight device to enable
  */
static inline int backlight_enable(struct backlight_device *bd)
{
     if (!bd)
         return 0;

     bd->props.power = FB_BLANK_UNBLANK;
     bd->props.state &= ~BL_CORE_FBBLANK;

     return backlight_update_status(bd);
}

/**
  * backlight_disable - Disable backlight
  * @bd: the backlight device to disable
  */
static inline int backlight_disable(struct backlight_device *bd)
{
     if (!bd)
         return 0;

     bd->props.power = FB_BLANK_POWERDOWN;
     bd->props.state |= BL_CORE_FBBLANK;

     return backlight_update_status(bd);
}

/**
  * backlight_put - Drop backlight reference
  * @bd: the backlight device to put
  */
static inline void backlight_put(struct backlight_device *bd)
{
     if (bd)
         put_device(bd->dev);
}

#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
struct backlight_device *backlight_get(struct device *dev);
struct backlight_device *devm_backlight_get(struct device *dev);
#else
static inline struct backlight_device *backlight_get(struct device *dev)
{
     return NULL;
}

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

[Daniel Vetter]

On Sun, Oct 08, 2017 at 03:43:35PM +0100, Chris Wilson wrote:
> Quoting Harsha Sharma (2017-10-08 15:04:07)
> > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device 
> > *dev,
> > ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8;
> > ifbdev->fb = fb;
> >  
> > -   drm_framebuffer_reference(>fb->base);
> > +   drm_framebuffer_put(>fb->base);
> 
> Whoops.

Hm yeah, how did this happen? Does cocci really do this, or is that an
accident from manually fixing stuff up?
-Daniel
-- 
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

Re: Fwd: linux video documentation ?

[Daniel Vetter]

On Fri, Oct 06, 2017 at 01:44:48PM -0500, Brad Walker wrote:
> I noticed this email address is listed as the relevant area for the
> Documentation/devicetree/bindings/video/ directory in the Linux kernel. I
> have a question about this.
> 
> I noticed the Documentation/devicetree/bindings/video/ is no longer in the
> Linux kernel repo. It was in release 4.3.6 but got dropped in release
> v4.4-rc1.
> 
> Is there a reason for this? I ask because I am using the
> "simple-framebuffer" and wanted to possibly make some improvements to the
> documentation.

video/ moved to display/, it's all still there.
-Daniel

> 
> Thanks for any insight you can provide.
> 
> -brad w.

> ___
> 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

Re: [PATCH v2 4/5] drm/vc4: remove bridge from driver internal structure

[Benjamin Gaignard]

2017-10-02 11:34 GMT+02:00 Benjamin Gaignard :
> With a call to drm_of_panel_bridge_remove() we could remove
> the bridge without store it in vc4_dpi internal driver structure.

+ Eric to get his point of view on that

>
> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 519cefe..72c9dbd 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -97,8 +97,6 @@ struct vc4_dpi {
>
> struct drm_encoder *encoder;
> struct drm_connector *connector;
> -   struct drm_bridge *bridge;
> -   bool is_panel_bridge;
>
> void __iomem *regs;
>
> @@ -251,10 +249,11 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
>  {
> struct device *dev = >pdev->dev;
> struct drm_panel *panel;
> +   struct drm_bridge *bridge;
> int ret;
>
> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> - , >bridge);
> + , );
> if (ret) {
> /* If nothing was connected in the DT, that's not an
>  * error.
> @@ -265,13 +264,10 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
> return ret;
> }
>
> -   if (panel) {
> -   dpi->bridge = drm_panel_bridge_add(panel,
> -  DRM_MODE_CONNECTOR_DPI);
> -   dpi->is_panel_bridge = true;
> -   }
> +   if (panel)
> +   bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI);
>
> -   return drm_bridge_attach(dpi->encoder, dpi->bridge, NULL);
> +   return drm_bridge_attach(dpi->encoder, bridge, NULL);
>  }
>
>  static int vc4_dpi_bind(struct device *dev, struct device *master, void 
> *data)
> @@ -352,8 +348,7 @@ static void vc4_dpi_unbind(struct device *dev, struct 
> device *master,
> struct vc4_dev *vc4 = to_vc4_dev(drm);
> struct vc4_dpi *dpi = dev_get_drvdata(dev);
>
> -   if (dpi->is_panel_bridge)
> -   drm_panel_bridge_remove(dpi->bridge);
> +   drm_of_panel_bridge_remove(dev->of_node, 0, 0);
>
> drm_encoder_cleanup(dpi->encoder);
>
> --
> 2.7.4
>



-- 
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: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 06.10.2017 19:23, Rob Herring wrote:
> On Fri, Oct 6, 2017 at 6:10 AM, Andrzej Hajda  wrote:
>> Hi Rob,
>>
>> Thanks for review.
>>
>> On 06.10.2017 01:12, Rob Herring wrote:
>>> On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote:
 These bindings allows to describe most known standard USB connectors
 and it should be possible to extend it if necessary.
 USB connectors, beside USB can be used to route other protocols,
 for example UART, Audio, MHL. In such case every device passing data
 through the connector should have appropriate graph bindings.
>>> Yay!
>>>
 Signed-off-by: Andrzej Hajda 
 ---
 There are few things for discussion (IMO):
 1. vendor specific connectors, I have added them here, but maybe better is
to place them in separate files.
>>> I'd worry about the standard connectors first, but probably good to have
>>> an idea of how vendor connectors need to be extended.
>>>
 2. physical connector description - I have split it to three properties:
type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
This tripled is able to describe all USB-standard connectors, but there
are also impossible combinations, for example(c, *, micro). Maybe better
would be to just enumerate all possible connectors in include file.
>>> We did "type" for hdmi-connector, but I think I'd really prefer
>>> compatible be used to distinguish as least where it may matter to s/w.
>>> In the HDMI case, they all are pretty much the same, just different
>>> physical size.
>> I guess that from S/W point of view only matters:
>> - which IP is connected to which part of the connector, and this can be
>> handled by port node(s),
>> - Type: A, B, C
>> - probably maximal supported speed of the connector - for example SS+
>> connectors have the same wires but different electrical characteristics
>> than SS as I understand,
>>
>> With this in mind maybe we can drop 'type' and introduce following
>> compatibles:
>> - usb-a-connector,
>> - usb-b-connector,
>> - usb-c-connector.
>> Encoding other properties in compatible would explode their number, so I
>> would prefer to avoid it.
>> I would leave other props:
>> max-speed: hs, ss, ss+,
>> (optional)size: micro, mini
>>
>> I would drop also unpopular/obsolete variants: type-ab, powered, they
>> can be added later if necessary.
>>
>> Just for reference, list of connectors defined by USB (>= 2) specifications:
>> 1. USB 2.0 (with later amendments):
>> - Standard-A plug and receptacle
>> - Standard-B plug and receptacle
>> - Mini-B plug and receptacle
>> - Micro-B plug and receptacle
>> - Micro-AB receptacle
>> - Micro-A plug
>> 2. USB 3.0:
>> - USB 3.0 Standard-A plug and receptacle
>> - USB 3.0 Standard-B plug and receptacle
>> - USB 3.0 Powered-B plug and receptacle
>> - USB 3.0 Micro-B plug and receptacle
>> - USB 3.0 Micro-A plug
>> - USB 3.0 Micro-AB receptacle
>> 3. USB 3.1:
>> - Enhanced SuperSpeed Standard-A plug and receptacle
>> - Enhanced SuperSpeed Standard-B plug and receptacle
>> - Enhanced SuperSpeed Micro-B plug and receptacle
>> - Enhanced SuperSpeed Micro-A plug
>> - Enhanced SuperSpeed Micro-AB receptacle
>> 4. USB-C (release 1.3):
>> - USB Full-Featured Type-C receptacle
>> - USB 2.0 Type-C receptacle
>> - USB Full-Featured Type-C plug
>> - USB 2.0 Type-C plug
>> - USB Type-C Power-Only plug
>>
 3. Numbering of port/remote nodes, currently only 0 is assigned for 
 Interface
Controller. Maybe other functions should be also assigned:
HS, SS, CC, SBU, ... whatever. Maybe functions should be described
as an additional property of remote node?
>>> child of the controller is also an option. There's already prec
>> Shall we support both solutions or just make one mandatory?
> Oops, I was just going to say for display, there's already precedent
> that ports are used. So that means at least SS should just be
> described with ports. Then HS probably should be a port too just to be
> symmetrical.
>
> The connector being a child of the USB-PD (or other controller chip)
> is probably the only thing that makes sense. I guess the question is
> whether there are cases where that doesn't make sense.
>
 ---
  .../bindings/connector/usb-connector.txt   | 49 
 ++
  1 file changed, 49 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/connector/usb-connector.txt

 diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
 b/Documentation/devicetree/bindings/connector/usb-connector.txt
 new file mode 100644
 index ..f3a4e85122d5
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
 @@ -0,0 +1,49 @@
 +USB Connector
 +=
 +
 +Required properties:
 +- compatible: "usb-connector"
 +  connectors with vendor specific 

[PATCH] drm/exynos: Fix potential NULL pointer dereference in suspend/resume paths

[Marek Szyprowski]

The patch 6e8edf8a7d8d: "drm/exynos: Fix suspend/resume support" introduced
a new code in suspend/resume paths. However it unconditionally dereference
drm_dev pointer, which might be NULL if suspend/resume happens before
Exynos DRM driver components bind. This patch fixes this issue.

Reported-by: Dan Carpenter 
Fixes: 6e8edf8a7d8d "drm/exynos: Fix suspend/resume support"
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e651a58c18cf..aa770bb0153c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -168,11 +168,13 @@ static struct drm_driver exynos_drm_driver = {
 static int exynos_drm_suspend(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
-   struct exynos_drm_private *private = drm_dev->dev_private;
+   struct exynos_drm_private *private;
 
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
 
+   private = drm_dev->dev_private;
+
drm_kms_helper_poll_disable(drm_dev);
exynos_drm_fbdev_suspend(drm_dev);
private->suspend_state = drm_atomic_helper_suspend(drm_dev);
@@ -188,11 +190,12 @@ static int exynos_drm_suspend(struct device *dev)
 static int exynos_drm_resume(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
-   struct exynos_drm_private *private = drm_dev->dev_private;
+   struct exynos_drm_private *private;
 
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
 
+   private = drm_dev->dev_private;
drm_atomic_helper_resume(drm_dev, private->suspend_state);
exynos_drm_fbdev_resume(drm_dev);
drm_kms_helper_poll_enable(drm_dev);
-- 
2.14.2

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

[PATCH] drm/exynos: Clear drvdata after component unbind

[Marek Szyprowski]

When components are unbound, DRM driver is unregistered and freed,
so clear drvdata to avoid potential use-after-free issue in
suspend/resume paths.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index aa770bb0153c..82b72425a42f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -430,6 +430,7 @@ static void exynos_drm_unbind(struct device *dev)
 
kfree(drm->dev_private);
drm->dev_private = NULL;
+   dev_set_drvdata(dev, NULL);
 
drm_dev_unref(drm);
 }
-- 
2.14.2

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

[PATCH 12/12] drm/i915: replace with

[Masahiro Yamada]

The header drivers/gpu/drm/i915/i915_gem_context.h requires the
definition of struct radix_tree_root, but does not need to know
anything about other radix tree stuff.

Include  instead of  to
reduce the number of included header files.

While we are here, let's add missing  where
radix tree accessors are used.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/i915/i915_gem.c| 1 +
 drivers/gpu/drm/i915/i915_gem_context.c| 1 +
 drivers/gpu/drm/i915/i915_gem_context.h| 2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 +
 drivers/gpu/drm/i915/i915_gem_object.h | 1 +
 5 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 19404c9..d2356eb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -37,6 +37,7 @@
 #include "intel_mocs.h"
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 58a2a44..34b2195 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -86,6 +86,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "i915_drv.h"
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 44688e2..0ebe11f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -27,7 +27,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 struct pid;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 92437f4..af9ee58 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -27,6 +27,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
b/drivers/gpu/drm/i915/i915_gem_object.h
index c30d8f8..a5a5506 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -25,6 +25,7 @@
 #ifndef __I915_GEM_OBJECT_H__
 #define __I915_GEM_OBJECT_H__
 
+#include 
 #include 
 
 #include 
-- 
2.7.4

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

[PATCH 00/12] radix-tree: split out struct radix_tree_root out to

[Masahiro Yamada]

The motivation of this series is to cut down unnecessary header
dependency in terms of radix tree.

Sub-systems or drivers that use radix-tree for data management
typically embed struct radix_tree_root in their data structures,
like this:

struct foo {
   ...

   struct radix_tree_root   foo_tree;
   ...
};

So,  needs to include ,
therefore, users of  include a lot of bloat
from .

If you see the definition of radix_tree_root,

   struct radix_tree_root {
   gfp_tgfp_mask;
   struct radix_tree_node   __rcu *rnode;
   };

it is a very simple structure.
It only depends on  for gfp_t and
 for __rcu.

By splitting out the radix_tree_root definition,
we can reduce the header file dependency.

Reducing the header dependency will help for speeding the kernel
build, suppressing unnecessary recompile of objects during
git-bisect'ing, etc.

The patch 1 is a trivial clean-up; it is just here
to avoid conflict.

The patch 2 is the main part of this series;
split out struct radix_tree_root.

The rest of the series replace 
with  where appropriate.

Please review if the idea is OK.

If it is OK, I'd like to know how to apply the series.

Perhaps, the first two for v4.15.  Then, rest of series
will be sent per-subsystem for v4.16?

Or, can somebody take care of the whole series?

I checked allmodconfig for x86 and arm64.
I am expecting 0 day testing will check it too.



Masahiro Yamada (12):
  radix-tree: replace  with 
  radix-tree: split struct radix_tree_root to 
  irqdomain: replace  with 
  writeback: replace  with 
  iocontext.h: replace  with

  fs: replace  with 
  blkcg: replace  with 
  fscache: include 
  sh: intc: replace  with 
  net/mlx4: replace  with 
  net/mlx5: replace  with 
  drm/i915: replace  with 

 drivers/gpu/drm/i915/i915_gem.c|  1 +
 drivers/gpu/drm/i915/i915_gem_context.c|  1 +
 drivers/gpu/drm/i915/i915_gem_context.h|  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  1 +
 drivers/gpu/drm/i915/i915_gem_object.h |  1 +
 drivers/net/ethernet/mellanox/mlx4/cq.c|  1 +
 drivers/net/ethernet/mellanox/mlx4/mlx4.h  |  2 +-
 drivers/net/ethernet/mellanox/mlx4/qp.c|  1 +
 drivers/net/ethernet/mellanox/mlx4/srq.c   |  1 +
 drivers/sh/intc/internals.h|  2 +-
 include/linux/backing-dev-defs.h   |  2 +-
 include/linux/blk-cgroup.h |  2 +-
 include/linux/fs.h |  2 +-
 include/linux/fscache.h|  1 +
 include/linux/iocontext.h  |  2 +-
 include/linux/irqdomain.h  |  2 +-
 include/linux/mlx4/device.h|  2 +-
 include/linux/mlx4/qp.h|  1 +
 include/linux/mlx5/driver.h|  2 +-
 include/linux/mlx5/qp.h|  1 +
 include/linux/radix-tree-root.h| 24 
 include/linux/radix-tree.h |  8 ++--
 22 files changed, 46 insertions(+), 16 deletions(-)
 create mode 100644 include/linux/radix-tree-root.h

-- 
2.7.4

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

Re: [PATCH 00/12] radix-tree: split out struct radix_tree_root out to

[Leon Romanovsky]

On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote:

<...>
>
> By splitting out the radix_tree_root definition,
> we can reduce the header file dependency.
>
> Reducing the header dependency will help for speeding the kernel
> build, suppressing unnecessary recompile of objects during
> git-bisect'ing, etc.

If we judge by the diffstat of this series, there won't be any
visible change in anything mentioned above.

<...>

>
> Masahiro Yamada (12):
>   radix-tree: replace  with 
>   radix-tree: split struct radix_tree_root to 
>   irqdomain: replace  with 
>   writeback: replace  with 
>   iocontext.h: replace  with
> 
>   fs: replace  with 
>   blkcg: replace  with 
>   fscache: include 
>   sh: intc: replace  with 
>   net/mlx4: replace  with 
>   net/mlx5: replace  with 
>   drm/i915: replace  with 
>
>  drivers/gpu/drm/i915/i915_gem.c|  1 +
>  drivers/gpu/drm/i915/i915_gem_context.c|  1 +
>  drivers/gpu/drm/i915/i915_gem_context.h|  2 +-
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  1 +
>  drivers/gpu/drm/i915/i915_gem_object.h |  1 +
>  drivers/net/ethernet/mellanox/mlx4/cq.c|  1 +
>  drivers/net/ethernet/mellanox/mlx4/mlx4.h  |  2 +-
>  drivers/net/ethernet/mellanox/mlx4/qp.c|  1 +
>  drivers/net/ethernet/mellanox/mlx4/srq.c   |  1 +
>  drivers/sh/intc/internals.h|  2 +-
>  include/linux/backing-dev-defs.h   |  2 +-
>  include/linux/blk-cgroup.h |  2 +-
>  include/linux/fs.h |  2 +-
>  include/linux/fscache.h|  1 +
>  include/linux/iocontext.h  |  2 +-
>  include/linux/irqdomain.h  |  2 +-
>  include/linux/mlx4/device.h|  2 +-
>  include/linux/mlx4/qp.h|  1 +
>  include/linux/mlx5/driver.h|  2 +-
>  include/linux/mlx5/qp.h|  1 +
>  include/linux/radix-tree-root.h| 24 
>  include/linux/radix-tree.h |  8 ++--
>  22 files changed, 46 insertions(+), 16 deletions(-)
>  create mode 100644 include/linux/radix-tree-root.h
>
> --
> 2.7.4
>


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: vc4: Fix race during binding

[Stefan Wahren]

> Eric Anholt  hat am 8. Oktober 2017 um 19:09 geschrieben:
> 
> 
> Stefan Wahren  writes:
> 
> > Hi Eric,
> >
> >> Eric Anholt  hat am 6. Oktober 2017 um 21:42 geschrieben:
> >> 
> >> 
> >> Stefan Wahren  writes:
> >> 
> >> > This fixes the race between vc4_overflow_mem_work and the init of the
> >> > job lock. Otherwise we could trigger a NULL pointer dereference
> >> > during VC4 binding.
> >> >
> >> > Link: https://github.com/anholt/linux/issues/114
> >> > Signed-off-by: Stefan Wahren 
> >> > Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
> >> > ---
> >> >  drivers/gpu/drm/vc4/vc4_gem.c | 1 -
> >> >  drivers/gpu/drm/vc4/vc4_irq.c | 1 +
> >> >  2 files changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/vc4/vc4_gem.c 
> >> > b/drivers/gpu/drm/vc4/vc4_gem.c
> >> > index d0c6bfb..47d964f 100644
> >> > --- a/drivers/gpu/drm/vc4/vc4_gem.c
> >> > +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> >> > @@ -1088,7 +1088,6 @@ vc4_gem_init(struct drm_device *dev)
> >> >  INIT_LIST_HEAD(>render_job_list);
> >> >  INIT_LIST_HEAD(>job_done_list);
> >> >  INIT_LIST_HEAD(>seqno_cb_list);
> >> > -spin_lock_init(>job_lock);
> >> >  
> >> >  INIT_WORK(>hangcheck.reset_work, vc4_reset_work);
> >> >  setup_timer(>hangcheck.timer,
> >> > diff --git a/drivers/gpu/drm/vc4/vc4_irq.c 
> >> > b/drivers/gpu/drm/vc4/vc4_irq.c
> >> > index 7d7af3a..d508d13 100644
> >> > --- a/drivers/gpu/drm/vc4/vc4_irq.c
> >> > +++ b/drivers/gpu/drm/vc4/vc4_irq.c
> >> > @@ -195,6 +195,7 @@ vc4_irq_preinstall(struct drm_device *dev)
> >> >  struct vc4_dev *vc4 = to_vc4_dev(dev);
> >> >  
> >> >  init_waitqueue_head(>job_wait_queue);
> >> > +spin_lock_init(>job_lock);
> >> >  INIT_WORK(>overflow_mem_work, vc4_overflow_mem_work);
> >> >  
> >> >  /* Clear any pending interrupts someone might have left around
> >> 
> >> Are you sure this is a fix?  We don't attach the IRQ handler until V3D
> >> bind, and vc4_gem_init happens before component_bind_all(), right?
> >
> > i agree i should have mark it as a RFC. But is it really impossible
> > that vc4_overflow_mem_work is triggered before vc4_gem_init?
> 
> As far as I can see, it gets queued from the IRQ handler, the IRQ
> handler is added during V3D bind, and binding happens after GEM init.
> 
> Hmm.  If we fail out of component binding and try again, we'll end up
> doing the job_wait_queue and overflow_mem_work initialization on the
> same pointer twice.  Will that cause any trouble?  We cancel any pending
> work during uninstall (V3D unbind path), but does drm_irq_uninstall()
> make sure that the irq handler has finished?

I cannot see an issue.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/12] radix-tree: split out struct radix_tree_root out to

[Masahiro Yamada]

2017-10-09 3:52 GMT+09:00 Leon Romanovsky :
> On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote:
>
> <...>
>>
>> By splitting out the radix_tree_root definition,
>> we can reduce the header file dependency.
>>
>> Reducing the header dependency will help for speeding the kernel
>> build, suppressing unnecessary recompile of objects during
>> git-bisect'ing, etc.
>
> If we judge by the diffstat of this series, there won't be any
> visible change in anything mentioned above.


Of course, judging by the diffstat is wrong.



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

Re: [PATCH 00/12] radix-tree: split out struct radix_tree_root out to

[Leon Romanovsky]

On Mon, Oct 09, 2017 at 02:58:58PM +0900, Masahiro Yamada wrote:
> 2017-10-09 3:52 GMT+09:00 Leon Romanovsky :
> > On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote:
> >
> > <...>
> >>
> >> By splitting out the radix_tree_root definition,
> >> we can reduce the header file dependency.
> >>
> >> Reducing the header dependency will help for speeding the kernel
> >> build, suppressing unnecessary recompile of objects during
> >> git-bisect'ing, etc.
> >
> > If we judge by the diffstat of this series, there won't be any
> > visible change in anything mentioned above.
>
>
> Of course, judging by the diffstat is wrong.
>

I'm more than happy to be wrong and you for sure can help me.
Can you provide any quantitative support of your claims?

Thanks

>
>
> --
> Best Regards
> Masahiro Yamada
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

[Greg KH]

On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote:
> The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, 
> which may sleep.
> The function call paths are:
> gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c)
>   gma_resume_pci
> pci_set_power_state
>   __pci_start_power_transition (drivers/pci/pci.c)
> msleep --> may sleep
> 
> gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c)
>   gma_resume_pci
> pci_enable_device
>   pci_enable_device_flags (drivers/pci/pci.c)
> do_pci_enable_device
>   pci_set_power_state
> __pci_start_power_transition
>   msleep --> may sleep
> 
> vt6655_suspend (acquire the spinlock) (drivers/staging/vt6655/device_main.c)
>   pci_set_power_state
> __pci_start_power_transition (drivers/pci/pci.c)
>   msleep --> may sleep
> 
> To fix these bugs, msleep is replaced with mdelay in 
> __pci_start_power_transition
> 
> These bugs are found by my static analysis tool and my code review.

Wait, no, why not fix the callers to not have a spinlock.  Those are the
only users of these calls that are doing so incorrectly, don't change
the PCI core for the fault of 2 broken drivers.

thanks,

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

[PATCH v3 3/4] drm/rockchip: Add support for Rockchip Soc RGB output interface

[Sandy Huang]

Some Rockchip CRTCs, like rv1108, can directly output parallel and
serial RGB data to panel or conversion chip, so we add this driver to
probe encoder and connector.

Signed-off-by: Sandy Huang 
---
Changes in v3:
  update for rgb-mode move to panel node.
Changes in v2:
  1. add error log when probe failed;
  2. update name_to_output_mode() according to sean's suggest;
  3. Fix uninitialized use of ret.

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c | 343 
 5 files changed, 356 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0c31f0a..85c7cc5 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -8,6 +8,7 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
@@ -65,4 +66,12 @@ config ROCKCHIP_LVDS
  Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
  support LVDS, rgb, dual LVDS output mode. say Y to enable its
  driver.
+
+config ROCKCHIP_RGB
+   bool "Rockchip RGB support"
+   help
+ Choose this option to enable support for Rockchip RGB output.
+ Some Rockchip CRTCs, like rv1108, can directly output parallel
+ and serial RGB format to panel or connect to a conversion chip.
+ say Y to enable its driver.
 endif
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a881d2c..f32a17f 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -13,5 +13,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 76d63de..265597c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -459,6 +459,8 @@ static int __init rockchip_drm_init(void)
CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver,
+   CONFIG_ROCKCHIP_RGB);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
CONFIG_ROCKCHIP_DW_HDMI);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 498dfbc..6b0ec7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver;
 extern struct platform_driver inno_hdmi_driver;
 extern struct platform_driver rockchip_dp_driver;
 extern struct platform_driver rockchip_lvds_driver;
+extern struct platform_driver rockchip_rgb_driver;
 extern struct platform_driver vop_platform_driver;
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c 
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
new file mode 100644
index 000..6227ed7
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -0,0 +1,343 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Sandy Huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_rgb(c) container_of(c, struct rockchip_rgb, connector)
+#define encoder_to_rgb(c) container_of(c, struct rockchip_rgb, encoder)
+
+struct rockchip_rgb {
+   struct device *dev;
+   

[PATCH v3 4/4] drm/rockchip: vop: Add more RGB output interface type

[Sandy Huang]

This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:

Documentation/devicetree/bindings/display/panel/panel-rgb.txt

Signed-off-by: Sandy Huang 
---
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e..59a01c3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -209,6 +209,8 @@ struct vop_data {
 #define ROCKCHIP_OUT_MODE_P888 0
 #define ROCKCHIP_OUT_MODE_P666 1
 #define ROCKCHIP_OUT_MODE_P565 2
+#define ROCKCHIP_OUT_MODE_S888 8
+#define ROCKCHIP_OUT_MODE_S888_DUMMY   12
 /* for use special outface */
 #define ROCKCHIP_OUT_MODE_ 15
 
-- 
2.7.4


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

[PATCH v3 0/4] Add support rockchip RGB output interface

[Sandy Huang]

This patches add support rockchip RGB output, Some Rockchip CRTCs, like rv1108,
can directly output parallel and serial RGB data to panel or to conversion chip.
So we add this driver to probe encoder and connector to support this case.

Sandy Huang (4):
  devicetree/bindings: display: Add doucument for RGB panels
  devicetree/bindings: display: Add document for rockchip RGB output
  drm/rockchip: Add support for Rockchip Soc RGB output interface
  drm/rockchip: vop: Add more RGB output interface type

 .../bindings/display/panel/panel-rgb.txt   | 116 +++
 .../bindings/display/rockchip/rockchip-rgb.txt |  72 +
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c| 343 +
 8 files changed, 546 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/panel-rgb.txt
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

-- 
2.7.4


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

Re: [PATCH v2 1/3] dt-bindings: Add document for rockchip RGB output interface

[Sandy Huang]

Hi rob,
Thanks for your reply.

在 2017/10/4 5:56, Rob Herring 写道:

On Fri, Sep 22, 2017 at 11:00:26AM +0800, Sandy Huang wrote:

This path add support rv1108 rgb output interface driver.

Signed-off-by: Sandy Huang 
---
Changes in v2:
  1. rename rockchip,rgb-mode to rgb-mode;


You can't just drop the vendor. This needs to be documented in a common
place that others will find and use. See panel-common.txt or
panel-dpi.txt.

Alternatively, you could just drop it and let the panel compatible imply
what the mode is.


ok, get it, i will move the rgb-mode to panel and describe it at 
panel-rgb.txt. the patches will be send soon later.



  2. delete reg for signle endpoint;

  .../bindings/display/rockchip/rockchip-rgb.txt | 78 ++
  1 file changed, 78 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
new file mode 100644
index 000..86bd1ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
@@ -0,0 +1,78 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+   - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+Required nodes:
+- rgb-mode: should be "p888", "p666", "p565", "s888", "s888-dummy"
+   - p888: output r8-g8-b8 at each dclk cycle for per-pixel
+   - p666: output r6-g6-b6 at each dclk cycle for per-pixel
+   - p565: output r5-g6-b5 at each dclk cycle for per-pixel
+   - s888: output r8-g8-b8 in three dclk cycle for per-pixel
+   - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel
+
+The rgb has two video ports described by:
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+   compatible = "auo,b101ean01";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+
+   ports {
+   panel_in_rgb: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RV1108:
+
+   rgb: rgb {
+   compatible = "rockchip,rv1108-rgb";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   rgb-mode = "p888";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in_vop: endpoint {
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+
+   rgb_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_out_panel: endpoint {
+   remote-endpoint = <_in_rgb>;
+   };
+   };
+   };
+   };
--
2.7.4








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

[PATCH v3 1/4] devicetree/bindings: display: Add doucument for RGB panels

[Sandy Huang]

Describe the panel property rgb-mode for parallel and serial
RGB output interface, include the connection relations for each
mode.

Signed-off-by: Sandy Huang 
---
 .../bindings/display/panel/panel-rgb.txt   | 116 +
 1 file changed, 116 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/panel-rgb.txt

diff --git a/Documentation/devicetree/bindings/display/panel/panel-rgb.txt 
b/Documentation/devicetree/bindings/display/panel/panel-rgb.txt
new file mode 100644
index 000..0c5b054
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-rgb.txt
@@ -0,0 +1,116 @@
+RGB Display Panel
+==
+
+This describe the panel property rgb-mode for parallel and serial
+RGB output interface. rgb-mode should be "p888", "p666", "p565", "s888"
+and "s888-dummy", the following describe the connection relations.
+
+p888 mode:
+   ___ ___ ___ ___ ___ ___ ___
+dclk__/   \___/   \___/   \___/   \___/   \___/   \___/   \___
+  __  __  __  __  __  __  __
+DATA23  ><__R7__><__R7__><__R7__><__R7__><__R7__><__R7__><__R7__><
+DATA22  ><__R6__><__R6__><__R6__><__R6__><__R6__><__R6__><__R6__><
+DATA21  ><__R5__><__R5__><__R5__><__R5__><__R5__><__R5__><__R5__><
+DATA20  ><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><
+DATA19  ><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><
+DATA18  ><__R2__><__R2__><__R2__><__R2__><__R2__><__R2__><__R2__><
+DATA17  ><__R1__><__R1__><__R1__><__R1__><__R1__><__R1__><__R1__><
+DATA16  ><__R0__><__R0__><__R0__><__R0__><__R0__><__R0__><__R0__><
+  __  __  __  __  __  __  __
+DATA15  ><__G7__><__G7__><__G7__><__G7__><__G7__><__G7__><__G7__><
+DATA14  ><__G6__><__G6__><__G6__><__G6__><__G6__><__G6__><__G6__><
+DATA13  ><__G5__><__G5__><__G5__><__G5__><__G5__><__G5__><__G5__><
+DATA12  ><__G4__><__G4__><__G4__><__G4__><__G4__><__G4__><__G4__><
+DATA11  ><__G3__><__G3__><__G3__><__G3__><__G3__><__G3__><__G3__><
+DATA10  ><__G2__><__G2__><__G2__><__G2__><__G2__><__G2__><__G2__><
+DATA9   ><__G1__><__G1__><__G1__><__G1__><__G1__><__G1__><__G1__><
+DATA8   ><__G0__><__G0__><__G0__><__G0__><__G0__><__G0__><__G0__><
+  __  __  __  __  __  __  __
+DATA7   ><__B7__><__B7__><__B7__><__B7__><__B7__><__B7__><__B7__><
+DATA6   ><__B6__><__B6__><__B6__><__B6__><__B6__><__B6__><__B6__><
+DATA5   ><__B5__><__B5__><__B5__><__B5__><__B5__><__B5__><__B5__><
+DATA4   ><__B4__><__B4__><__B4__><__B4__><__B4__><__B4__><__B4__><
+DATA3   ><__B3__><__B3__><__B3__><__B3__><__B3__><__B3__><__B3__><
+DATA2   ><__B2__><__B2__><__B2__><__B2__><__B2__><__B2__><__B2__><
+DATA1   ><__B1__><__B1__><__B1__><__B1__><__B1__><__B1__><__B1__><
+DATA0   ><__B0__><__B0__><__B0__><__B0__><__B0__><__B0__><__B0__><
+pixel   |   n   |  n+1  |  n+3  |  n+4  |  n+5  |  n+6  |  n+7  |
+
+p666 mode:
+   ___ ___ ___ ___ ___ ___ ___
+dclk__/   \___/   \___/   \___/   \___/   \___/   \___/   \___
+  __  __  __  __  __  __  __
+DATA17  ><__R5__><__R5__><__R5__><__R5__><__R5__><__R5__><__R5__><
+DATA16  ><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><
+DATA15  ><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><
+DATA14  ><__R2__><__R2__><__R2__><__R2__><__R2__><__R2__><__R2__><
+DATA13  ><__R1__><__R1__><__R1__><__R1__><__R1__><__R1__><__R1__><
+DATA12  ><__R0__><__R0__><__R0__><__R0__><__R0__><__R0__><__R0__><
+  __  __  __  __  __  __  __
+DATA11  ><__G5__><__G5__><__G5__><__G5__><__G5__><__G5__><__G5__><
+DATA10  ><__G4__><__G4__><__G4__><__G4__><__G4__><__G4__><__G4__><
+DATA9   ><__G3__><__G3__><__G3__><__G3__><__G3__><__G3__><__G3__><
+DATA8   ><__G2__><__G2__><__G2__><__G2__><__G2__><__G2__><__G2__><
+DATA7   ><__G1__><__G1__><__G1__><__G1__><__G1__><__G1__><__G1__><
+DATA6   ><__G0__><__G0__><__G0__><__G0__><__G0__><__G0__><__G0__><
+  __  __  __  __  __  __  __
+DATA5   ><__B5__><__B5__><__B5__><__B5__><__B5__><__B5__><__B5__><
+DATA4   ><__B4__><__B4__><__B4__><__B4__><__B4__><__B4__><__B4__><
+DATA3   ><__B3__><__B3__><__B3__><__B3__><__B3__><__B3__><__B3__><
+DATA2   ><__B2__><__B2__><__B2__><__B2__><__B2__><__B2__><__B2__><
+DATA1   ><__B1__><__B1__><__B1__><__B1__><__B1__><__B1__><__B1__><
+DATA0   ><__B0__><__B0__><__B0__><__B0__><__B0__><__B0__><__B0__><
+pixel   |   n   |  n+1  |  n+3  |  n+4  |  n+5  |  n+6  |  n+7  |
+
+p565 mode:
+   ___ ___ ___ ___ ___ ___ ___
+dclk__/   \___/   \___/   \___/   \___/   \___/   \___/   \___
+  __  __  __  __  __  __  __
+DATA15  ><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><
+DATA14  ><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><
+DATA13  

[PATCH v3 2/4] devicetree/bindings: display: Add document for rockchip RGB output

[Sandy Huang]

This path add support rv1108 rgb output interface driver.

Signed-off-by: Sandy Huang 
---
Changes in v3:
 move rgb-mode to panel node which describe at:
 Documentation/devicetree/bindings/display/panel/panel-rgb.txt

Changes in v2:
 1. rename rockchip,rgb-mode to rgb-mode;
 2. delete reg for signle endpoint;
 .../bindings/display/rockchip/rockchip-rgb.txt | 72 ++
 1 file changed, 72 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
new file mode 100644
index 000..d91a7bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
@@ -0,0 +1,72 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+   - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+The rgb has two video ports described by:
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+rgb-mode nodes described by:
+   Documentation/devicetree/bindings/display/panel/panel-rgb.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+   compatible = "auo,b101ean01";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+   rgb-mode = "p888";
+
+   ports {
+   panel_in_rgb: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RV1108:
+
+   rgb: rgb {
+   compatible = "rockchip,rv1108-rgb";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in_vop: endpoint {
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+
+   rgb_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_out_panel: endpoint {
+   remote-endpoint = <_in_rgb>;
+   };
+   };
+   };
+   };
-- 
2.7.4


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

[Bug 103142] R600g+sb: optimizer apparently stuck in an endless loop

[bugzilla-daemon]

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

Gert Wollny  changed:

   What|Removed |Added

 Attachment #134738|0   |1
is obsolete||

--- Comment #1 from Gert Wollny  ---
Created attachment 134759
  --> https://bugs.freedesktop.org/attachment.cgi?id=134759=edit
Shader triggering the endless loop

I think the last log was not correct, i.e. it was not the right shader. This
new log shows different error messages. The the endless loop is happening in
"post_scheduler". 

I've run the code with R600_DEBUG=nocw,sbdump in addition to the PSC_DUMP. 
I've also tried R600_DEBUG=sbsafemath, but to no avail.

Snip of the log: 

# REGMAP :
current_AR: R42.x.199||@R1.x
  current_AR is R42.x.199||@R1.x  trying to use R41.x.235||@R0.z
  current_AR is R42.x.199||@R1.x  trying to use R42.x.200@R10.w
  current_AR is R42.x.199||@R1.x  trying to use R44.x.77@R7.z
!! interf slot: 2  : ADD t116||@R2.z,   
A100.y[R41.x.235||@R0.z]_763F@R8.y, A100.y[R43.x.126@R2.z]_764F@R8.y
rels:
A100.y[R41.x.235||@R0.z]_763F@R8.y :  <= R100.y.1F, R101.y.1F, R102.y.1F,
R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F
rels:
A100.y[R43.x.126@R2.z]_764F@R8.y :  <= R100.y.1F, R101.y.1F, R102.y.1F,
R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F
!! interf slot: 3  : MOV R43.z.49||@R10.w,   
A100.y[R42.x.200@R10.w]_759F@R8.y
rels:
A100.y[R42.x.200@R10.w]_759F@R8.y :  <= R100.y.1F, R101.y.1F, R102.y.1F,
R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F
!! interf slot: 4  : MOV R43.y.48||@R12.z,   
A100.x[R44.x.77@R7.z]_755F@R8.x
rels:
A100.x[R44.x.77@R7.z]_755F@R8.x :  <= R100.x.1F, R101.x.1F, R102.x.1F,
R103.x.1F, R104.x.1F, R105.x.1F, R106.x.1F, R107.x.1F, R108.x.1F, R109.x.1F
ci: discarding slots 28
discard_slots : packed_ops : 0
discarding slot 2 : ADD t116||@R2.z,A100.y[R41.x.235||@R0.z]_763F@R8.y,
A100.y[R43.x.126@R2.z]_764F@R8.y
rels:
A100.y[R41.x.235||@R0.z]_763F@R8.y :  <= R100.y.1F, R101.y.1F, R102.y.1F,
R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F
rels:
A100.y[R43.x.126@R2.z]_764F@R8.y :  <= R100.y.1F, R101.y.1F, R102.y.1F,
R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F
discarding slot 3 : MOV R43.z.49||@R10.w,   
A100.y[R42.x.200@R10.w]_759F@R8.y
rels:
A100.y[R42.x.200@R10.w]_759F@R8.y :  <= R100.y.1F, R101.y.1F, R102.y.1F,
R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F
discarding slot 4 : MOV R43.y.48||@R12.z,   
A100.x[R44.x.77@R7.z]_755F@R8.x
rels:
A100.x[R44.x.77@R7.z]_755F@R8.x :  <= R100.x.1F, R101.x.1F, R102.x.1F,
R103.x.1F, R104.x.1F, R105.x.1F, R106.x.1F, R107.x.1F, R108.x.1F, R109.x.1F
check_interferences: after: 
# REGMAP :
current_AR: R42.x.199||@R1.x
update_local_interferences : [R26.x.7F R26.y.7F R26.z.7F R27.x.7F R27.y.7F
R27.z.7F R28.x.7F R28.y.7F R28.z.7F R100.x.1F R101.x.1F R100.y.1F R101.y.1F
R102.x.1F R102.y.1F R103.x.1F R104.x.1F R103.y.1F R104.y.1F R105.x.1F R105.y.1F
R106.x.1F R107.x.1F R106.y.1F R107.y.1F R108.x.1F R108.y.1F R109.x.1F R109.y.1F
R4.x.410||@R6.w R41.x.194||@R4.y R42.x.184||@R2.y R43.x.112||@R12.y
R43.y.43||@R14.w R41.x.202||@R0.w R42.x.188||@R1.z R43.x.114||@R13.w
R43.y.44||@R7.w R4.x.423||@R5.w R41.x.213||@R2.w R42.x.195||@R3.y
R43.x.119||@R17.w R43.y.48||@R12.z R43.z.48||@R10.w R41.x.221||@R0.y
R42.x.199||@R1.x R44.x.78||@R3.x R43.z.49||@R10.w R4.x.436||@R4.w
R40.x.206||@R1.y R41.x.231||@R1.w R42.x.206||@R16.z R42.y.71||@R10.z
R42.z.71||@R8.w R40.x.214||@R0.x R41.x.235||@R0.z R42.x.208||@R9.z
R42.y.72||@R3.z R42.z.72||@R8.w t111||@R8.z t112||@R13.z t113||@R7.z
t114||@R3.x t115||@R3.w t116||@R2.z ]
p_a_g: MOV R42.x.206||@R16.z,A100.x[R41.x.231||@R1.w]_760F@R8.x
rels:
A100.x[R41.x.231||@R1.w]_760F@R8.x :  <= R100.x.1F, R101.x.1F, R102.x.1F,
R103.x.1F, R104.x.1F, R105.x.1F, R106.x.1F, R107.x.1F, R108.x.1F, R109.x.1F
slot: 2
current group:
slot 2 : MOV R42.x.206||@R16.z,A100.x[R41.x.231||@R1.w]_760F@R8.x
rels:
A100.x[R41.x.231||@R1.w]_760F@R8.x :  <= R100.x.1F, R101.x.1F, R102.x.1F,
R103.x.1F, R104.x.1F, R105.x.1F, R106.x.1F, R107.x.1F, R108.x.1F, R109.x.1F
p_a_g: MOV R43.z.48||@R10.w,A100.x[R42.x.196@R11.z]_756F@R8.x
rels:
A100.x[R42.x.196@R11.z]_756F@R8.x :  <= R100.x.1F, 

[RESEND PATCH v5] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

[Maciej Purski]

Add HDMI and Sil9234 MHL converter to Trats2 board.
Following in SoC devices have been enabled:
- HDMI (HDMI signal encoder),
- Mixer (video buffer scanout device),
- I2C_5 bus (used for HDMI DDC)
- I2C_8 bus (used for HDMI_PHY control).

Based on previous work by:
Tomasz Stanislawski 

Signed-off-by: Maciej Purski 
Reviewed-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 111 
 1 file changed, 111 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index bceb919..d7f77a6 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Samsung Trats 2 based on Exynos4412";
@@ -97,6 +98,34 @@
gpio = < 5 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   vsil12: voltage-regulator-6 {
+   compatible = "regulator-fixed";
+   regulator-name = "VSIL_1.2V";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   vin-supply = <_reg>;
+   };
+
+   vcc33mhl: voltage-regulator-7 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3.3_MHL";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vcc18mhl: voltage-regulator-8 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_1.8_MHL";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
};
 
gpio-keys {
@@ -229,6 +258,36 @@
};
};
 
+   i2c-mhl {
+   compatible = "i2c-gpio";
+   gpios = < 4 GPIO_ACTIVE_HIGH>, < 6 GPIO_ACTIVE_HIGH>;
+   i2c-gpio,delay-us = <100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pinctrl-0 = <_mhl_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   sii9234: hdmi-bridge@39 {
+   compatible = "sil,sii9234";
+   avcc33-supply = <>;
+   iovcc18-supply = <>;
+   avcc12-supply = <>;
+   cvcc12-supply = <>;
+   reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+   reg = <0x39>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+   };
+   };
+
camera: camera {
pinctrl-0 = <_port_a_clk_active _port_b_clk_active>;
pinctrl-names = "default";
@@ -501,6 +560,29 @@
status = "okay";
 };
 
+ {
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpd>;
+   vdd-supply = <_reg>;
+   vdd_osc-supply = <_reg>;
+   vdd_pll-supply = <_reg>;
+   ddc = <_5>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   hdmi_to_mhl: endpoint {
+   remote-endpoint = <_to_hdmi>;
+   };
+   };
+   };
+};
+
  {
vusb_d-supply = <_reg>;
vusb_a-supply = <_reg>;
@@ -579,6 +661,10 @@
};
 };
 
+_5 {
+   status = "okay";
+};
+
 _7 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -873,12 +959,20 @@
};
 };
 
+_8 {
+   status = "okay";
+};
+
  {
pinctrl-0 = <_bus>;
pinctrl-names = "default";
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
 _0 {
broken-cd;
non-removable;
@@ -904,6 +998,18 @@
pinctrl-names = "default";
pinctrl-0 = <>;
 
+   mhl_int: mhl-int {
+   samsung,pins = "gpf3-5";
+   samsung,pin-pud = ;
+   };
+
+   i2c_mhl_bus: i2c-mhl-bus {
+   samsung,pins = "gpf0-4", "gpf0-6";
+   

Re: [PATCH] drm: fix typo in drm_gem_get_pages() comment

[Jani Nikula]

On Wed, 04 Oct 2017, Daniel Vetter  wrote:
> On Tue, Oct 03, 2017 at 09:38:10AM -0600, Jordan Crouse wrote:
>> I spent an embarrassingly long time looking for drm_gem_init_object()
>> before I realized I was actually looking for drm_gem_object_init().
>> Fix the typo to keep other poor developers from suffering the same
>> fate.
>> 
>> Signed-off-by: Jordan Crouse 
>
> Yeah would be nice if sphinx would complain a bit louder about symlinks it
> can't find ...

But if it did, we'd never have been able to do a gradual conversion to
it!

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] drm/rockchip: Fix memory leak in rockchip_drm_sys_resume()

[jeffy]

Hi Sean,

On 09/28/2017 11:16 AM, jeffy wrote:

Hi Sean,

On 09/28/2017 04:27 AM, Sean Paul wrote:

>@@ -299,6 +300,7 @@ static int rockchip_drm_sys_resume(struct device
*dev)
>
>  priv = drm->dev_private;
>  drm_atomic_helper_resume(drm, priv->state);
>+drm_atomic_state_put(priv->state);

Won't this be freed for you eventually in commit_tail()?


i think the drm_atomic_state_put in commit_tail is paired to the
drm_atomic_state_get in drm_atomic_helper_commit.

and the kmemleak shows(after a few suspend/resume):

 unreferenced object 0xffc0ce0fa400 (size 256):
 ...
   backtrace:
 [] __save_stack_trace+0x48/0x6c
 [] create_object+0x138/0x254
 [] kmemleak_alloc+0x58/0x8c
 [] __kmalloc+0x1d4/0x2a0
 [] usb_alloc_urb+0x30/0x60
 [] alloc_ctrl_urb+0x38/0x120 [btusb]
 [] btusb_send_frame+0x64/0xf8 [btusb]


oops, the log is wrong...

it should be:
unreferenced object 0xffc0c75fe600 (size 256):
  comm "bash", pid 168, jiffies 4294748032 (age 557.932s)
  hex dump (first 32 bytes):
e0 4a 02 ce c0 ff ff ff 00 98 f2 c8 c0 ff ff ff  .J..
00 98 f2 c8 c0 ff ff ff 00 45 9f cb c0 ff ff ff  .E..
  backtrace:
[] kmemleak_alloc+0x58/0x8c
[] __kmalloc+0x1dc/0x2d4
[] drm_atomic_state_init+0xb8/0x114
[] drm_atomic_state_alloc+0x70/0xa4
[] drm_atomic_helper_duplicate_state+0x94/0x210
[] drm_atomic_helper_suspend+0xb4/0x160
[] rockchip_drm_sys_suspend+0x5c/0xa0
[] platform_pm_suspend+0x58/0x74
[] dpm_run_callback+0x13c/0x2f0
[] __device_suspend+0x28c/0x3fc
[] dpm_suspend+0x1cc/0x50c
[] dpm_suspend_start+0x8c/0xa4
[] suspend_devices_and_enter+0x12c/0xd84
[] pm_suspend+0xa38/0xb98
[] state_store+0xe0/0x108
[] kobj_attr_store+0x48/0x58


since it's allocated in the drm_atomic_helper_suspend(), maybe it would 
make more sense to unref it in drm_atomic_helper_resume(), i'll send a 
v2 patch for it :)







checking the current code, i saw only i915/intel_display.c has this
drm_atomic_state_put for the state allocated by
drm_atomic_helper_suspend(), there're many drivers missing that(or maybe
they free it in some other way?)


Sean






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

[PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()

[Jeffy Chen]

Kmemleak reported memory leak after suspend and resume:
unreferenced object 0xffc0e31d8880 (size 128):
  comm "bash", pid 181, jiffies 4294763583 (age 24.694s)
  hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 20 a2 eb c0 ff ff ff  . ..
01 00 00 00 00 00 00 00 80 87 1d e3 c0 ff ff ff  
  backtrace:
[] __save_stack_trace+0x48/0x6c
[] create_object+0x138/0x254
[] kmemleak_alloc+0x58/0x8c
[] kmem_cache_alloc_trace+0x188/0x254
[] drm_atomic_state_alloc+0x3c/0x88
[] drm_atomic_helper_duplicate_state+0x28/0x158
[] drm_atomic_helper_suspend+0x5c/0xf0

Problem here is that we are duplicating the drm_atomic_state in
drm_atomic_helper_suspend(), but not unreference it in the resume path.

Fixes: 1494276000db ("drm/atomic-helper: Implement subsystem-level 
suspend/resume")
Signed-off-by: Jeffy Chen 
---

Changes in v2:
Unref duplicated drm_atomic_state in drm_atomic_helper_resume() instead
of specific drivers.

 drivers/gpu/drm/drm_atomic_helper.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 01c34bc5b5b0..4a262380c631 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev,
drm_modeset_backoff();
}
 
+   drm_atomic_state_put(state);
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
 
-- 
2.11.0


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