[Bug 85842] Radeon HD 7750 random GPU lockup

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

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

Alex B  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Alex B  ---
After Xserver and Mesa update the issue went away.

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

[Bug 85376] Dolphin emulator has bad colors

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

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

--- Comment #12 from ghallberg+bugzilla at gmail.com ---
Created attachment 109371
  --> https://bugs.freedesktop.org/attachment.cgi?id=109371=edit
psfs output on edit9 with glennks patch

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

[Bug 86043] Optimus issue with libdrm 2.4.58

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

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

--- Comment #2 from Gavin Graham  ---
(In reply to Tobias Klausmann from comment #1)
> Works fine on my Optimus machine with libdrm 2.4.58. Dota2 runs fine on both
> GPUs!
> I am not using bumblebee or primus, so i guess the problem lies there!
> 
> Anyway, keeping this bug open for a while.

Out of curiosity, what version nVidia driver are you using?

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

[PATCH v8 9/9] drm: bridge/dw_hdmi: add rockchip rk3288 support

[Andy Yan]

rk3288 hdmi is compatible with Designware hdmi

this patch is depend on patch by Mark Yao Add drm
driver for Rockchip Socs

see https://lkml.org/lkml/2014/10/8/201

Signed-off-by: Andy Yan 
Signed-off-by: Yakir Yang 

---

Changes in v8:
- add support for rockchip rk3288 hdmi

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c|  66 --
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 319 
 include/drm/bridge/dw_hdmi.h|   1 +
 3 files changed, 374 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index ed75147..a8071c1 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -668,11 +668,15 @@ static inline void hdmi_phy_test_dout(struct dw_hdmi 
*hdmi,

 static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec)
 {
-   while ((hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) {
+   u32 val;
+
+   while ((val = hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) {
if (msec-- == 0)
return false;
udelay(1000);
}
+   hdmi_writeb(hdmi, val, HDMI_IH_I2CMPHY_STAT0);
+
return true;
 }

@@ -815,24 +819,45 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,

hdmi_phy_i2c_write(hdmi, 0x, 0x13);  /* PLLPHBYCTRL */
hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
-   /* RESISTANCE TERM 133Ohm Cfg */
-   hdmi_phy_i2c_write(hdmi, 0x0005, 0x19);  /* TXTERM */
-   /* PREEMP Cgf 0.00 */
-   hdmi_phy_i2c_write(hdmi, 0x800d, 0x09);  /* CKSYMTXCTRL */
+
+   if (hdmi->dev_type != RK3288_HDMI) {
+   /* RESISTANCE TERM 133Ohm Cfg */
+   hdmi_phy_i2c_write(hdmi, 0x0005, 0x19);  /* TXTERM */
+   /* PREEMP Cgf 0.00 */
+   hdmi_phy_i2c_write(hdmi, 0x800d, 0x09);  /* CKSYMTXCTRL */
+   } else {
+   if (curr_ctr[i].mpixelclock <= 7425) {
+   /* RESISTANCE TERM 100Ohm Cfg */
+   hdmi_phy_i2c_write(hdmi, 0x0004, 0x19);
+   hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
+   } else if (curr_ctr[i].mpixelclock <= 14850) {
+   /* RESISTANCE TERM 100Ohm Cfg */
+   hdmi_phy_i2c_write(hdmi, 0x0004, 0x19);
+   hdmi_phy_i2c_write(hdmi, 0x8029, 0x09);
+   } else {
+   /* RESISTANCE TERM 133Ohm Cfg */
+   hdmi_phy_i2c_write(hdmi, 0x0005, 0x19);
+   hdmi_phy_i2c_write(hdmi, 0x8039, 0x09);
+   }
+   }
/* TX/CK LVL 10 */
hdmi_phy_i2c_write(hdmi, 0x01ad, 0x0E);  /* VLEVCTRL */
/* REMOVE CLK TERM */
hdmi_phy_i2c_write(hdmi, 0x8000, 0x05);  /* CKCALCTRL */

-   dw_hdmi_phy_enable_power(hdmi, 1);
+   if (hdmi->dev_type != RK3288_HDMI) {
+   dw_hdmi_phy_enable_power(hdmi, 1);

-   /* toggle TMDS enable */
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 1);
+   /* toggle TMDS enable */
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_tmds(hdmi, 1);

-   /* gen2 tx power on */
-   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
-   dw_hdmi_phy_gen2_pddq(hdmi, 0);
+   /* gen2 tx power on */
+   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+   dw_hdmi_phy_gen2_pddq(hdmi, 0);
+   } else {
+   hdmi_writeb(hdmi, 0x6e, HDMI_PHY_CONF0);
+   }

/*Wait for PHY PLL lock */
msec = 5;
@@ -1398,6 +1423,20 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return 0;
 }

+static enum drm_mode_status
+dw_hdmi_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+   struct dw_hdmi *hdmi = container_of(connector,
+   struct dw_hdmi, connector);
+   enum drm_mode_status mode_status = MODE_OK;
+
+   if (hdmi->plat_data->mode_valid)
+   mode_status = hdmi->plat_data->mode_valid(connector, mode);
+
+   return mode_status;
+}
+
 static struct drm_encoder *dw_hdmi_connector_best_encoder(struct drm_connector
   *connector)
 {
@@ -1422,6 +1461,7 @@ static struct drm_connector_funcs dw_hdmi_connector_funcs 
= {

 static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
.get_modes = dw_hdmi_connector_get_modes,
+   .mode_valid = dw_hdmi_connector_mode_valid,
.best_encoder = dw_hdmi_connector_best_encoder,
 };

@@ -1514,6 +1554,8 @@ static int dw_hdmi_register(struct drm_device *drm, 
struct 

[PATCH v8 8/9] dt-bindings: Add documentation for rockchip dw hdmi

[Andy Yan]

Signed-off-by: Andy Yan 

---

Changes in v8:
- Add documentation for rockchip dw hdmi

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt

diff --git a/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
new file mode 100644
index 000..6ea6764
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
@@ -0,0 +1,43 @@
+Rockchip specific extensions to the Synopsys Designware HDMI
+
+
+Required properties:
+- compatible: "rockchip,rk3288-dw-hdmi";
+- reg: physical base address of the controller and length
+- ddc-i2c-bus:  phandle of an I2C controller used for DDC EDID probing
+- clocks: from common clock binding: handle to hdmi clock.
+- clock-names: should be "clk" "hdcp_clk"
+- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
+- interrupts: HDMI interrupt number
+- ports: contain a port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. For
+  vopb,set the reg = <0> and set the reg = <1> for vopl.
+- reg-io-width: the width of the reg:1,4, the value should be 4 on
+  rk3288 platform
+
+Example:
+hdmi: hdmi at ff98 {
+   compatible = "rockchip,rk3288-dw-hdmi";
+   reg = <0xff98 0x2>;
+   reg-io-width = <4>;
+   ddc-i2c-bus = <>;
+   rockchip,grf = <>;
+   interrupts = ;
+   clocks = <  PCLK_HDMI_CTRL>, < SCLK_HDMI_HDCP>;
+   clock-names = "clk", "hdcp_clk";
+   status = "disabled";
+   ports {
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   hdmi_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v8 7/9] drm: bridge/dw_hdmi: convert dw-hdmi to drm_bridge mode

[Andy Yan]

From: Yakir Yang 

keep the connector & birdge in dw_hdmi.c, handle encoder
in dw_hdmi-imx.c, as most of the encoder operation are
platform specific such as crtc select and panel format
set

Signed-off-by: Andy Yan 
Signed-off-by: Yakir Yang 

---

Changes in v8: None
Changes in v7: None
Changes in v6:
- move some modification from patch#5

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c  | 228 +++---
 drivers/staging/imx-drm/dw_hdmi-imx.c | 145 ++---
 include/drm/bridge/dw_hdmi.h  |  13 +-
 3 files changed, 199 insertions(+), 187 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 978c709..ed75147 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -11,7 +11,6 @@
  * Copyright (C) 2010, Guennadi Liakhovetski 
  */

-#include 
 #include 
 #include 
 #include 
@@ -108,7 +107,8 @@ union dw_reg_ptr {

 struct dw_hdmi {
struct drm_connector connector;
-   struct drm_encoder encoder;
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;

enum dw_hdmi_devtype dev_type;
struct device *dev;
@@ -1319,6 +1319,50 @@ static void dw_hdmi_poweroff(struct dw_hdmi *hdmi)
dw_hdmi_phy_disable(hdmi);
 }

+static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   dw_hdmi_setup(hdmi, mode);
+
+   /* Store the display mode for plugin/DKMS poweron events */
+   memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
+}
+
+static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void dw_hdmi_bridge_disable(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   dw_hdmi_poweroff(hdmi);
+}
+
+static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   dw_hdmi_poweron(hdmi);
+}
+
+static void dw_hdmi_bridge_destroy(struct drm_bridge *bridge)
+{
+   drm_bridge_cleanup(bridge);
+   kfree(bridge);
+}
+
+static void dw_hdmi_bridge_nope(struct drm_bridge *bridge)
+{
+   /* do nothing */
+}
+
 static enum drm_connector_status dw_hdmi_connector_detect(struct drm_connector
*connector, bool force)
 {
@@ -1360,60 +1404,7 @@ static struct drm_encoder 
*dw_hdmi_connector_best_encoder(struct drm_connector
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
 connector);

-   return >encoder;
-}
-
-static void dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-   struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   struct dw_hdmi *hdmi = container_of(encoder, struct dw_hdmi, encoder);
-
-   dw_hdmi_setup(hdmi, mode);
-
-   /* Store the display mode for plugin/DKMS poweron events */
-   memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
-}
-
-static bool dw_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   return true;
-}
-
-static void dw_hdmi_encoder_disable(struct drm_encoder *encoder)
-{
-}
-
-static void dw_hdmi_encoder_dpms(struct drm_encoder *encoder, int mode)
-{
-   struct dw_hdmi *hdmi = container_of(encoder, struct dw_hdmi, encoder);
-
-   if (mode)
-   dw_hdmi_poweroff(hdmi);
-   else
-   dw_hdmi_poweron(hdmi);
-}
-
-static void dw_hdmi_encoder_prepare(struct drm_encoder *encoder)
-{
-   struct dw_hdmi *hdmi = container_of(encoder, struct dw_hdmi, encoder);
-
-   dw_hdmi_poweroff(hdmi);
-
-   if (hdmi->plat_data->encoder_prepare)
-   hdmi->plat_data->encoder_prepare(>connector, encoder);
-}
-
-static void dw_hdmi_encoder_commit(struct drm_encoder *encoder)
-{
-   struct dw_hdmi *hdmi = container_of(encoder, struct dw_hdmi, encoder);
-
-   if (hdmi->plat_data->encoder_commit)
-   hdmi->plat_data->encoder_commit(hdmi->priv, encoder);
-
-   dw_hdmi_poweron(hdmi);
+   return hdmi->encoder;
 }

 void dw_hdmi_connector_destroy(struct drm_connector *connector)
@@ -1422,19 +1413,6 @@ void dw_hdmi_connector_destroy(struct drm_connector 
*connector)
drm_connector_cleanup(connector);
 }

-static struct drm_encoder_funcs dw_hdmi_encoder_funcs = {
-   .destroy = drm_encoder_cleanup,
-};

[PATCH v8 6/9] drm: bridge/dw_hdmi: add support for multi byte register width access

[Andy Yan]

On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers.  Byte width accesses (writeb,
readb) generate an imprecise external abort.

Signed-off-by: Andy Yan 

---

Changes in v8: None
Changes in v7: None
Changes in v6:
- move some modification to  patch#6
- refactor register access without reg_shift

Changes in v5:
- refactor reg-io-width

Changes in v4: None
Changes in v3:
- split multi register access to one indepent patch

Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 57 +++-
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index e9f0dfe..978c709 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -101,6 +101,11 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

+union dw_reg_ptr {
+   u32 __iomem *p32;
+   u8 __iomem *p8;
+};
+
 struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder encoder;
@@ -121,20 +126,43 @@ struct dw_hdmi {

struct regmap *regmap;
struct i2c_adapter *ddc;
-   void __iomem *regs;
+   union dw_reg_ptr regs;

unsigned int sample_rate;
int ratio;
+
+   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+   u8 (*read)(struct dw_hdmi *hdmi, int offset);
 };

+static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+   writel(val, hdmi->regs.p32 + offset);
+}
+
+static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
+{
+   return readl(hdmi->regs.p32 + offset);
+}
+
+static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+   writeb(val, hdmi->regs.p8 + offset);
+}
+
+static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
+{
+   return readb(hdmi->regs.p8 + offset);
+}
+
 static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
-   writeb(val, hdmi->regs + offset);
+   hdmi->write(hdmi, val, offset);
 }

 static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
-   return readb(hdmi->regs + offset);
+   return hdmi->read(hdmi, offset);
 }

 static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
@@ -1499,6 +1527,23 @@ static int dw_hdmi_bind(struct device *dev, struct 
device *master, void *data)
struct device_node *ddc_node;
struct resource *iores;
int ret, irq;
+   u32 val = 1;
+
+   of_property_read_u32(np, "reg-io-width", );
+
+   switch (val) {
+   case 4:
+   hdmi->write = dw_hdmi_writel;
+   hdmi->read = dw_hdmi_readl;
+   break;
+   case 1:
+   hdmi->write = dw_hdmi_writeb;
+   hdmi->read = dw_hdmi_readb;
+   break;
+   default:
+   dev_err(dev, "reg-io-width must be 1 or 4\n");
+   return -EINVAL;
+   }

ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
@@ -1525,9 +1570,9 @@ static int dw_hdmi_bind(struct device *dev, struct device 
*master, void *data)
return ret;

iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   hdmi->regs = devm_ioremap_resource(dev, iores);
-   if (IS_ERR(hdmi->regs))
-   return PTR_ERR(hdmi->regs);
+   hdmi->regs.p32 = devm_ioremap_resource(dev, iores);
+   if (IS_ERR(hdmi->regs.p32))
+   return PTR_ERR(hdmi->regs.p32);

if (hdmi->plat_data->setup)
hdmi->priv = hdmi->plat_data->setup(pdev);
-- 
1.9.1

[PATCH v8 5/9] dt-bindings: add document for dw_hdmi

[Andy Yan]

Signed-off-by: Andy Yan 

---

Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
new file mode 100644
index 000..0558442
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
@@ -0,0 +1,40 @@
+DesignWare HDMI bridge bindings
+
+Required properities:
+- compatible: platform specific such as:
+   * "fsl,imx6q-hdmi"
+   * "fsl,imx6dl-hdmi"
+   * "rockchip,rk3288-dw-hdmi"
+- reg: physical base address of the controller and length
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- interrupts: The HDMI interrupt number
+
+Optional properties
+- reg-io-width: the width of the reg:1,4, default set to 1 if not present
+
+Example:
+   hdmi: hdmi at 012 {
+   compatible = "fsl,imx6q-hdmi";
+   reg = <0x0012 0x9000>;
+   interrupts = <0 115 0x04>;
+   gpr = <>;
+   clocks = < 123>, < 124>;
+   clock-names = "iahb", "isfr";
+   ddc-i2c-bus = <>;
+
+   port at 0 {
+   reg = <0>;
+
+   hdmi_mux_0: endpoint {
+   remote-endpoint = <_di0_hdmi>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   hdmi_mux_1: endpoint {
+   remote-endpoint = <_di1_hdmi>;
+   };
+   };
+   };
-- 
1.9.1

[PATCH v8 4/9] staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

[Andy Yan]

the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi driver out
to drm/bridge and rename imx-hdmi to dw_hdmi

Signed-off-by: Andy Yan 

---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- use git format -M to generate these patch

 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 281 +++--
 .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}|  46 +---
 drivers/staging/imx-drm/Kconfig|   1 +
 drivers/staging/imx-drm/Makefile   |   2 +-
 drivers/staging/imx-drm/dw_hdmi-imx.c  |  70 ++---
 include/drm/bridge/dw_hdmi.h   |  57 +
 8 files changed, 243 insertions(+), 220 deletions(-)
 rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c} (83%)
 rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h} (97%)
 create mode 100644 include/drm/bridge/dw_hdmi.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..26162ef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,3 +3,8 @@ config DRM_PTN3460
depends on DRM
select DRM_KMS_HELPER
---help---
+
+config DRM_DW_HDMI
+   bool "Synopsys DesignWare High-Definition Multimedia Interface"
+   depends on DRM
+   select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d8a8cfd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
 ccflags-y := -Iinclude/drm

 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/gpu/drm/bridge/dw_hdmi.c
similarity index 83%
rename from drivers/staging/imx-drm/imx-hdmi.c
rename to drivers/gpu/drm/bridge/dw_hdmi.c
index c7e5f12..e9f0dfe 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -6,8 +6,7 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  *
- * SH-Mobile High-Definition Multimedia Interface (HDMI) driver
- * for SLISHDMI13T and SLIPHDMIT IP cores
+ * Designware High-Definition Multimedia Interface (HDMI) driver
  *
  * Copyright (C) 2010, Guennadi Liakhovetski 
  */
@@ -24,8 +23,9 @@
 #include 
 #include 
 #include 
+#include 

-#include "imx-hdmi.h"
+#include "dw_hdmi.h"

 #define HDMI_EDID_LEN  512

@@ -101,15 +101,15 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

-struct imx_hdmi {
+struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder encoder;

-   enum imx_hdmi_devtype dev_type;
+   enum dw_hdmi_devtype dev_type;
struct device *dev;

struct hdmi_data_info hdmi_data;
-   const struct imx_hdmi_plat_data *plat_data;
+   const struct dw_hdmi_plat_data *plat_data;
void *priv;
int vic;

@@ -127,17 +127,17 @@ struct imx_hdmi {
int ratio;
 };

-static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
+static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
writeb(val, hdmi->regs + offset);
 }

-static inline u8 hdmi_readb(struct imx_hdmi *hdmi, int offset)
+static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
return readb(hdmi->regs + offset);
 }

-static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
+static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
 {
u8 val = hdmi_readb(hdmi, reg) & ~mask;

@@ -145,13 +145,13 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 
mask, unsigned reg)
hdmi_writeb(hdmi, val, reg);
 }

-static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg,
+static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
 u8 shift, u8 mask)
 {
hdmi_modb(hdmi, data << shift, mask, reg);
 }

-static void hdmi_set_clock_regenerator_n(struct imx_hdmi *hdmi,
+static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi,
 unsigned int value)
 {
hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1);
@@ -162,7 +162,7 @@ static void hdmi_set_clock_regenerator_n(struct imx_hdmi 
*hdmi,
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
 }

-static void hdmi_regenerate_cts(struct imx_hdmi *hdmi, unsigned int cts)
+static void hdmi_regenerate_cts(struct dw_hdmi *hdmi, unsigned int cts)
 {
/* Must be set/cleared first */
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
@@ -309,7 +309,7 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned 

[PATCH v8 3/9] staging: imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi

[Andy Yan]

imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly differences, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.

To reuse the imx hdmi driver, split the platform specific code out
to dw_hdmi-imx.c.

Signed-off-by: Andy Yan 

---

Changes in v8: None
Changes in v7:
- remove unused variables from structure dw_hdmi
- remove a wrong modification
- add copyrights for dw_hdmi-imx.c

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/staging/imx-drm/Makefile  |   2 +-
 drivers/staging/imx-drm/dw_hdmi-imx.c | 217 +
 drivers/staging/imx-drm/imx-hdmi.c| 255 --
 drivers/staging/imx-drm/imx-hdmi.h|  43 ++
 4 files changed, 322 insertions(+), 195 deletions(-)
 create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c

diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index 582c438..809027d 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -9,4 +9,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o

 imx-ipuv3-crtc-objs  := ipuv3-crtc.o ipuv3-plane.o
 obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
-obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
+obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o dw_hdmi-imx.o
diff --git a/drivers/staging/imx-drm/dw_hdmi-imx.c 
b/drivers/staging/imx-drm/dw_hdmi-imx.c
new file mode 100644
index 000..0db978e
--- /dev/null
+++ b/drivers/staging/imx-drm/dw_hdmi-imx.c
@@ -0,0 +1,217 @@
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ *
+ * derived from imx-hdmi.c(renamed to bridge/dw_hdmi.c now)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-drm.h"
+#include "imx-hdmi.h"
+
+struct imx_hdmi_priv {
+   struct device *dev;
+   struct clk *isfr_clk;
+   struct clk *iahb_clk;
+   struct regmap *regmap;
+};
+
+static const struct mpll_config imx_mpll_cfg[] = {
+   {
+   4525, {
+   { 0x01e0, 0x },
+   { 0x21e1, 0x },
+   { 0x41e2, 0x }
+   },
+   }, {
+   9250, {
+   { 0x0140, 0x0005 },
+   { 0x2141, 0x0005 },
+   { 0x4142, 0x0005 },
+   },
+   }, {
+   14850, {
+   { 0x00a0, 0x000a },
+   { 0x20a1, 0x000a },
+   { 0x40a2, 0x000a },
+   },
+   }, {
+   ~0UL, {
+   { 0x00a0, 0x000a },
+   { 0x2001, 0x000f },
+   { 0x4002, 0x000f },
+   },
+   }
+};
+
+static const struct curr_ctrl imx_cur_ctr[] = {
+   /*  pixelclk bpp8bpp10   bpp12 */
+   {
+   5400, { 0x091c, 0x091c, 0x06dc },
+   }, {
+   5840, { 0x091c, 0x06dc, 0x06dc },
+   }, {
+   7200, { 0x06dc, 0x06dc, 0x091c },
+   }, {
+   7425, { 0x06dc, 0x0b5c, 0x091c },
+   }, {
+   11880, { 0x091c, 0x091c, 0x06dc },
+   }, {
+   21600, { 0x06dc, 0x0b5c, 0x091c },
+   }
+};
+
+static int imx_hdmi_parse_dt(struct imx_hdmi_priv *hdmi)
+{
+   struct device_node *np = hdmi->dev->of_node;
+
+   hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "gpr");
+   if (IS_ERR(hdmi->regmap)) {
+   dev_err(hdmi->dev, "Unable to get gpr\n");
+   return PTR_ERR(hdmi->regmap);
+   }
+
+   hdmi->isfr_clk = devm_clk_get(hdmi->dev, "isfr");
+   if (IS_ERR(hdmi->isfr_clk)) {
+   dev_err(hdmi->dev, "Unable to get HDMI isfr clk\n");
+   return PTR_ERR(hdmi->isfr_clk);
+   }
+
+   hdmi->iahb_clk = devm_clk_get(hdmi->dev, "iahb");
+   if (IS_ERR(hdmi->iahb_clk)) {
+   dev_err(hdmi->dev, "Unable to get HDMI iahb clk\n");
+   return PTR_ERR(hdmi->iahb_clk);
+   }
+
+   return 0;
+}
+
+static void *imx_hdmi_imx_setup(struct platform_device *pdev)
+{
+   struct imx_hdmi_priv *hdmi;
+   int ret;
+
+   hdmi = devm_kzalloc(>dev, sizeof(*hdmi), GFP_KERNEL);
+   if (!hdmi)
+   return ERR_PTR(-ENOMEM);
+   hdmi->dev = >dev;
+
+   ret = imx_hdmi_parse_dt(hdmi);
+   if (ret < 0)
+   return ERR_PTR(ret);
+   ret = clk_prepare_enable(hdmi->isfr_clk);
+   if (ret) {
+   dev_err(hdmi->dev,
+   "Cannot enable HDMI isfr clock: %d\n", ret);
+   return 

[PATCH v8 2/9] staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter

[Andy Yan]

drm driver may probe before the i2c bus, so the driver should
defer probing until it is available

Signed-off-by: Andy Yan 

---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- defer probe ddc i2c adapter

Changes in v3: None
Changes in v2: None

 drivers/staging/imx-drm/imx-hdmi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/staging/imx-drm/imx-hdmi.c
index 79daec4..c2b035a 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -1611,8 +1611,11 @@ static int imx_hdmi_bind(struct device *dev, struct 
device *master, void *data)
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
-   if (!hdmi->ddc)
+   if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
+   of_node_put(ddc_node);
+   return -EPROBE_DEFER;
+   }

of_node_put(ddc_node);
} else {
-- 
1.9.1

[PATCH v8 1/9] staging: imx-drm: imx-hdmi: make checkpatch happy

[Andy Yan]

CHECK: Alignment should match open parenthesis
+   if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
+   (hdmi->vic == 12) || (hdmi->vic == 13) ||

CHECK: braces {} should be used on all arms of this statement
+   if (hdmi->hdmi_data.video_mode.mdvi)
[...]
+   else {
[...]

Signed-off-by: Andy Yan 

---

Changes in v8: None
Changes in v7: None
Changes in v6:
- rearrange the patch order

Changes in v5: None
Changes in v4:
- fix checkpatch CHECK

Changes in v3: None
Changes in v2: None

 drivers/staging/imx-drm/imx-hdmi.c | 97 +++---
 1 file changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/staging/imx-drm/imx-hdmi.c
index aaec6b2..79daec4 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -163,7 +163,7 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 
mask, unsigned reg)
 }

 static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg,
- u8 shift, u8 mask)
+u8 shift, u8 mask)
 {
hdmi_modb(hdmi, data << shift, mask, reg);
 }
@@ -327,7 +327,7 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
 }

 static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi,
-   unsigned long pixel_clk)
+unsigned long pixel_clk)
 {
unsigned int clk_n, clk_cts;

@@ -338,7 +338,7 @@ static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi,

if (!clk_cts) {
dev_dbg(hdmi->dev, "%s: pixel clock not supported: %lu\n",
-__func__, pixel_clk);
+   __func__, pixel_clk);
return;
}

@@ -477,13 +477,11 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi 
*hdmi)
u16 coeff_b = (*csc_coeff)[1][i];
u16 coeff_c = (*csc_coeff)[2][i];

-   hdmi_writeb(hdmi, coeff_a & 0xff,
-   HDMI_CSC_COEF_A1_LSB + i * 2);
+   hdmi_writeb(hdmi, coeff_a & 0xff, HDMI_CSC_COEF_A1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_a >> 8, HDMI_CSC_COEF_A1_MSB + i * 2);
hdmi_writeb(hdmi, coeff_b & 0xff, HDMI_CSC_COEF_B1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_b >> 8, HDMI_CSC_COEF_B1_MSB + i * 2);
-   hdmi_writeb(hdmi, coeff_c & 0xff,
-   HDMI_CSC_COEF_C1_LSB + i * 2);
+   hdmi_writeb(hdmi, coeff_c & 0xff, HDMI_CSC_COEF_C1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_c >> 8, HDMI_CSC_COEF_C1_MSB + i * 2);
}

@@ -535,21 +533,22 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
struct hdmi_data_info *hdmi_data = >hdmi_data;
u8 val, vp_conf;

-   if (hdmi_data->enc_out_format == RGB
-   || hdmi_data->enc_out_format == YCBCR444) {
-   if (!hdmi_data->enc_color_depth)
+   if (hdmi_data->enc_out_format == RGB ||
+   hdmi_data->enc_out_format == YCBCR444) {
+   if (!hdmi_data->enc_color_depth) {
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
-   else if (hdmi_data->enc_color_depth == 8) {
+   } else if (hdmi_data->enc_color_depth == 8) {
color_depth = 4;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
-   } else if (hdmi_data->enc_color_depth == 10)
+   } else if (hdmi_data->enc_color_depth == 10) {
color_depth = 5;
-   else if (hdmi_data->enc_color_depth == 12)
+   } else if (hdmi_data->enc_color_depth == 12) {
color_depth = 6;
-   else if (hdmi_data->enc_color_depth == 16)
+   } else if (hdmi_data->enc_color_depth == 16) {
color_depth = 7;
-   else
+   } else {
return;
+   }
} else if (hdmi_data->enc_out_format == YCBCR422_8BITS) {
if (!hdmi_data->enc_color_depth ||
hdmi_data->enc_color_depth == 8)
@@ -561,8 +560,9 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
else
return;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_YCC422;
-   } else
+   } else {
return;
+   }

/* set the packetizer registers */
val = ((color_depth << HDMI_VP_PR_CD_COLOR_DEPTH_OFFSET) &
@@ -623,34 +623,34 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
 }

 static inline void hdmi_phy_test_clear(struct imx_hdmi *hdmi,
-   unsigned char bit)
+  unsigned char bit)
 {
hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTCLR_OFFSET,
  HDMI_PHY_TST0_TSTCLR_MASK, HDMI_PHY_TST0);
 }

 static inline void 

[PATCH v8 0/9] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

[Andy Yan]

We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly differences, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only access by word),
4K support(imx6 doesn't support 4k, but rk3288 does).

To reuse the imx-hdmi driver, we make this patch set:
(1): fix some CodingStyle warning to make checkpatch happy
(2): split out imx-soc code from imx-hdmi to dw_hdmi-imx.c
(3): move imx-hdmi to bridge/dw-hdmi, and convert it to a drm_bridge driver
(4): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c

Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description
- Add documentation for rockchip dw hdmi
- add support for rockchip rk3288 hdmi

Changes in v7:
- remove unused variables from structure dw_hdmi
- remove a wrong modification
- add copyrights for dw_hdmi-imx.c

Changes in v6:
- rearrange the patch order
- move some modification to  patch#6
- refactor register access without reg_shift
- move some modification from patch#5

Changes in v5:
- refactor reg-io-width

Changes in v4:
- fix checkpatch CHECK
- defer probe ddc i2c adapter

Changes in v3:
- split multi register access to one indepent patch

Changes in v2:
- use git format -M to generate these patch

Andy Yan (8):
  staging: imx-drm: imx-hdmi: make checkpatch happy
  staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter
  staging: imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi
  staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
  dt-bindings: add document for dw_hdmi
  drm: bridge/dw_hdmi: add support for multi byte register width access
  dt-bindings: Add documentation for rockchip dw hdmi
  drm: bridge/dw_hdmi: add rockchip rk3288 support

Yakir Yang (1):
  drm: bridge/dw_hdmi: convert dw-hdmi to drm_bridge mode

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt |  40 ++
 .../devicetree/bindings/video/dw_hdmi-rockchip.txt |  43 ++
 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 773 ++---
 .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}|   5 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 319 +
 drivers/staging/imx-drm/Kconfig|   1 +
 drivers/staging/imx-drm/Makefile   |   2 +-
 drivers/staging/imx-drm/dw_hdmi-imx.c  | 266 +++
 include/drm/bridge/dw_hdmi.h   |  53 ++
 11 files changed, 1081 insertions(+), 427 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
 rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c} (70%)
 rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h} (99%)
 create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
 create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c
 create mode 100644 include/drm/bridge/dw_hdmi.h

-- 
1.9.1

[PATCH 1/6] x86: Add support for the pcommit instruction

[Andy Lutomirski]

On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> Add support for the new pcommit instruction.  This instruction was
> announced in the document "Intel Architecture Instruction Set Extensions
> Programming Reference" with reference number 319433-022.
> 
> https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
> 
> Signed-off-by: Ross Zwisler 
> Cc: H Peter Anvin 
> Cc: Ingo Molnar 
> Cc: Thomas Gleixner 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: x86 at kernel.org
> ---
>  arch/x86/include/asm/cpufeature.h| 1 +
>  arch/x86/include/asm/special_insns.h | 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpufeature.h 
> b/arch/x86/include/asm/cpufeature.h
> index 0bb1335..b3e6b89 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -225,6 +225,7 @@
>  #define X86_FEATURE_RDSEED   ( 9*32+18) /* The RDSEED instruction */
>  #define X86_FEATURE_ADX  ( 9*32+19) /* The ADCX and ADOX 
> instructions */
>  #define X86_FEATURE_SMAP ( 9*32+20) /* Supervisor Mode Access Prevention 
> */
> +#define X86_FEATURE_PCOMMIT  ( 9*32+22) /* PCOMMIT instruction */
>  #define X86_FEATURE_CLFLUSHOPT   ( 9*32+23) /* CLFLUSHOPT instruction */
>  #define X86_FEATURE_AVX512PF ( 9*32+26) /* AVX-512 Prefetch */
>  #define X86_FEATURE_AVX512ER ( 9*32+27) /* AVX-512 Exponential and 
> Reciprocal */
> diff --git a/arch/x86/include/asm/special_insns.h 
> b/arch/x86/include/asm/special_insns.h
> index e820c08..1709a2e 100644
> --- a/arch/x86/include/asm/special_insns.h
> +++ b/arch/x86/include/asm/special_insns.h
> @@ -199,6 +199,12 @@ static inline void clflushopt(volatile void *__p)
>  "+m" (*(volatile char __force *)__p));
>  }
>  
> +static inline void pcommit(void)
> +{
> + alternative(ASM_NOP4, ".byte 0x66, 0x0f, 0xae, 0xf8",
> + X86_FEATURE_PCOMMIT);
> +}
> +

Should this patch add the feature bit and cpuinfo entry to go with it?

--Andy

[PATCH 6/6] x86: Use clwb in drm_clflush_virt_range

[Andy Lutomirski]

On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> If clwb is available on the system, use it in drm_clflush_virt_range.
> If clwb is not available, fall back to clflushopt if you can.
> If clflushopt is not supported, fall all the way back to clflush.

I don't know exactly what drm_clflush_virt_range (and the other
functions you're modifying similarly) are for, but it seems plausible to
me that they're used before reads to make sure that non-coherent memory
sees updated data.  If that's true, then this will break it.

But maybe all the users are write to coherent memory that just need to
ensure that whatever's backing the memory knows about the write.

FWIW, it may make sense to rename this function to drm_clwb_virt_range
if you make this change.

--Andy

> 
> Signed-off-by: Ross Zwisler 
> Cc: H Peter Anvin 
> Cc: Ingo Molnar 
> Cc: Thomas Gleixner 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: x86 at kernel.org
> ---
>  drivers/gpu/drm/drm_cache.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index aad9d82..84e9a04 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -138,8 +138,8 @@ drm_clflush_virt_range(void *addr, unsigned long length)
>   void *end = addr + length;
>   mb();
>   for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
> - clflushopt(addr);
> - clflushopt(end - 1);
> + clwb(addr);
> + clwb(end - 1);
>   mb();
>   return;
>   }
> 

[PATCH 2/2] drm/udl: add support to export a handle to a FD on UDL.

[Haixia Shi]

M_ERROR("obj pages is NULL %d\n", npages);
> +   return -ENOMEM;
> +   }
> +
> +   drm_prime_sg_to_page_addr_arrays(sg, obj->pages, NULL, npages);
> +
> +   *obj_p = obj;
> +   return 0;
> +}
> +
> +struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev,
> +   struct dma_buf *dma_buf)
> +{
> +   struct dma_buf_attachment *attach;
> +   struct sg_table *sg;
> +   struct udl_gem_object *uobj;
> +   int ret;
> +
> +   /* need to attach */
> +   get_device(dev->dev);
> +   attach = dma_buf_attach(dma_buf, dev->dev);
> +   if (IS_ERR(attach)) {
> +   put_device(dev->dev);
> +   return ERR_CAST(attach);
> +   }
> +
> +   get_dma_buf(dma_buf);
> +
> +   sg = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> +   if (IS_ERR(sg)) {
> +   ret = PTR_ERR(sg);
> +   goto fail_detach;
> +   }
> +
> +   ret = udl_prime_create(dev, dma_buf->size, sg, );
> +   if (ret)
> +   goto fail_unmap;
> +
> +   uobj->base.import_attach = attach;
> +   uobj->flags = UDL_BO_WC;
> +
> +   return >base;
> +
> +fail_unmap:
> +   dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> +fail_detach:
> +   dma_buf_detach(dma_buf, attach);
> +   dma_buf_put(dma_buf);
> +   put_device(dev->dev);
> +   return ERR_PTR(ret);
> +}
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 8607e9e..d5728ec 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -51,7 +51,9 @@ static struct drm_driver driver = {
> .dumb_destroy = drm_gem_dumb_destroy,
> .fops = _driver_fops,
>
> +   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> +   .gem_prime_export = udl_gem_prime_export,
> .gem_prime_import = udl_gem_prime_import,
>
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 3082780..1b132d7 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -124,6 +124,8 @@ int udl_gem_mmap(struct drm_file *file_priv, struct
> drm_device *dev,
>  void udl_gem_free_object(struct drm_gem_object *gem_obj);
>  struct udl_gem_object *udl_gem_alloc_object(struct drm_device *dev,
> size_t size);
> +struct dma_buf *udl_gem_prime_export(struct drm_device *dev,
> +struct drm_gem_object *obj, int
> flags);
>  struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev,
> struct dma_buf *dma_buf);
>
> diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
> index e00459d..692d6f2 100644
> --- a/drivers/gpu/drm/udl/udl_gem.c
> +++ b/drivers/gpu/drm/udl/udl_gem.c
> @@ -240,74 +240,3 @@ unlock:
> mutex_unlock(>struct_mutex);
> return ret;
>  }
> -
> -static int udl_prime_create(struct drm_device *dev,
> -   size_t size,
> -   struct sg_table *sg,
> -   struct udl_gem_object **obj_p)
> -{
> -   struct udl_gem_object *obj;
> -   int npages;
> -
> -   npages = size / PAGE_SIZE;
> -
> -   *obj_p = NULL;
> -   obj = udl_gem_alloc_object(dev, npages * PAGE_SIZE);
> -   if (!obj)
> -   return -ENOMEM;
> -
> -   obj->sg = sg;
> -   obj->pages = drm_malloc_ab(npages, sizeof(struct page *));
> -   if (obj->pages == NULL) {
> -   DRM_ERROR("obj pages is NULL %d\n", npages);
> -   return -ENOMEM;
> -   }
> -
> -   drm_prime_sg_to_page_addr_arrays(sg, obj->pages, NULL, npages);
> -
> -   *obj_p = obj;
> -   return 0;
> -}
> -
> -struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev,
> -   struct dma_buf *dma_buf)
> -{
> -   struct dma_buf_attachment *attach;
> -   struct sg_table *sg;
> -   struct udl_gem_object *uobj;
> -   int ret;
> -
> -   /* need to attach */
> -   get_device(dev->dev);
> -   attach = dma_buf_attach(dma_buf, dev->dev);
> -   if (IS_ERR(attach)) {
> -   put_device(dev->dev);
> -   return ERR_CAST(attach);
> -   }
> -
> -   get_dma_buf(dma_buf);
> -
> -   sg = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> -   if (IS_ERR(sg)) {
> -   ret = PTR_ERR(sg);
> -   goto fail_detach;
> -   }
> -
> -   ret = udl_prime_create(dev, dma_buf->size, sg, );
> -   if (ret) {
> -   goto fail_unmap;
> -   }
> -
> -   uobj->base.import_attach = attach;
> -   uobj->flags = UDL_BO_WC;
> -
> -   return >base;
> -
> -fail_unmap:
> -   dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> -fail_detach:
> -   dma_buf_detach(dma_buf, attach);
> -   dma_buf_put(dma_buf);
> -   put_device(dev->dev);
> -   return ERR_PTR(ret);
> -}
> --
> 2.1.0.rc2.206.gedb03e5
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141112/33ab09b9/attachment-0001.html>

[PATCH v3 1/2] drm/exynos: dp: Remove support for unused dptx-phy

[Jingoo Han]

On Wednesday, November 12, 2014 6:28 PM, Vivek Gautam wrote:
> 
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Inki Dae 
> Cc: Jingoo Han 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
> Changes from V2:
>  - Moved devm_phy_get() call out of exynos_dp_dt_parse_phydata() to
>exynos_dp_bind() function and,
>removed exynos_dp_dt_parse_phydata() function, since it was only
>getting the PHY.
> 
> Changes from V1:
>  - Reworked error handling in exynos_dp_dt_parse_phydata() as commented
>by Inki.
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   74 
> +++
>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
>  2 files changed, 17 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index cd50ece..dbe9add 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
> 
>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>  {
> - if (dp->phy) {
> + if (dp->phy)
>   phy_power_on(dp->phy);
> - } else if (dp->phy_addr) {
> - u32 reg;
> -
> - reg = __raw_readl(dp->phy_addr);
> - reg |= dp->enable_mask;
> - __raw_writel(reg, dp->phy_addr);
> - }
>  }
> 
>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>  {
> - if (dp->phy) {
> + if (dp->phy)
>   phy_power_off(dp->phy);
> - } else if (dp->phy_addr) {
> - u32 reg;
> -
> - reg = __raw_readl(dp->phy_addr);
> - reg &= ~(dp->enable_mask);
> - __raw_writel(reg, dp->phy_addr);
> - }
>  }
> 
>  static void exynos_dp_poweron(struct exynos_drm_display *display)
> @@ -1210,44 +1196,6 @@ static struct video_info 
> *exynos_dp_dt_parse_pdata(struct device *dev)
>   return dp_video_config;
>  }
> 
> -static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> -{
> - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> - u32 phy_base;
> - int ret = 0;
> -
> - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> - if (!dp_phy_node) {
> - dp->phy = devm_phy_get(dp->dev, "dp");
> - return PTR_ERR_OR_ZERO(dp->phy);
> - }
> -
> - if (of_property_read_u32(dp_phy_node, "reg", _base)) {
> - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> - ret = -EINVAL;
> - goto err;
> - }
> -
> - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> - >enable_mask)) {
> - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> - ret = -EINVAL;
> - goto err;
> - }
> -
> - dp->phy_addr = ioremap(phy_base, SZ_4);
> - if (!dp->phy_addr) {
> - dev_err(dp->dev, "failed to ioremap dp-phy\n");
> - ret = -ENOMEM;
> - goto err;
> - }
> -
> -err:
> - of_node_put(dp_phy_node);
> -
> - return ret;
> -}
> -
>  static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
>  {
>   int ret;
> @@ -1277,9 +1225,21 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>   if (IS_ERR(dp->video_info))
>   return PTR_ERR(dp->video_info);
> 
> - ret = exynos_dp_dt_parse_phydata(dp);
> - if (ret)
> - return ret;
> + dp->phy = devm_phy_get(dp->dev, "dp");
> + if (IS_ERR(dp->phy)) {
> + dev_err(dp->dev, "no DP phy configured\n");
> + ret = PTR_ERR(dp->phy);
> + if (ret) {
> + /*
> +  * phy itself is not enabled, so we can move forward
> +  * assigning NULL to phy pointer.
> +  */
> + if (ret == -ENOSYS || ret == -ENODEV)
> + dp->phy = NULL;
> + else
> + return ret;
> + }
> + }
> 
>   if (!dp->panel) {
>   ret = exynos_dp_dt_parse_panel(dp);
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
> b/drivers/gpu/drm/exynos/exynos_dp_core.h
> index a1aee69..6426201 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>   struct clk  *clock;
>   unsigned intirq;
>   void __iomem*reg_base;
> - void __iomem*phy_addr;
> - unsigned intenable_mask;
> 
>   struct video_info   *video_info;
>   struct link_train   link_train;
> --
> 

[PATCH 2/2] drm/udl: add support to export a handle to a FD on UDL.

[Haixia Shi]

Only importing an FD to a handle is currently supported on UDL,
but the exporting functionality is equally useful.

Change-Id: If4983041875ebf3bd2ecf996d0771eb77b0cf1dc
Signed-off-by: Haixia Shi 
Reviewed-by: Stéphane Marchesin 
---
 drivers/gpu/drm/udl/Makefile |   2 +-
 drivers/gpu/drm/udl/udl_dmabuf.c | 273 +++
 drivers/gpu/drm/udl/udl_drv.c|   2 +
 drivers/gpu/drm/udl/udl_drv.h|   2 +
 drivers/gpu/drm/udl/udl_gem.c|  71 --
 5 files changed, 278 insertions(+), 72 deletions(-)
 create mode 100644 drivers/gpu/drm/udl/udl_dmabuf.c

diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile
index 05c7481..195bcac 100644
--- a/drivers/gpu/drm/udl/Makefile
+++ b/drivers/gpu/drm/udl/Makefile
@@ -1,6 +1,6 @@

 ccflags-y := -Iinclude/drm

-udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_encoder.o udl_main.o 
udl_fb.o udl_transfer.o udl_gem.o
+udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_encoder.o udl_main.o 
udl_fb.o udl_transfer.o udl_gem.o udl_dmabuf.o

 obj-$(CONFIG_DRM_UDL) := udl.o
diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c b/drivers/gpu/drm/udl/udl_dmabuf.c
new file mode 100644
index 000..1d85c3a
--- /dev/null
+++ b/drivers/gpu/drm/udl/udl_dmabuf.c
@@ -0,0 +1,273 @@
+/*
+ * udl_dmabuf.c
+ *
+ * Copyright (c) 2014 The Chromium OS Authors
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include "udl_drv.h"
+#include 
+#include 
+
+struct udl_drm_dmabuf_attachment {
+   struct sg_table sgt;
+   enum dma_data_direction dir;
+   bool is_mapped;
+};
+
+static int udl_attach_dma_buf(struct dma_buf *dmabuf,
+ struct device *dev,
+ struct dma_buf_attachment *attach)
+{
+   struct udl_drm_dmabuf_attachment *udl_attach;
+
+   DRM_DEBUG_PRIME("[DEV:%s] size:%zd\n", dev_name(attach->dev),
+   attach->dmabuf->size);
+
+   udl_attach = kzalloc(sizeof(*udl_attach), GFP_KERNEL);
+   if (!udl_attach)
+   return -ENOMEM;
+
+   udl_attach->dir = DMA_NONE;
+   attach->priv = udl_attach;
+
+   return 0;
+}
+
+static void udl_detach_dma_buf(struct dma_buf *dmabuf,
+  struct dma_buf_attachment *attach)
+{
+   struct udl_drm_dmabuf_attachment *udl_attach = attach->priv;
+   struct sg_table *sgt;
+
+   if (!udl_attach)
+   return;
+
+   DRM_DEBUG_PRIME("[DEV:%s] size:%zd\n", dev_name(attach->dev),
+   attach->dmabuf->size);
+
+   sgt = _attach->sgt;
+
+   if (udl_attach->dir != DMA_NONE)
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
+   udl_attach->dir);
+
+   sg_free_table(sgt);
+   kfree(udl_attach);
+   attach->priv = NULL;
+}
+
+static struct sg_table *udl_map_dma_buf(struct dma_buf_attachment *attach,
+   enum dma_data_direction dir)
+{
+   struct udl_drm_dmabuf_attachment *udl_attach = attach->priv;
+   struct udl_gem_object *obj = to_udl_bo(attach->dmabuf->priv);
+   struct drm_device *dev = obj->base.dev;
+   struct scatterlist *rd, *wr;
+   struct sg_table *sgt = NULL;
+   unsigned int i;
+   int page_count;
+   int nents, ret;
+
+   DRM_DEBUG_PRIME("[DEV:%s] size:%zd dir=%d\n", dev_name(attach->dev),
+   attach->dmabuf->size, dir);
+
+   /* just return current sgt if already requested. */
+   if (udl_attach->dir == dir && udl_attach->is_mapped)
+   return _attach->sgt;
+
+   if (!obj->pages) {
+   DRM_ERROR("pages is null.\n");
+   return ERR_PTR(-ENOMEM);
+   }
+
+   page_count = obj->base.size / PAGE_SIZE;
+   obj->sg = drm_prime_pages_to_sg(obj->pages, page_count);
+   if (!obj->sg) {
+   DRM_ERROR("sg is null.\n");
+   return ERR_PTR(-ENOMEM);
+   }
+
+   sgt = _attach->sgt;
+
+   ret = sg_alloc_table(sgt, obj->sg->orig_nents, GFP_KERNEL);
+   if (ret) {
+   DRM_ERROR("failed to alloc sgt.\n");
+   return ERR_PTR(-ENOMEM);
+   }
+
+   mutex_lock(>struct_mutex);
+
+   rd = obj->sg->sgl;
+   wr = sgt->sgl;
+   for (i = 0; i < sgt->orig_nents; ++i) {
+   sg_set_page(wr, sg_page(rd), 

[PATCH 1/2] drm/udl: add cache flags definitions for udl_gem_object

[Haixia Shi]

By default set udl_gem_object as cacheable, but set WC flag when attaching
dmabuf. In udl_gem_mmap() update cache attributes based on the flags, similar
to exynos_drm_gem_mmap().

Change-Id: I00e5e67f2285d66adcf2ae652a9d59f12af64541
Signed-off-by: Haixia Shi 
Reviewed-by: Sonny Rao 
Reviewed-by: Olof Johansson 
Reviewed-by: Stéphane Marchesin 
---
 drivers/gpu/drm/udl/udl_drv.h |  4 
 drivers/gpu/drm/udl/udl_gem.c | 21 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index c7490a2..3082780 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -25,6 +25,9 @@
 #define DRIVER_MINOR   0
 #define DRIVER_PATCHLEVEL  1

+#define UDL_BO_CACHEABLE   (1 << 0)
+#define UDL_BO_WC  (1 << 1)
+
 struct udl_device;

 struct urb_node {
@@ -69,6 +72,7 @@ struct udl_gem_object {
struct page **pages;
void *vmapping;
struct sg_table *sg;
+   unsigned int flags;
 };

 #define to_udl_bo(x) container_of(x, struct udl_gem_object, base)
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 8044f5f..e00459d 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -25,6 +25,7 @@ struct udl_gem_object *udl_gem_alloc_object(struct drm_device 
*dev,
return NULL;
}

+   obj->flags = UDL_BO_CACHEABLE;
return obj;
 }

@@ -56,6 +57,23 @@ udl_gem_create(struct drm_file *file,
return 0;
 }

+static void update_vm_cache_attr(struct udl_gem_object *obj,
+struct vm_area_struct *vma)
+{
+   DRM_DEBUG_KMS("flags = 0x%x\n", obj->flags);
+
+   /* non-cacheable as default. */
+   if (obj->flags & UDL_BO_CACHEABLE) {
+   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+   } else if (obj->flags & UDL_BO_WC) {
+   vma->vm_page_prot =
+   pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+   } else {
+   vma->vm_page_prot =
+   pgprot_noncached(vm_get_page_prot(vma->vm_flags));
+   }
+}
+
 int udl_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
@@ -77,6 +95,8 @@ int udl_drm_gem_mmap(struct file *filp, struct vm_area_struct 
*vma)
vma->vm_flags &= ~VM_PFNMAP;
vma->vm_flags |= VM_MIXEDMAP;

+   update_vm_cache_attr(to_udl_bo(vma->vm_private_data), vma);
+
return ret;
 }

@@ -279,6 +299,7 @@ struct drm_gem_object *udl_gem_prime_import(struct 
drm_device *dev,
}

uobj->base.import_attach = attach;
+   uobj->flags = UDL_BO_WC;

return >base;

-- 
2.1.0.rc2.206.gedb03e5

[Bug 80004] Serious Sam 3 BFE - incorrect weapon rendering

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

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

--- Comment #10 from Benjamin Bellec  ---
(In reply to Vitaliy Filippov from comment #9)
> Maybe... so the only thing that is left is to get response from someone who
> can fix it? :)

Absolutely.

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

[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM

[Arnd Bergmann]

On Wednesday 12 November 2014 09:18:59 Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > dma_alloc_coherent() returns a kernel virtual address that is part of
> > the linear range. Passing such an address to virt_to_page() is illegal
> > on non-coherent architectures. This causes the kernel to oops on 64-bit
> > ARM because the struct page * obtained from virt_to_page() points to
> > unmapped memory.
> 
> Oh! That is not good!
>
I think what Thierry meant is that the returned pointer is /not/ in the
linear range.

> > Until that time, this temporary fix will allow TTM to work on 32-bit
> > and 64-bit ARM as well, provided that no IOMMU translations are enabled
> > for the GPU.
> 
> Is there a way to query the 'struct device' to see if the IOMMU translation
> is enabled/disabled for said device?
> 
> Now your patch looks to get the 'struct page' by doing some  form of
> translation. Could you explain to me which type of memory have a 'struct page'
> and which ones do not ?
> 
> It is OK if you explain this in nauseating details 

Basically there are two types of memory that have a struct page:

- directly mapped cacheable memory, i.e. anything that can be accessed
  through a kernel pointer without having to go though ioremap/vmalloc/...

- highmem pages on 32-bit system.

On noncoherent ARM systems, dma_alloc_coherent will return memory that
is was unmapped from the linear range to avoid having both cacheable and
noncachable mappings for the same page.

Arnd

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Joonsoo Kim]

On Wed, Nov 12, 2014 at 04:37:46AM +0200, Kirill A. Shutemov wrote:
> On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote:
> > On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter  > > > linux.com> wrote:
> > > > 
> > > > > On Tue, 11 Nov 2014, Andrew Morton wrote:
> > > > > 
> > > > > > There's no point in doing
> > > > > >
> > > > > > #define GFP_SLAB_BUG_MASK 
> > > > > > (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> > > > > >
> > > > > > because __GFP_DMA32|__GFP_HIGHMEM are already part of 
> > > > > > ~__GFP_BITS_MASK.
> > > > > 
> > > > > ?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
> > > > > 
> > > > > __GFP_DMA32 is bit 2 and __GFP_HIGHMEM is bit 1.
> > > > 
> > > > Ah, yes, OK.
> > > > 
> > > > I suppose it's possible that __GFP_HIGHMEM was set.
> > > > 
> > > > do_huge_pmd_anonymous_page
> > > > ->pte_alloc_one
> > > >   ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)
> > > 
> > > do_huge_pmd_anonymous_page
> > >  alloc_hugepage_vma
> > >   alloc_pages_vma(GFP_TRANSHUGE)
> > > 
> > > GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.
> > 
> > Hello, Kirill.
> > 
> > BTW, why does GFP_TRANSHUGE have MOVABLE flag despite it isn't
> > movable? After breaking hugepage, it could be movable, but, it may
> > prevent CMA from working correctly until break.
> 
> Again, the same alloc vs. free gfp_mask: we want page allocator to move
> pages around to find space from THP, but resulting page is no really
> movable.

Hmm... AFAIK, without MOVABLE flag page allocator will try to move
pages to find space for THP page. Am I missing something?

> 
> I've tried to look into making THP movable: it requires quite a bit of
> infrastructure changes around rmap: try_to_unmap*(), remove_migration_pmd(),
> migration entries for PMDs, etc. I gets ugly pretty fast :-/
> I probably need to give it second try. No promises.

Good to hear. :)

I think that we can go another way that breaks the hugepage. This
operation makes it movable and CMA would be succeed.

Thanks.

[Bug 72701] Screen freeze when using radeon driver

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

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

--- Comment #22 from EmanueL Czirai  ---
In order to avoid any freezes, with the caveat that the DIScrete card won't
ever be turned off (even by # echo 'OFF' >
/sys/kernel/debug/vgaswitcheroo/switch  which would have no effect) I am using:
 radeon.dpm=1 radeon.runpm=1
with the above patch[originally made by  Alex Deucher above in Comment #14 ]
(which I also put here
https://github.com/emanueLczirai/coostomhuston/blob/a3c118ac44b616ebcc049419cc08c4d13ebb44bd/system/lenovo%20z575/OS/manjaro/filesystem%20now/home/emacs/build/kernel/linuxgit/2100_DIScrete_gfx_card_systemfreeze.patch
)

As per our irc conversation, it would seem that maybe the lenovo board requires
some quirk in order to avoid the system freeze and thus I accept the current
workaround. Besides, I always keep my DIS card off from BIOS anyway (the BIOS
Graphics: UDMA setting(instead of Dynamic), does this)

I am thus then giving up on this for now, but I'm always ready to test new
ideas, if any should arise.

Thank you.

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

[pull] radeon drm-next-3.19

[Alex Deucher]

Hi Dave,

Radeon patches for 3.19.  Christian has a number of GPUVM improvements
slated as well, but I'd like to wait until he gets back to work next week
to pull those in. Highlights of this pull:
- ttm performance improvements
- CI dpm fixes

The following changes since commit fcf93f6948c3c29fd414bc00f1f713c501dfd22e:

  drm: More specific locking for get* ioctls (2014-11-12 17:56:34 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-3.19

for you to fetch changes up to c81b99423bd9d3fc35ac8752ca5fb4c50eab063c:

  drm/radeon/si/ci: make u8 static arrays constant (2014-11-12 11:56:46 -0500)


Alex Deucher (20):
  drm/radeon/dpm: grab fan info from vbios
  drm/radeon: rework SI dpm thermal setup
  drm/radeon: rework CI dpm thermal setup
  drm/radeon: fix typo in CI dpm disable
  drm/radeon: export radeon_atombios_lookup_gpio
  drm/radeon: store the gpio shift as well
  drm/radeon/ci: handle gpio controlled dpm features properly
  drm/radeon: fix for memory training on bonaire 0x6649
  drm/radeon: switch force state commands for CI
  drm/radeon: fix dram timing for certain hawaii boards
  drm/radeon: improve mclk param calcuations for ci dpm
  drm/radeon: fix activity settings for sclk and mclk for CI
  drm/radeon: fix sclk DS enablement
  drm/radeon: fix mclk vddc configuration for cards for hawaii
  drm/radeon: workaround a hw bug in bonaire pcie dpm
  drm/radeon: fix default dpm state setup
  drm/radeon: set bootup pcie level to max for ci dpm
  drm/radeon: fix dpm mc init for certain hawaii boards
  drm/radeon: powertune fixes for hawaii
  drm/radeon: set power control in ci dpm enable

Dave Airlie (1):
  drm/radeon/si/ci: make u8 static arrays constant

Michel Dänzer (5):
  drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM
  drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first
  drm/radeon: Set TTM_PL_FLAG_TOPDOWN also for RADEON_GEM_CPU_ACCESS BOs
  drm/ttm: Add DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN
  drm/ttm: Use only DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN

 drivers/gpu/drm/radeon/ci_dpm.c  | 339 +--
 drivers/gpu/drm/radeon/ci_dpm.h  |   2 +
 drivers/gpu/drm/radeon/ci_smc.c  |   2 +-
 drivers/gpu/drm/radeon/cik.c |  11 +-
 drivers/gpu/drm/radeon/ppsmc.h   |   4 +-
 drivers/gpu/drm/radeon/radeon.h  |   7 +-
 drivers/gpu/drm/radeon/radeon_atombios.c |  21 +-
 drivers/gpu/drm/radeon/radeon_mode.h |   3 +
 drivers/gpu/drm/radeon/radeon_object.c   |  46 -
 drivers/gpu/drm/radeon/radeon_ttm.c  |  25 ++-
 drivers/gpu/drm/radeon/si_dpm.c  |  63 --
 drivers/gpu/drm/radeon/si_smc.c  |   2 +-
 drivers/gpu/drm/ttm/ttm_bo_manager.c |   8 +-
 13 files changed, 428 insertions(+), 105 deletions(-)

How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane)

[Ville Syrjälä]

On Wed, Nov 12, 2014 at 03:22:07PM +0100, Daniel Vetter wrote:
> On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> > > > As a side note if someone is looking for stuff to do, then the pin/unpin
> > > > logic might be good thing to look at. We're currently a bit inconsistent
> > > > whether we have the buffer pinned when the plane is disabled, or just
> > > > otherwise invisible, or when the crtc itself is disabled. And I guess
> > > > cooking up some tests to poke at planes with disabled crtcs might be in
> > > > order too, as well as all kinds of variations on the
> > > > crtc_enable->plane_enable->crtc_disable->plane_disable theme.
> > > 
> > > Hm, I've thought that thus far we've kept the buffer pinned when the crtc
> > > is enabled (irrespective or crtc state). And when the crtc gets disabled
> > > we dropped the buffers. Then planes happened and everything got messy.
> > > 
> > > Actually I'm not really sure what the right semantics are here - in the
> > > atomic helpers I don't disable planes/framebuffers. Which is consistent
> > > with the legacy plane interface, but not consistent with the legacy
> > > setCrtc ioctl.
> > > 
> > > Anyone has a good idea how to handle all this properly?
> > 
> > Well I think we should avoid the "change in property X changes
> > property Y" problem. That means leaving the plane->fb alone when the
> > crtc is disabled.
> > 
> > But as as far as the pinning goes, my original idea was that we keep
> > things pinned as long as plane->fb is set, whether the plane is
> > invisible or crtc disabled. The idea was you could set up all the planes
> > in advance, and then enable the crtc and it would at least not fail due
> > to failure to pin the buffers.
> > 
> > But that is rather wasteful and might prevent defragmenting the address
> > space. So I suppose we should just change things so that at least we
> > don't keep the buffers pinned when the crtc is disabled. And perhaps
> > we should just go all the way and not pin when the plane is invisible,
> > for any reason.
> 
> The problem is a bit that the legacy setCrtc does free the buffer, and
> userspace might rely on that. So if we decide to keep the plane fb around
> when the crtc is disabled we need to at least update the set_config atomic
> helper function to release the fb of the primary plane and unlink/disable
> the primary plane.

Sounds reasonable. At least I'd prefer if we can keep such uglies neatly
tucked away in their own legacy corner, and not let them spread into the
general population.

-- 
Ville Syrjälä
Intel OTC

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

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

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

--- Comment #37 from Alexandre Demers  ---
Well, the bisection was not conclusive... A branch's head commit produced the
error, but I was unable to reproduce it earlier in that branch... I'll have to
dig again in that branch and make sure it is related to that branch only.

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

[Bug 72701] Screen freeze when using radeon driver

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

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

EmanueL Czirai  changed:

   What|Removed |Added

 Attachment #143031|0   |1
is obsolete||

--- Comment #21 from EmanueL Czirai  ---
Created attachment 157401
  --> https://bugzilla.kernel.org/attachment.cgi?id=157401=edit
updated sloppy patch to kernel 3.18-rc4

Doesn't freeze(works) with(kernel params):
radeon.dpm=1 radeon.runpm=1
radeon.dpm=0 radeon.runpm=1
(but this doesn't turn off the DIScrete card)
sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::00:01.0
1:DIS: :DynPwr::01:00.0
# echo 'OFF' > /sys/kernel/debug/vgaswitcheroo/switch
has no effect

Freezes system with:
radeon.dpm=0 radeon.runpm=-1
(what I tested, freezes system in about 10 seconds after boot)

Without this patch:
Tested to freeze, only when:
# echo 'OFF' > /sys/kernel/debug/vgaswitcheroo/switch
with:
radeon.dpm=1 radeon.runpm=0
radeon.dpm=0 radeon.runpm=0

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

[RFC PATCH] drm/gem: Warn on illegal use of the dumb buffer interface

[Daniel Vetter]

On Wed, Nov 12, 2014 at 12:55:32PM +0100, Thomas Hellstrom wrote:
> It happens on occasion that developers of generic user-space applications
> abuse the dumb buffer API to get hold of drm buffers that they can both
> mmap() and use for GPU acceleration, using the assumptions that dumb buffers
> and buffers available for GPU are
> a) The same type and can be aribtrarily type-casted.
> b) fully coherent.
> 
> This patch makes the most widely used drivers warn nicely when that happens,
> the next step will be to fail.

Yeah, makes sense to enforce a bit of sanity here. Not sure whether the
armsoc folks have already terminally screwed this up though :(

> Signed-off-by: Thomas Hellstrom 
> ---
> Patch is only compile-tested.
> FWIW vmware should typically fail on these errors.

At first I wanted to drop a bikeshed about the new bool arguments (since
they tend to make the code harder to read). But looking closer we can't
remove it from create because that would cause races (by setting it
afterwards) and for the mmap offset handling the code would end up rather
more ugly I think.

So Acked-by: Daniel Vetter  on the patch and i915
parts.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane)

[Daniel Vetter]

On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> > > As a side note if someone is looking for stuff to do, then the pin/unpin
> > > logic might be good thing to look at. We're currently a bit inconsistent
> > > whether we have the buffer pinned when the plane is disabled, or just
> > > otherwise invisible, or when the crtc itself is disabled. And I guess
> > > cooking up some tests to poke at planes with disabled crtcs might be in
> > > order too, as well as all kinds of variations on the
> > > crtc_enable->plane_enable->crtc_disable->plane_disable theme.
> > 
> > Hm, I've thought that thus far we've kept the buffer pinned when the crtc
> > is enabled (irrespective or crtc state). And when the crtc gets disabled
> > we dropped the buffers. Then planes happened and everything got messy.
> > 
> > Actually I'm not really sure what the right semantics are here - in the
> > atomic helpers I don't disable planes/framebuffers. Which is consistent
> > with the legacy plane interface, but not consistent with the legacy
> > setCrtc ioctl.
> > 
> > Anyone has a good idea how to handle all this properly?
> 
> Well I think we should avoid the "change in property X changes
> property Y" problem. That means leaving the plane->fb alone when the
> crtc is disabled.
> 
> But as as far as the pinning goes, my original idea was that we keep
> things pinned as long as plane->fb is set, whether the plane is
> invisible or crtc disabled. The idea was you could set up all the planes
> in advance, and then enable the crtc and it would at least not fail due
> to failure to pin the buffers.
> 
> But that is rather wasteful and might prevent defragmenting the address
> space. So I suppose we should just change things so that at least we
> don't keep the buffers pinned when the crtc is disabled. And perhaps
> we should just go all the way and not pin when the plane is invisible,
> for any reason.

The problem is a bit that the legacy setCrtc does free the buffer, and
userspace might rely on that. So if we decide to keep the plane fb around
when the crtc is disabled we need to at least update the set_config atomic
helper function to release the fb of the primary plane and unlink/disable
the primary plane.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/6] x86: Add support for the clwb instruction

[Borislav Petkov]

On Wed, Nov 12, 2014 at 01:38:45PM +, Anvin, H Peter wrote:
> No, it doesn't.  x86 requires 3.4+ at a minimum.

The only test I see is:

#if GCC_VERSION < 30200
# error Sorry, your compiler is too old - please upgrade it.
#endif

And even if we do require 3.4, the build fails with 4.1+ so...

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH v3 RESEND 1/2] drm/exynos: dp: Remove support for unused dptx-phy

[Vivek Gautam]

Now that we have moved to generic phy based bindings,
we don't need to have any code related to older dptx-phy.
Nobody is using this dptx-phy anymore, so removing the
same.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Cc: Inki Dae 
---

Problem with my mail client caused change in author's mail id.
So resending it with authorship under my Samsung id.

 drivers/gpu/drm/exynos/exynos_dp_core.c |   74 +++
 drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
 2 files changed, 17 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index cd50ece..dbe9add 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,

 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_on(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg |= dp->enable_mask;
-   __raw_writel(reg, dp->phy_addr);
-   }
 }

 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_off(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg &= ~(dp->enable_mask);
-   __raw_writel(reg, dp->phy_addr);
-   }
 }

 static void exynos_dp_poweron(struct exynos_drm_display *display)
@@ -1210,44 +1196,6 @@ static struct video_info 
*exynos_dp_dt_parse_pdata(struct device *dev)
return dp_video_config;
 }

-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
-   u32 phy_base;
-   int ret = 0;
-
-   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
-   if (!dp_phy_node) {
-   dp->phy = devm_phy_get(dp->dev, "dp");
-   return PTR_ERR_OR_ZERO(dp->phy);
-   }
-
-   if (of_property_read_u32(dp_phy_node, "reg", _base)) {
-   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
-   >enable_mask)) {
-   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   dp->phy_addr = ioremap(phy_base, SZ_4);
-   if (!dp->phy_addr) {
-   dev_err(dp->dev, "failed to ioremap dp-phy\n");
-   ret = -ENOMEM;
-   goto err;
-   }
-
-err:
-   of_node_put(dp_phy_node);
-
-   return ret;
-}
-
 static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
 {
int ret;
@@ -1277,9 +1225,21 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
if (IS_ERR(dp->video_info))
return PTR_ERR(dp->video_info);

-   ret = exynos_dp_dt_parse_phydata(dp);
-   if (ret)
-   return ret;
+   dp->phy = devm_phy_get(dp->dev, "dp");
+   if (IS_ERR(dp->phy)) {
+   dev_err(dp->dev, "no DP phy configured\n");
+   ret = PTR_ERR(dp->phy);
+   if (ret) {
+   /*
+* phy itself is not enabled, so we can move forward
+* assigning NULL to phy pointer.
+*/
+   if (ret == -ENOSYS || ret == -ENODEV)
+   dp->phy = NULL;
+   else
+   return ret;
+   }
+   }

if (!dp->panel) {
ret = exynos_dp_dt_parse_panel(dp);
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index a1aee69..6426201 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -153,8 +153,6 @@ struct exynos_dp_device {
struct clk  *clock;
unsigned intirq;
void __iomem*reg_base;
-   void __iomem*phy_addr;
-   unsigned intenable_mask;

struct video_info   *video_info;
struct link_train   link_train;
-- 
1.7.9.5

[PATCH v2 v3.18-rc4 2/4] drm: prime: Document gem_prime_mmap

[Daniel Vetter]

On Wed, Nov 12, 2014 at 11:38:13AM +, Daniel Thompson wrote:
> gem_prime_map is not currently described in the DRM manual, lets document
> it.
> 
> Signed-off-by: Daniel Thompson 

Patches 1&2 are Reviewed-by: Daniel Vetter 

Nit: Since this fixes an oversight in an earlier patch I usally cc the
people of the offending patch:

commit 7c397cd97b8f46659698396b420bd48c3e6703e6
Author: Joonyoung Shim 
Date:   Fri Jun 28 14:24:53 2013 +0900

drm: add mmap function to prime helpers

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 1/2] drm/exynos: dp: Remove support for unused dptx-phy

[Vivek Gautam]

On Wed, Nov 12, 2014 at 9:38 AM, Jingoo Han  wrote:
> On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
>>
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>
> Right, older dptx-phy was replaced long time ago.
> However, it was not removed for DT compatibility.
> I think that now these old DT properties can be removed.
>
> I added some comments below.

Thanks Jingoo for reviewing.

>
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Inki Dae 
>> Cc: Jingoo Han 
>> ---
>>
>> Changes from V1:
>>  - Reworked error handling in exynos_dp_dt_parse_phydata() as commented
>>by Inki.
>>
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   67 
>> ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
>>  2 files changed, 17 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index cd50ece..206163b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
>> exynos_drm_display *display,
>>
>>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>>  {
>> - if (dp->phy) {
>> + if (dp->phy)
>>   phy_power_on(dp->phy);
>> - } else if (dp->phy_addr) {
>> - u32 reg;
>> -
>> - reg = __raw_readl(dp->phy_addr);
>> - reg |= dp->enable_mask;
>> - __raw_writel(reg, dp->phy_addr);
>> - }
>>  }
>>
>>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>>  {
>> - if (dp->phy) {
>> + if (dp->phy)
>>   phy_power_off(dp->phy);
>> - } else if (dp->phy_addr) {
>> - u32 reg;
>> -
>> - reg = __raw_readl(dp->phy_addr);
>> - reg &= ~(dp->enable_mask);
>> - __raw_writel(reg, dp->phy_addr);
>> - }
>>  }
>>
>>  static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1212,40 +1198,13 @@ static struct video_info 
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>>  {
>> - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> - u32 phy_base;
>> - int ret = 0;
>> -
>> - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> - if (!dp_phy_node) {
>> - dp->phy = devm_phy_get(dp->dev, "dp");
>> - return PTR_ERR_OR_ZERO(dp->phy);
>> - }
>> -
>> - if (of_property_read_u32(dp_phy_node, "reg", _base)) {
>> - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> - ret = -EINVAL;
>> - goto err;
>> - }
>> -
>> - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> - >enable_mask)) {
>> - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> - ret = -EINVAL;
>> - goto err;
>> - }
>> -
>> - dp->phy_addr = ioremap(phy_base, SZ_4);
>> - if (!dp->phy_addr) {
>> - dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> - ret = -ENOMEM;
>> - goto err;
>> + dp->phy = devm_phy_get(dp->dev, "dp");
>> + if (IS_ERR(dp->phy)) {
>> + dev_err(dp->dev, "no DP phy configured\n");
>> + return PTR_ERR(dp->phy);
>>   }
>>
>> -err:
>> - of_node_put(dp_phy_node);
>> -
>> - return ret;
>> + return 0;
>>  }
>>
>>  static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
>> @@ -1278,8 +1237,16 @@ static int exynos_dp_bind(struct device *dev, struct 
>> device *master, void *data)
>>   return PTR_ERR(dp->video_info);
>>
>>   ret = exynos_dp_dt_parse_phydata(dp);
>
> In your patch, exynos_dp_dt_parse_phydata() calls only devm_phy_get().
> Then, how about calling devm_phy_get() directly and removing
> exynos_dp_dt_parse_phydata()? It looks simpler.

Right, makes sense. Will send quick rework for this.
Then you can give your Reviewed-by. ;-)

[snip]



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

On Wed, Nov 12, 2014 at 9:38 AM, Jingoo Han  wrote:
> On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
>>
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>
> Right, older dptx-phy was replaced long time ago.
> However, it was not removed for DT compatibility.
> I think that now these old DT properties can be removed.
>
> I added some comments below.
>
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Inki Dae 
>> Cc: Jingoo Han 
>> ---
>>
>> Changes from V1:
>>  - Reworked error handling in exynos_dp_dt_parse_phydata() as commented
>>by Inki.
>>
>>  drivers/gpu/drm/exynos/exynos_dp_core.c | 

How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane)

[Ville Syrjälä]

On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote:
> On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> > As a side note if someone is looking for stuff to do, then the pin/unpin
> > logic might be good thing to look at. We're currently a bit inconsistent
> > whether we have the buffer pinned when the plane is disabled, or just
> > otherwise invisible, or when the crtc itself is disabled. And I guess
> > cooking up some tests to poke at planes with disabled crtcs might be in
> > order too, as well as all kinds of variations on the
> > crtc_enable->plane_enable->crtc_disable->plane_disable theme.
> 
> Hm, I've thought that thus far we've kept the buffer pinned when the crtc
> is enabled (irrespective or crtc state). And when the crtc gets disabled
> we dropped the buffers. Then planes happened and everything got messy.
> 
> Actually I'm not really sure what the right semantics are here - in the
> atomic helpers I don't disable planes/framebuffers. Which is consistent
> with the legacy plane interface, but not consistent with the legacy
> setCrtc ioctl.
> 
> Anyone has a good idea how to handle all this properly?

Well I think we should avoid the "change in property X changes
property Y" problem. That means leaving the plane->fb alone when the
crtc is disabled.

But as as far as the pinning goes, my original idea was that we keep
things pinned as long as plane->fb is set, whether the plane is
invisible or crtc disabled. The idea was you could set up all the planes
in advance, and then enable the crtc and it would at least not fail due
to failure to pin the buffers.

But that is rather wasteful and might prevent defragmenting the address
space. So I suppose we should just change things so that at least we
don't keep the buffers pinned when the crtc is disabled. And perhaps
we should just go all the way and not pin when the plane is invisible,
for any reason.

-- 
Ville Syrjälä
Intel OTC

[PATCH 3/6] x86: Add support for the clwb instruction

[Borislav Petkov]

On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote:
> +static inline void clwb(volatile void *__p)
> +{
> + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",
> +  ".byte 0x66; clflush %P0",
> +  X86_FEATURE_CLFLUSHOPT,
> +  ".byte 0x66; xsaveopt %P0",

Btw, I'm afraid you're going to have to spell out those new instruction
mnemonics as they aren't supported by older compilers:

  CC  drivers/gpu/drm/drm_cache.o
{standard input}: Assembler messages:
{standard input}:63: Error: no such instruction: `xsaveopt (%rax)'
{standard input}:249: Error: no such instruction: `xsaveopt (%rdi)'
{standard input}:283: Error: no such instruction: `xsaveopt -1(%rdx)'
make[1]: *** [drivers/gpu/drm/drm_cache.o] Error 1
make: *** [drivers/gpu/drm/drm_cache.o] Error 2
[boris at etch:14:35:40:k:14)->  gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

This is on a very old guest I have which has this gcc in it and the
kernel supports everything gcc >= 3.2.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM

[Thierry Reding]

From: Thierry Reding 

dma_alloc_coherent() returns a kernel virtual address that is part of
the linear range. Passing such an address to virt_to_page() is illegal
on non-coherent architectures. This causes the kernel to oops on 64-bit
ARM because the struct page * obtained from virt_to_page() points to
unmapped memory.

This commit fixes this by using phys_to_page() since we get a physical
address from dma_alloc_coherent(). Note that this is not a proper fix
because if an IOMMU is set up to translate addresses for the GPU this
address will be an I/O virtual address rather than a physical one. The
proper fix probably involves not getting a pointer to the struct page
in the first place, but that would be a much more intrusive change, if
at all possible.

Until that time, this temporary fix will allow TTM to work on 32-bit
and 64-bit ARM as well, provided that no IOMMU translations are enabled
for the GPU.

Signed-off-by: Thierry Reding 
---
Arnd, I realize that this isn't a proper fix according to what we discussed on
IRC yesterday, but I can't see a way to remove access to the pages array that
would be as simple as this. I've marked this as RFC in the hope that it will
trigger some discussion that will lead to a proper solution.

 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c96db433f8af..d7993985752c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -343,7 +343,11 @@ static struct dma_page *__ttm_dma_alloc_page(struct 
dma_pool *pool)
   _page->dma,
   pool->gfp_flags);
if (d_page->vaddr)
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   d_page->p = phys_to_page(d_page->dma);
+#else
d_page->p = virt_to_page(d_page->vaddr);
+#endif
else {
kfree(d_page);
d_page = NULL;
-- 
2.1.3

[PATCH 3/6] x86: Add support for the clwb instruction

[Anvin, H Peter]

No, it doesn't.  x86 requires 3.4+ at a minimum.


From: Borislav Petkov
Sent: Wednesday, November 12, 2014 4:39:09 AM
To: Ross Zwisler
Cc: linux-kernel at vger.kernel.org; Anvin, H Peter; Ingo Molnar; Thomas 
Gleixner; David Airlie; dri-devel at lists.freedesktop.org; x86 at kernel.org
Subject: Re: [PATCH 3/6] x86: Add support for the clwb instruction

On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote:
> +static inline void clwb(volatile void *__p)
> +{
> + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",
> +  ".byte 0x66; clflush %P0",
> +  X86_FEATURE_CLFLUSHOPT,
> +  ".byte 0x66; xsaveopt %P0",

Btw, I'm afraid you're going to have to spell out those new instruction
mnemonics as they aren't supported by older compilers:

  CC  drivers/gpu/drm/drm_cache.o
{standard input}: Assembler messages:
{standard input}:63: Error: no such instruction: `xsaveopt (%rax)'
{standard input}:249: Error: no such instruction: `xsaveopt (%rdi)'
{standard input}:283: Error: no such instruction: `xsaveopt -1(%rdx)'
make[1]: *** [drivers/gpu/drm/drm_cache.o] Error 1
make: *** [drivers/gpu/drm/drm_cache.o] Error 2
[boris at etch:14:35:40:k:14)->  gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

This is on a very old guest I have which has this gcc in it and the
kernel supports everything gcc >= 3.2.

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

[Jingoo Han]

On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
> 
> DP PHY now require pmu-system-controller to handle PMU register
> to control PHY's power isolation. Adding the same to dp-phy
> node.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
> Changes from V1:
>  - none.
> 
>  arch/arm/boot/dts/exynos5250.dtsi |2 +-
>  arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 012b021..69f5eb0 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -732,7 +732,7 @@
> 
>   dp_phy: video-phy at 10040720 {
>   compatible = "samsung,exynos5250-dp-video-phy";
> - reg = <0x10040720 4>;
> + samsung,pmu-syscon = <_system_controller>;
>   #phy-cells = <0>;
>   };
> 
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 8617a03..1353a09 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -503,8 +503,8 @@
>   };
> 
>   dp_phy: video-phy at 10040728 {
> - compatible = "samsung,exynos5250-dp-video-phy";
> - reg = <0x10040728 4>;
> + compatible = "samsung,exynos5420-dp-video-phy";
> + samsung,pmu-syscon = <_system_controller>;
>   #phy-cells = <0>;
>   };
> 
> --
> 1.7.10.4

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Tetsuo Handa]

Andrew Morton wrote:
> Poor ttm guys - this is a bit of a trap we set for them.

Commit a91576d7916f6cce (\"drm/ttm: Pass GFP flags in order to avoid 
deadlock.\")
changed to use sc->gfp_mask rather than GFP_KERNEL.

-   pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
-   GFP_KERNEL);
+   pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);

But this bug is caused by sc->gfp_mask containing some flags which are not
in GFP_KERNEL, right? Then, I think

-   pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
+   pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & 
GFP_KERNEL);

would hide this bug.

But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag) for
two reasons when __alloc_pages_nodemask() is called from shrinker functions.

(1) Stack usage by __alloc_pages_nodemask() is large. If we unlimitedly allow
recursive __alloc_pages_nodemask() calls, kernel stack could overflow
under extreme memory pressure.

(2) Some shrinker functions are using sleepable locks which could make kswapd
sleep for unpredictable duration. If kswapd is unexpectedly blocked inside
shrinker functions and somebody is expecting that kswapd is running for
reclaiming memory, it is a memory allocation deadlock.

Speak of ttm module, commit 22e71691fd54c637 (\"drm/ttm: Use mutex_trylock() to
avoid deadlock inside shrinker functions.\") prevents unlimited recursive
__alloc_pages_nodemask() calls.

[PATCH v2 1/2] drm/exynos: dp: Remove support for unused dptx-phy

[Jingoo Han]

On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
> 
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.

Right, older dptx-phy was replaced long time ago.
However, it was not removed for DT compatibility.
I think that now these old DT properties can be removed.

I added some comments below.

> 
> Signed-off-by: Vivek Gautam 
> Cc: Inki Dae 
> Cc: Jingoo Han 
> ---
> 
> Changes from V1:
>  - Reworked error handling in exynos_dp_dt_parse_phydata() as commented
>by Inki.
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   67 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
>  2 files changed, 17 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index cd50ece..206163b 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
> 
>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>  {
> - if (dp->phy) {
> + if (dp->phy)
>   phy_power_on(dp->phy);
> - } else if (dp->phy_addr) {
> - u32 reg;
> -
> - reg = __raw_readl(dp->phy_addr);
> - reg |= dp->enable_mask;
> - __raw_writel(reg, dp->phy_addr);
> - }
>  }
> 
>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>  {
> - if (dp->phy) {
> + if (dp->phy)
>   phy_power_off(dp->phy);
> - } else if (dp->phy_addr) {
> - u32 reg;
> -
> - reg = __raw_readl(dp->phy_addr);
> - reg &= ~(dp->enable_mask);
> - __raw_writel(reg, dp->phy_addr);
> - }
>  }
> 
>  static void exynos_dp_poweron(struct exynos_drm_display *display)
> @@ -1212,40 +1198,13 @@ static struct video_info 
> *exynos_dp_dt_parse_pdata(struct device *dev)
> 
>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>  {
> - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> - u32 phy_base;
> - int ret = 0;
> -
> - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> - if (!dp_phy_node) {
> - dp->phy = devm_phy_get(dp->dev, "dp");
> - return PTR_ERR_OR_ZERO(dp->phy);
> - }
> -
> - if (of_property_read_u32(dp_phy_node, "reg", _base)) {
> - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> - ret = -EINVAL;
> - goto err;
> - }
> -
> - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> - >enable_mask)) {
> - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> - ret = -EINVAL;
> - goto err;
> - }
> -
> - dp->phy_addr = ioremap(phy_base, SZ_4);
> - if (!dp->phy_addr) {
> - dev_err(dp->dev, "failed to ioremap dp-phy\n");
> - ret = -ENOMEM;
> - goto err;
> + dp->phy = devm_phy_get(dp->dev, "dp");
> + if (IS_ERR(dp->phy)) {
> + dev_err(dp->dev, "no DP phy configured\n");
> + return PTR_ERR(dp->phy);
>   }
> 
> -err:
> - of_node_put(dp_phy_node);
> -
> - return ret;
> + return 0;
>  }
> 
>  static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
> @@ -1278,8 +1237,16 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>   return PTR_ERR(dp->video_info);
> 
>   ret = exynos_dp_dt_parse_phydata(dp);

In your patch, exynos_dp_dt_parse_phydata() calls only devm_phy_get().
Then, how about calling devm_phy_get() directly and removing
exynos_dp_dt_parse_phydata()? It looks simpler.

Best regards,
Jingoo Han

> - if (ret)
> - return ret;
> + if (ret) {
> + /*
> +  * phy itself is not enabled, so we can move forward
> +  * assigning NULL to phy pointer.
> +  */
> + if (ret == -ENOSYS || ret == -ENODEV)
> + dp->phy = NULL;
> + else
> + return ret;
> + }
> 
>   if (!dp->panel) {
>   ret = exynos_dp_dt_parse_panel(dp);
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
> b/drivers/gpu/drm/exynos/exynos_dp_core.h
> index a1aee69..6426201 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>   struct clk  *clock;
>   unsigned intirq;
>   void __iomem*reg_base;
> - void __iomem*phy_addr;
> - unsigned intenable_mask;
> 
>   struct video_info   *video_info;
>   struct link_train   link_train;
> --
> 1.7.10.4

[Bug 86196] Massive Chalice crashes on startup

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

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

Bug ID: 86196
   Summary: Massive Chalice crashes on startup
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: elad at fedoraproject.org

Created attachment 109335
  --> https://bugs.freedesktop.org/attachment.cgi?id=109335=edit
backtrace

Trying to play Massive Chalice (http://store.steampowered.com/app/246110/), it
crashes on startup after the logos.

My video card is Radeon HD 7770
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde XT [Radeon HD 7770/8760 / R7 250X]

Running Fedora 21, 64bit.

When it crashes, I can see this in the terminal:

LLVM ERROR: Cannot select: 0xdd82a2cc: i32 = truncate 0xdd818230 [ORD=47]
[ID=184]
  0xdd818230: i128 = srl 0xdd81cc14, 0xdd81cca0 [ORD=47] [ID=164]
0xdd81cc14: i128 = bitcast 0xdd81b6f4 [ORD=47] [ID=150]
  0xdd81b6f4: v4i32,ch = load 0xe02affdc, 0xdd817f74,
0xdd8189d8<LD16[%54](tbaa=!"const")> [ORD=34] [ID=119]
0xdd817f74: i64,ch = CopyFromReg 0xe02affdc, 0xdd817ee8 [ID=110]
  0xdd817ee8: i64 = Register %vreg111 [ID=2]
0xdd8189d8: i64 = undef [ID=8]
0xdd81cca0: i32 = Constant<64> [ID=107]
In function: main
ERROR: Passed a NULL mutex
ERROR: Passed a NULL mutex

Installed mesa packages:

mesa-libEGL-10.3.3-1.20141110.fc21.i686
mesa-libxatracker-10.3.3-1.20141110.fc21.x86_64
mesa-dri-drivers-10.3.3-1.20141110.fc21.x86_64
mesa-libGL-devel-10.3.3-1.20141110.fc21.x86_64
mesa-libglapi-10.3.3-1.20141110.fc21.i686
mesa-libGLES-10.3.3-1.20141110.fc21.x86_64
mesa-filesystem-10.3.3-1.20141110.fc21.x86_64
mesa-libgbm-devel-10.3.3-1.20141110.fc21.x86_64
mesa-demos-8.2.0-2.fc21.x86_64
mesa-libEGL-devel-10.3.3-1.20141110.fc21.x86_64
mesa-libGLU-9.0.0-7.fc21.i686
mesa-libwayland-egl-devel-10.3.3-1.20141110.fc21.x86_64
mesa-libGLU-9.0.0-7.fc21.x86_64
mesa-libwayland-egl-10.3.3-1.20141110.fc21.x86_64
mesa-dri-drivers-10.3.3-1.20141110.fc21.i686
mesa-libEGL-10.3.3-1.20141110.fc21.x86_64
mesa-libgbm-10.3.3-1.20141110.fc21.i686
mesa-libglapi-10.3.3-1.20141110.fc21.x86_64
mesa-libOpenCL-10.3.3-1.20141110.fc21.x86_64
mesa-vdpau-drivers-10.3.3-1.20141110.fc21.x86_64
mesa-libGLES-devel-10.3.3-1.20141110.fc21.x86_64
mesa-filesystem-10.3.3-1.20141110.fc21.i686
mesa-libGL-10.3.3-1.20141110.fc21.x86_64
mesa-libgbm-10.3.3-1.20141110.fc21.x86_64
mesa-libGL-10.3.3-1.20141110.fc21.i686
mesa-debuginfo-10.3.3-1.20141110.fc21.x86_64


I attached a backtrace of the game that systemd's coredumpctl helpfully
generated for me - I tried using gdb to get more info but gdb crashes when
processing the coredump.

I'm not 100% sure it's a driver bug, but it probably is because it seems the
developer tested this on the propritary drivers and it worked for them.

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

[RFC PATCH] drm/gem: Warn on illegal use of the dumb buffer interface

[Thomas Hellstrom]

It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.

This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.

Signed-off-by: Thomas Hellstrom 
---
Patch is only compile-tested.
FWIW vmware should typically fail on these errors.

---
 drivers/gpu/drm/i915/i915_drv.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  5 +++--
 drivers/gpu/drm/i915/i915_gem.c| 28 +++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  3 +++
 drivers/gpu/drm/nouveau/nouveau_display.c  |  9 +
 drivers/gpu/drm/nouveau/nouveau_gem.c  |  3 +++
 drivers/gpu/drm/radeon/radeon_gem.c| 29 -
 drivers/gpu/drm/radeon/radeon_object.c |  3 +++
 include/drm/drmP.h |  7 +++
 9 files changed, 80 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e27cdbe..956b154 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1593,7 +1593,7 @@ static struct drm_driver driver = {
.gem_prime_import = i915_gem_prime_import,

.dumb_create = i915_gem_dumb_create,
-   .dumb_map_offset = i915_gem_mmap_gtt,
+   .dumb_map_offset = i915_gem_dumb_map_offset,
.dumb_destroy = drm_gem_dumb_destroy,
.ioctls = i915_ioctls,
.fops = _driver_fops,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a830ea..669537c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2321,8 +2321,9 @@ void i915_vma_move_to_active(struct i915_vma *vma,
 int i915_gem_dumb_create(struct drm_file *file_priv,
 struct drm_device *dev,
 struct drm_mode_create_dumb *args);
-int i915_gem_mmap_gtt(struct drm_file *file_priv, struct drm_device *dev,
- uint32_t handle, uint64_t *offset);
+int i915_gem_dumb_map_offset(struct drm_file *file_priv,
+struct drm_device *dev, uint32_t handle,
+uint64_t *offset);
 /**
  * Returns true if seq1 is later than seq2.
  */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ba7f5c6..3d97a43 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -347,6 +347,7 @@ static int
 i915_gem_create(struct drm_file *file,
struct drm_device *dev,
uint64_t size,
+   bool dumb,
uint32_t *handle_p)
 {
struct drm_i915_gem_object *obj;
@@ -362,6 +363,7 @@ i915_gem_create(struct drm_file *file,
if (obj == NULL)
return -ENOMEM;

+   obj->base.dumb = dumb;
ret = drm_gem_handle_create(file, >base, );
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(>base);
@@ -381,7 +383,7 @@ i915_gem_dumb_create(struct drm_file *file,
args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
args->size = args->pitch * args->height;
return i915_gem_create(file, dev,
-  args->size, >handle);
+  args->size, true, >handle);
 }

 /**
@@ -394,7 +396,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_i915_gem_create *args = data;

return i915_gem_create(file, dev,
-  args->size, >handle);
+  args->size, false, >handle);
 }

 static inline int
@@ -1750,10 +1752,10 @@ static void i915_gem_object_free_mmap_offset(struct 
drm_i915_gem_object *obj)
drm_gem_free_mmap_offset(>base);
 }

-int
+static int
 i915_gem_mmap_gtt(struct drm_file *file,
  struct drm_device *dev,
- uint32_t handle,
+ uint32_t handle, bool dumb,
  uint64_t *offset)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1770,6 +1772,13 @@ i915_gem_mmap_gtt(struct drm_file *file,
goto unlock;
}

+   /*
+* We don't allow dumb mmaps on objects created using another
+* interface.
+*/
+   WARN_ONCE(dumb && !(obj->base.dumb || obj->base.import_attach),
+ "Illegal dumb map of accelerated buffer.\n");
+
if (obj->base.size > dev_priv->gtt.mappable_end) {
ret = -E2BIG;
goto out;
@@ -1794,6 +1803,15 @@ unlock:
return ret;
 }

+int
+i915_gem_dumb_map_offset(struct drm_file *file,
+struct drm_device *dev,
+uint32_t handle,
+  

[PATCH 1/9] drm/exynos: remove uneeded declaration of struct dma_iommu_mapping

[Gustavo Padovan]

Hi Inki,

2014-11-06 Inki Dae :

> 
> Hi Gustavo,
> 
> On 2014년 11월 06일 21:38, Gustavo Padovan wrote:
> > 
> > Hi Inki,
> > 
> > Could you please give a review to this series?
> 
> It looks good to me. This patch series is just cleanup but not test so I
> will merge them next week after testing if there is no any comment.

Is there any comments on this series or are the patches ready to be merged?

Thanks

Gustavo

[RFC] drm/msm: select REGULATOR

[Rob Clark]

Fixes a potential error, spotted by Felipe with randconfig:

 -
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ‘mdp4_kms_init’:
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \
of function ‘devm_regulator_get_exclusive’ 
[-Werror=implicit-function-declaration]
  mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
  ^
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:16: error: assignment makes \
pointer from integer without a cast [-Werror]
  mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
^
 -

Also add a brief comment explaining the use of _get_exclusive()

Reported-by: Felipe Balbi 
Signed-off-by: Rob Clark 
---
Was planning to include this for my 3.19 pull req, but wanted to check
if anyone had any comments.  I tried 'depends on REGULATOR' but that
was massive circular dependency hell via fbdev stuff.

 drivers/gpu/drm/msm/Kconfig | 1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 9d907c5..5b2a1ff 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -3,6 +3,7 @@ config DRM_MSM
tristate "MSM DRM"
depends on DRM
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
+   select REGULATOR
select DRM_KMS_HELPER
select DRM_PANEL
select SHMEM
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 79d804e..ac20472 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -381,6 +381,10 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
if (IS_ERR(mdp4_kms->dsi_pll_vddio))
mdp4_kms->dsi_pll_vddio = NULL;

+   /* NOTE: driver for this regulator still missing upstream.. use
+* _get_exclusive() and ignore the error if it does not exist
+* (and hope that the bootloader left it on for us)
+*/
mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
if (IS_ERR(mdp4_kms->vdd))
mdp4_kms->vdd = NULL;
-- 
1.9.3

[PATCH] drm: Simplify return value handling in drm_crtc.c

[Daniel Vetter]

While looking through drm_crtc.c to double-check make locking changes
I've noticed that there's a few other places that would now benefit
from simplified return value handling.

So let's flatten the control flow and replace and always 0 ret with 0
where possible.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 26 +-
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2beb219df1bd..46e00a29cce2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -683,7 +683,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
drm_modeset_lock_init(>mutex);
ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_CRTC);
if (ret)
-   goto out;
+   return ret;

crtc->base.properties = >properties;

@@ -697,9 +697,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
if (cursor)
cursor->possible_crtcs = 1 << drm_crtc_index(crtc);

- out:
-
-   return ret;
+   return 0;
 }
 EXPORT_SYMBOL(drm_crtc_init_with_planes);

@@ -1154,7 +1152,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,

ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
if (ret)
-   goto out;
+   return ret;

drm_modeset_lock_init(>mutex);

@@ -1166,8 +1164,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,
if (!plane->format_types) {
DRM_DEBUG_KMS("out of memory when allocating plane\n");
drm_mode_object_put(dev, >base);
-   ret = -ENOMEM;
-   goto out;
+   return -ENOMEM;
}

memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
@@ -1184,9 +1181,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,
   dev->mode_config.plane_type_property,
   plane->type);

- out:
-
-   return ret;
+   return 0;
 }
 EXPORT_SYMBOL(drm_universal_plane_init);

@@ -1887,7 +1882,6 @@ int drm_mode_getcrtc(struct drm_device *dev,
 {
struct drm_mode_crtc *crtc_resp = data;
struct drm_crtc *crtc;
-   int ret = 0;

if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -1915,7 +1909,7 @@ int drm_mode_getcrtc(struct drm_device *dev,
}
drm_modeset_unlock_crtc(crtc);

-   return ret;
+   return 0;
 }

 static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
@@ -2093,7 +2087,6 @@ int drm_mode_getencoder(struct drm_device *dev, void 
*data,
 {
struct drm_mode_get_encoder *enc_resp = data;
struct drm_encoder *encoder;
-   int ret = 0;

if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -2114,7 +2107,7 @@ int drm_mode_getencoder(struct drm_device *dev, void 
*data,
enc_resp->possible_crtcs = encoder->possible_crtcs;
enc_resp->possible_clones = encoder->possible_clones;

-   return ret;
+   return 0;
 }

 /**
@@ -2197,7 +2190,6 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
struct drm_mode_get_plane *plane_resp = data;
struct drm_plane *plane;
uint32_t __user *format_ptr;
-   int ret = 0;

if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -2237,7 +2229,7 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
}
plane_resp->count_format_types = plane->format_count;

-   return ret;
+   return 0;
 }

 /*
@@ -2957,7 +2949,7 @@ int drm_mode_addfb(struct drm_device *dev,

or->fb_id = r.fb_id;

-   return ret;
+   return 0;
 }

 static int format_check(const struct drm_mode_fb_cmd2 *r)
-- 
2.1.1

[PATCH v2 v3.18-rc4 4/4] drm: sti: Honour O_RDWR during prime-handle-to-fd

[Daniel Thompson]

Currently the sti drm driver forcible applies O_RDWR when it exports
a prime handle. This is because it was not previously possible for
user requests to create the fd with O_RDWR passed into drivers.

This is a cleanup to remove this code. This change has obvious impact
upon the userspace which must change the flags passed to
DRM_IOCTL_PRIME_HANDLE_TO_FD. However at present only a tiny handful of
developers run this userspace and, if they don't complain, nobody else
will.

Signed-off-by: Daniel Thompson 
---
 drivers/gpu/drm/sti/sti_drm_drv.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drm_drv.c 
b/drivers/gpu/drm/sti/sti_drm_drv.c
index 223d93c3a05d..320167e1520a 100644
--- a/drivers/gpu/drm/sti/sti_drm_drv.c
+++ b/drivers/gpu/drm/sti/sti_drm_drv.c
@@ -93,15 +93,6 @@ static const struct file_operations sti_drm_driver_fops = {
.release = drm_release,
 };

-static struct dma_buf *sti_drm_gem_prime_export(struct drm_device *dev,
-   struct drm_gem_object *obj,
-   int flags)
-{
-   /* we want to be able to write in mmapped buffer */
-   flags |= O_RDWR;
-   return drm_gem_prime_export(dev, obj, flags);
-}
-
 static struct drm_driver sti_drm_driver = {
.driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
DRIVER_GEM | DRIVER_PRIME,
@@ -119,7 +110,7 @@ static struct drm_driver sti_drm_driver = {

.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = sti_drm_gem_prime_export,
+   .gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-- 
1.9.3

[PATCH v2 v3.18-rc4 3/4] drm: msm: Allow exported dma-bufs to be mapped

[Daniel Thompson]

Currently msm does not implement gem_prime_mmap. Without this it is not
possible to draw onto a dma-buf from userspace (making its very hard to
implement the Android rendering model).

Fixing this is just a matter of adding a little boilerplate.

Signed-off-by: Daniel Thompson 
---
 drivers/gpu/drm/msm/msm_drv.c   |  1 +
 drivers/gpu/drm/msm/msm_drv.h   |  3 +++
 drivers/gpu/drm/msm/msm_gem_prime.c | 13 +
 3 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index b67ef5985125..5717d4ec1a2c 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -832,6 +832,7 @@ static struct drm_driver msm_driver = {
.gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
.gem_prime_vmap = msm_gem_prime_vmap,
.gem_prime_vunmap   = msm_gem_prime_vunmap,
+   .gem_prime_mmap = msm_gem_prime_mmap,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = msm_debugfs_init,
.debugfs_cleanup= msm_debugfs_cleanup,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 67f9d0a2332c..1a7344066154 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -154,6 +154,8 @@ void msm_update_fence(struct drm_device *dev, uint32_t 
fence);
 int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct drm_file *file);

+int msm_gem_mmap_obj(struct drm_gem_object *obj,
+   struct vm_area_struct *vma);
 int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
 int msm_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
 uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj);
@@ -170,6 +172,7 @@ int msm_gem_dumb_map_offset(struct drm_file *file, struct 
drm_device *dev,
 struct sg_table *msm_gem_prime_get_sg_table(struct drm_gem_object *obj);
 void *msm_gem_prime_vmap(struct drm_gem_object *obj);
 void msm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+int msm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
 struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach, struct sg_table *sg);
 int msm_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c 
b/drivers/gpu/drm/msm/msm_gem_prime.c
index ad772fe36115..dd7a7ab603e2 100644
--- a/drivers/gpu/drm/msm/msm_gem_prime.c
+++ b/drivers/gpu/drm/msm/msm_gem_prime.c
@@ -37,6 +37,19 @@ void msm_gem_prime_vunmap(struct drm_gem_object *obj, void 
*vaddr)
/* TODO msm_gem_vunmap() */
 }

+int msm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
+{
+   int ret;
+
+   mutex_lock(>dev->struct_mutex);
+   ret = drm_gem_mmap_obj(obj, obj->size, vma);
+   mutex_unlock(>dev->struct_mutex);
+   if (ret < 0)
+   return ret;
+
+   return msm_gem_mmap_obj(vma->vm_private_data, vma);
+}
+
 struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach, struct sg_table *sg)
 {
-- 
1.9.3

[PATCH v2 v3.18-rc4 2/4] drm: prime: Document gem_prime_mmap

[Daniel Thompson]

gem_prime_map is not currently described in the DRM manual, lets document
it.

Signed-off-by: Daniel Thompson 
---
 drivers/gpu/drm/drm_prime.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 8467b17c8053..5d00c8726133 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -309,7 +309,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  * Drivers can implement @gem_prime_export and @gem_prime_import in terms of
  * simpler APIs by using the helper functions @drm_gem_prime_export and
  * @drm_gem_prime_import.  These functions implement dma-buf support in terms 
of
- * five lower-level driver callbacks:
+ * six lower-level driver callbacks:
  *
  * Export callbacks:
  *
@@ -321,6 +321,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  *
  *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
  *
+ *  - @gem_prime_mmap (optional): mmap a buffer exported by your driver
+ *
  * Import callback:
  *
  *  - @gem_prime_import_sg_table (import): produce a GEM object from another
-- 
1.9.3

[PATCH v2 v3.18-rc4 1/4] drm: prime: Honour O_RDWR during prime-handle-to-fd

[Daniel Thompson]

Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it hard for the userspace to generate a file
descriptor that can be used by mmap().

It is easy to relax the restriction and allow read/write permissions.
This should be safe because the flags are seldom touched by drm; mostly
they are passed verbatim to dma_buf calls.

Signed-off-by: Daniel Thompson 
---
 drivers/gpu/drm/drm_prime.c | 9 +++--
 include/uapi/drm/drm.h  | 1 +
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 78ca30808422..8467b17c8053 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -331,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  * drm_gem_prime_export - helper library implemention of the export callback
  * @dev: drm_device to export from
  * @obj: GEM object to export
- * @flags: flags like DRM_CLOEXEC
+ * @flags: flags like DRM_CLOEXEC and DRM_RDWR
  *
  * This is the implementation of the gem_prime_export functions for GEM drivers
  * using the PRIME helpers.
@@ -635,14 +635,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
return -ENOSYS;

/* check flags are valid */
-   if (args->flags & ~DRM_CLOEXEC)
+   if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
return -EINVAL;

-   /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
-   flags = args->flags & DRM_CLOEXEC;
-
return dev->driver->prime_handle_to_fd(dev, file_priv,
-   args->handle, flags, >fd);
+   args->handle, args->flags, >fd);
 }

 int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b0b855613641..89c2b68ddc51 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -660,6 +660,7 @@ struct drm_set_client_cap {
__u64 value;
 };

+#define DRM_RDWR O_RDWR
 #define DRM_CLOEXEC O_CLOEXEC
 struct drm_prime_handle {
__u32 handle;
-- 
1.9.3

[PATCH v2 v3.18-rc4 0/4] drm: prime: Allow exported dma-bufs to be mapped

[Daniel Thompson]

This patch set started out as a single patch with a trivial bit of
boilerplate to add dmabuf mmap support to the msm driver. Each of the
change remains fairly trivial but I've split it out by topic.

Patches 1, 2 and 3 in this series should be good to go but please don't
take patch 4 (which has a small effect on userspace) without an explicit
ack from Benjamin Gaignard.

I've tested this both with a rather hacked about Android userspace
and with a fairly small test case run from debian. Both bits of code
currently use dumb buffers.

Thanks to Benjamin for his help in finding this bit of code.

v2:

* Modified DRM_PRIME_HANDLE_TO_FD to honour the O_RDRW from the user
  and removed code to workaround this from the sti driver (Rob Clark).

* Added a patch to (rather spartanly) document gem_prime_mmap. Only
  tacked into this series 'cos I spotted it was missing when I was
  checking whether I needed to describe DRM_RDRWR anywhere.


Daniel Thompson (4):
  drm: prime: Honour O_RDWR during prime-handle-to-fd
  drm: prime: Document gem_prime_mmap
  drm: msm: Allow exported dma-bufs to be mapped
  drm: sti: Honour O_RDWR during prime-handle-to-fd

 drivers/gpu/drm/drm_prime.c | 13 ++---
 drivers/gpu/drm/msm/msm_drv.c   |  1 +
 drivers/gpu/drm/msm/msm_drv.h   |  3 +++
 drivers/gpu/drm/msm/msm_gem_prime.c | 13 +
 drivers/gpu/drm/sti/sti_drm_drv.c   | 11 +--
 include/uapi/drm/drm.h  |  1 +
 6 files changed, 25 insertions(+), 17 deletions(-)

--
1.9.3

[pull] radeon drm-fixes-3.18

[Alex Deucher]

Hi Dave,

Just your atom scratch buffer locking fix.

The following changes since commit 03dca708521d30153fc5c7e2ff136f780a7372c9:

  Merge tag 'drm-intel-fixes-2014-11-07' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-11-10 10:05:37 
+1000)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.18

for you to fetch changes up to 1c9498425453bb65ef339a57705c5ef59fe1541d:

  drm/radeon: add locking around atombios scratch space usage (2014-11-11 
17:22:26 -0500)


Dave Airlie (1):
  drm/radeon: add locking around atombios scratch space usage

 drivers/gpu/drm/radeon/atom.c  | 11 ++-
 drivers/gpu/drm/radeon/atom.h  |  2 ++
 drivers/gpu/drm/radeon/atombios_dp.c   |  4 +++-
 drivers/gpu/drm/radeon/atombios_i2c.c  |  4 +++-
 drivers/gpu/drm/radeon/radeon_device.c |  1 +
 5 files changed, 19 insertions(+), 3 deletions(-)

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Joonsoo Kim]

On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter  > linux.com> wrote:
> > 
> > > On Tue, 11 Nov 2014, Andrew Morton wrote:
> > > 
> > > > There's no point in doing
> > > >
> > > > #define GFP_SLAB_BUG_MASK 
> > > > (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> > > >
> > > > because __GFP_DMA32|__GFP_HIGHMEM are already part of ~__GFP_BITS_MASK.
> > > 
> > > ?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
> > > 
> > > __GFP_DMA32 is bit 2 and __GFP_HIGHMEM is bit 1.
> > 
> > Ah, yes, OK.
> > 
> > I suppose it's possible that __GFP_HIGHMEM was set.
> > 
> > do_huge_pmd_anonymous_page
> > ->pte_alloc_one
> >   ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)
> 
> do_huge_pmd_anonymous_page
>  alloc_hugepage_vma
>   alloc_pages_vma(GFP_TRANSHUGE)
> 
> GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.

Hello, Kirill.

BTW, why does GFP_TRANSHUGE have MOVABLE flag despite it isn't
movable? After breaking hugepage, it could be movable, but, it may
prevent CMA from working correctly until break.

Thanks.

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Joonsoo Kim]

On Tue, Nov 11, 2014 at 05:44:12PM -0800, Andrew Morton wrote:
> On Wed, 12 Nov 2014 10:22:45 +0900 Joonsoo Kim  
> wrote:
> 
> > On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote:
> > > On Wed, 12 Nov 2014 00:54:01 + Luke Dashjr  wrote:
> > > 
> > > > On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> > > > > But anyway - Luke, please attach your .config to
> > > > > https://bugzilla.kernel.org/show_bug.cgi?id=87891?
> > > > 
> > > > Done: https://bugzilla.kernel.org/attachment.cgi?id=157381
> > > > 
> > > 
> > > OK, thanks.  No CONFIG_HIGHMEM of course.  I'm stumped.
> > 
> > Hello, Andrew.
> > 
> > I think that the cause is GFP_HIGHMEM.
> > GFP_HIGHMEM is always defined regardless CONFIG_HIGHMEM.
> > Please look at the do_huge_pmd_anonymous_page().
> > It calls alloc_hugepage_vma() and then alloc_pages_vma() is called
> > with alloc_hugepage_gfpmask(). This gfpmask includes GFP_TRANSHUGE
> > and then GFP_HIGHUSER_MOVABLE.
> 
> OK.
> 
> So where's the bug?  I'm inclined to say that it's in ttm.  It's taking

I agree that.

> a gfp_mask which means "this is the allocation attempt which we are
> attempting to satisfy" and uses that for its own allocation.
> 
> But ttm has no business using that gfp_mask for its own allocation
> attempt.  If anything it should use something like, err,
> 
>   GFP_KERNEL & ~__GFP_IO & ~__GFP_FS | __GFP_HIGH
> 
> although as I mentioned earlier, it would be better to avoid allocation
> altogether.

Yes, avoiding would be the best.

If not possible, introducing new common helper for changing shrinker
control's gfp to valid allocation gfp is better than just open code.

Thanks.

> 
> Poor ttm guys - this is a bit of a trap we set for them.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"dont at kvack.org"> email at kvack.org 

[PATCH v3.18-rc3] drm: msm: Allow exported dma-bufs to be mapped

[Benjamin Gaignard]

The same kind of issue has been fixed in v4l2:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/media/v4l2-core/videobuf2-core.c?id=c1b96a236e94d49d9396d0bbceb5524519c5c66e

I'm ok to add a DRM_RDWR flag, just do not remove the code from sti
driver until I have been able to test it.

Benjamin


2014-11-11 17:26 GMT+01:00 Rob Clark :
> On Tue, Nov 11, 2014 at 9:28 AM, Daniel Thompson
>  wrote:
>> On 10/11/14 17:36, Rob Clark wrote:
>>> On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson
>>>  wrote:
 diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c 
 b/drivers/gpu/drm/msm/msm_gem_prime.c
 index ad772fe36115..4e4fa5828d5d 100644
 --- a/drivers/gpu/drm/msm/msm_gem_prime.c
 +++ b/drivers/gpu/drm/msm/msm_gem_prime.c
 @@ -20,6 +20,14 @@

  #include 

 +struct dma_buf *msm_gem_prime_export(struct drm_device *dev,
 +struct drm_gem_object *obj, int flags)
 +{
 +   /* we want to be able to write in mmapped buffer */
 +   flags |= O_RDWR;
 +   return drm_gem_prime_export(dev, obj, flags);
 +}
 +
>>>
>>> seems like this probably should be done more centrally..  and in fact,
>>> might be better to have something like this in
>>> drm_prime_handle_to_fd_ioctl:
>>>
>>> /* check flags are valid */
>>> -if (args->flags & ~DRM_CLOEXEC)
>>> +if (args->flags & ~(DRM_CLOEXEC | O_RDWR))
>>>return -EINVAL;
>>>
>>> so exporter can specify whether to allow mmap or not.
>>
>> That makes sense I'll try this.
>>
>> Do we need to wrap O_RDWR in the same way we wrap O_CLOEXEC? (I don't
>> really understand why DRM_CLOEXEC exists; even the patch description
>> from when the symbol was introduced names it O_CLOEXEC).
>
> I *think* wrapping it w/ DRM_CLOEXEC was mostly just for purposes of
> making it clear which flags are appropriate.. probably best to do the
> same w/ a DRM_RDWR I guess
>
> BR,
> -R
>
>> Also the "flags |= O_RDWR" approach is copied from the sti driver. I'll
>> share a patch to remove it but that will definitely needs Benjamin's ack
>> because it will stop some userspaces working correctly (however I
>> suspect that Benjamin may be the only person currently with such a
>> userspace and that he can be persuaded not to call it a regression).
>>
>>
>> Daniel.



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Mel Gorman]

On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote:
> On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter  > > linux.com> wrote:
> > > 
> > > > On Tue, 11 Nov 2014, Andrew Morton wrote:
> > > > 
> > > > > There's no point in doing
> > > > >
> > > > >   #define GFP_SLAB_BUG_MASK 
> > > > > (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> > > > >
> > > > > because __GFP_DMA32|__GFP_HIGHMEM are already part of 
> > > > > ~__GFP_BITS_MASK.
> > > > 
> > > > ?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
> > > > 
> > > > __GFP_DMA32 is bit 2 and __GFP_HIGHMEM is bit 1.
> > > 
> > > Ah, yes, OK.
> > > 
> > > I suppose it's possible that __GFP_HIGHMEM was set.
> > > 
> > > do_huge_pmd_anonymous_page
> > > ->pte_alloc_one
> > >   ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)
> > 
> > do_huge_pmd_anonymous_page
> >  alloc_hugepage_vma
> >   alloc_pages_vma(GFP_TRANSHUGE)
> > 
> > GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.
> 
> Hello, Kirill.
> 
> BTW, why does GFP_TRANSHUGE have MOVABLE flag despite it isn't
> movable? After breaking hugepage, it could be movable, but, it may
> prevent CMA from working correctly until break.
> 

Because THP can use the Movable zone if it's allocated. When movable was
introduced it did not just mean migratable. It meant it could also be
moved to swap. THP can be broken up and swapped so it tagged as movable.

-- 
Mel Gorman
SUSE Labs

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Joonsoo Kim]

On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote:
> On Wed, 12 Nov 2014 00:54:01 + Luke Dashjr  wrote:
> 
> > On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> > > But anyway - Luke, please attach your .config to
> > > https://bugzilla.kernel.org/show_bug.cgi?id=87891?
> > 
> > Done: https://bugzilla.kernel.org/attachment.cgi?id=157381
> > 
> 
> OK, thanks.  No CONFIG_HIGHMEM of course.  I'm stumped.

Hello, Andrew.

I think that the cause is GFP_HIGHMEM.
GFP_HIGHMEM is always defined regardless CONFIG_HIGHMEM.
Please look at the do_huge_pmd_anonymous_page().
It calls alloc_hugepage_vma() and then alloc_pages_vma() is called
with alloc_hugepage_gfpmask(). This gfpmask includes GFP_TRANSHUGE
and then GFP_HIGHUSER_MOVABLE.

Thanks.

[PATCH] drm/dp/mst: Handle invalid link bandwidth from DPCD gracefully

[Chris Wilson]

Don't BUG out if the link reports an invalid (or plain unknown)
bandwidth value, but report the failure and fail gracefully.

Fixes a trivial compiler warning in case the BUG is ever compiled away.

Link: http://lkml.kernel.org/p/1415785566-12758-1-git-send-email-geert at 
linux-m68k.org
Signed-off-by: Chris Wilson 
Cc: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index dc98b8f78168..5682d7e9f1ec 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1799,17 +1799,27 @@ static int drm_dp_send_up_ack_reply(struct 
drm_dp_mst_topology_mgr *mgr,
return 0;
 }

-static int drm_dp_get_vc_payload_bw(int dp_link_bw, int dp_link_count)
+static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
+int dp_link_count,
+int *out)
 {
switch (dp_link_bw) {
+   default:
+   DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count: 
%d)\n",
+ dp_link_bw, dp_link_count);
+   return false;
+
case DP_LINK_BW_1_62:
-   return 3 * dp_link_count;
+   *out = 3 * dp_link_count;
+   break;
case DP_LINK_BW_2_7:
-   return 5 * dp_link_count;
+   *out = 5 * dp_link_count;
+   break;
case DP_LINK_BW_5_4:
-   return 10 * dp_link_count;
+   *out = 10 * dp_link_count;
+   break;
}
-   BUG();
+   return true;
 }

 /**
@@ -1841,7 +1851,13 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
}

-   mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr->dpcd[1], 
mgr->dpcd[2] & DP_MAX_LANE_COUNT_MASK);
+   if (!drm_dp_get_vc_payload_bw(mgr->dpcd[1],
+ mgr->dpcd[2] & 
DP_MAX_LANE_COUNT_MASK,
+ >pbn_div)) {
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
mgr->total_pbn = 2560;
mgr->total_slots = DIV_ROUND_UP(mgr->total_pbn, mgr->pbn_div);
mgr->avail_slots = mgr->total_slots;
-- 
2.1.3

[PATCH v3.18-rc3] drm: msm: Allow exported dma-bufs to be mapped

[Daniel Thompson]

On 12/11/14 09:41, Benjamin Gaignard wrote:
> The same kind of issue has been fixed in v4l2:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/media/v4l2-core/videobuf2-core.c?id=c1b96a236e94d49d9396d0bbceb5524519c5c66e
> 
> I'm ok to add a DRM_RDWR flag, just do not remove the code from sti
> driver until I have been able to test it.

Don't worry. I'll do that as a separate patch so you can ack/nack as you
need to.


Daniel.

> 
> Benjamin
> 
> 
> 2014-11-11 17:26 GMT+01:00 Rob Clark :
>> On Tue, Nov 11, 2014 at 9:28 AM, Daniel Thompson
>>  wrote:
>>> On 10/11/14 17:36, Rob Clark wrote:
 On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson
  wrote:
> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c 
> b/drivers/gpu/drm/msm/msm_gem_prime.c
> index ad772fe36115..4e4fa5828d5d 100644
> --- a/drivers/gpu/drm/msm/msm_gem_prime.c
> +++ b/drivers/gpu/drm/msm/msm_gem_prime.c
> @@ -20,6 +20,14 @@
>
>  #include 
>
> +struct dma_buf *msm_gem_prime_export(struct drm_device *dev,
> +struct drm_gem_object *obj, int 
> flags)
> +{
> +   /* we want to be able to write in mmapped buffer */
> +   flags |= O_RDWR;
> +   return drm_gem_prime_export(dev, obj, flags);
> +}
> +

 seems like this probably should be done more centrally..  and in fact,
 might be better to have something like this in
 drm_prime_handle_to_fd_ioctl:

 /* check flags are valid */
 -if (args->flags & ~DRM_CLOEXEC)
 +if (args->flags & ~(DRM_CLOEXEC | O_RDWR))
return -EINVAL;

 so exporter can specify whether to allow mmap or not.
>>>
>>> That makes sense I'll try this.
>>>
>>> Do we need to wrap O_RDWR in the same way we wrap O_CLOEXEC? (I don't
>>> really understand why DRM_CLOEXEC exists; even the patch description
>>> from when the symbol was introduced names it O_CLOEXEC).
>>
>> I *think* wrapping it w/ DRM_CLOEXEC was mostly just for purposes of
>> making it clear which flags are appropriate.. probably best to do the
>> same w/ a DRM_RDWR I guess
>>
>> BR,
>> -R
>>
>>> Also the "flags |= O_RDWR" approach is copied from the sti driver. I'll
>>> share a patch to remove it but that will definitely needs Benjamin's ack
>>> because it will stop some userspaces working correctly (however I
>>> suspect that Benjamin may be the only person currently with such a
>>> userspace and that he can be persuaded not to call it a regression).
>>>
>>>
>>> Daniel.
> 
> 
> 

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Joonsoo Kim]

On Tue, Nov 11, 2014 at 03:31:20PM -0800, Andrew Morton wrote:
> 
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> On Thu, 06 Nov 2014 17:28:41 + bugzilla-daemon at bugzilla.kernel.org 
> wrote:
> 
> > https://bugzilla.kernel.org/show_bug.cgi?id=87891
> > 
> > Bug ID: 87891
> >Summary: kernel BUG at mm/slab.c:2625!
> >Product: Memory Management
> >Version: 2.5
> > Kernel Version: 3.17.2
> >   Hardware: i386
> > OS: Linux
> >   Tree: Mainline
> > Status: NEW
> >   Severity: blocking
> >   Priority: P1
> >  Component: Slab Allocator
> >   Assignee: akpm at linux-foundation.org
> >   Reporter: luke-jr+linuxbugs at utopios.org
> > Regression: No
> 
> Well this is interesting.
> 
> 
> > [359782.842112] kernel BUG at mm/slab.c:2625!
> > ...
> > [359782.843008] Call Trace:
> > [359782.843017]  [] __kmalloc+0xdf/0x200
> > [359782.843037]  [] ? ttm_page_pool_free+0x35/0x180 [ttm]
> > [359782.843060]  [] ttm_page_pool_free+0x35/0x180 [ttm]
> > [359782.843084]  [] ttm_pool_shrink_scan+0xae/0xd0 [ttm]
> > [359782.843108]  [] shrink_slab_node+0x12b/0x2e0
> > [359782.843129]  [] ? fragmentation_index+0x14/0x70
> > [359782.843150]  [] ? zone_watermark_ok+0x1a/0x20
> > [359782.843171]  [] shrink_slab+0xc8/0x110
> > [359782.843189]  [] do_try_to_free_pages+0x300/0x410
> > [359782.843210]  [] try_to_free_pages+0xbb/0x190
> > [359782.843230]  [] __alloc_pages_nodemask+0x696/0xa90
> > [359782.843253]  [] do_huge_pmd_anonymous_page+0xfa/0x3f0
> > [359782.843278]  [] ? debug_smp_processor_id+0x17/0x20
> > [359782.843300]  [] ? __lru_cache_add+0x57/0xa0
> > [359782.843321]  [] handle_mm_fault+0x37e/0xdd0
> 
> It went pagefault
> ->__alloc_pages_nodemask
>   ->shrink_slab
> ->ttm_pool_shrink_scan
>   ->ttm_page_pool_free
> ->kmalloc
>   ->cache_grow
> ->BUG_ON(flags & GFP_SLAB_BUG_MASK);
> 
> And I don't really know why - I'm not seeing anything in there which
> can set a GFP flag which is outside GFP_SLAB_BUG_MASK.  However I see
> lots of nits.
> 
> Core MM:
> 
> __alloc_pages_nodemask() does
> 
>   if (unlikely(!page)) {
>   /*
>* Runtime PM, block IO and its error handling path
>* can deadlock because I/O on the device might not
>* complete.
>*/
>   gfp_mask = memalloc_noio_flags(gfp_mask);
>   page = __alloc_pages_slowpath(gfp_mask, order,
>   zonelist, high_zoneidx, nodemask,
>   preferred_zone, classzone_idx, migratetype);
>   }
> 
> so it permanently alters the value of incoming arg gfp_mask.  This
> means that the following trace_mm_page_alloc() will print the wrong
> value of gfp_mask, and if we later do the `goto retry_cpuset', we retry
> with a possibly different gfp_mask.  Isn't this a bug?
> 
> 
> Also, why are we even passing a gfp_t down to the shrinkers?  So they
> can work out the allocation context - things like __GFP_IO, __GFP_FS,
> etc?  Is it even appropriate to use that mask for a new allocation
> attempt within a particular shrinker?
> 
> 
> ttm:
> 
> I think it's a bad idea to be calling kmalloc() in the slab shrinker
> function.  We *know* that the system is low on memory and is trying to
> free things up.  Trying to allocate *more* memory at this time is
> asking for trouble.  ttm_page_pool_free() could easily be tweaked to
> use a fixed-size local array of page*'s t avoid that allocation.  Could
> someone implement this please?
> 
> 
> slab:
> 
> There's no point in doing
> 
>   #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> 
> because __GFP_DMA32|__GFP_HIGHMEM are already part of ~__GFP_BITS_MASK.
> What's it trying to do here?

Hello, Andrew.

__GFP_DMA32 and __GFP_HIGHMEM isn't included in ~__GFP_BITS_MASK.
~__GFP_BITS_MASK means all the high bits excluding all gfp bits.

As you already know, HIGHMEM isn't appropriate for slab because there
is no direct mapping on this memory. And, if we want memory only from
the memory on DMA32 area, specific kmem_cache is needed. But, there is
no interface for it, so allocation for DMA32 is also restricted here.

> 
> And it's quite infuriating to go BUG when the code could easily warn
> and fix it up.

If user wants memory on HIGHMEM, it can be easily fixed by following
change because all memory is compatible for HIGHMEM. But, if user wants
memory on DMA32, it's not easy to fix because memory on NORMAL isn't
compatible with DMA32. slab could return object from another slab page
even if cache_grow() is successfully called. So BUG_ON() here
looks right thing to me. We cannot know in advance whether ignoring this
flag cause more serious result or not.

> 
> And it's quite 

[PATCH v2 v3.18-rc4 2/4] drm: prime: Document gem_prime_mmap

[Rob Clark]

On Wed, Nov 12, 2014 at 6:38 AM, Daniel Thompson
 wrote:
> gem_prime_map is not currently described in the DRM manual, lets document
> it.
>
> Signed-off-by: Daniel Thompson 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_prime.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 8467b17c8053..5d00c8726133 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -309,7 +309,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   * Drivers can implement @gem_prime_export and @gem_prime_import in terms of
>   * simpler APIs by using the helper functions @drm_gem_prime_export and
>   * @drm_gem_prime_import.  These functions implement dma-buf support in 
> terms of
> - * five lower-level driver callbacks:
> + * six lower-level driver callbacks:
>   *
>   * Export callbacks:
>   *
> @@ -321,6 +321,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   *
>   *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
>   *
> + *  - @gem_prime_mmap (optional): mmap a buffer exported by your driver
> + *
>   * Import callback:
>   *
>   *  - @gem_prime_import_sg_table (import): produce a GEM object from another
> --
> 1.9.3
>

[PATCH v2 v3.18-rc4 1/4] drm: prime: Honour O_RDWR during prime-handle-to-fd

[Rob Clark]

On Wed, Nov 12, 2014 at 6:38 AM, Daniel Thompson
 wrote:
> Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
> (DRM|O)_CLOEXEC making it hard for the userspace to generate a file
> descriptor that can be used by mmap().
>
> It is easy to relax the restriction and allow read/write permissions.
> This should be safe because the flags are seldom touched by drm; mostly
> they are passed verbatim to dma_buf calls.
>
> Signed-off-by: Daniel Thompson 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_prime.c | 9 +++--
>  include/uapi/drm/drm.h  | 1 +
>  2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 78ca30808422..8467b17c8053 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -331,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   * drm_gem_prime_export - helper library implemention of the export callback
>   * @dev: drm_device to export from
>   * @obj: GEM object to export
> - * @flags: flags like DRM_CLOEXEC
> + * @flags: flags like DRM_CLOEXEC and DRM_RDWR
>   *
>   * This is the implementation of the gem_prime_export functions for GEM 
> drivers
>   * using the PRIME helpers.
> @@ -635,14 +635,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device 
> *dev, void *data,
> return -ENOSYS;
>
> /* check flags are valid */
> -   if (args->flags & ~DRM_CLOEXEC)
> +   if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
> return -EINVAL;
>
> -   /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
> -   flags = args->flags & DRM_CLOEXEC;
> -
> return dev->driver->prime_handle_to_fd(dev, file_priv,
> -   args->handle, flags, >fd);
> +   args->handle, args->flags, >fd);
>  }
>
>  int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index b0b855613641..89c2b68ddc51 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -660,6 +660,7 @@ struct drm_set_client_cap {
> __u64 value;
>  };
>
> +#define DRM_RDWR O_RDWR
>  #define DRM_CLOEXEC O_CLOEXEC
>  struct drm_prime_handle {
> __u32 handle;
> --
> 1.9.3
>

[PATCH v2 v3.18-rc4 3/4] drm: msm: Allow exported dma-bufs to be mapped

[Rob Clark]

On Wed, Nov 12, 2014 at 6:38 AM, Daniel Thompson
 wrote:
> Currently msm does not implement gem_prime_mmap. Without this it is not
> possible to draw onto a dma-buf from userspace (making its very hard to
> implement the Android rendering model).
>
> Fixing this is just a matter of adding a little boilerplate.

looks good.. I'll queue it up for my 3.19 pull req.  Thanks!

BR,
-R


> Signed-off-by: Daniel Thompson 
> ---
>  drivers/gpu/drm/msm/msm_drv.c   |  1 +
>  drivers/gpu/drm/msm/msm_drv.h   |  3 +++
>  drivers/gpu/drm/msm/msm_gem_prime.c | 13 +
>  3 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index b67ef5985125..5717d4ec1a2c 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -832,6 +832,7 @@ static struct drm_driver msm_driver = {
> .gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
> .gem_prime_vmap = msm_gem_prime_vmap,
> .gem_prime_vunmap   = msm_gem_prime_vunmap,
> +   .gem_prime_mmap = msm_gem_prime_mmap,
>  #ifdef CONFIG_DEBUG_FS
> .debugfs_init   = msm_debugfs_init,
> .debugfs_cleanup= msm_debugfs_cleanup,
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 67f9d0a2332c..1a7344066154 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -154,6 +154,8 @@ void msm_update_fence(struct drm_device *dev, uint32_t 
> fence);
>  int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
> struct drm_file *file);
>
> +int msm_gem_mmap_obj(struct drm_gem_object *obj,
> +   struct vm_area_struct *vma);
>  int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
>  int msm_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
>  uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj);
> @@ -170,6 +172,7 @@ int msm_gem_dumb_map_offset(struct drm_file *file, struct 
> drm_device *dev,
>  struct sg_table *msm_gem_prime_get_sg_table(struct drm_gem_object *obj);
>  void *msm_gem_prime_vmap(struct drm_gem_object *obj);
>  void msm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
> +int msm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct 
> *vma);
>  struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
> struct dma_buf_attachment *attach, struct sg_table *sg);
>  int msm_gem_prime_pin(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c 
> b/drivers/gpu/drm/msm/msm_gem_prime.c
> index ad772fe36115..dd7a7ab603e2 100644
> --- a/drivers/gpu/drm/msm/msm_gem_prime.c
> +++ b/drivers/gpu/drm/msm/msm_gem_prime.c
> @@ -37,6 +37,19 @@ void msm_gem_prime_vunmap(struct drm_gem_object *obj, void 
> *vaddr)
> /* TODO msm_gem_vunmap() */
>  }
>
> +int msm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct 
> *vma)
> +{
> +   int ret;
> +
> +   mutex_lock(>dev->struct_mutex);
> +   ret = drm_gem_mmap_obj(obj, obj->size, vma);
> +   mutex_unlock(>dev->struct_mutex);
> +   if (ret < 0)
> +   return ret;
> +
> +   return msm_gem_mmap_obj(vma->vm_private_data, vma);
> +}
> +
>  struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
> struct dma_buf_attachment *attach, struct sg_table *sg)
>  {
> --
> 1.9.3
>

[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM

[Konrad Rzeszutek Wilk]

On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> dma_alloc_coherent() returns a kernel virtual address that is part of
> the linear range. Passing such an address to virt_to_page() is illegal
> on non-coherent architectures. This causes the kernel to oops on 64-bit
> ARM because the struct page * obtained from virt_to_page() points to
> unmapped memory.

Oh! That is not good!
> 
> This commit fixes this by using phys_to_page() since we get a physical
> address from dma_alloc_coherent(). Note that this is not a proper fix
> because if an IOMMU is set up to translate addresses for the GPU this
> address will be an I/O virtual address rather than a physical one. The
> proper fix probably involves not getting a pointer to the struct page
> in the first place, but that would be a much more intrusive change, if
> at all possible.

What type of caching types are there on ARM? We use the 'struct page'
on the set_pages_to_[wc|uc|wb] but all of those are X86 specfic.

But I think you could by passing the 'struct dma_page' instead
of 'struct page' (and the array uses) around. That should solve
the touching of 'struct page' and we can treat it as an opaque
type.
> 
> Until that time, this temporary fix will allow TTM to work on 32-bit
> and 64-bit ARM as well, provided that no IOMMU translations are enabled
> for the GPU.

Is there a way to query the 'struct device' to see if the IOMMU translation
is enabled/disabled for said device?

Now your patch looks to get the 'struct page' by doing some  form of
translation. Could you explain to me which type of memory have a 'struct page'
and which ones do not ?

It is OK if you explain this in nauseating details :-)

> 
> Signed-off-by: Thierry Reding 
> ---
> Arnd, I realize that this isn't a proper fix according to what we discussed on
> IRC yesterday, but I can't see a way to remove access to the pages array that
> would be as simple as this. I've marked this as RFC in the hope that it will
> trigger some discussion that will lead to a proper solution.
> 
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index c96db433f8af..d7993985752c 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -343,7 +343,11 @@ static struct dma_page *__ttm_dma_alloc_page(struct 
> dma_pool *pool)
>  _page->dma,
>  pool->gfp_flags);
>   if (d_page->vaddr)
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> + d_page->p = phys_to_page(d_page->dma);
> +#else
>   d_page->p = virt_to_page(d_page->vaddr);
> +#endif
>   else {
>   kfree(d_page);
>   d_page = NULL;
> -- 
> 2.1.3
> 

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

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

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

--- Comment #24 from Hannu  ---
(In reply to Michel Dänzer from comment #19)
> Created attachment 109261 [details] [review]
> radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
> 
> Can you test this patch as well?

Tested with a 23 minute full screen flash video same as before.

Mesa 10.3.2 with the "radeonsi: Disable asynchronous DMA except for
PIPE_BUFFER"-patch: 10 playbacks of the video, no crashes/lockups.

I think the patch makes mesa stable at least for flash videos, no further
testing needed for this patch.

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

[PATCH] drm: More specific locking for get* ioctls

[Daniel Vetter]

Motivated by the per-plane locking I've gone through all the get*
ioctls and reduced the locking to the bare minimum required.

v2: Rebase and make it compile ...

v3: Review from Sean:
- Simplify return handling in getplane_res.
- Add a comment to getplane_res that the plane list is invariant and
  can be walked locklessly.

v4: Actually git add.

Cc: Sean Paul 
Reviewed-by: Sean Paul 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 58 ++
 1 file changed, 23 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3652ed8dda80..2beb219df1bd 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1743,7 +1743,9 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
card_res->count_fbs = fb_count;
mutex_unlock(_priv->fbs_lock);

-   drm_modeset_lock_all(dev);
+   /* mode_config.mutex protects the connector list against e.g. DP MST
+* connector hot-adding. CRTC/Plane lists are invariant. */
+   mutex_lock(>mode_config.mutex);
if (!drm_is_primary_client(file_priv)) {

mode_group = NULL;
@@ -1863,7 +1865,7 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
  card_res->count_connectors, card_res->count_encoders);

 out:
-   drm_modeset_unlock_all(dev);
+   mutex_unlock(>mode_config.mutex);
return ret;
 }

@@ -1890,14 +1892,11 @@ int drm_mode_getcrtc(struct drm_device *dev,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   drm_modeset_lock_all(dev);
-
crtc = drm_crtc_find(dev, crtc_resp->crtc_id);
-   if (!crtc) {
-   ret = -ENOENT;
-   goto out;
-   }
+   if (!crtc)
+   return -ENOENT;

+   drm_modeset_lock_crtc(crtc, crtc->primary);
crtc_resp->x = crtc->x;
crtc_resp->y = crtc->y;
crtc_resp->gamma_size = crtc->gamma_size;
@@ -1914,9 +1913,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
} else {
crtc_resp->mode_valid = 0;
}
+   drm_modeset_unlock_crtc(crtc);

-out:
-   drm_modeset_unlock_all(dev);
return ret;
 }

@@ -2100,24 +2098,22 @@ int drm_mode_getencoder(struct drm_device *dev, void 
*data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   drm_modeset_lock_all(dev);
encoder = drm_encoder_find(dev, enc_resp->encoder_id);
-   if (!encoder) {
-   ret = -ENOENT;
-   goto out;
-   }
+   if (!encoder)
+   return -ENOENT;

+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
if (encoder->crtc)
enc_resp->crtc_id = encoder->crtc->base.id;
else
enc_resp->crtc_id = 0;
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
enc_resp->encoder_type = encoder->encoder_type;
enc_resp->encoder_id = encoder->base.id;
enc_resp->possible_crtcs = encoder->possible_crtcs;
enc_resp->possible_clones = encoder->possible_clones;

-out:
-   drm_modeset_unlock_all(dev);
return ret;
 }

@@ -2141,13 +2137,12 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
struct drm_mode_config *config;
struct drm_plane *plane;
uint32_t __user *plane_ptr;
-   int copied = 0, ret = 0;
+   int copied = 0;
unsigned num_planes;

if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   drm_modeset_lock_all(dev);
config = >mode_config;

if (file_priv->universal_planes)
@@ -2163,6 +2158,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
(plane_resp->count_planes >= num_planes)) {
plane_ptr = (uint32_t __user *)(unsigned 
long)plane_resp->plane_id_ptr;

+   /* Plane lists are invariant, no locking needed. */
list_for_each_entry(plane, >plane_list, head) {
/*
 * Unless userspace set the 'universal planes'
@@ -2172,18 +2168,14 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
!file_priv->universal_planes)
continue;

-   if (put_user(plane->base.id, plane_ptr + copied)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   if (put_user(plane->base.id, plane_ptr + copied))
+   return -EFAULT;
copied++;
}
}
plane_resp->count_planes = num_planes;

-out:
-   drm_modeset_unlock_all(dev);
-   return ret;
+   return 0;
 }

 /**
@@ -2210,13 +2202,11 @@ int drm_mode_getplane(struct drm_device *dev, void 
*data,
if 

[Bug 86038] [radeonsi] Dreamfall Chapters: heavy visual corruption, large parts of the screen are black in some scenes

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

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

--- Comment #16 from Kai  ---
Created attachment 109319
  --> https://bugs.freedesktop.org/attachment.cgi?id=109319=edit
No visual corruption on Intel (Sandybridge)

Just FYI: I had the chance to test the game on an Intel Sandybridge system and
there's no visible visual corruption in the same scene (even if it's not the
same frame). So the shader is probably ok?

The Mesa version running on that system, is a bit older though: 10.4-devel,
commit 5ccdc23a86 (and a build from 2014-09-28).

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

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Kirill A. Shutemov]

On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote:
> On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter  > > linux.com> wrote:
> > > 
> > > > On Tue, 11 Nov 2014, Andrew Morton wrote:
> > > > 
> > > > > There's no point in doing
> > > > >
> > > > >   #define GFP_SLAB_BUG_MASK 
> > > > > (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> > > > >
> > > > > because __GFP_DMA32|__GFP_HIGHMEM are already part of 
> > > > > ~__GFP_BITS_MASK.
> > > > 
> > > > ?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
> > > > 
> > > > __GFP_DMA32 is bit 2 and __GFP_HIGHMEM is bit 1.
> > > 
> > > Ah, yes, OK.
> > > 
> > > I suppose it's possible that __GFP_HIGHMEM was set.
> > > 
> > > do_huge_pmd_anonymous_page
> > > ->pte_alloc_one
> > >   ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)
> > 
> > do_huge_pmd_anonymous_page
> >  alloc_hugepage_vma
> >   alloc_pages_vma(GFP_TRANSHUGE)
> > 
> > GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.
> 
> Hello, Kirill.
> 
> BTW, why does GFP_TRANSHUGE have MOVABLE flag despite it isn't
> movable? After breaking hugepage, it could be movable, but, it may
> prevent CMA from working correctly until break.

Again, the same alloc vs. free gfp_mask: we want page allocator to move
pages around to find space from THP, but resulting page is no really
movable.

I've tried to look into making THP movable: it requires quite a bit of
infrastructure changes around rmap: try_to_unmap*(), remove_migration_pmd(),
migration entries for PMDs, etc. I gets ugly pretty fast :-/
I probably need to give it second try. No promises.

-- 
 Kirill A. Shutemov

[Bug 86089] [r600g][mesa 10.4.0-dev] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

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

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

Shawn Starr  changed:

   What|Removed |Added

Summary|[r600g] shader failure -|[r600g][mesa 10.4.0-dev]
   |r600_sb::bc_finalizer::cf_p |shader failure -
   |eephole() when starting |r600_sb::bc_finalizer::cf_p
   |Second Life |eephole() when starting
   ||Second Life

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

[Bug 86089] [r600g] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

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

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

--- Comment #3 from Shawn Starr  ---
A second bisect, repeated this. So this is the commit that breaks r600 SB
compiler.

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

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Kirill A. Shutemov]

On Tue, Nov 11, 2014 at 05:56:03PM -0800, Andrew Morton wrote:
> On Wed, 12 Nov 2014 03:47:03 +0200 "Kirill A. Shutemov"  shutemov.name> wrote:
> 
> > On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter  > > > linux.com> wrote:
> > > > 
> > > > > On Tue, 11 Nov 2014, Andrew Morton wrote:
> > > > > 
> > > > > > There's no point in doing
> > > > > >
> > > > > > #define GFP_SLAB_BUG_MASK 
> > > > > > (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> > > > > >
> > > > > > because __GFP_DMA32|__GFP_HIGHMEM are already part of 
> > > > > > ~__GFP_BITS_MASK.
> > > > > 
> > > > > ?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
> > > > > 
> > > > > __GFP_DMA32 is bit 2 and __GFP_HIGHMEM is bit 1.
> > > > 
> > > > Ah, yes, OK.
> > > > 
> > > > I suppose it's possible that __GFP_HIGHMEM was set.
> > > > 
> > > > do_huge_pmd_anonymous_page
> > > > ->pte_alloc_one
> > > >   ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)
> > > 
> > > do_huge_pmd_anonymous_page
> > >  alloc_hugepage_vma
> > >   alloc_pages_vma(GFP_TRANSHUGE)
> > > 
> > > GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.
> > 
> > Looks like it's reasonable to sanitize flags in shrink_slab() by dropping
> > flags incompatible with slab expectation. Like this:
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index dcb47074ae03..eb165d29c5e5 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -369,6 +369,8 @@ unsigned long shrink_slab(struct shrink_control 
> > *shrinkctl,
> > if (nr_pages_scanned == 0)
> > nr_pages_scanned = SWAP_CLUSTER_MAX;
> >  
> > +   shrinkctl->gfp_mask &= ~(__GFP_DMA32 | __GFP_HIGHMEM);
> > +
> > if (!down_read_trylock(_rwsem)) {
> > /*
> >  * If we would return 0, our callers would understand that 
> > we
> 
> Well no, because nobody is supposed to be passing this gfp_mask back
> into a new allocation attempt anyway.  It would be better to do
> 
>   shrinkctl->gfp_mask |= __GFP_IMMEDIATELY_GO_BUG;
> 
> ?

>From my POV, the problem is that we combine what-need-to-be-freed gfp_mask
with if-have-to-allocate gfp_mask: we want to respect __GFP_IO/FS on
alloc, but not nessesary both if there's no restriction from the context.

For shrink_slab(), __GFP_DMA32 and __GFP_HIGHMEM don't make sense in both
cases.

__GFP_IMMEDIATELY_GO_BUG would work too, but we also need to provide
macros to construct alloc-suitable mask from the given one for
yes-i-really-have-to-allocate case.

-- 
 Kirill A. Shutemov

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Kirill A. Shutemov]

On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter  > linux.com> wrote:
> > 
> > > On Tue, 11 Nov 2014, Andrew Morton wrote:
> > > 
> > > > There's no point in doing
> > > >
> > > > #define GFP_SLAB_BUG_MASK 
> > > > (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> > > >
> > > > because __GFP_DMA32|__GFP_HIGHMEM are already part of ~__GFP_BITS_MASK.
> > > 
> > > ?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
> > > 
> > > __GFP_DMA32 is bit 2 and __GFP_HIGHMEM is bit 1.
> > 
> > Ah, yes, OK.
> > 
> > I suppose it's possible that __GFP_HIGHMEM was set.
> > 
> > do_huge_pmd_anonymous_page
> > ->pte_alloc_one
> >   ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)
> 
> do_huge_pmd_anonymous_page
>  alloc_hugepage_vma
>   alloc_pages_vma(GFP_TRANSHUGE)
> 
> GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.

Looks like it's reasonable to sanitize flags in shrink_slab() by dropping
flags incompatible with slab expectation. Like this:

diff --git a/mm/vmscan.c b/mm/vmscan.c
index dcb47074ae03..eb165d29c5e5 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -369,6 +369,8 @@ unsigned long shrink_slab(struct shrink_control *shrinkctl,
if (nr_pages_scanned == 0)
nr_pages_scanned = SWAP_CLUSTER_MAX;

+   shrinkctl->gfp_mask &= ~(__GFP_DMA32 | __GFP_HIGHMEM);
+
if (!down_read_trylock(_rwsem)) {
/*
 * If we would return 0, our callers would understand that we
-- 
 Kirill A. Shutemov

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Kirill A. Shutemov]

On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter  
> wrote:
> 
> > On Tue, 11 Nov 2014, Andrew Morton wrote:
> > 
> > > There's no point in doing
> > >
> > >   #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> > >
> > > because __GFP_DMA32|__GFP_HIGHMEM are already part of ~__GFP_BITS_MASK.
> > 
> > ?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
> > 
> > __GFP_DMA32 is bit 2 and __GFP_HIGHMEM is bit 1.
> 
> Ah, yes, OK.
> 
> I suppose it's possible that __GFP_HIGHMEM was set.
> 
> do_huge_pmd_anonymous_page
> ->pte_alloc_one
>   ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)

do_huge_pmd_anonymous_page
 alloc_hugepage_vma
  alloc_pages_vma(GFP_TRANSHUGE)

GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.

-- 
 Kirill A. Shutemov

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

[Luke Dashjr]

On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> But anyway - Luke, please attach your .config to
> https://bugzilla.kernel.org/show_bug.cgi?id=87891?

Done: https://bugzilla.kernel.org/attachment.cgi?id=157381

Luke