[v5 PATCH 0/5] Rockchip Type-C and DisplayPort driver

[Chris Zhong]

Hi all

This series patch is for rockchip Type-C phy and DisplayPort controller
driver.

The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data rates. The Type-C cable orientation detection and Power Delivery
(PD) is accomplished using a PD PHY or a exernal PD chip.

The DP controller is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work, please
put the firmware file[0] to /lib/firmware/cdn/dptx.bin. The uCPU in charge
of aux communication and link training, the host use mailbox to
communicate with the ucpu.

The DP contoller has register a notification with extcon API, to get the
alt mode from PD, the PD driver need call the devm_extcon_dev_allocate
to create a extcon device and use extcon_set_state to notify DP
controller. And call extcon_set_cable_property to set orientation.

About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF.
We can reference them in simple-card.

This series is based on Mark Yao's branch[1] and Chanwoo Choi's
extcon-test branch[2]

I test this patches on the rk3399-evb board, with a fusb302 driver,
this branch has no rk3399.dtsi, so the patch about dts is not included
in this series.

[0]
https://patchwork.kernel.org/patch/9225567/
[1]
https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23
[2]
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-test
- usb: dwc3: omap: Support the changed method to get the state of connector
- usb: chipdata: Support the changed method to get the state of connector
- extcon: Add the support for extcon property according to type of connector
- extcon: Add the extcon_type to group each connector into five category


Changes in v5:
- support get property
- support get property from extcon
- remove PIN ASSIGN A/B support
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.

Changes in v4:
- add a #phy-cells node
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_
- add a reset node
- support 2 phys
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use compatible: rockchip,rk3399-typec-phy
- use dashes instead of underscores.
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port
- add SoC specific compatible string
- remove reg = <1>;
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- add some registers description
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- add extcon node description
- move the registers in phy driver
- remove the suffix of reset
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")
- add extcon node description
- add #sound-dai-cells description
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

Chris Zhong (5):
  extcon: Add Type-C and DP support
  Documentation: bindings: add dt doc for Rockchip USB Type-C PHY
  phy: Add USB Type-C PHY driver for rk3399
  Documentation: bindings: add dt documentation for cdn DP controller
  drm/rockchip: cdn-dp: add cdn DP support for rk3399

 .../bindings/display/rockchip/cdn-dp-rockchip.txt  |  67 ++
 .../devicetree/bindings/phy/phy-rockchip-typec.txt |  77 ++
 drivers/extcon/extcon.c

[v5 PATCH 4/5] Documentation: bindings: add dt documentation for cdn DP controller

[Chris Zhong]

This patch adds a binding that describes the cdn DP controller for
rk3399.

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 

---

Changes in v5: None
Changes in v4:
- add a reset node
- support 2 phys

Changes in v3:
- add SoC specific compatible string
- remove reg = <1>;

Changes in v2: None
Changes in v1:
- add extcon node description
- add #sound-dai-cells description

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

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
new file mode 100644
index 000..bf0b2ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
@@ -0,0 +1,67 @@
+Rockchip RK3399 specific extensions to the cdn Display Port
+
+
+Required properties:
+- compatible: must be "rockchip,rk3399-cdn-dp"
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+
+- clock-names: from common clock binding:
+  Required elements: "core-clk" "pclk" "spdif"
+
+- resets : a list of phandle + reset specifier pairs
+- reset-names : string reset name, must be:
+   "spdif"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port nodes with endpoint definitions as defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+contained 2 endpoints, connecting to the output of vop.
+
+- phys: from general PHY binding: the phandle for the PHY device.
+
+- extcon: extcon specifier for the Power Delivery
+
+- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF
+
+---
+
+Example:
+   cdn_dp: dp at fec0 {
+   compatible = "rockchip,rk3399-cdn-dp";
+   reg = <0x0 0xfec0 0x0 0x10>;
+   interrupts = ;
+   clocks = < SCLK_DP_CORE>, < PCLK_DP_CTRL>,
+< SCLK_SPDIF_REC_DPTX>;
+   clock-names = "core-clk", "pclk", "spdif";
+   phys = <>, <>;
+   resets = < SRST_DPTX_SPDIF_REC>;
+   reset-names = "spdif";
+   extcon = <>, <>;
+   rockchip,grf = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #sound-dai-cells = <1>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dp_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dp_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_dp>;
+   };
+
+   dp_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_dp>;
+   };
+   };
+   };
+   };
-- 
2.6.3

[v5 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/cdn/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 

---

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 761 
 drivers/gpu/drm/rockchip/cdn-dp-core.h  | 113 +
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 740 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 409 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
 9 files changed, 2042 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20da9a8 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.

+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn Dp driver. If you want to enable Dp on
+ RK3399 based SoC, you should selet this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..abdecd5 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o

 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..5b8a15e
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,761 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_dp(c) \
+   container_of(c, struct cdn_dp_device, connector)
+
+#define encoder_to_dp(c) \
+   container_of(c, struct cdn_dp_device, encoder)
+
+/* dp grf register offset */
+#define DP_VOP_SEL 0x6224

[PATCH v3 2/4] drm/rockchip: add an common abstracted PSR driver

[Tomasz Figa]

On Tue, Jul 12, 2016 at 9:38 PM, Daniel Vetter  wrote:
> On Fri, Jul 01, 2016 at 02:00:00PM -0400, Sean Paul wrote:
>> On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang  wrote:
>> > The PSR driver have exported four symbols for specific device driver:
>> > - rockchip_drm_psr_register()
>> > - rockchip_drm_psr_unregister()
>> > - rockchip_drm_psr_enable()
>> > - rockchip_drm_psr_disable()
>> > - rockchip_drm_psr_flush()
>> >
>> > Encoder driver should call the register/unregister interfaces to hook
>> > itself into common PSR driver, encoder have implement the 'psr_set'
>> > callback which use the set PSR state in hardware side.
>> >
>> > Crtc driver would call the enable/disable interfaces when vblank is
>> > enable/disable, after that the common PSR driver would call the encoder
>> > registered callback to set the PSR state.
>> >
>>
>> This feels overly complicated. It seems like you could cut out a bunch
>> of code by just coding the psr functions into vop and
>> analogix_dp-rockchip. I suppose the only reason to keep it abstracted
>> would be if you plan on supporting psr in a different encoder or crtc
>> in rockchip, or if you're planning on moving this into drm core.
>
> Agreed on the layers of indirection. Also, you end up with 3 delayed
> timers in total:
> - defio timer from fbdev emulation
> - timer in this abstraction
> - delayed work in the psr backend driver

Maybe I'm missing something obvious (don't know how the PSR is
implemented in hardware or in other drivers), but why do we need all
these timers? Couldn't we just trigger a fake page flip on fb dirty
call?

Best regards,
Tomasz

Kernel stability on baytrail machines

[Pavel Machek]

On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote:
> Hi Alan,
> 
> (Adding interested people to this thread)
> 
> On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
> > > > I do feel that the importance of the mentioned bug is currently
> > > > underestimated. Can anyone here give a note, how much current linux
> > > > kernel is supposed to be stable on general baytrail machines?  
> > > 
> > > If you did not get any replies... you might want to check MAINTAINERS 
> > > file, and
> > > put Intel x86 maintainers on Cc list.
> > > 
> > > I'm sure someone cares :-).
> > 
> > Yes we care, and there are people looking at the various reports.
> > 
> 
> Are there any updates on the status of this issue?
> 
> The current bugzilla report [1] marks this as a power management
> issue. However, many reports indicate that it would only freeze
> when running X, so it's not completely clear if it's related to
> the gfx driver too.

Does

"intel_idle.max_cstate=1"

fix it for you?

If you feel it is X-only problem, you may want to provide details
about your graphics subsystem (DRM enabled? framebuffer only?) and
probably cc.

...actually... you may want to verify if it happens in unaccelerated X.

INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative
chipsets)
M:  Daniel Vetter 
M:  Jani Nikula 
L:  intel-gfx at lists.freedesktop.org
L:  dri-devel at lists.freedesktop.org
W:  https://01.org/linuxgraphics/
Q:  http://patchwork.freedesktop.org/project/intel-gfx/
T:  git git://anongit.freedesktop.org/drm-intel
S:  Supported
F:  drivers/gpu/drm/i915/
F:  include/drm/i915*
F:  include/uapi/drm/i915_drm.h

Best regards,
Pavel

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

[PATCH v3 3/4] drm/bridge: analogix_dp: add the PSR function support

[Yakir Yang]

D


>>>> +
>>>> +   writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
>>>> +}
>>>> +
>>>> +void analogix_dp_send_psr_spd(struct analogix_dp_device *dp, int db1)
>>>> +{
>>>> +   unsigned int val;
>>>> +
>>>> +   /* don't send info frame */
>>>> +   val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>>>> +   val &= ~IF_EN;
>>>> +   writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>>>> +
>>>> +   /* configure single frame update mode */
>>>> +   writel(0x3, dp->reg_base + ANALOGIX_DP_PSR_FRAME_UPDATE_CTRL);
>>>> +
>>>> +   /* configure VSC HB0 ~ HB3 */
>>>> +   writel(0x00, dp->reg_base + ANALOGIX_DP_SPD_HB0);
>>>> +   writel(0x07, dp->reg_base + ANALOGIX_DP_SPD_HB1);
>>>> +   writel(0x02, dp->reg_base + ANALOGIX_DP_SPD_HB2);
>>>> +   writel(0x08, dp->reg_base + ANALOGIX_DP_SPD_HB3);
>>>> +
>>>> +   /* configure VSC HB0 ~ HB3 */
>>>> +   writel(0x00, dp->reg_base + ANALOGIX_DP_SPD_PB0);
>>>> +   writel(0x16, dp->reg_base + ANALOGIX_DP_SPD_PB1);
>>>> +   writel(0xCE, dp->reg_base + ANALOGIX_DP_SPD_PB2);
>>>> +   writel(0x5D, dp->reg_base + ANALOGIX_DP_SPD_PB3);
>>>> +
>>>> +   /* configure DB0 / DB1 values */
>>>> +   writel(0x00, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
>>> Lots of hardcoded values here. I think this could be cleaned up.
>>
>> For "HB0~HB3", "PB0~PB3" and "DB1", I don't understand very well. Those
>> seems to be a kind of head number, I got those magic values from our IC
>> side. So I think those should be okay to keep the hardcode values here :-D
>>
> Hmm. Well, I'd probably pull them out into some HBX_MAGIC_VALUE
> define, but I suppose it's fine to keep them as-is. Please at least
> add a comment above explaining that they're magic values provided by
> your IC team.

Done ;)

Thanks,
- Yakir

>> But for the "0x3" in "ANALOGIX_DP_PSR_FRAME_UPDATE_CTRL", I would fix it
>> with suitable macro.
>>
>>
>>>> +   writel(db1, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
>>>> +
>>>> +   /* set reuse spd inforframe */
>>>> +   val = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
>>>> +   val |= REUSE_SPD_EN;
>>>> +   writel(val, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
>>>> +
>>>> +   /* mark info frame update */
>>>> +   val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>>>> +   val = (val | IF_UP) & ~IF_EN;
>>>> +   writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>>>> +
>>>> +   /* send info frame */
>>>> +   val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>>>> +   val |= IF_EN;
>>>> +   writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>>>> +}
>>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
>>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
>>>> index cdcc6c5..a2698e4 100644
>>>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
>>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
>>>> @@ -22,6 +22,8 @@
>>>>#define ANALOGIX_DP_VIDEO_CTL_80x3C
>>>>#define ANALOGIX_DP_VIDEO_CTL_10   0x44
>>>>
>>>> +#define ANALOGIX_DP_SPDIF_AUDIO_CTL_0  0xD8
>>>> +
>>>>#define ANALOGIX_DP_PLL_REG_1  0xfc
>>>>#define ANALOGIX_DP_PLL_REG_2  0x9e4
>>>>#define ANALOGIX_DP_PLL_REG_3  0x9e8
>>>> @@ -30,6 +32,21 @@
>>>>
>>>>#define ANALOGIX_DP_PD 0x12c
>>>>
>>>> +#define ANALOGIX_DP_IF_TYPE0x244
>>>> +#define ANALOGIX_DP_IF_PKT_DB1 0x254
>>>> +#define ANALOGIX_DP_IF_PKT_DB2 0x258
>>>> +#define ANALOGIX_DP_SPD_HB00x2F8
>>>> +#define ANALOGIX_DP_SPD_HB10x2FC
>>>> +#define ANALOGIX_DP_SPD_HB20x300
>>>> +#define ANALOGIX_DP_SPD_HB30x304
>>>> +#define ANALOGIX_DP_SPD_PB00x308
>>>> +#define ANALOGIX_DP_SPD_PB10x30C
>>>> +#define ANALOGIX_DP_SPD_PB20x310
>>>> +#define ANALOGIX_DP_SPD_PB30x314
>>>> +#define ANALOGIX_DP_PSR_FRAME_UPDATE_CTRL  0x318
>>>> +#define ANALOGIX_DP_VSC_SHADOW_DB0 0x31C
>>>> +#define ANALOGIX_DP_VSC_SHADOW_DB1 0x320
>>>> +
>>>>#define ANALOGIX_DP_LANE_MAP   0x35C
>>>>
>>>>#define ANALOGIX_DP_ANALOG_CTL_1   0x370
>>>> @@ -103,6 +120,8 @@
>>>>
>>>>#define ANALOGIX_DP_SOC_GENERAL_CTL0x800
>>>>
>>>> +#define ANALOGIX_DP_CRC_CON0x890
>>>> +
>>>>/* ANALOGIX_DP_TX_SW_RESET */
>>>>#define RESET_DP_TX(0x1 << 0)
>>>>
>>>> @@ -151,6 +170,7 @@
>>>>#define VID_CHK_UPDATE_TYPE_SHIFT  (4)
>>>>#define VID_CHK_UPDATE_TYPE_1  (0x1 << 4)
>>>>#define VID_CHK_UPDATE_TYPE_0  (0x0 << 4)
>>>> +#define REUSE_SPD_EN   (0x1 << 3)
>>>>
>>>>/* ANALOGIX_DP_VIDEO_CTL_8 */
>>>>#define VID_HRES_TH(x) (((x) & 0xf) << 4)
>>>> @@ -376,4 +396,12 @@
>>>>#define VIDEO_MODE_SLAVE_MODE  (0x1 << 0)
>>>>#define VIDEO_MODE_MASTER_MODE (0x0 << 0)
>>>>
>>>> +/* ANALOGIX_DP_PKT_SEND_CTL */
>>>> +#define IF_UP  (0x1 << 4)
>>>> +#define IF_EN  (0x1 << 0)
>>>> +
>>>> +/* ANALOGIX_DP_CRC_CON */
>>>> +#define PSR_VID_CRC_FLUSH  (0x1 << 2)
>>>> +#define PSR_VID_CRC_ENABLE (0x1 << 0)
>>>> +
>>>>#endif /* _ANALOGIX_DP_REG_H */
>>>> diff --git a/include/drm/bridge/analogix_dp.h
>>>> b/include/drm/bridge/analogix_dp.h
>>>> index 261b86d..183a336 100644
>>>> --- a/include/drm/bridge/analogix_dp.h
>>>> +++ b/include/drm/bridge/analogix_dp.h
>>>> @@ -38,6 +38,9 @@ struct analogix_dp_plat_data {
>>>>struct drm_connector *);
>>>>};
>>>>
>>>> +int analogix_dp_active_psr(struct device *dev);
>>>> +int analogix_dp_inactive_psr(struct device *dev);
>>> Why active/inactive instead of enable/disable, which is used everywhere
>>> else?
>>
>> Done
>>
>> Thanks,
>> - Yakir
>>
>>
>>>> +
>>>>int analogix_dp_resume(struct device *dev);
>>>>int analogix_dp_suspend(struct device *dev);
>>>>
>>>> --
>>>> 1.9.1
>>>>
>>>>
>>>
>>
>
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/e045f779/attachment-0001.html>

linux-next: manual merge of the drm-misc tree with the arm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/rockchip/rockchip_drm_drv.c

between commit:

  062993b15e8e ("drm: convert DT component matching to 
component_match_add_release()")

from the arm tree and commit:

  6d5fa28c13b9 ("gpu: drm: rockchip_drm_drv: add missing of_node_put after 
calling of_parse_phandle")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 7fd20c0e1fc8,f0bd1ee8b128..
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@@ -438,9 -433,8 +438,10 @@@ static int rockchip_drm_platform_probe(
is_support_iommu = false;
}

+   of_node_put(iommu);
 -  component_match_add(dev, , compare_of, port->parent);
 +  of_node_get(port->parent);
 +  component_match_add_release(dev, , release_of,
 +  compare_of, port->parent);
of_node_put(port);
}

[PATCH v3 2/4] drm/rockchip: add an common abstracted PSR driver

[Yakir Yang]

Daniel,

On 07/12/2016 08:38 PM, Daniel Vetter wrote:
> On Fri, Jul 01, 2016 at 02:00:00PM -0400, Sean Paul wrote:
>> On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang  wrote:
>>> The PSR driver have exported four symbols for specific device driver:
>>> - rockchip_drm_psr_register()
>>> - rockchip_drm_psr_unregister()
>>> - rockchip_drm_psr_enable()
>>> - rockchip_drm_psr_disable()
>>> - rockchip_drm_psr_flush()
>>>
>>> Encoder driver should call the register/unregister interfaces to hook
>>> itself into common PSR driver, encoder have implement the 'psr_set'
>>> callback which use the set PSR state in hardware side.
>>>
>>> Crtc driver would call the enable/disable interfaces when vblank is
>>> enable/disable, after that the common PSR driver would call the encoder
>>> registered callback to set the PSR state.
>>>
>> This feels overly complicated. It seems like you could cut out a bunch
>> of code by just coding the psr functions into vop and
>> analogix_dp-rockchip. I suppose the only reason to keep it abstracted
>> would be if you plan on supporting psr in a different encoder or crtc
>> in rockchip, or if you're planning on moving this into drm core.
> Agreed on the layers of indirection. Also, you end up with 3 delayed
> timers in total:
> - defio timer from fbdev emulation
> - timer in this abstraction
> - delayed work in the psr backend driver
>
> I'd cut out at least the middle one.
>
> But since this seems to correctly use the ->dirty callback it gets my Ack
> either way ;-)

Aha, thanks :-D

- Yakir

> Cheers, Daniel
>
>> Perhaps others will disagree with this sentiment and this is the right
>> thing to do.
>>
>>> Fb driver would call the flush interface in 'fb->dirty' callback, this
>>> helper function would force all PSR enabled encoders to exit from PSR
>>> for 3 seconds.
>>>
>>> Signed-off-by: Yakir Yang 
>>> ---
>>> Changes in v3:
>>> - split the psr flow into an common abstracted PSR driver
>>> - implement the 'fb->dirty' callback function (Daniel)
>>> - avoid to use notify to acqiure for vact event (Daniel)
>>> - remove psr_active() callback which introduce in v2
>>>
>>> Changes in v2: None
>>>
>>>   drivers/gpu/drm/rockchip/Makefile   |   2 +-
>>>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  12 ++
>>>   drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 200 
>>> 
>>>   drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  12 ++
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  24 
>>>   5 files changed, 249 insertions(+), 1 deletion(-)
>>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/Makefile 
>>> b/drivers/gpu/drm/rockchip/Makefile
>>> index 05d0713..9746365 100644
>>> --- a/drivers/gpu/drm/rockchip/Makefile
>>> +++ b/drivers/gpu/drm/rockchip/Makefile
>>> @@ -3,7 +3,7 @@
>>>   # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>>>
>>>   rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>>> -   rockchip_drm_gem.o rockchip_drm_vop.o
>>> +   rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
>>>   rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>>>
>>>   obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
>>> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>>> index 20f12bc..0fec18f 100644
>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>>> @@ -21,6 +21,7 @@
>>>
>>>   #include "rockchip_drm_drv.h"
>>>   #include "rockchip_drm_gem.h"
>>> +#include "rockchip_drm_psr.h"
>>>
>>>   #define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
>>>
>>> @@ -66,9 +67,20 @@ static int rockchip_drm_fb_create_handle(struct 
>>> drm_framebuffer *fb,
>>>   rockchip_fb->obj[0], handle);
>>>   }
>>>
>>> +static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
>>> +struct drm_file *file,
>>> +unsigned int flags, unsigned int color,
>>> +struct drm_clip_rect *clips,
>>> +unsigned int num_clips)
>>> +{
>>> +   rockchip_drm_psr_flush();
>>> +   return 0;
>>> +}
>>> +
>>>   static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
>>>  .destroy= rockchip_drm_fb_destroy,
>>>  .create_handle  = rockchip_drm_fb_create_handle,
>>> +   .dirty  = rockchip_drm_fb_dirty,
>>>   };
>>>
>>>   static struct rockchip_drm_fb *
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
>>> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>>> new file mode 100644
>>> index 000..c03
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>>> @@ -0,0 +1,200 @@
>>> +#include 
>>> +
>>> +#include "rockchip_drm_psr.h"
>>> +
>>> 

[Bug 96897] [opencl] clpeak hangs during compilation

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

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #125023|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/20160713/ebbd98bb/attachment.html>

[Bug 96897] [opencl] clpeak hangs during compilation

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

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

Michel Dänzer  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
 QA Contact|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Mesa core

--- Comment #2 from Michel Dänzer  ---
Looks like deep recursion in clover / LLVM code.

-- 
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/20160713/5a6c38b7/attachment-0001.html>

[PATCH v2 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver

[Archit Taneja]

Hi,

On 07/12/2016 10:51 PM, Philipp Zabel wrote:
> From: Andrey Gusakov 
>
> Add a drm_bridge driver for the Toshiba TC358767 DPI/DSI to
> eDP/DP bridge. Currently only DPI input with 24-bit RGB is
> supported.
>
> Signed-off-by: Andrey Gusakov 
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v1:
>   - Replaced the regmap_read_poll_timeout macro with a function.
>   - Rebased on top of SiI902x driver merge to avoid Makefile/Kconfig 
> conflicts.
>   - Fixed tc_pxl_pll_en as requested: removed unnecessary checks, whitespace
> and comment improvements.
>   - Switched to atomic connector funcs.
>   - Moved the output port to port at 2.
> ---
>   drivers/gpu/drm/bridge/Kconfig|8 +
>   drivers/gpu/drm/bridge/Makefile   |1 +
>   drivers/gpu/drm/bridge/tc358767.c | 1421 
> +
>   3 files changed, 1430 insertions(+)
>   create mode 100644 drivers/gpu/drm/bridge/tc358767.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index a1419214..ebcad29 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -58,6 +58,14 @@ config DRM_SII902X
>   ---help---
> Silicon Image sii902x bridge chip driver.
>
> +config DRM_TOSHIBA_TC358767
> + tristate "Toshiba TC358767 eDP bridge"

Can we add a 'depends on OF ' here, or wrap around the
'tc->bridge.of_node' access with a CONFIG_OF check? It currently
breaks build for non-OF platforms.

> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + select DRM_PANEL
> + ---help---
> +   Toshiba TC358767 eDP bridge chip driver.
> +
>   source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
>   endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index bfec9f8..42b853a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -6,4 +6,5 @@ obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>   obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>   obj-$(CONFIG_DRM_SII902X) += sii902x.o
> +obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>   obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> new file mode 100644
> index 000..f1e3a4b
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -0,0 +1,1421 @@
> +/*
> + * tc358767 eDP bridge driver
> + *
> + * Copyright (C) 2016 CogentEmbedded Inc
> + * Author: Andrey Gusakov 
> + *
> + * Copyright (C) 2016 Pengutronix, Philipp Zabel 
> + *
> + * Initially based on: drivers/gpu/drm/i2c/tda998x_drv.c
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Registers */
> +
> +/* Display Parallel Interface */
> +#define DPIPXLFMT0x0440
> +#define VS_POL_ACTIVE_LOW(1 << 10)
> +#define HS_POL_ACTIVE_LOW(1 << 9)
> +#define DE_POL_ACTIVE_HIGH   (0 << 8)
> +#define SUB_CFG_TYPE_CONFIG1 (0 << 2) /* LSB aligned */
> +#define SUB_CFG_TYPE_CONFIG2 (1 << 2) /* Loosely Packed */
> +#define SUB_CFG_TYPE_CONFIG3 (2 << 2) /* LSB aligned 8-bit */
> +#define DPI_BPP_RGB888   (0 << 0)
> +#define DPI_BPP_RGB666   (1 << 0)
> +#define DPI_BPP_RGB565   (2 << 0)
> +
> +/* Video Path */
> +#define VPCTRL0  0x0450
> +#define OPXLFMT_RGB666   (0 << 8)
> +#define OPXLFMT_RGB888   (1 << 8)
> +#define FRMSYNC_DISABLED (0 << 4) /* Video Timing Gen Disabled */
> +#define FRMSYNC_ENABLED  (1 << 4) /* Video Timing Gen 
> Enabled */
> +#define MSF_DISABLED (0 << 0) /* Magic Square FRC disabled */
> +#define MSF_ENABLED  (1 << 0) /* Magic Square FRC enabled */
> +#define HTIM01   0x0454
> +#define HTIM02   0x0458
> +#define VTIM01   0x045c
> +#define VTIM02   0x0460
> +#define VFUEN0   0x0464
> +#define VFUENBIT(0)   /* Video Frame Timing 
> Upload */
> +
> +/* System */
> +#define TC_IDREG 

[Bug 86669] SSH Account request

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

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

Daniel Stone  changed:

   What|Removed |Added

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

--- Comment #3 from Daniel Stone  ---
wfm, added now

-- 
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/20160713/b5fd1f7c/attachment.html>

[PATCH v2 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver

[Philipp Zabel]

Hi Archit,

Am Mittwoch, den 13.07.2016, 11:25 +0530 schrieb Archit Taneja:
[...]
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index a1419214..ebcad29 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -58,6 +58,14 @@ config DRM_SII902X
> > ---help---
> >   Silicon Image sii902x bridge chip driver.
> >
> > +config DRM_TOSHIBA_TC358767
> > +   tristate "Toshiba TC358767 eDP bridge"
> 
> Can we add a 'depends on OF ' here, or wrap around the
> 'tc->bridge.of_node' access with a CONFIG_OF check? It currently
> breaks build for non-OF platforms.

Done.

[...]
> > +   int test_pattern;
> 
> This still doesn't seem to be initialized. Didn't we want this
> to be a module param? If we're not sure yet, it would be fine
> just to set tc->test_pattern explicitly to 0 and add a comment.

And done, sorry I forgot this. Now that I have added the module
parameter, I have and actually tested the test pattern code and
noticed that I also have to set the pixel clock rate. I'll send
a new version shortly.

regards
Philipp

[PATCH v3 0/2] Toshiba TC358767 eDP bridge driver

[Philipp Zabel]

Hi,

this patchset adds DT binding docs and a drm_bridge driver for the
Toshiba TC358767 eDP bridge, currently supporting only 24-bit DPI input
and control via I2C. The chip is also capable to act as a DSI sink, but
the driver doesn't support that yet.
It is based on Andrey's initial driver, which can be found at
https://github.com/CogentEmbedded/linux-zodiac.git, commit 4abb1d0a9a1c
("drm/i2c: tc358767 eDP encoder initial commit"). I have turned it into
a drm_bridge driver and changed it to use regmap and the drm_dp helpers.

Changes since v2:
 - Let DRM_TOSHIBA_TC358767 depend on OF
 - Add a module parameter "test" to enable the color bar test pattern
 - Provide mode clock to tc_pxl_pll_en
 - Remove now otherwise unused struct tc_data members "pll_clk",
   "pll_clk_real" and "test_pattern".

regards
Philipp

Andrey Gusakov (1):
  drm/bridge: tc358767: Add DPI to eDP bridge driver

Philipp Zabel (1):
  dt-bindings: tc358767: add DT documentation

 .../bindings/display/bridge/toshiba,tc358767.txt   |   51 +
 drivers/gpu/drm/bridge/Kconfig |9 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/tc358767.c  | 1413 
 4 files changed, 1474 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
 create mode 100644 drivers/gpu/drm/bridge/tc358767.c

-- 
2.8.1

[PATCH v3 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver

[Philipp Zabel]

From: Andrey Gusakov 

Add a drm_bridge driver for the Toshiba TC358767 DPI/DSI to
eDP/DP bridge. Currently only DPI input with 24-bit RGB is
supported.

Signed-off-by: Andrey Gusakov 
Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Let DRM_TOSHIBA_TC358767 depend on OF
 - Add a module parameter "test" to enable the color bar test pattern
 - Provide mode clock to tc_pxl_pll_en
 - Remove now otherwise unused struct tc_data members "pll_clk",
   "pll_clk_real" and "test_pattern".
---
 drivers/gpu/drm/bridge/Kconfig|9 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/tc358767.c | 1413 +
 3 files changed, 1423 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/tc358767.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index a1419214..21612bf 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -58,6 +58,15 @@ config DRM_SII902X
---help---
  Silicon Image sii902x bridge chip driver.

+config DRM_TOSHIBA_TC358767
+   tristate "Toshiba TC358767 eDP bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   select DRM_PANEL
+   ---help---
+ Toshiba TC358767 eDP bridge chip driver.
+
 source "drivers/gpu/drm/bridge/analogix/Kconfig"

 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index bfec9f8..42b853a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
new file mode 100644
index 000..a09825d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -0,0 +1,1413 @@
+/*
+ * tc358767 eDP bridge driver
+ *
+ * Copyright (C) 2016 CogentEmbedded Inc
+ * Author: Andrey Gusakov 
+ *
+ * Copyright (C) 2016 Pengutronix, Philipp Zabel 
+ *
+ * Initially based on: drivers/gpu/drm/i2c/tda998x_drv.c
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Registers */
+
+/* Display Parallel Interface */
+#define DPIPXLFMT  0x0440
+#define VS_POL_ACTIVE_LOW  (1 << 10)
+#define HS_POL_ACTIVE_LOW  (1 << 9)
+#define DE_POL_ACTIVE_HIGH (0 << 8)
+#define SUB_CFG_TYPE_CONFIG1   (0 << 2) /* LSB aligned */
+#define SUB_CFG_TYPE_CONFIG2   (1 << 2) /* Loosely Packed */
+#define SUB_CFG_TYPE_CONFIG3   (2 << 2) /* LSB aligned 8-bit */
+#define DPI_BPP_RGB888 (0 << 0)
+#define DPI_BPP_RGB666 (1 << 0)
+#define DPI_BPP_RGB565 (2 << 0)
+
+/* Video Path */
+#define VPCTRL00x0450
+#define OPXLFMT_RGB666 (0 << 8)
+#define OPXLFMT_RGB888 (1 << 8)
+#define FRMSYNC_DISABLED   (0 << 4) /* Video Timing Gen Disabled */
+#define FRMSYNC_ENABLED(1 << 4) /* Video Timing Gen 
Enabled */
+#define MSF_DISABLED   (0 << 0) /* Magic Square FRC disabled */
+#define MSF_ENABLED(1 << 0) /* Magic Square FRC enabled */
+#define HTIM01 0x0454
+#define HTIM02 0x0458
+#define VTIM01 0x045c
+#define VTIM02 0x0460
+#define VFUEN0 0x0464
+#define VFUEN  BIT(0)   /* Video Frame Timing Upload */
+
+/* System */
+#define TC_IDREG   0x0500
+#define SYSCTRL0x0510
+#define DP0_AUDSRC_NO_INPUT(0 << 3)
+#define DP0_AUDSRC_I2S_RX  (1 << 3)
+#define DP0_VIDSRC_NO_INPUT(0 << 0)
+#define DP0_VIDSRC_DSI_RX  (1 << 0)
+#define DP0_VIDSRC_DPI_RX  (2 << 0)
+#define DP0_VIDSRC_COLOR_BAR   (3 << 0)
+
+/* Control */
+#define DP0CTL 0x0600
+#define VID_MN_GEN BIT(6)   /* Auto-generate M/N values */
+#define EF_EN

[PATCH v3 1/2] dt-bindings: tc358767: add DT documentation

[Philipp Zabel]

Add DT binding documentation for the Toshiba TC358767 eDP bridge.

Signed-off-by: Philipp Zabel 
---
 .../bindings/display/bridge/toshiba,tc358767.txt   | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
new file mode 100644
index 000..05ada28
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
@@ -0,0 +1,51 @@
+Toshiba TC358767 eDP bridge bindings
+
+Required properties:
+ - compatible: "toshiba,tc358767"
+ - reg: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins
+ - clock-names: should be "ref"
+ - clocks: OF device-tree clock specification for refclk input. The reference
+   clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz.
+
+Optional properties:
+ - shutdown-gpios: OF device-tree gpio specification for SD pin
+   (active high shutdown input)
+ - reset-gpios: OF device-tree gpio specification for RSTX pin
+(active low system reset)
+ - ports: the ports node can contain video interface port nodes to connect
+   to a DPI/DSI source and to an eDP/DP sink according to [1][2]:
+- port at 0: DSI input port
+- port at 1: DPI input port
+- port at 2: eDP/DP output port
+
+[1]: Documentation/devicetree/bindings/graph.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   edp-bridge at 68 {
+   compatible = "toshiba,tc358767";
+   reg = <0x68>;
+   shutdown-gpios = < 23 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 24 GPIO_ACTIVE_LOW>;
+   clock-names = "ref";
+   clocks = <_refclk>;
+
+   ports {
+   port at 1 {
+   reg = <1>;
+
+   bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port at 2 {
+   reg = <2>;
+
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
-- 
2.8.1

[PATCH v1 4/6] drm/rockchip: dw_hdmi: add RK3399 HDMI support

[Yakir Yang]

Philipp,

On 07/11/2016 07:51 PM, Philipp Zabel wrote:
> Am Montag, den 11.07.2016, 19:05 +0800 schrieb Yakir Yang:
>> RK3399 and RK3288 shared the same HDMI IP controller, only some light
>> difference with GRF configure.
>>
>> Signed-off-by: Yakir Yang 
> Reviewed-by: Philipp Zabel 

Thanks for your fast respond :-D
- Yakir

> regards
> Philipp
>
>
>
>

[PATCH] drm/amdkfd: print doorbell offset as a hex value

[Colin King]

From: Colin Ian King 

The doorbell offset is formatted with a 0x prefix to suggest it is
a hexadecimal value, when in fact %d is being used and this is confusing.
Use %X instead to match the proceeding 0x prefix.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
index e621eba..a7d3cb3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
@@ -184,7 +184,7 @@ u32 __iomem *kfd_get_kernel_doorbell(struct kfd_dev *kfd,
sizeof(u32)) + inx;

pr_debug("kfd: get kernel queue doorbell\n"
-" doorbell offset   == 0x%08d\n"
+" doorbell offset   == 0x%08X\n"
 " kernel address== 0x%08lX\n",
*doorbell_off, (uintptr_t)(kfd->doorbell_kernel_ptr + inx));

-- 
2.8.1

[PATCH v1 5/6] drm/rockchip: dw_hdmi: introduce the VPLL clock setting

[Yakir Yang]

Heiko,

On 07/12/2016 10:27 PM, Heiko Stübner wrote:
> Hi Yakir,
>
> Am Montag, 11. Juli 2016, 19:05:49 schrieb Yakir Yang:
>> For RK3399 HDMI, there is an external clock need for HDMI PHY,
>> and it should keep the same clock rate with VOP DCLK.
>>
>> VPLL have supported the clock for HDMI PHY, but there is no
>> clock divider bewteen VPLL and HDMI PHY. So we need to set the
>> VPLL rate manually in HDMI driver.
> I don't think reserving the vpll for the hdmi at all times is the right way to
> go.
>
> While I do agree that reserving the VPLL (and NPLL on the rk3288) for graphics
> use looks like the right way, I think the core Rockchip drm driver should be
> responsible for managing it and also for deciding which output encoder gets to
> use it.
> While true that on the Chromebook device-types the edp is static and hdmi
> needs the broad range of dynamic frequencies, this is not necessarily the case
> for all future device types and/or socs.
>
> In the other thread we discussed adding that as rockchip,dclk-pll = <&...>; to
> the base display-subsystem node, Doug didn't manage to find time to respond 
> yet
> though - and is on vacation right now.

Great idea. Let a separate drm-pll driver to maintain all connector's 
clock requirement.

> I still believe that would be the best solution :-) .
>
>
> That property could list 1 or even 2 plls, depending on the soc or board
> layout - maybe someone frees up the cpll in some special layout or something.
> If none are listed, then the drm driver would need to cope with its available
> clocks.
>
> Implementation-wise you could even still keep your shortcut until we encounter
> a device with different , let the drm use the pll for hdmi only until someone
> comes up with a better concept, but still the binding should be correct and
> versatile from the start.

Someone should start to prepare the drm core pll driver, it's great idea.

BR,
- Yakir

>
> Heiko
>
>> ---
>>   .../bindings/display/rockchip/dw_hdmi-rockchip.txt |  3 ++-
>>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 25
>> +- 2 files changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
>> b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
>> index 4e573d2..4e23ca4 100644
>> ---
>> a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
>> +++
>> b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
>> @@ -17,7 +17,8 @@ Required properties:
>>
>>   Optional properties
>>   - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
>> -- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
>> +- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec",
>> +   phandle to the VPLL clock, name should be "vpll".
>>
>>   Example:
>>   hdmi: hdmi at ff98 {
>> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c index 329099b..701bb73 100644
>> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> @@ -7,10 +7,12 @@
>>* (at your option) any later version.
>>*/
>>
>> +#include 
>> +#include 
>>   #include 
>>   #include 
>> -#include 
>>   #include 
>> +
>>   #include 
>>   #include 
>>   #include 
>> @@ -33,6 +35,7 @@ struct rockchip_hdmi {
>>  struct regmap *regmap;
>>  struct drm_encoder encoder;
>>  enum dw_hdmi_devtype dev_type;
>> +struct clk *vpll_clk;
>>   };
>>
>>   #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
>> @@ -145,6 +148,7 @@ static const struct dw_hdmi_phy_config
>> rockchip_phy_config[] = { static int rockchip_hdmi_parse_dt(struct
>> rockchip_hdmi *hdmi)
>>   {
>>  struct device_node *np = hdmi->dev->of_node;
>> +int ret;
>>
>>  hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
>>  if (IS_ERR(hdmi->regmap)) {
>> @@ -152,6 +156,22 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
>> *hdmi) return PTR_ERR(hdmi->regmap);
>>  }
>>
>> +hdmi->vpll_clk = devm_clk_get(hdmi->dev, "vpll");
>> +if (PTR_ERR(hdmi->vpll_clk) == -ENOENT) {
>> +hdmi->vpll_clk = NULL;
>> +} else if (PTR_ERR(hdmi->vpll_clk) == -EPROBE_DEFER) {
>> +return -EPROBE_DEFER;
>> +} else if (IS_ERR(hdmi->vpll_clk)) {
>> +dev_err(hdmi->dev, "failed to get grf clock\n");
>> +return PTR_ERR(hdmi->vpll_clk);
>> +}
>> +
>> +ret = clk_prepare_enable(hdmi->vpll_clk);
>> +if (ret) {
>> +dev_err(hdmi->dev, "Failed to enable HDMI vpll: %d\n", ret);
>> +return ret;
>> +}
>> +
>>  return 0;
>>   }
>>
>> @@ -194,6 +214,9 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct
>> drm_encoder *encoder, struct drm_display_mode *mode,
>>struct drm_display_mode 

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

[Rainer Hochecker]

Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is not
an option anymore because we need EGL for vaapi. But we can fall back to
the invisible window for getting vsync. I never tried using EGL and GLX in
the same application, different windows. Any reason why this should not
work?

Rainer

On Tue, Jul 12, 2016 at 12:29 PM, Daniel Vetter  wrote:

> On Fri, Jun 24, 2016 at 06:55:55AM +1000, Daniel Stone wrote:
> > Hi Rainer,
> >
> > On 24 June 2016 at 05:54, Rainer Hochecker  wrote:
> > > I spent some time reading and investigating on this. Bear with me, I am
> > > doing Kodi development in my spare time and may not be up-to-date on
> all
> > > platforms. Seems Wayland is much better suited to serve as reference
> > > platform as X11 does. Is that correct? If so I don't request
> > > OML_sync_control for EGL. Don't waste resources and let the old crap
> die.
> >
> > I certainly think so, for a number of reasons. I don't believe X11
> > will ever be as accurate or as efficient as Wayland can be.
>
> Seconded. I think GLX+OML_sync_control for X11 and Wayland with EGL and
> the frame timing Daniel Stone laid out (already should work in both cases)
> seems like the perfect solution.
>
> What kind of transition plan would be reasonable? Should we start with a
> printk_once to inform userspace developers that they should change their
> code, and then eventually (after a few years or so) remove that ioctl?
> Maybe first behind a module option?
>
> Who should all be on cc for such a change?
>
> I'd like to get this started, it'll take years no matter what ...
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/2b76e6ae/attachment-0001.html>

Error handling in drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c

[Christophe JAILLET]

Hi,

in file 'drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c', error 
handling in 'gm20b_tegra_read_wpr()' seams to be broken.

The code used is:

 mc = ioremap(TEGRA_MC_BASE, 0xd00);
 if (!mc) {
 nvkm_error(>subdev, "...");
 return PTR_ERR(mc);
 }

so we always return '0', which means success.


Best regards,

CJ
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/2026ff2d/attachment-0001.html>

[Bug 96444] GRID Autosport crash on loading race

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

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

--- Comment #17 from Adam Lyall  ---
It seems this issue may have been resolved. I got a new llvm version from the
padoka PPA (package version 1:3.9~svn274905-0~x~padoka0) and Grid Autosport is
once again working with my R9 270X.

-- 
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/20160713/81d47409/attachment.html>

[PATCH 2/2] [media] s5p-g2d: Replace old driver with DRM version

[Krzysztof Kozlowski]

On 07/13/2016 01:02 AM, Mauro Carvalho Chehab wrote:
> I suspect that you'll be applying this one via DRM tree, so:
> 
> Em Tue, 24 May 2016 15:28:13 +0200
> Krzysztof Kozlowski  escreveu:
> 
>> Remove the old non-DRM driver because it is now entirely supported by
>> exynos_drm_g2d driver.
>>
>> Cc: Kyungmin Park 
>> Cc: Kamil Debski 
>> Signed-off-by: Krzysztof Kozlowski 
> 
> Acked-by: Mauro Carvalho Chehab 
> 
> PS.: If you prefer to apply this one via my tree, I'm ok too. Just
> let me know when the first patch gets merged upstream.

This patchset was insufficient and I didn't came up with follow up.
Please ignore it for now.

Best regards,
Krzysztof

[Intel-gfx] [PATCH 06/64] drm: Restore double clflush on the last partial cacheline

[Mika Kuoppala]

Daniel Vetter  writes:

> On Thu, Jul 07, 2016 at 09:41:12AM +0100, Chris Wilson wrote:
>> This effectively reverts
>> 
>> commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
>> Author: Chris Wilson 
>> Date:   Wed Jun 10 15:58:01 2015 +0100
>> 
>> drm: Avoid the double clflush on the last cache line in 
>> drm_clflush_virt_range()
>> 
>> as we have observed issues with serialisation of the clflush operations
>> on Baytrail+ Atoms with partial updates. Applying the double flush on the
>> last cacheline forces that clflush to be ordered with respect to the
>> previous clflush, and the mfence then protects against prefetches crossing
>> the clflush boundary.
>> 
>> The same issue can be demonstrated in userspace with igt/gem_exec_flush.
>> 
>> Fixes: afcd950cafea6 (drm: Avoid the double clflush on the last cache...)
>> Testcase: igt/gem_concurrent_blit
>> Testcase: igt/gem_partial_pread_pwrite
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92845
>> Signed-off-by: Chris Wilson 
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: Akash Goel 
>> Cc: Imre Deak 
>> Cc: Daniel Vetter 
>> Cc: Jason Ekstrand 
>> Cc: stable at vger.kernel.org
>> Reviewed-by: Mika Kuoppala 
>
> It's duct-tape, but oh well. Applied to drm-misc.

We were confused how many layers we need.

-Mika

> -Daniel
>
>> ---
>>  drivers/gpu/drm/drm_cache.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
>> index 059f7c39c582..a7916e5f8864 100644
>> --- a/drivers/gpu/drm/drm_cache.c
>> +++ b/drivers/gpu/drm/drm_cache.c
>> @@ -136,6 +136,7 @@ drm_clflush_virt_range(void *addr, unsigned long length)
>>  mb();
>>  for (; addr < end; addr += size)
>>  clflushopt(addr);
>> +clflushopt(end - 1); /* force serialisation */
>>  mb();
>>  return;
>>  }
>> -- 
>> 2.8.1
>> 
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/amdkfd: print doorbell offset as a hex value

[Oded Gabbay]

On Wed, Jul 13, 2016 at 10:36 AM, Colin King  
wrote:
> From: Colin Ian King 
>
> The doorbell offset is formatted with a 0x prefix to suggest it is
> a hexadecimal value, when in fact %d is being used and this is confusing.
> Use %X instead to match the proceeding 0x prefix.
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> index e621eba..a7d3cb3 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> @@ -184,7 +184,7 @@ u32 __iomem *kfd_get_kernel_doorbell(struct kfd_dev *kfd,
> sizeof(u32)) + inx;
>
> pr_debug("kfd: get kernel queue doorbell\n"
> -" doorbell offset   == 0x%08d\n"
> +" doorbell offset   == 0x%08X\n"
>  " kernel address== 0x%08lX\n",
> *doorbell_off, (uintptr_t)(kfd->doorbell_kernel_ptr + inx));
>
> --
> 2.8.1
>

Thanks,
Applied to my -fixes tree

Oded

[PATCH v3 0/2] Toshiba TC358767 eDP bridge driver

[Archit Taneja]

Hi,

On 07/13/2016 12:37 PM, Philipp Zabel wrote:
> Hi,
>
> this patchset adds DT binding docs and a drm_bridge driver for the
> Toshiba TC358767 eDP bridge, currently supporting only 24-bit DPI input
> and control via I2C. The chip is also capable to act as a DSI sink, but
> the driver doesn't support that yet.
> It is based on Andrey's initial driver, which can be found at
> https://github.com/CogentEmbedded/linux-zodiac.git, commit 4abb1d0a9a1c
> ("drm/i2c: tc358767 eDP encoder initial commit"). I have turned it into
> a drm_bridge driver and changed it to use regmap and the drm_dp helpers.

The patchset looks good. We just need an ack for the DT bindings from
Rob.

Thanks,
Archit

>
> Changes since v2:
>   - Let DRM_TOSHIBA_TC358767 depend on OF
>   - Add a module parameter "test" to enable the color bar test pattern
>   - Provide mode clock to tc_pxl_pll_en
>   - Remove now otherwise unused struct tc_data members "pll_clk",
> "pll_clk_real" and "test_pattern".
>
> regards
> Philipp
>
> Andrey Gusakov (1):
>drm/bridge: tc358767: Add DPI to eDP bridge driver
>
> Philipp Zabel (1):
>dt-bindings: tc358767: add DT documentation
>
>   .../bindings/display/bridge/toshiba,tc358767.txt   |   51 +
>   drivers/gpu/drm/bridge/Kconfig |9 +
>   drivers/gpu/drm/bridge/Makefile|1 +
>   drivers/gpu/drm/bridge/tc358767.c  | 1413 
> 
>   4 files changed, 1474 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
>   create mode 100644 drivers/gpu/drm/bridge/tc358767.c
>

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

[PATCH 3/3] drm/imx: ipuv3-crtc: implement fast path mode_set_base

[Stefan Christ]

Implementing the function "mode_set_base" for i.MX6 IPU enables the
fast-path in function drm_crtc_helper_set_config. The fast-path is used
when flag 'mode_changed' is false and flag 'fb_changed' is true.

The fast-patch is needed for applications using the legcay framebuffer
ioctl FBIOPAN_DISPLAY for buffer flipping. When the fast-patch is not
present, the ioctl FBIOPAN_DISPLAY causes a complete mode set which is
too interruptive.

Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index fc04041..9858a57 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -234,6 +234,15 @@ static const struct drm_crtc_funcs ipu_crtc_funcs = {
.page_flip = ipu_page_flip,
 };

+int ipu_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
+ struct drm_framebuffer *old_fb)
+{
+   struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
+   struct ipu_plane *plane = ipu_crtc->plane[0];
+
+   return ipu_plane_set_base(plane, crtc->primary->fb, x, y);
+}
+
 static int ipu_crtc_mode_set(struct drm_crtc *crtc,
   struct drm_display_mode *orig_mode,
   struct drm_display_mode *mode,
@@ -378,6 +387,7 @@ static const struct drm_crtc_helper_funcs ipu_helper_funcs 
= {
.dpms = ipu_crtc_dpms,
.mode_fixup = ipu_crtc_mode_fixup,
.mode_set = ipu_crtc_mode_set,
+   .mode_set_base = ipu_crtc_mode_set_base,
.prepare = ipu_crtc_prepare,
.commit = ipu_crtc_commit,
 };
-- 
1.9.1

[PATCH 0/3] Support fast framebuffer panning for i.MX6

[Stefan Christ]

Hi,

im currently working on supporting double/tripple buffering for the framebuffer
emulation on the i.MX6.  While working on it I noticed that the mainline kernel
does not support some features in the generic drm framebuffer emulation for
framebuffer panning and vsync synchronisation. They are needed for simple
framebuffer applications and some OpenGL libraries using double buffering with
FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY.

Any comments?

Kind regards,
Stefan Christ

Stefan Christ (2):
  drm: fb_helper: implement ioctl FBIO_WAITFORVSYNC
  drm/imx: ipuv3-crtc: implement fast path mode_set_base

Xinliang Liu (1):
  drm/cma-helper: Add multi buffer support for cma fbdev

 drivers/gpu/drm/Kconfig |  8 +++
 drivers/gpu/drm/drm_fb_cma_helper.c |  9 +++-
 drivers/gpu/drm/drm_fb_helper.c | 43 +
 drivers/gpu/drm/imx/ipuv3-crtc.c| 10 +
 include/drm/drm_fb_helper.h |  2 ++
 5 files changed, 71 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH 1/3] drm/cma-helper: Add multi buffer support for cma fbdev

[Stefan Christ]

From: Xinliang Liu 

This patch add a config to support to create multi buffer for cma fbdev.
Such as double buffer and triple buffer.

Cma fbdev is convient to add a legency fbdev. And still many Android
devices use fbdev now and at least double buffer is needed for these
Android devices, so that a buffer flip can be operated. It will need
some time for Android device vendors to abondon legency fbdev. So multi
buffer for fbdev is needed.

Signed-off-by: Xinliang Liu 
[s.christ at phytec.de: Picking patch from
 https://lkml.org/lkml/2015/9/14/188]
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/Kconfig | 8 
 drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index fc35731..56cf34d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -106,6 +106,14 @@ config DRM_KMS_CMA_HELPER
help
  Choose this if you need the KMS CMA helper functions

+config DRM_CMA_FBDEV_BUFFER_NUM
+   int "Cma Fbdev Buffer Number"
+   depends on DRM_KMS_CMA_HELPER
+   default 1
+   help
+ Defines the buffer number of cma fbdev.  Default is one buffer.
+ For double buffer please set to 2 and 3 for triple buffer.
+
 source "drivers/gpu/drm/i2c/Kconfig"

 config DRM_TDFX
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 5075fae..be66042 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -27,6 +27,12 @@

 #define DEFAULT_FBDEFIO_DELAY_MS 50

+#ifdef CONFIG_DRM_CMA_FBDEV_BUFFER_NUM
+#define FBDEV_BUFFER_NUM CONFIG_DRM_CMA_FBDEV_BUFFER_NUM
+#else
+#define FBDEV_BUFFER_NUM 1
+#endif
+
 struct drm_fb_cma {
struct drm_framebuffer  fb;
struct drm_gem_cma_object   *obj[4];
@@ -389,7 +395,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper 
*helper,
bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);

mode_cmd.width = sizes->surface_width;
-   mode_cmd.height = sizes->surface_height;
+   mode_cmd.height = sizes->surface_height * FBDEV_BUFFER_NUM;
mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
sizes->surface_depth);
-- 
1.9.1

[PATCH 2/3] drm: fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Stefan Christ]

Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double buffering. It is tested on
the i.MX6.

Code is based on

https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196

Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/drm_fb_cma_helper.c |  1 +
 drivers/gpu/drm/drm_fb_helper.c | 43 +
 include/drm/drm_fb_helper.h |  2 ++
 3 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index be66042..95657da 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -313,6 +313,7 @@ static struct fb_ops drm_fbdev_cma_ops = {
.fb_blank   = drm_fb_helper_blank,
.fb_pan_display = drm_fb_helper_pan_display,
.fb_setcmap = drm_fb_helper_setcmap,
+   .fb_ioctl   = drm_fb_helper_ioctl,
 };

 static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 7c2eb75..4d1f9b9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1167,6 +1167,49 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
fb_info *info)
 EXPORT_SYMBOL(drm_fb_helper_setcmap);

 /**
+ * drm_fb_helper_ioctl - legacy ioctl implementation
+ * @info:
+ * @cmd: ioctl like FBIO_WAITFORVSYNC
+ * @arg: ioctl argument
+ */
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long 
arg)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   unsigned int i;
+   int ret = 0;
+
+   switch (cmd) {
+   case FBIO_WAITFORVSYNC:
+   for (i = 0; i < fb_helper->crtc_count; i++) {
+   struct drm_mode_set *mode_set;
+   struct drm_crtc *crtc;
+
+   mode_set = _helper->crtc_info[i].mode_set;
+   crtc = mode_set->crtc;
+
+   /*
+* Only call drm_crtc_wait_one_vblank for crtcs that
+* are currently active.
+*/
+   if (!crtc->enabled)
+   continue;
+
+   ret = drm_crtc_vblank_get(crtc);
+   if (!ret) {
+   drm_crtc_wait_one_vblank(crtc);
+   drm_crtc_vblank_put(crtc);
+   }
+   }
+   return ret;
+   default:
+   return -ENOTTY;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_ioctl);
+
+/**
  * drm_fb_helper_check_var - implementation for ->fb_check_var
  * @var: screeninfo to check
  * @info: fbdev registered by the helper
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 5b4aa35..121af93 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -278,6 +278,8 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
*fb_helper, int state);

 int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);

+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long 
arg);
+
 int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
 int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel);
 int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
-- 
1.9.1

[PATCH v6 12/46] drm/exynos: dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
[for drm]
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 12 +---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 20 ++--
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |  2 +-
 4 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 67dcd6831291..dd091175fc2d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -52,7 +52,7 @@ static int exynos_drm_fb_mmap(struct fb_info *info,

ret = dma_mmap_attrs(to_dma_dev(helper->dev), vma, exynos_gem->cookie,
 exynos_gem->dma_addr, exynos_gem->size,
-_gem->dma_attrs);
+exynos_gem->dma_attrs);
if (ret < 0) {
DRM_ERROR("failed to mmap.\n");
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 8564c3da0d22..4bf00f57ffe8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 #include 
@@ -235,7 +234,7 @@ struct g2d_data {
struct mutexcmdlist_mutex;
dma_addr_t  cmdlist_pool;
void*cmdlist_pool_virt;
-   struct dma_attrscmdlist_dma_attrs;
+   unsigned long   cmdlist_dma_attrs;

/* runqueue*/
struct g2d_runqueue_node*runqueue_node;
@@ -256,13 +255,12 @@ static int g2d_init_cmdlist(struct g2d_data *g2d)
int ret;
struct g2d_buf_info *buf_info;

-   init_dma_attrs(>cmdlist_dma_attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, >cmdlist_dma_attrs);
+   g2d->cmdlist_dma_attrs = DMA_ATTR_WRITE_COMBINE;

g2d->cmdlist_pool_virt = dma_alloc_attrs(to_dma_dev(subdrv->drm_dev),
G2D_CMDLIST_POOL_SIZE,
>cmdlist_pool, GFP_KERNEL,
-   >cmdlist_dma_attrs);
+   g2d->cmdlist_dma_attrs);
if (!g2d->cmdlist_pool_virt) {
dev_err(dev, "failed to allocate dma memory\n");
return -ENOMEM;
@@ -295,7 +293,7 @@ static int g2d_init_cmdlist(struct g2d_data *g2d)
 err:
dma_free_attrs(to_dma_dev(subdrv->drm_dev), G2D_CMDLIST_POOL_SIZE,
g2d->cmdlist_pool_virt,
-   g2d->cmdlist_pool, >cmdlist_dma_attrs);
+   g2d->cmdlist_pool, g2d->cmdlist_dma_attrs);
return ret;
 }

@@ -309,7 +307,7 @@ static void g2d_fini_cmdlist(struct g2d_data *g2d)
dma_free_attrs(to_dma_dev(subdrv->drm_dev),
G2D_CMDLIST_POOL_SIZE,
g2d->cmdlist_pool_virt,
-   g2d->cmdlist_pool, >cmdlist_dma_attrs);
+   g2d->cmdlist_pool, g2d->cmdlist_dma_attrs);
}
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index cdf9f1af4347..f2ae72ba7d5a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -24,7 +24,7 @@
 static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem)
 {
struct drm_device *dev = exynos_gem->base.dev;
-   enum dma_attr attr;
+   unsigned long attr;
unsigned int nr_pages;
struct sg_table sgt;
int ret = -ENOMEM;
@@ -34,7 +34,7 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem 
*exynos_gem)
return 0;
}

-   init_dma_attrs(_gem->dma_attrs);
+   exynos_gem->dma_attrs = 0;

/*
 * if EXYNOS_BO_CONTIG, fully physically contiguous memory
@@ -42,7 +42,7 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem 
*exynos_gem)
 * as possible.
 */
if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
-   dma_set_attr(DMA_ATTR_FORCE_CONTIGUOUS, _gem->dma_attrs);
+   exynos_gem->dma_attrs |= DMA_ATTR_FORCE_CONTIGUOUS;

/*
 * if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping
@@ -54,8 +54,8 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem 
*exynos_gem)
else
attr = DMA_ATTR_NON_CONSISTENT;

-   dma_set_attr(attr, _gem->dma_attrs);
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _gem->dma_attrs);
+   exynos_gem->dma_attrs |= attr;
+   exynos_gem->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;

nr_pages = exynos_gem->size >> PAGE_SHIFT;

[PATCH v6 15/46] drm/nouveau: dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
[for drm]
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index 6b8f2a19b2d9..a6a7fa0d7679 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -109,7 +109,7 @@ struct gk20a_instmem {
u16 iommu_bit;

/* Only used by DMA API */
-   struct dma_attrs attrs;
+   unsigned long attrs;
 };
 #define gk20a_instmem(p) container_of((p), struct gk20a_instmem, base)

@@ -293,7 +293,7 @@ gk20a_instobj_dtor_dma(struct nvkm_memory *memory)
goto out;

dma_free_attrs(dev, node->base.mem.size << PAGE_SHIFT, node->base.vaddr,
-  node->handle, >attrs);
+  node->handle, imem->attrs);

 out:
return node;
@@ -386,7 +386,7 @@ gk20a_instobj_ctor_dma(struct gk20a_instmem *imem, u32 
npages, u32 align,

node->base.vaddr = dma_alloc_attrs(dev, npages << PAGE_SHIFT,
   >handle, GFP_KERNEL,
-  >attrs);
+  imem->attrs);
if (!node->base.vaddr) {
nvkm_error(subdev, "cannot allocate DMA memory\n");
return -ENOMEM;
@@ -597,10 +597,9 @@ gk20a_instmem_new(struct nvkm_device *device, int index,

nvkm_info(>base.subdev, "using IOMMU\n");
} else {
-   init_dma_attrs(>attrs);
-   dma_set_attr(DMA_ATTR_NON_CONSISTENT, >attrs);
-   dma_set_attr(DMA_ATTR_WEAK_ORDERING, >attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, >attrs);
+   imem->attrs = DMA_ATTR_NON_CONSISTENT |
+ DMA_ATTR_WEAK_ORDERING |
+ DMA_ATTR_WRITE_COMBINE;

nvkm_info(>base.subdev, "using DMA API\n");
}
-- 
1.9.1

[PATCH v6 13/46] drm/mediatek: dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
[for drm]
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 13 ++---
 drivers/gpu/drm/mediatek/mtk_drm_gem.h |  2 +-
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index fa2ec0cd00e8..7abc550ebc00 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -54,15 +54,14 @@ struct mtk_drm_gem_obj *mtk_drm_gem_create(struct 
drm_device *dev,

obj = _gem->base;

-   init_dma_attrs(_gem->dma_attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, _gem->dma_attrs);
+   mtk_gem->dma_attrs = DMA_ATTR_WRITE_COMBINE;

if (!alloc_kmap)
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _gem->dma_attrs);
+   mtk_gem->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;

mtk_gem->cookie = dma_alloc_attrs(priv->dma_dev, obj->size,
  _gem->dma_addr, GFP_KERNEL,
- _gem->dma_attrs);
+ mtk_gem->dma_attrs);
if (!mtk_gem->cookie) {
DRM_ERROR("failed to allocate %zx byte dma buffer", obj->size);
ret = -ENOMEM;
@@ -93,7 +92,7 @@ void mtk_drm_gem_free_object(struct drm_gem_object *obj)
drm_prime_gem_destroy(obj, mtk_gem->sg);
else
dma_free_attrs(priv->dma_dev, obj->size, mtk_gem->cookie,
-  mtk_gem->dma_addr, _gem->dma_attrs);
+  mtk_gem->dma_addr, mtk_gem->dma_attrs);

/* release file pointer to gem object. */
drm_gem_object_release(obj);
@@ -173,7 +172,7 @@ static int mtk_drm_gem_object_mmap(struct drm_gem_object 
*obj,
vma->vm_pgoff = 0;

ret = dma_mmap_attrs(priv->dma_dev, vma, mtk_gem->cookie,
-mtk_gem->dma_addr, obj->size, _gem->dma_attrs);
+mtk_gem->dma_addr, obj->size, mtk_gem->dma_attrs);
if (ret)
drm_gem_vm_close(vma);

@@ -224,7 +223,7 @@ struct sg_table *mtk_gem_prime_get_sg_table(struct 
drm_gem_object *obj)

ret = dma_get_sgtable_attrs(priv->dma_dev, sgt, mtk_gem->cookie,
mtk_gem->dma_addr, obj->size,
-   _gem->dma_attrs);
+   mtk_gem->dma_attrs);
if (ret) {
DRM_ERROR("failed to allocate sgt, %d\n", ret);
kfree(sgt);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h 
b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
index 3a2a5624a1cb..2752718fa5b2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
@@ -35,7 +35,7 @@ struct mtk_drm_gem_obj {
void*cookie;
void*kvaddr;
dma_addr_t  dma_addr;
-   struct dma_attrsdma_attrs;
+   unsigned long   dma_attrs;
struct sg_table *sg;
 };

-- 
1.9.1

[PATCH v6 14/46] drm/msm: dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
[for drm]
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/msm/msm_drv.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 108f9d4876b9..95b99f6b8826 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -238,11 +238,10 @@ static int msm_drm_uninit(struct device *dev)
}

if (priv->vram.paddr) {
-   DEFINE_DMA_ATTRS(attrs);
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, );
+   unsigned long attrs = DMA_ATTR_NO_KERNEL_MAPPING;
drm_mm_takedown(>vram.mm);
dma_free_attrs(dev, priv->vram.size, NULL,
-  priv->vram.paddr, );
+  priv->vram.paddr, attrs);
}

component_unbind_all(dev, ddev);
@@ -310,21 +309,21 @@ static int msm_init_vram(struct drm_device *dev)
}

if (size) {
-   DEFINE_DMA_ATTRS(attrs);
+   unsigned long attrs = 0;
void *p;

priv->vram.size = size;

drm_mm_init(>vram.mm, 0, (size >> PAGE_SHIFT) - 1);

-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, );
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
+   attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
+   attrs |= DMA_ATTR_WRITE_COMBINE;

/* note that for no-kernel-mapping, the vaddr returned
 * is bogus, but non-null if allocation succeeded:
 */
p = dma_alloc_attrs(dev->dev, size,
-   >vram.paddr, GFP_KERNEL, );
+   >vram.paddr, GFP_KERNEL, attrs);
if (!p) {
dev_err(dev->dev, "failed to allocate VRAM\n");
priv->vram.paddr = 0;
-- 
1.9.1

[PATCH v6 16/46] drm/rockship: dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
[for drm]
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |  2 +-
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 059e902f872d..28b2a828c650 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -17,8 +17,6 @@
 #include 
 #include 

-#include 
-
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"

@@ -28,15 +26,14 @@ static int rockchip_gem_alloc_buf(struct 
rockchip_gem_object *rk_obj,
struct drm_gem_object *obj = _obj->base;
struct drm_device *drm = obj->dev;

-   init_dma_attrs(_obj->dma_attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, _obj->dma_attrs);
+   rk_obj->dma_attrs = DMA_ATTR_WRITE_COMBINE;

if (!alloc_kmap)
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _obj->dma_attrs);
+   rk_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;

rk_obj->kvaddr = dma_alloc_attrs(drm->dev, obj->size,
 _obj->dma_addr, GFP_KERNEL,
-_obj->dma_attrs);
+rk_obj->dma_attrs);
if (!rk_obj->kvaddr) {
DRM_ERROR("failed to allocate %zu byte dma buffer", obj->size);
return -ENOMEM;
@@ -51,7 +48,7 @@ static void rockchip_gem_free_buf(struct rockchip_gem_object 
*rk_obj)
struct drm_device *drm = obj->dev;

dma_free_attrs(drm->dev, obj->size, rk_obj->kvaddr, rk_obj->dma_addr,
-  _obj->dma_attrs);
+  rk_obj->dma_attrs);
 }

 static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
@@ -70,7 +67,7 @@ static int rockchip_drm_gem_object_mmap(struct drm_gem_object 
*obj,
vma->vm_pgoff = 0;

ret = dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
-obj->size, _obj->dma_attrs);
+obj->size, rk_obj->dma_attrs);
if (ret)
drm_gem_vm_close(vma);

@@ -262,7 +259,7 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct 
drm_gem_object *obj)

ret = dma_get_sgtable_attrs(drm->dev, sgt, rk_obj->kvaddr,
rk_obj->dma_addr, obj->size,
-   _obj->dma_attrs);
+   rk_obj->dma_attrs);
if (ret) {
DRM_ERROR("failed to allocate sgt, %d\n", ret);
kfree(sgt);
@@ -276,7 +273,7 @@ void *rockchip_gem_prime_vmap(struct drm_gem_object *obj)
 {
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);

-   if (dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, _obj->dma_attrs))
+   if (dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, rk_obj->dma_attrs))
return NULL;

return rk_obj->kvaddr;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
index ad22618473a4..18b3488db4ec 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
@@ -23,7 +23,7 @@ struct rockchip_gem_object {

void *kvaddr;
dma_addr_t dma_addr;
-   struct dma_attrs dma_attrs;
+   unsigned long dma_attrs;
 };

 struct sg_table *rockchip_gem_prime_get_sg_table(struct drm_gem_object *obj);
-- 
1.9.1

[PATCH v6 00/46] dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

Hi,

The fifth version of this patchset was merged by Andrew Morton
few days ago.  It was rebased on v4.7-rc5 so it missed some ongoing
changes.

This is just rebase on next-20160713.


For easier testing the patchset is available here:
repo:   https://github.com/krzk/linux
branch: for-next/dma-attrs-const-v6


Changes since v5

1. New patches:
   1/46:  [media] mtk-vcodec: Remove unused dma_attrs
   44/46: remoteproc: qcom: Use unsigned long for dma_attrs
2. 19/46: rebased on next, some more changes inside
3. Added accumulated acks: Marek Szyprowski, Richard Kuo,
   Konrad Rzeszutek Wilk, Daniel Vetter and Joerg Roedel.


Changes since v4

1. Collect some acks. Still need more.
2. Minor fixes pointed by Robin Murphy.
3. Applied changes from Bart Van Assche's comment.
4. More tests and builds (using https://www.kernel.org/pub/tools/crosstool/).


Changes since v3

1. Collect some acks.
2. Drop wrong patch 1/45 ("powerpc: dma-mapping: Don't hard-code
   the value of DMA_ATTR_WEAK_ORDERING").
3. Minor fix pointed out by Michael Ellerman.


Changes since v2

1. Follow Christoph Hellwig's comments (don't use BIT add
   documentation, remove dma_get_attr).


Rationale
=
The dma-mapping core and the implementations do not change the
DMA attributes passed by pointer.  Thus the pointer can point to const
data.  However the attributes do not have to be a bitfield. Instead
unsigned long will do fine:

1. This is just simpler.  Both in terms of reading the code and setting
   attributes.  Instead of initializing local attributes on the stack
   and passing pointer to it to dma_set_attr(), just set the bits.

2. It brings safeness and checking for const correctness because the
   attributes are passed by value.


Best regards,
Krzysztof


Krzysztof Kozlowski (46):
  [media] mtk-vcodec: Remove unused dma_attrs
  dma-mapping: Use unsigned long for dma_attrs
  alpha: dma-mapping: Use unsigned long for dma_attrs
  arc: dma-mapping: Use unsigned long for dma_attrs
  ARM: dma-mapping: Use unsigned long for dma_attrs
  arm64: dma-mapping: Use unsigned long for dma_attrs
  avr32: dma-mapping: Use unsigned long for dma_attrs
  blackfin: dma-mapping: Use unsigned long for dma_attrs
  c6x: dma-mapping: Use unsigned long for dma_attrs
  cris: dma-mapping: Use unsigned long for dma_attrs
  frv: dma-mapping: Use unsigned long for dma_attrs
  drm/exynos: dma-mapping: Use unsigned long for dma_attrs
  drm/mediatek: dma-mapping: Use unsigned long for dma_attrs
  drm/msm: dma-mapping: Use unsigned long for dma_attrs
  drm/nouveau: dma-mapping: Use unsigned long for dma_attrs
  drm/rockship: dma-mapping: Use unsigned long for dma_attrs
  infiniband: dma-mapping: Use unsigned long for dma_attrs
  iommu: dma-mapping: Use unsigned long for dma_attrs
  [media] dma-mapping: Use unsigned long for dma_attrs
  xen: dma-mapping: Use unsigned long for dma_attrs
  swiotlb: dma-mapping: Use unsigned long for dma_attrs
  powerpc: dma-mapping: Use unsigned long for dma_attrs
  video: dma-mapping: Use unsigned long for dma_attrs
  x86: dma-mapping: Use unsigned long for dma_attrs
  iommu: intel: dma-mapping: Use unsigned long for dma_attrs
  h8300: dma-mapping: Use unsigned long for dma_attrs
  hexagon: dma-mapping: Use unsigned long for dma_attrs
  ia64: dma-mapping: Use unsigned long for dma_attrs
  m68k: dma-mapping: Use unsigned long for dma_attrs
  metag: dma-mapping: Use unsigned long for dma_attrs
  microblaze: dma-mapping: Use unsigned long for dma_attrs
  mips: dma-mapping: Use unsigned long for dma_attrs
  mn10300: dma-mapping: Use unsigned long for dma_attrs
  nios2: dma-mapping: Use unsigned long for dma_attrs
  openrisc: dma-mapping: Use unsigned long for dma_attrs
  parisc: dma-mapping: Use unsigned long for dma_attrs
  misc: mic: dma-mapping: Use unsigned long for dma_attrs
  s390: dma-mapping: Use unsigned long for dma_attrs
  sh: dma-mapping: Use unsigned long for dma_attrs
  sparc: dma-mapping: Use unsigned long for dma_attrs
  tile: dma-mapping: Use unsigned long for dma_attrs
  unicore32: dma-mapping: Use unsigned long for dma_attrs
  xtensa: dma-mapping: Use unsigned long for dma_attrs
  remoteproc: qcom: Use unsigned long for dma_attrs
  dma-mapping: Remove dma_get_attr
  dma-mapping: Document the DMA attributes next to the declaration

 Documentation/DMA-API.txt  |  33 +++---
 Documentation/DMA-attributes.txt   |   2 +-
 arch/alpha/include/asm/dma-mapping.h   |   2 -
 arch/alpha/kernel/pci-noop.c   |   2 +-
 arch/alpha/kernel/pci_iommu.c  |  12 +-
 arch/arc/mm/dma.c  |  12 +-
 arch/arm/common/dmabounce.c|   4 +-
 arch/arm/include/asm/dma-mapping.h |  13 +--
 arch/arm/include/asm/xen/page-coherent.h   |  16 +--
 arch/arm/mm/dma-mapping.c 

[PATCH v6 45/46] dma-mapping: Remove dma_get_attr

[Krzysztof Kozlowski]

After switching DMA attributes to unsigned long it is easier to just
compare the bits.

Signed-off-by: Krzysztof Kozlowski 
[for avr32]
Acked-by: Hans-Christian Noren Egtvedt 
[for arc]
Acked-by: Vineet Gupta 
[for arm64 and dma-iommu]
Acked-by: Robin Murphy 
---
 Documentation/DMA-API.txt  |  4 +--
 arch/arc/mm/dma.c  |  4 +--
 arch/arm/mm/dma-mapping.c  | 36 --
 arch/arm/xen/mm.c  |  4 +--
 arch/arm64/mm/dma-mapping.c| 10 +++
 arch/avr32/mm/dma-coherent.c   |  4 +--
 arch/ia64/sn/pci/pci_dma.c | 10 ++-
 arch/metag/kernel/dma.c|  2 +-
 arch/mips/mm/dma-default.c |  6 ++---
 arch/openrisc/kernel/dma.c |  4 +--
 arch/parisc/kernel/pci-dma.c   |  2 +-
 arch/powerpc/platforms/cell/iommu.c| 12 -
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  2 +-
 drivers/iommu/dma-iommu.c  |  2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  2 +-
 include/linux/dma-mapping.h| 10 ---
 16 files changed, 47 insertions(+), 67 deletions(-)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 24f9688bb98a..1d26eeb6b5f6 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -422,9 +422,7 @@ void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t 
dma_addr,
 unsigned long attrs)
 {

-   int foo =  dma_get_attr(DMA_ATTR_FOO, attrs);
-   
-   if (foo)
+   if (attrs & DMA_ATTR_FOO)
/* twizzle the frobnozzle */


diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 3d1f467d1792..74bbe68dce9d 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -46,7 +46,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
 *   (vs. always going to memory - thus are faster)
 */
if ((is_isa_arcv2() && ioc_exists) ||
-   dma_get_attr(DMA_ATTR_NON_CONSISTENT, attrs))
+   (attrs & DMA_ATTR_NON_CONSISTENT))
need_coh = 0;

/*
@@ -95,7 +95,7 @@ static void arc_dma_free(struct device *dev, size_t size, 
void *vaddr,
struct page *page = virt_to_page(dma_handle);
int is_non_coh = 1;

-   is_non_coh = dma_get_attr(DMA_ATTR_NON_CONSISTENT, attrs) ||
+   is_non_coh = (attrs & DMA_ATTR_NON_CONSISTENT) ||
(is_isa_arcv2() && ioc_exists);

if (PageHighMem(page) || !is_non_coh)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ebb3fde99043..43e03b5293d0 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -126,7 +126,7 @@ static dma_addr_t arm_dma_map_page(struct device *dev, 
struct page *page,
 unsigned long offset, size_t size, enum dma_data_direction dir,
 unsigned long attrs)
 {
-   if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+   if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_cpu_to_dev(page, offset, size, dir);
return pfn_to_dma(dev, page_to_pfn(page)) + offset;
 }
@@ -155,7 +155,7 @@ static dma_addr_t arm_coherent_dma_map_page(struct device 
*dev, struct page *pag
 static void arm_dma_unmap_page(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-   if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+   if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_dev_to_cpu(pfn_to_page(dma_to_pfn(dev, handle)),
  handle & ~PAGE_MASK, size, dir);
 }
@@ -622,9 +622,9 @@ static void __free_from_contiguous(struct device *dev, 
struct page *page,

 static inline pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot)
 {
-   prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
-   pgprot_writecombine(prot) :
-   pgprot_dmacoherent(prot);
+   prot = (attrs & DMA_ATTR_WRITE_COMBINE) ?
+   pgprot_writecombine(prot) :
+   pgprot_dmacoherent(prot);
return prot;
 }

@@ -744,7 +744,7 @@ static void *__dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
.gfp = gfp,
.prot = prot,
.caller = caller,
-   .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+   .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0),
};

 #ifdef CONFIG_DMA_API_DEBUG
@@ -887,7 +887,7 @@ static void __arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
.size = PAGE_ALIGN(size),
.cpu_addr = cpu_addr,
.page = page,
-   .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+

[Bug 96908] [radeonsi] MSAA causes graphical artifacts

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

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

--- Comment #4 from Nicolai Hähnle  ---
Hi Andrey, thanks for the report.

I just tried Unigine Heaven with x8 on Tonga, and see no such problems. I'm
also fairly certain that I tried MSAA in Heaven on Polaris10 and so no such
problems, but I'll re-try when I get the change. I'll keep you posted.

-- 
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/20160713/73205086/attachment.html>

[Bug 96908] [radeonsi] MSAA causes graphical artifacts

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

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

--- Comment #5 from Nicolai Hähnle  ---
Sorry, forgot to mention: could you provide an apitrace of The Talos Principle
that shows the artifacts on your system? Upload e.g. to Google Drive since it's
going to be fairly large.

-- 
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/20160713/ab6fcb4e/attachment.html>

[Bug 96908] [radeonsi] MSAA causes graphical artifacts

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

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

--- Comment #6 from Nicolai Hähnle  ---
Never mind, I see them in Unigine Heaven on Polaris10 as well. Must be a recent
regression.

-- 
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/20160713/4b2ced10/attachment.html>

[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

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

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

--- Comment #24 from cosiekvfj at o2.pl ---
Created attachment 125049
  --> https://bugs.freedesktop.org/attachment.cgi?id=125049=edit
gdb

Do I need also lib32-llvm-db?

-- 
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/20160713/d4e2c69a/attachment.html>

[Bug 93475] Saints Row IV causes GPU lockup on Linux

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

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

--- Comment #3 from iive at yahoo.com ---
Could you try `export R600_DEBUG=nosb`?

This disables Shader Backend that optimizes the assembler code.
If this workarounds the problem, it would be useful to provide an
apitrace of the game that could reproduce your problem.

These may be related:
https://bugs.freedesktop.org/show_bug.cgi?id=86720
https://bugs.freedesktop.org/show_bug.cgi?id=94900

-- 
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/20160713/bc23c988/attachment.html>

[PATCH 2/9] async: Introduce kfence, a N:M completion mechanism

[Peter Zijlstra]

On Fri, Jun 24, 2016 at 10:08:46AM +0100, Chris Wilson wrote:
> diff --git a/kernel/async.c b/kernel/async.c
> index d2edd6efec56..d0bcb7cc4884 100644
> --- a/kernel/async.c
> +++ b/kernel/async.c
> @@ -50,6 +50,7 @@ asynchronous and synchronous parts of the kernel.
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 

So why does this live in async.c? It got its own header, why not also
give it its own .c file?

Also, I'm not a particular fan of the k* naming, but I see 'fence' is
already taken.

> +/**
> + * DOC: kfence overview
> + *
> + * kfences provide synchronisation barriers between multiple processes.
> + * They are very similar to completions, or a pthread_barrier. Where
> + * kfence differs from completions is their ability to track multiple
> + * event sources rather than being a singular "completion event". Similar
> + * to completions, multiple processes or other kfences can listen or wait
> + * upon a kfence to signal its completion.
> + *
> + * The kfence is a one-shot flag, signaling that work has progressed passed
> + * a certain point (as measured by completion of all events the kfence is
> + * listening for) and the waiters upon kfence may proceed.
> + *
> + * kfences provide both signaling and waiting routines:
> + *
> + *   kfence_pending()
> + *
> + * indicates that the kfence should itself wait for another signal. A
> + * kfence created by kfence_create() starts in the pending state.

I would much prefer:

 *  - kfence_pending(): indicates that the kfence should itself wait for
 *another signal. A kfence created by kfence_create() starts in the
 *pending state.

Which is much clearer in what text belongs where.

Also, what !? I don't get what this function does.

> + *
> + *   kfence_signal()
> + *
> + * undoes the earlier pending notification and allows the fence to complete
> + * if all pending events have then been signaled.

So I know _signal() is the posix thing, but seeing how we already
completions, how about being consistent with those and use _complete()
for this?

> + *
> + *   kfence_wait()
> + *
> + * allows the caller to sleep (uninterruptibly) until the fence is complete.

whitespace to separate the description of kfence_wait() from whatever
else follows.

> + * Meanwhile,
> + *
> + *   kfence_complete()
> + *
> + * reports whether or not the kfence has been passed.

kfence_done(), again to match completions.

> + *
> + * This interface is very similar to completions, with the exception of
> + * allowing multiple pending / signals to be sent before the kfence is
> + * complete.
> + *
> + *   kfence_add() / kfence_add_completion()
> + *
> + * sets the kfence to wait upon another fence, or completion respectively.
> + *
> + * Unlike completions, kfences are expected to live inside more complex 
> graphs
> + * and form the basis for parallel execution of interdependent and so are
> + * reference counted. A kfence may be created using,
> + *
> + *   kfence_create()
> + *
> + * The fence starts off pending a single signal. Once you have finished
> + * setting up the fence, use kfence_signal() to allow it to wait upon
> + * its event sources.
> + *
> + * Use
> + *
> + *   kfence_get() / kfence_put
> + *
> + * to acquire or release a reference on kfence respectively.
> + */

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

[Michel Dänzer]

On 13.07.2016 15:50, Rainer Hochecker wrote:
> Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is
> not an option anymore because we need EGL for vaapi. But we can fall
> back to the invisible window for getting vsync. I never tried using EGL
> and GLX in the same application, different windows. Any reason why this
> should not work?

An invisible window may not synchronize with the same output refresh
cycle as your output window.


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

[PATCH][libdrm] drm: Fix multi GPU drmGetDevice return wrong device

[Emil Velikov]

Hi Qiang Yu,

Thanks for fixing my buggy code (yet again) :-)

On 11 July 2016 at 06:17, Qiang Yu  wrote:
> drmGetDevice will always return the first device it find
> under /dev/dri/. This is not true for multi GPU situation.
>
How does the following alternative solution sound:
 - keep drmFoldDuplicatedDevices as is
 - after the drmFoldDuplicatedDevices call use the find_rdev to find
the correct device in local_devices.

> Plus fix the memory leak in error handling path of
> drmGetDevices.
>
Unless I'm missing something, there is no memory leak fix below ?
Alternatively please keep it as separate patch.

> Change-Id: I2a85a8a4feba8a5cc517ad75c6afb532fa07c53d
Please drop this line.

Regards,
Emil

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

[Daniel Vetter]

On Wed, Jul 13, 2016 at 06:43:37PM +0900, Michel Dänzer wrote:
> On 13.07.2016 15:50, Rainer Hochecker wrote:
> > Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is
> > not an option anymore because we need EGL for vaapi. But we can fall
> > back to the invisible window for getting vsync. I never tried using EGL
> > and GLX in the same application, different windows. Any reason why this
> > should not work?
> 
> An invisible window may not synchronize with the same output refresh
> cycle as your output window.

Why do you need EGL for libva? Besides that noob question from me, no idea
how well EGL/GLX can interop at all ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Daniel Vetter]

On Wed, Jul 13, 2016 at 01:22:06AM +, Peter Chen wrote:
>  
> >
> >Just an aside: When you do the same bugfix for multiple places it's good 
> >practice to
> >submit it as one series (and cc everyone involved). Increases the odds that 
> >someone
> >is in a good mood and reviews them all, instead of just the one affecting 
> >their own
> >driver.
> 
> Thanks, I realized that, and did it for later fixes for drm.
> But if the bug fixes are at several subsystems, I think
> we should split patch set per subsystem.

Yeah, splitting per subsystem makes sense I'd say. I merged some of your
patches, others are merged by driver maintainers directly. Is there
anything left? If so, pls resend those as a new series to make sure it's
all in one place.
-Daniel

> 
> Peter
> 
> >
> >> ---
> >>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 ---
> >>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
> >> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> >> index bf407b6..1ee6e5e 100644
> >> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> >> @@ -126,15 +126,16 @@ 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;
> >> +  struct device_node *np, *np_parent;
> >>
> >>np = of_parse_phandle(node, "remote-endpoint", 0);
> >>if (!np)
> >>return NULL;
> >>
> >> -  np = of_get_next_parent(np);
> >> +  np_parent = of_get_next_parent(np);
> >> +  of_node_put(np);
> >>
> >> -  return np;
> >> +  return np_parent;
> >>  }
> >>
> >>  struct device_node *
> >> --
> >> 1.9.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >--
> >Daniel Vetter
> >Software Engineer, Intel Corporation
> >http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Peter Chen]

>
>Just an aside: When you do the same bugfix for multiple places it's good 
>practice to
>submit it as one series (and cc everyone involved). Increases the odds that 
>someone
>is in a good mood and reviews them all, instead of just the one affecting 
>their own
>driver.

Thanks, I realized that, and did it for later fixes for drm.
But if the bug fixes are at several subsystems, I think
we should split patch set per subsystem.

Peter

>
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> index bf407b6..1ee6e5e 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> @@ -126,15 +126,16 @@ 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;
>> +struct device_node *np, *np_parent;
>>
>>  np = of_parse_phandle(node, "remote-endpoint", 0);
>>  if (!np)
>>  return NULL;
>>
>> -np = of_get_next_parent(np);
>> +np_parent = of_get_next_parent(np);
>> +of_node_put(np);
>>
>> -return np;
>> +return np_parent;
>>  }
>>
>>  struct device_node *
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

[Rainer Hochecker]

We have been using this for years now and did not observe issues you
mentioned. I would be surprised if a child window refreshes in a different
rate than the main window
Am 13.07.2016 11:44 schrieb "Michel Dänzer" :

On 13.07.2016 15:50, Rainer Hochecker wrote:
> Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is
> not an option anymore because we need EGL for vaapi. But we can fall
> back to the invisible window for getting vsync. I never tried using EGL
> and GLX in the same application, different windows. Any reason why this
> should not work?

An invisible window may not synchronize with the same output refresh
cycle as your output window.


--
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/c2ad5b90/attachment.html>

[PATCH] drm/nouveau/fbcon: fix deadlock with FBIOPUT_CON2FBMAP

[Daniel Vetter]

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> while nouveau was runtime suspended, a deadlock would occur due to
> nouveau_fbcon_set_suspend also trying to obtain console_lock().
> 
> Fix this by delaying the drm_fb_helper_set_suspend call. Based on the
> i915 code (which was done for performance reasons though).
> 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Signed-off-by: Peter Wu 
> ---
> Tested on top of v4.7-rc5, the deadlock is gone.

If we bother with this, it should imo be moved into the drm_fb_helper.c
function drm_fb_helper_set_suspend(). But this also smells like some kind
of bad duct-tape. I think Lukas is working on some other rpm vs. fbdev
deadlocks, maybe we could fix them all with one proper fix? I've made some
comments on Lukas' last patch series.

Besides this, when fixing a deadlock pls provide more details about the
precise callchain and the locks involved in the deadlock. If you
discovered this using lockdep, then just add the entire lockdep splat to
the commit message. Otherwise there's lots of guesswork involved here.
-Daniel

> ---
>  drivers/gpu/drm/nouveau/nouveau_drm.c   |  4 +--
>  drivers/gpu/drm/nouveau/nouveau_drv.h   |  1 +
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c | 54 
> -
>  drivers/gpu/drm/nouveau/nouveau_fbcon.h |  2 +-
>  4 files changed, 50 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 11f8dd9..f9a2c10 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -552,7 +552,7 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
>  
>   if (dev->mode_config.num_crtc) {
>   NV_INFO(drm, "suspending console...\n");
> - nouveau_fbcon_set_suspend(dev, 1);
> + nouveau_fbcon_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
>   NV_INFO(drm, "suspending display...\n");
>   ret = nouveau_display_suspend(dev, runtime);
>   if (ret)
> @@ -635,7 +635,7 @@ nouveau_do_resume(struct drm_device *dev, bool runtime)
>   NV_INFO(drm, "resuming display...\n");
>   nouveau_display_resume(dev, runtime);
>   NV_INFO(drm, "resuming console...\n");
> - nouveau_fbcon_set_suspend(dev, 0);
> + nouveau_fbcon_set_suspend(dev, FBINFO_STATE_RUNNING, false);
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index 822a021..a743d19 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -147,6 +147,7 @@ struct nouveau_drm {
>   struct nouveau_channel *channel;
>   struct nvkm_gpuobj *notify;
>   struct nouveau_fbdev *fbcon;
> + struct work_struct fbdev_suspend_work;
>   struct nvif_object nvsw;
>   struct nvif_object ntfy;
>   struct nvif_notify flip;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index d1f248f..089156a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -492,19 +492,53 @@ static const struct drm_fb_helper_funcs 
> nouveau_fbcon_helper_funcs = {
>   .fb_probe = nouveau_fbcon_create,
>  };
>  
> +static void nouveau_fbcon_suspend_worker(struct work_struct *work)
> +{
> + nouveau_fbcon_set_suspend(container_of(work,
> +struct nouveau_drm,
> +fbdev_suspend_work)->dev,
> +   FBINFO_STATE_RUNNING,
> +   true);
> +}
> +
>  void
> -nouveau_fbcon_set_suspend(struct drm_device *dev, int state)
> +nouveau_fbcon_set_suspend(struct drm_device *dev, int state, bool 
> synchronous)
>  {
>   struct nouveau_drm *drm = nouveau_drm(dev);
> - if (drm->fbcon) {
> - console_lock();
> - if (state == FBINFO_STATE_RUNNING)
> - nouveau_fbcon_accel_restore(dev);
> - drm_fb_helper_set_suspend(>fbcon->helper, state);
> + if (!drm->fbcon)
> + return;
> +
> + if (synchronous) {
> + /* Flush any pending work to turn the console on, and then
> +  * wait to turn it off. It must be synchronous as we are
> +  * about to suspend or unload the driver.
> +  *
> +  * Note that from within the work-handler, we cannot flush
> +  * ourselves, so only flush outstanding work upon suspend!
> +  */
>   if (state != FBINFO_STATE_RUNNING)
> - nouveau_fbcon_accel_save_disable(dev);
> - console_unlock();
> + flush_work(>fbdev_suspend_work);
> + console_lock();
> + } else {
> + /*

[PATCH 0/3] Support fast framebuffer panning for i.MX6

[Daniel Vetter]

On Wed, Jul 13, 2016 at 10:11:45AM +0200, Stefan Christ wrote:
> Hi,
> 
> im currently working on supporting double/tripple buffering for the 
> framebuffer
> emulation on the i.MX6.  While working on it I noticed that the mainline 
> kernel
> does not support some features in the generic drm framebuffer emulation for
> framebuffer panning and vsync synchronisation. They are needed for simple
> framebuffer applications and some OpenGL libraries using double buffering with
> FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY.
> 
> Any comments?

Don't ever do OpenGL on fbdev. Ever. The fbdev emulation we have is to
support boot splashs, kernel console, oopses and legacy applications that
just love fbdev too much and don't support native kms dumb buffers.

Anything that goes beyond kms dumb buffers (like displaying buffers
rendered through opengl) is imo a complete no-go. Yes Android loves to do
that, but for upstream we need a proper drm render driver, buffer sharing
through prime and the userspace hwcomposer needs to use native drm kms
ioctls. Also, userspace (especially the opengl part) needs to be open
source for upstream.

Thanks, Daniel
> 
> Kind regards,
>   Stefan Christ
> 
> Stefan Christ (2):
>   drm: fb_helper: implement ioctl FBIO_WAITFORVSYNC
>   drm/imx: ipuv3-crtc: implement fast path mode_set_base
> 
> Xinliang Liu (1):
>   drm/cma-helper: Add multi buffer support for cma fbdev
> 
>  drivers/gpu/drm/Kconfig |  8 +++
>  drivers/gpu/drm/drm_fb_cma_helper.c |  9 +++-
>  drivers/gpu/drm/drm_fb_helper.c | 43 
> +
>  drivers/gpu/drm/imx/ipuv3-crtc.c| 10 +
>  include/drm/drm_fb_helper.h |  2 ++
>  5 files changed, 71 insertions(+), 1 deletion(-)
> 
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/3] drm/cma-helper: Add multi buffer support for cma fbdev

[Daniel Vetter]

On Wed, Jul 13, 2016 at 10:11:46AM +0200, Stefan Christ wrote:
> From: Xinliang Liu 
> 
> This patch add a config to support to create multi buffer for cma fbdev.
> Such as double buffer and triple buffer.
> 
> Cma fbdev is convient to add a legency fbdev. And still many Android
> devices use fbdev now and at least double buffer is needed for these
> Android devices, so that a buffer flip can be operated. It will need
> some time for Android device vendors to abondon legency fbdev. So multi
> buffer for fbdev is needed.
> 
> Signed-off-by: Xinliang Liu 
> [s.christ at phytec.de: Picking patch from
>  https://lkml.org/lkml/2015/9/14/188]
> Signed-off-by: Stefan Christ 

We first need to discuss whether we want to do this as a high level idea,
but meanwhile also some comments about details on the patches.

> ---
>  drivers/gpu/drm/Kconfig | 8 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index fc35731..56cf34d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -106,6 +106,14 @@ config DRM_KMS_CMA_HELPER
>   help
> Choose this if you need the KMS CMA helper functions
>  
> +config DRM_CMA_FBDEV_BUFFER_NUM
> + int "Cma Fbdev Buffer Number"
> + depends on DRM_KMS_CMA_HELPER
> + default 1
> + help
> +   Defines the buffer number of cma fbdev.  Default is one buffer.
> +   For double buffer please set to 2 and 3 for triple buffer.
> +
>  source "drivers/gpu/drm/i2c/Kconfig"
>  
>  config DRM_TDFX
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 5075fae..be66042 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -27,6 +27,12 @@
>  
>  #define DEFAULT_FBDEFIO_DELAY_MS 50
>  
> +#ifdef CONFIG_DRM_CMA_FBDEV_BUFFER_NUM
> +#define FBDEV_BUFFER_NUM CONFIG_DRM_CMA_FBDEV_BUFFER_NUM
> +#else
> +#define FBDEV_BUFFER_NUM 1
> +#endif

Imo this should be done in the core helpers, we could do this by
multiplying the height of buffers. And I think we should also expose this
as a module option, with Kconfig simply setting the default.
-Daniel

> +
>  struct drm_fb_cma {
>   struct drm_framebuffer  fb;
>   struct drm_gem_cma_object   *obj[4];
> @@ -389,7 +395,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper 
> *helper,
>   bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
>  
>   mode_cmd.width = sizes->surface_width;
> - mode_cmd.height = sizes->surface_height;
> + mode_cmd.height = sizes->surface_height * FBDEV_BUFFER_NUM;
>   mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
>   mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
>   sizes->surface_depth);
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games or after extended periods of time

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

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

--- Comment #12 from Arek Ruśniak  ---
Hi, 
I have HD 7770 too and your problem sounds familiar. I use gnome3 as well. I
use mesa/llvm from git master tree all the time. 
Sometimes clicking at "activites" was enough to gpu went "bunga bunga" but
sometimes it was stable as hell.  It was extremly random and no trigger for
that I found but some times ago I don't remember exactly (half year or so)
problem disappeared. 

If you are still using mesa from fedora (I can't see what version is) maybe
it's time to consider changes. 
There is repo with mesa-git for fedora (against llvm 3.8). It could be good
start.

-- 
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/20160713/2dd9633b/attachment.html>

[patch] drm/rockchip: fix a couple off by one bugs

[Dan Carpenter]

The priv->crtc_funcs[] array has ROCKCHIP_MAX_CRTC elements so > should
be >= here.

Fixes: 2048e3286f34 ('drm: rockchip: Add basic drm driver')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 7fd20c0..37ca427 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -79,7 +79,7 @@ int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
int pipe = drm_crtc_index(crtc);
struct rockchip_drm_private *priv = crtc->dev->dev_private;

-   if (pipe > ROCKCHIP_MAX_CRTC)
+   if (pipe >= ROCKCHIP_MAX_CRTC)
return -EINVAL;

priv->crtc_funcs[pipe] = crtc_funcs;
@@ -92,7 +92,7 @@ void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)
int pipe = drm_crtc_index(crtc);
struct rockchip_drm_private *priv = crtc->dev->dev_private;

-   if (pipe > ROCKCHIP_MAX_CRTC)
+   if (pipe >= ROCKCHIP_MAX_CRTC)
return;

priv->crtc_funcs[pipe] = NULL;

[PATCH 24/27] drm: Resurrect atomic rmfb code

[Maarten Lankhorst]

Op 08-06-16 om 14:19 schreef Daniel Vetter:
> This was somehow lost between v3 and the merged version in Maarten's
> patch merged as:
>
> commit f2d580b9a8149735cbc4b59c4a8df60173658140
> Author: Maarten Lankhorst 
> Date:   Wed May 4 14:38:26 2016 +0200
>
> drm/core: Do not preserve framebuffer on rmfb, v4.
>
> Actual code copied from Maarten's patch, but with the slight change to
> just use dev->mode_config.funcs->atomic_commit to decide whether to
> use the atomic path or not.
>
> Cc: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c| 66 
> +
>  drivers/gpu/drm/drm_crtc.c  |  6 
>  drivers/gpu/drm/drm_crtc_internal.h |  1 +
>  3 files changed, 73 insertions(+)
It passes the IGT kms_rmfb test, so I'm happy. :)

Reviewed-by: Maarten Lankhorst 

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

[Rainer Hochecker]

GLX can't interop with libva in a reasonable way. That was the reason why
we switched to EGL
Am 13.07.2016 11:48 schrieb "Daniel Vetter" :

On Wed, Jul 13, 2016 at 06:43:37PM +0900, Michel Dänzer wrote:
> On 13.07.2016 15:50, Rainer Hochecker wrote:
> > Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is
> > not an option anymore because we need EGL for vaapi. But we can fall
> > back to the invisible window for getting vsync. I never tried using EGL
> > and GLX in the same application, different windows. Any reason why this
> > should not work?
>
> An invisible window may not synchronize with the same output refresh
> cycle as your output window.

Why do you need EGL for libva? Besides that noob question from me, no idea
how well EGL/GLX can interop at all ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/899cfec0/attachment-0001.html>

Kernel stability on baytrail machines

[Michal Feix]

On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote:
>> Hi Alan,
>>
>> (Adding interested people to this thread)
>>
>> On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
> I do feel that the importance of the mentioned bug is currently
> underestimated. Can anyone here give a note, how much current linux
> kernel is supposed to be stable on general baytrail machines?
 If you did not get any replies... you might want to check MAINTAINERS 
 file, and
 put Intel x86 maintainers on Cc list.

 I'm sure someone cares :-).
>>> Yes we care, and there are people looking at the various reports.
>>>
>> Are there any updates on the status of this issue?
>>
>> The current bugzilla report [1] marks this as a power management
>> issue. However, many reports indicate that it would only freeze
>> when running X, so it's not completely clear if it's related to
>> the gfx driver too.
> Does
>
> "intel_idle.max_cstate=1"
>
> fix it for you?
Yes, it does.
> If you feel it is X-only problem, you may want to provide details
> about your graphics subsystem (DRM enabled? framebuffer only?) and
> probably cc.
It's not X-only problem. Happens even in console mode, which is KMS 
switched during boot though.
> ...actually... you may want to verify if it happens in unaccelerated X.
As it happens even in console mode, is this relevant test?

Michal

[PATCH 2/3] drm: fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Daniel Vetter]

On Wed, Jul 13, 2016 at 10:11:47AM +0200, Stefan Christ wrote:
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
> synchronize drawing or buffer flip for double buffering. It is tested on
> the i.MX6.
> 
> Code is based on
> 
> https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> 
> Signed-off-by: Stefan Christ 
> ---
>  drivers/gpu/drm/drm_fb_cma_helper.c |  1 +
>  drivers/gpu/drm/drm_fb_helper.c | 43 
> +
>  include/drm/drm_fb_helper.h |  2 ++
>  3 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index be66042..95657da 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -313,6 +313,7 @@ static struct fb_ops drm_fbdev_cma_ops = {
>   .fb_blank   = drm_fb_helper_blank,
>   .fb_pan_display = drm_fb_helper_pan_display,
>   .fb_setcmap = drm_fb_helper_setcmap,
> + .fb_ioctl   = drm_fb_helper_ioctl,
>  };
>  
>  static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 7c2eb75..4d1f9b9 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1167,6 +1167,49 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
> fb_info *info)
>  EXPORT_SYMBOL(drm_fb_helper_setcmap);
>  
>  /**
> + * drm_fb_helper_ioctl - legacy ioctl implementation
> + * @info:
> + * @cmd: ioctl like FBIO_WAITFORVSYNC
> + * @arg: ioctl argument

A bit more verbose kerneldoc would be great. Also, if you add this I think
we should roll it out for all drivers, for consistency of the supported
fbdev features when using emulation.
-Daniel

> + */
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
> long arg)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + unsigned int i;
> + int ret = 0;

You must first check whether fbdev owns the kms driver by calling
drm_fb_helper_is_bound(). Not sure whether the ioctl should fail, or
whether you instead should msleep(16) to throttle userspace a bit. Up to
you really.

> +
> + switch (cmd) {
> + case FBIO_WAITFORVSYNC:
> + for (i = 0; i < fb_helper->crtc_count; i++) {
> + struct drm_mode_set *mode_set;
> + struct drm_crtc *crtc;
> +
> + mode_set = _helper->crtc_info[i].mode_set;
> + crtc = mode_set->crtc;
> +
> + /*
> +  * Only call drm_crtc_wait_one_vblank for crtcs that
> +  * are currently active.
> +  */
> + if (!crtc->enabled)
> + continue;

crtc->enabled != crtc->active, and drm_crtc_vblank_get only works when the
crtc is active. This means this ioctl will fail if the display is
suspended using dpms off/FB_BLANK. Is that what you want?

> +
> + ret = drm_crtc_vblank_get(crtc);
> + if (!ret) {
> + drm_crtc_wait_one_vblank(crtc);
> + drm_crtc_vblank_put(crtc);
> + }

else
break;

Probably you also need some locking here, drm_modeset_lock(>mutex);
should be enough. Without that you might race with a dpms off. Might need
more locks, not entirely sure, perhaps also dev->mode_config.mutex for
fbdev emulation state.
-Daniel

> + }
> + return ret;
> + default:
> + return -ENOTTY;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_fb_helper_ioctl);
> +
> +/**
>   * drm_fb_helper_check_var - implementation for ->fb_check_var
>   * @var: screeninfo to check
>   * @info: fbdev registered by the helper
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 5b4aa35..121af93 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -278,6 +278,8 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
> *fb_helper, int state);
>  
>  int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>  
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
> long arg);
> +
>  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
>  int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int 
> bpp_sel);
>  int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software 

[PATCH 2/9] async: Introduce kfence, a N:M completion mechanism

[Chris Wilson]

On Wed, Jul 13, 2016 at 11:38:52AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 10:08:46AM +0100, Chris Wilson wrote:
> > diff --git a/kernel/async.c b/kernel/async.c
> > index d2edd6efec56..d0bcb7cc4884 100644
> > --- a/kernel/async.c
> > +++ b/kernel/async.c
> > @@ -50,6 +50,7 @@ asynchronous and synchronous parts of the kernel.
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> 
> So why does this live in async.c? It got its own header, why not also
> give it its own .c file?

I started in kernel/async (since my first goal was fine-grained
async_work serialisation). It is still in kernel/async.c as the embedded
fence inside the async_work needs a return code to integrate. I should
have done that before posting...

> Also, I'm not a particular fan of the k* naming, but I see 'fence' is
> already taken.

Agreed, I really want to rename the dma-buf fence to struct dma_fence -
we would need to do that whilst it dma-buf fencing is still in its infancy.

> > +/**
> > + * DOC: kfence overview
> > + *
> > + * kfences provide synchronisation barriers between multiple processes.
> > + * They are very similar to completions, or a pthread_barrier. Where
> > + * kfence differs from completions is their ability to track multiple
> > + * event sources rather than being a singular "completion event". Similar
> > + * to completions, multiple processes or other kfences can listen or wait
> > + * upon a kfence to signal its completion.
> > + *
> > + * The kfence is a one-shot flag, signaling that work has progressed passed
> > + * a certain point (as measured by completion of all events the kfence is
> > + * listening for) and the waiters upon kfence may proceed.
> > + *
> > + * kfences provide both signaling and waiting routines:
> > + *
> > + * kfence_pending()
> > + *
> > + * indicates that the kfence should itself wait for another signal. A
> > + * kfence created by kfence_create() starts in the pending state.
> 
> I would much prefer:
> 
>  *  - kfence_pending(): indicates that the kfence should itself wait for
>  *another signal. A kfence created by kfence_create() starts in the
>  *pending state.
> 
> Which is much clearer in what text belongs where.

Ok, I was just copying the style from
Documentation/scheduler/completion.txt

> Also, what !? I don't get what this function does.

Hmm. Something more like:

"To check the state of a kfence without changing it in any way, call
kfence_pending(), which returns true if the kfence is still waiting for
its event sources to be signaled."

s/signaled/completed/ depending on kfence_signal() vs kfence_complete()

> > + *
> > + * kfence_signal()
> > + *
> > + * undoes the earlier pending notification and allows the fence to complete
> > + * if all pending events have then been signaled.
> 
> So I know _signal() is the posix thing, but seeing how we already
> completions, how about being consistent with those and use _complete()
> for this?

Possibly, but we also have the dma-buf fences to try and be fairly
consistent with. struct completion is definitely a closer sibling
though. The biggest conceptual change from completions though is that a
kfence will be signaled multiple times before it is complete - I think
that is a strong argument in favour of using _signal().

> > + *
> > + * kfence_wait()
> > + *
> > + * allows the caller to sleep (uninterruptibly) until the fence is 
> > complete.
> 
> whitespace to separate the description of kfence_wait() from whatever
> else follows.
> 
> > + * Meanwhile,
> > + *
> > + * kfence_complete()
> > + *
> > + * reports whether or not the kfence has been passed.
> 
> kfence_done(), again to match completions.

Ok, will do a spin with completion naming convention and see how that
fits in (and complete the extraction to a separate .c)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 2/9] async: Introduce kfence, a N:M completion mechanism

[Peter Zijlstra]

On Fri, Jun 24, 2016 at 10:08:46AM +0100, Chris Wilson wrote:
> +struct kfence {
> + wait_queue_head_t wait;
> + unsigned long flags;
> + struct kref kref;
> + atomic_t pending;
> +};

> +#define KFENCE_CHECKED_BIT   0
> +
> +static void kfence_free(struct kref *kref)
> +{
> + struct kfence *fence = container_of(kref, typeof(*fence), kref);
> +
> + WARN_ON(atomic_read(>pending) > 0);
> +
> + kfree(fence);
> +}
> +
> +/**
> + * kfence_put - release a reference to a kfence
> + * @fence: the kfence being disposed of
> + */
> +void kfence_put(struct kfence *fence)
> +{
> + if (fence)
> + kref_put(>kref, kfence_free);

It seems very poor semantics to allow to put NULL, that would indicate a
severe logic fail.

> +}
> +EXPORT_SYMBOL_GPL(kfence_put);

> +/**
> + * kfence_get - acquire a reference to a kfence
> + * @fence: the kfence being used
> + *
> + * Returns the pointer to the kfence, with its reference count incremented.
> + */
> +struct kfence *kfence_get(struct kfence *fence)
> +{
> + if (fence)
> + kref_get(>kref);

Similar, getting NULL is just horrible taste.

> + return fence;
> +}
> +EXPORT_SYMBOL_GPL(kfence_get);


> +static void __kfence_wake_up_all(struct kfence *fence,
> +  struct list_head *continuation)
> +{
> + wait_queue_head_t *x = >wait;
> + unsigned long flags;
> +
> + /* To prevent unbounded recursion as we traverse the graph

Broken comment style.

> +  * of kfences, we move the task_list from this ready fence
> +  * to the tail of the current fence we are signaling.
> +  */
> + spin_lock_irqsave_nested(>lock, flags, 1 + !!continuation);
> + if (continuation)
> + list_splice_tail_init(>task_list, continuation);
> + else while (!list_empty(>task_list))
> + __wake_up_locked_key(x, TASK_NORMAL, >task_list);
> + spin_unlock_irqrestore(>lock, flags);
> +}
> +
> +static void __kfence_signal(struct kfence *fence,
> + struct list_head *continuation)
> +{
> + if (!atomic_dec_and_test(>pending))
> + return;
> +
> + atomic_dec(>pending);

You decrement twice?

> + __kfence_wake_up_all(fence, continuation);
> +}
> +
> +/**
> + * kfence_pending - mark the fence as pending a signal

I would say: increment the pending count, requiring one more completion
before the fence is done.

'Mark' completely misses the point. You need to balance these increments
with decrements, its not a boolean state.

> + * @fence: the kfence to be signaled
> + *
> + */
> +void kfence_pending(struct kfence *fence)
> +{
> + WARN_ON(atomic_inc_return(>pending) <= 1);
> +}
> +EXPORT_SYMBOL_GPL(kfence_pending);


> +/**
> + * kfence_create - create a fence
> + * @gfp: the allowed allocation type
> + *
> + * A fence is created with a reference count of one, and pending a signal.
> + * After you have completed setting up the fence for use, call 
> kfence_signal()
> + * to signal completion.
> + *
> + * Returns the newly allocated fence, or NULL on error.
> + */
> +struct kfence *kfence_create(gfp_t gfp)
> +{
> + struct kfence *fence;
> +
> + fence = kmalloc(sizeof(*fence), gfp);
> + if (!fence)
> + return NULL;
> +
> + kfence_init(fence);
> + return fence;
> +}
> +EXPORT_SYMBOL_GPL(kfence_create);

Why? What is the purpose of this here thing? We never provide allocation
wrappers.

> +
> +/**
> + * kfence_add - set one fence to wait upon another

Since you're going to do a whole lot other kfence_add_$foo() thingies,
why isn't this called kfence_add_kfence() ?

> + * @fence: this kfence
> + * @signaler: target kfence to wait upon
> + * @gfp: the allowed allocation type
> + *
> + * kfence_add() causes the @fence to wait upon completion of @signaler.
> + * Internally the @fence is marked as pending a signal from @signaler.
> + *
> + * Returns 1 if the @fence was added to the waiqueue of @signaler, 0
> + * if @signaler was already complete, or a negative error code.
> + */
> +int kfence_add(struct kfence *fence, struct kfence *signaler, gfp_t gfp)
> +{
> + wait_queue_t *wq;
> + unsigned long flags;
> + int pending;
> +
> + if (!signaler || kfence_complete(signaler))

Again, wth would you allow adding NULL? That's just horrible.

> + return 0;
> +
> + /* The dependency graph must be acyclic */
> + if (unlikely(kfence_check_if_after(fence, signaler)))
> + return -EINVAL;
> +
> + wq = kmalloc(sizeof(*wq), gfp);
> + if (unlikely(!wq)) {
> + if (!gfpflags_allow_blocking(gfp))
> + return -ENOMEM;
> +
> + kfence_wait(signaler);
> + return 0;
> + }
> +
> + wq->flags = 0;
> + wq->func = kfence_wake;
> + wq->private = kfence_get(fence);
> +
> + kfence_pending(fence);
> +
> + spin_lock_irqsave(>wait.lock, flags);
> + if (likely(!kfence_complete(signaler))) {
> + 

[PATCH][libdrm] drm: Fix multi GPU drmGetDevice return wrong device

[Yu, Qiang]

Hi Emil,


Nice to hear from you.

On 11 July 2016 at 06:17, Qiang Yu  wrote:
> drmGetDevice will always return the first device it find
> under /dev/dri/. This is not true for multi GPU situation.
>
How does the following alternative solution sound:
 - keep drmFoldDuplicatedDevices as is
 - after the drmFoldDuplicatedDevices call use the find_rdev to find
the correct device in local_devices.

[yuq] This is also OK. But drmFoldDuplicatedDevices() has to be changed for the
drmFreeDevices() in the error handling path: it also exit after see a NULL in 
the array.

> Plus fix the memory leak in error handling path of
> drmGetDevices.
>
Unless I'm missing something, there is no memory leak fix below ?
Alternatively please keep it as separate patch.

[yuq] This is fixed at the same time by changing drmFoldDuplicatedDevices().

> Change-Id: I2a85a8a4feba8a5cc517ad75c6afb532fa07c53d
Please drop this line.

[yuq] OK.

Regards,
Qiang
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/94117712/attachment-0001.html>

[patch] drm/msm: return -EFAULT instead of bytes remaining

[Dan Carpenter]

copy_to/from_user returns the number of bytes remaining to be copied but
we want to return -EFAULT.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/msm/msm_perf.c b/drivers/gpu/drm/msm/msm_perf.c
index 830857c..17fe4e5 100644
--- a/drivers/gpu/drm/msm/msm_perf.c
+++ b/drivers/gpu/drm/msm/msm_perf.c
@@ -132,7 +132,7 @@ static ssize_t perf_read(struct file *file, char __user 
*buf,
size_t sz, loff_t *ppos)
 {
struct msm_perf_state *perf = file->private_data;
-   int n = 0, ret;
+   int n = 0, ret = 0;

mutex_lock(>read_lock);

@@ -143,9 +143,10 @@ static ssize_t perf_read(struct file *file, char __user 
*buf,
}

n = min((int)sz, perf->buftot - perf->bufpos);
-   ret = copy_to_user(buf, >buf[perf->bufpos], n);
-   if (ret)
+   if (copy_to_user(buf, >buf[perf->bufpos], n)) {
+   ret = -EFAULT;
goto out;
+   }

perf->bufpos += n;
*ppos += n;
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 24254e0..3a5fdfc 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -149,9 +149,10 @@ static ssize_t rd_read(struct file *file, char __user *buf,
goto out;

n = min_t(int, sz, circ_count_to_end(>fifo));
-   ret = copy_to_user(buf, fptr, n);
-   if (ret)
+   if (copy_to_user(buf, fptr, n)) {
+   ret = -EFAULT;
goto out;
+   }

fifo->tail = (fifo->tail + n) & (BUF_SZ - 1);
*ppos += n;

[PATCH 5/9] async: Wrap hrtimer to provide a time source for a kfence

[Peter Zijlstra]

On Fri, Jun 24, 2016 at 10:08:49AM +0100, Chris Wilson wrote:
> kfence_add_delay() is a convenience wrapper around
> hrtimer_start_range_ns() to provide a time source for a kfence graph.

Changelog could be greatly improved by telling us why we'd want this.

[PATCH 3/9] async: Extend kfence to allow struct embedding

[Peter Zijlstra]

On Fri, Jun 24, 2016 at 10:08:47AM +0100, Chris Wilson wrote:
> @@ -151,7 +161,11 @@ static void kfence_free(struct kref *kref)
>  
>   WARN_ON(atomic_read(>pending) > 0);
>  
> - kfree(fence);
> + if (fence->flags) {
> + kfence_notify_t fn = (kfence_notify_t)fence->flags;

Maybe provide an inline helper for that conversion and also mask out the
low bits, just to be careful. You're assuming they're not set here,
which seems like a dangerous thing.

> + fn(fence);
> + } else
> + kfree(fence);

Also Codingstyle wants braces on both branches if its on one.

Kernel stability on baytrail machines

[Pavel Machek]

> On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote:
> >>Hi Alan,
> >>
> >>(Adding interested people to this thread)
> >>
> >>On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
> >I do feel that the importance of the mentioned bug is currently
> >underestimated. Can anyone here give a note, how much current linux
> >kernel is supposed to be stable on general baytrail machines?
> If you did not get any replies... you might want to check MAINTAINERS 
> file, and
> put Intel x86 maintainers on Cc list.
> 
> I'm sure someone cares :-).
> >>>Yes we care, and there are people looking at the various reports.
> >>>
> >>Are there any updates on the status of this issue?
> >>
> >>The current bugzilla report [1] marks this as a power management
> >>issue. However, many reports indicate that it would only freeze
> >>when running X, so it's not completely clear if it's related to
> >>the gfx driver too.
> >Does
> >
> >"intel_idle.max_cstate=1"
> >
> >fix it for you?
> Yes, it does.
> >If you feel it is X-only problem, you may want to provide details
> >about your graphics subsystem (DRM enabled? framebuffer only?) and
> >probably cc.
> It's not X-only problem. Happens even in console mode, which is KMS
> switched during boot though.
> >...actually... you may want to verify if it happens in unaccelerated X.
> As it happens even in console mode, is this relevant test?

No, no need to test with X.

Would it be possible to test in good old VGA mode?

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

[PATCH 24/27] drm: Resurrect atomic rmfb code

[Daniel Vetter]

On Wed, Jul 13, 2016 at 12:15:17PM +0200, Maarten Lankhorst wrote:
> Op 08-06-16 om 14:19 schreef Daniel Vetter:
> > This was somehow lost between v3 and the merged version in Maarten's
> > patch merged as:
> >
> > commit f2d580b9a8149735cbc4b59c4a8df60173658140
> > Author: Maarten Lankhorst 
> > Date:   Wed May 4 14:38:26 2016 +0200
> >
> > drm/core: Do not preserve framebuffer on rmfb, v4.
> >
> > Actual code copied from Maarten's patch, but with the slight change to
> > just use dev->mode_config.funcs->atomic_commit to decide whether to
> > use the atomic path or not.
> >
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 66 
> > +
> >  drivers/gpu/drm/drm_crtc.c  |  6 
> >  drivers/gpu/drm/drm_crtc_internal.h |  1 +
> >  3 files changed, 73 insertions(+)
> It passes the IGT kms_rmfb test, so I'm happy. :)
> 
> Reviewed-by: Maarten Lankhorst 

Applied to drm-misc, thanks for the review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/9] async: Introduce kfence, a N:M completion mechanism

[Daniel Vetter]

On Wed, Jul 13, 2016 at 11:20:14AM +0100, Chris Wilson wrote:
> On Wed, Jul 13, 2016 at 11:38:52AM +0200, Peter Zijlstra wrote:
> > Also, I'm not a particular fan of the k* naming, but I see 'fence' is
> > already taken.
> 
> Agreed, I really want to rename the dma-buf fence to struct dma_fence -
> we would need to do that whilst it dma-buf fencing is still in its infancy.

+1 on dma_fence, seems to make more sense than plain struct fence.
Probably best to do after the recent pile of work from Gustavo to de-stage
sync_file has landed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH][libdrm] drm: Fix multi GPU drmGetDevice return wrong device

[Emil Velikov]

On 13 July 2016 at 11:17, Yu, Qiang  wrote:
> Hi Emil,
>
>
> Nice to hear from you.
>
>
> On 11 July 2016 at 06:17, Qiang Yu  wrote:
>> drmGetDevice will always return the first device it find
>> under /dev/dri/. This is not true for multi GPU situation.
>>
> How does the following alternative solution sound:
>  - keep drmFoldDuplicatedDevices as is
>  - after the drmFoldDuplicatedDevices call use the find_rdev to find
> the correct device in local_devices.
>
> [yuq] This is also OK. But drmFoldDuplicatedDevices() has to be changed for
> the
> drmFreeDevices() in the error handling path: it also exit after see a NULL
> in the array.
>
>> Plus fix the memory leak in error handling path of
>> drmGetDevices.
>>
> Unless I'm missing something, there is no memory leak fix below ?
> Alternatively please keep it as separate patch.
>
> [yuq] This is fixed at the same time by changing drmFoldDuplicatedDevices().
>
Heh, silly me was assumed that your earlier patch fixed all the
codepaths to handle the "holes" made by drmFoldDuplicatedDevices.
Seems like the ones drmFreeDevices and drmGetDevice are still
outstanding, thus the predicament.

In this case we could do either:
 - go with the above making sure drmFoldDuplicatedDevices doesn't create 'holes'
Note: we still want to fix drmFreeDevices to continue (as opposed to
break) when it sees one.
 - or, fix drmGetDevice/drmFreeDevices

In either case we want that as separate patch, bonus points for adding
a inline comment about the behaviour of drmFoldDuplicatedDevices.

About the core issue a trivial suggestion - s/move target to the first
of local_devices/store target at local_devices[0] for ease to use
below/

Thanks
Emil
P.S. When working with mailing lists please use plain text emails.

[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad, saints row 4, grid autosport)

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

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

--- Comment #12 from Daniel T.  ---
Cheers for the thorough reply, before I try your debugging tips I will wait for
12.1(first bugfix release) to filter down to archlinux in hopes that mesa 12
fixes some of these already so I'm not wasting my time chasing bugs that are
already fixed. I'll update in a few weeks with new info. thanks

-- 
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/20160713/5b99d517/attachment.html>

[PATCH] clover: Pass unquoted compiler arguments to Clang

[Vedran Miletić]

OpenCL apps can quote arguments they pass to the OpenCL compiler, most
commonly include paths containing spaces.

If the Clang OpenCL compiler was called via a shell, the shell would
split the arguments with respect to to quotes and then remove quotes
before passing the arguments to the compiler. Since we call Clang as a
library, we have to split the argument with respect to quotes and then
remove quotes before passing the arguments.

v2: move to tokenize(), remove throwing of CL_INVALID_COMPILER_OPTIONS
---
 src/gallium/state_trackers/clover/llvm/util.hpp | 37 ++---
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/clover/llvm/util.hpp 
b/src/gallium/state_trackers/clover/llvm/util.hpp
index 8db6f20..c149542 100644
--- a/src/gallium/state_trackers/clover/llvm/util.hpp
+++ b/src/gallium/state_trackers/clover/llvm/util.hpp
@@ -42,11 +42,40 @@ namespace clover {
   inline std::vector
   tokenize(const std::string ) {
  std::vector ss;
- std::istringstream iss(s);
- std::string t;
+ std::ostringstream oss;

- while (getline(iss, t, ' '))
-ss.push_back(t);
+ // OpenCL programs can pass a single or double quoted argument, most
+ // frequently include path. This is useful so that the path containing
+ // spaces is treated as a single argument, but we should anyhow 
unquote
+ // quoted arguments before passing them to the compiler.
+ // We do not want to avoid using std::string::replace here, as include
+ // path can contain quotes in file names.
+ bool escape_next = false;
+ bool skip_space = false;
+ bool in_quote_double = false;
+ bool in_quote_single = false;
+ for (auto pos = std::begin(s); pos != std::end(s); ++pos) {
+if (escape_next) {
+   oss.put(*pos);
+   escape_next = false;
+} else if (*pos == '\\') {
+   escape_next = true;
+} else if (*pos == '"' && !in_quote_single) {
+   in_quote_double = !in_quote_double;
+   skip_space = !skip_space;
+} else if (*pos == '\'' && !in_quote_double) {
+   in_quote_single = !in_quote_single;
+   skip_space = !skip_space;
+} else if (*pos == ' ' && !skip_space && oss.tellp() > 0) {
+   ss.emplace_back(oss.str());
+   oss.str("");
+} else if (*pos != ' ' || skip_space) {
+   oss.put(*pos);
+}
+ }
+ if (oss.tellp() > 0) {
+ss.emplace_back(oss.str());
+ }

  return ss;
   }
-- 
2.7.4

[PATCH] clover: Pass unquoted compiler arguments to Clang

[Vedran Miletić]

On 07/13/2016 02:18 PM, Vedran Miletić wrote:
> OpenCL apps can quote arguments they pass to the OpenCL compiler, most
> commonly include paths containing spaces.
>
> If the Clang OpenCL compiler was called via a shell, the shell would
> split the arguments with respect to to quotes and then remove quotes
> before passing the arguments to the compiler. Since we call Clang as a
> library, we have to split the argument with respect to quotes and then
> remove quotes before passing the arguments.
>
> v2: move to tokenize(), remove throwing of CL_INVALID_COMPILER_OPTIONS
> ---
>  src/gallium/state_trackers/clover/llvm/util.hpp | 37 
> ++---
>  1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/util.hpp 
> b/src/gallium/state_trackers/clover/llvm/util.hpp
> index 8db6f20..c149542 100644
> --- a/src/gallium/state_trackers/clover/llvm/util.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/util.hpp
> @@ -42,11 +42,40 @@ namespace clover {
>inline std::vector
>tokenize(const std::string ) {
>   std::vector ss;
> - std::istringstream iss(s);
> - std::string t;
> + std::ostringstream oss;
>
> - while (getline(iss, t, ' '))
> -ss.push_back(t);
> + // OpenCL programs can pass a single or double quoted argument, most
> + // frequently include path. This is useful so that the path 
> containing
> + // spaces is treated as a single argument, but we should anyhow 
> unquote
> + // quoted arguments before passing them to the compiler.
> + // We do not want to avoid using std::string::replace here, as 
> include
> + // path can contain quotes in file names.
> + bool escape_next = false;
> + bool skip_space = false;
> + bool in_quote_double = false;
> + bool in_quote_single = false;
> + for (auto pos = std::begin(s); pos != std::end(s); ++pos) {
> +if (escape_next) {
> +   oss.put(*pos);
> +   escape_next = false;
> +} else if (*pos == '\\') {
> +   escape_next = true;
> +} else if (*pos == '"' && !in_quote_single) {
> +   in_quote_double = !in_quote_double;
> +   skip_space = !skip_space;
> +} else if (*pos == '\'' && !in_quote_double) {
> +   in_quote_single = !in_quote_single;
> +   skip_space = !skip_space;
> +} else if (*pos == ' ' && !skip_space && oss.tellp() > 0) {
> +   ss.emplace_back(oss.str());
> +   oss.str("");
> +} else if (*pos != ' ' || skip_space) {
> +   oss.put(*pos);
> +}
> + }
> + if (oss.tellp() > 0) {
> +ss.emplace_back(oss.str());
> + }
>
>   return ss;
>}
>

Apologies, wrongly sent e-mail.

Vedran

-- 
Vedran Miletić
vedran.miletic.net

[Beignet] [PATCH] intel: Export pooled EU and min no. of eus in a pool.

[Arun Siluvery]

On 06/07/2016 05:51, Yang Rong wrote:
> Update kernel interface with new I915_GETPARAM ioctl entries for
> pooled EU and min no. of eus in a pool. Add a wrapping function
> for each parameter. Userspace drivers need these values when decide
> the thread count. This kernel enabled pooled eu by default for BXT
> and for fused down 2x6 parts it is advised to turn it off.
>
> But there is another HW issue in these parts (fused
> down 2x6 parts) before C0 that requires Pooled EU to be enabled as a
> workaround. In this case the pool configuration changes depending upon
> which subslice is disabled and the no. of eus in a pool is different,
> So userspace need to know min no. of eus in a pool.
>
> Signed-off-by: Yang Rong 
> ---

Could you check this and give comments/ACK to merge this to libdrm?
Kernel changes are merged in drm-intel.

regards
Arun

>   include/drm/i915_drm.h   |  2 ++
>   intel/intel_bufmgr.h |  3 +++
>   intel/intel_bufmgr_gem.c | 32 
>   3 files changed, 37 insertions(+)
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index c4ce6b2..eb611a7 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -357,6 +357,8 @@ typedef struct drm_i915_irq_wait {
>   #define I915_PARAM_HAS_GPU_RESET 35
>   #define I915_PARAM_HAS_RESOURCE_STREAMER 36
>   #define I915_PARAM_HAS_EXEC_SOFTPIN  37
> +#define I915_PARAM_HAS_POOLED_EU 38
> +#define I915_PARAM_MIN_EU_IN_POOL39
>
>   typedef struct drm_i915_getparam {
>   __s32 param;
> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
> index a1abbcd..8370694 100644
> --- a/intel/intel_bufmgr.h
> +++ b/intel/intel_bufmgr.h
> @@ -273,6 +273,9 @@ int drm_intel_get_reset_stats(drm_intel_context *ctx,
>   int drm_intel_get_subslice_total(int fd, unsigned int *subslice_total);
>   int drm_intel_get_eu_total(int fd, unsigned int *eu_total);
>
> +int drm_intel_get_pooled_eu(int fd, unsigned int *has_pooled_eu);
> +int drm_intel_get_min_eu_in_pool(int fd, unsigned int *min_eu);
> +
>   /** @{ Compatibility defines to keep old code building despite the symbol 
> rename
>* from dri_* to drm_intel_*
>*/
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 0a4012b..b8bb654 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -3237,6 +3237,38 @@ drm_intel_get_eu_total(int fd, unsigned int *eu_total)
>   return 0;
>   }
>
> +int
> +drm_intel_get_pooled_eu(int fd, unsigned int *has_pooled_eu)
> +{
> + drm_i915_getparam_t gp;
> + int ret;
> +
> + memclear(gp);
> + gp.value = (int*)has_pooled_eu;
> + gp.param = I915_PARAM_HAS_POOLED_EU;
> + ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
> + if (ret)
> + return -errno;
> +
> + return 0;
> +}
> +
> +int
> +drm_intel_get_min_eu_in_pool(int fd, unsigned int *min_eu)
> +{
> + drm_i915_getparam_t gp;
> + int ret;
> +
> + memclear(gp);
> + gp.value = (int*)min_eu;
> + gp.param = I915_PARAM_MIN_EU_IN_POOL;
> + ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
> + if (ret)
> + return -errno;
> +
> + return 0;
> +}
> +
>   /**
>* Annotate the given bo for use in aub dumping.
>*
>

[PATCH] drm/nouveau/fbcon: fix deadlock with FBIOPUT_CON2FBMAP

[Peter Wu]

On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote:
> On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> > while nouveau was runtime suspended, a deadlock would occur due to
> > nouveau_fbcon_set_suspend also trying to obtain console_lock().
> > 
> > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the
> > i915 code (which was done for performance reasons though).
> > 
> > Cc: Chris Wilson 
> > Cc: Daniel Vetter 
> > Signed-off-by: Peter Wu 
> > ---
> > Tested on top of v4.7-rc5, the deadlock is gone.
> 
> If we bother with this, it should imo be moved into the drm_fb_helper.c
> function drm_fb_helper_set_suspend(). But this also smells like some kind
> of bad duct-tape. I think Lukas is working on some other rpm vs. fbdev
> deadlocks, maybe we could fix them all with one proper fix? I've made some
> comments on Lukas' last patch series.

This patch is only needed for drivers that use console_lock (for
drm_fb_helper_set_suspend) in their runtime resume functions.
Lukas posted fixes for runtime PM reference leaks, those are different
from this deadlock (see
https://lists.freedesktop.org/archives/dri-devel/2016-July/113005.html
for a backtrace for this issue).

The deadlock could also be avoided if the device backing the fbcon is
somehow runtime-resumed outside the lock, but that feels like a larger
hack that does not seem easy.

The i915 patch was done to reduce resume time (due to console_lock
contention), that feature seems useful to all other drivers too even if
the deadlock is fixed in a different way.

My current plan is to move stuff out of the lock and allow (just)
resuming the console to be delayed.  Some drivers (nouveau,
radeon/amdgpu, i915) do unnecessary stuff under the console lock:

 - nouveau: I *think* that cleraing/setting FBINFO_HWACCEL_DISABLED
   (nouveau_fbcon_accel_restore) is safe outside the lock as the fb is
   already suspended before clearing/after setting the flag.
 - radeon: since the console is suspended, I don't think that that all
   of the code is radeon_resume_kms is really needed.
 - amdgpu: same as radeon. Btw, console_lock is leaked on an error path.
 - i915: I think that clearing the fb memory can be done outside the
   lock too as the console is suspended.

Please correct me if my assumptions are flawed.

> Besides this, when fixing a deadlock pls provide more details about the
> precise callchain and the locks involved in the deadlock. If you
> discovered this using lockdep, then just add the entire lockdep splat to
> the commit message. Otherwise there's lots of guesswork involved here.
> -Daniel

There was no lockdep splat, it was triggered via the ioctl in the commit
message. I'll include the verbose trace from the previous mail in the
next proposed patch to reduce hunting though.

Peter

> > ---
> >  drivers/gpu/drm/nouveau/nouveau_drm.c   |  4 +--
> >  drivers/gpu/drm/nouveau/nouveau_drv.h   |  1 +
> >  drivers/gpu/drm/nouveau/nouveau_fbcon.c | 54 
> > -
> >  drivers/gpu/drm/nouveau/nouveau_fbcon.h |  2 +-
> >  4 files changed, 50 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> > b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > index 11f8dd9..f9a2c10 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > @@ -552,7 +552,7 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
> >  
> > if (dev->mode_config.num_crtc) {
> > NV_INFO(drm, "suspending console...\n");
> > -   nouveau_fbcon_set_suspend(dev, 1);
> > +   nouveau_fbcon_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
> > NV_INFO(drm, "suspending display...\n");
> > ret = nouveau_display_suspend(dev, runtime);
> > if (ret)
> > @@ -635,7 +635,7 @@ nouveau_do_resume(struct drm_device *dev, bool runtime)
> > NV_INFO(drm, "resuming display...\n");
> > nouveau_display_resume(dev, runtime);
> > NV_INFO(drm, "resuming console...\n");
> > -   nouveau_fbcon_set_suspend(dev, 0);
> > +   nouveau_fbcon_set_suspend(dev, FBINFO_STATE_RUNNING, false);
> > }
> >  
> > return 0;
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> > b/drivers/gpu/drm/nouveau/nouveau_drv.h
> > index 822a021..a743d19 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> > @@ -147,6 +147,7 @@ struct nouveau_drm {
> > struct nouveau_channel *channel;
> > struct nvkm_gpuobj *notify;
> > struct nouveau_fbdev *fbcon;
> > +   struct work_struct fbdev_suspend_work;
> > struct nvif_object nvsw;
> > struct nvif_object ntfy;
> > struct nvif_notify flip;
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> > index d1f248f..089156a 100644
> > --- 

[PATCH -next] drm: atmel-hlcdc: fix non static symbol warning

[weiyj...@163.com]

From: Wei Yongjun 

Fixes the following sparse warning:

drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:390:6: warning:
 symbol 'atmel_hlcdc_crtc_reset' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index a978381..9b17a66 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -387,7 +387,7 @@ void atmel_hlcdc_crtc_irq(struct drm_crtc *c)
atmel_hlcdc_crtc_finish_page_flip(drm_crtc_to_atmel_hlcdc_crtc(c));
 }

-void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
+static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
 {
struct atmel_hlcdc_crtc_state *state;

[patch] drm/msm: return -EFAULT instead of bytes remaining

[Rob Clark]

On Wed, Jul 13, 2016 at 6:35 AM, Dan Carpenter  
wrote:
> copy_to/from_user returns the number of bytes remaining to be copied but
> we want to return -EFAULT.
>
> Signed-off-by: Dan Carpenter 

thanks, I've added to msm-next

BR,
-R

>
> diff --git a/drivers/gpu/drm/msm/msm_perf.c b/drivers/gpu/drm/msm/msm_perf.c
> index 830857c..17fe4e5 100644
> --- a/drivers/gpu/drm/msm/msm_perf.c
> +++ b/drivers/gpu/drm/msm/msm_perf.c
> @@ -132,7 +132,7 @@ static ssize_t perf_read(struct file *file, char __user 
> *buf,
> size_t sz, loff_t *ppos)
>  {
> struct msm_perf_state *perf = file->private_data;
> -   int n = 0, ret;
> +   int n = 0, ret = 0;
>
> mutex_lock(>read_lock);
>
> @@ -143,9 +143,10 @@ static ssize_t perf_read(struct file *file, char __user 
> *buf,
> }
>
> n = min((int)sz, perf->buftot - perf->bufpos);
> -   ret = copy_to_user(buf, >buf[perf->bufpos], n);
> -   if (ret)
> +   if (copy_to_user(buf, >buf[perf->bufpos], n)) {
> +   ret = -EFAULT;
> goto out;
> +   }
>
> perf->bufpos += n;
> *ppos += n;
> diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
> index 24254e0..3a5fdfc 100644
> --- a/drivers/gpu/drm/msm/msm_rd.c
> +++ b/drivers/gpu/drm/msm/msm_rd.c
> @@ -149,9 +149,10 @@ static ssize_t rd_read(struct file *file, char __user 
> *buf,
> goto out;
>
> n = min_t(int, sz, circ_count_to_end(>fifo));
> -   ret = copy_to_user(buf, fptr, n);
> -   if (ret)
> +   if (copy_to_user(buf, fptr, n)) {
> +   ret = -EFAULT;
> goto out;
> +   }
>
> fifo->tail = (fifo->tail + n) & (BUF_SZ - 1);
> *ppos += n;

[PATCH -next] drm: atmel-hlcdc: fix non static symbol warning

[Boris Brezillon]

On Wed, 13 Jul 2016 12:43:03 +
weiyj_lk at 163.com wrote:

> From: Wei Yongjun 
> 
> Fixes the following sparse warning:
> 
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:390:6: warning:
>  symbol 'atmel_hlcdc_crtc_reset' was not declared. Should it be static?

Sorry but Thierry already proposed the same fix a few days ago.

> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index a978381..9b17a66 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -387,7 +387,7 @@ void atmel_hlcdc_crtc_irq(struct drm_crtc *c)
>   atmel_hlcdc_crtc_finish_page_flip(drm_crtc_to_atmel_hlcdc_crtc(c));
>  }
>  
> -void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
> +static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
>  {
>   struct atmel_hlcdc_crtc_state *state;
>  
> 
> 
> 
> 

[PATCH 2/4] drm/msm/hdmi: Use more DT friendly GPIO names

[Rob Herring]

On Fri, Jul 08, 2016 at 11:25:52AM +0530, Archit Taneja wrote:
> Update the gpio name parsing code to try to search for without the
> "qcom,hdmi-tx-" prefix. The older downstream bindings that expect
> "qcom,hdmi-tx-xyz" or "qcom,hdmi-tx-xyz-gpio" would work as the
> property name would work as before.

Why?

> Update the binding doc. Add an entry for the missing hpd and lpm
> gpios.
> 
> Cc: Rob Herring 
> Cc: devicetree at vger.kernel.org
> 
> Signed-off-by: Archit Taneja 
> ---
>  Documentation/devicetree/bindings/display/msm/hdmi.txt |  6 --
>  drivers/gpu/drm/msm/hdmi/hdmi.c| 16 
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt 
> b/Documentation/devicetree/bindings/display/msm/hdmi.txt
> index b63f614..4da1abd 100644
> --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt
> @@ -23,8 +23,10 @@ Required properties:
>  - 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-gpio: hdmi hpd pin

hpd-gpios is the somewhat standard name.

> +- mux-en-gpio: hdmi mux enable pin
> +- mux-sel-gpio: hdmi mux select pin
> +- mux-lpm-gpio: hdmi mux lpm pin

These look pretty QCom specific and should keep the vendor prefix.

I understand why you don't have '-gpios', but if we change these they 
should use the preferred form.

Rob

[PATCH 1/7] dt-bindings: add rk3399 support for dw-mipi-rockchip

[Rob Herring]

On Fri, Jul 08, 2016 at 05:04:55PM +0800, Chris Zhong wrote:
> The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has
> additional phy config clock.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
>  .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt| 5 
> +
>  1 file changed, 5 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> index 1753f0c..4d59df3 100644
> --- 
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> @@ -5,6 +5,7 @@ Required properties:
>  - #address-cells: Should be <1>.
>  - #size-cells: Should be <0>.
>  - compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
> +   "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi".
>  - reg: Represent the physical address range of the controller.
>  - interrupts: Represent the controller's interrupt to the CPU(s).
>  - clocks, clock-names: Phandles to the controller's pll reference
> @@ -13,6 +14,10 @@ Required properties:
>  - ports: contain a port node with endpoint definitions as defined in [2].
>For vopb,set the reg = <0> and set the reg = <1> for vopl.
>  
> +Optional properties:
> +- clocks, clock-names: phandle to the dw-mipi phy clock, name should be
> +"phy_cfg".
> +

This is not really optional. It is required for rk3399. Document with 
the rest of the clocks and note this one is rk3399 only.

Rob

[PATCH 3/7] dt-bindings: add power domain node for dw-mipi-rockchip

[Rob Herring]

On Fri, Jul 08, 2016 at 05:04:57PM +0800, Chris Zhong wrote:
> Signed-off-by: Chris Zhong 
> ---
> 
>  .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt| 1 
> +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

[v5 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Sean Paul]

On Tue, Jul 12, 2016 at 8:09 AM, Chris Zhong  wrote:
> Add support for cdn DP controller which is embedded in the rk3399
> SoCs. The DP is compliant with DisplayPort Specification,
> Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
> There is a uCPU in DP controller, it need a firmware to work,
> please put the firmware file to /lib/firmware/cdn/dptx.bin. The
> uCPU in charge of aux communication and link training, the host use
> mailbox to communicate with the ucpu.
> The dclk pin_pol of vop must not be invert for DP.
>
> Signed-off-by: Chris Zhong 
>
> ---
>
> Changes in v5:
> - alphabetical order
> - do not use long, use u32 or u64
> - return MODE_CLOCK_HIGH when requested > actual
> - Optimized Coding Style
> - add a formula to get better tu size and symbol value.
>
> Changes in v4:
> - use phy framework to control DP phy
> - support 2 phys
>
> Changes in v3:
> - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
> - reset spdif before config it
> - modify the firmware clk to 100Mhz
> - retry load firmware if fw file is requested too early
>
> Changes in v2:
> - Alphabetic order
> - remove excess error message
> - use define clk_rate
> - check all return value
> - remove dev_set_name(dp->dev, "cdn-dp");
> - use schedule_delayed_work
> - remove never-called functions
> - remove some unnecessary ()
>
> Changes in v1:
> - use extcon API
> - use hdmi-codec for the DP Asoc
> - do not initialize the "ret"
> - printk a err log when drm_of_encoder_active_endpoint_id
> - modify the dclk pin_pol to a single line
>
>  drivers/gpu/drm/rockchip/Kconfig|   9 +
>  drivers/gpu/drm/rockchip/Makefile   |   1 +
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  | 761 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  | 113 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 740 +++
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 409 +++

Could you explain the file naming convention in the rk driver? We've
got analogix_dp-rockchip.c, dw_hdmi-rockchip.c, dw-mipi-dsi.c, and now
cdn-dp-(core|reg).[ch]. I'm honestly not sure whether these filenames
are consistent with the rest, but bleh.


>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
>  9 files changed, 2042 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index d30bdc3..20da9a8 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
>   for the Analogix Core DP driver. If you want to enable DP
>   on RK3288 based SoC, you should selet this option.
>
> +config ROCKCHIP_CDN_DP
> +tristate "Rockchip cdn DP"
> +depends on DRM_ROCKCHIP
> +help
> + This selects support for Rockchip SoC specific extensions
> + for the cdn Dp driver. If you want to enable Dp on

s/Dp/DP/

> + RK3399 based SoC, you should selet this

s/selet/select/

> + option.
> +
>  config ROCKCHIP_DW_HDMI
>  tristate "Rockchip specific extensions for Synopsys DW HDMI"
>  depends on DRM_ROCKCHIP
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index 05d0713..abdecd5 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>
>  obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
>  obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> new file mode 100644
> index 000..5b8a15e
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -0,0 +1,761 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more 

[RFC] dma-buf: Rename struct fence to dma_fence

[Chris Wilson]

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.

As an indication of the scale of the flag day:

 91 files changed, 904 insertions(+), 880 deletions(-)

with the greatest victim being amdgpu.

Just the highlights shown below.
-Chris

---
 drivers/base/Kconfig|   6 +-
 drivers/dma-buf/Makefile|   2 +-
 drivers/dma-buf/dma-buf.c   |  28 +-
 drivers/dma-buf/dma-fence.c | 535 
 drivers/dma-buf/fence.c | 532 ---
 drivers/dma-buf/reservation.c   |  90 ++--
 drivers/dma-buf/seqno-fence.c   |  18 +-
 drivers/dma-buf/sw_sync.c   |  44 +-
 drivers/dma-buf/sync_debug.c|   9 +-
 drivers/dma-buf/sync_debug.h|  13 +-
 drivers/dma-buf/sync_file.c |  30 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  56 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c   |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  18 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c   |  50 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  18 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  |  24 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c|  56 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c|  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h   |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |  18 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c |  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  56 +--
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c   |   8 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |   8 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  16 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c   |   6 +-
 drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h |   4 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c   |  42 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h   |  24 +-
 drivers/gpu/drm/amd/scheduler/sched_fence.c |  22 +-
 drivers/gpu/drm/drm_atomic_helper.c |   6 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   |   6 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c   |  46 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |   4 +-
 drivers/gpu/drm/imx/ipuv3-crtc.c|  12 +-
 drivers/gpu/drm/msm/msm_drv.h   |   2 +-
 drivers/gpu/drm/msm/msm_fence.c |  30 +-
 drivers/gpu/drm/msm/msm_fence.h |   2 +-
 drivers/gpu/drm/msm/msm_gem.c   |  14 +-
 drivers/gpu/drm/msm/msm_gem.h   |   2 +-
 drivers/gpu/drm/msm/msm_gem_submit.c|   2 +-
 drivers/gpu/drm/msm/msm_gpu.c   |   2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c|   6 +-
 drivers/gpu/drm/nouveau/nouveau_fence.c |  68 +--
 drivers/gpu/drm/nouveau/nouveau_fence.h |   6 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c   |   2 +-
 drivers/gpu/drm/nouveau/nv04_fence.c|   2 +-
 drivers/gpu/drm/nouveau/nv10_fence.c|   2 +-
 drivers/gpu/drm/nouveau/nv17_fence.c|   2 +-
 drivers/gpu/drm/nouveau/nv50_fence.c|   2 +-
 drivers/gpu/drm/nouveau/nv84_fence.c|   2 +-
 drivers/gpu/drm/qxl/qxl_drv.h   |   4 +-
 drivers/gpu/drm/qxl/qxl_release.c   |  27 +-
 drivers/gpu/drm/radeon/radeon.h |  10 +-
 drivers/gpu/drm/radeon/radeon_device.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_display.c |   8 +-
 drivers/gpu/drm/radeon/radeon_fence.c   |  50 +--
 drivers/gpu/drm/radeon/radeon_sync.c|   6 +-
 drivers/gpu/drm/radeon/radeon_uvd.c |   2 +-
 drivers/gpu/drm/ttm/ttm_bo.c|  24 +-
 drivers/gpu/drm/ttm/ttm_bo_util.c   |   2 +-
 drivers/gpu/drm/ttm/ttm_execbuf_util.c  |   3 +-
 drivers/gpu/drm/virtio/virtgpu_display.c|   2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.h|   2 +-
 drivers/gpu/drm/virtio/virtgpu_fence.c  |  22 +-
 

[RFC] dma-buf: Rename struct fence to dma_fence

[Daniel Vetter]

On Wed, Jul 13, 2016 at 03:10:45PM +0100, Chris Wilson wrote:
> I plan to usurp the short name of struct fence for a core kernel struct,
> and so I need to rename the specialised fence/timeline for DMA
> operations to make room.
>
> As an indication of the scale of the flag day:
>
>  91 files changed, 904 insertions(+), 880 deletions(-)
>
> with the greatest victim being amdgpu.
>
> Just the highlights shown below.

+1 on dma_fence, for more consistency with dma_buf and everything else
dma_*. I think if we land this right before/after 4.8-rc1 through the drm
tree it should be minimally invasive. Worst case we'll have a fun merge
between drm.git and drm-intel.git (since drm-intel-next-queued doesn't get
closed while the merge window is open).

Adding lots more people to gather their opinion.
-Daniel

> -Chris
>
> ---
>  drivers/base/Kconfig|   6 +-
>  drivers/dma-buf/Makefile|   2 +-
>  drivers/dma-buf/dma-buf.c   |  28 +-
>  drivers/dma-buf/dma-fence.c | 535 
> 
>  drivers/dma-buf/fence.c | 532 ---
>  drivers/dma-buf/reservation.c   |  90 ++--
>  drivers/dma-buf/seqno-fence.c   |  18 +-
>  drivers/dma-buf/sw_sync.c   |  44 +-
>  drivers/dma-buf/sync_debug.c|   9 +-
>  drivers/dma-buf/sync_debug.h|  13 +-
>  drivers/dma-buf/sync_file.c |  30 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  56 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c   |  50 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  |  10 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  |  24 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c|  56 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c|  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h   |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c |  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  56 +--
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  16 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c   |   6 +-
>  drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h |   4 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c   |  42 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.h   |  24 +-
>  drivers/gpu/drm/amd/scheduler/sched_fence.c |  22 +-
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c   |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c   |  46 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |   4 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c|  12 +-
>  drivers/gpu/drm/msm/msm_drv.h   |   2 +-
>  drivers/gpu/drm/msm/msm_fence.c |  30 +-
>  drivers/gpu/drm/msm/msm_fence.h |   2 +-
>  drivers/gpu/drm/msm/msm_gem.c   |  14 +-
>  drivers/gpu/drm/msm/msm_gem.h   |   2 +-
>  drivers/gpu/drm/msm/msm_gem_submit.c|   2 +-
>  drivers/gpu/drm/msm/msm_gpu.c   |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c|   6 +-
>  drivers/gpu/drm/nouveau/nouveau_fence.c |  68 +--
>  drivers/gpu/drm/nouveau/nouveau_fence.h |   6 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c   |   2 +-
>  drivers/gpu/drm/nouveau/nv04_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv10_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv17_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv50_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv84_fence.c|   2 +-
>  drivers/gpu/drm/qxl/qxl_drv.h   |   4 +-
>  drivers/gpu/drm/qxl/qxl_release.c   |  27 +-
>  drivers/gpu/drm/radeon/radeon.h |  10 +-
>  

[PATCH] drm/nouveau/fbcon: fix deadlock with FBIOPUT_CON2FBMAP

[Daniel Vetter]

On Wed, Jul 13, 2016 at 02:40:50PM +0200, Peter Wu wrote:
> On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> > > while nouveau was runtime suspended, a deadlock would occur due to
> > > nouveau_fbcon_set_suspend also trying to obtain console_lock().
> > > 
> > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the
> > > i915 code (which was done for performance reasons though).
> > > 
> > > Cc: Chris Wilson 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Peter Wu 
> > > ---
> > > Tested on top of v4.7-rc5, the deadlock is gone.
> > 
> > If we bother with this, it should imo be moved into the drm_fb_helper.c
> > function drm_fb_helper_set_suspend(). But this also smells like some kind
> > of bad duct-tape. I think Lukas is working on some other rpm vs. fbdev
> > deadlocks, maybe we could fix them all with one proper fix? I've made some
> > comments on Lukas' last patch series.
> 
> This patch is only needed for drivers that use console_lock (for
> drm_fb_helper_set_suspend) in their runtime resume functions.
> Lukas posted fixes for runtime PM reference leaks, those are different
> from this deadlock (see
> https://lists.freedesktop.org/archives/dri-devel/2016-July/113005.html
> for a backtrace for this issue).
> 
> The deadlock could also be avoided if the device backing the fbcon is
> somehow runtime-resumed outside the lock, but that feels like a larger
> hack that does not seem easy.
> 
> The i915 patch was done to reduce resume time (due to console_lock
> contention), that feature seems useful to all other drivers too even if
> the deadlock is fixed in a different way.

I might have imagined something, but I thought Lukas is already working on
some rpm vs. vga_switcheroo inversions. But looking again this was on the
audio side.

I think the proper solution for fbcon would be for the fbdev emulation to
also hold a runtime pm references when the console is in use. This should
already happen correctly for vblank, the more tricky part is fbdev mmap
and fbcon:

- I have no idea, but there should be a way to intercept fbdev userspace
  mmaps and make sure that as long as an app has the fbdev mmapped we
  don't runtime suspend. No one really should be doing that (at least for
  normal setups), hence this shouldn't result in unsafe.

- For fbcon, we could suspend it in the dpms off callbacks (maybe with a
  timer), and resume it only when enabling fbcon again - fbcon needs to
  redraw anyway on dpms on.

  Another solution for fbcon might be to untangle the suspend/resume stuff
  and protect it by something else than console_lock. But that means
  fixing up fbcon locking horror shows.

> My current plan is to move stuff out of the lock and allow (just)
> resuming the console to be delayed.  Some drivers (nouveau,
> radeon/amdgpu, i915) do unnecessary stuff under the console lock:
> 
>  - nouveau: I *think* that cleraing/setting FBINFO_HWACCEL_DISABLED
>(nouveau_fbcon_accel_restore) is safe outside the lock as the fb is
>already suspended before clearing/after setting the flag.
>  - radeon: since the console is suspended, I don't think that that all
>of the code is radeon_resume_kms is really needed.
>  - amdgpu: same as radeon. Btw, console_lock is leaked on an error path.
>  - i915: I think that clearing the fb memory can be done outside the
>lock too as the console is suspended.
> 
> Please correct me if my assumptions are flawed.

Yeah, fixing this independent issues should definitely help, irrespective
of how we fix fb_set_suspend.

> > Besides this, when fixing a deadlock pls provide more details about the
> > precise callchain and the locks involved in the deadlock. If you
> > discovered this using lockdep, then just add the entire lockdep splat to
> > the commit message. Otherwise there's lots of guesswork involved here.
> > -Daniel
> 
> There was no lockdep splat, it was triggered via the ioctl in the commit
> message. I'll include the verbose trace from the previous mail in the
> next proposed patch to reduce hunting though.

Sounds good too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC] dma-buf: Rename struct fence to dma_fence

[Emil Velikov]

On 13 July 2016 at 15:10, Chris Wilson  wrote:
> I plan to usurp the short name of struct fence for a core kernel struct,
> and so I need to rename the specialised fence/timeline for DMA
> operations to make room.
>
> As an indication of the scale of the flag day:
>
>  91 files changed, 904 insertions(+), 880 deletions(-)
>
> with the greatest victim being amdgpu.
>
> Just the highlights shown below.
> -Chris
>
> ---
>  drivers/base/Kconfig|   6 +-
>  drivers/dma-buf/Makefile|   2 +-
>  drivers/dma-buf/dma-buf.c   |  28 +-
>  drivers/dma-buf/dma-fence.c | 535 
> 
>  drivers/dma-buf/fence.c | 532 ---
>  drivers/dma-buf/reservation.c   |  90 ++--
>  drivers/dma-buf/seqno-fence.c   |  18 +-
>  drivers/dma-buf/sw_sync.c   |  44 +-
>  drivers/dma-buf/sync_debug.c|   9 +-
>  drivers/dma-buf/sync_debug.h|  13 +-
>  drivers/dma-buf/sync_file.c |  30 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  56 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c   |  50 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  |  10 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  |  24 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c|  56 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c|  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h   |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c |  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  56 +--
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  16 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c   |   6 +-
>  drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h |   4 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c   |  42 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.h   |  24 +-
>  drivers/gpu/drm/amd/scheduler/sched_fence.c |  22 +-
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c   |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c   |  46 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |   4 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c|  12 +-
>  drivers/gpu/drm/msm/msm_drv.h   |   2 +-
>  drivers/gpu/drm/msm/msm_fence.c |  30 +-
>  drivers/gpu/drm/msm/msm_fence.h |   2 +-
>  drivers/gpu/drm/msm/msm_gem.c   |  14 +-
>  drivers/gpu/drm/msm/msm_gem.h   |   2 +-
>  drivers/gpu/drm/msm/msm_gem_submit.c|   2 +-
>  drivers/gpu/drm/msm/msm_gpu.c   |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c|   6 +-
>  drivers/gpu/drm/nouveau/nouveau_fence.c |  68 +--
>  drivers/gpu/drm/nouveau/nouveau_fence.h |   6 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c   |   2 +-
>  drivers/gpu/drm/nouveau/nv04_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv10_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv17_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv50_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv84_fence.c|   2 +-
>  drivers/gpu/drm/qxl/qxl_drv.h   |   4 +-
>  drivers/gpu/drm/qxl/qxl_release.c   |  27 +-
>  drivers/gpu/drm/radeon/radeon.h |  10 +-
>  drivers/gpu/drm/radeon/radeon_device.c  |   2 +-
>  drivers/gpu/drm/radeon/radeon_display.c |   8 +-
>  drivers/gpu/drm/radeon/radeon_fence.c   |  50 +--
>  drivers/gpu/drm/radeon/radeon_sync.c|   6 +-
>  drivers/gpu/drm/radeon/radeon_uvd.c |   2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c|  24 +-
>  drivers/gpu/drm/ttm/ttm_bo_util.c   |   2 +-
>  

[RFC] dma-buf: Rename struct fence to dma_fence

[Chris Wilson]

On Wed, Jul 13, 2016 at 11:54:50PM +0900, Inki Dae wrote:
> Hi,
> 
> 2016-07-13 23:10 GMT+09:00 Chris Wilson :
> > I plan to usurp the short name of struct fence for a core kernel struct,
> > and so I need to rename the specialised fence/timeline for DMA
> > operations to make room.
> >
> > As an indication of the scale of the flag day:
> >
> >  91 files changed, 904 insertions(+), 880 deletions(-)
> 
> Seems files changed and below patch codes are not inconsistent. i.e.,
> I cannot see modified codes for Android sync driver.

The cut'n'paste doesn't include the renames which the patch below does
(i..e. it should be a more accurate representation of lines changed by
ignoring the lines moved).

> And Android sync driver - explicit fence - can use a fence object
> regardless of DMA buffer. So it looks reasonable to use 'fence' as-is.
> Was there any changes for Android sync driver to be dependent on DMA buffer?

This was based on Gustova Padovan's destaged sync tree, so all the
Android changes should be inside drivers/dma-buf/*sync*

I was using grep to find all users of struct fence and callers of
fence_*() so I don't think I missed any drivers/staging/ - and obviously
this will have to repeated closer to the flag day.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[RFC] dma-buf: Rename struct fence to dma_fence

[Sumit Semwal]

On 13 July 2016 at 20:16, Daniel Vetter  wrote:
> On Wed, Jul 13, 2016 at 03:10:45PM +0100, Chris Wilson wrote:
>> I plan to usurp the short name of struct fence for a core kernel struct,
>> and so I need to rename the specialised fence/timeline for DMA
>> operations to make room.
>>
>> As an indication of the scale of the flag day:
>>
>>  91 files changed, 904 insertions(+), 880 deletions(-)
>>
>> with the greatest victim being amdgpu.
>>
>> Just the highlights shown below.
>
> +1 on dma_fence, for more consistency with dma_buf and everything else
> dma_*. I think if we land this right before/after 4.8-rc1 through the drm
> tree it should be minimally invasive. Worst case we'll have a fun merge
> between drm.git and drm-intel.git (since drm-intel-next-queued doesn't get
> closed while the merge window is open).
>
+1 on the merge idea, Daniel.
> Adding lots more people to gather their opinion.
> -Daniel
>
>> -Chris
>>
>> ---
>>  drivers/base/Kconfig|   6 +-
>>  drivers/dma-buf/Makefile|   2 +-
>>  drivers/dma-buf/dma-buf.c   |  28 +-
>>  drivers/dma-buf/dma-fence.c | 535 
>> 
>>  drivers/dma-buf/fence.c | 532 
>> ---
>>  drivers/dma-buf/reservation.c   |  90 ++--
>>  drivers/dma-buf/seqno-fence.c   |  18 +-
>>  drivers/dma-buf/sw_sync.c   |  44 +-
>>  drivers/dma-buf/sync_debug.c|   9 +-
>>  drivers/dma-buf/sync_debug.h|  13 +-
>>  drivers/dma-buf/sync_file.c |  30 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  56 +--
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c   |   8 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  18 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |  22 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   2 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  16 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c   |  50 +--
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  |  10 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  18 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   2 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |   4 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  |  24 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c|  56 +--
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c|  12 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h   |   4 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   6 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |  18 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h |   4 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c |  22 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h |   4 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  56 +--
>>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c   |   8 +-
>>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |   8 +-
>>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  16 +-
>>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c  |   8 +-
>>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |   8 +-
>>  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c   |   6 +-
>>  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c   |   6 +-
>>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c   |   6 +-
>>  drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h |   4 +-
>>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c   |  42 +-
>>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.h   |  24 +-
>>  drivers/gpu/drm/amd/scheduler/sched_fence.c |  22 +-
>>  drivers/gpu/drm/drm_atomic_helper.c |   6 +-
>>  drivers/gpu/drm/etnaviv/etnaviv_gem.c   |   6 +-
>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c   |  46 +-
>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |   4 +-
>>  drivers/gpu/drm/imx/ipuv3-crtc.c|  12 +-
>>  drivers/gpu/drm/msm/msm_drv.h   |   2 +-
>>  drivers/gpu/drm/msm/msm_fence.c |  30 +-
>>  drivers/gpu/drm/msm/msm_fence.h |   2 +-
>>  drivers/gpu/drm/msm/msm_gem.c   |  14 +-
>>  drivers/gpu/drm/msm/msm_gem.h   |   2 +-
>>  drivers/gpu/drm/msm/msm_gem_submit.c|   2 +-
>>  drivers/gpu/drm/msm/msm_gpu.c   |   2 +-
>>  drivers/gpu/drm/nouveau/nouveau_bo.c|   6 +-
>>  drivers/gpu/drm/nouveau/nouveau_fence.c |  68 +--
>>  drivers/gpu/drm/nouveau/nouveau_fence.h |   6 +-
>>  drivers/gpu/drm/nouveau/nouveau_gem.c   |   2 +-
>>  drivers/gpu/drm/nouveau/nv04_fence.c|   2 +-
>>  drivers/gpu/drm/nouveau/nv10_fence.c|   2 +-
>>  drivers/gpu/drm/nouveau/nv17_fence.c|   2 +-
>>  drivers/gpu/drm/nouveau/nv50_fence.c|   2 +-
>>  drivers/gpu/drm/nouveau/nv84_fence.c|   2 +-
>>  drivers/gpu/drm/qxl/qxl_drv.h

[patch] drm/rockchip: fix a couple off by one bugs

[Sean Paul]

On Wed, Jul 13, 2016 at 3:15 AM, Dan Carpenter  
wrote:
> The priv->crtc_funcs[] array has ROCKCHIP_MAX_CRTC elements so > should
> be >= here.
>
> Fixes: 2048e3286f34 ('drm: rockchip: Add basic drm driver')
> Signed-off-by: Dan Carpenter 
>

Reviewed-by: Sean Paul 

> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 7fd20c0..37ca427 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -79,7 +79,7 @@ int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
> int pipe = drm_crtc_index(crtc);
> struct rockchip_drm_private *priv = crtc->dev->dev_private;
>
> -   if (pipe > ROCKCHIP_MAX_CRTC)
> +   if (pipe >= ROCKCHIP_MAX_CRTC)
> return -EINVAL;
>
> priv->crtc_funcs[pipe] = crtc_funcs;
> @@ -92,7 +92,7 @@ void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)
> int pipe = drm_crtc_index(crtc);
> struct rockchip_drm_private *priv = crtc->dev->dev_private;
>
> -   if (pipe > ROCKCHIP_MAX_CRTC)
> +   if (pipe >= ROCKCHIP_MAX_CRTC)
> return;
>
> priv->crtc_funcs[pipe] = NULL;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC] dma-buf: Rename struct fence to dma_fence

[Christian König]

Am 13.07.2016 um 16:10 schrieb Chris Wilson:
> I plan to usurp the short name of struct fence for a core kernel struct,
> and so I need to rename the specialised fence/timeline for DMA
> operations to make room.
>
> As an indication of the scale of the flag day:
>
>   91 files changed, 904 insertions(+), 880 deletions(-)
>
> with the greatest victim being amdgpu.
>
> Just the highlights shown below.

Oh, yes please.

You won't believe how often I had to explain the difference between this 
fence infrastructure and an actual hardware fence (e.g. the hardware 
command) because people confused one with the other.

Christian.

> -Chris
>
> ---
>   drivers/base/Kconfig|   6 +-
>   drivers/dma-buf/Makefile|   2 +-
>   drivers/dma-buf/dma-buf.c   |  28 +-
>   drivers/dma-buf/dma-fence.c | 535 
> 
>   drivers/dma-buf/fence.c | 532 
> ---
>   drivers/dma-buf/reservation.c   |  90 ++--
>   drivers/dma-buf/seqno-fence.c   |  18 +-
>   drivers/dma-buf/sw_sync.c   |  44 +-
>   drivers/dma-buf/sync_debug.c|   9 +-
>   drivers/dma-buf/sync_debug.h|  13 +-
>   drivers/dma-buf/sync_file.c |  30 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h |  56 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c   |   8 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  18 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |  22 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  16 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c   |  50 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  |  10 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  18 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |   4 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  |  24 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c|  56 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_test.c|  12 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h   |   4 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   6 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |  18 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h |   4 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c |  22 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h |   4 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  56 +--
>   drivers/gpu/drm/amd/amdgpu/cik_sdma.c   |   8 +-
>   drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |   8 +-
>   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  16 +-
>   drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c  |   8 +-
>   drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |   8 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c   |   6 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c   |   6 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c   |   6 +-
>   drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h |   4 +-
>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.c   |  42 +-
>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.h   |  24 +-
>   drivers/gpu/drm/amd/scheduler/sched_fence.c |  22 +-
>   drivers/gpu/drm/drm_atomic_helper.c |   6 +-
>   drivers/gpu/drm/etnaviv/etnaviv_gem.c   |   6 +-
>   drivers/gpu/drm/etnaviv/etnaviv_gpu.c   |  46 +-
>   drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |   4 +-
>   drivers/gpu/drm/imx/ipuv3-crtc.c|  12 +-
>   drivers/gpu/drm/msm/msm_drv.h   |   2 +-
>   drivers/gpu/drm/msm/msm_fence.c |  30 +-
>   drivers/gpu/drm/msm/msm_fence.h |   2 +-
>   drivers/gpu/drm/msm/msm_gem.c   |  14 +-
>   drivers/gpu/drm/msm/msm_gem.h   |   2 +-
>   drivers/gpu/drm/msm/msm_gem_submit.c|   2 +-
>   drivers/gpu/drm/msm/msm_gpu.c   |   2 +-
>   drivers/gpu/drm/nouveau/nouveau_bo.c|   6 +-
>   drivers/gpu/drm/nouveau/nouveau_fence.c |  68 +--
>   drivers/gpu/drm/nouveau/nouveau_fence.h |   6 +-
>   drivers/gpu/drm/nouveau/nouveau_gem.c   |   2 +-
>   drivers/gpu/drm/nouveau/nv04_fence.c|   2 +-
>   drivers/gpu/drm/nouveau/nv10_fence.c|   2 +-
>   drivers/gpu/drm/nouveau/nv17_fence.c|   2 +-
>   drivers/gpu/drm/nouveau/nv50_fence.c|   2 +-
>   drivers/gpu/drm/nouveau/nv84_fence.c|   2 +-
>   drivers/gpu/drm/qxl/qxl_drv.h   |   4 +-
>   drivers/gpu/drm/qxl/qxl_release.c   |  27 +-
>   drivers/gpu/drm/radeon/radeon.h |  10 +-
>   drivers/gpu/drm/radeon/radeon_device.c  |   2 +-
>   drivers/gpu/drm/radeon/radeon_display.c |   8 +-
>   

[PATCH 1/2] drm/sun4i: Remove redundant call to drm_connector_unregister_all()

[Chris Wilson]

drm_connector_unregister_all() is automatically called by
drm_dev_unregister() and so the manual call can be dropped.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Chen-Yu Tsai 
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 4dc543e1db10..7092daaf6c43 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -185,7 +185,6 @@ static void sun4i_drv_unbind(struct device *dev)
 {
struct drm_device *drm = dev_get_drvdata(dev);

-   drm_connector_unregister_all(drm);
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
sun4i_framebuffer_free(drm);
-- 
2.8.1

[PATCH 2/2] drm: Unexport drm_connector_unregister_all()

[Chris Wilson]

This has now been removed from all drivers as it is performed centrally
as a part of device unregistration for modesetting drivers. With the last
user gone, we can unexport it from the DRM module. That requires us to
move the code slightly to avoid the need for a forward declaration.

Signed-off-by: Chris Wilson 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_crtc.c | 29 +
 include/drm/drm_crtc.h |  3 ---
 2 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c85963f4f1dc..f65b75949c20 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1115,6 +1115,15 @@ void drm_connector_unregister(struct drm_connector 
*connector)
 }
 EXPORT_SYMBOL(drm_connector_unregister);

+static void drm_connector_unregister_all(struct drm_device *dev)
+{
+   struct drm_connector *connector;
+
+   /* FIXME: taking the mode config mutex ends up in a clash with sysfs */
+   list_for_each_entry(connector, >mode_config.connector_list, head)
+   drm_connector_unregister(connector);
+}
+
 static int drm_connector_register_all(struct drm_device *dev)
 {
struct drm_connector *connector;
@@ -1138,26 +1147,6 @@ err:
return ret;
 }

-/**
- * drm_connector_unregister_all - unregister connector userspace interfaces
- * @dev: drm device
- *
- * This functions unregisters all connectors from sysfs and other places so
- * that userspace can no longer access them. Drivers should call this as the
- * first step tearing down the device instace, or when the underlying
- * physical device disappeared (e.g. USB unplug), right before calling
- * drm_dev_unregister().
- */
-void drm_connector_unregister_all(struct drm_device *dev)
-{
-   struct drm_connector *connector;
-
-   /* FIXME: taking the mode config mutex ends up in a clash with sysfs */
-   list_for_each_entry(connector, >mode_config.connector_list, head)
-   drm_connector_unregister(connector);
-}
-EXPORT_SYMBOL(drm_connector_unregister_all);
-
 static int drm_encoder_register_all(struct drm_device *dev)
 {
struct drm_encoder *encoder;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ddaa7243af55..b1e72322ebd6 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2588,9 +2588,6 @@ static inline unsigned drm_connector_index(struct 
drm_connector *connector)
return connector->connector_id;
 }

-/* helpers to {un}register all connectors from sysfs for device */
-extern void drm_connector_unregister_all(struct drm_device *dev);
-
 extern __printf(5, 6)
 int drm_encoder_init(struct drm_device *dev,
 struct drm_encoder *encoder,
-- 
2.8.1

[PATCH] drm/nouveau/fbcon: fix deadlock with FBIOPUT_CON2FBMAP

[Chris Wilson]

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> while nouveau was runtime suspended, a deadlock would occur due to
> nouveau_fbcon_set_suspend also trying to obtain console_lock().
> 
> Fix this by delaying the drm_fb_helper_set_suspend call. Based on the
> i915 code (which was done for performance reasons though).
> 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Signed-off-by: Peter Wu 
> ---
> Tested on top of v4.7-rc5, the deadlock is gone.
> ---
>  drivers/gpu/drm/nouveau/nouveau_drm.c   |  4 +--
>  drivers/gpu/drm/nouveau/nouveau_drv.h   |  1 +
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c | 54 
> -
>  drivers/gpu/drm/nouveau/nouveau_fbcon.h |  2 +-
>  4 files changed, 50 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 11f8dd9..f9a2c10 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -552,7 +552,7 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
>  
>   if (dev->mode_config.num_crtc) {
>   NV_INFO(drm, "suspending console...\n");
> - nouveau_fbcon_set_suspend(dev, 1);
> + nouveau_fbcon_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
>   NV_INFO(drm, "suspending display...\n");
>   ret = nouveau_display_suspend(dev, runtime);
>   if (ret)
> @@ -635,7 +635,7 @@ nouveau_do_resume(struct drm_device *dev, bool runtime)
>   NV_INFO(drm, "resuming display...\n");
>   nouveau_display_resume(dev, runtime);
>   NV_INFO(drm, "resuming console...\n");
> - nouveau_fbcon_set_suspend(dev, 0);
> + nouveau_fbcon_set_suspend(dev, FBINFO_STATE_RUNNING, false);
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index 822a021..a743d19 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -147,6 +147,7 @@ struct nouveau_drm {
>   struct nouveau_channel *channel;
>   struct nvkm_gpuobj *notify;
>   struct nouveau_fbdev *fbcon;
> + struct work_struct fbdev_suspend_work;
>   struct nvif_object nvsw;
>   struct nvif_object ntfy;
>   struct nvif_notify flip;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index d1f248f..089156a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -492,19 +492,53 @@ static const struct drm_fb_helper_funcs 
> nouveau_fbcon_helper_funcs = {
>   .fb_probe = nouveau_fbcon_create,
>  };
>  
> +static void nouveau_fbcon_suspend_worker(struct work_struct *work)
> +{
> + nouveau_fbcon_set_suspend(container_of(work,
> +struct nouveau_drm,
> +fbdev_suspend_work)->dev,
> +   FBINFO_STATE_RUNNING,
> +   true);
> +}
> +
>  void
> -nouveau_fbcon_set_suspend(struct drm_device *dev, int state)
> +nouveau_fbcon_set_suspend(struct drm_device *dev, int state, bool 
> synchronous)
>  {
>   struct nouveau_drm *drm = nouveau_drm(dev);
> - if (drm->fbcon) {
> - console_lock();
> - if (state == FBINFO_STATE_RUNNING)
> - nouveau_fbcon_accel_restore(dev);
> - drm_fb_helper_set_suspend(>fbcon->helper, state);
> + if (!drm->fbcon)
> + return;
> +
> + if (synchronous) {
> + /* Flush any pending work to turn the console on, and then
> +  * wait to turn it off. It must be synchronous as we are
> +  * about to suspend or unload the driver.
> +  *
> +  * Note that from within the work-handler, we cannot flush
> +  * ourselves, so only flush outstanding work upon suspend!
> +  */
>   if (state != FBINFO_STATE_RUNNING)
> - nouveau_fbcon_accel_save_disable(dev);
> - console_unlock();
> + flush_work(>fbdev_suspend_work);
> + console_lock();
> + } else {
> + /*
> +  * The console lock can be pretty contented on resume due
> +  * to all the printk activity.  Try to keep it out of the hot
> +  * path of resume if possible.  This also prevents a deadlock
> +  * with FBIOPUT_CON2FBMAP.
> +  */
> + WARN_ON(state != FBINFO_STATE_RUNNING);
> + if (!console_trylock()) {
> + schedule_work(>fbdev_suspend_work);
> + return;
> + }
>   }
> +
> + if (state == FBINFO_STATE_RUNNING)
> + nouveau_fbcon_accel_restore(dev);
> + 

[PATCH v3 1/7] lib: string: add functions to case-convert strings

[Luis de Bethencourt]

On 11/07/16 23:46, Markus Mayer wrote:
> On 9 July 2016 at 08:30, Markus Mayer  wrote:
>> On 9 July 2016 at 05:04, Luis de Bethencourt  
>> wrote:
>>> On 08/07/16 23:43, Markus Mayer wrote:
 Add a collection of generic functions to convert strings to lowercase
 or uppercase.

 Changing the case of a string (with or without copying it first) seems
 to be a recurring requirement in the kernel that is currently being
 solved by several duplicated implementations doing the same thing. This
 change aims at reducing this code duplication.

 The new functions are
 void strlcpytoupper(char *dst, const char *src, size_t len);
 void strlcpytolower(char *dst, const char *src, size_t len);
 void strcpytoupper(char *dst, const char *src);
 void strcpytolower(char *dst, const char *src);
 void strtoupper(char *s);
 void strtolower(char *s);

 The "str[l]cpyto*" versions of the function take a destination string
 and a source string as arguments. The "strlcpyto*" versions additionally
 take a length argument like strlcpy() itself. Lastly, the strto*
 functions take a single string argument and modify the passed-in string.

 Like strlcpy(), and unlike strncpy(), the functions guarantee NULL
 termination of the destination string.

 Signed-off-by: Markus Mayer 
 ---
  include/linux/string.h | 40 
  lib/string.c   | 38 ++
  2 files changed, 78 insertions(+)

 diff --git a/include/linux/string.h b/include/linux/string.h
 index 26b6f6a..36c9d14 100644
 --- a/include/linux/string.h
 +++ b/include/linux/string.h
 @@ -116,6 +116,8 @@ extern void * memchr(const void *,int,__kernel_size_t);
  #endif
  void *memchr_inv(const void *s, int c, size_t n);
  char *strreplace(char *s, char old, char new);
 +extern void strlcpytoupper(char *dst, const char *src, size_t len);
 +extern void strlcpytolower(char *dst, const char *src, size_t len);

  extern void kfree_const(const void *x);

 @@ -169,4 +171,42 @@ static inline const char *kbasename(const char *path)
   return tail ? tail + 1 : path;
  }

 +/**
 + * strcpytoupper - Copy string and convert to uppercase.
 + * @dst: The buffer to store the result.
 + * @src: The string to convert to uppercase.
 + */
 +static inline void strcpytoupper(char *dst, const char *src)
 +{
 + strlcpytoupper(dst, src, -1);
 +}
 +
>>>
>>> Why not use SIZE_MAX instead of -1?
>>
>> Sure. I'll change all four of them. Thanks.
> 
> Turns out there's actually a circular dependency here. SIZE_MAX is
> defined in linux/kernel.h. So, string.h would need to include
> kernel.h. But kernel.h, by way of several other headers, includes
> string.h.
> 
> Attempting to include kernel.h in string.h then leads to something like this:
> 
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CC  scripts/mod/devicetable-offsets.s
>   CHK include/generated/timeconst.h
> In file included from include/linux/printk.h:289:0,
>  from include/linux/kernel.h:13,
>  from include/linux/string.h:11,
>  from include/uapi/linux/uuid.h:21,
>  from include/linux/uuid.h:19,
>  from include/linux/mod_devicetable.h:12,
>  from scripts/mod/devicetable-offsets.c:2:
> include/linux/dynamic_debug.h: In function 
> ‘ddebug_dyndbg_module_param_cb’:
> include/linux/dynamic_debug.h:122:2: error: implicit declaration of
> function ‘strstr’ [-Werror=implicit-function-declaration]
>   if (strstr(param, "dyndbg")) {
>   ^
> include/linux/dynamic_debug.h:122:6: warning: incompatible implicit
> declaration of built-in function ‘strstr’ [enabled by default]
>   if (strstr(param, "dyndbg")) {
>   ^
> Since kernel.h is referencing string.h (which is needed, but not
> included a second time due to the include guards), this leads to
> undeclared string functions, because we are still in the early stages
> of including string.h itself and haven't gotten to the function
> declarations yet.
> 

Hi Markus,

Amazing. I see this happening as well, but I know it shouldn't.

The reason the #ifndef guards in headers are there is precisely to allow
circular dependencies.

The problem in your output reads as:
strstr() is in string.h
#include string.h -> that includes kernel.h -> that includes string.h

The third should do nothing based on _LINUX_STRING_H_ being defined already
and all code inside the #ifndef in string.h not being executed.
Yet it shouldn't block the first include above since that macro isn't defined,
which is what the error suggests since it doesn't have strstr()
If _LINUX_STRING_H is defined, strstr() should be 

[PATCH 1/2] drm/sun4i: Remove redundant call to drm_connector_unregister_all()

[Sean Paul]

On Wed, Jul 13, 2016 at 9:39 AM, Chris Wilson  
wrote:
> drm_connector_unregister_all() is automatically called by
> drm_dev_unregister() and so the manual call can be dropped.
>

The documentation for drm_connector_unregister_all says "Drivers
should call this [...] right before calling drm_dev_unregister()". If
this is no longer true, could you update that comment as part of this
series?

Sean

> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Maxime Ripard 
> Cc: David Airlie 
> Cc: Chen-Yu Tsai 
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 4dc543e1db10..7092daaf6c43 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -185,7 +185,6 @@ static void sun4i_drv_unbind(struct device *dev)
>  {
> struct drm_device *drm = dev_get_drvdata(dev);
>
> -   drm_connector_unregister_all(drm);
> drm_dev_unregister(drm);
> drm_kms_helper_poll_fini(drm);
> sun4i_framebuffer_free(drm);
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/msm/hdmi: Delete an unnecessary check before the function call "kfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 13 Jul 2016 18:54:11 +0200

The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
index 0ba..6e76797 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
@@ -1430,7 +1430,7 @@ struct hdmi_hdcp_ctrl *msm_hdmi_hdcp_init(struct hdmi 
*hdmi)

 void msm_hdmi_hdcp_destroy(struct hdmi *hdmi)
 {
-   if (hdmi && hdmi->hdcp_ctrl) {
+   if (hdmi) {
kfree(hdmi->hdcp_ctrl);
hdmi->hdcp_ctrl = NULL;
}
-- 
2.9.0

[PATCH 2/3] drm/msm: Delete unnecessary checks before drm_gem_object_unreference_unlocked()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 13 Jul 2016 19:15:35 +0200

The drm_gem_object_unreference_unlocked() function tests whether
its argument is NULL and then returns immediately.
Thus the test around the calls is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 3 +--
 drivers/gpu/drm/msm/msm_fb.c| 4 ++--
 drivers/gpu/drm/msm/msm_gem.c   | 4 +---
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index ba8df15..7b39e89 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -168,8 +168,7 @@ static void mdp4_destroy(struct msm_kms *kms)

if (mdp4_kms->blank_cursor_iova)
msm_gem_put_iova(mdp4_kms->blank_cursor_bo, mdp4_kms->id);
-   if (mdp4_kms->blank_cursor_bo)
-   drm_gem_object_unreference_unlocked(mdp4_kms->blank_cursor_bo);
+   drm_gem_object_unreference_unlocked(mdp4_kms->blank_cursor_bo);

if (mdp4_kms->rpm_enabled)
pm_runtime_disable(dev);
diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 7919c24..95cf8fe 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -49,8 +49,8 @@ static void msm_framebuffer_destroy(struct drm_framebuffer 
*fb)

for (i = 0; i < n; i++) {
struct drm_gem_object *bo = msm_fb->planes[i];
-   if (bo)
-   drm_gem_object_unreference_unlocked(bo);
+
+   drm_gem_object_unreference_unlocked(bo);
}

kfree(msm_fb);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 886cfe0..9a713fb 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -875,8 +875,6 @@ struct drm_gem_object *msm_gem_import(struct drm_device 
*dev,
return obj;

 fail:
-   if (obj)
-   drm_gem_object_unreference_unlocked(obj);
-
+   drm_gem_object_unreference_unlocked(obj);
return ERR_PTR(ret);
 }
-- 
2.9.0

[PATCH 3/3] drm/msm: Delete an unnecessary check before drm_gem_object_unreference()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 13 Jul 2016 19:29:19 +0200

The drm_gem_object_unreference() function tests whether its argument
is NULL and then returns immediately.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/msm_gem.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 9a713fb..6cd4af4 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -830,9 +830,7 @@ struct drm_gem_object *msm_gem_new(struct drm_device *dev,
return obj;

 fail:
-   if (obj)
-   drm_gem_object_unreference(obj);
-
+   drm_gem_object_unreference(obj);
return ERR_PTR(ret);
 }

-- 
2.9.0

[PATCH 1/2] drm/sun4i: Remove redundant call to drm_connector_unregister_all()

[Chris Wilson]

On Wed, Jul 13, 2016 at 10:56:58AM -0700, Sean Paul wrote:
> On Wed, Jul 13, 2016 at 9:39 AM, Chris Wilson  
> wrote:
> > drm_connector_unregister_all() is automatically called by
> > drm_dev_unregister() and so the manual call can be dropped.
> >
> 
> The documentation for drm_connector_unregister_all says "Drivers
> should call this [...] right before calling drm_dev_unregister()". If
> this is no longer true, could you update that comment as part of this
> series?

That is done. (The comment block is entirely removed so that we don't
distract authors with superfluous functions that they cannot call
themselves, i.e. Daniel wanted only the DRM interfaces documented.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [PATCH v3] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Matt Roper]

On Tue, Jul 12, 2016 at 11:21:39AM -0700, Matt Roper wrote:
> On Tue, Jul 12, 2016 at 01:36:03PM -0400, Lyude wrote:
> > Since the watermark calculations for Skylake are still broken, we're apt
> > to hitting underruns very easily under multi-monitor configurations.
> > While it would be lovely if this was fixed, it's not. Another problem
> > that's been coming from this however, is the mysterious issue of
> > underruns causing full system hangs. An easy way to reproduce this with
> > a skylake system:
> > 
> > - Get a laptop with a skylake GPU, and hook up two external monitors to
> >   it
> > - Move the cursor from the built-in LCD to one of the external displays
> >   as quickly as you can
> > - You'll get a few pipe underruns, and eventually the entire system will
> >   just freeze.
> > 
> > After doing a lot of investigation and reading through the bspec, I
> > found the existence of the SAGV, which is responsible for adjusting the
> > system agent voltage and clock frequencies depending on how much power
> > we need. According to the bspec:
> > 
> > "The display engine access to system memory is blocked during the
> >  adjustment time. SAGV defaults to enabled. Software must use the
> >  GT-driver pcode mailbox to disable SAGV when the display engine is not
> >  able to tolerate the blocking time."
> > 
> > The rest of the bspec goes on to explain that software can simply leave
> > the SAGV enabled, and disable it when we use interlaced pipes/have more
> > then one pipe active.
> > 
> > Sure enough, with this patchset the system hangs resulting from pipe
> > underruns on Skylake have completely vanished on my T460s. Additionally,
> > the bspec mentions turning off the SAGV with more then one pipe enabled
> > as a workaround for display underruns. While this patch doesn't entirely
> > fix that, it looks like it does improve the situation a little bit so
> > it's likely this is going to be required to make watermarks on Skylake
> > fully functional.
> > 
> > Changes since v2:
> >  - Really apply minor style nitpicks to patch this time
> > Changes since v1:
> >  - Added comments about this probably being one of the requirements to
> >fixing Skylake's watermark issues
> >  - Minor style nitpicks from Matt Roper
> >  - Disable these functions on Broxton, since it doesn't have an SAGV
> > 
> > Cc: Matt Roper 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Lyude 
> 
> I don't have a SKL to try this out on (only BXT here), but this matches
> my interpretation of the current bspec text, so
> 
> Reviewed-by: Matt Roper 
> 
> I think this also applies to
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94625
> 
> And maybe a +cc stable?
> 

Oops, one more minor issue below that I missed the first time around.

...
> > +   /* bspec says to keep retrying for at least 1 ms */
> > +   timeout = jiffies + msecs_to_jiffies(1);
> > +   do {
> > +   ret = sandybridge_pcode_write(dev_priv, GEN9_PCODE_SAGV_CONTROL,
> > + GEN9_SAGV_DISABLE);
> > +   if (ret) {
> > +   DRM_ERROR("Failed to disable the SAGV\n");
> > +   goto out;
> > +   }
> > +
> > +   ret = sandybridge_pcode_read(dev_priv, GEN9_PCODE_SAGV_CONTROL,
> > +);
> > +   if (ret) {
> > +   DRM_ERROR("Failed to check the status of the SAGV\n");
> > +   goto out;
> > +   }
> > +   } while (!(temp & 0x1) && jiffies < timeout);

We shouldn't compare jiffies directly here due to wraparound; you can
use time_before() to handle that safely.


Matt

> > +
> > +   if (temp & 0x1) {
> > +   dev_priv->skl_sagv_enabled = false;
> > +   } else {
> > +   ret = -1;
> > +   DRM_ERROR("Request to disable SAGV timed out\n");
> > +   }
> > +
> > +out:
> > +   mutex_unlock(_priv->rps.hw_lock);
> > +   return ret;
> > +}
> > +
> > +static void
> >  skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
> >const struct intel_crtc_state *cstate,
> >struct skl_ddb_entry *alloc, /* out */
> > @@ -3686,6 +3789,11 @@ static void skl_write_wm_values(struct 
> > drm_i915_private *dev_priv,
> > struct drm_device *dev = _priv->drm;
> > struct intel_crtc *crtc;
> >  
> > +   if (dev_priv->active_crtcs == 1)
> > +   skl_enable_sagv(dev_priv);
> > +   else
> > +   skl_disable_sagv(dev_priv);
> > +
> > for_each_intel_crtc(dev, crtc) {
> > int i, level, max_level = ilk_wm_max_level(dev);
> > enum pipe pipe = crtc->pipe;
> > @@ -4228,6 +4336,8 @@ void skl_wm_get_hw_state(struct drm_device *dev)
> > /* Easy/common case; just sanitize DDB now if everything off */
> > memset(ddb, 0, sizeof(*ddb));
> > }
> > +
> > +   skl_sagv_get_hw_state(dev_priv);
> >  }
> >  
> >  static void 

[PATCH 0/3] drm/msm: Deletion of a few unnecessary checks

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 13 Jul 2016 19:46:45 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  HDMI: Delete an unnecessary check before the function call "kfree"
  Delete unnecessary checks before drm_gem_object_unreference_unlocked()
  Delete an unnecessary check before drm_gem_object_unreference()

 drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c| 2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 3 +--
 drivers/gpu/drm/msm/msm_fb.c| 4 ++--
 drivers/gpu/drm/msm/msm_gem.c   | 8 ++--
 4 files changed, 6 insertions(+), 11 deletions(-)

-- 
2.9.0

[Intel-gfx] [PATCH v3] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Ville Syrjälä]

On Wed, Jul 13, 2016 at 11:08:46AM -0700, Matt Roper wrote:
> On Tue, Jul 12, 2016 at 11:21:39AM -0700, Matt Roper wrote:
> > On Tue, Jul 12, 2016 at 01:36:03PM -0400, Lyude wrote:
> > > Since the watermark calculations for Skylake are still broken, we're apt
> > > to hitting underruns very easily under multi-monitor configurations.
> > > While it would be lovely if this was fixed, it's not. Another problem
> > > that's been coming from this however, is the mysterious issue of
> > > underruns causing full system hangs. An easy way to reproduce this with
> > > a skylake system:
> > > 
> > > - Get a laptop with a skylake GPU, and hook up two external monitors to
> > >   it
> > > - Move the cursor from the built-in LCD to one of the external displays
> > >   as quickly as you can
> > > - You'll get a few pipe underruns, and eventually the entire system will
> > >   just freeze.
> > > 
> > > After doing a lot of investigation and reading through the bspec, I
> > > found the existence of the SAGV, which is responsible for adjusting the
> > > system agent voltage and clock frequencies depending on how much power
> > > we need. According to the bspec:
> > > 
> > > "The display engine access to system memory is blocked during the
> > >  adjustment time. SAGV defaults to enabled. Software must use the
> > >  GT-driver pcode mailbox to disable SAGV when the display engine is not
> > >  able to tolerate the blocking time."
> > > 
> > > The rest of the bspec goes on to explain that software can simply leave
> > > the SAGV enabled, and disable it when we use interlaced pipes/have more
> > > then one pipe active.
> > > 
> > > Sure enough, with this patchset the system hangs resulting from pipe
> > > underruns on Skylake have completely vanished on my T460s. Additionally,
> > > the bspec mentions turning off the SAGV   with more then one pipe enabled
> > > as a workaround for display underruns. While this patch doesn't entirely
> > > fix that, it looks like it does improve the situation a little bit so
> > > it's likely this is going to be required to make watermarks on Skylake
> > > fully functional.
> > > 
> > > Changes since v2:
> > >  - Really apply minor style nitpicks to patch this time
> > > Changes since v1:
> > >  - Added comments about this probably being one of the requirements to
> > >fixing Skylake's watermark issues
> > >  - Minor style nitpicks from Matt Roper
> > >  - Disable these functions on Broxton, since it doesn't have an SAGV
> > > 
> > > Cc: Matt Roper 
> > > Cc: Daniel Vetter 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Lyude 
> > 
> > I don't have a SKL to try this out on (only BXT here), but this matches
> > my interpretation of the current bspec text, so
> > 
> > Reviewed-by: Matt Roper 
> > 
> > I think this also applies to
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94625
> > 
> > And maybe a +cc stable?
> > 
> 
> Oops, one more minor issue below that I missed the first time around.
> 
> ...
> > > + /* bspec says to keep retrying for at least 1 ms */
> > > + timeout = jiffies + msecs_to_jiffies(1);
> > > + do {
> > > + ret = sandybridge_pcode_write(dev_priv, GEN9_PCODE_SAGV_CONTROL,
> > > +   GEN9_SAGV_DISABLE);
> > > + if (ret) {
> > > + DRM_ERROR("Failed to disable the SAGV\n");
> > > + goto out;
> > > + }
> > > +
> > > + ret = sandybridge_pcode_read(dev_priv, GEN9_PCODE_SAGV_CONTROL,
> > > +  );
> > > + if (ret) {
> > > + DRM_ERROR("Failed to check the status of the SAGV\n");
> > > + goto out;
> > > + }
> > > + } while (!(temp & 0x1) && jiffies < timeout);
> 
> We shouldn't compare jiffies directly here due to wraparound; you can
> use time_before() to handle that safely.

We have wait_for()/_wait_for() for polling stuff.

> 
> 
> Matt
> 
> > > +
> > > + if (temp & 0x1) {
> > > + dev_priv->skl_sagv_enabled = false;
> > > + } else {
> > > + ret = -1;
> > > + DRM_ERROR("Request to disable SAGV timed out\n");
> > > + }
> > > +
> > > +out:
> > > + mutex_unlock(_priv->rps.hw_lock);
> > > + return ret;
> > > +}
> > > +
> > > +static void
> > >  skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
> > >  const struct intel_crtc_state *cstate,
> > >  struct skl_ddb_entry *alloc, /* out */
> > > @@ -3686,6 +3789,11 @@ static void skl_write_wm_values(struct 
> > > drm_i915_private *dev_priv,
> > >   struct drm_device *dev = _priv->drm;
> > >   struct intel_crtc *crtc;
> > >  
> > > + if (dev_priv->active_crtcs == 1)
> > > + skl_enable_sagv(dev_priv);
> > > + else
> > > + skl_disable_sagv(dev_priv);
> > > +
> > >   for_each_intel_crtc(dev, crtc) {
> > >   int i, level, max_level = ilk_wm_max_level(dev);
> > >   enum pipe pipe = crtc->pipe;
> > > @@ -4228,6 +4336,8 @@ void