[GIT PULL] drm/fsl-dcu: fixes for v4.9

[Stefan Agner]

Hi Dave,

Only three small fixes for this merge window, everything else is not
yet ready for v4.9.

--
Stefan

The following changes since commit 2b2fd56d7e92f134ecaae5c89e20f64dd0f95aa2:

  Revert "drm: make DRI1 drivers depend on BROKEN" (2016-09-01 06:16:12 +1000)

are available in the git repository at:

  http://git.agner.ch/git/linux-drm-fsl-dcu.git for-next

for you to fetch changes up to e0dc7c837dd0f514abce47101c04ce0ce243188e:

  drm/fsl-dcu: disable clock on error path (2016-09-05 12:32:55 -0700)


Fabio Estevam (1):
  drm/fsl-dcu: disable clock on error path

Stefan Agner (1):
  drm/fsl-dcu: fix endian issue when using clk_register_divider

Wei Yongjun (1):
  drm/fsl-dcu: use PTR_ERR_OR_ZERO() to simplify the code

 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 12 ++--
 drivers/gpu/drm/fsl-dcu/fsl_tcon.c|  5 +
 2 files changed, 11 insertions(+), 6 deletions(-)

[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage

[bugzilla-dae...@freedesktop.org]

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

Arek Ruśniak  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/9201c32d/attachment-0001.html>

[Bug 97634] [amdgpu SI] multigpu setup crashes during boot when dpm=1

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Arek Ruśniak  ---
Created attachment 126508
  --> https://bugs.freedesktop.org/attachment.cgi?id=126508=edit
dmesg log with latest drm-next-4.9-wip: 72bb0f5

modprobe -r amdgpu: at "148 
modprobe amdgpu: at "162

It's some kind of progress, because intel-gfx works but amdgpu doesn't start at
all. error from dmesg looks like the same:
https://bugs.freedesktop.org/show_bug.cgi?id=97801 

kernel: drm-next-4.9-wip: 72bb0f5

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/dabc8d00/attachment.html>

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Martin Steigerwald]

Hi.

Am Dienstag, 13. September 2016, 22:23:50 CEST schrieb Pavel Machek: 
> I have
> 
> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> Integrated Graphics Controller (rev 03)

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation 
Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)

Phoronix Test Suite system-info:

System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd 
Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, 
Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.8.0-rc6-tp520-btrfstrim+ (x86_64), Desktop: KDE 
Frameworks 5, Display Server: X Server 1.18.4, Display Driver: modesetting 
1.18.4, OpenGL: 3.3 Mesa 12.0.2, Compiler: GCC 6.2.0 20160901, File-System: 
btrfs, Screen Resolution: 3840x1080

> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> powersave) and all windows move to secondary monitor (VGA). Running
> "xrandr" fixes that.

I have seen this in 4.8 up to rc5 as well. I am not sure yet about rc6 which I 
am currently running.

I didn´t run xrandr by hand. But I ran systemsettings, dragged the second, 
deactivated external display back beneath the internal laptop display, 
activated it again and applied this changes. I think this has a somewhat 
similar effect as Plasma uses RANDR as well.

> I'll update to newer rc and see if it happens again, but if you have
> any ideas, now would be good time.

No ideas, sorry.

Thanks,
-- 
Martin

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Pavel Machek]

Hi!

I have

00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)

In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
in 10 resumes?) get in state where primary monitor (DVI) is dead (in
powersave) and all windows move to secondary monitor (VGA). Running
"xrandr" fixes that.

I'll update to newer rc and see if it happens again, but if you have
any ideas, now would be good time.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[Bug 97801] [amdgpu SI] "drm/amd/amdgpu: Tidy up SI SMC code" prevents amdgpu loading with dpm=1

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 97801
   Summary: [amdgpu SI] "drm/amd/amdgpu: Tidy up SI SMC code"
prevents amdgpu loading with dpm=1
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 126501
  --> https://bugs.freedesktop.org/attachment.cgi?id=126501=edit
dmesg log

This is quasi-bisected while I need apply patch newer than first bad commit.

So keep in mind that i always apply: drm/amd/amdgpu: Remove double lock from
gfx v6
see: https://bugs.freedesktop.org/show_bug.cgi?id=97594

kernel: drm-next-4.9-wip
boot with dpm=0 works, 
dmesg is attached

"first" bad commit: drm/amd/amdgpu: Tidy up SI SMC code
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.9-wip=c4f7beed7017652ca39fb475a1f423084944975e

Due i cannot simple revert i don't know if it's only problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/d85aa406/attachment.html>

[PATCH v3 4/4] arm: dts: qcom: apq8064-ifc6410: Add HDMI support

[Archit Taneja]

Add HDMI support on IFC6410. Populate the regulators required by HDMI-TX
and PHY. Establish the link between the MDP4 DTV encoder and HDMI. Create
a generic micro HDMI connector DT node. The msm drm driver doesn't parse
for HDMI connectors in DT, but it will do so later.

Cc: Rob Herring 
Cc: devicetree at vger.kernel.org

Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 2eeb090..3d37cab 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -43,6 +43,17 @@
};
};

+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "d";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
soc {
pinctrl at 80 {
card_detect: card_detect {
@@ -64,6 +75,25 @@
bias-disable;
};
};
+
+   hdmi_pinctrl: hdmi-pinctrl {
+   mux {
+   pins = "gpio70", "gpio71", "gpio72";
+   function = "hdmi";
+   };
+
+   pinconf_ddc {
+   pins = "gpio70", "gpio71";
+   bias-pull-up;
+   drive-strength = <2>;
+   };
+
+   pinconf_hpd {
+   pins = "gpio72";
+   bias-pull-down;
+   drive-strength = <16>;
+   };
+   };
};

rpm at 108000 {
@@ -329,5 +359,49 @@
mmc-pwrseq = <_pwrseq>;
};
};
+
+   hdmi-tx at 4a0 {
+   status = "okay";
+
+   core-vdda-supply = <_hdmi_switch>;
+   hdmi-mux-supply = <_3p3v>;
+
+   hpd-gpios = <_pinmux 72 GPIO_ACTIVE_HIGH>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pinctrl>;
+
+   ports {
+   port at 0 {
+   endpoint {
+   remote-endpoint = 
<_dtv_out>;
+   };
+   };
+
+   port at 1 {
+   endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
+
+   hdmi-phy at 4a00400 {
+   status = "okay";
+
+   core-vdda-supply = <_hdmi_switch>;
+   };
+
+   mdp at 510 {
+   status = "okay";
+
+   ports {
+   port at 3 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v3 3/4] arm: dts: qcom: apq8064: Add display DT nodes

[Archit Taneja]

APQ8064 contains a MDP4 based display controller. It contains a HDMI, LVDS
and 2 DSI outputs.

Add display DT nodes for MDP4, HDMI TX and HDMI PHY. MDP4 based display
blocks have a flat device hierarchy.

Nodes for other outputs will be added later.

Cc: Rob Herring 
Cc: devicetree at vger.kernel.org

Tested-by: John Stultz 
Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 91 +
 1 file changed, 91 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 74a9b6c..b688fb6 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -955,6 +955,97 @@
reset-names = "axi", "ahb", "por", "pci", "phy";
status = "disabled";
};
+
+   hdmi: hdmi-tx at 4a0 {
+   compatible = "qcom,hdmi-tx-8960";
+   reg = <0x04a0 0x2f0>;
+   reg-names = "core_physical";
+   interrupts = ;
+   clocks = < HDMI_APP_CLK>,
+< HDMI_M_AHB_CLK>,
+< HDMI_S_AHB_CLK>;
+   clock-names = "core_clk",
+ "master_iface_clk",
+ "slave_iface_clk";
+
+   phys = <_phy>;
+   phy-names = "hdmi-phy";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   hdmi_in: endpoint {
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   hdmi_out: endpoint {
+   };
+   };
+   };
+   };
+
+   hdmi_phy: hdmi-phy at 4a00400 {
+   compatible = "qcom,hdmi-phy-8960";
+   reg = <0x4a00400 0x60>,
+ <0x4a00500 0x100>;
+   reg-names = "hdmi_phy",
+   "hdmi_pll";
+
+   clocks = < HDMI_S_AHB_CLK>;
+   clock-names = "slave_iface_clk";
+   };
+
+   mdp: mdp at 510 {
+   compatible = "qcom,mdp4";
+   reg = <0x0510 0xf>;
+   interrupts = ;
+   clocks = < MDP_CLK>,
+< MDP_AHB_CLK>,
+< MDP_AXI_CLK>,
+< MDP_LUT_CLK>,
+< HDMI_TV_CLK>,
+< MDP_TV_CLK>;
+   clock-names = "core_clk",
+ "iface_clk",
+ "bus_clk",
+ "lut_clk",
+ "hdmi_clk",
+ "tv_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   mdp_lvds_out: endpoint {
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   mdp_dsi1_out: endpoint {
+   };
+   };
+
+   port at 2 {
+   reg = <2>;
+   mdp_dsi2_out: endpoint {
+   };
+   };
+
+   port at 3 {
+   reg = <3>;
+   mdp_dtv_out: endpoint {
+   };
+   };
+   };
+   };
};
 };
 #include "qcom-apq8064-pins.dtsi"
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v3 2/4] drm/msm/hdmi: Clean up HDMI gpio DT bindings

[Archit Taneja]

Make the following changes in the HDMI gpio bindings:

- Use "-gpios" as the suffix for all the gpio names
- Move all the gpios to optional, since there are platforms that use none
  of them.
- The HPD gpio is a standard one, remove the "qcom,hdmi-tx-" prefix from
  it.
- Remove the HDMI DDC clk/data gpios. They are just leftovers of an old
  way to configure pinctrl properties.
- Add a missing lpm gpio used on some platforms.

Make the necessary changes in the driver to incorporate these changes.

There hasn't been any upstream DT that uses the HDMI bindings, so it's
okay to change and move around these properties.

Cc: Rob Herring 
Cc: devicetree at vger.kernel.org
Signed-off-by: Archit Taneja 
---
v3:
- Removed HDMI DDC clk/data gpios.

 .../devicetree/bindings/display/msm/hdmi.txt|  9 -
 drivers/gpu/drm/msm/hdmi/hdmi.c | 21 +++--
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt 
b/Documentation/devicetree/bindings/display/msm/hdmi.txt
index ce84459..bfa7259 100644
--- a/Documentation/devicetree/bindings/display/msm/hdmi.txt
+++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt
@@ -13,17 +13,16 @@ Required properties:
 - interrupts: The interrupt signal from the hdmi block.
 - clocks: device clocks
   See ../clocks/clock-bindings.txt for details.
-- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin
-- qcom,hdmi-tx-ddc-data-gpio: ddc data pin
-- qcom,hdmi-tx-hpd-gpio: hpd pin
 - core-vdda-supply: phandle to supply regulator
 - hdmi-mux-supply: phandle to mux regulator
 - phys: the phandle for the HDMI PHY device
 - phy-names: the name of the corresponding PHY device

 Optional properties:
-- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
-- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
+- hpd-gpios: hpd pin
+- qcom,hdmi-tx-mux-en-gpios: hdmi mux enable pin
+- qcom,hdmi-tx-mux-sel-gpios: hdmi mux select pin
+- qcom,hdmi-tx-mux-lpm-gpios: hdmi mux lpm pin
 - power-domains: reference to the power domain(s), if available.
 - pinctrl-names: the pin control state names; should contain "default"
 - pinctrl-0: the default pinctrl state (active)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 9737207..a968cad 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -422,12 +422,29 @@ static const struct {

 static int msm_hdmi_get_gpio(struct device_node *of_node, const char *name)
 {
-   int gpio = of_get_named_gpio(of_node, name, 0);
+   int gpio;
+
+   /* try with the gpio names as in the table (downstream bindings) */
+   gpio = of_get_named_gpio(of_node, name, 0);
if (gpio < 0) {
char name2[32];
-   snprintf(name2, sizeof(name2), "%s-gpio", name);
+
+   /* try with the gpio names as in the upstream bindings */
+   snprintf(name2, sizeof(name2), "%s-gpios", name);
gpio = of_get_named_gpio(of_node, name2, 0);
if (gpio < 0) {
+   char name3[32];
+
+   /*
+* try again after stripping out the "qcom,hdmi-tx"
+* prefix. This is mainly to match "hpd-gpios" used
+* in the upstream bindings
+*/
+   if (sscanf(name2, "qcom,hdmi-tx-%s", name3))
+   gpio = of_get_named_gpio(of_node, name3, 0);
+   }
+
+   if (gpio < 0) {
DBG("failed to get gpio: %s (%d)", name, gpio);
gpio = -1;
}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v3 1/4] drm/msm/mdp4: Fix issue with LCDC/LVDS port parsing

[Archit Taneja]

The LVDS port is the first in the list of the output ports in MDP4.
The driver assumed that if the port and its corresponding endpoint
is defined, then there should be a panel node too. This isn't
necessary since boards may not really use a LVDS panel. Don't fail
if there isn't a panel node available.

While we're at it, use of_graph_get_endpoint_by_regs instead of
of_graph_get_next_endpoint to make it more explicit that the LVDS
output is at port 0.

Tested-by: John Stultz 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 7b39e89..571a91e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -228,18 +228,21 @@ static struct device_node *mdp4_detect_lcdc_panel(struct 
drm_device *dev)
struct device_node *endpoint, *panel_node;
struct device_node *np = dev->dev->of_node;

-   endpoint = of_graph_get_next_endpoint(np, NULL);
+   /*
+* LVDS/LCDC is the first port described in the list of ports in the
+* MDP4 DT node.
+*/
+   endpoint = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!endpoint) {
-   DBG("no endpoint in MDP4 to fetch LVDS panel\n");
+   DBG("no LVDS remote endpoint\n");
return NULL;
}

-   /* don't proceed if we have an endpoint but no panel_node tied to it */
panel_node = of_graph_get_remote_port_parent(endpoint);
if (!panel_node) {
-   dev_err(dev->dev, "no valid panel node\n");
+   DBG("no valid panel node in LVDS endpoint\n");
of_node_put(endpoint);
-   return ERR_PTR(-ENODEV);
+   return NULL;
}

of_node_put(endpoint);
@@ -262,14 +265,12 @@ static int mdp4_modeset_init_intf(struct mdp4_kms 
*mdp4_kms,
switch (intf_type) {
case DRM_MODE_ENCODER_LVDS:
/*
-* bail out early if:
-* - there is no panel node (no need to initialize lcdc
-*   encoder and lvds connector), or
-* - panel node is a bad pointer
+* bail out early if there is no panel node (no need to
+* initialize LCDC encoder and LVDS connector)
 */
panel_node = mdp4_detect_lcdc_panel(dev);
-   if (IS_ERR_OR_NULL(panel_node))
-   return PTR_ERR(panel_node);
+   if (!panel_node)
+   return 0;

encoder = mdp4_lcdc_encoder_init(dev, panel_node);
if (IS_ERR(encoder)) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v3 0/4] drm/msm: HDMI support on IFC6410

[Archit Taneja]

This set adds the display DT parts for the APQ8064 based IFC6410 board.
There were a couple of small fixes/cleanups required in the driver to
use the correct bindings. Those are a part of this patchset too.

Changes in v3:
- Removed HDMI DDC clk/data gpios.

Changes in v2:
- Incorporated comments on HDMI gpio bindings as suggested by Rob H.

Archit Taneja (4):
  drm/msm/mdp4: Fix issue with LCDC/LVDS port parsing
  drm/msm/hdmi: Clean up HDMI gpio DT bindings
  arm: dts: qcom: apq8064: Add display DT nodes
  arm: dts: qcom: apq8064-ifc6410: Add HDMI support

 .../devicetree/bindings/display/msm/hdmi.txt   |  9 +--
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 74 ++
 arch/arm/boot/dts/qcom-apq8064.dtsi| 91 ++
 drivers/gpu/drm/msm/hdmi/hdmi.c| 21 -
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 23 +++---
 5 files changed, 200 insertions(+), 18 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH] dma-buf/sync_file: Always increment refcount when merging fences.

[Gustavo Padovan]

Hi Rafael,

2016-09-13 Rafael Antognolli :

> The refcount of a fence should be increased whenever it is added to a merged
> fence, since it will later be decreased when the merged fence is destroyed.
> Failing to do so will cause the original fence to be freed if the merged fence
> gets freed, but other places still referencing won't know about it.
> 
> This patch fixes a kernel panic that can be triggered by creating a fence that
> is expired (or increasing the timeline until it expires), then creating a
> merged fence out of it, and deleting the merged fence. This will make the
> original expired fence's refcount go to zero.
> 
> Signed-off-by: Rafael Antognolli 
> ---
> 
> Sample code to trigger the mentioned kernel panic (might need to be executed a
> couple times before it actually breaks everything):
> 
> static void test_sync_expired_merge(void)
> {
>int iterations = 1 << 20;
>int timeline;
>int i;
>int fence_expired, fence_merged;
> 
>timeline = sw_sync_timeline_create();
> 
>sw_sync_timeline_inc(timeline, 100);
>fence_expired = sw_sync_fence_create(timeline, 1);
>fence_merged = sw_sync_merge(fence_expired, fence_expired);
>sw_sync_fence_destroy(fence_merged);
> 
>for (i = 0; i < iterations; i++) {
>int fence = sw_sync_merge(fence_expired, fence_expired);
> 
>igt_assert_f(sw_sync_wait(fence, -1) > 0,
> "Failure waiting on fence\n");
>sw_sync_fence_destroy(fence);
>}
> 
>sw_sync_fence_destroy(fence_expired);
> }
> 
>  drivers/dma-buf/sync_file.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)


Thanks for spotting this.

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH] drm/nouveau/disp: remove unused function in sorg94.c

[Baoyou Xie]

We get 1 warning when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/disp/sorg94.c:49:1: warning: no previous 
prototype for 'g94_sor_output_new' [-Wmissing-prototypes]

In fact, this function is called by no one and not exported,
so this patch removes it.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/disp/sorg94.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorg94.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorg94.c
index 1bb9d66..4510cb6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorg94.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorg94.c
@@ -45,14 +45,6 @@ static const struct nvkm_output_func
 g94_sor_output_func = {
 };

-int
-g94_sor_output_new(struct nvkm_disp *disp, int index,
-  struct dcb_output *dcbE, struct nvkm_output **poutp)
-{
-   return nvkm_output_new_(_sor_output_func, disp,
-   index, dcbE, poutp);
-}
-
 
/***
  * DisplayPort
  
**/
-- 
2.7.4

[PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)

[Sumit Semwal]

Hi Chris,

On 29 August 2016 at 23:56, Gustavo Padovan  wrote:
> Hi Chris,
>
> 2016-08-29 Chris Wilson :
>
>> If we being polled with a timeout of zero, a nonblocking busy query,
>> we don't need to install any fence callbacks as we will not be waiting.
>> As we only install the callback once, the overhead comes from the atomic
>> bit test that also causes serialisation between threads.
>>
>> Signed-off-by: Chris Wilson 
>> Cc: Sumit Semwal 
>> Cc: Gustavo Padovan 
>> Cc: linux-media at vger.kernel.org
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: linaro-mm-sig at lists.linaro.org
>> ---
>>  drivers/dma-buf/sync_file.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> Indeed, we can shortcut this.
>
> Reviewed-by: Gustavo Padovan 
>
> Gustavo

Thanks; pushed to drm-misc.

Best,
Sumit.

[PATCH] Add drmModeAddFB2WithModifiers() which takes format modifiers

[Rob Clark]

On Tue, Sep 13, 2016 at 6:07 PM, Kristian H. Kristensen
 wrote:
> The only current user of this open codes the ioctl. Let's add an entry
> point for this to libdrm.
>
> Signed-off-by: Kristian H. Kristensen 
> ---
>  xf86drmMode.c | 21 +
>  xf86drmMode.h |  7 +++
>  2 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index f7b5948..2907c5c 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -270,10 +270,10 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t 
> height, uint8_t depth,
> return 0;
>  }
>
> -int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
> - uint32_t pixel_format, uint32_t bo_handles[4],
> - uint32_t pitches[4], uint32_t offsets[4],
> - uint32_t *buf_id, uint32_t flags)
> +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
> +   uint32_t pixel_format, uint32_t bo_handles[4],
> +   uint32_t pitches[4], uint32_t offsets[4],
> +   uint64_t modifier[4], uint32_t *buf_id, 
> uint32_t flags)
>  {
> struct drm_mode_fb_cmd2 f;
> int ret;
> @@ -286,6 +286,8 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
> memcpy(f.handles, bo_handles, 4 * sizeof(bo_handles[0]));
> memcpy(f.pitches, pitches, 4 * sizeof(pitches[0]));
> memcpy(f.offsets, offsets, 4 * sizeof(offsets[0]));
> +if (modifier)
> +   memcpy(f.modifier, modifier, 4 * sizeof(modifier[0]));

I can't quite tell if it is my email client or not, but the
whitespace/indentation here and below in drmModeAddFB2() looks funny..
other than that (and with that potentially fixed if needed), lgtm

Reviewed-by: Rob Clark 

> if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, )))
> return ret;
> @@ -294,6 +296,17 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t 
> height,
> return 0;
>  }
>
> +int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
> +  uint32_t pixel_format, uint32_t bo_handles[4],
> +  uint32_t pitches[4], uint32_t offsets[4],
> +  uint32_t *buf_id, uint32_t flags)
> +{
> +  return drmModeAddFB2WithModifiers(fd, width, height,
> +pixel_format, bo_handles,
> +pitches, offsets, NULL,
> +buf_id, flags);
> +}
> +
>  int drmModeRmFB(int fd, uint32_t bufferId)
>  {
> return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, );
> diff --git a/xf86drmMode.h b/xf86drmMode.h
> index 4de7bbb..02190ea 100644
> --- a/xf86drmMode.h
> +++ b/xf86drmMode.h
> @@ -369,6 +369,13 @@ extern int drmModeAddFB2(int fd, uint32_t width, 
> uint32_t height,
>  uint32_t pixel_format, uint32_t bo_handles[4],
>  uint32_t pitches[4], uint32_t offsets[4],
>  uint32_t *buf_id, uint32_t flags);
> +
> +/* ...with format modifiers */
> +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
> +   uint32_t pixel_format, uint32_t bo_handles[4],
> +   uint32_t pitches[4], uint32_t offsets[4],
> +   uint64_t modifier[4], uint32_t *buf_id, 
> uint32_t flags);
> +
>  /**
>   * Destroies the given framebuffer.
>   */
> --
> 2.8.0.rc3.226.g39d4020
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/4] drm/msm/hdmi: Clean up HDMI gpio DT bindings

[Archit Taneja]

On 9/13/2016 12:42 PM, Archit Taneja wrote:
>
>
> On 9/12/2016 6:49 PM, Rob Herring wrote:
>> On Thu, Sep 01, 2016 at 07:06:52PM +0530, Archit Taneja wrote:
>>> Make the following changes in the HDMI gpio bindings:
>>>
>>> - Use "-gpios" as the suffix for all the gpio names
>>> - Move all the gpios to optional, since there are platforms that use
>>> none
>>>of them.
>>> - The HPD gpio is a standard one, remove the "qcom,hdmi-tx-" prefix from
>>>it.
>>> - Add a missing lpm gpio used on some platforms.
>>>
>>> Make the necessary changes in the driver to incorporate these changes.
>>>
>>> There hasn't been any upstream DT that uses the HDMI bindings, so it's
>>> okay to change and move around these properties.
>>>
>>> Cc: Rob Herring 
>>> Cc: devicetree at vger.kernel.org
>>> Signed-off-by: Archit Taneja 
>>> ---
>>> v2:
>>> - Keep "qcom,hdmi-tx-" suffix for all gpios except for hpd.
>>> - Use "-gpios" suffix instead of "-gpio".
>>> - Move all the gpios to optional properties.
>>>
>>>   .../devicetree/bindings/display/msm/hdmi.txt| 11 ++-
>>>   drivers/gpu/drm/msm/hdmi/hdmi.c | 21
>>> +++--
>>>   2 files changed, 25 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt
>>> b/Documentation/devicetree/bindings/display/msm/hdmi.txt
>>> index ce84459..f1a83ab 100644
>>> --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt
>>> +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt
>>> @@ -13,17 +13,18 @@ Required properties:
>>>   - interrupts: The interrupt signal from the hdmi block.
>>>   - clocks: device clocks
>>> See ../clocks/clock-bindings.txt for details.
>>> -- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin
>>> -- qcom,hdmi-tx-ddc-data-gpio: ddc data pin
>>> -- qcom,hdmi-tx-hpd-gpio: hpd pin
>>>   - core-vdda-supply: phandle to supply regulator
>>>   - hdmi-mux-supply: phandle to mux regulator
>>>   - phys: the phandle for the HDMI PHY device
>>>   - phy-names: the name of the corresponding PHY device
>>>
>>>   Optional properties:
>>> -- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
>>> -- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
>>> +- qcom,hdmi-tx-ddc-clk-gpios: ddc clk pin
>>> +- qcom,hdmi-tx-ddc-data-gpios: ddc data pin
>>
>> Sorry, for raising another point, but couldn't you use the i2c-gpio
>> binding for these instead?
>
> I'm not entirely sure what these are used for either, they predate the
> APQ8064 SoC. They are certainly not bit-banged to implement i2c, since
> the driver just sets them to a high during driver initialization, and
> we have our dedicated i2c controller anyway.
>

I just checked some old qualcomm kernels. It looks like they were
passed as gpios just so that the pins could be configured(function,
pull up/down, strength etc) using gpiolib api. I guess these
kernels predated pinctrl drivers.

I will post a new revision of the patch with these removed.

Thanks,
Archit

> Rob,
>
> Are you aware why we have these for older SoCs?
>
> Thanks,
> Archit
>
>>
>>> +- hpd-gpios: hpd pin
>>> +- qcom,hdmi-tx-mux-en-gpios: hdmi mux enable pin
>>> +- qcom,hdmi-tx-mux-sel-gpios: hdmi mux select pin
>>> +- qcom,hdmi-tx-mux-lpm-gpios: hdmi mux lpm pin
>>>   - power-domains: reference to the power domain(s), if available.
>>>   - pinctrl-names: the pin control state names; should contain "default"
>>>   - pinctrl-0: the default pinctrl state (active)
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[ADV7393] DRM Encoder Slave or DRM Bridge

[Vikas Patil]

Thanks Tomi for quick comment.

I am thinking to base adv7393 driver on
"drivers\gpu\drm\omapdrm\displays\encoder-tc358768.c" as I don't think
any similar to adv7393 chip driver available. Could you please comment
if this will help to get adv chip running?

I tried to add the device tree config but after adding device
configuration related to adv7393, my first display stopped working and
whenever I run kmscube or modetest it fails.

I have following configuration related to displays. Could anyone tell
me if I am doing anything wrong in DTS configuration? What could be
going wrong when I enable adv7393 related config so display 1 stops
working?

I am not sure if I have to use "composite-video-connector" driver.
Could you please suggest?

display1:  VOUT3 --> LCD display
display2: VOUT1 --> ADV7393 --> CVBS OUT --> DISPLAY

dts configs:


 aliases {
display0 = 
display1 = _out;
};


lcd: display {

compatible = "omapdss,panel-dpi";

label = "lcd";

panel-timing {
clock-frequency = <2700>;
hactive = <800>;
vactive = <480>;

hfront-porch = <15>;
hback-porch = <7>;
hsync-len = <7>;

vfront-porch = <40>;
vback-porch = <4>;
vsync-len = <3>;

hsync-active = <1>;
vsync-active = <1>;
de-active = <0>;
pixelclk-active = <0>;
};

 port at lcd3 {
lcd_in: endpoint {
remote-endpoint = <_out3>;
};
};

};

 cvbs_out: connector {
compatible = "omapdss,composite-video-connector";
label = "cvbs_out";

port {
 cvbs_con: endpoint {
remote-endpoint = <_out>;
};
};
};


 {
   status = "okay";
   clock-frequency = <40>;

adv7393 at 54 {
compatible = "adi,adv7393";
reg = <0x54>;

pinctrl-names = "i2c", "ddc";

ddc-i2c-bus = <>;

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

port at 0 {
reg = <0>;

adv7393_in: endpoint at 0 {
remote-endpoint = <_out>;
};
};

port at 1 {
reg = <1>;

adv7393_out: endpoint at 0 {
remote-endpoint = <_con>;
};
};
};
};
};

 {
status = "okay";


ports {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";

port at lcd3 {
reg = <2>;

dpi_out3: endpoint {
remote-endpoint = <_in>;
data-lines = <24>;
};
};

port at lcd1 {
reg = <0>;

dpi_out: endpoint {
remote-endpoint = <_in>;
data-lines = <24>;
};
};
};
};




root at dra7xx-evm:~# modetest
trying to open device 'i915'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...failed
trying to open device 'tilcdc'...failed
trying to open device 'msm'...failed
trying to open device 'sti'...failed
trying to open device 'tegra'...failed
trying to open device 'imx-drm'...failed
trying to open device 'rockchip'...failed
trying to open device 'atmel-hlcdc'...failed
trying to open device 'fsl-dcu-drm'...failed
trying to open device 'vc4'...failed
no device found

root at dra7xx-evm:~# kmscube
trying to load module omapdrm...failed.
trying to load module tilcdc...failed.
trying to load module i915...failed.
trying to load module radeon...failed.
trying to load module nouveau...failed.
trying to load module vmwgfx...failed.
trying to load module exynos...failed.
could not open drm device
failed to initialize DRM

Thanks & Regards,
Vikash

On Tue, Sep 13, 2016 at 2:27 PM, Tomi Valkeinen  
wrote:
> Hi,
>
> On 13/09/16 11:47, Vikas Patil wrote:
>> Dear All,
>>
>> I also see some of the encoder driver are at
>> 

[PATCH v7 8/9] drm/mediatek: update DSI sub driver flow

[CK Hu]

Hi, YT:

On Mon, 2016-09-12 at 18:15 +0800, YT Shen wrote:
> Hi CK,
> 
> On Wed, 2016-09-07 at 12:58 +0800, CK Hu wrote:
> > Hi, YT:
> > 
> > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > This patch update enable/disable flow of DSI module and MIPI TX module
> > > 
> > > Signed-off-by: shaoming chen 
> > > Signed-off-by: YT Shen 
> > > ---
> > 
> > I think the description is too simple. Please briefly describe WHY of
> > this patch. The original enable/disable flow is workable, so why do you
> > need this patch? Without this patch, what problem would happen?
> Got it, we will update more descriptions in the next version.
> There is no transfer/interrupt function in the upstream DSI driver.
> We also implement the following function [1][2] in this patch series.
> 
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
> 
> [1] https://patchwork.kernel.org/patch/9310819/
> drm/mediatek: add dsi interrupt control
> [2] https://patchwork.kernel.org/patch/9310823/
> drm/mediatek: add dsi transfer function
> 

I suggest you to separate "DSI directly connect to panel" related
patches to another series because MT8173 could also apply it and it is
not essential for MT2701 if MT2701 use bridge IC for dsi.

Regards,
CK

> > 
> > Regards,
> > CK
> > 
> > 
> 
> 

[PATCH v8 4/9] drm/mediatek: update display module connections

[CK Hu]

Hi, YT:

On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> update connections for OVL, RDMA, BLS, DSI
> 
> Signed-off-by: YT Shen 
> ---

[snip...]

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 53065c7..0850aa4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -40,6 +40,7 @@ enum mtk_ddp_comp_type {
>  
>  enum mtk_ddp_comp_id {
>   DDP_COMPONENT_AAL,
> + DDP_COMPONENT_BLS,

I think this should be moved to an independent patch and title of it
should be "Add BLS component." If you keep it in this patch, title of
this patch should be modified as "Add BLS component and update display
module connections."

Regards,
CK

>   DDP_COMPONENT_COLOR0,
>   DDP_COMPONENT_COLOR1,
>   DDP_COMPONENT_DPI0,

[PATCH v7 7/9] drm/mediatek: add dsi transfer function

[CK Hu]

Hi, YT:

On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> Hi CK,
> 
> On Wed, 2016-09-07 at 10:33 +0800, CK Hu wrote:
> > Hi, YT:
> > 
> > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > From: shaoming chen 
> > > 
> > > add dsi read/write commands for transfer function
> > > 
> > > Signed-off-by: shaoming chen 
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_dsi.c | 188 
> > > +
> > >  1 file changed, 188 insertions(+)
> > > 
> > 
> > [snip...]
> > 
> > >  
> > > +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> > > +{
> > > + dsi->irq_data &= ~irq_bit;
> > > +}
> > > +
> > 
> > [snip...]
> > 
> > > +
> > > +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> > > +  unsigned int timeout)
> > > +{
> > > + s32 ret = 0;
> > > + unsigned long jiffies = msecs_to_jiffies(timeout);
> > > +
> > > + ret = wait_event_interruptible_timeout(_dsi_irq_wait_queue,
> > > +dsi->irq_data & irq_flag,
> > > +jiffies);
> > > + if (ret == 0) {
> > > + dev_info(dsi->dev, "Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
> > > +
> > > + mtk_dsi_enable(dsi);
> > > + mtk_dsi_reset_engine(dsi);
> > > + }
> > > +
> > > + return ret;
> > > +}
> > 
> > I think mtk_dsi_irq_data_clear() and mtk_dsi_wait_for_irq_done() should
> > be moved to the 6th patch [1] of this series because these two functions
> > deal the irq control.
> We will move mtk_dsi_irq_data_clear() to patch "drm/mediatek: add dsi
> interrupt control" and put mtk_dsi_wait_for_irq_done() here, because it
> is used in the transfer function.

mtk_dsi_irq_data_clear() is also only used in transfer function now. I
think both function could be used for other application rather than
transfer function, so these two function are general function for irq
control.

Regards,
CK

> 
> Regards,
> yt.shen
> > 
> > 
> > [1] https://patchwork.kernel.org/patch/9310819/
> > 
> > 
> > Regards,
> > CK
> > 
> 
> 

[Bug 97796] Parts of screen do not update

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 97796
   Summary: Parts of screen do not update
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: pmenzel at molgen.mpg.de

Created attachment 126486
  --> https://bugs.freedesktop.org/attachment.cgi?id=126486=edit
Screenshot to show tags and bar in window manager *awesome*

Using Linux 4.8-rc5, with X.Org X Server 1.18.4, certain parts of the screen do
not update right away. This happens in Xfce 4.12 [1] and the window manager
*awesome* 3.5.9 [2].

1. Changing a Firefox window from maximum to “reduced”/“normal” size, 
the part
were the Firefox window isn’t present anymore, is still present. Switching
between windows often fixes this.

2. In the window manager *awesome* the top bar is not updated when changing
tags (think of virtual screen, although different). See the attached screen,
which doesn’t show the problem, as doing the screenshot didn’t capture it,
despite me seeing it.

[1] https://www.xfce.org
[2] https://awesomewm.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/a7dd9364/attachment.html>

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Sun, 11 Sep 2016, James Hogan  wrote:
> I've just bisected a similar (same?) problem (slow increase and
> decrease of screen brightness with a period of a few seconds) to the
> same commit (this is on a Dell XPS 13 laptop)
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
>
> drm/i915: Get panel_type from OpRegion panel details
>
> the difference for me is that good commits used the acpi backlight,
> and bad ones used the intel backlight (/sys/class/backlight/). Its
> like intel_backlight is fighting with the firmware to control the
> backlight or something. Reverting the commit on v4.7.3 switches it
> back to the acpi backlight and all works nicely again.
>
> let me know if I can provide anything else to help debug.

Please try [1].

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala
 at linux.intel.com


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v8 6/9] drm/mediatek: add dsi interrupt control

[CK Hu]

Hi, YT:

On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi interrupt control
> 
> Signed-off-by: shaoming chen 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 78 
> ++
>  1 file changed, 78 insertions(+)
> 

[snip...]

>  
> +static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> +{
> + u32 inten = DSI_INT_ALL_BITS;
> +
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO)
> + inten &= ~(TE_RDY_INT_FLAG | EXT_TE_RDY_INT_FLAG);
> +
> + writel(inten, dsi->regs + DSI_INTEN);
> +}
> +

[snip...]

> +
> +static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> +{
> + struct mtk_dsi *dsi = dev_id;
> + u32 status, tmp;
> + u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;

Why do you only process these three irq? You also enable TE_RDY_INT_FLAG
& EXT_TE_RDY_INT_FLAG in mtk_dsi_set_interrupt_enable(). Process these
two irq here or not enable them in mtk_dsi_set_interrupt_enable().

Regards,
CK

> +
> + status = readl(dsi->regs + DSI_INTSTA) & flag;
> +
> + if (status) {
> + do {
> + mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
> + tmp = readl(dsi->regs + DSI_INTSTA);
> + } while (tmp & DSI_BUSY);
> +
> + mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
> + mtk_dsi_irq_data_set(dsi, status);
> + wake_up_interruptible(>irq_wait_queue);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +

UDL: screen update breakage

[poma]

https://bugzilla.redhat.com/show_bug.cgi?id=1375566

Guys,
do you use such a device - DisplayLink GPU USB2.0 ?

[PATCH i-g-t] tests/sw_sync: Add subtest test_sync_expired_merge

[Rafael Antognolli]

This test creates an already expired fence, then creates a merged fence
out of that expired one (passed twice to the merge operation), and
finally closes the merged fence. It shows that if the refcounts are
wrong on the original expired fence, it might get freed while still in
use. Usually a kernel panick will follow.

Signed-off-by: Rafael Antognolli 
---
 tests/sw_sync.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 4336659..31cde50 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -582,6 +582,31 @@ static void test_sync_multi_producer_single_consumer(void)
pthread_join(threads[i], NULL);
 }

+static void test_sync_expired_merge(void)
+{
+   int iterations = 1 << 20;
+   int timeline;
+   int i;
+   int fence_expired, fence_merged;
+
+   timeline = sw_sync_timeline_create();
+
+   sw_sync_timeline_inc(timeline, 100);
+   fence_expired = sw_sync_fence_create(timeline, 1);
+   fence_merged = sw_sync_merge(fence_expired, fence_expired);
+   sw_sync_fence_destroy(fence_merged);
+
+   for (i = 0; i < iterations; i++) {
+   int fence = sw_sync_merge(fence_expired, fence_expired);
+
+   igt_assert_f(sw_sync_wait(fence, -1) > 0,
+"Failure waiting on fence\n");
+   sw_sync_fence_destroy(fence);
+   }
+
+   sw_sync_fence_destroy(fence_expired);
+}
+
 static void test_sync_random_merge(void)
 {
int i, size, ret;
@@ -687,6 +712,9 @@ igt_main
igt_subtest("sync_multi_producer_single_consumer")
test_sync_multi_producer_single_consumer();

+   igt_subtest("sync_expired_merge")
+   test_sync_expired_merge();
+
igt_subtest("sync_random_merge")
test_sync_random_merge();
 }
-- 
2.7.4

[PATCH] dma-buf/sync_file: Always increment refcount when merging fences.

[Rafael Antognolli]

The refcount of a fence should be increased whenever it is added to a merged
fence, since it will later be decreased when the merged fence is destroyed.
Failing to do so will cause the original fence to be freed if the merged fence
gets freed, but other places still referencing won't know about it.

This patch fixes a kernel panic that can be triggered by creating a fence that
is expired (or increasing the timeline until it expires), then creating a
merged fence out of it, and deleting the merged fence. This will make the
original expired fence's refcount go to zero.

Signed-off-by: Rafael Antognolli 
---

Sample code to trigger the mentioned kernel panic (might need to be executed a
couple times before it actually breaks everything):

static void test_sync_expired_merge(void)
{
   int iterations = 1 << 20;
   int timeline;
   int i;
   int fence_expired, fence_merged;

   timeline = sw_sync_timeline_create();

   sw_sync_timeline_inc(timeline, 100);
   fence_expired = sw_sync_fence_create(timeline, 1);
   fence_merged = sw_sync_merge(fence_expired, fence_expired);
   sw_sync_fence_destroy(fence_merged);

   for (i = 0; i < iterations; i++) {
   int fence = sw_sync_merge(fence_expired, fence_expired);

   igt_assert_f(sw_sync_wait(fence, -1) > 0,
"Failure waiting on fence\n");
   sw_sync_fence_destroy(fence);
   }

   sw_sync_fence_destroy(fence_expired);
}

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

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 486d29c..6ce6b8f 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -178,11 +178,8 @@ static struct fence **get_fences(struct sync_file 
*sync_file, int *num_fences)
 static void add_fence(struct fence **fences, int *i, struct fence *fence)
 {
fences[*i] = fence;
-
-   if (!fence_is_signaled(fence)) {
-   fence_get(fence);
-   (*i)++;
-   }
+   fence_get(fence);
+   (*i)++;
 }

 /**
-- 
2.7.4

[PATCH 1/1] Revert "gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle"

[Tomi Valkeinen]

Hi Dave,

Ping on this. This one is already in drm-next, so one can just
cherry-pick it: 5a78ff7bf7e25191144b550961001bbf6c734da4

 Tomi

On 06/09/16 15:18, Tomi Valkeinen wrote:
> Hi Dave,
> 
> Can you pick this for drm-fixes? The bug is causing scary looking stack
> dumps when loading omapdrm.
> 
> Apparently this fix went into drm-next accidentally instead of
> drm-fixes. I hope having the same patch in both trees won't be causing
> any extra conflicts.
> 
>  Tomi
> 
> On 11/08/16 12:44, Peter Chen wrote:
>> This reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f.
>>
>> The of_get_next_parent will drop refcount on the passed node, so the reverted
>> patch is wrong, thanks for Tomi Valkeinen points it.
>>
>> Cc: Tomi Valkeinen 
>> Signed-off-by: Peter Chen 
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
>> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> index e256d87..dfd4e96 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> @@ -125,16 +125,15 @@ u32 dss_of_port_get_port_number(struct device_node 
>> *port)
>>  
>>  static struct device_node *omapdss_of_get_remote_port(const struct 
>> device_node *node)
>>  {
>> -struct device_node *np, *np_parent;
>> +struct device_node *np;
>>  
>>  np = of_parse_phandle(node, "remote-endpoint", 0);
>>  if (!np)
>>  return NULL;
>>  
>> -np_parent = of_get_next_parent(np);
>> -of_node_put(np);
>> +np = of_get_next_parent(np);
>>  
>> -return np_parent;
>> +return np;
>>  }
>>  
>>  struct device_node *
>>
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/d30201eb/attachment.sig>

[PATCH 2/3] drm: add ARM vendor format afbc

[Brian Starkey]

Hi Mark,

On Sat, Sep 10, 2016 at 10:29:03AM +0800, Mark Yao wrote:
>AFBC is arm vendor format, it's a compressed format.
>
>The AFBC format is supported by rk3399 vop big.
>
>We know little about AFBC layout, hope to some guys can
>fixme about the afbc comment.
>
>Signed-off-by: Mark Yao 
>---
> include/uapi/drm/drm_fourcc.h | 7 +++
> 1 file changed, 7 insertions(+)
>
>diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>index a5890bf..9a47d7e 100644
>--- a/include/uapi/drm/drm_fourcc.h
>+++ b/include/uapi/drm/drm_fourcc.h
>@@ -159,6 +159,7 @@ extern "C" {
> #define DRM_FORMAT_MOD_VENDOR_NV  0x03
> #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
> #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
>+#define DRM_FORMAT_MOD_VENDOR_ARM 0x06
> /* add more to the end as needed */
>
> #define fourcc_mod_code(vendor, val) \
>@@ -233,6 +234,12 @@ extern "C" {
>  */
> #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
>
>+/*
>+ * FIXME: AFBC is arm vendor format, it's a compressed format.
>+ *
>+ */
>+#define DRM_FORMAT_MOD_ARM_AFBC   fourcc_mod_code(ARM, 1)

Do you have any details about the exact type of AFBC data you are
consuming here?

We need to agree what exactly a buffer with the modifier
"DRM_FORMAT_MOD_ARM_AFBC" means. For instance the block size, whether
the data has the YUV transform applied, how the data is laid out in
memory etc.

We (ARM) want to make sure that the format modifiers we expose to
userspace for AFBC are precise and non-ambiguous, cover all
possible AFBC modifiers (of which there are many, and the list can
only get longer) and all possible AFBC consuming/producing IPs'
requirements.

We had intended to delay adding any AFBC format modifiers to DRM until
we'd had this kind of discussion internally to agree the exact set
of modifiers we need, but if you need this now then we can start that 
discussion here.

Thanks,
Brian

>+
> #if defined(__cplusplus)
> }
> #endif
>-- 
>1.9.1
>
>
>___
>dri-devel mailing list
>dri-devel at lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Add drmModeAddFB2WithModifiers() which takes format modifiers

[Kristian H. Kristensen]

The only current user of this open codes the ioctl. Let's add an entry
point for this to libdrm.

Signed-off-by: Kristian H. Kristensen 
---
 xf86drmMode.c | 21 +
 xf86drmMode.h |  7 +++
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index f7b5948..2907c5c 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -270,10 +270,10 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t height, 
uint8_t depth,
return 0;
 }

-int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
- uint32_t pixel_format, uint32_t bo_handles[4],
- uint32_t pitches[4], uint32_t offsets[4],
- uint32_t *buf_id, uint32_t flags)
+int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
+   uint32_t pixel_format, uint32_t bo_handles[4],
+   uint32_t pitches[4], uint32_t offsets[4],
+   uint64_t modifier[4], uint32_t *buf_id, 
uint32_t flags)
 {
struct drm_mode_fb_cmd2 f;
int ret;
@@ -286,6 +286,8 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
memcpy(f.handles, bo_handles, 4 * sizeof(bo_handles[0]));
memcpy(f.pitches, pitches, 4 * sizeof(pitches[0]));
memcpy(f.offsets, offsets, 4 * sizeof(offsets[0]));
+if (modifier)
+   memcpy(f.modifier, modifier, 4 * sizeof(modifier[0]));

if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, )))
return ret;
@@ -294,6 +296,17 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
return 0;
 }

+int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
+  uint32_t pixel_format, uint32_t bo_handles[4],
+  uint32_t pitches[4], uint32_t offsets[4],
+  uint32_t *buf_id, uint32_t flags)
+{
+  return drmModeAddFB2WithModifiers(fd, width, height,
+pixel_format, bo_handles,
+pitches, offsets, NULL,
+buf_id, flags);
+}
+
 int drmModeRmFB(int fd, uint32_t bufferId)
 {
return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, );
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 4de7bbb..02190ea 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -369,6 +369,13 @@ extern int drmModeAddFB2(int fd, uint32_t width, uint32_t 
height,
 uint32_t pixel_format, uint32_t bo_handles[4],
 uint32_t pitches[4], uint32_t offsets[4],
 uint32_t *buf_id, uint32_t flags);
+
+/* ...with format modifiers */
+int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
+   uint32_t pixel_format, uint32_t bo_handles[4],
+   uint32_t pitches[4], uint32_t offsets[4],
+   uint64_t modifier[4], uint32_t *buf_id, 
uint32_t flags);
+
 /**
  * Destroies the given framebuffer.
  */
-- 
2.8.0.rc3.226.g39d4020

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

[Christian König]

Am 13.09.2016 um 11:39 schrieb Chris Wilson:
> On Tue, Sep 13, 2016 at 10:44:11AM +0200, Christian König wrote:
>> Am 09.09.2016 um 03:15 schrieb Michel Dänzer:
>>> On 09/09/16 01:23 AM, Chris Wilson wrote:
 On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
> On 09/08/2016 08:30 AM, Chris Wilson wrote:
>> On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
>>> amdgpu-kms uses shared fences for its prime exported dmabufs,
>>> instead of an exclusive fence. Therefore we need to wait for
>>> all fences of the dmabuf reservation object to prevent
>>> unsynchronized rendering and flipping.
>> No. Fix the root cause as this affects not just flips but copies -
>> this implies that everybody using the resv object must wait for all
>> fences. The resv object is not just used for prime, but all fencing, so
>> this breaks the ability to schedule parallel operations across engine.
>> -Chris
>>
> Ok. I think i now understand the difference, but let's check: The
> exclusive fence is essentially acting a bit like a write-lock, and
> the shared fences as readers-locks? So you can have multiple readers
> but only one writer at a time?
 That's how we (i915.ko and I hope the rest of the world) are using them.
 In the model where here is just one reservation object on the GEM
 object, that reservation object is then shared between internal driver
 scheduling and external. We are reliant on being able to use buffers on
 multiple engines through the virtue of the shared fences, and to serialise
 after writes by waiting on the exclusive fence. (So we can have concurrent
 reads on the display engine, render engines and on the CPU - or
 alternatively an exclusive writer.)

 In the near future, i915 flips will wait on the common reservation object
 not only for dma-bufs, but also its own GEM objects.
> Ie.:
>
> Writer must wait for all fences before starting write access to a
> buffer, then attach the exclusive fence and signal it on end of
> write access. E.g., write to renderbuffer, write to texture etc.
 Yes.
> Readers must wait for exclusive fence, then attach a shared fence
> per reader and signal it on end of read access? E.g., read from
> texture, fb, scanout?
 Yes.
> Is that correct? In that case we'd have a missing exclusive fence in
> amdgpu for the linear target dmabuf? Probably beyond my level of
> knowledge to fix this?
 i915.ko requires the client to mark which buffers are written to.

 In ttm, there are ttm_validate_buffer objects which mark whether they
 should be using shared or exclusive fences. Afaict, in amdgpu they are
 all set to shared, the relevant user interface seems to be
 amdgpu_bo_list_set().
>>> This all makes sense to me.
>>>
>>> Christian, why is amdgpu setting only shared fences? Can we fix that?
>> No, amdgpu relies on the fact that we even allow concurrent write
>> accesses by userspace.
>>
>> E.g. one part of the buffer can be rendered by one engine while
>> another part could be rendered by another engine.
>>
>> Just imagine X which is composing a buffer with both the 3D engine
>> as well as the DMA engine.
>>
>> All engines need to run in parallel and you need to wait for all of
>> them to finish before scanout.
>>
>> Everybody which needs exclusive access to the reservation object
>> (like scanouts do) needs to wait for all fences, not just the
>> exclusive one.
>>
>> The Intel driver clearly needs to be fixed here.
> If you are not using implicit fencing, you have to pass explicit fences
> instead.

Which is exactly what we do, but only for the driver internally command 
submissions.

All command submissions from the same process can run concurrently with 
amdgpu, only when we see a fence from another driver or process we wait 
for it to complete before starting to run a command submission.

Other drivers can't make any assumption on what a shared access is 
actually doing (e.g. writing or reading) with a buffer.

So the model i915.ko is using the reservation object and it's shared 
fences is certainly not correct and needs to be fixed.

Regards,
Christian.

> -Chris
>

[PATCH v3 3/4] arm: dts: qcom: apq8064: Add display DT nodes

[Stephen Boyd]

On 09/13/2016 08:21 AM, Archit Taneja wrote:
> APQ8064 contains a MDP4 based display controller. It contains a HDMI, LVDS
> and 2 DSI outputs.
>
> Add display DT nodes for MDP4, HDMI TX and HDMI PHY. MDP4 based display
> blocks have a flat device hierarchy.
>
> Nodes for other outputs will be added later.
>
> Cc: Rob Herring 
> Cc: devicetree at vger.kernel.org
>
> Tested-by: John Stultz 
> Signed-off-by: Archit Taneja 
> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 91 
> +
>  1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 74a9b6c..b688fb6 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -955,6 +955,97 @@
>   reset-names = "axi", "ahb", "por", "pci", "phy";
>   status = "disabled";
>   };
> +
> + hdmi: hdmi-tx at 4a0 {
> + compatible = "qcom,hdmi-tx-8960";
> + reg = <0x04a0 0x2f0>;
> + reg-names = "core_physical";
> + interrupts = ;

Please specify the IRQ_TYPE that isn't NONE here.

> + clocks = < HDMI_APP_CLK>,
> +  < HDMI_M_AHB_CLK>,
> +  < HDMI_S_AHB_CLK>;
> + clock-names = "core_clk",
> +   "master_iface_clk",
> +   "slave_iface_clk";
> +
> + phys = <_phy>;
> + phy-names = "hdmi-phy";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + hdmi_in: endpoint {
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + hdmi_out: endpoint {
> + };
> + };
> + };
> + };
> +
> + hdmi_phy: hdmi-phy at 4a00400 {
> + compatible = "qcom,hdmi-phy-8960";
> + reg = <0x4a00400 0x60>,
> +   <0x4a00500 0x100>;
> + reg-names = "hdmi_phy",
> + "hdmi_pll";
> +
> + clocks = < HDMI_S_AHB_CLK>;
> + clock-names = "slave_iface_clk";
> + };
> +
> + mdp: mdp at 510 {
> + compatible = "qcom,mdp4";
> + reg = <0x0510 0xf>;
> + interrupts = ;

Same comment here.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 2/4] drm/msm/hdmi: Clean up HDMI gpio DT bindings

[Rob Herring]

On Tue, Sep 13, 2016 at 10:21 AM, Archit Taneja  
wrote:
> Make the following changes in the HDMI gpio bindings:
>
> - Use "-gpios" as the suffix for all the gpio names
> - Move all the gpios to optional, since there are platforms that use none
>   of them.
> - The HPD gpio is a standard one, remove the "qcom,hdmi-tx-" prefix from
>   it.
> - Remove the HDMI DDC clk/data gpios. They are just leftovers of an old
>   way to configure pinctrl properties.
> - Add a missing lpm gpio used on some platforms.
>
> Make the necessary changes in the driver to incorporate these changes.
>
> There hasn't been any upstream DT that uses the HDMI bindings, so it's
> okay to change and move around these properties.
>
> Cc: Rob Herring 
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Archit Taneja 
> ---
> v3:
> - Removed HDMI DDC clk/data gpios.
>
>  .../devicetree/bindings/display/msm/hdmi.txt|  9 -
>  drivers/gpu/drm/msm/hdmi/hdmi.c | 21 
> +++--
>  2 files changed, 23 insertions(+), 7 deletions(-)

Acked-by: Rob Herring 

[Bug 97618] W600 (Cape Verde PRO): reproducible hang on piglit test spec@ext_texture_lod_bias@lodbias in drmCommandWrite()

[bugzilla-dae...@freedesktop.org]

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

Dan Kegel  changed:

   What|Removed |Added

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

--- Comment #4 from Dan Kegel  ---
Installing from the padoka PPA did indeed solve my problem.
No warnings in /var/log/kern.log, either!
So fixed as of libgl1-mesa-dri 12.1~git1600912162600.546bc07~x~padoka0
et al.

(There are still 78 fails vs. 5984 passes, but IIRC that's less fails than
before.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/3f6adb58/attachment.html>

[PATCH] drm: Only use compat ioctl for addfb2 on X86/IA64

[Kristian H. Kristensen]

Similar to struct drm_update_draw, struct drm_mode_fb_cmd2 has an
unaligned 64 bit field (modifier). This get packed differently between
32 bit and 64 bit modes on architectures that can handle unaligned 64
bit access (X86 and IA64).  Other architectures pack the structs the
same and don't need the compat wrapper. Use the same condition for
drm_mode_fb_cmd2 as we use for drm_update_draw.

Signed-off-by: Kristian H. Kristensen 
---
 drivers/gpu/drm/drm_ioc32.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 57676f8..a628975 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -1015,6 +1015,7 @@ static int compat_drm_wait_vblank(struct file *file, 
unsigned int cmd,
return 0;
 }

+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
 typedef struct drm_mode_fb_cmd232 {
u32 fb_id;
u32 width;
@@ -1071,6 +1072,7 @@ static int compat_drm_mode_addfb2(struct file *file, 
unsigned int cmd,

return 0;
 }
+#endif

 static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_VERSION32)] = compat_drm_version,
@@ -1104,7 +1106,9 @@ static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_UPDATE_DRAW32)] = compat_drm_update_draw,
 #endif
[DRM_IOCTL_NR(DRM_IOCTL_WAIT_VBLANK32)] = compat_drm_wait_vblank,
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
[DRM_IOCTL_NR(DRM_IOCTL_MODE_ADDFB232)] = compat_drm_mode_addfb2,
+#endif
 };

 /**
-- 
2.8.0.rc3.226.g39d4020

[ADV7393] DRM Encoder Slave or DRM Bridge

[Vikas Patil]

Dear All,

I also see some of the encoder driver are at
"drivers/gpu/drm/omapdrm/displays/". I am confused about which driver
I should consider for reference for adv7393 driver development.

Do I need to use
"drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c" too along
with adv7393 driver?

Thanks & Regards,
Vikash

On Mon, Sep 12, 2016 at 5:59 PM, Vikas Patil  wrote:
> Dear All,
>
> I am trying to understand difference between "DRM Encoder slave
> driver" and "DRM bridge driver" as I need to write one for ADV7393
> Video Encoder Chip for the custom target
> based on DRA74x having following display connection.
>
> VOUT1 --> ADV7393 --> CVBS Out(ADV7393 is on I2C)
>
> Could anyone here explain what is the difference between two and which
> I need to implement for ADV7393 and why?
>
> I could see adv7393 driver available at "drivers/media/i2c/adv7393.c"
> in linux 4.4.14. Can I use this driver? My feeling is I can not use
> but why could not much understand.
> or Do I need to base my driver something like
> "drivers/gpu/drm/i2c/adv7511.c", however I also see it is converted to
> bridge driver and moved to  "drivers/gpu/drm/bridge/adv7511.c" [1]
>
> [1] http://www.spinics.net/lists/dri-devel/msg113244.html
>
> Thanking you all in advance.
>
> Thanks & Regards,
> Vikash

[PATCH v7 9/9] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> Hi CK,
> 
> On Wed, 2016-09-07 at 13:37 +0800, CK Hu wrote:
> > Hi, YT:
> > 
> > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > This patch add support for the Mediatek MT2701 DISP subsystem.
> > > There is only one OVL engine in MT2701.
> > > 
> > > Signed-off-by: YT Shen 
> > 
> > [snip...]
> > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > index 4b4e449..465819b 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > @@ -112,6 +112,7 @@ struct mtk_ddp_comp_match {
> > >  
> > >  static const struct mtk_ddp_comp_match 
> > > mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> > >   [DDP_COMPONENT_AAL] = { MTK_DISP_AAL,   0, NULL },
> > > + [DDP_COMPONENT_BLS] = { MTK_DISP_PWM,   0, NULL },
> > 
> > I think BLS is different than PWM, so this statement should be
> > 
> > [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL };
> The BLS module actually is a multifunction device, one of them is the
> PWM function.  We only upstream PWM function [1] now, and it is
> accepted.  When there are real use case (gamma function), we will update
> this part.  What do you think?

I think BLS = PWM + GAMMA and the device with register range from
0x1400a000 to 0x1400afff should be called BLS. I think this device is
called PWM in [1] because it just use its PWM function and it's not
suitable. At least in DRM driver, we should use the term BLS rather than
PWM. Maybe we should define as below:

[DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL };

and

{ .compatible = "mediatek,mt2701-disp-pwm",   .data = (void
*)MTK_DISP_BLS },


Regards,
CK

[1] https://patchwork.kernel.org/patch/9223001/

> 
> Regards,
> yt.shen
> 
> [1] https://patchwork.kernel.org/patch/9223001/
> 
> > 
> > 
> > >   [DDP_COMPONENT_COLOR0]  = { MTK_DISP_COLOR, 0, _color },
> > >   [DDP_COMPONENT_COLOR1]  = { MTK_DISP_COLOR, 1, _color },
> > >   [DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
> > 
> > Regards,
> > CK
> > 
> > 
> 
> 

[PATCH v2 2/4] drm/msm/hdmi: Clean up HDMI gpio DT bindings

[Archit Taneja]

On 9/12/2016 6:49 PM, Rob Herring wrote:
> On Thu, Sep 01, 2016 at 07:06:52PM +0530, Archit Taneja wrote:
>> Make the following changes in the HDMI gpio bindings:
>>
>> - Use "-gpios" as the suffix for all the gpio names
>> - Move all the gpios to optional, since there are platforms that use none
>>of them.
>> - The HPD gpio is a standard one, remove the "qcom,hdmi-tx-" prefix from
>>it.
>> - Add a missing lpm gpio used on some platforms.
>>
>> Make the necessary changes in the driver to incorporate these changes.
>>
>> There hasn't been any upstream DT that uses the HDMI bindings, so it's
>> okay to change and move around these properties.
>>
>> Cc: Rob Herring 
>> Cc: devicetree at vger.kernel.org
>> Signed-off-by: Archit Taneja 
>> ---
>> v2:
>> - Keep "qcom,hdmi-tx-" suffix for all gpios except for hpd.
>> - Use "-gpios" suffix instead of "-gpio".
>> - Move all the gpios to optional properties.
>>
>>   .../devicetree/bindings/display/msm/hdmi.txt| 11 ++-
>>   drivers/gpu/drm/msm/hdmi/hdmi.c | 21 
>> +++--
>>   2 files changed, 25 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt 
>> b/Documentation/devicetree/bindings/display/msm/hdmi.txt
>> index ce84459..f1a83ab 100644
>> --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt
>> +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt
>> @@ -13,17 +13,18 @@ Required properties:
>>   - interrupts: The interrupt signal from the hdmi block.
>>   - clocks: device clocks
>> See ../clocks/clock-bindings.txt for details.
>> -- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin
>> -- qcom,hdmi-tx-ddc-data-gpio: ddc data pin
>> -- qcom,hdmi-tx-hpd-gpio: hpd pin
>>   - core-vdda-supply: phandle to supply regulator
>>   - hdmi-mux-supply: phandle to mux regulator
>>   - phys: the phandle for the HDMI PHY device
>>   - phy-names: the name of the corresponding PHY device
>>
>>   Optional properties:
>> -- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
>> -- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
>> +- qcom,hdmi-tx-ddc-clk-gpios: ddc clk pin
>> +- qcom,hdmi-tx-ddc-data-gpios: ddc data pin
>
> Sorry, for raising another point, but couldn't you use the i2c-gpio
> binding for these instead?

I'm not entirely sure what these are used for either, they predate the
APQ8064 SoC. They are certainly not bit-banged to implement i2c, since
the driver just sets them to a high during driver initialization, and
we have our dedicated i2c controller anyway.

Rob,

Are you aware why we have these for older SoCs?

Thanks,
Archit

>
>> +- hpd-gpios: hpd pin
>> +- qcom,hdmi-tx-mux-en-gpios: hdmi mux enable pin
>> +- qcom,hdmi-tx-mux-sel-gpios: hdmi mux select pin
>> +- qcom,hdmi-tx-mux-lpm-gpios: hdmi mux lpm pin
>>   - power-domains: reference to the power domain(s), if available.
>>   - pinctrl-names: the pin control state names; should contain "default"
>>   - pinctrl-0: the default pinctrl state (active)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] drm/i915: Ignore OpRegion panel type on Ivy Bridge + Mobile

[Jani Nikula]

On Sun, 11 Sep 2016, Adrien Vergé  wrote:
> On Terra Mobile Ultrabook 1450 II (Core i5-3337U, i915 devid = 0x166),
> the screen is tiled in many 480×320 screens (like a mosaic) since v4.7.
> This laptop is simply unusable.
>
> I have bisected the cause to commit a05628195a0d ("drm/i915: Get
> panel_type from OpRegion panel details").
>
> Like for Skylake, it seems that using the OpRegion panel type (here, 0)
> causes the problem, whereas the VBT panel type (here, 7) gives a normal
> display. See commit aeddda06c1a7 ("drm/i915: Ignore panel type from
> OpRegion on SKL") for background on this Skylake fix.
>
> This patch ignores OpRegion panel type for Ivy Bridge + Mobile chips.

Please try this patch [1] instead, and reply to it if it works for you.

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala
 at linux.intel.com

>
> Tested-by: Adrien Vergé 
> Signed-off-by: Adrien Vergé 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index adca262..94e2db7 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1083,5 +1083,16 @@ intel_opregion_get_panel_type(struct drm_i915_private 
> *dev_priv)
>   return -ENODEV;
>   }
>  
> + /*
> +  * FIXME On Terra Mobile Ultrabook 1450 II (Intel Core i5-3337U) the
> +  * OpRegion panel type (0) results in tiled ("mosaic") display bug,
> +  * whereas the VBT panel type (7) gives a normal display.
> +  * Let's ignore the OpRegion panel type for this chip.
> +  */
> + if (IS_IVYBRIDGE(dev_priv) && IS_MOBILE(dev_priv)) {
> + DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> + return -ENODEV;
> + }
> +
>   return ret - 1;
>  }

-- 
Jani Nikula, Intel Open Source Technology Center

[ADV7393] DRM Encoder Slave or DRM Bridge

[Tomi Valkeinen]

Hi,

On 13/09/16 11:47, Vikas Patil wrote:
> Dear All,
> 
> I also see some of the encoder driver are at
> "drivers/gpu/drm/omapdrm/displays/". I am confused about which driver
> I should consider for reference for adv7393 driver development.
> 
> Do I need to use
> "drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c" too along
> with adv7393 driver?

At the moment omapdrm has its own encoder driver architecture, and you
have to use those if you use omapdrm. So yes, for DRA74x, you should
look at drivers/gpu/drm/omapdrm/displays/.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/bbab46b3/attachment.sig>

[PATCH for v4.8-rc6] drm/i915: fix pointer dereference in intel_dvo_init

[Jani Nikula]

On Mon, 12 Sep 2016, Stefan Christ  wrote:
> Loading the module i915 on my IBM Thinkpad X40 fails in the function
> intel_dvo_init(). The function tries to cleanup the struct drm_encoder
> that was never initialized. This happens when all intel_dvo_devices
> failed to be probed in the for loop. The backtrace was:

This is already fixed by

commit 8a07fed44b126f48020f122b9e6bf05d8c48f281
Author: Chris Wilson 
Date:   Tue Aug 23 10:25:58 2016 +0100

drm/i915/dvo: Remove dangling call to drm_encoder_cleanup()

in drm-intel-fixes and drm-fixes, headed to v4.8-rc7.

Thanks,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets

[Bjorn Andersson]

On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:

> Hi Vinod & Bjorn,
> 
> [..]
> 
> On Mon, 05 Sep 2016, Peter Griffin wrote:
> 
> > v8 actions some review feedback from Bjorn to the slim rproc driver, and 
> > also includes
> > a patch which fixes a recursive Kconfig error which is triggered when 
> > st_fdma selects
> > slim_rproc driver. The series has also been rebased on v4.8-rc3.
> > 
> > v9 actions some review feedback from Bjorn, Lee and Vinod. See below. 
> > Importantly a bug
> > was found during testing now that the platform boots without 
> > clk_ignore_unused parameter
> > whereby the clocks would not be enabled properly before firmware loading 
> > was attempted.
> > 
> > regards,
> > 
> > Peter.
> > 
> > Changes since v8:
> >  - Add MODULE_ALIAS (Vinod)
> >  - devm_kzalloc to devm_kcalloc (Vinod)
> >  - quisce tasklet initialised by vchan_init() (Vinod)
> >  - Don't make SLIM rproc user selectable (Bjorn)
> >  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
> >  - Various code style nits / commit message change (Lee)
> >  - Separate patch for '\n' kconfig removal (Vinod)
> 
> I hate to send a ping,

Sorry about that.

> but do you think we can merge this fdma series? It has gone
> through quite a few review rounds now.
> 

I think the remoteproc part looks good.

Vinod, I don't have any changes queued in remoteproc that should cause
merge issues. If you want to you could take the remoteproc patch
through your tree.


I do however think that the dts patches should go through arm-soc.

Regards,
Bjorn

[PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver

[Bjorn Andersson]

On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:

> slim core is used as a basis for many IPs in the STi
> chipsets such as fdma and demux. To avoid duplicating
> the elf loading code in each device driver a slim
> rproc driver has been created.
> 
> This driver is designed to be used by other device drivers
> such as fdma, or demux whose IP is based around a slim core.
> The device driver can call slim_rproc_alloc() to allocate
> a slim rproc and slim_rproc_put() when finished.
> 
> This driver takes care of ioremapping the slim
> registers (dmem, imem, slimcore, peripherals), whose offsets
> and sizes can change between IP's. It also obtains and enables
> any clocks used by the device. This approach avoids having
> a double mapping of the registers as slim_rproc does not register
> its own platform device. It also maps well to device tree
> abstraction as it allows us to have one dt node for the whole
> device.
> 
> All of the generic rproc elf loading code can be reused, and
> we provide start() stop() hooks to start and stop the slim
> core once the firmware has been loaded. This has been tested
> successfully with fdma driver.
> 
> Signed-off-by: Peter Griffin 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/remoteproc/Kconfig   |   4 +
>  drivers/remoteproc/Makefile  |   1 +
>  drivers/remoteproc/st_slim_rproc.c   | 364 
> +++
>  include/linux/remoteproc/st_slim_rproc.h |  58 +
>  4 files changed, 427 insertions(+)
>  create mode 100644 drivers/remoteproc/st_slim_rproc.c
>  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 1a8bf76a..a7bedc6 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -100,4 +100,8 @@ config ST_REMOTEPROC
> processor framework.
> This can be either built-in or a loadable module.
>  
> +config ST_SLIM_REMOTEPROC
> + tristate
> + select REMOTEPROC
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 92d3758..db1dae7 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)  += 
> da8xx_remoteproc.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)+= qcom_mdt_loader.o
>  obj-$(CONFIG_QCOM_Q6V5_PIL)  += qcom_q6v5_pil.o
>  obj-$(CONFIG_ST_REMOTEPROC)  += st_remoteproc.o
> +obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> diff --git a/drivers/remoteproc/st_slim_rproc.c 
> b/drivers/remoteproc/st_slim_rproc.c
> new file mode 100644
> index 000..1484e97
> --- /dev/null
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -0,0 +1,364 @@
> +/*
> + * SLIM core rproc driver
> + *
> + * Copyright (C) 2016 STMicroelectronics
> + *
> + * Author: Peter Griffin 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "remoteproc_internal.h"
> +
> +/* SLIM core registers */
> +#define SLIM_ID_OFST 0x0
> +#define SLIM_VER_OFST0x4
> +
> +#define SLIM_EN_OFST 0x8
> +#define SLIM_EN_RUN  BIT(0)
> +
> +#define SLIM_CLK_GATE_OFST   0xC
> +#define SLIM_CLK_GATE_DISBIT(0)
> +#define SLIM_CLK_GATE_RESET  BIT(2)
> +
> +#define SLIM_SLIM_PC_OFST0x20
> +
> +/* DMEM registers */
> +#define SLIM_REV_ID_OFST 0x0
> +#define SLIM_REV_ID_MIN_MASK GENMASK(15, 8)
> +#define SLIM_REV_ID_MIN(id)  ((id & SLIM_REV_ID_MIN_MASK) >> 8)
> +#define SLIM_REV_ID_MAJ_MASK GENMASK(23, 16)
> +#define SLIM_REV_ID_MAJ(id)  ((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> +
> +
> +/* peripherals registers */
> +#define SLIM_STBUS_SYNC_OFST 0xF88
> +#define SLIM_STBUS_SYNC_DIS  BIT(0)
> +
> +#define SLIM_INT_SET_OFST0xFD4
> +#define SLIM_INT_CLR_OFST0xFD8
> +#define SLIM_INT_MASK_OFST   0xFDC
> +
> +#define SLIM_CMD_CLR_OFST0xFC8
> +#define SLIM_CMD_MASK_OFST   0xFCC
> +
> +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> + [ST_SLIM_DMEM]  = "dmem",
> + [ST_SLIM_IMEM]  = "imem",
> +};
> +
> +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> +{
> + int clk, err;
> +
> + for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> + slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
> + if (IS_ERR(slim_rproc->clks[clk])) {
> + err = PTR_ERR(slim_rproc->clks[clk]);
> + if (err == -EPROBE_DEFER)
> + goto err_put_clks;
> + slim_rproc->clks[clk] = NULL;
> + 

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

[Christian König]

Am 09.09.2016 um 03:15 schrieb Michel Dänzer:
> On 09/09/16 01:23 AM, Chris Wilson wrote:
>> On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
>>> On 09/08/2016 08:30 AM, Chris Wilson wrote:
 On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
> amdgpu-kms uses shared fences for its prime exported dmabufs,
> instead of an exclusive fence. Therefore we need to wait for
> all fences of the dmabuf reservation object to prevent
> unsynchronized rendering and flipping.
 No. Fix the root cause as this affects not just flips but copies -
 this implies that everybody using the resv object must wait for all
 fences. The resv object is not just used for prime, but all fencing, so
 this breaks the ability to schedule parallel operations across engine.
 -Chris

>>> Ok. I think i now understand the difference, but let's check: The
>>> exclusive fence is essentially acting a bit like a write-lock, and
>>> the shared fences as readers-locks? So you can have multiple readers
>>> but only one writer at a time?
>> That's how we (i915.ko and I hope the rest of the world) are using them.
>> In the model where here is just one reservation object on the GEM
>> object, that reservation object is then shared between internal driver
>> scheduling and external. We are reliant on being able to use buffers on
>> multiple engines through the virtue of the shared fences, and to serialise
>> after writes by waiting on the exclusive fence. (So we can have concurrent
>> reads on the display engine, render engines and on the CPU - or
>> alternatively an exclusive writer.)
>>
>> In the near future, i915 flips will wait on the common reservation object
>> not only for dma-bufs, but also its own GEM objects.
>>   
>>> Ie.:
>>>
>>> Writer must wait for all fences before starting write access to a
>>> buffer, then attach the exclusive fence and signal it on end of
>>> write access. E.g., write to renderbuffer, write to texture etc.
>> Yes.
>>   
>>> Readers must wait for exclusive fence, then attach a shared fence
>>> per reader and signal it on end of read access? E.g., read from
>>> texture, fb, scanout?
>> Yes.
>>   
>>> Is that correct? In that case we'd have a missing exclusive fence in
>>> amdgpu for the linear target dmabuf? Probably beyond my level of
>>> knowledge to fix this?
>> i915.ko requires the client to mark which buffers are written to.
>>
>> In ttm, there are ttm_validate_buffer objects which mark whether they
>> should be using shared or exclusive fences. Afaict, in amdgpu they are
>> all set to shared, the relevant user interface seems to be
>> amdgpu_bo_list_set().
> This all makes sense to me.
>
> Christian, why is amdgpu setting only shared fences? Can we fix that?

No, amdgpu relies on the fact that we even allow concurrent write 
accesses by userspace.

E.g. one part of the buffer can be rendered by one engine while another 
part could be rendered by another engine.

Just imagine X which is composing a buffer with both the 3D engine as 
well as the DMA engine.

All engines need to run in parallel and you need to wait for all of them 
to finish before scanout.

Everybody which needs exclusive access to the reservation object (like 
scanouts do) needs to wait for all fences, not just the exclusive one.

The Intel driver clearly needs to be fixed here.

Regards,
Christian.

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

[Chris Wilson]

On Tue, Sep 13, 2016 at 10:44:11AM +0200, Christian König wrote:
> Am 09.09.2016 um 03:15 schrieb Michel Dänzer:
> >On 09/09/16 01:23 AM, Chris Wilson wrote:
> >>On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
> >>>On 09/08/2016 08:30 AM, Chris Wilson wrote:
> On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
> >amdgpu-kms uses shared fences for its prime exported dmabufs,
> >instead of an exclusive fence. Therefore we need to wait for
> >all fences of the dmabuf reservation object to prevent
> >unsynchronized rendering and flipping.
> No. Fix the root cause as this affects not just flips but copies -
> this implies that everybody using the resv object must wait for all
> fences. The resv object is not just used for prime, but all fencing, so
> this breaks the ability to schedule parallel operations across engine.
> -Chris
> 
> >>>Ok. I think i now understand the difference, but let's check: The
> >>>exclusive fence is essentially acting a bit like a write-lock, and
> >>>the shared fences as readers-locks? So you can have multiple readers
> >>>but only one writer at a time?
> >>That's how we (i915.ko and I hope the rest of the world) are using them.
> >>In the model where here is just one reservation object on the GEM
> >>object, that reservation object is then shared between internal driver
> >>scheduling and external. We are reliant on being able to use buffers on
> >>multiple engines through the virtue of the shared fences, and to serialise
> >>after writes by waiting on the exclusive fence. (So we can have concurrent
> >>reads on the display engine, render engines and on the CPU - or
> >>alternatively an exclusive writer.)
> >>
> >>In the near future, i915 flips will wait on the common reservation object
> >>not only for dma-bufs, but also its own GEM objects.
> >>>Ie.:
> >>>
> >>>Writer must wait for all fences before starting write access to a
> >>>buffer, then attach the exclusive fence and signal it on end of
> >>>write access. E.g., write to renderbuffer, write to texture etc.
> >>Yes.
> >>>Readers must wait for exclusive fence, then attach a shared fence
> >>>per reader and signal it on end of read access? E.g., read from
> >>>texture, fb, scanout?
> >>Yes.
> >>>Is that correct? In that case we'd have a missing exclusive fence in
> >>>amdgpu for the linear target dmabuf? Probably beyond my level of
> >>>knowledge to fix this?
> >>i915.ko requires the client to mark which buffers are written to.
> >>
> >>In ttm, there are ttm_validate_buffer objects which mark whether they
> >>should be using shared or exclusive fences. Afaict, in amdgpu they are
> >>all set to shared, the relevant user interface seems to be
> >>amdgpu_bo_list_set().
> >This all makes sense to me.
> >
> >Christian, why is amdgpu setting only shared fences? Can we fix that?
> 
> No, amdgpu relies on the fact that we even allow concurrent write
> accesses by userspace.
> 
> E.g. one part of the buffer can be rendered by one engine while
> another part could be rendered by another engine.
> 
> Just imagine X which is composing a buffer with both the 3D engine
> as well as the DMA engine.
> 
> All engines need to run in parallel and you need to wait for all of
> them to finish before scanout.
> 
> Everybody which needs exclusive access to the reservation object
> (like scanouts do) needs to wait for all fences, not just the
> exclusive one.
> 
> The Intel driver clearly needs to be fixed here.

If you are not using implicit fencing, you have to pass explicit fences
instead.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets

[Peter Griffin]

Hi Vinod & Bjorn,

[..]

On Mon, 05 Sep 2016, Peter Griffin wrote:

> v8 actions some review feedback from Bjorn to the slim rproc driver, and also 
> includes
> a patch which fixes a recursive Kconfig error which is triggered when st_fdma 
> selects
> slim_rproc driver. The series has also been rebased on v4.8-rc3.
> 
> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. 
> Importantly a bug
> was found during testing now that the platform boots without 
> clk_ignore_unused parameter
> whereby the clocks would not be enabled properly before firmware loading was 
> attempted.
> 
> regards,
> 
> Peter.
> 
> Changes since v8:
>  - Add MODULE_ALIAS (Vinod)
>  - devm_kzalloc to devm_kcalloc (Vinod)
>  - quisce tasklet initialised by vchan_init() (Vinod)
>  - Don't make SLIM rproc user selectable (Bjorn)
>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>  - Various code style nits / commit message change (Lee)
>  - Separate patch for '\n' kconfig removal (Vinod)

I hate to send a ping, but do you think we can merge this fdma series? It has 
gone
through quite a few review rounds now.

regards,

Peter.

[GIT PULL] drm/rockchip: some fixes

[Dave Airlie]

On 10 September 2016 at 12:57, Mark yao  wrote:
> Hi Dave
> Here are some little fixes for rockchip drm, looks good for me, and
> there is no doubt on them, So I'd like you can land them.
>
> Thanks.
>
> The following changes since commit 603f2c9f45c6620afd65b60ec084c1ea7c36b2ec:
>
>   Merge tag 'drm-vc4-fixes-2016-08-29' of https://github.com/anholt/linux
> into drm-fixes (2016-09-02 15:55:15 +1000)
>
> are available in the git repository at:
>
>
>   https://github.com/markyzq/kernel-drm-rockchip.git

Something is wrong with this pull request, there is no branch name.

Please test pull requests are complete before sending,

Thanks,
Dave.

[PATCH] drm/amdgpu: improve GTT BO alloc speed in OGL

[Michel Dänzer]

On 13/09/16 01:44 AM, Alex Deucher wrote:
> From: "monk.liu" 
> 
> original we use ttm_dma path to allocate GTT bo, which is too much
> slower than the path of ttm_pool, in most cases.
> 
> The swiotlb checks don't seem to work and we always end up in the
> slow path even when an IOMMU is available.

This change will break any cases where SWIOTLB is actually necessary
though, won't it?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 4/4] drm/ttm: move placement structures into ttm_placement.h

[zhoucm1]

On 2016年09月13日 05:00, Alex Deucher wrote:
> On Mon, Sep 12, 2016 at 7:46 AM, Christian König
>  wrote:
>> From: Christian König 
>>
>> Makes more sense to keep that together.
>>
>> Signed-off-by: Christian König 
>> Reviewed-by: Chunming Zhou 
> For the series:
> Reviewed-by: Alex Deucher 
The series is ok to me.

Regards,
David Zhou
>
>> ---
>>   include/drm/ttm/ttm_bo_api.h| 32 +---
>>   include/drm/ttm/ttm_placement.h | 35 +++
>>   2 files changed, 36 insertions(+), 31 deletions(-)
>>
>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>> index 97aaf5c..d73c7c2 100644
>> --- a/include/drm/ttm/ttm_bo_api.h
>> +++ b/include/drm/ttm/ttm_bo_api.h
>> @@ -45,37 +45,7 @@ struct ttm_bo_device;
>>
>>   struct drm_mm_node;
>>
>> -/**
>> - * struct ttm_place
>> - *
>> - * @fpfn:  first valid page frame number to put the object
>> - * @lpfn:  last valid page frame number to put the object
>> - * @flags: memory domain and caching flags for the object
>> - *
>> - * Structure indicating a possible place to put an object.
>> - */
>> -struct ttm_place {
>> -   unsignedfpfn;
>> -   unsignedlpfn;
>> -   uint32_tflags;
>> -};
>> -
>> -/**
>> - * struct ttm_placement
>> - *
>> - * @num_placement: number of preferred placements
>> - * @placement: preferred placements
>> - * @num_busy_placement:number of preferred placements when need to 
>> evict buffer
>> - * @busy_placement:preferred placements when need to evict buffer
>> - *
>> - * Structure indicating the placement you request for an object.
>> - */
>> -struct ttm_placement {
>> -   unsignednum_placement;
>> -   const struct ttm_place  *placement;
>> -   unsignednum_busy_placement;
>> -   const struct ttm_place  *busy_placement;
>> -};
>> +struct ttm_placement;
>>
>>   /**
>>* struct ttm_bus_placement
>> diff --git a/include/drm/ttm/ttm_placement.h 
>> b/include/drm/ttm/ttm_placement.h
>> index 7641582..932be0c 100644
>> --- a/include/drm/ttm/ttm_placement.h
>> +++ b/include/drm/ttm/ttm_placement.h
>> @@ -30,6 +30,9 @@
>>
>>   #ifndef _TTM_PLACEMENT_H_
>>   #define _TTM_PLACEMENT_H_
>> +
>> +#include 
>> +
>>   /*
>>* Memory regions for data placement.
>>*/
>> @@ -69,4 +72,36 @@
>>
>>   #define TTM_PL_MASK_MEMTYPE (TTM_PL_MASK_MEM | TTM_PL_MASK_CACHING)
>>
>> +/**
>> + * struct ttm_place
>> + *
>> + * @fpfn:  first valid page frame number to put the object
>> + * @lpfn:  last valid page frame number to put the object
>> + * @flags: memory domain and caching flags for the object
>> + *
>> + * Structure indicating a possible place to put an object.
>> + */
>> +struct ttm_place {
>> +   unsignedfpfn;
>> +   unsignedlpfn;
>> +   uint32_tflags;
>> +};
>> +
>> +/**
>> + * struct ttm_placement
>> + *
>> + * @num_placement: number of preferred placements
>> + * @placement: preferred placements
>> + * @num_busy_placement:number of preferred placements when need to 
>> evict buffer
>> + * @busy_placement:preferred placements when need to evict buffer
>> + *
>> + * Structure indicating the placement you request for an object.
>> + */
>> +struct ttm_placement {
>> +   unsignednum_placement;
>> +   const struct ttm_place  *placement;
>> +   unsignednum_busy_placement;
>> +   const struct ttm_place  *busy_placement;
>> +};
>> +
>>   #endif
>> --
>> 2.5.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon: avoid boot hang in Xen Dom0

[Jan Beulich]

While a hard hang in atom_asic_init() likely points at a deeper problem
in the driver, restore the capability to boot a Xen Dom0 by simply
avoiding the call there: Other than for Xen DomU, Dom0 owning a device
does not really mean is has got passed through to it.

In case it is of interest for further investigation, lspci for the
offending device says:

ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]

Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized 
environments"
Signed-off-by: Jan Beulich 
---
 drivers/gpu/drm/radeon/radeon_device.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- 4.8-rc6/drivers/gpu/drm/radeon/radeon_device.c
+++ 4.8-rc6-radeon-Xen-boot/drivers/gpu/drm/radeon/radeon_device.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "radeon_reg.h"
 #include "radeon.h"
 #include "atom.h"
@@ -642,7 +643,7 @@ void radeon_gtt_location(struct radeon_d
 static bool radeon_device_is_virtual(void)
 {
 #ifdef CONFIG_X86
-   return boot_cpu_has(X86_FEATURE_HYPERVISOR);
+   return boot_cpu_has(X86_FEATURE_HYPERVISOR) && !xen_initial_domain();
 #else
return false;
 #endif

[Bug 97783] TearFree fails in dual card configuration

[bugzilla-dae...@freedesktop.org]

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

--- Comment #6 from denisgolovan at yandex.ru ---
Yes, single line command works, but with some quirks.

Rotated display seems like lacks redraw(damage? not sure how to call them)
events in its bottom half. Does it has something to do with height of right
display? 
Mouse cursor leaves trails, moving windows leaves their contents on desktop,
etc.

I mean my display configuration is:
+--+---+
|  |   |
|1 | 3 |
|  |   |
|--|---|
|  |
|2 |
|  |
+--+

1,2 - halves on rotated display and 3 - horizontal monitor.
1 and 3 - redraw ok, 2 - does not.

Hope it'll help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/8541edb6/attachment-0001.html>

[Bug 97783] TearFree fails in dual card configuration

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Michel Dänzer  ---
Does

xrandr --output DisplayPort-1-1 --auto --rotate left --left-of DisplayPort-0

as a single command work?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/f47e9daa/attachment.html>

[Bug 97783] TearFree fails in dual card configuration

[bugzilla-dae...@freedesktop.org]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #126475|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/1753fcab/attachment.html>

[Bug 97783] TearFree fails in dual card configuration

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from denisgolovan at yandex.ru ---
Created attachment 126476
  --> https://bugs.freedesktop.org/attachment.cgi?id=126476=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/7f080c66/attachment-0001.html>

[Bug 97783] TearFree fails in dual card configuration

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from denisgolovan at yandex.ru ---
Created attachment 126475
  --> https://bugs.freedesktop.org/attachment.cgi?id=126475=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/76fa4fc9/attachment.html>

[Bug 97783] TearFree fails in dual card configuration

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from denisgolovan at yandex.ru ---
Created attachment 126474
  --> https://bugs.freedesktop.org/attachment.cgi?id=126474=edit
xorg.conf

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/ff6b7493/attachment.html>

[Bug 97783] TearFree fails in dual card configuration

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from denisgolovan at yandex.ru ---
Rotation without TearFree works, but tearing of large displays (2560x1440) is
scary.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/dbb77935/attachment.html>

[Bug 97783] TearFree fails in dual card configuration

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 97783
   Summary: TearFree fails in dual card configuration
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: denisgolovan at yandex.ru

Hi

I am trying to use radeon driver git (38797a33117222dadbc89e5f21ed8cd5deef9bea)
together with 2 radeon cards under Linux 64bit.

# uname -a
Linux denis-devuan 4.6.0-0.bpo.1-amd64 #1 SMP Debian 4.6.4-1~bpo8+1
(2016-08-11) x86_64 GNU/Linux

# lspci | grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus
LE [Radeon HD 8830M] (rev 87)
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus
LE [Radeon HD 8830M] (rev 87)

It works until I try to rotate one of outputs.
$ xrandr --setprovideroutputsource 1 0
$ xrandr --output DisplayPort-1-1 --auto
$ xrandr --output DisplayPort-1-1 --rotate left --left-of DisplayPort-0

Right after attempt to rotate rotated output hangs. The other one still works
though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/9a3c3480/attachment.html>

[PATCH v3] drm/fsl-dcu: Implement gamma_lut atomic crtc properties

[Meng Yi]

> > diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig
> > b/drivers/gpu/drm/fsl-dcu/Kconfig index 14a72c4..f9c76b1 100644
> > --- a/drivers/gpu/drm/fsl-dcu/Kconfig
> > +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
> > @@ -11,3 +11,9 @@ config DRM_FSL_DCU
> > help
> >   Choose this option if you have an Freescale DCU chipset.
> >   If M is selected the module will be called fsl-dcu-drm.
> > +
> > +config DRM_FSL_DCU_GAMMA
> > +   bool "Gamma Correction Support for NXP/Freescale DCU"
> > +   depends on DRM_FSL_DCU
> > +   help
> > + Enable support for gamma correction.
> 
> What is the reason for making this a configuration option? Are there
> implementation without support for the Gamma tables?
> 
When gamma correction is enabled, the color won't display normally since
The gamma tables are not filled with correct data. So I give a choice to not 
using
The gamma correction when you don't want to use it.

Should I remove this configuration?

Best Regards,
Meng

[PATCH v2 1/2] libdrm: add etnaviv drm support

[Rob Herring]

On Tue, Sep 6, 2016 at 11:18 AM, Christian Gmeiner
 wrote:
> From: The etnaviv authors 
>
> Add the libdrm_etnaviv helper library to encapsulate etnaviv-specific 
> interfaces to the DRM.
>
> Signed-off-by: Christian Gmeiner 
> Signed-off-by: Lucas Stach 

Android is not completely working, but it builds and at least gets
thru the early stages, so:

Tested-by: Rob Herring 

[Bug 156651] The 4.7 kernel will not boot with a GTX 970

[bugzilla-dae...@bugzilla.kernel.org]

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

Pierre Moreau  changed:

   What|Removed |Added

 CC||pierre.morrow at free.fr

--- Comment #1 from Pierre Moreau  ---
Could you please provide the output of dmesg?
I would guess that you are experiencing the same issue as
https://bugs.freedesktop.org/show_bug.cgi?id=94990 (even if 4.6 worked for you,
which is interesting…).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 156651] New: The 4.7 kernel will not boot with a GTX 970

[bugzilla-dae...@bugzilla.kernel.org]

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

Bug ID: 156651
   Summary: The 4.7 kernel will not boot with a GTX 970
   Product: Drivers
   Version: 2.5
Kernel Version: 4.7
  Hardware: Intel
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: tjjrx7 at gmail.com
Regression: No

First off, I am fairly sure I am not filing this bug correctly, so I apologize
in advance. 

The issue I have is that any time I try to boot using the 4.7 kernel, I
completely loose all video output. 

Kernels 4.6, 4.5, and 4.4 all boot perfectly fine. But 4.7 just gives me a
black screen. 

I have also tried several distros to include opensuse tumbleweed, fedora, and
arch. All distros give me the exact same result. 

I can successfully boot kernel 4.7 if I use the nomodeset parameter. 

I personally do not own another video card to test if other video cards work,
but I do have a friend who owns a GTX 760 that seems to work just fine. So I am
thinking that this may be either a problem with the GTX 900 series cards or
perhaps the 970 in particular. 

And in case it matters, I am using display port out to a 1440p screen.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 115011] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller

[bugzilla-dae...@bugzilla.kernel.org]

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

Luya Tshimbalanga  changed:

   What|Removed |Added

 Resolution|PATCH_ALREADY_AVAILABLE |CODE_FIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 115011] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #15 from Luya Tshimbalanga  ---
(In reply to Alex Deucher from comment #14)
> You aren't seeing the message because it was removed in newer kernels.

Thank you for the clarification. Should I set the status as code fix then?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 115011] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #14 from Alex Deucher  ---
You aren't seeing the message because it was removed in newer kernels.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 115011] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller

[bugzilla-dae...@bugzilla.kernel.org]

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

Luya Tshimbalanga  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

--- Comment #13 from Luya Tshimbalanga  ---
Hello, 
I am closing this bug report now it was revealed the bug was triggered by the
new ACPI EC scheme from the BIOS first used by Microsoft Windows 8.1 and up.
Tested with patch on Kernel 4.8 rc4  properly handle the backlight controller.
I no longer see the error message:

$ journalctl -b | grep backlight
Sep 12 09:42:22 muamba-telus1603 kernel: [drm] radeon atom DIG backlight
initialized
Sep 12 16:42:59 muamba-telus1603 kernel: audit: type=1130
audit(1473723759.682:64): pid=1 uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:init_t:s0
msg='unit=systemd-backlight at backlight:radeon_bl0 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 12 16:42:39 muamba-telus1603 audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-backlight at backlight:radeon_bl0 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 12 16:42:39 muamba-telus1603 systemd[1]: Created slice
system-systemd\x2dbacklight.slice.
Sep 12 16:42:39 muamba-telus1603 systemd[1]: Starting Load/Save Screen
Backlight Brightness of backlight:radeon_bl0...
Sep 12 16:42:39 muamba-telus1603 systemd[1]: Started Load/Save Screen Backlight
Brightness of backlight:radeon_bl0.

Thank you for the investigation and the effort.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/vc4: cleanup with list_first_entry_or_null()

[Masahiro Yamada]

The combo of list_empty() check and return list_first_entry()
can be replaced with list_first_entry_or_null().

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/vc4/vc4_drv.h | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 428e249..61c1902 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -307,18 +307,15 @@ struct vc4_exec_info {
 static inline struct vc4_exec_info *
 vc4_first_bin_job(struct vc4_dev *vc4)
 {
-   if (list_empty(>bin_job_list))
-   return NULL;
-   return list_first_entry(>bin_job_list, struct vc4_exec_info, head);
+   return list_first_entry_or_null(>bin_job_list,
+   struct vc4_exec_info, head);
 }

 static inline struct vc4_exec_info *
 vc4_first_render_job(struct vc4_dev *vc4)
 {
-   if (list_empty(>render_job_list))
-   return NULL;
-   return list_first_entry(>render_job_list,
-   struct vc4_exec_info, head);
+   return list_first_entry_or_null(>render_job_list,
+   struct vc4_exec_info, head);
 }

 static inline struct vc4_exec_info *
-- 
1.9.1

[PATCH] drm/fsl-dcu: Add gamma set for crtc

[Meng Yi]

> Subject: Re: [PATCH] drm/fsl-dcu: Add gamma set for crtc
> 
> On Mon, Sep 05, 2016 at 12:24:32AM -0700, Stefan Agner wrote:
> 
> > So, afaik, we deal with 3x 256 32-bit register which happen to be a
> > different endianness on one SoC implementing the DCU IP...
> 
> That does sound like a second regmap then.

Here is the patch V3 for this https://patchwork.kernel.org/patch/9318711/

Will send V4 according to the comments.

Best Regards,
Meng

[Bug 97782] radeonsi: don't preload constants at the beginning of shaders patch break X rebirth

[bugzilla-dae...@freedesktop.org]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #126472|text/x-log  |text/plain
  mime type||

--- Comment #1 from Rafael Castillo  ---
Created attachment 126472
  --> https://bugs.freedesktop.org/attachment.cgi?id=126472=edit
X Rebirth log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/69f3d7cd/attachment.html>

[Bug 97782] radeonsi: don't preload constants at the beginning of shaders patch break X rebirth

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 97782
   Summary: radeonsi: don't preload constants at the beginning of
shaders patch break X rebirth
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: jrch2k10 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Hi, all

After this patch landed X rebirth got broken, it renders a white background.

attaching steam output on shader compilation error

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/35f63235/attachment.html>

[Bug 97500] Cannot unbind GPU from AMDGPU

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Micael Bergeron  ---
I also have this behavior on Linux 4.7.2 
I tried either to unbind on /sys/bus/pci/drivers/amdgpu/unbind or remove the
device and trigger a rescan using /sys/bus/pci/devices/.../remove,
/sys/bus/pci/rescan.

I have kernel panics and/or system hangs either way.
It would be awesome to be able to yield the GPU to a VM then claim it back when
finished.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160913/aac11393/attachment.html>

[PATCH v3] drm/fsl-dcu: Implement gamma_lut atomic crtc properties

[Stefan Agner]

Hi Meng,

One more thing which I have my concern:

On 2016-09-07 02:22, Meng Yi wrote:
> Gamma correction is optional and can be used to adjust the color
> output values to match the gamut of a particular TFT LCD panel
> Errata:
> Gamma_R, Gamma_G and Gamma_B registers are little-endian registers
> while the rest of the address-space in 2D-ACE is big-endian.
> Workaround:
> Split the DCU regs into "regs", "palette", "gamma" and "cursor".
> Create a second regmap for gamma memory space using little endian.
> 
> Suggested-by: Stefan Agner 
> Signed-off-by: Meng Yi 
> ---
> Changes in V3:
> -created a second regmap for gamma
> -updated the DCU DT binding
> ---
>  .../devicetree/bindings/display/fsl,dcu.txt|  6 +++-
>  drivers/gpu/drm/fsl-dcu/Kconfig|  6 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 38 
> ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 30 -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  |  8 +
>  5 files changed, 86 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> index 63ec2a6..1b1321a 100644
> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> @@ -20,7 +20,11 @@ Optional properties:
>  Examples:
>  dcu: dcu at 2ce {
>   compatible = "fsl,ls1021a-dcu";
> - reg = <0x0 0x2ce 0x0 0x1>;
> + reg = <0x0 0x2ce 0x0 0x2000>,
> +   <0x0 0x2ce2000 0x0 0x2000>,
> +   <0x0 0x2ce4000 0x0 0xc00>,
> +   <0x0 0x2ce4c00 0x0 0x400>;
> + reg-names = "regs", "palette", "gamma", "cursor";
>   clocks = <_clk 0>, <_clk 0>;
>   clock-names = "dcu", "pix";
>   big-endian;
> diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig
> index 14a72c4..f9c76b1 100644
> --- a/drivers/gpu/drm/fsl-dcu/Kconfig
> +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
> @@ -11,3 +11,9 @@ config DRM_FSL_DCU
>   help
> Choose this option if you have an Freescale DCU chipset.
> If M is selected the module will be called fsl-dcu-drm.
> +
> +config DRM_FSL_DCU_GAMMA
> + bool "Gamma Correction Support for NXP/Freescale DCU"
> + depends on DRM_FSL_DCU
> + help
> +   Enable support for gamma correction.

What is the reason for making this a configuration option? Are there
implementation without support for the Gamma tables?

--
Stefan

> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> index 3371635..25ab0ff 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> @@ -22,6 +22,22 @@
>  #include "fsl_dcu_drm_drv.h"
>  #include "fsl_dcu_drm_plane.h"
>  
> +static void fsl_crtc_gamma_set(struct drm_crtc *crtc, struct
> drm_color_lut *lut,
> +   uint32_t size)
> +{
> + struct fsl_dcu_drm_device *fsl_dev = crtc->dev->dev_private;
> + unsigned int i;
> +
> + for (i = 0; i < size; i++) {
> + regmap_write(fsl_dev->regmap_gamma, FSL_GAMMA_R + 4 * i,
> +  lut[i].red);
> + regmap_write(fsl_dev->regmap_gamma, FSL_GAMMA_G + 4 * i,
> +  lut[i].green);
> + regmap_write(fsl_dev->regmap_gamma, FSL_GAMMA_B + 4 * i,
> +  lut[i].blue);
> + }
> +}
> +
>  static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> struct drm_crtc_state *old_crtc_state)
>  {
> @@ -37,6 +53,11 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct
> drm_crtc *crtc,
>   drm_crtc_send_vblank_event(crtc, event);
>   spin_unlock_irq(>dev->event_lock);
>   }
> +
> + if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut)
> + fsl_crtc_gamma_set(crtc, (struct drm_color_lut *)
> +crtc->state->gamma_lut->data,
> +256);
>  }
>  
>  static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc)
> @@ -46,6 +67,10 @@ static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc)
>  
>   drm_crtc_vblank_off(crtc);
>  
> + if (fsl_dev->enable_color_mgmt)
> + regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
> +DCU_MODE_EN_GAMMA_MASK, 0);
> +
>   regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
>  DCU_MODE_DCU_MODE_MASK,
>  DCU_MODE_DCU_MODE(DCU_MODE_OFF));
> @@ -58,6 +83,11 @@ static void fsl_dcu_drm_crtc_enable(struct drm_crtc *crtc)
>   struct drm_device *dev = crtc->dev;
>   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
>  
> + if (fsl_dev->enable_color_mgmt)
> + regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
> +

[PATCH 0/2 v3] Audio support for adv7511 hdmi bridge

[Mark Brown]

On Mon, Sep 12, 2016 at 02:58:44PM -0700, John Stultz wrote:

> Ping? Just wanted to see if there was any other feedback on this?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings just adds to the mail volume (if they are
seen at all) and if something has gone wrong you'll have to resend the
patches anyway.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: