[PATCH v7 7/7] dt-bindings: add document for dw-hdmi

[Andy Yan]

On 2014年11月11日 22:40, Zubair Lutfullah Kakakhel wrote:
> Hi Andy,
>
> Some minor comments inline.
>
> On 11/11/14 12:54, Andy Yan wrote:
>> Signed-off-by: Andy Yan 
>> ---
>>
>> 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 | 38 
>> ++
>>   1 file changed, 38 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..aa7ed17
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt
>> @@ -0,0 +1,38 @@
>> +DesignWare HDMI bridge bindings
>> +
>> +Required properities:
>   
>   ^properties
>
>> +- compatibel: platform specific such as "fsl,imx6q-hdmi","fsl,imx6dl-hdmi"
>   ^compatible
   thanks , these will be fixed next.
>> +  "rockchip,rk3288-dw-hdmi"
> This will need to come in a separate series which adds rk3288 hdmi support..
  we will add rk3288 hdmi platform code soon
>
>> +- reg: physical base address of the controller and length
>> +- ddc-i2c-bus: the ddc i2c bus
>> +- interrupts: The interrupt number to the cpu
>> +
>> +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>;
>> +};
>> +};
>> +};
>>
> Thanks
> ZubairLK
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>

[PATCH v7 6/7] drm: bridge/dw-hdmi: convert dw-hdmi to drm_bridge mode

[Andy Yan]

Hi ZubairLK:
On 2014年11月11日 22:36, Zubair Lutfullah Kakakhel wrote:
> Hi Andy,
>
> On 11/11/14 12:54, Andy Yan wrote:
>> From: Yakir Yang 
>>
>> keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c
> Is there a reason for this separation? Keeping encoder in platform files?
> If yes, then the commit message should explain that.
in the encoder, most operation are platform specific, such as
   mux to select which crtc is used,  set panel format etc, these operation
   complete by platform specific interface
>> Signed-off-by: Andy Yan 
>> Signed-off-by: Yakir Yang 
>>
>> ---
>>
>> 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(-)
>
> Regards
> ZubairLK
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

[Andy Yan]

On 2014年11月11日 22:20, Zubair Lutfullah Kakakhel wrote:
> Hi Andy,
>
> This patch adds the reg-io-width binding.
>
> Hence the binding patch should come before it.
>
do you mean that I should put dts binding patch
before this patch?
> On 11/11/14 12:53, Andy Yan wrote:
>> 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 
>>
>> ---
>>
>>   }
>>   
>>   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;
>> +}
> The binding patch says this is an optional property.
> But here if undefined it returns -EINVAL.
>
> I would keep it optional and default it to byte access.
   if the dts undefined it, the val will be 1.
   if the dts defined other value except 4 and 1, return -EINVAL
>
> Regards,
> ZubairLK
>
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>

[PATCH v7 4/7] staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw-hdmi

[Andy Yan]

On 2014年11月11日 22:16, Zubair Lutfullah Kakakhel wrote:
> Hi Andy,
>
> On 11/11/14 12:53, Andy Yan wrote:
>> the original imx hdmi driver is under staging/imx-drm,
>> which depends on imx-drm, so move the imx hdmi drvier out
> Spelling mistake. ^'driver'
>
>> to drm/bridge and rename imx-hdmi to dw-hdmi
> ^dw_hdmi
  thanks , these will be fixed in v8
>> Signed-off-by: Andy Yan 
>>
>> ---
>>
>> 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
> ...
>
>> diff --git a/drivers/staging/imx-drm/imx-hdmi.h 
>> b/drivers/gpu/drm/bridge/dw_hdmi.h
>> similarity index 97%
>> rename from drivers/staging/imx-drm/imx-hdmi.h
>> rename to drivers/gpu/drm/bridge/dw_hdmi.h
>> index e67d60d..b8412a9 100644
>> --- a/drivers/staging/imx-drm/imx-hdmi.h
>> +++ b/drivers/gpu/drm/bridge/dw_hdmi.h
>> @@ -7,8 +7,8 @@
>>* (at your option) any later version.
>>*/
>>   
>> -#ifndef __IMX_HDMI_H__
>> -#define __IMX_HDMI_H__
>> +#ifndef __DW_HDMI__
>> +#define __DW_HDMI__
>>   
>>   /* Identification Registers */
>>   #define HDMI_DESIGN_ID  0x
>> @@ -1030,46 +1030,4 @@ enum {
>>  HDMI_A_VIDPOLCFG_HSYNCPOL_ACTIVE_LOW = 0x0,
>>   };
>>   
>> -enum {
>> -RES_8,
>> -RES_10,
>> -RES_12,
>> -RES_MAX,
>> -};
>> -
>> -enum imx_hdmi_devtype {
>> -IMX6Q_HDMI,
>> -IMX6DL_HDMI,
>> -};
>> -
>> -struct mpll_config {
>> -unsigned long mpixelclock;
>> -struct {
>> -u16 cpce;
>> -u16 gmp;
>> -} res[RES_MAX];
>> -};
>> -
>> -struct curr_ctrl {
>> -unsigned long mpixelclock;
>> -u16 curr[RES_MAX];
>> -};
>> -
>> -struct imx_hdmi_plat_data {
>> -void * (*setup)(struct platform_device *pdev);
>> -void (*exit)(void *priv);
>> -void (*encoder_commit)(void *priv, struct drm_encoder *encoder);
>> -void (*encoder_prepare)(struct drm_connector *connector,
>> -struct drm_encoder *encoder);
>> -enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
>> -   struct drm_display_mode *mode);
>> -const struct mpll_config *mpll_cfg;
>> -const struct curr_ctrl *cur_ctr;
>> -enum imx_hdmi_devtype dev_type;
>> -
>> -};
>> -
>> -int imx_hdmi_platform_register(struct platform_device *pdev,
>> -   const struct imx_hdmi_plat_data *plat_data);
>> -int imx_hdmi_platform_unregister(struct platform_device *pdev);
> Doesn't this change belong in the previous splitting patch?
 in previous splitting patch we put these in staging/imx-drm/imx-hdmi.h
now we move 

[RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

Hi Inki,

On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae  wrote:
>
> Hi,
>
> Fortunately, I could get the user manual for Exynos7420. Below are my
> comments.
>
> Thanks,
> Inki Dae
>
> On 2014년 10월 23일 01:34, Ajay kumar wrote:
>> On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae  wrote:
>>>
>>> Thanks for contribution.
>>>
>>> It seems reasonable that you separate device drivers into FIMD and DECON
>>> because many registers of them have many different offsets and fields.
>>> However, there may be a good solution that we can combine common sets of
>>> these drivers later.
>> Yes, this is the main reason behind sending this as RFC patch.
>> I want to know what's the best way to do this.
>> FIMD, 5433 DECON and Exynos7 DECON - all are different.
>> Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer).
>> So, even I am not sure how the driver layouts should be!
>
> Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my
> understanding, Exynos7 doesn't mean one real SoC.
We shall use Exynos7 as per the discussion.

>>
>>> Below are my comments.
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>> On 2014년 10월 10일 21:48, Ajay Kumar wrote:
 This series is based on exynos-drm-next branch of Inki Dae's tree at:
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

 DECON(Display and Enhancement Controller) is the new IP
 in exynos7 SOC for generating video signals using pixel data.
>>>
>>> DECON was used since Exynos5430. And is Exynos5433 different from
>>> Exynos7? If so, could I get the Exynos7 user manual (TRM) for review?
>> Yes, Exynos5433 DECON is very much different than Exynos7 DECON.
>
> Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead.
Again, we shall use Exynos7.

>> I will see how manual can be arranged.
>>

 DECON driver can be used to drive 2 different interfaces on Exynos7:
 DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)

 The existing FIMD driver code was used as a template to create
 DECON driver. Only DECON-INT is supported as of now, and
 DECON-EXT support will be added later.

 Signed-off-by: Akshu Agrawal 
 Signed-off-by: Ajay Kumar 
 ---
  .../devicetree/bindings/video/exynos-decon.txt |   68 ++
  drivers/gpu/drm/exynos/Kconfig |   11 +-
  drivers/gpu/drm/exynos/Makefile|1 +
  drivers/gpu/drm/exynos/exynos_drm_decon.c  | 1086
>>> 
  drivers/gpu/drm/exynos/exynos_drm_drv.c|   17 +-
  drivers/gpu/drm/exynos/exynos_drm_drv.h|   11 +
  include/video/samsung_decon.h  |  346 +++
  7 files changed, 1537 insertions(+), 3 deletions(-)
  create mode 100644
>>> Documentation/devicetree/bindings/video/exynos-decon.txt
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
  create mode 100644 include/video/samsung_decon.h

 diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt
>>> b/Documentation/devicetree/bindings/video/exynos-decon.txt
 new file mode 100644
 index 000..e865650
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
 @@ -0,0 +1,68 @@
 +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
 +
 +DECON (Display and Enhancement Controller) is the Display Controller
>>> for the
 +Exynos7 series of SoCs which transfers the image data from a video memory
 +buffer to an external LCD interface.
 +
 +Required properties:
 +- compatible: value should be "samsung,exynos7-decon";
>>>
>>> If exynos5433 was just renamed to exynos7 then, it should be one of the
>>> following:
>>> (a) "samsung,exynos5430-decon" for Display and enhancement 
>>> controller
>>> IP for Exynos5430
>>> (b) "samsung,exynos7" for Display and enhancement controller IP for 
>>> Exynos7
>>>
>>> Or,
>>> (a) "samsung,exynos5430-decon" for Display and enhancement 
>>> controller
>>> IP for Exynos5430
>>>
>>> (b) "samsung,exynos5433-decon" for Display and enhancement 
>>> controller
>>> IP for Exynos5433
>>> (c) "samsung,exynos7" for Display and enhancement controller IP for 
>>> Exynos7
>> Eventually, we will end up here.
>>
>>>
 +
 +- reg: physical base address and length of the DECON registers set.
 +
 +- interrupt-parent: should be the phandle of the decon controller's
 + parent interrupt controller.
 +
 +- interrupts: should contain a list of all DECON IP block interrupts
>>> in the
 +  order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt 
 specifier
 +  format depends on the interrupt controller used.
 +
 +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
 + "lcd_sys", in the same order as they were listed in the interrupts
 +property.
 +
 +- pinctrl-0: pin 

[Bug 85376] Dolphin emulator has bad colors

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

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

--- Comment #11 from Glenn Kennard  ---
Created attachment 109308
  --> https://bugs.freedesktop.org/attachment.cgi?id=109308=edit
Proposed fix

Does the attached patch fix the issue?

-- 
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/2014/88f7a4e3/attachment.html>

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

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

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

--- Comment #23 from boombatower  ---
I tested attachment 108943 (coming from
https://bugs.freedesktop.org/show_bug.cgi?id=85866) which solved the issues for
me as well. Radeon HD 7970.

-- 
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/20141111/4a8d320c/attachment.html>

[PATCH v7 7/7] dt-bindings: add document for dw-hdmi

[Andy Yan]

Signed-off-by: Andy Yan 
---

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 | 38 ++
 1 file changed, 38 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..aa7ed17
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt
@@ -0,0 +1,38 @@
+DesignWare HDMI bridge bindings
+
+Required properities:
+- compatibel: 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: the ddc i2c bus
+- interrupts: The interrupt number to the cpu
+
+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 3/6] x86: Add support for the clwb instruction

[Borislav Petkov]

On Tue, Nov 11, 2014 at 12:48:52PM -0700, Ross Zwisler wrote:
> Essentially we need one additional byte at the beginning of the clflush so
> that we can flip it into a clflushopt by changing that byte into a 0x66
> prefix.  Two options are to either insert a 1 byte ASM_NOP1, or to add a 1
> byte NOP_DS_PREFIX.  Both have no functional effect with the plain clflush,
> but I've been told that executing a clflush + prefix should be faster than
> executing a clflush + NOP.

I see. :)

Thanks.

-- 
Regards/Gruss,
Boris.

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

[PATCH v7 6/7] 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

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

---

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,
-};
-
-static struct drm_encoder_helper_funcs dw_hdmi_encoder_helper_funcs = {
-   .dpms = dw_hdmi_encoder_dpms,
-   

[PATCH v7 5/7] 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 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 v7 4/7] 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 drvier out
to drm/bridge and rename imx-hdmi to dw-hdmi

Signed-off-by: Andy Yan 

---

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 long pixel_clk,
  

[PATCH v7 3/7] 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 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 ERR_PTR(ret);
+   }
+
+

[PATCH v7 2/7] 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 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 v7 1/7] 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 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 

LibDRM Cloned Monitor Support

[Rob Clark]

On Tue, Nov 11, 2014 at 8:40 PM, Rian Quinn  wrote:
> Right now I need to support Intel and AMD, and nVidia would be a great plus 
> with VMWare being my sudo dev/test environment on travel. I have control of 
> the kernel so it’s whatever I need.
>
> Can you point me to the “atomic-helpers” stuff. I have never heard of 
> that. Is that exposed via LibDRM?
>

well, right now, it is a pull-req for 3.19
(http://lists.freedesktop.org/archives/dri-devel/2014-November/071623.html)
and ongoing driver work.. new userspace API or libdrm bits are not in
place yet, but hopefully following in next kernel version or two.  I'd
expect support earlier for i915 and various other SoC hw.

For now, for hw which advertises plane support (I think some
generations for i915 and nouveau?  not really sure offhand about
radeon) you could use an overlay plane in addition to dummy crtc
scanout fb.

BR,
-R

> Thanks,
> - Rian
>
>> On Nov 11, 2014, at 8:35 PM, Rob Clark  wrote:
>>
>> On Tue, Nov 11, 2014 at 8:25 PM, Rian Quinn  wrote:
>>> Yeah, I had issues trying to get the first method to work across the board 
>>> on all of the hardware that we need to support. One example that I saw was 
>>> to use the second method, and then to use planes when you had to scale. So 
>>> basically, if you could not find a match, you would select the lowest of 
>>> the resolutions, and then setup planes for the ones that need to be scaled. 
>>> From what I can see, this will end up consuming an extra frame buffer, but 
>>> it takes care of the issue.
>>>
>>> Do you see any issues with that approach?
>>>
>>
>> This is basically a recent approach (meaning not necessarily supported
>> by all drivers, etc).. with the primary-plane feature you could even
>> configure the primary scanout layer via the plane API (but, keep in
>> mind, scaling is not something all hw supports).  The new
>> 'atomic-helpers' stuff should help with exposing support for hw that
>> can do scaling on primary layer.
>>
>> So in the end, it depends on what hw, and what kernel versions, you
>> need to support.  You may need to fallback to cropping without scaling
>> if you need to support everything.  But one of the goals with the
>> 'atomic' work is to make it easier to expose scaling support on hw
>> that can do it.
>>
>>> Thanks,
>>> - Rian
>>>
 On Nov 11, 2014, at 8:10 PM, Rob Clark  wrote:

 On Tue, Nov 11, 2014 at 12:19 PM, Rian Quinn  
 wrote:
> What exactly is the correct way to support cloned monitors using LibDRM. 
> As
> I see it, there are two methods:
>
> - Use the connector array in drmModeSetCrtc
> - Use one crtc per connector, but share the same framebuffer.
>
> Right now I am using option #2 as it seems to be the most flexible, but my
> current issue is that on laptops, the connector for the laptop's main 
> screen
> is only retuning 1 mode (tested on a Lenovo, and an HP folio), which means
> that your unlikely to find a common mode between the laptop monitor, and 
> an
> external screen (monitor or projector).

 #2 is the method that will work on all hw..  usually DE's will pick
 the closest matching modes between the two connectors/outputs, and
 truncate edges on the smaller display (via non-zero x/y offset).  Some
 hw may support upscaling to fit, although that isn't really exposed in
 a completely standard way at the moment.

 BR,
 -R

> So with the above problem, right now the only thing that I know to do 
> would
> be to set the resolution of the laptop monitor and external monitor to be
> their "preferred" resolution, and then copy and scale for "cloned mode"
> which seems like a terrible idea considering the laptop monitor should be
> able to set itself to some more basic resolutions (like 800x600).
>
> - Rian
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>>>
>

[PATCH v7 0/7] dw-hdmi: convert imx hdmi to bridge/dw-hdmi

[Andy Yan]

We found freescale imx5 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 do 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
And we will add rockchip platform specific code dw_hdmi-rockchip.c later,
which is depend on drm-rockchip.

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 (6):
  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
  drm: bridge/dw-hdmi: add support for multi byte register width access
  dt-bindings: add document for dw-hdmi

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

 .../devicetree/bindings/drm/bridge/dw-hdmi.txt |  38 ++
 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 723 +
 .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}|   5 +-
 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   |  52 ++
 9 files changed, 670 insertions(+), 423 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt
 rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c} (71%)
 rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h} (99%)
 create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c
 create mode 100644 include/drm/bridge/dw_hdmi.h

-- 
1.9.1

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

[Borislav Petkov]

On Tue, Nov 11, 2014 at 12:40:00PM -0700, Ross Zwisler wrote:
> Yep, it's weird, I know.  :)

But sure, saving opcode space, makes sense to me.

Btw, I'd still be interested about this:

> +static inline void clwb(volatile void *__p)
> +{
> + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",

Any particular reason for using 0x3e as a prefix to have the insns be
the same size or is it simply because CLFLUSH can stomach it?

Thanks.

-- 
Regards/Gruss,
Boris.

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

LibDRM Cloned Monitor Support

[Rian Quinn]

Right now I need to support Intel and AMD, and nVidia would be a great plus 
with VMWare being my sudo dev/test environment on travel. I have control of the 
kernel so it’s whatever I need. 

Can you point me to the “atomic-helpers” stuff. I have never heard of that. 
Is that exposed via LibDRM?

Thanks,
- Rian

> On Nov 11, 2014, at 8:35 PM, Rob Clark  wrote:
> 
> On Tue, Nov 11, 2014 at 8:25 PM, Rian Quinn  wrote:
>> Yeah, I had issues trying to get the first method to work across the board 
>> on all of the hardware that we need to support. One example that I saw was 
>> to use the second method, and then to use planes when you had to scale. So 
>> basically, if you could not find a match, you would select the lowest of the 
>> resolutions, and then setup planes for the ones that need to be scaled. From 
>> what I can see, this will end up consuming an extra frame buffer, but it 
>> takes care of the issue.
>> 
>> Do you see any issues with that approach?
>> 
> 
> This is basically a recent approach (meaning not necessarily supported
> by all drivers, etc).. with the primary-plane feature you could even
> configure the primary scanout layer via the plane API (but, keep in
> mind, scaling is not something all hw supports).  The new
> 'atomic-helpers' stuff should help with exposing support for hw that
> can do scaling on primary layer.
> 
> So in the end, it depends on what hw, and what kernel versions, you
> need to support.  You may need to fallback to cropping without scaling
> if you need to support everything.  But one of the goals with the
> 'atomic' work is to make it easier to expose scaling support on hw
> that can do it.
> 
>> Thanks,
>> - Rian
>> 
>>> On Nov 11, 2014, at 8:10 PM, Rob Clark  wrote:
>>> 
>>> On Tue, Nov 11, 2014 at 12:19 PM, Rian Quinn  wrote:
 What exactly is the correct way to support cloned monitors using LibDRM. As
 I see it, there are two methods:
 
 - Use the connector array in drmModeSetCrtc
 - Use one crtc per connector, but share the same framebuffer.
 
 Right now I am using option #2 as it seems to be the most flexible, but my
 current issue is that on laptops, the connector for the laptop's main 
 screen
 is only retuning 1 mode (tested on a Lenovo, and an HP folio), which means
 that your unlikely to find a common mode between the laptop monitor, and an
 external screen (monitor or projector).
>>> 
>>> #2 is the method that will work on all hw..  usually DE's will pick
>>> the closest matching modes between the two connectors/outputs, and
>>> truncate edges on the smaller display (via non-zero x/y offset).  Some
>>> hw may support upscaling to fit, although that isn't really exposed in
>>> a completely standard way at the moment.
>>> 
>>> BR,
>>> -R
>>> 
 So with the above problem, right now the only thing that I know to do would
 be to set the resolution of the laptop monitor and external monitor to be
 their "preferred" resolution, and then copy and scale for "cloned mode"
 which seems like a terrible idea considering the laptop monitor should be
 able to set itself to some more basic resolutions (like 800x600).
 
 - Rian
 
 ___
 dri-devel mailing list
 dri-devel at lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
 
>> 

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

[Andrew Morton]

On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa  wrote:

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

Well no - ttm_page_pool_free() should stop calling kmalloc altogether. 
Just do

struct page *pages_to_free[16];

and rework the code to free 16 pages at a time.  Easy.

Apart from all the other things we're discussing here, it should do
this because kmalloc() isn't very reliable within a shrinker.


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

Yes, there are such problems.

Shrinkers do all sorts of surprising things - some of the filesystem
ones do disk writes!  And these involve all sorts of locking and memory
allocations.  But they won't be directly using scan_control.gfp_mask. 
They may be using open-coded __GFP_NOFS for the allocations.  The
complicated ones pass the IO over to kernel threads and wait for them
to complete, which addresses the stack consumption concerns (at least).

[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

Kai  changed:

   What|Removed |Added

   Assignee|aarnsgonzales at gmail.com |dri-devel at 
lists.freedesktop
   ||.org

--- Comment #15 from Kai  ---
Resetting assignee, which Alexandre must have taken by accident.

(In reply to Alexandre from comment #14)
> What must I do to adopt or switch in my machine to a open-source driver then?
> 
> PS: what's a AFAIK?

I've answered both your questions by private e-mail.

-- 
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/2014/651a2ddf/attachment.html>

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

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

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

--- Comment #9 from Vitaliy Filippov  ---
Maybe... so the only thing that is left is to get response from someone who can
fix it? :)

It's also interesting that the same commit
e9822f77a9cc024f528d30382fd5ad21c73a173b is also mentioned in bug 77288...

-- 
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/20141111/768359ea/attachment.html>

LibDRM Cloned Monitor Support

[Rob Clark]

On Tue, Nov 11, 2014 at 8:25 PM, Rian Quinn  wrote:
> Yeah, I had issues trying to get the first method to work across the board on 
> all of the hardware that we need to support. One example that I saw was to 
> use the second method, and then to use planes when you had to scale. So 
> basically, if you could not find a match, you would select the lowest of the 
> resolutions, and then setup planes for the ones that need to be scaled. From 
> what I can see, this will end up consuming an extra frame buffer, but it 
> takes care of the issue.
>
> Do you see any issues with that approach?
>

This is basically a recent approach (meaning not necessarily supported
by all drivers, etc).. with the primary-plane feature you could even
configure the primary scanout layer via the plane API (but, keep in
mind, scaling is not something all hw supports).  The new
'atomic-helpers' stuff should help with exposing support for hw that
can do scaling on primary layer.

So in the end, it depends on what hw, and what kernel versions, you
need to support.  You may need to fallback to cropping without scaling
if you need to support everything.  But one of the goals with the
'atomic' work is to make it easier to expose scaling support on hw
that can do it.

> Thanks,
> - Rian
>
>> On Nov 11, 2014, at 8:10 PM, Rob Clark  wrote:
>>
>> On Tue, Nov 11, 2014 at 12:19 PM, Rian Quinn  wrote:
>>> What exactly is the correct way to support cloned monitors using LibDRM. As
>>> I see it, there are two methods:
>>>
>>> - Use the connector array in drmModeSetCrtc
>>> - Use one crtc per connector, but share the same framebuffer.
>>>
>>> Right now I am using option #2 as it seems to be the most flexible, but my
>>> current issue is that on laptops, the connector for the laptop's main screen
>>> is only retuning 1 mode (tested on a Lenovo, and an HP folio), which means
>>> that your unlikely to find a common mode between the laptop monitor, and an
>>> external screen (monitor or projector).
>>
>> #2 is the method that will work on all hw..  usually DE's will pick
>> the closest matching modes between the two connectors/outputs, and
>> truncate edges on the smaller display (via non-zero x/y offset).  Some
>> hw may support upscaling to fit, although that isn't really exposed in
>> a completely standard way at the moment.
>>
>> BR,
>> -R
>>
>>> So with the above problem, right now the only thing that I know to do would
>>> be to set the resolution of the laptop monitor and external monitor to be
>>> their "preferred" resolution, and then copy and scale for "cloned mode"
>>> which seems like a terrible idea considering the laptop monitor should be
>>> able to set itself to some more basic resolutions (like 800x600).
>>>
>>> - Rian
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>

[Bug 85376] Dolphin emulator has bad colors

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

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

--- Comment #10 from Ilia Mirkin  ---
Some observations (from IRC, edited):

In shader 21 (from attachment 109303), we see the following:

 MULLO_INT  R5.x,  [0x0046 9.80909e-44].x, PV.x
 MULLO_INT  R5.y,  [0x0078 1.68156e-43].x, PV.x
 that seems wrong
 the second PV.x uses the newly computed R5.x, no?
 instead of the previous R5.x before the mul happened
 so the 2nd and 3rd components get the compounded multiplication
factor of .x and the respective .y and .z factor
 Starting with the R5.x value returned by the ADD_INT, the
caluclation is: R5.y = ((R5.x *46) * 78); R5.z = (R5.x * 46) * 0xc8
   6: UMUL TEMP[1].xyz, IMM[0].yzww, TEMP[1].
 i'm guessing the thing that splits it up into 3 instructions forgets
that it's overwriting the source
 cayman_mul_int_instr
 cayman-specific, and doesn't do the tmp register dance

vs the "regular" umul implementation (op2_trans) which will use a temp register
if the dst mask has multiple dests. I wonder if all the cayman_* emit functions
need this treatment.

-- 
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/2014/d07f5e0c/attachment.html>

LibDRM Cloned Monitor Support

[Rian Quinn]

Yeah, I had issues trying to get the first method to work across the board on 
all of the hardware that we need to support. One example that I saw was to use 
the second method, and then to use planes when you had to scale. So basically, 
if you could not find a match, you would select the lowest of the resolutions, 
and then setup planes for the ones that need to be scaled. From what I can see, 
this will end up consuming an extra frame buffer, but it takes care of the 
issue. 

Do you see any issues with that approach?

Thanks,
- Rian

> On Nov 11, 2014, at 8:10 PM, Rob Clark  wrote:
> 
> On Tue, Nov 11, 2014 at 12:19 PM, Rian Quinn  wrote:
>> What exactly is the correct way to support cloned monitors using LibDRM. As
>> I see it, there are two methods:
>> 
>> - Use the connector array in drmModeSetCrtc
>> - Use one crtc per connector, but share the same framebuffer.
>> 
>> Right now I am using option #2 as it seems to be the most flexible, but my
>> current issue is that on laptops, the connector for the laptop's main screen
>> is only retuning 1 mode (tested on a Lenovo, and an HP folio), which means
>> that your unlikely to find a common mode between the laptop monitor, and an
>> external screen (monitor or projector).
> 
> #2 is the method that will work on all hw..  usually DE's will pick
> the closest matching modes between the two connectors/outputs, and
> truncate edges on the smaller display (via non-zero x/y offset).  Some
> hw may support upscaling to fit, although that isn't really exposed in
> a completely standard way at the moment.
> 
> BR,
> -R
> 
>> So with the above problem, right now the only thing that I know to do would
>> be to set the resolution of the laptop monitor and external monitor to be
>> their "preferred" resolution, and then copy and scale for "cloned mode"
>> which seems like a terrible idea considering the laptop monitor should be
>> able to set itself to some more basic resolutions (like 800x600).
>> 
>> - Rian
>> 
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> 

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

[Borislav Petkov]

On Tue, Nov 11, 2014 at 08:12:39PM +0100, Borislav Petkov wrote:
> > +".byte 0x66; xsaveopt %P0",
> 
> Huh, XSAVEOPT?!? Shouldn't that be CLWB??

Bah, the same opcodes, only 0x66 prefix makes it into CLWB. Could use a
comment I guess.

-- 
Regards/Gruss,
Boris.

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

[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:
> Add support for the new clwb 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
> 
> Here are some things of note:
> 
>  - As with the clflushopt patches before this, I'm assuming that the 
> addressing
>mode generated by the original clflush instruction will match the new
>clflush instruction with the 0x66 prefix for clflushopt, and for the
>xsaveopt instruction with the 0x66 prefix for clwb.  For all the test cases
>that I've come up with and for the new clwb code generated by this patch
>series, this has proven to be true on my test machine.
> 
>  - According to the SDM, xsaveopt has a form where it has a REX.W prefix.  I
>believe that this prefix will not be generated by gcc in x86_64 kernel 
> code.
>Based on this, I don't believe I need to account for this extra prefix when
>dealing with the assembly language created for clwb.  Please correct me if
>I'm wrong.
> 
> 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 | 10 ++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpufeature.h 
> b/arch/x86/include/asm/cpufeature.h
> index b3e6b89..fbbed34 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -227,6 +227,7 @@
>  #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_CLWB ( 9*32+24) /* CLWB instruction */
>  #define X86_FEATURE_AVX512PF ( 9*32+26) /* AVX-512 Prefetch */
>  #define X86_FEATURE_AVX512ER ( 9*32+27) /* AVX-512 Exponential and 
> Reciprocal */
>  #define X86_FEATURE_AVX512CD ( 9*32+28) /* AVX-512 Conflict Detection */
> diff --git a/arch/x86/include/asm/special_insns.h 
> b/arch/x86/include/asm/special_insns.h
> index 1709a2e..a328460 100644
> --- a/arch/x86/include/asm/special_insns.h
> +++ b/arch/x86/include/asm/special_insns.h
> @@ -199,6 +199,16 @@ static inline void clflushopt(volatile void *__p)
>  "+m" (*(volatile char __force *)__p));
>  }
>  
> +static inline void clwb(volatile void *__p)
> +{
> + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",

Any particular reason for using 0x3e as a prefix to have the insns be
the same size or is it simply because CLFLUSH can stomach it?

:-)

> +  ".byte 0x66; clflush %P0",
> +  X86_FEATURE_CLFLUSHOPT,
> +  ".byte 0x66; xsaveopt %P0",

Huh, XSAVEOPT?!? Shouldn't that be CLWB??

> +  X86_FEATURE_CLWB,
> +  "+m" (*(volatile char __force *)__p));
> +}
> +
>  static inline void pcommit(void)
>  {
>   alternative(ASM_NOP4, ".byte 0x66, 0x0f, 0xae, 0xf8",
> -- 
> 1.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
Regards/Gruss,
Boris.

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

[PATCH v7 6/7] 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

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

---

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,
-};
-
-static struct drm_encoder_helper_funcs dw_hdmi_encoder_helper_funcs = {
-   .dpms = dw_hdmi_encoder_dpms,
-   

[PATCH v7 5/7] 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 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 v7 0/7] dw-hdmi: convert imx hdmi to bridge/dw-hdmi

[Andy Yan]

We found freescale imx5 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 do 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
And we will add rockchip platform specific code dw_hdmi-rockchip.c later,
which is depend on drm-rockchip.

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 (6):
  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
  drm: bridge/dw-hdmi: add support for multi byte register width access
  dt-bindings: add document for dw-hdmi

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

 .../devicetree/bindings/drm/bridge/dw-hdmi.txt |  38 ++
 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 723 +
 .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}|   5 +-
 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   |  52 ++
 9 files changed, 670 insertions(+), 423 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt
 rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c} (71%)
 rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h} (99%)
 create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c
 create mode 100644 include/drm/bridge/dw_hdmi.h

-- 
1.9.1

LibDRM Cloned Monitor Support

[Rob Clark]

On Tue, Nov 11, 2014 at 12:19 PM, Rian Quinn  wrote:
> What exactly is the correct way to support cloned monitors using LibDRM. As
> I see it, there are two methods:
>
> - Use the connector array in drmModeSetCrtc
> - Use one crtc per connector, but share the same framebuffer.
>
> Right now I am using option #2 as it seems to be the most flexible, but my
> current issue is that on laptops, the connector for the laptop's main screen
> is only retuning 1 mode (tested on a Lenovo, and an HP folio), which means
> that your unlikely to find a common mode between the laptop monitor, and an
> external screen (monitor or projector).

#2 is the method that will work on all hw..  usually DE's will pick
the closest matching modes between the two connectors/outputs, and
truncate edges on the smaller display (via non-zero x/y offset).  Some
hw may support upscaling to fit, although that isn't really exposed in
a completely standard way at the moment.

BR,
-R

> So with the above problem, right now the only thing that I know to do would
> be to set the resolution of the laptop monitor and external monitor to be
> their "preferred" resolution, and then copy and scale for "cloned mode"
> which seems like a terrible idea considering the laptop monitor should be
> able to set itself to some more basic resolutions (like 800x600).
>
> - Rian
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 82441] [gma500] Dell Inspiron Mini 1010 black screen after boot

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

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

Laurent BP  changed:

   What|Removed |Added

   See Also|https://bugs.freedesktop.or |
   |g/show_bug.cgi?id=86169 |

-- 
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/20141111/8446bd0f/attachment-0001.html>

[Bug 82441] [gma500] Dell Inspiron Mini 1010 black screen after boot

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

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

Laurent BP  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=86169

-- 
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/20141111/559af512/attachment.html>

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

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

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

--- Comment #12 from Marek  ---
Created attachment 157341
  --> https://bugzilla.kernel.org/attachment.cgi?id=157341=edit
logs for first not working kernel

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

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

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

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

--- Comment #11 from Marek  ---
Created attachment 157331
  --> https://bugzilla.kernel.org/attachment.cgi?id=157331=edit
logs for last working kernel

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

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

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

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

Marek  changed:

   What|Removed |Added

 CC||kordikmarek at gmail.com

--- Comment #10 from Marek  ---
Hi all, I have simillar problem and I tried to find some solution but with no
success. Until kernel 3.15.10-201 worked everythink fine, but after upgrade to
3.16.2-200 (and every next kernel up to 3.16.7-200) instead radeon driver VESA
is used (small resolution, kde gui is bit laggy probably because gpu
acceleration is not used). My description maybe isn`t accurate  but I will be
happy to answer any of your questions. I have attached output of journalctl,
lsmod, dmesg and Xorg.log for last working and first not working kernel. I am
using Fedora 20 x64 on asus notebook M51Se with ati radeon HD3470 graphics.

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

[PATCH] drm: export atomic wait_for_vblanks helper (v2)

[Rob Clark]

v1: original
v2: danvet's kerneldoc nitpicks

Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 17 ++---
 include/drm/drm_atomic_helper.h |  3 +++
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ca839bd..fad2b93 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -754,8 +754,18 @@ static void wait_for_fences(struct drm_device *dev,
}
 }

-static void
-wait_for_vblanks(struct drm_device *dev, struct drm_atomic_state *old_state)
+/**
+ * drm_atomic_helper_wait_for_vblanks - wait for vblank on crtcs
+ * @dev: DRM device
+ * @old_state: atomic state object with old state structures
+ *
+ * Helper to, after atomic commit, wait for vblanks on all effected
+ * crtcs (ie. before cleaning up old framebuffers using
+ * drm_atomic_helper_cleanup_planes())
+ */
+void
+drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
+   struct drm_atomic_state *old_state)
 {
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
@@ -800,6 +810,7 @@ wait_for_vblanks(struct drm_device *dev, struct 
drm_atomic_state *old_state)
drm_crtc_vblank_put(crtc);
}
 }
+EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);

 /**
  * drm_atomic_helper_commit - commit validated state object
@@ -859,7 +870,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,

drm_atomic_helper_commit_post_planes(dev, state);

-   wait_for_vblanks(dev, state);
+   drm_atomic_helper_wait_for_vblanks(dev, state);

drm_atomic_helper_cleanup_planes(dev, state);

diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 67e3c46..64b4e91 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -34,6 +34,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 struct drm_atomic_state *state,
 bool async);

+void drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
+   struct drm_atomic_state *old_state);
+
 void drm_atomic_helper_commit_pre_planes(struct drm_device *dev,
 struct drm_atomic_state *state);
 void drm_atomic_helper_commit_post_planes(struct drm_device *dev,
-- 
1.9.3

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

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

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

--- Comment #8 from Benjamin Bellec  ---
(In reply to Vitaliy Filippov from comment #7)
> It seems it's OK with nosb

OK, this is maybe related to issue I have :
https://bugs.freedesktop.org/show_bug.cgi?id=86165

(In reply to Vitaliy Filippov from comment #7)
> although the frame rate seems lower

Yes, "sb" is the enhanced r600g GLSL compiler. So disabling it decrease the
performance.

-- 
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/2014/de5b224c/attachment.html>

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

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

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

Vitaliy Filippov  changed:

   What|Removed |Added

 Attachment #109305|text/plain  |image/jpeg
  mime type||

-- 
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/20141111/c83597ff/attachment.html>

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

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

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

--- Comment #7 from Vitaliy Filippov  ---
Created attachment 109305
  --> https://bugs.freedesktop.org/attachment.cgi?id=109305=edit
OK with R600_DEBUG=nosb

It seems it's OK with nosb (although the frame rate seems lower)

-- 
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/2014/05080cfa/attachment-0001.html>

[Bug 85376] Dolphin emulator has bad colors

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

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

--- Comment #9 from ghallberg+bugzilla at gmail.com ---
Created attachment 109303
  --> https://bugs.freedesktop.org/attachment.cgi?id=109303=edit
psfs results of edit9

-- 
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/2014/b2f61799/attachment.html>

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

[Christoph Lameter]

On Tue, 11 Nov 2014, Andrew Morton wrote:

> Well, attempting to fix it up and continue is nice, but we can live
> with the BUG.
>
> Not knowing which bit was set is bad.

Could we change BUG_ON to diplay the value? This keeps on coming up.

If you want to add this to the slab allocators then please add to
mm/slab_common.c and refer to it from the other allocators.

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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

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

--- Comment #4 from Benjamin Bellec  ---
You can find an apitrace at high settings here :
https://drive.google.com/file/d/0B7D2Y0QXFND2bHd3ZXlBeDI0OUk/view?usp=sharing
309 MB
md5sum c9a7e793122d4babe71e68535ab86459

-- 
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/20141111/0a3e8103/attachment.html>

Crash of radeon_ttm_tt_unpopulate in ttm_dma_unpopulate with

[Marcus Overhagen]

This crash occured after about a day  with 3.18.0-rc3
that is unmodified with exception of a single unrelated i915 driver
patch from http://www.spinics.net/lists/intel-gfx/msg54997.html

Its a samsung np730u3e-s05 with hybrid graphics chipset and the Radeon HD
8550M isn't used. I can provide further info if this is of interest.

[23168.559229] BUG: unable to handle kernel NULL pointer dereference at
0018
[23168.560206] IP: [] ttm_dma_unpopulate+0x260/0x390 [ttm]
[23168.561209] PGD 0
[23168.562145] Oops:  [#1] PREEMPT SMP
[23168.563096] Modules linked in: ctr ccm fuse arc4 snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic iTCO_wdt uvcvideo iwldvm
coretemp videobuf2_vmalloc intel_rapl joydev videobuf2_memops mac80211
videobuf2_core snd_hda_intel snd_hda_controller iTCO_vendor_support
mousedev x86_pkg_temp_thermal intel_powerclamp radeon v4l2_common iwlwifi
samsung_laptop kvm_intel videodev snd_hda_codec i915 ttm evdev ecb mac_hid
snd_hwdep drm_kms_helper r8169 kvm btusb psmouse pcspkr serio_raw i2c_i801
media cfg80211 drm lpc_ich rtsx_usb_ms intel_gtt snd_pcm hwmon bluetooth
mii i2c_algo_bit tpm_infineon memstick mei_me fan rfkill snd_timer wmi
tpm_tis i2c_core battery snd thermal tpm soundcore mei video shpchp button
ac processor ext4 crc16 mbcache jbd2 algif_skcipher af_alg dm_crypt dm_mod
rtsx_usb_sdmmc
[23168.566629]  led_class mmc_core rtsx_usb sd_mod crct10dif_pclmul
crc32_pclmul crc32c_intel atkbd ghash_clmulni_intel libps2 aesni_intel
aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci
xhci_pci ehci_pci libata xhci_hcd ehci_hcd scsi_mod usbcore usb_common
i8042 serio
[23168.569111] CPU: 3 PID: 406 Comm: Xorg.bin Tainted: GW
3.18.0-rc3-marcus1 #1
[23168.570348] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
730U3E/740U3E/NP730U3E-S05DE, BIOS P03ABW.051.130226.dg 02/26/2013
[23168.571614] task: 8801a5cf6eb0 ti: 8800bf908000 task.ti:
8800bf908000
[23168.572879] RIP: 0010:[]  []
ttm_dma_unpopulate+0x260/0x390 [ttm]
[23168.574163] RSP: :8800bf90b978  EFLAGS: 00010207
[23168.575443] RAX:  RBX: 8801a55d6300 RCX:
0005
[23168.576719] RDX: 8800bffd3600 RSI: dead00200200 RDI:
8801a55d6900
[23168.578039] RBP: 8800bf90b9b8 R08: 0004 R09:
8800c372b5a0
[23168.579310] R10:  R11: 0001 R12:
8801a55d6360
[23168.580579] R13: 8801a4bd4710 R14: 8801a4f3cb40 R15:
0006
[23168.581855] FS:  7fd27407f700() GS:8801af38()
knlGS:
[23168.583145] CS:  0010 DS:  ES:  CR0: 80050033
[23168.584434] CR2: 0018 CR3: 01811000 CR4:
001407e0
[23168.585742] Stack:
[23168.587045]  8800c3728800 8801a55d6900 8801a4bd4000
8801a55d6300
[23168.588420]  0002 8801a4bd4710 8801a55d6300
002a
[23168.589785]  8800bf90b9e8 a094a8b7 8801a55d6300
0002
[23168.591134] Call Trace:
[23168.592483]  [] radeon_ttm_tt_unpopulate+0x147/0x150
[radeon]
[23168.593878]  [] ttm_tt_unpopulate+0x54/0x60 [ttm]
[23168.595220]  [] ttm_tt_destroy+0x65/0x70 [ttm]
[23168.596557]  [] ttm_bo_cleanup_memtype_use+0x43/0x90
[ttm]
[23168.597901]  [] ttm_bo_release+0x120/0x2e0 [ttm]
[23168.599188]  [] ttm_bo_unref+0x29/0x30 [ttm]
[23168.600431]  [] radeon_bo_unref+0x39/0x70 [radeon]
[23168.601661]  [] radeon_gem_object_free+0x4b/0x70
[radeon]
[23168.602899]  [] drm_gem_object_free+0x27/0x40 [drm]
[23168.604143]  []
drm_gem_object_handle_unreference_unlocked+0x120/0x130 [drm]
[23168.605406]  []
drm_gem_object_release_handle+0x57/0x80 [drm]
[23168.606668]  [] idr_for_each+0xb5/0x120
[23168.607934]  [] ? drm_gem_dumb_destroy+0x20/0x20 [drm]
[23168.609213]  [] drm_gem_release+0x24/0x40 [drm]
[23168.610463]  [] drm_release+0x43b/0x520 [drm]
[23168.611773]  [] __fput+0x9c/0x200
[23168.613039]  [] fput+0xe/0x10
[23168.614333]  [] task_work_run+0xbc/0xe0
[23168.615577]  [] do_exit+0x3a5/0xb30
[23168.616825]  [] ? ttwu_stat+0x9e/0x110
[23168.618083]  [] ? get_futex_key+0x250/0x2c0
[23168.619400]  [] do_group_exit+0x47/0xc0
[23168.620666]  [] get_signal+0x273/0x710
[23168.621931]  [] do_signal+0x37/0x800
[23168.623221]  [] do_notify_resume+0x68/0xa0
[23168.624488]  [] int_signal+0x12/0x17
[23168.625762] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 49 89 ce 48 8b 43 60
4c 8d 63 60 45 31 ff 4c 39 e0 74 28 45 31 ff 66 2e 0f 1f 84 00 00 00 00 00
<48> 8b 70 18 48 8b 53 18 44 89 f9 41 83 c7 01 48 89 34 ca 48 8b
[23168.627274] RIP  [] ttm_dma_unpopulate+0x260/0x390
[ttm]
[23168.628790]  RSP 
[23168.630300] CR2: 0018
[23168.631810] ---[ end trace acd63743d38c53a7 ]---
[23168.633307] Fixing recursive fault but reboot is needed!

regards
Marcus
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/c76b08bf/attachment.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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

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

--- Comment #3 from Benjamin Bellec  ---
Created attachment 109300
  --> https://bugs.freedesktop.org/attachment.cgi?id=109300=edit
Worse ground textures at low settings with a more recent commit

I noted that at low settings, a recent commit broken more dramatically the
ground textures, see attachment for a preview.

The commit is e9822f77a9cc024f528d30382fd5ad21c73a173b
summary : glsl: Skip making a temporary for assignments when we don't need one.
author : Eric Anholt 
date : 2014-04-08 07:59:47 (GMT)

-- 
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/2014/cbb52a51/attachment.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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

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

--- Comment #2 from Benjamin Bellec  ---
Created attachment 109299
  --> https://bugs.freedesktop.org/attachment.cgi?id=109299=edit
Incorrect ground textures at low settings

-- 
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/2014/10ba74e7/attachment.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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

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

--- Comment #1 from Benjamin Bellec  ---
Created attachment 109298
  --> https://bugs.freedesktop.org/attachment.cgi?id=109298=edit
The ground textures at high settings when sb is disabled.

-- 
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/2014/91a9cc7d/attachment-0001.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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

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

Benjamin Bellec  changed:

   What|Removed |Added

 Attachment #109297|text/plain  |image/png
  mime type||
 CC||b.bellec at gmail.com

-- 
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/20141111/56f64455/attachment.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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

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

Bug ID: 86165
   Summary: [RV770] [bisected] Bad textures rendering on Serious
Sam 3 with sb enabled
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: b.bellec at gmail.com

Created attachment 109297
  --> https://bugs.freedesktop.org/attachment.cgi?id=109297=edit
SS3 ground textures at high settings when SB is enabled

Ground textures in Serious Sam 3 are incorrectly rendered (see the first
attachment for a preview).

This only occurs with my RV770, not with my HD5850 (Evergreen).
This only occurs when sb is enabled (which is the default setting).

The first bad commit is :
commit: 7ae9cc71f097af5ae1f83f77f75de2198849faca
summary: st/mesa: use new float comparison opcodes if native integers are
supported
author: Roland Scheidegger 
date of commit: 2013-08-15 15:30:07 (GMT)

-- 
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/2014/37eae9ba/attachment.html>

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

[Christoph Lameter]

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.

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

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

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

Benjamin Bellec  changed:

   What|Removed |Added

 CC||b.bellec at gmail.com

--- Comment #6 from Benjamin Bellec  ---
Can you try with sb disabled, set then envvar "R600_DEBUG=nosb".

-- 
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/2014/eb262e9f/attachment.html>

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

[Andrew Morton]

On Wed, 12 Nov 2014 03:47:03 +0200 "Kirill A. Shutemov"  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;

?

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

[Andrew Morton]

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

Poor ttm guys - this is a bit of a trap we set for them.

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

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

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3652ed8dda80..8850f32994e3 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;
 }

@@ -2147,7 +2143,6 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   drm_modeset_lock_all(dev);
config = >mode_config;

if (file_priv->universal_planes)
@@ -2182,7 +2177,6 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
plane_resp->count_planes = num_planes;

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

@@ -2210,13 +2204,11 @@ int drm_mode_getplane(struct drm_device *dev, void 
*data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   drm_modeset_lock_all(dev);
plane = drm_plane_find(dev, plane_resp->plane_id);
-   if (!plane) {
-   ret = -ENOENT;
-   goto out;
-   }
+   if (!plane)
+   return -ENOENT;

+   drm_modeset_lock(>mutex, NULL);
if (plane->crtc)
plane_resp->crtc_id = plane->crtc->base.id;
else
@@ -2226,6 +2218,7 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
plane_resp->fb_id = plane->fb->base.id;
else
plane_resp->fb_id = 0;
+   drm_modeset_unlock(>mutex);

plane_resp->plane_id = plane->base.id;
plane_resp->possible_crtcs = plane->possible_crtcs;
@@ -2241,14 +2234,11 @@ int drm_mode_getplane(struct drm_device *dev, void 
*data,
if (copy_to_user(format_ptr,
 plane->format_types,
 sizeof(uint32_t) * plane->format_count)) {
-   ret = -EFAULT;
-   goto out;
+   return -EFAULT;
}
}

[Bug 85376] Dolphin emulator has bad colors

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

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

--- Comment #8 from ghallberg+bugzilla at gmail.com ---
Created attachment 109289
  --> https://bugs.freedesktop.org/attachment.cgi?id=109289=edit
psfs results of edit7

-- 
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/2014/8ab020f0/attachment.html>

[PATCH] drm/radeon: add locking around atombios scratch space usage

[Alex Deucher]

On Mon, Nov 10, 2014 at 6:16 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> While developing MST support I noticed I often got the wrong data
> back from a transaction, in a racy fashion. I noticed the scratch
> space wasn't locked against concurrent users.
>
> Based on a patch by Alex, but I've made it a bit more obvious when
> things are locked.
>
> Signed-off-by: Dave Airlie 

Applied to my -fixes tree.

Alex

> ---
>  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(-)
>
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index 6f26eb7..bec41c4 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -1218,7 +1218,7 @@ free:
> return ret;
>  }
>
> -int atom_execute_table(struct atom_context *ctx, int index, uint32_t * 
> params)
> +int atom_execute_table_scratch_unlocked(struct atom_context *ctx, int index, 
> uint32_t * params)
>  {
> int r;
>
> @@ -1239,6 +1239,15 @@ int atom_execute_table(struct atom_context *ctx, int 
> index, uint32_t * params)
> return r;
>  }
>
> +int atom_execute_table(struct atom_context *ctx, int index, uint32_t * 
> params)
> +{
> +   int r;
> +   mutex_lock(>scratch_mutex);
> +   r = atom_execute_table_scratch_unlocked(ctx, index, params);
> +   mutex_unlock(>scratch_mutex);
> +   return r;
> +}
> +
>  static int atom_iio_len[] = { 1, 2, 3, 3, 3, 3, 4, 4, 4, 3 };
>
>  static void atom_index_iio(struct atom_context *ctx, int base)
> diff --git a/drivers/gpu/drm/radeon/atom.h b/drivers/gpu/drm/radeon/atom.h
> index bf9e6f2..6dffe15 100644
> --- a/drivers/gpu/drm/radeon/atom.h
> +++ b/drivers/gpu/drm/radeon/atom.h
> @@ -125,6 +125,7 @@ struct card_info {
>  struct atom_context {
> struct card_info *card;
> struct mutex mutex;
> +   struct mutex scratch_mutex;
> void *bios;
> uint32_t cmd_table, data_table;
> uint16_t *iio;
> @@ -146,6 +147,7 @@ extern int atom_reg_debug;
>
>  struct atom_context *atom_parse(struct card_info *, void *);
>  int atom_execute_table(struct atom_context *, int, uint32_t *);
> +int atom_execute_table_scratch_unlocked(struct atom_context *, int, uint32_t 
> *);
>  int atom_asic_init(struct atom_context *);
>  void atom_destroy(struct atom_context *);
>  bool atom_parse_data_header(struct atom_context *ctx, int index, uint16_t 
> *size,
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index bd96ae7..0f39d96 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -100,6 +100,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
> *chan,
> memset(, 0, sizeof(args));
>
> mutex_lock(>mutex);
> +   mutex_lock(>mode_info.atom_context->scratch_mutex);
>
> base = (unsigned char *)(rdev->mode_info.atom_context->scratch + 1);
>
> @@ -113,7 +114,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
> *chan,
> if (ASIC_IS_DCE4(rdev))
> args.v2.ucHPD_ID = chan->rec.hpd;
>
> -   atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
> *));
> +   atom_execute_table_scratch_unlocked(rdev->mode_info.atom_context, 
> index, (uint32_t *));
>
> *ack = args.v1.ucReplyStatus;
>
> @@ -147,6 +148,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
> *chan,
>
> r = recv_bytes;
>  done:
> +   mutex_unlock(>mode_info.atom_context->scratch_mutex);
> mutex_unlock(>mutex);
>
> return r;
> diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c 
> b/drivers/gpu/drm/radeon/atombios_i2c.c
> index 9c570fb..4157780 100644
> --- a/drivers/gpu/drm/radeon/atombios_i2c.c
> +++ b/drivers/gpu/drm/radeon/atombios_i2c.c
> @@ -48,6 +48,7 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan 
> *chan,
> memset(, 0, sizeof(args));
>
> mutex_lock(>mutex);
> +   mutex_lock(>mode_info.atom_context->scratch_mutex);
>
> base = (unsigned char *)rdev->mode_info.atom_context->scratch;
>
> @@ -82,7 +83,7 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan 
> *chan,
> args.ucSlaveAddr = slave_addr << 1;
> args.ucLineNumber = chan->rec.i2c_id;
>
> -   atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
> *));
> +   atom_execute_table_scratch_unlocked(rdev->mode_info.atom_context, 
> index, (uint32_t *));
>
> /* error */
> if (args.ucStatus != HW_ASSISTED_I2C_STATUS_SUCCESS) {
> @@ -95,6 +96,7 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan 
> *chan,
> radeon_atom_copy_swap(buf, base, num, false);
>
>  done:
> +   mutex_unlock(>mode_info.atom_context->scratch_mutex);

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

[Andrew Morton]

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.

It might just have been a random memory bitflip or other corruption of
course.  Is it repeatable at all?

If it is, please add the below and retest?

--- a/mm/slab.c~slab-improve-checking-for-invalid-gfp_flags
+++ a/mm/slab.c
@@ -2590,7 +2590,10 @@ static int cache_grow(struct kmem_cache
 * Be lazy and only check for valid flags here,  keeping it out of the
 * critical path in kmem_cache_alloc().
 */
-   BUG_ON(flags & GFP_SLAB_BUG_MASK);
+   if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
+   pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
+   BUG();
+   }
local_flags = flags & (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK);

/* Take the node list lock to change the colour_next on this node */
diff -puN mm/slub.c~slab-improve-checking-for-invalid-gfp_flags mm/slub.c
--- a/mm/slub.c~slab-improve-checking-for-invalid-gfp_flags
+++ a/mm/slub.c
@@ -1377,7 +1377,10 @@ static struct page *new_slab(struct kmem
int order;
int idx;

-   BUG_ON(flags & GFP_SLAB_BUG_MASK);
+   if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
+   pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
+   BUG();
+   }

page = allocate_slab(s,
flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK), node);
_

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

[Andrew Morton]

On Wed, 12 Nov 2014 09:44:19 +0900 Joonsoo Kim  
wrote:

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

Well, attempting to fix it up and continue is nice, but we can live
with the BUG.

Not knowing which bit was set is bad.

diff -puN mm/slab.c~slab-improve-checking-for-invalid-gfp_flags mm/slab.c
--- a/mm/slab.c~slab-improve-checking-for-invalid-gfp_flags
+++ a/mm/slab.c
@@ -2590,7 +2590,10 @@ static int cache_grow(struct kmem_cache
 * Be lazy and only check for valid flags here,  keeping it out of the
 * critical path in kmem_cache_alloc().
 */
-   BUG_ON(flags & GFP_SLAB_BUG_MASK);
+   if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
+   pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
+   BUG();
+   }
local_flags = flags & (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK);

/* Take the node list lock to change the colour_next on this node */
--- a/mm/slub.c~slab-improve-checking-for-invalid-gfp_flags
+++ a/mm/slub.c
@@ -1377,7 +1377,10 @@ static struct page *new_slab(struct kmem
int order;
int idx;

-   BUG_ON(flags & GFP_SLAB_BUG_MASK);
+   if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
+   pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
+   BUG();
+   }

page = allocate_slab(s,
flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK), node);
_

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

[Andrew Morton]

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)

but I haven't traced that through and that's 32-bit.

But anyway - Luke, please attach your .config to
https://bugzilla.kernel.org/show_bug.cgi?id=87891?

[Bug 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors

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

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

José Fonseca  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #16 from José Fonseca  ---
I just tried the simplied version of shadowtex w/ llvmpipe, and it renders the
exactly same things as NVIDIA.

I supposed it was fixed eventually.

-- 
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/20141111/0c8607f1/attachment.html>

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

[Andrew Morton]

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

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

And it's quite infuriating to go BUG because one of the bits was set,
but not tell us which bit it was!


Could the slab guys please review this?

From: Andrew Morton 
Subject: slab: improve checking for invalid gfp_flags

- The code goes BUG, but doesn't tell us which bits were unexpectedly
  set.  Print that out.

- The code goes BUG when it could jsut fix things up and proceed.  Do that.

- ~__GFP_BITS_MASK already includes __GFP_DMA32 and __GFP_HIGHMEM, so
  remove those from the GFP_SLAB_BUG_MASK definition.

Cc: Christoph Lameter 
Cc: Pekka Enberg 
Cc: David Rientjes 
Cc: Joonsoo Kim 
Signed-off-by: Andrew Morton 
---

 include/linux/gfp.h |2 +-
 mm/slab.c   |5 -
 mm/slub.c   |5 -
 3 files changed, 9 insertions(+), 3 deletions(-)

diff -puN include/linux/gfp.h~slab-improve-checking-for-invalid-gfp_flags 
include/linux/gfp.h
--- a/include/linux/gfp.h~slab-improve-checking-for-invalid-gfp_flags
+++ a/include/linux/gfp.h
@@ -145,7 +145,7 @@ struct vm_area_struct;
 #define GFP_CONSTRAINT_MASK (__GFP_HARDWALL|__GFP_THISNODE)

 /* Do not use these with a slab allocator */
-#define 

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

[Lucas Stach]

Am Dienstag, den 11.11.2014, 14:20 + schrieb Zubair Lutfullah
Kakakhel:
> Hi Andy,
> 
> This patch adds the reg-io-width binding.
> 
> Hence the binding patch should come before it.
> 
> 
> On 11/11/14 12:53, Andy Yan wrote:
> > 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 
> > 
> > ---
> > 
> >  }
> >  
> >  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;
> > +   }
> 
> The binding patch says this is an optional property.
> But here if undefined it returns -EINVAL.
> 
> I would keep it optional and default it to byte access.

That's exactly what the patch does. val is initialized to 1, which is
not changed if the property could not be found in the DT. The default
case will only be taken if the property is present in DT but has any
other value than 1 or 4, which is an error.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

[Zubair Lutfullah Kakakhel]

On 11/11/14 14:46, Andy Yan wrote:
> 
> On 2014年11月11日 22:20, Zubair Lutfullah Kakakhel wrote:
>> Hi Andy,
>>
>> This patch adds the reg-io-width binding.
>>
>> Hence the binding patch should come before it.
>>
>do you mean that I should put dts binding patch
>before this patch?

Yes. The patch adding the binding to the Documentation folder comes
before the driver implementing the binding.

ZubairLK

>> On 11/11/14 12:53, Andy Yan wrote:
>>> On rockchip rk3288, only word(32-bit) accesses are
>>> permitted for hdmi registers.  Byte width accesses (writeb,
>>> readb) generate an imprecise external abort.

[PATCH v7 7/7] dt-bindings: add document for dw-hdmi

[Zubair Lutfullah Kakakhel]

Hi Andy,

Some minor comments inline.

On 11/11/14 12:54, Andy Yan wrote:
> Signed-off-by: Andy Yan 
> ---
> 
> 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 | 38 
> ++
>  1 file changed, 38 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..aa7ed17
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt
> @@ -0,0 +1,38 @@
> +DesignWare HDMI bridge bindings
> +
> +Required properities:

^properties

> +- compatibel: platform specific such as "fsl,imx6q-hdmi","fsl,imx6dl-hdmi"

 ^compatible

> +   "rockchip,rk3288-dw-hdmi"

This will need to come in a separate series which adds rk3288 hdmi support..

> +- reg: physical base address of the controller and length
> +- ddc-i2c-bus: the ddc i2c bus
> +- interrupts: The interrupt number to the cpu
> +
> +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>;
> + };
> + };
> + };
> 

Thanks
ZubairLK

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

[Zubair Lutfullah Kakakhel]

On 11/11/14 14:23, Lucas Stach wrote:
> Am Dienstag, den 11.11.2014, 14:20 + schrieb Zubair Lutfullah
> Kakakhel:
>> Hi Andy,
>>
>> This patch adds the reg-io-width binding.
>>
>> Hence the binding patch should come before it.
>>
>>
>> On 11/11/14 12:53, Andy Yan wrote:
>>> 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 
>>>
>>> ---
>>>
>>>  }
>>>  
>>>  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;
>>> +   }
>>
>> The binding patch says this is an optional property.
>> But here if undefined it returns -EINVAL.
>>
>> I would keep it optional and default it to byte access.
> 
> That's exactly what the patch does. val is initialized to 1, which is
> not changed if the property could not be found in the DT. The default
> case will only be taken if the property is present in DT but has any
> other value than 1 or 4, which is an error.
> 

I missed the initialization. My bad.

Thanks
ZubairLK

[PATCH v7 6/7] drm: bridge/dw-hdmi: convert dw-hdmi to drm_bridge mode

[Zubair Lutfullah Kakakhel]

Hi Andy,

On 11/11/14 12:54, Andy Yan wrote:
> From: Yakir Yang 
> 
> keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c

Is there a reason for this separation? Keeping encoder in platform files?
If yes, then the commit message should explain that.

> 
> Signed-off-by: Andy Yan 
> Signed-off-by: Yakir Yang 
> 
> ---
> 
> 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(-)


Regards
ZubairLK

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

[Daniel Thompson]

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

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 86133] Graphics Driver Fails to Restart Post Suspend

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 42960 ***

-- 
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/20141111/d50a2b06/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||merciers.merciers at gmail.com

--- Comment #54 from Alex Deucher  ---
*** Bug 86133 has been marked as a duplicate of this bug. ***

-- 
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/20141111/0599ebcb/attachment.html>

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

[Zubair Lutfullah Kakakhel]

Hi Andy,

This patch adds the reg-io-width binding.

Hence the binding patch should come before it.


On 11/11/14 12:53, Andy Yan wrote:
> 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 
> 
> ---
> 
>  }
>  
>  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;
> + }

The binding patch says this is an optional property.
But here if undefined it returns -EINVAL.

I would keep it optional and default it to byte access.

Regards,
ZubairLK

[Bug 86130] Some textures are not rendering correctly in apitrace but are fine while capturing

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

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

--- Comment #2 from Benjamin Bellec  ---
(In reply to Marek Olšák from comment #1)
> Can you test Mesa master?

Done, no better results.

Note that all my tests have been done with R600_DEBUG=nohyperz

-- 
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/2014/85f3baad/attachment.html>

[PATCH v7 4/7] staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw-hdmi

[Zubair Lutfullah Kakakhel]

Hi Andy,

On 11/11/14 12:53, Andy Yan wrote:
> the original imx hdmi driver is under staging/imx-drm,
> which depends on imx-drm, so move the imx hdmi drvier out

Spelling mistake.   ^'driver'

> to drm/bridge and rename imx-hdmi to dw-hdmi
  ^dw_hdmi

> 
> Signed-off-by: Andy Yan 
> 
> ---
> 
> 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

...

> diff --git a/drivers/staging/imx-drm/imx-hdmi.h 
> b/drivers/gpu/drm/bridge/dw_hdmi.h
> similarity index 97%
> rename from drivers/staging/imx-drm/imx-hdmi.h
> rename to drivers/gpu/drm/bridge/dw_hdmi.h
> index e67d60d..b8412a9 100644
> --- a/drivers/staging/imx-drm/imx-hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.h
> @@ -7,8 +7,8 @@
>   * (at your option) any later version.
>   */
>  
> -#ifndef __IMX_HDMI_H__
> -#define __IMX_HDMI_H__
> +#ifndef __DW_HDMI__
> +#define __DW_HDMI__
>  
>  /* Identification Registers */
>  #define HDMI_DESIGN_ID  0x
> @@ -1030,46 +1030,4 @@ enum {
>   HDMI_A_VIDPOLCFG_HSYNCPOL_ACTIVE_LOW = 0x0,
>  };
>  
> -enum {
> - RES_8,
> - RES_10,
> - RES_12,
> - RES_MAX,
> -};
> -
> -enum imx_hdmi_devtype {
> - IMX6Q_HDMI,
> - IMX6DL_HDMI,
> -};
> -
> -struct mpll_config {
> - unsigned long mpixelclock;
> - struct {
> - u16 cpce;
> - u16 gmp;
> - } res[RES_MAX];
> -};
> -
> -struct curr_ctrl {
> - unsigned long mpixelclock;
> - u16 curr[RES_MAX];
> -};
> -
> -struct imx_hdmi_plat_data {
> - void * (*setup)(struct platform_device *pdev);
> - void (*exit)(void *priv);
> - void (*encoder_commit)(void *priv, struct drm_encoder *encoder);
> - void (*encoder_prepare)(struct drm_connector *connector,
> - struct drm_encoder *encoder);
> - enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
> -struct drm_display_mode *mode);
> - const struct mpll_config *mpll_cfg;
> - const struct curr_ctrl *cur_ctr;
> - enum imx_hdmi_devtype dev_type;
> -
> -};
> -
> -int imx_hdmi_platform_register(struct platform_device *pdev,
> -const struct imx_hdmi_plat_data *plat_data);
> -int imx_hdmi_platform_unregister(struct platform_device *pdev);

Doesn't this change belong in the previous splitting patch?

>  #endif /* __IMX_HDMI_H__ */
> diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
> index ab31848..560e1d3 100644
> --- a/drivers/staging/imx-drm/Kconfig
> +++ b/drivers/staging/imx-drm/Kconfig
> @@ -50,5 +50,6 @@ config DRM_IMX_IPUV3
>  config DRM_IMX_HDMI
>   tristate "Freescale i.MX DRM 

[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 #36 from Alexandre Demers  ---
Almost, I will be testing my last commit tonight (if I did no mistake along the
way). I'll have a look at the patch after that.

-- 
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/20141111/e19237ea/attachment.html>

[Bug 86130] Some textures are not rendering correctly in apitrace but are fine while capturing

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

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

--- Comment #1 from Marek Olšák  ---
Can you test Mesa master?

-- 
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/20141111/fc544fcd/attachment.html>

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

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

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

--- Comment #22 from Remco Zoet  ---
(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?

Hello Michel,

I suffered from the same crashes Hannu and Malte Schröder reported. After
applying this patch, the crashes and lockups ceased.

-- 
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/2014/95e8f62f/attachment.html>

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

[Ross Zwisler]

On Tue, 2014-11-11 at 20:46 +0100, Borislav Petkov wrote:
> On Tue, Nov 11, 2014 at 12:40:00PM -0700, Ross Zwisler wrote:
> > Yep, it's weird, I know.  :)
> 
> But sure, saving opcode space, makes sense to me.
> 
> Btw, I'd still be interested about this:
> 
> > +static inline void clwb(volatile void *__p)
> > +{
> > + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",
> 
> Any particular reason for using 0x3e as a prefix to have the insns be
> the same size or is it simply because CLFLUSH can stomach it?

Ah, sorry, I was still responding to your first mail.  :)  Response
copied here to save searching:

Essentially we need one additional byte at the beginning of the
clflush so that we can flip it into a clflushopt by changing that byte
into a 0x66 prefix.  Two options are to either insert a 1 byte
ASM_NOP1, or to add a 1 byte NOP_DS_PREFIX.  Both have no functional
effect with the plain clflush, but I've been told that executing a
clflush + prefix should be faster than executing a clflush + NOP.

I agree, this is useful info - I'll add it to the patch comments for v2.

Thank you for the feedback.

- Ross

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

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

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

--- Comment #21 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: 7 playbacks of the video, no crashes/lockups.

I will continue tomorrow, now the computer is needed for gaming.

-- 
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/2014/a71ee986/attachment-0001.html>

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

[Ross Zwisler]

On Tue, 2014-11-11 at 20:12 +0100, Borislav Petkov wrote:
> On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote:
> > Add support for the new clwb 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
> > 
> > Here are some things of note:
> > 
> >  - As with the clflushopt patches before this, I'm assuming that the 
> > addressing
> >mode generated by the original clflush instruction will match the new
> >clflush instruction with the 0x66 prefix for clflushopt, and for the
> >xsaveopt instruction with the 0x66 prefix for clwb.  For all the test 
> > cases
> >that I've come up with and for the new clwb code generated by this patch
> >series, this has proven to be true on my test machine.
> > 
> >  - According to the SDM, xsaveopt has a form where it has a REX.W prefix.  I
> >believe that this prefix will not be generated by gcc in x86_64 kernel 
> > code.
> >Based on this, I don't believe I need to account for this extra prefix 
> > when
> >dealing with the assembly language created for clwb.  Please correct me 
> > if
> >I'm wrong.
> > 
> > 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 | 10 ++
> >  2 files changed, 11 insertions(+)
> > 
> > diff --git a/arch/x86/include/asm/cpufeature.h 
> > b/arch/x86/include/asm/cpufeature.h
> > index b3e6b89..fbbed34 100644
> > --- a/arch/x86/include/asm/cpufeature.h
> > +++ b/arch/x86/include/asm/cpufeature.h
> > @@ -227,6 +227,7 @@
> >  #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_CLWB   ( 9*32+24) /* CLWB instruction */
> >  #define X86_FEATURE_AVX512PF   ( 9*32+26) /* AVX-512 Prefetch */
> >  #define X86_FEATURE_AVX512ER   ( 9*32+27) /* AVX-512 Exponential and 
> > Reciprocal */
> >  #define X86_FEATURE_AVX512CD   ( 9*32+28) /* AVX-512 Conflict 
> > Detection */
> > diff --git a/arch/x86/include/asm/special_insns.h 
> > b/arch/x86/include/asm/special_insns.h
> > index 1709a2e..a328460 100644
> > --- a/arch/x86/include/asm/special_insns.h
> > +++ b/arch/x86/include/asm/special_insns.h
> > @@ -199,6 +199,16 @@ static inline void clflushopt(volatile void *__p)
> >"+m" (*(volatile char __force *)__p));
> >  }
> >  
> > +static inline void clwb(volatile void *__p)
> > +{
> > +   alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",
> 
> Any particular reason for using 0x3e as a prefix to have the insns be
> the same size or is it simply because CLFLUSH can stomach it?
> 
> :-)

Essentially we need one additional byte at the beginning of the clflush so
that we can flip it into a clflushopt by changing that byte into a 0x66
prefix.  Two options are to either insert a 1 byte ASM_NOP1, or to add a 1
byte NOP_DS_PREFIX.  Both have no functional effect with the plain clflush,
but I've been told that executing a clflush + prefix should be faster than
executing a clflush + NOP.

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

[Ross Zwisler]

On Tue, 2014-11-11 at 20:19 +0100, Borislav Petkov wrote:
> On Tue, Nov 11, 2014 at 08:12:39PM +0100, Borislav Petkov wrote:
> > > +  ".byte 0x66; xsaveopt %P0",
> > 
> > Huh, XSAVEOPT?!? Shouldn't that be CLWB??
> 
> Bah, the same opcodes, only 0x66 prefix makes it into CLWB. Could use a
> comment I guess.

Yep, it's weird, I know.  :)  I'll add a comment.

Thanks,
- Ross

LibDRM Cloned Monitor Support

[Rian Quinn]

What exactly is the correct way to support cloned monitors using LibDRM. As
I see it, there are two methods:

- Use the connector array in drmModeSetCrtc
- Use one crtc per connector, but share the same framebuffer.

Right now I am using option #2 as it seems to be the most flexible, but my
current issue is that on laptops, the connector for the laptop's main
screen is only retuning 1 mode (tested on a Lenovo, and an HP folio), which
means that your unlikely to find a common mode between the laptop monitor,
and an external screen (monitor or projector).

So with the above problem, right now the only thing that I know to do would
be to set the resolution of the laptop monitor and external monitor to be
their "preferred" resolution, and then copy and scale for "cloned mode"
which seems like a terrible idea considering the laptop monitor should be
able to set itself to some more basic resolutions (like 800x600).

- Rian
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/5cf1c594/attachment.html>

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

[Ross Zwisler]

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.

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;
}
-- 
1.9.3

[PATCH 5/6] x86: Use clwb in drm_clflush_page

[Ross Zwisler]

If clwb is available on the system, use it in drm_clflush_page.
If clwb is not available, fall back to clflushopt if you can.
If clflushopt is not supported, fall all the way back to clflush.

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 | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index a6b6906..aad9d82 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -34,9 +34,9 @@
 #if defined(CONFIG_X86)

 /*
- * clflushopt is an unordered instruction which needs fencing with mfence or
- * sfence to avoid ordering issues.  For drm_clflush_page this fencing happens
- * in the caller.
+ * clwb and clflushopt are unordered instructions which need fencing with
+ * mfence or sfence to avoid ordering issues.  For drm_clflush_page this
+ * fencing happens in the caller.
  */
 static void
 drm_clflush_page(struct page *page)
@@ -50,7 +50,7 @@ drm_clflush_page(struct page *page)

page_virtual = kmap_atomic(page);
for (i = 0; i < PAGE_SIZE; i += size)
-   clflushopt(page_virtual + i);
+   clwb(page_virtual + i);
kunmap_atomic(page_virtual);
 }

-- 
1.9.3

[PATCH 4/6] x86: Use clwb in clflush_cache_range

[Ross Zwisler]

If clwb is available on the system, use it in clflush_cache_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.

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/mm/pageattr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 36de293..5229d45 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -126,8 +126,8 @@ within(unsigned long addr, unsigned long start, unsigned 
long end)
  * @vaddr: virtual start address
  * @size:  number of bytes to flush
  *
- * clflushopt is an unordered instruction which needs fencing with mfence or
- * sfence to avoid ordering issues.
+ * clflushopt and clwb are unordered instructions which need fencing with
+ * mfence or sfence to avoid ordering issues.
  */
 void clflush_cache_range(void *vaddr, unsigned int size)
 {
@@ -136,11 +136,11 @@ void clflush_cache_range(void *vaddr, unsigned int size)
mb();

for (; vaddr < vend; vaddr += boot_cpu_data.x86_clflush_size)
-   clflushopt(vaddr);
+   clwb(vaddr);
/*
 * Flush any possible final partial cacheline:
 */
-   clflushopt(vend);
+   clwb(vend);

mb();
 }
-- 
1.9.3

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

[Ross Zwisler]

Add support for the new clwb 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

Here are some things of note:

 - As with the clflushopt patches before this, I'm assuming that the addressing
   mode generated by the original clflush instruction will match the new
   clflush instruction with the 0x66 prefix for clflushopt, and for the
   xsaveopt instruction with the 0x66 prefix for clwb.  For all the test cases
   that I've come up with and for the new clwb code generated by this patch
   series, this has proven to be true on my test machine.

 - According to the SDM, xsaveopt has a form where it has a REX.W prefix.  I
   believe that this prefix will not be generated by gcc in x86_64 kernel code.
   Based on this, I don't believe I need to account for this extra prefix when
   dealing with the assembly language created for clwb.  Please correct me if
   I'm wrong.

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 | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index b3e6b89..fbbed34 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -227,6 +227,7 @@
 #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_CLWB   ( 9*32+24) /* CLWB instruction */
 #define X86_FEATURE_AVX512PF   ( 9*32+26) /* AVX-512 Prefetch */
 #define X86_FEATURE_AVX512ER   ( 9*32+27) /* AVX-512 Exponential and 
Reciprocal */
 #define X86_FEATURE_AVX512CD   ( 9*32+28) /* AVX-512 Conflict Detection */
diff --git a/arch/x86/include/asm/special_insns.h 
b/arch/x86/include/asm/special_insns.h
index 1709a2e..a328460 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -199,6 +199,16 @@ static inline void clflushopt(volatile void *__p)
   "+m" (*(volatile char __force *)__p));
 }

+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",
+X86_FEATURE_CLWB,
+"+m" (*(volatile char __force *)__p));
+}
+
 static inline void pcommit(void)
 {
alternative(ASM_NOP4, ".byte 0x66, 0x0f, 0xae, 0xf8",
-- 
1.9.3

[PATCH 2/6] x86/alternative: Add alternative_io_2

[Ross Zwisler]

Add alternative_io_2 in the spirit of alternative_input_2 and
alternative_io.  This will allow us to have instructions with an output
parameter that vary based on two CPU features.

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/alternative.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/include/asm/alternative.h 
b/arch/x86/include/asm/alternative.h
index 473bdbe..7d9ead9 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -180,6 +180,20 @@ static inline int alternatives_text_reserved(void *start, 
void *end)
asm volatile (ALTERNATIVE(oldinstr, newinstr, feature)  \
: output : "i" (0), ## input)

+/*
+ * This is similar to alternative_io. But it has two features and
+ * respective instructions.
+ *
+ * If CPU has feature2, newinstr2 is used.
+ * Otherwise, if CPU has feature1, newinstr1 is used.
+ * Otherwise, oldinstr is used.
+ */
+#define alternative_io_2(oldinstr, newinstr1, feature1, newinstr2,  \
+  feature2, output, input...)   \
+   asm volatile(ALTERNATIVE_2(oldinstr, newinstr1, feature1,\
+   newinstr2, feature2) \
+   : output : "i" (0), ## input)
+
 /* Like alternative_io, but for replacing a direct call with another one. */
 #define alternative_call(oldfunc, newfunc, feature, output, input...)  \
asm volatile (ALTERNATIVE("call %P[old]", "call %P[new]", feature) \
-- 
1.9.3

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

[Ross Zwisler]

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);
+}
+
 #define nop() asm volatile ("nop")


-- 
1.9.3

[PATCH 0/6] add support for new persistent memory instructions

[Ross Zwisler]

This patch set adds support for two new persistent memory instructions, pcommit
and clwb.  These instructions were 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

These patches apply cleanly to v3.18-rc4.

Here are some things of note:

 - As with the clflushopt patches before this, I'm assuming that the addressing
   mode generated by the original clflush instruction will match the new
   clflush instruction with the 0x66 prefix for clflushopt, and for the
   xsaveopt instruction with the 0x66 prefix for clwb.  For all the test cases
   that I've come up with and for the new clwb code generated by this patch
   series, this has proven to be true on my test machine.

 - According to the SDM, xsaveopt has a form where it has a REX.W prefix.  I
   believe that this prefix will not be generated by gcc in x86_64 kernel code.
   Based on this, I don't believe I need to account for this extra prefix when
   dealing with the assembly language created for clwb.  Please correct me if
   I'm wrong.

 - The last three patches in this series update existing uses of clflushopt to
   use clwb instead.  The assertion is that clwb is preferable to clflushopt in
   these cases because after a clwb the cache line will be clean and ready for
   eviction, but that there is a possibility that it might be referenced again
   in the future while it is still in the CPU cache, giving us a performance
   boost.

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

Ross Zwisler (6):
  x86: Add support for the pcommit instruction
  x86/alternative: Add alternative_io_2
  x86: Add support for the clwb instruction
  x86: Use clwb in clflush_cache_range
  x86: Use clwb in drm_clflush_page
  x86: Use clwb in drm_clflush_virt_range

 arch/x86/include/asm/alternative.h   | 14 ++
 arch/x86/include/asm/cpufeature.h|  2 ++
 arch/x86/include/asm/special_insns.h | 16 
 arch/x86/mm/pageattr.c   |  8 
 drivers/gpu/drm/drm_cache.c  | 12 ++--
 5 files changed, 42 insertions(+), 10 deletions(-)

-- 
1.9.3

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

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

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 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?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 2/2] 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 ...

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

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3652ed8dda80..8850f32994e3 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;
 }

@@ -2147,7 +2143,6 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   drm_modeset_lock_all(dev);
config = >mode_config;

if (file_priv->universal_planes)
@@ -2182,7 +2177,6 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
plane_resp->count_planes = num_planes;

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

@@ -2210,13 +2204,11 @@ int drm_mode_getplane(struct drm_device *dev, void 
*data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   drm_modeset_lock_all(dev);
plane = drm_plane_find(dev, plane_resp->plane_id);
-   if (!plane) {
-   ret = -ENOENT;
-   goto out;
-   }
+   if (!plane)
+   return -ENOENT;

+   drm_modeset_lock(>mutex, NULL);
if (plane->crtc)
plane_resp->crtc_id = plane->crtc->base.id;
else
@@ -2226,6 +2218,7 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
plane_resp->fb_id = plane->fb->base.id;
else
plane_resp->fb_id = 0;
+   drm_modeset_unlock(>mutex);

plane_resp->plane_id = plane->base.id;
plane_resp->possible_crtcs = plane->possible_crtcs;
@@ -2241,14 +2234,11 @@ int drm_mode_getplane(struct drm_device *dev, void 
*data,
if (copy_to_user(format_ptr,
 plane->format_types,
 sizeof(uint32_t) * plane->format_count)) {
-   ret = -EFAULT;
-   goto out;
+   return -EFAULT;
}
}
plane_resp->count_format_types = plane->format_count;

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

-- 
2.1.1

[PATCH 1/2] drm: Per-plane locking

[Daniel Vetter]

Turned out to be much simpler on top of my latest atomic stuff than
what I've feared. Some details:

- Drop the modeset_lock_all snakeoil in drm_plane_init. Same
  justification as for the equivalent change in drm_crtc_init done in

commit d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21
Author: Daniel Vetter 
Date:   Mon Sep 8 09:02:49 2014 +0200

drm: Drop modeset locking from crtc init function

  Without these the drm_modeset_lock_init would fall over the exact
  same way.

- Since the atomic core code wraps the locking switching it to
  per-plane locks was a one-line change.

- For the legacy ioctls add a plane argument to the locking helper so
  that we can grab the right plane lock (cursor or primary). Since the
  universal cursor plane might not be there, or someone really crazy
  might forgoe the primary plane even accept NULL.

- Add some locking WARN_ON to the atomic helpers for good paranoid
  measure and to check that it all works out.

Tested on my exynos atomic hackfest with full lockdep checks and ww
backoff injection.

v2: I've forgotten about the load-detect code in i915.

v3: Thierry reported that in latest 3.18-rc vmwgfx doesn't compile any
more due to

commit 21e88620aa21b48d4f62d29275e3e2944a5ea2b5
Author: Rob Clark 
Date:   Thu Oct 30 13:39:04 2014 -0400

drm/vmwgfx: fix lock breakage

Rebased and fix this up.

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c |  2 +-
 drivers/gpu/drm/drm_atomic_helper.c  |  4 
 drivers/gpu/drm/drm_crtc.c   |  9 
 drivers/gpu/drm/drm_modeset_lock.c   | 43 +++-
 drivers/gpu/drm/i915/intel_display.c |  6 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  4 ++--
 include/drm/drm_crtc.h   |  2 ++
 include/drm/drm_modeset_lock.h   |  4 +++-
 8 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ed991ba66e21..ed22a719440f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -244,7 +244,7 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
 * grab all crtc locks. Once we have per-plane locks we must update this
 * to only take the plane mutex.
 */
-   ret = drm_modeset_lock_all_crtcs(state->dev, state->acquire_ctx);
+   ret = drm_modeset_lock(>mutex, state->acquire_ctx);
if (ret)
return ERR_PTR(ret);

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ca839bd9bb0d..2526de8e6cbe 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -995,6 +995,8 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,
if (!crtc)
continue;

+   WARN_ON(!drm_modeset_is_locked(>mutex));
+
funcs = crtc->helper_private;

if (!funcs || !funcs->atomic_begin)
@@ -1010,6 +1012,8 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
if (!plane)
continue;

+   WARN_ON(!drm_modeset_is_locked(>mutex));
+
funcs = plane->helper_private;

if (!funcs || !funcs->atomic_update)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e6c169152bf1..3652ed8dda80 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1152,12 +1152,12 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,
 {
int ret;

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

+   drm_modeset_lock_init(>mutex);
+
plane->base.properties = >properties;
plane->dev = dev;
plane->funcs = funcs;
@@ -1185,7 +1185,6 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,
   plane->type);

  out:
-   drm_modeset_unlock_all(dev);

return ret;
 }
@@ -2809,7 +2808,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
 * If this crtc has a universal cursor plane, call that plane's update
 * handler rather than using legacy cursor handlers.
 */
-   drm_modeset_lock_crtc(crtc);
+   drm_modeset_lock_crtc(crtc, crtc->cursor);
if (crtc->cursor) {
ret = drm_mode_cursor_universal(crtc, req, file_priv);
goto out;
@@ -4598,7 +4597,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (!crtc)
return -ENOENT;

-   drm_modeset_lock_crtc(crtc);
+   drm_modeset_lock_crtc(crtc, crtc->primary);
if (crtc->primary->fb == NULL) {
/* The framebuffer is currently unbound, presumably
 * due to a hotplug event, that userspace has not
diff --git 

[Bug 84944] tearing on radeonsi vdpau deinterlacer

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

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

--- Comment #27 from warpme at o2.pl ---

I finally managed to have the same size/offset for GUI & playback.

GUI:
xwininfo: Window id: 0x163 "MythTV Frontend"

  Absolute upper-left X:  -1
  Absolute upper-left Y:  -1
  Relative upper-left X:  -1
  Relative upper-left Y:  -1
  Width: 1920
  Height: 1080
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +-1+-1  --1+-1  --1--1  +-1--1
  -geometry 1920x1080+-1+-1

Video playback:
xwininfo: Window id: 0x1600072 "MythTV Frontend"

  Absolute upper-left X:  -1
  Absolute upper-left Y:  -1
  Relative upper-left X:  -1
  Relative upper-left Y:  -1
  Width: 1920
  Height: 1080
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +-1+-1  --1+-1  --1--1  +-1--1
  -geometry 1920x1080+-1+-1

By this errors like below gone:

[1561601.461] (--) RADEON(0): HDMI max TMDS frequency 17KHz
[1561609.906] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1561609.906] Window clipList extents: (1, 1)-(1920, 1080)
[1561609.906] Root window extents: (0, 0)-(1920, 1080)
[1561609.906] Can\'t flip because DRI2CanFlip failed
[1561609.941] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1561609.941] Window clipList extents: (1, 1)-(1920, 1080)
[1561609.941] Root window extents: (0, 0)-(1920, 1080)
[1561609.941] Can\'t flip because DRI2CanFlip failed
[1561611.345] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:



Unfortunately I'm still getting 

[2654838.916] Can\'t flip because can_exchange failed
[2654839.124] Can\'t flip because can_exchange failed
[2654860.487] Can\'t flip because can_exchange failed
[2654862.887] Can\'t flip because can_exchange failed

Test were on kernel 3.16.7, drm 2.4.58, Mesa 10.3.3, Xserver 1.16.1

-- 
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/2014/45c00199/attachment.html>

[Intel-gfx] [PATCH 2/2] drm: More specific locking for get* ioctls

[Sean Paul]

On Tue, Nov 11, 2014 at 10:12:01AM +0100, Daniel Vetter wrote:
> 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 ...
> 
> Signed-off-by: Daniel Vetter 

Just a couple nits.

> ---
>  drivers/gpu/drm/drm_crtc.c | 46 
> ++
>  1 file changed, 18 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3652ed8dda80..8850f32994e3 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;
>  }
>  
> @@ -2147,7 +2143,6 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
> *data,
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
>  
> - drm_modeset_lock_all(dev);
>   config = >mode_config;

I'd feel better if you added a comment here similar to the one above
explaining that the plane_list cannot change and thus accessing it does not
require locking config->mutex.

>  
>   if (file_priv->universal_planes)
> @@ -2182,7 +2177,6 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
> *data,
>   plane_resp->count_planes = num_planes;
>  
>  out:

I think you can just remove this label entirely and return straight from the
failure cases.

> - drm_modeset_unlock_all(dev);
>   return ret;
>  }
>  
> @@ -2210,13 +2204,11 @@ int drm_mode_getplane(struct drm_device *dev, void 
> *data,
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
>  
> - drm_modeset_lock_all(dev);
>   plane = drm_plane_find(dev, plane_resp->plane_id);
> - if (!plane) {
> - ret = -ENOENT;
> - goto out;
> - }
> + if (!plane)
> + return -ENOENT;
>  
> + drm_modeset_lock(>mutex, NULL);
>   if (plane->crtc)
>   plane_resp->crtc_id = plane->crtc->base.id;
>   else
> @@ -2226,6 +2218,7 @@ int drm_mode_getplane(struct drm_device *dev, void 
> *data,
>   plane_resp->fb_id = plane->fb->base.id;
>   else
>   plane_resp->fb_id = 0;
> + drm_modeset_unlock(>mutex);
>  
>   plane_resp->plane_id = plane->base.id;
>   plane_resp->possible_crtcs = plane->possible_crtcs;
> @@ -2241,14 +2234,11 @@ int drm_mode_getplane(struct drm_device *dev, void 
> *data,
>   if 

[Intel-gfx] [PATCH 1/2] drm: Per-plane locking

[Sean Paul]

On Tue, Nov 11, 2014 at 10:12:00AM +0100, Daniel Vetter wrote:
> Turned out to be much simpler on top of my latest atomic stuff than
> what I've feared. Some details:
> 
> - Drop the modeset_lock_all snakeoil in drm_plane_init. Same
>   justification as for the equivalent change in drm_crtc_init done in
> 
>   commit d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21
>   Author: Daniel Vetter 
>   Date:   Mon Sep 8 09:02:49 2014 +0200
> 
>   drm: Drop modeset locking from crtc init function
> 
>   Without these the drm_modeset_lock_init would fall over the exact
>   same way.
> 
> - Since the atomic core code wraps the locking switching it to
>   per-plane locks was a one-line change.
> 
> - For the legacy ioctls add a plane argument to the locking helper so
>   that we can grab the right plane lock (cursor or primary). Since the
>   universal cursor plane might not be there, or someone really crazy
>   might forgoe the primary plane even accept NULL.
> 
> - Add some locking WARN_ON to the atomic helpers for good paranoid
>   measure and to check that it all works out.
> 
> Tested on my exynos atomic hackfest with full lockdep checks and ww
> backoff injection.
> 
> v2: I've forgotten about the load-detect code in i915.
> 
> v3: Thierry reported that in latest 3.18-rc vmwgfx doesn't compile any
> more due to
> 
> commit 21e88620aa21b48d4f62d29275e3e2944a5ea2b5
> Author: Rob Clark 
> Date:   Thu Oct 30 13:39:04 2014 -0400
> 
> drm/vmwgfx: fix lock breakage
> 
> Rebased and fix this up.
> 
> Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 


One minor nit about avoiding the recursive lock handling in drm_modeset_lock. I
am fine with the patch either way.

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_atomic.c |  2 +-
>  drivers/gpu/drm/drm_atomic_helper.c  |  4 
>  drivers/gpu/drm/drm_crtc.c   |  9 
>  drivers/gpu/drm/drm_modeset_lock.c   | 43 
> +++-
>  drivers/gpu/drm/i915/intel_display.c |  6 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  4 ++--
>  include/drm/drm_crtc.h   |  2 ++
>  include/drm/drm_modeset_lock.h   |  4 +++-
>  8 files changed, 55 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ed991ba66e21..ed22a719440f 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -244,7 +244,7 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
>* grab all crtc locks. Once we have per-plane locks we must update this
>* to only take the plane mutex.
>*/
> - ret = drm_modeset_lock_all_crtcs(state->dev, state->acquire_ctx);
> + ret = drm_modeset_lock(>mutex, state->acquire_ctx);
>   if (ret)
>   return ERR_PTR(ret);
>  
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ca839bd9bb0d..2526de8e6cbe 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -995,6 +995,8 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>   if (!crtc)
>   continue;
>  
> + WARN_ON(!drm_modeset_is_locked(>mutex));
> +
>   funcs = crtc->helper_private;
>  
>   if (!funcs || !funcs->atomic_begin)
> @@ -1010,6 +1012,8 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>   if (!plane)
>   continue;
>  
> + WARN_ON(!drm_modeset_is_locked(>mutex));
> +
>   funcs = plane->helper_private;
>  
>   if (!funcs || !funcs->atomic_update)
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e6c169152bf1..3652ed8dda80 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1152,12 +1152,12 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>  {
>   int ret;
>  
> - drm_modeset_lock_all(dev);
> -
>   ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
>   if (ret)
>   goto out;
>  
> + drm_modeset_lock_init(>mutex);
> +
>   plane->base.properties = >properties;
>   plane->dev = dev;
>   plane->funcs = funcs;
> @@ -1185,7 +1185,6 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>  plane->type);
>  
>   out:
> - drm_modeset_unlock_all(dev);
>  
>   return ret;
>  }
> @@ -2809,7 +2808,7 @@ static int drm_mode_cursor_common(struct drm_device 
> *dev,
>* If this crtc has a universal cursor plane, call that plane's update
>* handler rather than using legacy cursor handlers.
>*/
> - drm_modeset_lock_crtc(crtc);
> + drm_modeset_lock_crtc(crtc, crtc->cursor);
>   if (crtc->cursor) {
>   ret = drm_mode_cursor_universal(crtc, req, file_priv);
>   goto out;
> @@ -4598,7 +4597,7 

[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 #35 from Michel Dänzer  ---
(In reply to Alexandre Demers from comment #32)
> I'm still bisecting.

Did you get somewhere with the bisection? If not (or regardless), might be
worth testing the Mesa patches I attached to bug 85647.

-- 
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/2014/184e52cc/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #219 from Michel Dänzer  ---
Might be worth trying the Mesa patches I attached to bug 85647.

-- 
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/20141111/e21bec1c/attachment.html>

[PATCH] drm/radeon: add locking around atombios scratch space usage

[Dave Airlie]

From: Dave Airlie 

While developing MST support I noticed I often got the wrong data
back from a transaction, in a racy fashion. I noticed the scratch
space wasn't locked against concurrent users.

Based on a patch by Alex, but I've made it a bit more obvious when
things are locked.

Signed-off-by: Dave Airlie 
---
 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(-)

diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 6f26eb7..bec41c4 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -1218,7 +1218,7 @@ free:
return ret;
 }

-int atom_execute_table(struct atom_context *ctx, int index, uint32_t * params)
+int atom_execute_table_scratch_unlocked(struct atom_context *ctx, int index, 
uint32_t * params)
 {
int r;

@@ -1239,6 +1239,15 @@ int atom_execute_table(struct atom_context *ctx, int 
index, uint32_t * params)
return r;
 }

+int atom_execute_table(struct atom_context *ctx, int index, uint32_t * params)
+{
+   int r;
+   mutex_lock(>scratch_mutex);
+   r = atom_execute_table_scratch_unlocked(ctx, index, params);
+   mutex_unlock(>scratch_mutex);
+   return r;
+}
+
 static int atom_iio_len[] = { 1, 2, 3, 3, 3, 3, 4, 4, 4, 3 };

 static void atom_index_iio(struct atom_context *ctx, int base)
diff --git a/drivers/gpu/drm/radeon/atom.h b/drivers/gpu/drm/radeon/atom.h
index bf9e6f2..6dffe15 100644
--- a/drivers/gpu/drm/radeon/atom.h
+++ b/drivers/gpu/drm/radeon/atom.h
@@ -125,6 +125,7 @@ struct card_info {
 struct atom_context {
struct card_info *card;
struct mutex mutex;
+   struct mutex scratch_mutex;
void *bios;
uint32_t cmd_table, data_table;
uint16_t *iio;
@@ -146,6 +147,7 @@ extern int atom_reg_debug;

 struct atom_context *atom_parse(struct card_info *, void *);
 int atom_execute_table(struct atom_context *, int, uint32_t *);
+int atom_execute_table_scratch_unlocked(struct atom_context *, int, uint32_t 
*);
 int atom_asic_init(struct atom_context *);
 void atom_destroy(struct atom_context *);
 bool atom_parse_data_header(struct atom_context *ctx, int index, uint16_t 
*size,
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index bd96ae7..0f39d96 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -100,6 +100,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
memset(, 0, sizeof(args));

mutex_lock(>mutex);
+   mutex_lock(>mode_info.atom_context->scratch_mutex);

base = (unsigned char *)(rdev->mode_info.atom_context->scratch + 1);

@@ -113,7 +114,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
if (ASIC_IS_DCE4(rdev))
args.v2.ucHPD_ID = chan->rec.hpd;

-   atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*));
+   atom_execute_table_scratch_unlocked(rdev->mode_info.atom_context, 
index, (uint32_t *));

*ack = args.v1.ucReplyStatus;

@@ -147,6 +148,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,

r = recv_bytes;
 done:
+   mutex_unlock(>mode_info.atom_context->scratch_mutex);
mutex_unlock(>mutex);

return r;
diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c 
b/drivers/gpu/drm/radeon/atombios_i2c.c
index 9c570fb..4157780 100644
--- a/drivers/gpu/drm/radeon/atombios_i2c.c
+++ b/drivers/gpu/drm/radeon/atombios_i2c.c
@@ -48,6 +48,7 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan,
memset(, 0, sizeof(args));

mutex_lock(>mutex);
+   mutex_lock(>mode_info.atom_context->scratch_mutex);

base = (unsigned char *)rdev->mode_info.atom_context->scratch;

@@ -82,7 +83,7 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan,
args.ucSlaveAddr = slave_addr << 1;
args.ucLineNumber = chan->rec.i2c_id;

-   atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*));
+   atom_execute_table_scratch_unlocked(rdev->mode_info.atom_context, 
index, (uint32_t *));

/* error */
if (args.ucStatus != HW_ASSISTED_I2C_STATUS_SUCCESS) {
@@ -95,6 +96,7 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan,
radeon_atom_copy_swap(buf, base, num, false);

 done:
+   mutex_unlock(>mode_info.atom_context->scratch_mutex);
mutex_unlock(>mutex);

return r;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 0d77dce..e63c9a4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -950,6 +950,7 @@ int radeon_atombios_init(struct radeon_device 

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

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

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

--- Comment #20 from Hannu  ---
Created attachment 109263
  --> https://bugs.freedesktop.org/attachment.cgi?id=109263=edit
diff when patched with "radeonsi: Disable asynchronous DMA except for
PIPE_BUFFER"

Applied the patch, it was not for mesa 10.3.2 version. I attached the diff.

I will test with the same video as yesterday as soon as I get the packages
built.

-- 
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/2014/ab1fd9b5/attachment.html>

[PATCH 2/2] drm/edid: fix Baseline_ELD_Len field in drm_edid_to_eld()

[Ben Skeggs]

On Mon, Nov 10, 2014 at 11:39 PM, Daniel Vetter  wrote:
> Hi Ben,
>
> The below patch from Jani also touches nouveau, can you please take a
> look at it an ack? The core part + nouveau apply on top of drm-next,
> the i915 part needs stuff from my next queue. So I'd prefer if we can
> get this in through drm-intel-next.
>
> Hi Dave,
>
> Ack on that from your side?
>
> Cheers, Daniel
>
> On Tue, Oct 28, 2014 at 3:20 PM, Jani Nikula  wrote:
>> The Baseline_ELD_Len field does not include ELD Header Block size.
>>
>> From High Definition Audio Specification, Revision 1.0a:
>>
>> The header block is a fixed size of 4 bytes. The baseline block
>> is variable size in multiple of 4 bytes, and its size is defined
>> in the header block Baseline_ELD_Len field (in number of
>> DWords).
>>
>> Do not include the header size in Baseline_ELD_Len field. Fix all known
>> users of eld[2].
>>
>> While at it, switch to DIV_ROUND_UP instead of open coding it.
>>
>> Signed-off-by: Jani Nikula 
Acked-by: Ben Skeggs 

>>
>> ---
>>
>> This is based on an audio rework series which is mid-way being merged to
>> i915. I don't think this should be cc: stable worthy, as, AFAICT, we
>> don't use the vendor block, and anyone reading SADs respecting SAD_Count
>> should stop at the same offset regardless of this patch. So I propose
>> this gets eventually merged via i915 without a rush.
>> ---
>>  drivers/gpu/drm/drm_edid.c |  7 +--
>>  drivers/gpu/drm/i915/intel_audio.c | 16 
>>  drivers/gpu/drm/nouveau/nv50_display.c |  3 ++-
>>  3 files changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 3bf999134bcc..45aaa6f5ef36 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3128,9 +3128,12 @@ void drm_edid_to_eld(struct drm_connector *connector, 
>> struct edid *edid)
>> }
>> }
>> eld[5] |= sad_count << 4;
>> -   eld[2] = (20 + mnl + sad_count * 3 + 3) / 4;
>>
>> -   DRM_DEBUG_KMS("ELD size %d, SAD count %d\n", (int)eld[2], sad_count);
>> +   eld[DRM_ELD_BASELINE_ELD_LEN] =
>> +   DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
>> +
>> +   DRM_DEBUG_KMS("ELD size %d, SAD count %d\n",
>> + drm_eld_size(eld), sad_count);
>>  }
>>  EXPORT_SYMBOL(drm_edid_to_eld);
>>
>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>> b/drivers/gpu/drm/i915/intel_audio.c
>> index 20af973d7cba..439fa4afa18b 100644
>> --- a/drivers/gpu/drm/i915/intel_audio.c
>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>> @@ -107,7 +107,7 @@ static bool intel_eld_uptodate(struct drm_connector 
>> *connector,
>> tmp &= ~bits_elda;
>> I915_WRITE(reg_elda, tmp);
>>
>> -   for (i = 0; i < eld[2]; i++)
>> +   for (i = 0; i < drm_eld_size(eld) / 4; i++)
>> if (I915_READ(reg_edid) != *((uint32_t *)eld + i))
>> return false;
>>
>> @@ -162,7 +162,7 @@ static void g4x_audio_codec_enable(struct drm_connector 
>> *connector,
>> len = (tmp >> 9) & 0x1f;/* ELD buffer size */
>> I915_WRITE(G4X_AUD_CNTL_ST, tmp);
>>
>> -   len = min_t(int, eld[2], len);
>> +   len = min(drm_eld_size(eld) / 4, len);
>> DRM_DEBUG_DRIVER("ELD size %d\n", len);
>> for (i = 0; i < len; i++)
>> I915_WRITE(G4X_HDMIW_HDMIEDID, *((uint32_t *)eld + i));
>> @@ -209,7 +209,7 @@ static void hsw_audio_codec_enable(struct drm_connector 
>> *connector,
>> int len, i;
>>
>> DRM_DEBUG_KMS("Enable audio codec on pipe %c, %u bytes ELD\n",
>> - pipe_name(pipe), eld[2]);
>> + pipe_name(pipe), drm_eld_size(eld));
>>
>> /* Enable audio presence detect, invalidate ELD */
>> tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
>> @@ -225,8 +225,8 @@ static void hsw_audio_codec_enable(struct drm_connector 
>> *connector,
>> I915_WRITE(HSW_AUD_DIP_ELD_CTRL(pipe), tmp);
>>
>> /* Up to 84 bytes of hw ELD buffer */
>> -   len = min_t(int, eld[2], 21);
>> -   for (i = 0; i < len; i++)
>> +   len = min(drm_eld_size(eld), 84);
>> +   for (i = 0; i < len / 4; i++)
>> I915_WRITE(HSW_AUD_EDID_DATA(pipe), *((uint32_t *)eld + i));
>>
>> /* ELD valid */
>> @@ -315,7 +315,7 @@ static void ilk_audio_codec_enable(struct drm_connector 
>> *connector,
>> int aud_cntrl_st2;
>>
>> DRM_DEBUG_KMS("Enable audio codec on port %c, pipe %c, %u bytes 
>> ELD\n",
>> - port_name(port), pipe_name(pipe), eld[2]);
>> + port_name(port), pipe_name(pipe), drm_eld_size(eld));
>>
>> /* XXX: vblank wait here */
>>
>> @@ -354,8 +354,8 @@ static void ilk_audio_codec_enable(struct drm_connector 
>> *connector,
>> I915_WRITE(aud_cntl_st, tmp);
>>
>> /* Up to 84 bytes of hw ELD buffer */
>> -   

mmap fails for DRM_IOCTL_MODE_MAP_DUMB for Radeon, Nouveau, and VMWGFX

[Dave Airlie]

On 11 November 2014 07:33, Rian Quinn  wrote:
> I would be surprised if the size argument was the issue. That comes right
> out out of the create IOCTL unmodified. Here is the full source that I am
> using.
>
> // Clear the arg buffers.
> memset(_arg, 0, sizeof(create_arg));
> memset(_arg, 0, sizeof(map_arg));
>
> //
> 
> // Allocate
>
> // Fill in the arguments for the IOCTL. Note that we only support 32bpp
> // dumb buffers so that is hard coded here.
> create_arg.width = width;
> create_arg.height = height;
> create_arg.bpp = 32;
>
> // Allocate the dumb buffer
> if (drmIoctl(gpu->fd(), DRM_IOCTL_MODE_CREATE_DUMB, _arg))
> {
> svWarning(0) << "Failed: DRM_IOCTL_MODE_CREATE_DUMB - " <<
> strerror(errno);
> return;
> }
>
> // Store the dumb buffer properties.
> mSize = create_arg.size;
> mStride = create_arg.pitch;
> mHandle = create_arg.handle;
>
> //
> 
> // Map
>
> // Fill in the arguments for the IOCTL.
> map_arg.handle = mHandle;
>
> // Allocate the dumb buffer
> if (drmIoctl(gpu->fd(), DRM_IOCTL_MODE_MAP_DUMB, _arg))
> {
> svWarning(0) << "Failed: DRM_IOCTL_MODE_MAP_DUMB - " <<
> strerror(errno);
> return;
> }
>
> // Store the mapped memory
> if ((mVaddr = (svuint32 *)mmap(0, mSize, PROT_READ | PROT_WRITE,
> MAP_SHARED, gpu->fd(), map_arg.offset)) == MAP_FAILED)
> {
> // Need to clear out the address so that we don't try to use it.
> mVaddr = NULL;
>
> // Error out.
> svWarning(0) << "Failed: Dumb Buffer mmap - " << strerror(errno);
> return;
> }
>

mmap is probably truncating the offset,

look into,
#define _FILE_OFFSET_BITS 64

AC_SYS_LARGEFILE

Dave.