date:20140402

On Wed, Mar 26, 2014 at 1:22 PM, Ben Skeggs  wrote:
> On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot  
> wrote:
>> Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
>> run from non-prepadded firmware files.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> index f997a18f5760..367e72daf8b1 100644
>> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> @@ -768,6 +768,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 
>> fuc_base,
>> nv_wr32(priv, fuc_base + 0x0188, i >> 6);
>> nv_wr32(priv, fuc_base + 0x0184, code->data[i]);
>> }
>> +
>> +   /* code must be padded to 0x40 */
>> +   for (; i < (((code->size / 4) + 0x3f) & ~0x3f); i++)
> "for (; i & 0x3f; i++)" would work just as well :)

Indeed. >_<

[PATCH 08/12] drm/nouveau/graph: enable when using external firmware

On Wed, Mar 26, 2014 at 1:21 PM, Ben Skeggs  wrote:
> On Tue, Mar 25, 2014 at 8:58 AM, Thierry Reding
>  wrote:
>> On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote:
>> [...]
>>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
>>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> index 6ef8bf181b2d..f997a18f5760 100644
>>> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> @@ -1133,10 +1133,14 @@ nvc0_graph_ctor(struct nouveau_object *parent, 
>>> struct nouveau_object *engine,
>>>   struct nvc0_graph_oclass *oclass = (void *)bclass;
>>>   struct nouveau_device *device = nv_device(parent);
>>>   struct nvc0_graph_priv *priv;
>>> + bool use_fw;
>>
>> Perhaps "ext_fw" or "use_ext_fw" would be more accurate.
>>
>>>   int ret, i;
>>>
>>> + use_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW", false);
>>> +
>>>   ret = nouveau_graph_create(parent, engine, bclass,
>>> -(oclass->fecs.ucode != NULL), );
>>> +(oclass->fecs.ucode != NULL) || use_fw,
>>> +);
>>
>> Or perhaps a more intuitive way would be to name the variable "enable"
>> and have something like:
>>
>> if (!nouveau_boolopt(device->cfgopt, "NvGrUseFW", false))
>> enable = oclass->fecs.ucode != NULL;
>> else
>> enable = true;
>>
>> ret = nouveau_graph_create(parent, engine, bclass, enable, );
>> ...
> Agreed, this looks a lot nicer.

Will fix that, thanks!

[PATCH 06/12] drm/nouveau/ibus: add GK20A support

On Tue, Mar 25, 2014 at 7:34 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c 
>> b/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
> [...]
>> +#include 
>> +
>> +struct nvea_ibus_priv {
>> + struct nouveau_ibus base;
>> +};
>> +
>> +static void
>> +nvea_ibus_init_priv_ring(struct nvea_ibus_priv *priv)
>> +{
>> + nv_mask(priv, 0x137250, 0x3f, 0);
>> +
>> + nv_mask(priv, 0x000200, 0x20, 0);
>> + udelay(20);
>
> usleep_range()?

Sure.

>
>> +static void
>> +nvea_ibus_intr(struct nouveau_subdev *subdev)
>> +{
> [...]
>> + /* Acknowledge interrupt */
>> + nv_mask(priv, 0x12004c, 0x2, 0x2);
>> +
>> + while (--retry >= 0) {
>> + command = nv_rd32(priv, 0x12004c) & 0x3f;
>> + if (command == 0)
>> + break;
>> + }
>> +
>> + if (retry < 0)
>> + nv_warn(priv, "timeout waiting for ringmaster ack\n");
>> +}
>
> Perhaps I'm being paranoid, but this loop now depends on the frequency
> of the various clocks involved and therefore might break at some point
> if the frequencies get sufficiently high.
>
> So a slightly safer implementation would use a proper timeout using a
> combination of msecs_to_jiffies(), time_before() and usleep_range(),
> like so:
>
> timeout = jiffies + msecs_to_jiffies(...);
>
> while (time_before(jiffies, timeout)) {
> command = nv_rd32(...) & 0x3f;
> if (command == 0)
> break;
>
> usleep_range(...);
> }
>
> if (time_after(jiffies, timeout))
> nv_warn(...);

Right, now that I look at this code again I don't even understand why
I left it this way. Maybe I left some early test code slip into the
final patch, sorry about that.

> This assumes that there's some known timeout after which the ringmaster
> is expected to have acked the interrupt. On that note, I wonder if the
> warning is accurate here: it's my understanding that writing 0x2 to the
> register does acknowledge the interrupt, so the ringmaster does in fact
> "clear" it rather than "acknowledge" it, doesn't it?
>
> Although now that I mention it I seem to remember that this write is
> actually sending a command to the ring master and perhaps waiting for
> the register to return to 0 is indeed waiting for an ACK of sorts. Maybe
> adding a comment or so describing what this sequence does would be
> appropriate here?

Can we from an IP point of view? AFAIK this sequence has never been
publicly documented.

[PATCH 04/12] drm/nouveau/bar/nvc0: support chips without BAR3

On Tue, Mar 25, 2014 at 7:10 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:26PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c 
>> b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
> [...]
>>  static int
>> -nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
>> -   struct nouveau_oclass *oclass, void *data, u32 size,
>> -   struct nouveau_object **pobject)
>> +nvc0_bar_init_vm(struct nvc0_bar_priv *priv, int nr, int bar)
>>  {
> [...]
>> - /* BAR3 */
>>   ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x1000, 0, 0,
>> - >bar[0].mem);
>> - mem = priv->bar[0].mem;
>> + >bar[nr].mem);
>> + mem = priv->bar[nr].mem;
>>   if (ret)
>>   return ret;
>>
>>   ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x8000, 0, 0,
>> - >bar[0].pgd);
>> + >bar[nr].pgd);
>>   if (ret)
>>   return ret;
> [...]
>> +static int
>> +nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
>> +   struct nouveau_oclass *oclass, void *data, u32 size,
>> +   struct nouveau_object **pobject)
>> +{
> [...]
>> + /* BAR3 */
>> + if (has_bar3) {
>> + ret = nvc0_bar_init_vm(priv, 0, 3);
> [...]
>> + /* BAR1 */
>> + ret = nvc0_bar_init_vm(priv, 1, 1);
>>   if (ret)
>>   return ret;
>
> The calls to nvc0_bar_init_vm() are somewhat confusing in my opinion. It
> is hard to see from the invocation what these numbers mean and therefore
> distinguish which parameter is which.
>
> Perhaps a slightly more readable way would be to pass in a pointer to a
> structure as second parameter instead of the index into an array. So
> it'd look somewhat like this:
>
> if (has_bar3) {
> ret = nvc0_bar_init_vm(priv, >bar[0], 3);
> ...
> }
> ...
> ret = nvc0_bar_init_vm(priv, >bar[1], 1);
> ...
>
> Unfortunately that would require a new type to be created for the bar[]
> structures, so it'd be slightly more intrusive.

These types are local to nvc0.c anyway, so I don't think it would
hurt. And you are right that the code would become more readable as a
result, passing array indexes as arguments is not a common practice
(and should not be).

Alex.

[PATCH 5/5] drm/exynos: enable support for exynos5420 hdmi device

From: Rahul Sharma 

Enable support for hdmi for exynos5420 hdmiphy. Add
compatible string in the of_match table. Also added
hdmiphy configuration values for exynos5420.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shirish S 
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  165 
 2 files changed, 166 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 243a499..1fd8cf9 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -5,6 +5,7 @@ Required properties:
1) "samsung,exynos5-hdmi" 
2) "samsung,exynos4210-hdmi"
3) "samsung,exynos4212-hdmi"
+   4) "samsung,exynos5420-hdmi"
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5989770..f3189af 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -426,6 +426,168 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] 
= {
},
 };

+static const struct hdmiphy_config hdmiphy_5420_configs[] = {
+   {
+   .pixel_clock = 2520,
+   .conf = {
+   0x01, 0x52, 0x3F, 0x55, 0x40, 0x01, 0x00, 0xC8,
+   0x82, 0xC8, 0xBD, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x06, 0x80, 0x01, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xF4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 2700,
+   .conf = {
+   0x01, 0xD1, 0x22, 0x51, 0x40, 0x08, 0xFC, 0xE0,
+   0x98, 0xE8, 0xCB, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xE4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 27027000,
+   .conf = {
+   0x01, 0xD1, 0x2D, 0x72, 0x40, 0x64, 0x12, 0xC8,
+   0x43, 0xE8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+   0x26, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xE3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 3600,
+   .conf = {
+   0x01, 0x51, 0x2D, 0x55, 0x40, 0x40, 0x00, 0xC8,
+   0x02, 0xC8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xAB, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 4000,
+   .conf = {
+   0x01, 0xD1, 0x21, 0x31, 0x40, 0x3C, 0x28, 0xC8,
+   0x87, 0xE8, 0xC8, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0x9A, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 6500,
+   .conf = {
+   0x01, 0xD1, 0x36, 0x34, 0x40, 0x0C, 0x04, 0xC8,
+   0x82, 0xE8, 0x45, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xBD, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 7100,
+   .conf = {
+   0x01, 0xD1, 0x3B, 0x35, 0x40, 0x0C, 0x04, 0xC8,
+   0x85, 0xE8, 0x63, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0x57, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 7325,
+   .conf = {
+   0x01, 0xD1, 0x1F, 0x10, 0x40, 0x78, 0x8D, 0xC8,
+   0x81, 0xE8, 0xB7, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xA8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 74176000,
+   .conf = {
+   0x01, 0xD1, 0x1F, 0x10, 0x40, 0x5B, 0xEF, 0xC8,
+   0x81, 0xE8, 0xB9, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xA6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock =

[PATCH 4/5] drm/exynos: add support for apb mapped phys in hdmi driver

From: Rahul Sharma 

Previous SoCs have hdmi phys which are accessible through
dedicated i2c lines. Newer SoCs have Apb mapped hdmi phys.
Hdmi driver is modified to support apb mapped phys.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |  142 +-
 drivers/gpu/drm/exynos/regs-hdmi.h   |7 ++
 2 files changed, 96 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5b2cfe7..5989770 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -68,6 +69,8 @@ enum hdmi_type {

 struct hdmi_driver_data {
unsigned int type;
+   const struct hdmiphy_config *phy_confs;
+   unsigned int phy_conf_count;
unsigned int is_apb_phy:1;
 };

@@ -196,9 +199,12 @@ struct hdmi_context {
struct hdmi_resources   res;

int hpd_gpio;
+   void __iomem*regs_hdmiphy;
struct regmap   *pmureg;

enum hdmi_type  type;
+   const struct hdmiphy_config *phy_confs;
+   unsigned intphy_conf_count;
 };

 struct hdmiphy_config {
@@ -206,14 +212,6 @@ struct hdmiphy_config {
u8 conf[32];
 };

-struct hdmi_driver_data exynos4212_hdmi_driver_data = {
-   .type   = HDMI_TYPE14,
-};
-
-struct hdmi_driver_data exynos5_hdmi_driver_data = {
-   .type   = HDMI_TYPE14,
-};
-
 /* list of phy config settings */
 static const struct hdmiphy_config hdmiphy_v13_configs[] = {
{
@@ -428,6 +426,21 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = 
{
},
 };

+
+struct hdmi_driver_data exynos4212_hdmi_driver_data = {
+   .type   = HDMI_TYPE14,
+   .phy_confs  = hdmiphy_v14_configs,
+   .phy_conf_count = ARRAY_SIZE(hdmiphy_v14_configs),
+   .is_apb_phy = 0,
+};
+
+struct hdmi_driver_data exynos5_hdmi_driver_data = {
+   .type   = HDMI_TYPE14,
+   .phy_confs  = hdmiphy_v13_configs,
+   .phy_conf_count = ARRAY_SIZE(hdmiphy_v13_configs),
+   .is_apb_phy = 0,
+};
+
 static inline u32 hdmi_reg_read(struct hdmi_context *hdata, u32 reg_id)
 {
return readl(hdata->regs + reg_id);
@@ -447,6 +460,48 @@ static inline void hdmi_reg_writemask(struct hdmi_context 
*hdata,
writel(value, hdata->regs + reg_id);
 }

+static int hdmiphy_reg_writeb(struct hdmi_context *hdata,
+   u32 reg_offset, u8 value)
+{
+   if (hdata->hdmiphy_port) {
+   u8 buffer[2];
+   int ret;
+
+   buffer[0] = reg_offset;
+   buffer[1] = value;
+
+   ret = i2c_master_send(hdata->hdmiphy_port, buffer, 2);
+   if (ret == 2)
+   return 0;
+   return ret;
+   } else {
+   writeb(value, hdata->regs_hdmiphy + (reg_offset<<2));
+   return 0;
+   }
+}
+
+static int hdmiphy_reg_write_buf(struct hdmi_context *hdata,
+   u32 reg_offset, const u8 *buf, u32 len)
+{
+   if ((reg_offset + len) > 32)
+   return -EINVAL;
+
+   if (hdata->hdmiphy_port) {
+   int ret;
+
+   ret = i2c_master_send(hdata->hdmiphy_port, buf, len);
+   if (ret == len)
+   return 0;
+   return ret;
+   } else {
+   int i;
+   for (i = 0; i < len; i++)
+   writeb(buf[i], hdata->regs_hdmiphy +
+   ((reg_offset + i)<<2));
+   return 0;
+   }
+}
+
 static void hdmi_v13_regs_dump(struct hdmi_context *hdata, char *prefix)
 {
 #define DUMPREG(reg_id) \
@@ -850,20 +905,10 @@ static int hdmi_get_modes(struct drm_connector *connector)

 static int hdmi_find_phy_conf(struct hdmi_context *hdata, u32 pixel_clock)
 {
-   const struct hdmiphy_config *confs;
-   int count, i;
-
-   if (hdata->type == HDMI_TYPE13) {
-   confs = hdmiphy_v13_configs;
-   count = ARRAY_SIZE(hdmiphy_v13_configs);
-   } else if (hdata->type == HDMI_TYPE14) {
-   confs = hdmiphy_v14_configs;
-   count = ARRAY_SIZE(hdmiphy_v14_configs);
-   } else
-   return -EINVAL;
+   int i;

-   for (i = 0; i < count; i++)
-   if (confs[i].pixel_clock == pixel_clock)
+   for (i = 0; i < hdata->phy_conf_count; i++)
+   if (hdata->phy_confs[i].pixel_clock == pixel_clock)
return i;

DRM_DEBUG_KMS("Could not find phy config for %d\n", pixel_clock);
@@ -1515,17 +1560,9 @@ static void hdmiphy_poweroff(struct hdmi_context *hdata)

 static void hdmiphy_conf_apply(struct hdmi_context *hdata)
 {
-   const u8 *hdmiphy_data;
-

[PATCH 3/5] drm/exynos: remove unnecessary read for phy configuration values

From: Rahul Sharma 

Cleaning up unnecessary i2c read call after hdmiphy configuration.
This check is redundant since check for hdmiphy pll lock status
confirms the correct settings for phy.

Signed-off-by: Rahul Sharma 
Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 47b8c06..5b2cfe7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1518,7 +1518,6 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
const u8 *hdmiphy_data;
u8 buffer[32];
u8 operation[2];
-   u8 read_buffer[32] = {0, };
int ret;
int i;

@@ -1558,15 +1557,6 @@ static void hdmiphy_conf_apply(struct hdmi_context 
*hdata)
return;
}

-   ret = i2c_master_recv(hdata->hdmiphy_port, read_buffer, 32);
-   if (ret < 0) {
-   DRM_ERROR("failed to read hdmiphy config\n");
-   return;
-   }
-
-   for (i = 0; i < ret; i++)
-   DRM_DEBUG_KMS("hdmiphy[0x%02x] write[0x%02x] - "
-   "recv [0x%02x]\n", i, buffer[i], read_buffer[i]);
 }

 static void hdmi_conf_apply(struct hdmi_context *hdata)
-- 
1.7.9.5

[PATCH 2/5] drm/exynos: use regmap interface to set hdmiphy control bit in pmu

From: Rahul Sharma 

Hdmiphy control bit needs to be set before setting the resolution
to hdmi hardware. This was handled using dummy hdmiphy clock which
is removed now.

PMU is already defined as system controller for exynos SoC. Registers
of PMU are accessed using regmap interfaces.

Devicetree binding document for hdmi is also updated.

Signed-off-by: Rahul Sharma 
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |2 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   17 +
 drivers/gpu/drm/exynos/regs-hdmi.h |4 
 3 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..243a499 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -27,6 +27,7 @@ Required properties:
"hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
 - ddc: phandle to the hdmi ddc node
 - phy: phandle to the hdmi phy node
+- samsung,syscon-phandle: phandle for system controller node for PMU.

 Example:

@@ -37,4 +38,5 @@ Example:
hpd-gpio = < 7 1>;
ddc = <_ddc_node>;
phy = <_phy_node>;
+   samsung,syscon-phandle = <_system_controller>;
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 23abfa0..47b8c06 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -36,6 +36,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 

@@ -194,6 +196,7 @@ struct hdmi_context {
struct hdmi_resources   res;

int hpd_gpio;
+   struct regmap   *pmureg;

enum hdmi_type  type;
 };
@@ -1853,6 +1856,9 @@ static void hdmi_poweron(struct exynos_drm_display 
*display)
if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
DRM_DEBUG_KMS("failed to enable regulator bulk\n");

+   /* set pmu hdmiphy control bit to enable hdmiphy */
+   regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
+   PMU_HDMI_PHY_ENABLE_BIT, 1);
clk_prepare_enable(res->hdmi);
clk_prepare_enable(res->sclk_hdmi);

@@ -1879,6 +1885,10 @@ static void hdmi_poweroff(struct exynos_drm_display 
*display)

clk_disable_unprepare(res->sclk_hdmi);
clk_disable_unprepare(res->hdmi);
+   /* reset pmu hdmiphy control bit to disable hdmiphy */
+   regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
+   PMU_HDMI_PHY_ENABLE_BIT, 0);
+
regulator_bulk_disable(res->regul_count, res->regul_bulk);

pm_runtime_put_sync(hdata->dev);
@@ -2128,6 +2138,13 @@ static int hdmi_probe(struct platform_device *pdev)
goto err_hdmiphy;
}

+   hdata->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
+   "samsung,syscon-phandle");
+   if (IS_ERR_OR_NULL(hdata->pmureg)) {
+   DRM_ERROR("syscon regmap lookup failed.\n");
+   goto err_hdmiphy;
+   }
+
pm_runtime_enable(dev);

hdmi_display.ctx = hdata;
diff --git a/drivers/gpu/drm/exynos/regs-hdmi.h 
b/drivers/gpu/drm/exynos/regs-hdmi.h
index ef1b3eb..9811d6f 100644
--- a/drivers/gpu/drm/exynos/regs-hdmi.h
+++ b/drivers/gpu/drm/exynos/regs-hdmi.h
@@ -578,4 +578,8 @@
 #define HDMI_TG_VACT_ST4_H HDMI_TG_BASE(0x0074)
 #define HDMI_TG_3D HDMI_TG_BASE(0x00F0)

+/* PMU Registers for PHY */
+#define PMU_HDMI_PHY_CONTROL   0x700
+#define PMU_HDMI_PHY_ENABLE_BIT(1<<0)
+
 #endif /* SAMSUNG_REGS_HDMI_H */
-- 
1.7.9.5

[PATCH 1/5] drm/exynos: remove dummy hdmiphy clock from hdmi driver

From: Rahul Sharma 

Exynos drm hdmi driver used to get dummy hdmiphy clock to
control the PMU bit for hdmiphy. This clock is removed
during CCF migration. This should also be cleaned from
hdmi driver.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 25bf65a..23abfa0 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -74,7 +74,6 @@ struct hdmi_resources {
struct clk  *sclk_hdmi;
struct clk  *sclk_pixel;
struct clk  *sclk_hdmiphy;
-   struct clk  *hdmiphy;
struct clk  *mout_hdmi;
struct regulator_bulk_data  *regul_bulk;
int regul_count;
@@ -1854,7 +1853,6 @@ static void hdmi_poweron(struct exynos_drm_display 
*display)
if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
DRM_DEBUG_KMS("failed to enable regulator bulk\n");

-   clk_prepare_enable(res->hdmiphy);
clk_prepare_enable(res->hdmi);
clk_prepare_enable(res->sclk_hdmi);

@@ -1881,7 +1879,6 @@ static void hdmi_poweroff(struct exynos_drm_display 
*display)

clk_disable_unprepare(res->sclk_hdmi);
clk_disable_unprepare(res->hdmi);
-   clk_disable_unprepare(res->hdmiphy);
regulator_bulk_disable(res->regul_count, res->regul_bulk);

pm_runtime_put_sync(hdata->dev);
@@ -1977,11 +1974,6 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
goto fail;
}
-   res->hdmiphy = devm_clk_get(dev, "hdmiphy");
-   if (IS_ERR(res->hdmiphy)) {
-   DRM_ERROR("failed to get clock 'hdmiphy'\n");
-   goto fail;
-   }
res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
if (IS_ERR(res->mout_hdmi)) {
DRM_ERROR("failed to get clock 'mout_hdmi'\n");
-- 
1.7.9.5

[PATCH 0/5] drm/exynos: enable support for exynos5420 hdmi

From: Rahul Sharma 

Adds apb mapped phy support for exynos5420 hdmi. Replace
dummy hdmiphy clock with regmap calls.

Based on Inki Dae's exynos-drm-next branch.

Rahul Sharma (5):
  drm/exynos: remove dummy hdmiphy clock from hdmi driver
  drm/exynos: use regmap interface to set hdmiphy control bit in pmu
  drm/exynos: remove unnecessary read for phy configuration values
  drm/exynos: add support for apb mapped phys in hdmi driver
  drm/exynos: enable support for exynos5420 hdmi device

 .../devicetree/bindings/video/exynos_hdmi.txt  |3 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  342 
 drivers/gpu/drm/exynos/regs-hdmi.h |   11 +
 3 files changed, 285 insertions(+), 71 deletions(-)

-- 
1.7.9.5

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

--- Comment #19 from nucrap at hotmail.com ---
Ah, and I also get those rectangles. So it's definately the same 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/20140402/85faf0f9/attachment.html>

[PATCH] drm/radeon: Use two-ended allocation by size, v2

This decreases eviction by up to 20%, by improving the fragmentation
quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).

In some cases, even the VRAM-fitting cases improved slightly (openarena, urban 
terror).

512kb was measured as the most optimal threshold for 3d workloads common to 
radeon.
Other drivers may need different thresholds according to their workloads.

v2: Nicer formatting
Signed-off-by: Lauri Kasanen 
---
 drivers/gpu/drm/radeon/radeon_object.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 1375ff8..19bec0d 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -104,7 +104,7 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object 
*bo)

 void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
 {
-   u32 c = 0;
+   u32 c = 0, i;

rbo->placement.fpfn = 0;
rbo->placement.lpfn = 0;
@@ -131,6 +131,17 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
*rbo, u32 domain)
rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
rbo->placement.num_placement = c;
rbo->placement.num_busy_placement = c;
+
+   /*
+* Use two-ended allocation depending on the buffer size to
+* improve fragmentation quality.
+* 512kb was measured as the most optimal number.
+*/
+   if (rbo->tbo.mem.size > 512 * 1024) {
+   for (i = 0; i < c; i++) {
+   rbo->placements[i] |= TTM_PL_FLAG_TOPDOWN;
+   }
+   }
 }

 int radeon_bo_create(struct radeon_device *rdev,
-- 
1.8.3.1

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #52 from jeroen  ---
(In reply to comment #51)
> This bugtracker is not about fglrx. Not a single thing will change for the
> radeon oss driver cause of such statements.
> 
> At the end - before we dropped support for it (xvba + fglrx) - it was not
> even able to hold vsync without one core at 100%. So that's not any
> alternative at all.
> 
> Btw. such comments are really distracting, as we never had that good support
> from AMD as we get from christian and alex right now. 

Then you misunderstand me! I think it is really good that radeon OSS is getting
so much support. I never said I want fgrlx back.

It is just that comments like "a wrong speed does NOT have direct influence on
dropped or skipped frames." are not helping without any explanation and are not
constructive. Most people on this mailing list have probably no idea how XBMC
internally works making it difficult to help us. 

-- 
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/20140402/97b010d3/attachment.html>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

benjamin.menant+debian at gmail.com changed:

   What|Removed |Added

  Attachment #96801|0   |1
is obsolete||

--- Comment #8 from benjamin.menant+debian at gmail.com ---
Created attachment 96809
  --> https://bugs.freedesktop.org/attachment.cgi?id=96809=edit
full dmesg

-- 
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/20140402/80f96b55/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #51 from Peter Fr?hberger  ---
This bugtracker is not about fglrx. Not a single thing will change for the
radeon oss driver cause of such statements.

At the end - before we dropped support for it (xvba + fglrx) - it was not even
able to hold vsync without one core at 100%. So that's not any alternative at
all.

Btw. such comments are really distracting, as we never had that good support
from AMD as we get from christian and alex right now. 

-- 
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/20140402/9b960a7d/attachment.html>

[PATCH 2/2] drm/radeon: Use two-ended allocation by size

This decreases eviction by up to 20%, by improving the fragmentation
quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).

In some cases, even the VRAM-fitting cases improved slightly (openarena, urban 
terror).

512kb was measured as the most optimal threshold for 3d workloads common to 
radeon.
Other drivers may need different thresholds according to their workloads.

Signed-off-by: Lauri Kasanen 
---
 drivers/gpu/drm/radeon/radeon_object.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 1375ff8..6251456 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -104,7 +104,7 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object 
*bo)

 void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
 {
-   u32 c = 0;
+   u32 c = 0, i;

rbo->placement.fpfn = 0;
rbo->placement.lpfn = 0;
@@ -131,6 +131,15 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
*rbo, u32 domain)
rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
rbo->placement.num_placement = c;
rbo->placement.num_busy_placement = c;
+
+   /*
+* Use two-ended allocation depending on the buffer size to
+* improve fragmentation quality.
+* 512kb was measured as the most optimal number.
+*/
+   if (rbo->tbo.mem.size > 512 * 1024) for (i = 0; i < c; i++) {
+   rbo->placements[i] |= TTM_PL_FLAG_TOPDOWN;
+   }
 }

 int radeon_bo_create(struct radeon_device *rdev,
-- 
1.8.3.1

[PATCH 1/2] drm: Add support for two-ended allocation, v3

Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion of the GTT to only those buffers that require CPU
access through the GTT.

For other drivers, allocating small bos from one end and large ones
from the other helps improve the quality of fragmentation.

Based on drm_mm work by Chris Wilson.

v3: Changed to use a TTM placement flag
v2: Updated kerneldoc

Cc: Chris Wilson 
Cc: Ben Widawsky 
Cc: Christian K?nig 
Signed-off-by: Lauri Kasanen 
---
 drivers/gpu/drm/drm_mm.c | 66 ++--
 drivers/gpu/drm/i915/i915_gem.c  |  3 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  3 +-
 drivers/gpu/drm/ttm/ttm_bo_manager.c | 11 --
 include/drm/drm_mm.h | 32 ++---
 include/drm/ttm/ttm_placement.h  |  3 ++
 6 files changed, 92 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index a2d45b74..8f64be4 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -82,6 +82,10 @@
  * this to implement guard pages between incompatible caching domains in the
  * graphics TT.
  *
+ * Two behaviors are supported for searching and allocating: bottom-up and 
top-down.
+ * The default is bottom-up. Top-down allocation can be used if the memory area
+ * has different restrictions, or just to reduce fragmentation.
+ *
  * Finally iteration helpers to walk all nodes and all holes are provided as 
are
  * some basic allocator dumpers for debugging.
  */
@@ -102,7 +106,8 @@ static struct drm_mm_node 
*drm_mm_search_free_in_range_generic(const struct drm_
 static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
 struct drm_mm_node *node,
 unsigned long size, unsigned alignment,
-unsigned long color)
+unsigned long color,
+enum drm_mm_allocator_flags flags)
 {
struct drm_mm *mm = hole_node->mm;
unsigned long hole_start = drm_mm_hole_node_start(hole_node);
@@ -115,12 +120,22 @@ static void drm_mm_insert_helper(struct drm_mm_node 
*hole_node,
if (mm->color_adjust)
mm->color_adjust(hole_node, color, _start, _end);

+   if (flags & DRM_MM_CREATE_TOP)
+   adj_start = adj_end - size;
+
if (alignment) {
unsigned tmp = adj_start % alignment;
-   if (tmp)
-   adj_start += alignment - tmp;
+   if (tmp) {
+   if (flags & DRM_MM_CREATE_TOP)
+   adj_start -= tmp;
+   else
+   adj_start += alignment - tmp;
+   }
}

+   BUG_ON(adj_start < hole_start);
+   BUG_ON(adj_end > hole_end);
+
if (adj_start == hole_start) {
hole_node->hole_follows = 0;
list_del(_node->hole_stack);
@@ -205,7 +220,8 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
  * @size: size of the allocation
  * @alignment: alignment of the allocation
  * @color: opaque tag value to use for this node
- * @flags: flags to fine-tune the allocation
+ * @sflags: flags to fine-tune the allocation search
+ * @aflags: flags to fine-tune the allocation behavior
  *
  * The preallocated node must be cleared to 0.
  *
@@ -215,16 +231,17 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
 int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
   unsigned long size, unsigned alignment,
   unsigned long color,
-  enum drm_mm_search_flags flags)
+  enum drm_mm_search_flags sflags,
+  enum drm_mm_allocator_flags aflags)
 {
struct drm_mm_node *hole_node;

hole_node = drm_mm_search_free_generic(mm, size, alignment,
-  color, flags);
+  color, sflags);
if (!hole_node)
return -ENOSPC;

-   drm_mm_insert_helper(hole_node, node, size, alignment, color);
+   drm_mm_insert_helper(hole_node, node, size, alignment, color, aflags);
return 0;
 }
 EXPORT_SYMBOL(drm_mm_insert_node_generic);
@@ -233,7 +250,8 @@ static void drm_mm_insert_helper_range(struct drm_mm_node 
*hole_node,
   struct drm_mm_node *node,
   unsigned long size, unsigned alignment,
   unsigned long color,
-  unsigned long start, unsigned long end)
+  unsigned long start,

[PATCH] drm/radeon: Use two-ended allocation by size, v2

2014-04-02 Thread Christian König

Am 02.04.2014 19:33, schrieb Lauri Kasanen:
> This decreases eviction by up to 20%, by improving the fragmentation
> quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
>
> In some cases, even the VRAM-fitting cases improved slightly (openarena, 
> urban terror).
>
> 512kb was measured as the most optimal threshold for 3d workloads common to 
> radeon.
> Other drivers may need different thresholds according to their workloads.
>
> v2: Nicer formatting
> Signed-off-by: Lauri Kasanen 

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/radeon_object.c | 13 -
>   1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 1375ff8..19bec0d 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -104,7 +104,7 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object 
> *bo)
>   
>   void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
>   {
> - u32 c = 0;
> + u32 c = 0, i;
>   
>   rbo->placement.fpfn = 0;
>   rbo->placement.lpfn = 0;
> @@ -131,6 +131,17 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
> *rbo, u32 domain)
>   rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
>   rbo->placement.num_placement = c;
>   rbo->placement.num_busy_placement = c;
> +
> + /*
> +  * Use two-ended allocation depending on the buffer size to
> +  * improve fragmentation quality.
> +  * 512kb was measured as the most optimal number.
> +  */
> + if (rbo->tbo.mem.size > 512 * 1024) {
> + for (i = 0; i < c; i++) {
> + rbo->placements[i] |= TTM_PL_FLAG_TOPDOWN;
> + }
> + }
>   }
>   
>   int radeon_bo_create(struct radeon_device *rdev,

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #50 from jeroen  ---
(In reply to comment #47)
> (In reply to comment #41)
> > (In reply to comment #40)
> > > If you set "sync playback to display" in XBMC, an inaccurate clock has no
> > > impact on dropped or skipped frames. Suppose you only have a 24Hz mode and
> > > play material which is 23.976. It would slightly speed up playback: every
> > > vblank interval a frame is rendered.
> > > If you observe skipped frames, the render thread may have been blocked too
> > > long or a vertical retrace was missed.
> >  
> > Hello FernetMenta,
> > 
> > Thanks for commenting, as you are one of the experts on this subject in 
> > XBMC.
> > 
> > "sync playback to display" is definately enabled on my system and still I am
> > seeing skipped or missed frames depending on if the clock is too slow or too
> > fast, respectively.
> > Also, the patches from Christian already proved that a clock that is closer
> > to the television display clock DOES have an influence on skipping/missing
> > frames. If the clock had no impact there wouldn't be a problem in the first
> > place.
> > 
> > The posted xrandr logs also show my television does have a 23.976 mode.
> 
> Again, a wrong speed does NOT have direct influence on dropped or skipped
> frames. If you see a some kind of relationship you have to look for the
> missing piece.

Okay, but some more information would be helpful. This way the bug report
becomes more constructive in finding the root cause. It would help me (and
perhaps others) to find the missing piece if it clear how radeon OSS and XBMC
work in respect to the vblank timing etc.

For example the XBMC wiki is not very thorough on what the
missing/skipping/dropping really means. Therefore, I already read a lot of
threads on the XBMC forum. In
http://forum.xbmc.org/showthread.php?tid=178173=1551907#pid1551907 you
state that skipping MAY be caused by refresh rate problems.

So what I got together in terms of definitions in XMBC:
- Skipping: The renderer is late
- Dropping: The decoder is late
- Missing: A vblank interrupt was missed

If the 'sync to display' option is on in XBMC the video pixels clock is master
and I guess it then uses the vblank interrupt generated by the OSS driver.
These interrupts are generated using the same clock settings that were used to
set the PLL parameters. Why are there then ever skips reported, because the
renderer cannot be late as it is the master and just puts a frame out for each
vblank interrupt? or do I misunderstand something?
Are missed vblanks reported by the OSS driver to XBMC or does XBMC keep some
shadow adminstration to see if vblank interrupts arrive at the expected time?

In my opinion there were a lot of bad comments on fgrlx, but atleast it got the
core rendering of frames done without stuttering. The XVBA part was not that
ideal though.

-- 
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/20140402/f1c0b0dc/attachment.html>

drm/nouveau/bios: fetch the vbios from PROM using only aligned 32-bit accesses

2014-04-02 Thread Dan Carpenter

Hello Martin Peres,

The patch 18acc6d84eba: "drm/nouveau/bios: fetch the vbios from PROM
using only aligned 32-bit accesses" from Mar 25, 2014, leads to the
following static checker warning:

drivers/gpu/drm/nouveau/core/subdev/bios/base.c:191 
nouveau_bios_shadow_prom()
error: potential null dereference 'bios->data'. (kmalloc returns null)

drivers/gpu/drm/nouveau/core/subdev/bios/base.c
   178  /* read entire bios image to system memory */
   179  bios->size = ((nv_rd32(bios, 0x30) >> 16) & 0xff) * 512;
   180  if (!bios->size)
   181  goto out;
   182  
   183  bios->data = kmalloc(bios->size, GFP_KERNEL);

Allocation.

   184  if (bios->data) {
   185  for (i = 0; i < bios->size; i+=4)
   186  nv_wo32(bios, i, nv_rd32(bios, 0x30 + i));
   187  }
   188  
   189  /* check the PCI record header */
   190  pcir = nv_ro16(bios, 0x0018);
   191  if (bios->data[pcir + 0] != 'P' ||

NULL deref.

   192  bios->data[pcir + 1] != 'C' ||
   193  bios->data[pcir + 2] != 'I' ||
   194  bios->data[pcir + 3] != 'R') {
   195  bios->size = 0;
   196  kfree(bios->data);
   197  }
   198  
   199  out:
   200  /* disable access to rom */
   201  nv_wr32(bios, pcireg, access);
   202  }

regards,
dan carpenter

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

--- Comment #7 from Alex Deucher  ---
Please attach your full dmesg output.  This is not related to bug 66932 as dpm
is not enabled on your asic by default.

-- 
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/20140402/7c36e437/attachment.html>

[PATCH 3/6] shm: add memfd_create() syscall

2014-04-02 Thread Konstantin Khlebnikov

On Wed, Apr 2, 2014 at 6:18 PM, David Herrmann  wrote:
> Hi
>
> On Wed, Apr 2, 2014 at 3:38 PM, Konstantin Khlebnikov  
> wrote:
>> On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann  
>> wrote:
>>> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
>>> that you can pass to mmap(). It explicitly allows sealing and
>>> avoids any connection to user-visible mount-points. Thus, it's not
>>> subject to quotas on mounted file-systems, but can be used like
>>> malloc()'ed memory, but with a file-descriptor to it.
>>>
>>> memfd_create() does not create a front-FD, but instead returns the raw
>>> shmem file, so calls like ftruncate() can be used. Also calls like fstat()
>>> will return proper information and mark the file as regular file. Sealing
>>> is explicitly supported on memfds.
>>>
>>> Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not
>>> subject to quotas and alike.
>>
>> Instead of adding new syscall we can extend existing openat() a little
>> bit more:
>>
>> openat(AT_FDSHM, "name", O_TMPFILE | O_RDWR, 0666)
>
> O_TMPFILE requires an existing directory as "name". So you have to use:
>   open("/run/", O_TMPFILE | O_RDWR, 0666)
> instead of
>   open("/run/new_file", O_TMPFILE | O_RDWR, 0666)
>
> We _really_ want to set a name for the inode, though. Otherwise,
> debug-info via /proc/pid/fd/ is useless.
>
> Furthermore, Linus requested to allow sealing only on files that
> _explicitly_ allow sealing. So v2 of this series will have
> MFD_ALLOW_SEALING as memfd_create() flag. I don't think we can do this
> with linkat() (or is that meant to be implicit for the new AT_FDSHM?).
> Last but not least, you now need a separate syscall to set the
> file-size.
>
> I could live with most of these issues, except for the name-thing. Ideas?

Hmm, why AT_FDSHM + O_TMPFILE pair cannot has different naming behavior?
Actually O_TMPFILE flag is optional here. AT_FDSHM is enough, but
O_TMPFILE allows to
move branching out of common fast-paths and hide it inside do_tmpfile.

BTW you can set some extended attribute via fsetxattr and distinguish
files in proc by its value.

OR you could add fcntl() for changing 'name' of tmpfiles. In
combination with AT_FDSHM this
would give complete solution without changing O_TMPFILE naming scheme.
But one syscall turns into three. )

--

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #96797|text/plain  |image/png
  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/20140402/009a4824/attachment.html>

[PATCH] drm: Add support for two-ended allocation, v2

On Wed, 02 Apr 2014 13:00:00 +0200
Christian K?nig  wrote:

> Nice idea, but I wouldn't put the decision where to place the buffer 
> into TTM based on it's size.
> 
> Instead please make that a proper TTM placement flag because for example 
> for VM page tables we want them to be at the end of VRAM, not because 
> they are big (which they are anyway) but because they never accessed by 
> the CPU.

I think there aren't many special cases like that, and they could
already be handled by setting the first and last pages for the bo?

- Lauri

spinlock lockup suspected on CPU error on omapdrm

2014-04-02 Thread Vikas Patil

Hi,
I am seeing following kernel backtrace on J6 with linux 3.8.13 when trying
to start IVI LM service. Before starting this I started the X11 and run
some GLES2/X11 based tests successfully.

The same binaries and my graphics driver are working fine on OMAP5 and
linux 3.4.25. Is this some known BUG in omapdrm driver? If not a bug then
how should I go for debugging it?

>From the trace what I understood is, this is case of nested spinlock and I
might be seeing this error due to this as in the trace omap_gem_op_update()
and omap_gem_set_sync_object(), both functions are trying to acquire
spin_lock(_lock).


[  719.005340] BUG: spinlock lockup suspected on CPU#0, kworker/u:2/787
[  719.011749]  lock: sync_lock+0x0/0x20, .magic: dead4ead, .owner:
kworker/u:2/787, .owner_cpu: 0
[  719.020507] [] (unwind_backtrace+0x0/0x138) from []
(do_raw_spin_lock+0x100/0x17c)
[  719.029876] [] (do_raw_spin_lock+0x100/0x17c) from
[] (omap_gem_set_sync_object+0x14/0xf4)
[  719.039978] [] (omap_gem_set_sync_object+0x14/0xf4) from
[] (FreeMemCallBackCommon+0xf4/0x24c [omapdrm_pvr])
[  719.051635] [] (FreeMemCallBackCommon+0xf4/0x24c
[omapdrm_pvr]) from [] (UnwrapExtMemoryCallBack+0x28/0x68
[omapdrm_pvr])
[  719.064544] [] (UnwrapExtMemoryCallBack+0x28/0x68
[omapdrm_pvr]) from [] (FreeResourceByPtr.part.0+0xac/0xcc
[omapdrm_pvr])
[  719.077575] [] (FreeResourceByPtr.part.0+0xac/0xcc
[omapdrm_pvr]) from [] (ResManFreeResByPtr+0x44/0x6c
[omapdrm_pvr])
[  719.090118] [] (ResManFreeResByPtr+0x44/0x6c [omapdrm_pvr])
from [] (async_unmap+0x28/0x44 [omapdrm_pvr])
[  719.101531] [] (async_unmap+0x28/0x44 [omapdrm_pvr]) from
[] (sync_op_update+0x88/0xa8)
[  719.111328] [] (sync_op_update+0x88/0xa8) from []
(omap_gem_op_update+0x14/0x24)
[  719.120544] [] (omap_gem_op_update+0x14/0x24) from
[] (PVRSRVMISR+0xc/0x60 [omapdrm_pvr])
[  719.130523] [] (PVRSRVMISR+0xc/0x60 [omapdrm_pvr]) from
[] (process_one_work+0x1c8/0x5c0)
[  719.140502] [] (process_one_work+0x1c8/0x5c0) from
[] (worker_thread+0x168/0x444)
[  719.149810] [] (worker_thread+0x168/0x444) from []
(kthread+0xa4/0xb0)
[  719.158142] [] (kthread+0xa4/0xb0) from []
(ret_from_fork+0x14/0x24)

Thanking you for your time.

Thanks & Regards,
Vikas
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/43e04a33/attachment-0001.html>

[Bug 40762] Kernel crashes when activation powersaving feature of mobility radeon x1400

2014-04-02 Thread bugzilla-dae...@bugzilla.kernel.org

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

steve_northover at hotmail.com changed:

   What|Removed |Added

 CC||steve_northover at hotmail.com

--- Comment #2 from steve_northover at hotmail.com ---
Editing a bug.  I'm very sorry for the noise.

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

[PATCH 3/6] shm: add memfd_create() syscall

2014-04-02 Thread Konstantin Khlebnikov

On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann  
wrote:
> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
> that you can pass to mmap(). It explicitly allows sealing and
> avoids any connection to user-visible mount-points. Thus, it's not
> subject to quotas on mounted file-systems, but can be used like
> malloc()'ed memory, but with a file-descriptor to it.
>
> memfd_create() does not create a front-FD, but instead returns the raw
> shmem file, so calls like ftruncate() can be used. Also calls like fstat()
> will return proper information and mark the file as regular file. Sealing
> is explicitly supported on memfds.
>
> Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not
> subject to quotas and alike.

Instead of adding new syscall we can extend existing openat() a little
bit more:

openat(AT_FDSHM, "name", O_TMPFILE | O_RDWR, 0666)

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

--- Comment #6 from benjamin.menant+debian at gmail.com ---
Erratum: my graphic card has 256 MB of RAM.

Thank you,
Benjamin.

-- 
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/20140402/3b4d38fb/attachment.html>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

--- Comment #5 from benjamin.menant+debian at gmail.com ---
Created attachment 96803
  --> https://bugs.freedesktop.org/attachment.cgi?id=96803=edit
Syslog excerpt showing a segfault (I think it?s related)

-- 
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/20140402/ae331986/attachment.html>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

--- Comment #4 from benjamin.menant+debian at gmail.com ---
Created attachment 96802
  --> https://bugs.freedesktop.org/attachment.cgi?id=96802=edit
lspci -vvnn

-- 
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/20140402/41154fed/attachment.html>

[PATCH 3/4] drm/omap: fix DMM driver (un)registration

On 02/04/14 17:14, Rob Clark wrote:
> On Wed, Apr 2, 2014 at 8:37 AM, Tomi Valkeinen  
> wrote:
>> At the moment the DMM driver is never unregistered, even if it's
>> registered in the omapdrm module's init function. This means we'll get
>> errors when reloading the omapdrm module.
>>
>> Fix this by unregistering the DMM driver properly, and also change the
>> module init to fail if DMM driver cannot be registered, simplifying the
>> unregister path as we don't need to keep the state whether we registered
>> the DMM driver or not.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_drv.c | 23 +++
>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
>> b/drivers/gpu/drm/omapdrm/omap_drv.c
>> index df3e66416a30..f16a07d1668d 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>> @@ -727,18 +727,33 @@ static struct platform_driver pdev = {
>>
>>  static int __init omap_drm_init(void)
>>  {
>> +   int r;
>> +
>> DBG("init");
>> -   if (platform_driver_register(_dmm_driver)) {
>> -   /* we can continue on without DMM.. so not fatal */
>> -   dev_err(NULL, "DMM registration failed\n");
>> +
>> +   r = platform_driver_register(_dmm_driver);
> 
> the one thing I wonder slightly about, this is making omap_dmm_driver
> register fail fatal, whereas it wasn't before..
> 
> That said, I don't remember in which case the dmm driver registration
> would fail.  I think registering the driver should succeed even (for
> example) on omap3 without dmm/tiler device.  But I guess you've
> probably tested on o3 just to make sure?  Assuming you have:

Yes. I think the driver registration could fail more or less only if
we're out of memory, or the driver is already register, or some other
similar situation.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/5b5dd953/attachment.sig>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

--- Comment #3 from benjamin.menant+debian at gmail.com ---
Created attachment 96801
  --> https://bugs.freedesktop.org/attachment.cgi?id=96801=edit
dmesg | grep radeon

-- 
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/20140402/6d16b7d9/attachment.html>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

--- Comment #2 from benjamin.menant+debian at gmail.com ---
Created attachment 96800
  --> https://bugs.freedesktop.org/attachment.cgi?id=96800=edit
glxinfo outputs

-- 
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/20140402/c8389f4e/attachment.html>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

--- Comment #1 from benjamin.menant+debian at gmail.com ---
Created attachment 96799
  --> https://bugs.freedesktop.org/attachment.cgi?id=96799=edit
Xorg log

-- 
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/20140402/728870de/attachment.html>

[PATCH] drm: Add support for two-ended allocation, v2

2014-04-02 Thread Christian König

Am 02.04.2014 16:54, schrieb Lauri Kasanen:
> On Wed, 02 Apr 2014 13:00:00 +0200
> Christian K?nig  wrote:
>
>> Nice idea, but I wouldn't put the decision where to place the buffer
>> into TTM based on it's size.
>>
>> Instead please make that a proper TTM placement flag because for example
>> for VM page tables we want them to be at the end of VRAM, not because
>> they are big (which they are anyway) but because they never accessed by
>> the CPU.
> I think there aren't many special cases like that, and they could
> already be handled by setting the first and last pages for the bo?

Nope, that would require the driver to find a certain position for the 
buffer by itself.

The placement flag should just move allocation from preferring the start 
of the address space to preferring the end of it.

What I wanted to note is that this way the driver could use this feature 
in a much more flexible way, not only to change placement of buffers 
based on the size, but also on other criteria as well (and yes I have 
couple of use cases for this in mind).

Additional to that you could also separate the patch into adding this 
functionality and enabling it for radeon, which in the end will allow 
people to easier bisect it in the case something is wrong.

Apart from that the patch is a really nice piece of work,
Christian.

>
> - Lauri

[Bug 76957] New: Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

Priority: medium
Bug ID: 76957
Assignee: dri-devel at lists.freedesktop.org
Summary: Pixel artifacts and corruption plus system freeze and
instabilities with the free radeon driver (AMD HD
6570)
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: benjamin.menant+debian at gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: XOrg CVS
Component: DRM/Radeon
Product: DRI

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

Hello,

Each time I tried to use the free radeon drivers with my desktop computer, I
got those corrupted pixels when X starts. The issue effects increase as the
session time grows: more and more artifacts, more and more character
alterations (for instance, Thunderbird is displaying blocks instead of
characters), more and more instabilities (programs ends up by a segmentation
fault, and could eventually lead to a system freeze).

Otherwise, Gnome Shell starts without error. `glxgears` works and returns good
FPS. And the virtual consoles remain safe & clean; switching between them and X
has no effect.

The system was stable, without screen corruption when I used the AMD?s FGLRX
drivers.

How could I fix this issue? Any idea?
This ticket seems quite similar, should I try the proposed patch?
<https://bugs.freedesktop.org/show_bug.cgi?id=66932>

Chipset: AMD Radeon HD 6570 (Turks family) with 512MB dedicated RAM (AFAIR).
CPU: Intel DualCore E6300 with 4GB RAM.
Kernel: Linux 3.13-1-amd64.
And I use the defaut Xorg configuration (i.e. no configuration files).

--
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/20140402/5b89a8a6/attachment-0001.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

--- Comment #18 from nucrap at hotmail.com ---
Hi, I can confirm this regression on Kernel 3.14 using the the FOSS driver and
r7 260x of course.

I experience artifacts, constanst hangs and - in result of the hangs,
"colorfully" filled screens rendering the system unusable.

Can I help somehow? I'm not a developer, just to warn you...

-- 
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/20140402/b6b5c3cf/attachment-0001.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #48 from Garrett  ---
Created attachment 96792
  --> https://bugs.freedesktop.org/attachment.cgi?id=96792=edit
logs working and not

This patch appears to have broken my 24P playback which has been fine until
now.  My set is a Sony KDL 40NX711 NTSC set, A4-3400 - HDMI to set for
vid/audio stereo out speakers/no avr.  Using Openelec- gotham nightlies (this
patch is now comitted to OE-nightlies):
Playing 29.97 plays fine enough (a few skips- why I am testing this patch),
23.976 playback breaks the TV display- it starts to buzz then says "no signal",
I press stop and the menu/screen resumes at ~30P like normal. I am attaching
dmesg/xorg logs  drm.debug=0xe both working w/o patch and broken w/patch.  let
me know if you need more.

-- 
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/20140402/577583ee/attachment.html>

[PATCH 3/6] shm: add memfd_create() syscall

2014-04-02 Thread David Herrmann

Hi

On Wed, Apr 2, 2014 at 3:38 PM, Konstantin Khlebnikov  
wrote:
> On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann  
> wrote:
>> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
>> that you can pass to mmap(). It explicitly allows sealing and
>> avoids any connection to user-visible mount-points. Thus, it's not
>> subject to quotas on mounted file-systems, but can be used like
>> malloc()'ed memory, but with a file-descriptor to it.
>>
>> memfd_create() does not create a front-FD, but instead returns the raw
>> shmem file, so calls like ftruncate() can be used. Also calls like fstat()
>> will return proper information and mark the file as regular file. Sealing
>> is explicitly supported on memfds.
>>
>> Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not
>> subject to quotas and alike.
>
> Instead of adding new syscall we can extend existing openat() a little
> bit more:
>
> openat(AT_FDSHM, "name", O_TMPFILE | O_RDWR, 0666)

O_TMPFILE requires an existing directory as "name". So you have to use:
  open("/run/", O_TMPFILE | O_RDWR, 0666)
instead of
  open("/run/new_file", O_TMPFILE | O_RDWR, 0666)

We _really_ want to set a name for the inode, though. Otherwise,
debug-info via /proc/pid/fd/ is useless.

Furthermore, Linus requested to allow sealing only on files that
_explicitly_ allow sealing. So v2 of this series will have
MFD_ALLOW_SEALING as memfd_create() flag. I don't think we can do this
with linkat() (or is that meant to be implicit for the new AT_FDSHM?).
Last but not least, you now need a separate syscall to set the
file-size.

I could live with most of these issues, except for the name-thing. Ideas?

Thanks
David

[PATCH v2 1/7] drm/exynos: add super device support

On 04/01/2014 02:37 PM, Inki Dae wrote:
> This patch adds super device support to bind sub drivers
> using device tree.
> 
> For this, you should add a super device node to each machine dt files
> like belows,
> 
> In case of using MIPI-DSI,
>   display-subsystem {
>   compatible = "samsung,exynos-display-subsystem";
>   ports = <>, <>;
>   };
> 
> In case of using DisplayPort,
>   display-subsystem {
>   compatible = "samsung,exynos-display-subsystem";
>   ports = <>, <>;
>   };
> 
> In case of using Parallel panel,
>   display-subsystem {
>   compatible = "samsung,exynos-display-subsystem";
>   ports = <>;
>   };
> 
> And if you don't add connector device node to ports property,
> default parallel panel driver, exynos_drm_dpi module, will be used.
> 
> ports property can have the following device nodes,
>   fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI
> 
> With this patch, we can resolve the probing order issue without
> some global lists. So this patch also removes the unnecessary lists and
> stuff related to these lists.
> 

(...)

> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 40fd6cc..7ebfe15 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -19,10 +19,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "exynos_drm_drv.h"
> @@ -144,12 +146,14 @@ static inline struct fimd_driver_data 
> *drm_fimd_get_driver_data(
>  }
>  
>  static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
> - struct drm_device *drm_dev, int pipe)
> + struct drm_device *drm_dev)
>  {
>   struct fimd_context *ctx = mgr->ctx;
> + struct exynos_drm_private *priv;
> + priv = drm_dev->dev_private;
>  
> - ctx->drm_dev = drm_dev;
> - ctx->pipe = pipe;
> + mgr->drm_dev = ctx->drm_dev = drm_dev;
> + mgr->pipe = ctx->pipe = priv->pipe++;
>  
>   /*
>* enable drm irq mode.
> @@ -803,8 +807,6 @@ static void fimd_dpms(struct exynos_drm_manager *mgr, int 
> mode)
>  }
>  
>  static struct exynos_drm_manager_ops fimd_manager_ops = {
> - .initialize = fimd_mgr_initialize,
> - .remove = fimd_mgr_remove,
>   .dpms = fimd_dpms,
>   .mode_fixup = fimd_mode_fixup,
>   .mode_set = fimd_mode_set,
> @@ -849,9 +851,10 @@ out:
>   return IRQ_HANDLED;
>  }
>  
> -static int fimd_probe(struct platform_device *pdev)
> +static int fimd_bind(struct device *dev, struct device *master, void *data)
>  {
> - struct device *dev = >dev;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct drm_device *drm_dev = data;
>   struct fimd_context *ctx;
>   struct resource *res;
>   int win;
> @@ -910,11 +913,16 @@ static int fimd_probe(struct platform_device *pdev)
>   platform_set_drvdata(pdev, _manager);
>  
>   fimd_manager.ctx = ctx;
> - exynos_drm_manager_register(_manager);
> + fimd_mgr_initialize(_manager, drm_dev);
>  
> - exynos_dpi_probe(ctx->dev);
> + exynos_drm_crtc_create(_manager);
>  
> - pm_runtime_enable(dev);
> + /*
> +  * It should be called after exynos_drm_crtc_create call because
> +  * exynos_dpi_probe call will try to find same lcd type
> +  * of manager to setup possible_crtcs.
> +  */
> + exynos_dpi_probe(drm_dev, dev);
>  
>   for (win = 0; win < WINDOWS_NR; win++)
>   fimd_clear_win(ctx, win);
> @@ -922,18 +930,56 @@ static int fimd_probe(struct platform_device *pdev)
>   return 0;
>  }
>  
> -static int fimd_remove(struct platform_device *pdev)
> +static void fimd_unbind(struct device *dev, struct device *master,
> + void *data)
>  {
> - struct exynos_drm_manager *mgr = platform_get_drvdata(pdev);
> + struct exynos_drm_manager *mgr = dev_get_drvdata(dev);
> + struct drm_crtc *crtc = mgr->crtc;
> +
> + fimd_dpms(mgr, DRM_MODE_DPMS_OFF);
>  
> - exynos_dpi_remove(>dev);
> + exynos_dpi_remove(mgr->drm_dev, dev);
>  
> - exynos_drm_manager_unregister(_manager);
> + fimd_mgr_remove(mgr);
>  
> - fimd_dpms(mgr, DRM_MODE_DPMS_OFF);
> + crtc->funcs->destroy(crtc);
> +}
> +
> +static const struct component_ops fimd_component_ops = {
> + .bind   = fimd_bind,
> + .unbind = fimd_unbind,
> +};
>  
> +static int fimd_probe(struct platform_device *pdev)
> +{
> + struct device_node *dn;
> +
> + /* Check if fimd node has port node. */
> + dn = exynos_dpi_of_find_panel_node(>dev);
> + if (dn) {
> + struct drm_panel *panel;
> +
> + /*
> +  * Do not bind if there is the port node but a drm_panel
> +  * isn't added to panel_list yet.
> +  * In this case, fimd_probe will

[PATCH 4/4] drm/omap: fix race issue when unloading omapdrm

At module unload, omap_fbdev_free() gets called which releases the
framebuffers. However, the framebuffers are still used by crtcs, and
will be released only later at vsync. The driver doesn't wait for this,
and goes on to release the rest of the resources, which often
causes a crash.

This patchs adds a omap_crtc_flush() function which waits until the crtc
has finished with its apply queue and page flips.

The function utilizes a simple polling while-loop, as the performance is
not an issue here.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 19 +++
 drivers/gpu/drm/omapdrm/omap_drv.c  |  6 ++
 drivers/gpu/drm/omapdrm/omap_drv.h  |  1 +
 3 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index e7b643c178a6..4f624c59a660 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -620,6 +620,25 @@ static void omap_crtc_post_apply(struct omap_drm_apply 
*apply)
/* nothing needed for post-apply */
 }

+void omap_crtc_flush(struct drm_crtc *crtc)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   int loops = 0;
+
+   while (!list_empty(_crtc->pending_applies) ||
+   !list_empty(_crtc->queued_applies) ||
+   omap_crtc->event || omap_crtc->old_fb) {
+
+   if (++loops > 10) {
+   dev_err(crtc->dev->dev,
+   "omap_crtc_flush() timeout\n");
+   break;
+   }
+
+   schedule_timeout_uninterruptible(msecs_to_jiffies(20));
+   }
+}
+
 static const char *channel_names[] = {
[OMAP_DSS_CHANNEL_LCD] = "lcd",
[OMAP_DSS_CHANNEL_DIGIT] = "tv",
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index f16a07d1668d..c8270e4b26f3 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -513,12 +513,18 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)
 static int dev_unload(struct drm_device *dev)
 {
struct omap_drm_private *priv = dev->dev_private;
+   int i;

DBG("unload: dev=%p", dev);

drm_kms_helper_poll_fini(dev);

omap_fbdev_free(dev);
+
+   /* flush crtcs so the fbs get released */
+   for (i = 0; i < priv->num_crtcs; i++)
+   omap_crtc_flush(priv->crtcs[i]);
+
omap_modeset_free(dev);
omap_gem_deinit(dev);

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 428b2981fd68..284b80fc3c54 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -163,6 +163,7 @@ void omap_crtc_pre_init(void);
 void omap_crtc_pre_uninit(void);
 struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id);
+void omap_crtc_flush(struct drm_crtc *crtc);

 struct drm_plane *omap_plane_init(struct drm_device *dev,
int plane_id, bool private_plane);
-- 
1.8.3.2

[PATCH 3/4] drm/omap: fix DMM driver (un)registration

At the moment the DMM driver is never unregistered, even if it's
registered in the omapdrm module's init function. This means we'll get
errors when reloading the omapdrm module.

Fix this by unregistering the DMM driver properly, and also change the
module init to fail if DMM driver cannot be registered, simplifying the
unregister path as we don't need to keep the state whether we registered
the DMM driver or not.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index df3e66416a30..f16a07d1668d 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -727,18 +727,33 @@ static struct platform_driver pdev = {

 static int __init omap_drm_init(void)
 {
+   int r;
+
DBG("init");
-   if (platform_driver_register(_dmm_driver)) {
-   /* we can continue on without DMM.. so not fatal */
-   dev_err(NULL, "DMM registration failed\n");
+
+   r = platform_driver_register(_dmm_driver);
+   if (r) {
+   pr_err("DMM driver registration failed\n");
+   return r;
}
-   return platform_driver_register();
+
+   r = platform_driver_register();
+   if (r) {
+   pr_err("omapdrm driver registration failed\n");
+   platform_driver_unregister(_dmm_driver);
+   return r;
+   }
+
+   return 0;
 }

 static void __exit omap_drm_fini(void)
 {
DBG("fini");
+
platform_driver_unregister();
+
+   platform_driver_unregister(_dmm_driver);
 }

 /* need late_initcall() so we load after dss_driver's are loaded */
-- 
1.8.3.2

[PATCH 2/4] drm/omap: fix uninit order in pdev_remove()

When unloading omapdrm driver, the omapdrm platform device is
uninitialized last, after the displays have been disconnected omap_crtc
callbacks have been removed. As the omapdrm pdev uninitialization needs
the features uninitialized in earlier steps, a crash is guaranteed.

This patch fixes the uninitialize order so that the omapdrm pdev is
removed first.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index bf39fcc49e0f..df3e66416a30 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -696,10 +696,11 @@ static int pdev_remove(struct platform_device *device)
 {
DBG("");

+   drm_put_dev(platform_get_drvdata(device));
+
omap_disconnect_dssdevs();
omap_crtc_pre_uninit();

-   drm_put_dev(platform_get_drvdata(device));
return 0;
 }

-- 
1.8.3.2

[PATCH 1/4] drm/omap: fix output enable/disable sequence

At the moment it's quite easy to get the following errors when the HDMI
output is enabled or disabled:

[drm:omap_crtc_error_irq] *ERROR* tv: errors: 8000

The reason for the errors is that the omapdrm driver doesn't properly
handle the sync-lost irqs that happen when enabling the DIGIT crtc,
which is used for HDMI and analog TV. The driver does disable the
sync-lost irq properly, but it fails to wait until the output has been
fully enabled (i.e. the first vsync), so the sync-lost errors are still
seen occasionally.

This patch makes the omapdrm act the same way as the omapfb does:

- When enabling a display, we'll wait for the first vsync.
- When disabling a display, we'll wait for framedone if available, or
  odd and even vsyncs.

These changes make sure the output is fully enabled or disabled at the
end of the function.

Signed-off-by: Tomi Valkeinen 
Reported-by: Sanjay Singh Rawat 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 46 ++---
 1 file changed, 27 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 4313bb0a49a6..e7b643c178a6 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -527,38 +527,46 @@ static void set_enabled(struct drm_crtc *crtc, bool 
enable)
struct drm_device *dev = crtc->dev;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
enum omap_channel channel = omap_crtc->channel;
-   struct omap_irq_wait *wait = NULL;
+   struct omap_irq_wait *wait;
+   u32 framedone_irq, vsync_irq;
+   int ret;

if (dispc_mgr_is_enabled(channel) == enable)
return;

-   /* ignore sync-lost irqs during enable/disable */
+   /*
+* Digit output produces some sync lost interrupts during the first
+* frame when enabling, so we need to ignore those.
+*/
omap_irq_unregister(crtc->dev, _crtc->error_irq);

-   if (dispc_mgr_get_framedone_irq(channel)) {
-   if (!enable) {
-   wait = omap_irq_wait_init(dev,
-   dispc_mgr_get_framedone_irq(channel), 
1);
-   }
+   framedone_irq = dispc_mgr_get_framedone_irq(channel);
+   vsync_irq = dispc_mgr_get_vsync_irq(channel);
+
+   if (enable) {
+   wait = omap_irq_wait_init(dev, vsync_irq, 1);
} else {
/*
-* When we disable digit output, we need to wait until fields
-* are done.  Otherwise the DSS is still working, and turning
-* off the clocks prevents DSS from going to OFF mode. And when
-* enabling, we need to wait for the extra sync losts
+* When we disable the digit output, we need to wait for
+* FRAMEDONE to know that DISPC has finished with the output.
+*
+* OMAP2/3 does not have FRAMEDONE irq for digit output, and in
+* that case we need to use vsync interrupt, and wait for both
+* even and odd frames.
 */
-   wait = omap_irq_wait_init(dev,
-   dispc_mgr_get_vsync_irq(channel), 2);
+
+   if (framedone_irq)
+   wait = omap_irq_wait_init(dev, framedone_irq, 1);
+   else
+   wait = omap_irq_wait_init(dev, vsync_irq, 2);
}

dispc_mgr_enable(channel, enable);

-   if (wait) {
-   int ret = omap_irq_wait(dev, wait, msecs_to_jiffies(100));
-   if (ret) {
-   dev_err(dev->dev, "%s: timeout waiting for %s\n",
-   omap_crtc->name, enable ? "enable" : 
"disable");
-   }
+   ret = omap_irq_wait(dev, wait, msecs_to_jiffies(100));
+   if (ret) {
+   dev_err(dev->dev, "%s: timeout waiting for %s\n",
+   omap_crtc->name, enable ? "enable" : "disable");
}

omap_irq_register(crtc->dev, _crtc->error_irq);
-- 
1.8.3.2

Synchronization between a crtc mode_set and page_flip?

2014-04-02 Thread Archit Taneja

Hi,

I was trying to figure out how we are supposed to manage synchronization 
between a mode_set and a page_flip called on a crtc.

Say, if a mode_set is immediately followed by a page_flip. The driver 
can't process the page_flip straight away since the hardware is still 
completing the mode_set.

What is the driver supposed to do? Should it return -EBUSY? Or should it 
somehow queue the page_flip task internally?

A lot of libdrm applications seem to call mode_set, and call a page_flip 
soon after it. They tend to bail out if page_flip returns an error, they 
don't try to do another page_flip if it fails the first time. Is this 
okay behaviour?

Thanks,
Archit

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #47 from Rainer Hochecker  ---
(In reply to comment #41)
> (In reply to comment #40)
> > If you set "sync playback to display" in XBMC, an inaccurate clock has no
> > impact on dropped or skipped frames. Suppose you only have a 24Hz mode and
> > play material which is 23.976. It would slightly speed up playback: every
> > vblank interval a frame is rendered.
> > If you observe skipped frames, the render thread may have been blocked too
> > long or a vertical retrace was missed.
>  
> Hello FernetMenta,
> 
> Thanks for commenting, as you are one of the experts on this subject in XBMC.
> 
> "sync playback to display" is definately enabled on my system and still I am
> seeing skipped or missed frames depending on if the clock is too slow or too
> fast, respectively.
> Also, the patches from Christian already proved that a clock that is closer
> to the television display clock DOES have an influence on skipping/missing
> frames. If the clock had no impact there wouldn't be a problem in the first
> place.
> 
> The posted xrandr logs also show my television does have a 23.976 mode.

Again, a wrong speed does NOT have direct influence on dropped or skipped
frames. If you see a some kind of relationship you have to look for the missing
piece.

-- 
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/20140402/fbef1c7b/attachment.html>

[Bug 76954] New: Unigine Tropics has rendering issues all over the place with LLVM on Cayman

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

  Priority: medium
Bug ID: 76954
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Unigine Tropics has rendering issues all over the
place with LLVM on Cayman
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v10lator at myway.de
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

This video was made with LLVM + SB: https://vimeo.com/90754450

With LLVM and noSB it doesn't render anything at all (the scene is just black).
Without LLVM everything seems to be fine. HyperZ doesn't make a difference.

If you need any more information feel free to ask.

-- 
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/20140402/4cb39089/attachment.html>

[Bug 67110] [radeonsi] Anomaly Warzone Earth games are segfaulting

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

Laurent carlier  changed:

   What|Removed |Added

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

--- Comment #3 from Laurent carlier  ---
I cannot reproduce the segfault anymore with llvm-3.5svn and mesa-git trunk

-- 
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/20140402/0b571cb4/attachment.html>

[PATCH 2/2] drm/radeon: Use two-ended allocation by size

2014-04-02 Thread Alex Deucher

On Wed, Apr 2, 2014 at 1:04 PM, Lauri Kasanen  wrote:
> This decreases eviction by up to 20%, by improving the fragmentation
> quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
>
> In some cases, even the VRAM-fitting cases improved slightly (openarena, 
> urban terror).
>
> 512kb was measured as the most optimal threshold for 3d workloads common to 
> radeon.
> Other drivers may need different thresholds according to their workloads.
>
> Signed-off-by: Lauri Kasanen 
> ---
>  drivers/gpu/drm/radeon/radeon_object.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 1375ff8..6251456 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -104,7 +104,7 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object 
> *bo)
>
>  void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
>  {
> -   u32 c = 0;
> +   u32 c = 0, i;
>
> rbo->placement.fpfn = 0;
> rbo->placement.lpfn = 0;
> @@ -131,6 +131,15 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
> *rbo, u32 domain)
> rbo->placements[c++] = TTM_PL_MASK_CACHING | 
> TTM_PL_FLAG_SYSTEM;
> rbo->placement.num_placement = c;
> rbo->placement.num_busy_placement = c;
> +
> +   /*
> +* Use two-ended allocation depending on the buffer size to
> +* improve fragmentation quality.
> +* 512kb was measured as the most optimal number.
> +*/
> +   if (rbo->tbo.mem.size > 512 * 1024) for (i = 0; i < c; i++) {
> +   rbo->placements[i] |= TTM_PL_FLAG_TOPDOWN;
> +   }

Can you clean up the formatting of this chunk of code?  It's a bit
weird to read.

Alex

>  }
>
>  int radeon_bo_create(struct radeon_device *rdev,
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Add support for two-ended allocation, v2

2014-04-02 Thread Christian König

Nice idea, but I wouldn't put the decision where to place the buffer 
into TTM based on it's size.

Instead please make that a proper TTM placement flag because for example 
for VM page tables we want them to be at the end of VRAM, not because 
they are big (which they are anyway) but because they never accessed by 
the CPU.

Christian.

Am 02.04.2014 11:08, schrieb Lauri Kasanen:
> Clients like i915 need to segregate cache domains within the GTT which
> can lead to small amounts of fragmentation. By allocating the uncached
> buffers from the bottom and the cacheable buffers from the top, we can
> reduce the amount of wasted space and also optimize allocation of the
> mappable portion of the GTT to only those buffers that require CPU
> access through the GTT.
>
> For other drivers, allocating small bos from one end and large ones
> from the other helps improve the quality of fragmentation.
>
> Only Radeon has behavioral changes in this patch, as I have no Intel hw.
>
> Based on drm_mm work by Chris Wilson.
>
> --
>
> Radeon uses a 512kb threshold.
>
> This decreases eviction by up to 20%, by improving the fragmentation
> quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
>
> In some cases, even the VRAM-fitting cases improved slightly (openarena, 
> urban terror).
>
> 512kb was measured as the most optimal threshold for 3d workloads common to 
> radeon.
> Other drivers may need different thresholds according to their workloads.
>
> v2: Updated kerneldoc in more places
>
> Cc: Chris Wilson 
> Cc: Ben Widawsky 
> Signed-off-by: Lauri Kasanen 
> ---
>   drivers/gpu/drm/ast/ast_ttm.c |  3 +-
>   drivers/gpu/drm/bochs/bochs_mm.c  |  3 +-
>   drivers/gpu/drm/cirrus/cirrus_ttm.c   |  3 +-
>   drivers/gpu/drm/drm_mm.c  | 66 
> ++-
>   drivers/gpu/drm/i915/i915_gem.c   |  3 +-
>   drivers/gpu/drm/i915/i915_gem_gtt.c   |  3 +-
>   drivers/gpu/drm/mgag200/mgag200_ttm.c |  3 +-
>   drivers/gpu/drm/nouveau/nouveau_ttm.c |  2 +-
>   drivers/gpu/drm/qxl/qxl_ttm.c |  2 +-
>   drivers/gpu/drm/radeon/radeon_ttm.c   |  3 +-
>   drivers/gpu/drm/ttm/ttm_bo.c  |  4 ++-
>   drivers/gpu/drm/ttm/ttm_bo_manager.c  | 16 +++--
>   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |  2 +-
>   include/drm/drm_mm.h  | 32 ++---
>   include/drm/ttm/ttm_bo_driver.h   |  9 -
>   15 files changed, 118 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
> index b824622..61f9e39 100644
> --- a/drivers/gpu/drm/ast/ast_ttm.c
> +++ b/drivers/gpu/drm/ast/ast_ttm.c
> @@ -262,7 +262,8 @@ int ast_mm_init(struct ast_private *ast)
>_bo_driver,
>dev->anon_inode->i_mapping,
>DRM_FILE_PAGE_OFFSET,
> -  true);
> +  true,
> +  0);
>   if (ret) {
>   DRM_ERROR("Error initialising bo driver; %d\n", ret);
>   return ret;
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c 
> b/drivers/gpu/drm/bochs/bochs_mm.c
> index f488be5..9dfd24a 100644
> --- a/drivers/gpu/drm/bochs/bochs_mm.c
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> @@ -228,7 +228,8 @@ int bochs_mm_init(struct bochs_device *bochs)
>_bo_driver,
>bochs->dev->anon_inode->i_mapping,
>DRM_FILE_PAGE_OFFSET,
> -  true);
> +  true,
> +  0);
>   if (ret) {
>   DRM_ERROR("Error initialising bo driver; %d\n", ret);
>   return ret;
> diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
> b/drivers/gpu/drm/cirrus/cirrus_ttm.c
> index 92e6b77..74e8e21 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
> @@ -262,7 +262,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
>_bo_driver,
>dev->anon_inode->i_mapping,
>DRM_FILE_PAGE_OFFSET,
> -  true);
> +  true,
> +  0);
>   if (ret) {
>   DRM_ERROR("Error initialising bo driver; %d\n", ret);
>   return ret;
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index a2d45b74..8f64be4 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -82,6 +82,10 @@
>* this to implement guard pages between incompatible caching domains in the
>* graphics TT.
>*
> + * Two behaviors are supported for searching and allocating: bottom-up and 
> top-down.
> + * The default is bottom-up. Top-down allocation can be used if the memory 
> area
> + * has different restrictions, or just to reduce fragmentation.
> + *

[PATCH v2] drm: make mode_valid callback optional

Many drm connectors do not need mode validation.
The patch makes this callback optional and removes dumb implementations.

Signed-off-by: Andrzej Hajda 
---
v2:
- added comment and updated DocBook
---
 Documentation/DocBook/drm.tmpl | 6 +++---
 drivers/gpu/drm/ast/ast_mode.c | 7 ---
 drivers/gpu/drm/bridge/ptn3460.c   | 7 ---
 drivers/gpu/drm/cirrus/cirrus_mode.c   | 8 
 drivers/gpu/drm/drm_crtc_helper.c  | 2 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c| 7 ---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c| 7 ---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 7 ---
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  | 7 ---
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c   | 7 ---
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  | 7 ---
 drivers/staging/imx-drm/imx-hdmi.c | 8 
 drivers/staging/imx-drm/imx-ldb.c  | 7 ---
 drivers/staging/imx-drm/parallel-display.c | 7 ---
 include/drm/drm_crtc_helper.h  | 2 +-
 15 files changed, 5 insertions(+), 91 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 702c4474..92b4fa3 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1903,8 +1903,8 @@ void intel_crt_init(struct drm_device *dev)
   
 The function filters out modes larger than
 max_width and 
max_height
-if specified. It then calls the connector
-mode_valid helper operation for  each 
mode in
+if specified. It then calls the optional connector
+mode_valid helper operation for each mode 
in
 the probed list to check whether the mode is valid for the 
connector.
   
 
@@ -2265,7 +2265,7 @@ void intel_crt_init(struct drm_device *dev)
   
 Verify whether a mode is valid for the connector. Return MODE_OK 
for
 supported modes and one of the enum drm_mode_status values (MODE_*)
-for unsupported modes. This operation is mandatory.
+for unsupported modes. This operation is optional.
   
   
 As the mode rejection reason is currently not used beside for
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index a4afdc8..e599d64 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -743,12 +743,6 @@ static int ast_get_modes(struct drm_connector *connector)
return 0;
 }

-static int ast_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
-   return MODE_OK;
-}
-
 static void ast_connector_destroy(struct drm_connector *connector)
 {
struct ast_connector *ast_connector = to_ast_connector(connector);
@@ -765,7 +759,6 @@ ast_connector_detect(struct drm_connector *connector, bool 
force)
 }

 static const struct drm_connector_helper_funcs ast_connector_helper_funcs = {
-   .mode_valid = ast_mode_valid,
.get_modes = ast_get_modes,
.best_encoder = ast_best_single_encoder,
 };
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index a9e5c1a..3ff2813 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -225,12 +225,6 @@ out:
return num_modes;
 }

-static int ptn3460_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
-{
-   return MODE_OK;
-}
-
 struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
 {
struct ptn3460_bridge *ptn_bridge;
@@ -242,7 +236,6 @@ struct drm_encoder *ptn3460_best_encoder(struct 
drm_connector *connector)

 struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
.get_modes = ptn3460_get_modes,
-   .mode_valid = ptn3460_mode_valid,
.best_encoder = ptn3460_best_encoder,
 };

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 2d64aea..057c7d1 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -502,13 +502,6 @@ static int cirrus_vga_get_modes(struct drm_connector 
*connector)
return count;
 }

-static int cirrus_vga_mode_valid(struct drm_connector *connector,
-struct drm_display_mode *mode)
-{
-   /* Any mode we've added is valid */
-   return MODE_OK;
-}
-
 static struct drm_encoder *cirrus_connector_best_encoder(struct drm_connector
  *connector)
 {
@@ -543,7 +536,6 @@ static void cirrus_connector_destroy(struct drm_connector 
*connector)

 struct drm_connector_helper_funcs cirrus_vga_connector_helper_funcs = {
.get_modes = cirrus_vga_get_modes,
-   .mode_valid = cirrus_vga_mode_valid,
.best_encoder = cirrus_connector_best_encoder,
 };

diff --git a/drivers/gpu/drm/drm_crtc_helper.c

[PATCH] drm: Add support for two-ended allocation, v2

Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion of the GTT to only those buffers that require CPU
access through the GTT.

For other drivers, allocating small bos from one end and large ones
from the other helps improve the quality of fragmentation.

Only Radeon has behavioral changes in this patch, as I have no Intel hw.

Based on drm_mm work by Chris Wilson.

--

Radeon uses a 512kb threshold.

This decreases eviction by up to 20%, by improving the fragmentation
quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).

In some cases, even the VRAM-fitting cases improved slightly (openarena, urban 
terror).

512kb was measured as the most optimal threshold for 3d workloads common to 
radeon.
Other drivers may need different thresholds according to their workloads.

v2: Updated kerneldoc in more places

Cc: Chris Wilson 
Cc: Ben Widawsky 
Signed-off-by: Lauri Kasanen 
---
 drivers/gpu/drm/ast/ast_ttm.c |  3 +-
 drivers/gpu/drm/bochs/bochs_mm.c  |  3 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c   |  3 +-
 drivers/gpu/drm/drm_mm.c  | 66 ++-
 drivers/gpu/drm/i915/i915_gem.c   |  3 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  3 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c |  3 +-
 drivers/gpu/drm/nouveau/nouveau_ttm.c |  2 +-
 drivers/gpu/drm/qxl/qxl_ttm.c |  2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c   |  3 +-
 drivers/gpu/drm/ttm/ttm_bo.c  |  4 ++-
 drivers/gpu/drm/ttm/ttm_bo_manager.c  | 16 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |  2 +-
 include/drm/drm_mm.h  | 32 ++---
 include/drm/ttm/ttm_bo_driver.h   |  9 -
 15 files changed, 118 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index b824622..61f9e39 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -262,7 +262,8 @@ int ast_mm_init(struct ast_private *ast)
 _bo_driver,
 dev->anon_inode->i_mapping,
 DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index f488be5..9dfd24a 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -228,7 +228,8 @@ int bochs_mm_init(struct bochs_device *bochs)
 _bo_driver,
 bochs->dev->anon_inode->i_mapping,
 DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 92e6b77..74e8e21 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -262,7 +262,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
 _bo_driver,
 dev->anon_inode->i_mapping,
 DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index a2d45b74..8f64be4 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -82,6 +82,10 @@
  * this to implement guard pages between incompatible caching domains in the
  * graphics TT.
  *
+ * Two behaviors are supported for searching and allocating: bottom-up and 
top-down.
+ * The default is bottom-up. Top-down allocation can be used if the memory area
+ * has different restrictions, or just to reduce fragmentation.
+ *
  * Finally iteration helpers to walk all nodes and all holes are provided as 
are
  * some basic allocator dumpers for debugging.
  */
@@ -102,7 +106,8 @@ static struct drm_mm_node 
*drm_mm_search_free_in_range_generic(const struct drm_
 static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
 struct drm_mm_node *node,
 unsigned long size, unsigned alignment,
-unsigned long color)
+unsigned long color,
+

[PATCH] drm: make mode_valid callback optional

On Wed, Apr 02, 2014 at 10:34:04AM +0200, Andrzej Hajda wrote:
> Many drm connectors do not need mode validation.
> The patch makes this callback optional and removes dumb implementations.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> Hi,
> 
> This patch is based on the latest drm-next.
> I have removed all dumb implementations except for qxl_display.c,
> which is not entirely dumb - it contains log and TODO comments.
> 
> Changes seems to be quite obvious so I have put everything into single patch.

Can you please also update the drm DocBook and add a small comment stating
that this callback is now optional? Looks good to me otherwise.

Thanks, Daniel

> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/ast/ast_mode.c | 7 ---
>  drivers/gpu/drm/bridge/ptn3460.c   | 7 ---
>  drivers/gpu/drm/cirrus/cirrus_mode.c   | 8 
>  drivers/gpu/drm/drm_crtc_helper.c  | 2 +-
>  drivers/gpu/drm/exynos/exynos_dp_core.c| 7 ---
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c| 7 ---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 7 ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  | 7 ---
>  drivers/gpu/drm/rcar-du/rcar_du_vgacon.c   | 7 ---
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c  | 7 ---
>  drivers/staging/imx-drm/imx-hdmi.c | 8 
>  drivers/staging/imx-drm/imx-ldb.c  | 7 ---
>  drivers/staging/imx-drm/parallel-display.c | 7 ---
>  13 files changed, 1 insertion(+), 87 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index a4afdc8..e599d64 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -743,12 +743,6 @@ static int ast_get_modes(struct drm_connector *connector)
>   return 0;
>  }
>  
> -static int ast_mode_valid(struct drm_connector *connector,
> -   struct drm_display_mode *mode)
> -{
> - return MODE_OK;
> -}
> -
>  static void ast_connector_destroy(struct drm_connector *connector)
>  {
>   struct ast_connector *ast_connector = to_ast_connector(connector);
> @@ -765,7 +759,6 @@ ast_connector_detect(struct drm_connector *connector, 
> bool force)
>  }
>  
>  static const struct drm_connector_helper_funcs ast_connector_helper_funcs = {
> - .mode_valid = ast_mode_valid,
>   .get_modes = ast_get_modes,
>   .best_encoder = ast_best_single_encoder,
>  };
> diff --git a/drivers/gpu/drm/bridge/ptn3460.c 
> b/drivers/gpu/drm/bridge/ptn3460.c
> index a9e5c1a..3ff2813 100644
> --- a/drivers/gpu/drm/bridge/ptn3460.c
> +++ b/drivers/gpu/drm/bridge/ptn3460.c
> @@ -225,12 +225,6 @@ out:
>   return num_modes;
>  }
>  
> -static int ptn3460_mode_valid(struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - return MODE_OK;
> -}
> -
>  struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
>  {
>   struct ptn3460_bridge *ptn_bridge;
> @@ -242,7 +236,6 @@ struct drm_encoder *ptn3460_best_encoder(struct 
> drm_connector *connector)
>  
>  struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
>   .get_modes = ptn3460_get_modes,
> - .mode_valid = ptn3460_mode_valid,
>   .best_encoder = ptn3460_best_encoder,
>  };
>  
> diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
> b/drivers/gpu/drm/cirrus/cirrus_mode.c
> index 2d64aea..057c7d1 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
> @@ -502,13 +502,6 @@ static int cirrus_vga_get_modes(struct drm_connector 
> *connector)
>   return count;
>  }
>  
> -static int cirrus_vga_mode_valid(struct drm_connector *connector,
> -  struct drm_display_mode *mode)
> -{
> - /* Any mode we've added is valid */
> - return MODE_OK;
> -}
> -
>  static struct drm_encoder *cirrus_connector_best_encoder(struct drm_connector
> *connector)
>  {
> @@ -543,7 +536,6 @@ static void cirrus_connector_destroy(struct drm_connector 
> *connector)
>  
>  struct drm_connector_helper_funcs cirrus_vga_connector_helper_funcs = {
>   .get_modes = cirrus_vga_get_modes,
> - .mode_valid = cirrus_vga_mode_valid,
>   .best_encoder = cirrus_connector_best_encoder,
>  };
>  
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 1fbe842..3ca0aed 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -186,7 +186,7 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   drm_mode_validate_flag(connector, mode_flags);
>  
>   list_for_each_entry(mode, >modes, head) {
> - if (mode->status == MODE_OK)
> + if (mode->status == MODE_OK && connector_funcs->mode_valid)
>   mode->status = connector_funcs->mode_valid(connector,
>  mode);
>   }
> diff

[PATCH] drm/i915: fix command parser debug print format mismatches

2014-04-02 Thread Jani Nikula

Drop the cast from the pointer diff to fix:

drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects
argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int'
[-Wformat]

While at it, use %u for u32.

Reported-by: Randy Dunlap 
Signed-off-by: Jani Nikula 

---

Randy, try as I might, I wasn't able to coerce gcc to spit out that
warning. Please enlighten me! (Does this fix the warn?)

Thanks for the report.
---
 drivers/gpu/drm/i915/i915_cmd_parser.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 71ac3b4eaa0d..e5c4e99a22fb 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -811,10 +811,10 @@ int i915_parse_cmds(struct intel_ring_buffer *ring,
length = ((*cmd & desc->length.mask) + LENGTH_BIAS);

if ((batch_end - cmd) < length) {
-   DRM_DEBUG_DRIVER("CMD: Command length exceeds batch 
length: 0x%08X length=%d batchlen=%td\n",
+   DRM_DEBUG_DRIVER("CMD: Command length exceeds batch 
length: 0x%08X length=%u batchlen=%td\n",
 *cmd,
 length,
-(unsigned long)(batch_end - cmd));
+batch_end - cmd);
ret = -EINVAL;
break;
}
-- 
1.7.9.5

[PATCH] drm: make mode_valid callback optional

Many drm connectors do not need mode validation.
The patch makes this callback optional and removes dumb implementations.

Signed-off-by: Andrzej Hajda 
---
Hi,

This patch is based on the latest drm-next.
I have removed all dumb implementations except for qxl_display.c,
which is not entirely dumb - it contains log and TODO comments.

Changes seems to be quite obvious so I have put everything into single patch.

Regards
Andrzej
---
 drivers/gpu/drm/ast/ast_mode.c | 7 ---
 drivers/gpu/drm/bridge/ptn3460.c   | 7 ---
 drivers/gpu/drm/cirrus/cirrus_mode.c   | 8 
 drivers/gpu/drm/drm_crtc_helper.c  | 2 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c| 7 ---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c| 7 ---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 7 ---
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  | 7 ---
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c   | 7 ---
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  | 7 ---
 drivers/staging/imx-drm/imx-hdmi.c | 8 
 drivers/staging/imx-drm/imx-ldb.c  | 7 ---
 drivers/staging/imx-drm/parallel-display.c | 7 ---
 13 files changed, 1 insertion(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index a4afdc8..e599d64 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -743,12 +743,6 @@ static int ast_get_modes(struct drm_connector *connector)
return 0;
 }

-static int ast_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
-   return MODE_OK;
-}
-
 static void ast_connector_destroy(struct drm_connector *connector)
 {
struct ast_connector *ast_connector = to_ast_connector(connector);
@@ -765,7 +759,6 @@ ast_connector_detect(struct drm_connector *connector, bool 
force)
 }

 static const struct drm_connector_helper_funcs ast_connector_helper_funcs = {
-   .mode_valid = ast_mode_valid,
.get_modes = ast_get_modes,
.best_encoder = ast_best_single_encoder,
 };
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index a9e5c1a..3ff2813 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -225,12 +225,6 @@ out:
return num_modes;
 }

-static int ptn3460_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
-{
-   return MODE_OK;
-}
-
 struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
 {
struct ptn3460_bridge *ptn_bridge;
@@ -242,7 +236,6 @@ struct drm_encoder *ptn3460_best_encoder(struct 
drm_connector *connector)

 struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
.get_modes = ptn3460_get_modes,
-   .mode_valid = ptn3460_mode_valid,
.best_encoder = ptn3460_best_encoder,
 };

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 2d64aea..057c7d1 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -502,13 +502,6 @@ static int cirrus_vga_get_modes(struct drm_connector 
*connector)
return count;
 }

-static int cirrus_vga_mode_valid(struct drm_connector *connector,
-struct drm_display_mode *mode)
-{
-   /* Any mode we've added is valid */
-   return MODE_OK;
-}
-
 static struct drm_encoder *cirrus_connector_best_encoder(struct drm_connector
  *connector)
 {
@@ -543,7 +536,6 @@ static void cirrus_connector_destroy(struct drm_connector 
*connector)

 struct drm_connector_helper_funcs cirrus_vga_connector_helper_funcs = {
.get_modes = cirrus_vga_get_modes,
-   .mode_valid = cirrus_vga_mode_valid,
.best_encoder = cirrus_connector_best_encoder,
 };

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fbe842..3ca0aed 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -186,7 +186,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
drm_mode_validate_flag(connector, mode_flags);

list_for_each_entry(mode, >modes, head) {
-   if (mode->status == MODE_OK)
+   if (mode->status == MODE_OK && connector_funcs->mode_valid)
mode->status = connector_funcs->mode_valid(connector,
   mode);
}
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a59bca9..a135025 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -949,12 +949,6 @@ static int exynos_dp_get_modes(struct drm_connector 
*connector)
return 1;
 }

-static int exynos_dp_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode

spinlock lockup suspected on CPU error on omapdrm

On Wed, Apr 2, 2014 at 8:23 AM, Vikas Patil  wrote:
> Hi,
> I am seeing following kernel backtrace on J6 with linux 3.8.13 when trying
> to start IVI LM service. Before starting this I started the X11 and run some
> GLES2/X11 based tests successfully.
>
> The same binaries and my graphics driver are working fine on OMAP5 and linux
> 3.4.25. Is this some known BUG in omapdrm driver? If not a bug then how
> should I go for debugging it?
>
> From the trace what I understood is, this is case of nested spinlock and I
> might be seeing this error due to this as in the trace omap_gem_op_update()
> and omap_gem_set_sync_object(), both functions are trying to acquire
> spin_lock(_lock).
>

ok, to be fair this is more about pvr and some downstream patches to
omapdrm to make it work with pvr, than the upstream omapdrm.

tbh, I don't completely remember how this used to work.. it doesn't
seem like the sort of thing that could be easily missed.  You might
want to compare to older omapdrm+pvr, I might have moved some of the
locking around?

Probably the best/safest thing would be to move the waiter->notify()
callback off to omapdrm's workqueue, so it isn't called with spinlocks
held.

BR,
-R

>
> [  719.005340] BUG: spinlock lockup suspected on CPU#0, kworker/u:2/787
> [  719.011749]  lock: sync_lock+0x0/0x20, .magic: dead4ead, .owner:
> kworker/u:2/787, .owner_cpu: 0
> [  719.020507] [] (unwind_backtrace+0x0/0x138) from []
> (do_raw_spin_lock+0x100/0x17c)
> [  719.029876] [] (do_raw_spin_lock+0x100/0x17c) from []
> (omap_gem_set_sync_object+0x14/0xf4)
> [  719.039978] [] (omap_gem_set_sync_object+0x14/0xf4) from
> [] (FreeMemCallBackCommon+0xf4/0x24c [omapdrm_pvr])
> [  719.051635] [] (FreeMemCallBackCommon+0xf4/0x24c [omapdrm_pvr])
> from [] (UnwrapExtMemoryCallBack+0x28/0x68 [omapdrm_pvr])
> [  719.064544] [] (UnwrapExtMemoryCallBack+0x28/0x68
> [omapdrm_pvr]) from [] (FreeResourceByPtr.part.0+0xac/0xcc
> [omapdrm_pvr])
> [  719.077575] [] (FreeResourceByPtr.part.0+0xac/0xcc
> [omapdrm_pvr]) from [] (ResManFreeResByPtr+0x44/0x6c
> [omapdrm_pvr])
> [  719.090118] [] (ResManFreeResByPtr+0x44/0x6c [omapdrm_pvr])
> from [] (async_unmap+0x28/0x44 [omapdrm_pvr])
> [  719.101531] [] (async_unmap+0x28/0x44 [omapdrm_pvr]) from
> [] (sync_op_update+0x88/0xa8)
> [  719.111328] [] (sync_op_update+0x88/0xa8) from []
> (omap_gem_op_update+0x14/0x24)
> [  719.120544] [] (omap_gem_op_update+0x14/0x24) from []
> (PVRSRVMISR+0xc/0x60 [omapdrm_pvr])
> [  719.130523] [] (PVRSRVMISR+0xc/0x60 [omapdrm_pvr]) from
> [] (process_one_work+0x1c8/0x5c0)
> [  719.140502] [] (process_one_work+0x1c8/0x5c0) from []
> (worker_thread+0x168/0x444)
> [  719.149810] [] (worker_thread+0x168/0x444) from []
> (kthread+0xa4/0xb0)
> [  719.158142] [] (kthread+0xa4/0xb0) from []
> (ret_from_fork+0x14/0x24)
>
> Thanking you for your time.
>
> Thanks & Regards,
> Vikas

[PATCH 1/4] drm: Optionally create mm blocks from top-to-bottom

On Mon, Mar 31, 2014 at 03:27:54PM +0300, Lauri Kasanen wrote:
> Clients like i915 need to segregate cache domains within the GTT which
> can lead to small amounts of fragmentation. By allocating the uncached
> buffers from the bottom and the cacheable buffers from the top, we can
> reduce the amount of wasted space and also optimize allocation of the
> mappable portion of the GTT to only those buffers that require CPU
> access through the GTT.
> 
> For other drivers, allocating small bos from one end and large ones
> from the other helps improve the quality of fragmentation.
> 
> Original patch by Chris Wilson.
> 
> v2 by Ben:
> Update callers in i915_gem_object_bind_to_gtt()
> Turn search flags and allocation flags into separate enums
> Make checkpatch happy where logical/easy
> 
> v3 by Ben:
> Rebased on top of the many drm_mm changes since the original patches
> Remove ATOMIC from allocator flags (Chris)
> Reverse order of TOPDOWN and BOTTOMUP
> 
> v4 by Lauri:
> Remove i915 parts, they don't apply
> Respin on top of drm-next
> 
> Signed-off-by: Lauri Kasanen 

Please also update the kerneldoc we now have in drm-next, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_mm.c | 56 
> +++-
>  include/drm/drm_mm.h | 29 +
>  2 files changed, 66 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index a2d45b74..1728bcc 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -102,7 +102,8 @@ static struct drm_mm_node 
> *drm_mm_search_free_in_range_generic(const struct drm_
>  static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
>struct drm_mm_node *node,
>unsigned long size, unsigned alignment,
> -  unsigned long color)
> +  unsigned long color,
> +  enum drm_mm_allocator_flags flags)
>  {
>   struct drm_mm *mm = hole_node->mm;
>   unsigned long hole_start = drm_mm_hole_node_start(hole_node);
> @@ -115,12 +116,22 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
>   if (mm->color_adjust)
>   mm->color_adjust(hole_node, color, _start, _end);
>  
> + if (flags & DRM_MM_CREATE_TOP)
> + adj_start = adj_end - size;
> +
>   if (alignment) {
>   unsigned tmp = adj_start % alignment;
> - if (tmp)
> - adj_start += alignment - tmp;
> + if (tmp) {
> + if (flags & DRM_MM_CREATE_TOP)
> + adj_start -= tmp;
> + else
> + adj_start += alignment - tmp;
> + }
>   }
>  
> + BUG_ON(adj_start < hole_start);
> + BUG_ON(adj_end > hole_end);
> +
>   if (adj_start == hole_start) {
>   hole_node->hole_follows = 0;
>   list_del(_node->hole_stack);
> @@ -215,16 +226,17 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
>  int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
>  unsigned long size, unsigned alignment,
>  unsigned long color,
> -enum drm_mm_search_flags flags)
> +enum drm_mm_search_flags sflags,
> +enum drm_mm_allocator_flags aflags)
>  {
>   struct drm_mm_node *hole_node;
>  
>   hole_node = drm_mm_search_free_generic(mm, size, alignment,
> -color, flags);
> +color, sflags);
>   if (!hole_node)
>   return -ENOSPC;
>  
> - drm_mm_insert_helper(hole_node, node, size, alignment, color);
> + drm_mm_insert_helper(hole_node, node, size, alignment, color, aflags);
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_mm_insert_node_generic);
> @@ -233,7 +245,8 @@ static void drm_mm_insert_helper_range(struct drm_mm_node 
> *hole_node,
>  struct drm_mm_node *node,
>  unsigned long size, unsigned alignment,
>  unsigned long color,
> -unsigned long start, unsigned long end)
> +unsigned long start, unsigned long end,
> +enum drm_mm_allocator_flags flags)
>  {
>   struct drm_mm *mm = hole_node->mm;
>   unsigned long hole_start = drm_mm_hole_node_start(hole_node);
> @@ -248,13 +261,20 @@ static void drm_mm_insert_helper_range(struct 
> drm_mm_node *hole_node,
>   if (adj_end > end)
>   adj_end = end;
>  
> + if (flags & DRM_MM_CREATE_TOP)
> + adj_start = adj_end - size;
> +
>   if (mm->color_adjust)
>   mm->color_adjust(hole_node, color, _start, _end);
>

[Nouveau] [PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()

2014-04-02 Thread Ilia Mirkin

On Wed, Apr 2, 2014 at 10:14 AM, Alexandre Courbot  wrote:
 + /* Need to figure out how to handle sw for gk20a */
 + if (device->chipset == 0xea)
 + goto skip_sw_init;
>>>
>>> The commit message makes it sound like SW isn't needed since gk20a
>>> "lacks any display hardware". In that case the comment here doesn't make
>>> much sense.
>
> Correct. As far as I have looked (that is, not very far), SW methods
> are used for display-related functions, but there might be other
> use-cases too. Maybe someone who knows better can confirm?

http://cgit.freedesktop.org/~darktama/nouveau/tree/nvkm/engine/software/nvc0.c

Take a look at nvc0_software_mthd_mp_control -- that's used in the
mesa driver to... well, control those things :) They're related to
PGRAPH, which should be available on the GK20A. [Not sure what they do
though. One of them is about turning off error reporting.]

  -ilia

[PATCH 1/4] drm/omap: fix output enable/disable sequence

On Wed, Apr 2, 2014 at 8:37 AM, Tomi Valkeinen  wrote:
> At the moment it's quite easy to get the following errors when the HDMI
> output is enabled or disabled:
>
> [drm:omap_crtc_error_irq] *ERROR* tv: errors: 8000
>
> The reason for the errors is that the omapdrm driver doesn't properly
> handle the sync-lost irqs that happen when enabling the DIGIT crtc,
> which is used for HDMI and analog TV. The driver does disable the
> sync-lost irq properly, but it fails to wait until the output has been
> fully enabled (i.e. the first vsync), so the sync-lost errors are still
> seen occasionally.
>
> This patch makes the omapdrm act the same way as the omapfb does:
>
> - When enabling a display, we'll wait for the first vsync.
> - When disabling a display, we'll wait for framedone if available, or
>   odd and even vsyncs.
>
> These changes make sure the output is fully enabled or disabled at the
> end of the function.
>
> Signed-off-by: Tomi Valkeinen 
> Reported-by: Sanjay Singh Rawat 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 46 
> ++---
>  1 file changed, 27 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 4313bb0a49a6..e7b643c178a6 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -527,38 +527,46 @@ static void set_enabled(struct drm_crtc *crtc, bool 
> enable)
> struct drm_device *dev = crtc->dev;
> struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> enum omap_channel channel = omap_crtc->channel;
> -   struct omap_irq_wait *wait = NULL;
> +   struct omap_irq_wait *wait;
> +   u32 framedone_irq, vsync_irq;
> +   int ret;
>
> if (dispc_mgr_is_enabled(channel) == enable)
> return;
>
> -   /* ignore sync-lost irqs during enable/disable */
> +   /*
> +* Digit output produces some sync lost interrupts during the first
> +* frame when enabling, so we need to ignore those.
> +*/
> omap_irq_unregister(crtc->dev, _crtc->error_irq);
>
> -   if (dispc_mgr_get_framedone_irq(channel)) {
> -   if (!enable) {
> -   wait = omap_irq_wait_init(dev,
> -   dispc_mgr_get_framedone_irq(channel), 
> 1);
> -   }
> +   framedone_irq = dispc_mgr_get_framedone_irq(channel);
> +   vsync_irq = dispc_mgr_get_vsync_irq(channel);
> +
> +   if (enable) {
> +   wait = omap_irq_wait_init(dev, vsync_irq, 1);
> } else {
> /*
> -* When we disable digit output, we need to wait until fields
> -* are done.  Otherwise the DSS is still working, and turning
> -* off the clocks prevents DSS from going to OFF mode. And 
> when
> -* enabling, we need to wait for the extra sync losts
> +* When we disable the digit output, we need to wait for
> +* FRAMEDONE to know that DISPC has finished with the output.
> +*
> +* OMAP2/3 does not have FRAMEDONE irq for digit output, and 
> in
> +* that case we need to use vsync interrupt, and wait for both
> +* even and odd frames.
>  */
> -   wait = omap_irq_wait_init(dev,
> -   dispc_mgr_get_vsync_irq(channel), 2);
> +
> +   if (framedone_irq)
> +   wait = omap_irq_wait_init(dev, framedone_irq, 1);
> +   else
> +   wait = omap_irq_wait_init(dev, vsync_irq, 2);
> }
>
> dispc_mgr_enable(channel, enable);
>
> -   if (wait) {
> -   int ret = omap_irq_wait(dev, wait, msecs_to_jiffies(100));
> -   if (ret) {
> -   dev_err(dev->dev, "%s: timeout waiting for %s\n",
> -   omap_crtc->name, enable ? "enable" : 
> "disable");
> -   }
> +   ret = omap_irq_wait(dev, wait, msecs_to_jiffies(100));
> +   if (ret) {
> +   dev_err(dev->dev, "%s: timeout waiting for %s\n",
> +   omap_crtc->name, enable ? "enable" : 
> "disable");
> }
>
> omap_irq_register(crtc->dev, _crtc->error_irq);
> --
> 1.8.3.2
>

[Nouveau] [PATCH 06/12] drm/nouveau/ibus: add GK20A support

2014-04-02 Thread Ilia Mirkin

On Wed, Apr 2, 2014 at 9:52 AM, Alexandre Courbot  wrote:
> On Tue, Mar 25, 2014 at 7:34 AM, Thierry Reding
>  wrote:
>> On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote:
>> [...]
>>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c 
>>> b/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
>> [...]
>>> +#include 
>>> +
>>> +struct nvea_ibus_priv {
>>> + struct nouveau_ibus base;
>>> +};
>>> +
>>> +static void
>>> +nvea_ibus_init_priv_ring(struct nvea_ibus_priv *priv)
>>> +{
>>> + nv_mask(priv, 0x137250, 0x3f, 0);
>>> +
>>> + nv_mask(priv, 0x000200, 0x20, 0);
>>> + udelay(20);
>>
>> usleep_range()?
>
> Sure.
>
>>
>>> +static void
>>> +nvea_ibus_intr(struct nouveau_subdev *subdev)
>>> +{
>> [...]
>>> + /* Acknowledge interrupt */
>>> + nv_mask(priv, 0x12004c, 0x2, 0x2);
>>> +
>>> + while (--retry >= 0) {
>>> + command = nv_rd32(priv, 0x12004c) & 0x3f;
>>> + if (command == 0)
>>> + break;
>>> + }
>>> +
>>> + if (retry < 0)
>>> + nv_warn(priv, "timeout waiting for ringmaster ack\n");
>>> +}
>>
>> Perhaps I'm being paranoid, but this loop now depends on the frequency
>> of the various clocks involved and therefore might break at some point
>> if the frequencies get sufficiently high.
>>
>> So a slightly safer implementation would use a proper timeout using a
>> combination of msecs_to_jiffies(), time_before() and usleep_range(),
>> like so:
>>
>> timeout = jiffies + msecs_to_jiffies(...);
>>
>> while (time_before(jiffies, timeout)) {
>> command = nv_rd32(...) & 0x3f;
>> if (command == 0)
>> break;
>>
>> usleep_range(...);
>> }
>>
>> if (time_after(jiffies, timeout))
>> nv_warn(...);
>
> Right, now that I look at this code again I don't even understand why
> I left it this way. Maybe I left some early test code slip into the
> final patch, sorry about that.

I just remembered about this, but there's also the nv_wait() macro,
which you could use, e.g.

if (!nv_wait(subdev, 0x12004c, 0x3f, 0x00))
  nv_warn(...)

It has built-in timeout logic/etc (although no sleeps in the middle).
It does use the timer subdev, so if that's not operational at this
point, you can't use it.

>
>> This assumes that there's some known timeout after which the ringmaster
>> is expected to have acked the interrupt. On that note, I wonder if the
>> warning is accurate here: it's my understanding that writing 0x2 to the
>> register does acknowledge the interrupt, so the ringmaster does in fact
>> "clear" it rather than "acknowledge" it, doesn't it?
>>
>> Although now that I mention it I seem to remember that this write is
>> actually sending a command to the ring master and perhaps waiting for
>> the register to return to 0 is indeed waiting for an ACK of sorts. Maybe
>> adding a comment or so describing what this sequence does would be
>> appropriate here?
>
> Can we from an IP point of view? AFAIK this sequence has never been
> publicly documented.
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH 2/4] drm/omap: fix uninit order in pdev_remove()

On Wed, Apr 2, 2014 at 8:37 AM, Tomi Valkeinen  wrote:
> When unloading omapdrm driver, the omapdrm platform device is
> uninitialized last, after the displays have been disconnected omap_crtc
> callbacks have been removed. As the omapdrm pdev uninitialization needs
> the features uninitialized in earlier steps, a crash is guaranteed.
>
> This patch fixes the uninitialize order so that the omapdrm pdev is
> removed first.
>
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Rob Clark  ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index bf39fcc49e0f..df3e66416a30 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -696,10 +696,11 @@ static int pdev_remove(struct platform_device *device)
>  {
> DBG("");
>
> +   drm_put_dev(platform_get_drvdata(device));
> +
> omap_disconnect_dssdevs();
> omap_crtc_pre_uninit();
>
> -   drm_put_dev(platform_get_drvdata(device));
> return 0;
>  }
>
> --
> 1.8.3.2
>

[PATCH 3/4] drm/omap: fix DMM driver (un)registration

On Wed, Apr 2, 2014 at 8:37 AM, Tomi Valkeinen  wrote:
> At the moment the DMM driver is never unregistered, even if it's
> registered in the omapdrm module's init function. This means we'll get
> errors when reloading the omapdrm module.
>
> Fix this by unregistering the DMM driver properly, and also change the
> module init to fail if DMM driver cannot be registered, simplifying the
> unregister path as we don't need to keep the state whether we registered
> the DMM driver or not.
>
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index df3e66416a30..f16a07d1668d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -727,18 +727,33 @@ static struct platform_driver pdev = {
>
>  static int __init omap_drm_init(void)
>  {
> +   int r;
> +
> DBG("init");
> -   if (platform_driver_register(_dmm_driver)) {
> -   /* we can continue on without DMM.. so not fatal */
> -   dev_err(NULL, "DMM registration failed\n");
> +
> +   r = platform_driver_register(_dmm_driver);

the one thing I wonder slightly about, this is making omap_dmm_driver
register fail fatal, whereas it wasn't before..

That said, I don't remember in which case the dmm driver registration
would fail.  I think registering the driver should succeed even (for
example) on omap3 without dmm/tiler device.  But I guess you've
probably tested on o3 just to make sure?  Assuming you have:

Reviewed-by: Rob Clark 

> +   if (r) {
> +   pr_err("DMM driver registration failed\n");
> +   return r;
> }
> -   return platform_driver_register();
> +
> +   r = platform_driver_register();
> +   if (r) {
> +   pr_err("omapdrm driver registration failed\n");
> +   platform_driver_unregister(_dmm_driver);
> +   return r;
> +   }
> +
> +   return 0;
>  }
>
>  static void __exit omap_drm_fini(void)
>  {
> DBG("fini");
> +
> platform_driver_unregister();
> +
> +   platform_driver_unregister(_dmm_driver);
>  }
>
>  /* need late_initcall() so we load after dss_driver's are loaded */
> --
> 1.8.3.2
>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

--- Comment #69 from Pali Roh?r  ---
BUMP!

-- 
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/20140402/047fffe8/attachment.html>

[PATCH 4/4] drm/omap: fix race issue when unloading omapdrm

On Wed, Apr 2, 2014 at 8:38 AM, Tomi Valkeinen  wrote:
> At module unload, omap_fbdev_free() gets called which releases the
> framebuffers. However, the framebuffers are still used by crtcs, and
> will be released only later at vsync. The driver doesn't wait for this,
> and goes on to release the rest of the resources, which often
> causes a crash.
>
> This patchs adds a omap_crtc_flush() function which waits until the crtc
> has finished with its apply queue and page flips.
>
> The function utilizes a simple polling while-loop, as the performance is
> not an issue here.
>
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 19 +++
>  drivers/gpu/drm/omapdrm/omap_drv.c  |  6 ++
>  drivers/gpu/drm/omapdrm/omap_drv.h  |  1 +
>  3 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index e7b643c178a6..4f624c59a660 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -620,6 +620,25 @@ static void omap_crtc_post_apply(struct omap_drm_apply 
> *apply)
> /* nothing needed for post-apply */
>  }
>
> +void omap_crtc_flush(struct drm_crtc *crtc)
> +{
> +   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> +   int loops = 0;
> +
> +   while (!list_empty(_crtc->pending_applies) ||
> +   !list_empty(_crtc->queued_applies) ||
> +   omap_crtc->event || omap_crtc->old_fb) {
> +
> +   if (++loops > 10) {
> +   dev_err(crtc->dev->dev,
> +   "omap_crtc_flush() timeout\n");
> +   break;
> +   }
> +
> +   schedule_timeout_uninterruptible(msecs_to_jiffies(20));
> +   }
> +}
> +
>  static const char *channel_names[] = {
> [OMAP_DSS_CHANNEL_LCD] = "lcd",
> [OMAP_DSS_CHANNEL_DIGIT] = "tv",
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index f16a07d1668d..c8270e4b26f3 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -513,12 +513,18 @@ static int dev_load(struct drm_device *dev, unsigned 
> long flags)
>  static int dev_unload(struct drm_device *dev)
>  {
> struct omap_drm_private *priv = dev->dev_private;
> +   int i;
>
> DBG("unload: dev=%p", dev);
>
> drm_kms_helper_poll_fini(dev);
>
> omap_fbdev_free(dev);
> +
> +   /* flush crtcs so the fbs get released */
> +   for (i = 0; i < priv->num_crtcs; i++)
> +   omap_crtc_flush(priv->crtcs[i]);
> +
> omap_modeset_free(dev);
> omap_gem_deinit(dev);
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
> b/drivers/gpu/drm/omapdrm/omap_drv.h
> index 428b2981fd68..284b80fc3c54 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -163,6 +163,7 @@ void omap_crtc_pre_init(void);
>  void omap_crtc_pre_uninit(void);
>  struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> struct drm_plane *plane, enum omap_channel channel, int id);
> +void omap_crtc_flush(struct drm_crtc *crtc);
>
>  struct drm_plane *omap_plane_init(struct drm_device *dev,
> int plane_id, bool private_plane);
> --
> 1.8.3.2
>

[Bug 76919] Random junk at the bottom of non-multiple-of-4 compressed textures (original or mipmapped)

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

--- Comment #1 from Tapani P?lli  ---
I don't know details of the problem here but I got interested and went to read
the spec ..

EXT_texture_compression_s3tc specification states in "Implementation Note":

"If the width or height is not a multiple of four, there will be 4x4 blocks at
the edge of the image that contain "extra" texels that are not part of the
image."

I'm not sure though what should happen if one samples/reads such texel.

-- 
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/20140402/c3561c3d/attachment.html>

[PATCH] drm/exynos: add phy settings for RB resolutions

2014-04-02 Thread Shirish S

Hi,
Kindly hold the merging of this patch, i shall
update it with proper values, once i receive it from our hardware team.
Regards,
ShirisH S
On Thu, Mar 20, 2014 at 1:05 PM, St?phane Marchesin
 wrote:
>
>
>
> On Wed, Mar 12, 2014 at 10:28 PM, Shirish S  wrote:
>>
>> This patch adds support for the below mentioned
>> pixel clocks in Exynos5250.
>> Without them, following display modes won't
>> be supported:
>>
>> 71 MHz  - 1280x800 at 60Hz RB
>> 73.25 MHz   - 800x600 at 120Hz RB
>> 88.75 MHz   - 1440x900 at 60Hz RB
>> 115.5 MHz   - 1024x768 at 120Hz RB
>> 119 MHz - 1680x1050 at 60Hz RB
>>
>> Signed-off-by: Shirish S 
>> ---
>> V2: Incorporated review comments
>>
>>  drivers/gpu/drm/exynos/exynos_hdmi.c |   45
>> ++
>>  1 file changed, 45 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 12fdf55..406d89d 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -304,6 +304,24 @@ static const struct hdmiphy_config
>> hdmiphy_v14_configs[] = {
>> },
>> },
>> {
>> +   .pixel_clock = 7100,
>> +   .conf = {
>> +   0x01, 0x91, 0x1e, 0x15, 0x40, 0x3c, 0xce, 0x08,
>> +   0x04, 0x20, 0xb2, 0xd8, 0x45, 0xa0, 0xac, 0x80,
>> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
>> +   0x54, 0xad, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
>> +   },
>> +   },
>> +   {
>> +   .pixel_clock = 7325,
>> +   .conf = {
>> +   0x01, 0xd1, 0x1f, 0x15, 0x40, 0x18, 0xe9, 0x08,
>> +   0x02, 0xa0, 0xb7, 0xd8, 0x45, 0xa0, 0xac, 0x80,
>> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
>> +   0x54, 0xa8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
>> +   },
>> +   },
>> +   {
>> .pixel_clock = 74176000,
>> .conf = {
>> 0x01, 0xd1, 0x3e, 0x35, 0x40, 0x5b, 0xde, 0x08,
>> @@ -331,6 +349,15 @@ static const struct hdmiphy_config
>> hdmiphy_v14_configs[] = {
>> },
>> },
>> {
>> +   .pixel_clock = 8875,
>> +   .conf = {
>> +   0x01, 0x91, 0x25, 0x17, 0x40, 0x30, 0xfe, 0x08,
>> +   0x06, 0x20, 0xde, 0xd8, 0x45, 0xa0, 0xac, 0x80,
>> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
>> +   0x54, 0x8a, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
>> +   },
>> +   },
>> +   {
>> .pixel_clock = 10650,
>> .conf = {
>> 0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08,
>> @@ -349,6 +376,24 @@ static const struct hdmiphy_config
>> hdmiphy_v14_configs[] = {
>> },
>> },
>> {
>> +   .pixel_clock = 11550,
>> +   .conf = {
>> +   0x01, 0xd1, 0x30, 0x1a, 0x40, 0x40, 0x10, 0x04,
>> +   0x04, 0xa0, 0x21, 0xd9, 0x45, 0xa0, 0xac, 0x80,
>> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
>> +   0x54, 0xaa, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
>> +   },
>> +   },
>> +   {
>> +   .pixel_clock = 11900,
>
>
>
> We have found that the 119MHz clock doesn't work in Chrome OS (the clock
> doesn't stabilize), so we removed it. We should probably remove it here as
> well.
>
> St?phane
>
I have informed this issue to the hardware team, and will update it
once i receive
any changes,
Also i
>> +   .conf = {
>> +   0x01, 0x91, 0x32, 0x14, 0x40, 0x60, 0xd8, 0x08,
>> +   0x06, 0x20, 0x2a, 0xd9, 0x45, 0xa0, 0xac, 0x80,
>> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
>> +   0x54, 0x9d, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
>> +   },
>> +   },
>> +   {
>> .pixel_clock = 14625,
>> .conf = {
>> 0x01, 0xd1, 0x3d, 0x15, 0x40, 0x18, 0xfd, 0x08,
>> --
>> 1.7.10.4
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

[PATCH] drm: Missed clflushopt in drm_clflush_virt_range

2014-04-02 Thread Ross Zwisler

With this commit:

2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range

If clflushopt is available on the system, we use it instead of clflush
in drm_clflush_virt_range.  There were two calls to clflush in this
function, but only one was changed to clflushopt.  This patch changes
the other clflush call to clflushopt.

Signed-off-by: Ross Zwisler 
Reported-by: Matthew Wilcox 
---
 drivers/gpu/drm/drm_cache.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 534cb89..041b73b 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -138,7 +138,7 @@ drm_clflush_virt_range(char *addr, unsigned long length)
char *end = addr + length;
mb();
for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
-   clflush(addr);
+   clflushopt(addr);
clflushopt(end - 1);
mb();
return;
-- 
1.7.10.4

[PATCH v3 00/12] Add DSI display support for Exynos based boards

Hi Inki,

I see you have took also ld9040 driver patch [1].
Could you take the 3rd version of this patch [2].
It fixes build dependencies.

[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/102592
[2]: http://permalink.gmane.org/gmane.comp.video.dri.devel/102659

Thanks and Regards
Andrzej

On 04/01/2014 02:29 PM, Inki Dae wrote:
> Hi Andrzej,
>
>
>
> 2014-03-28 20:52 GMT+09:00 Andrzej Hajda :
>> Hi,
>>
>> This patchset adds drivers and bindings to the following devices:
>> - Exynos DSI master,
>> - S6E8AA0 DSI panel,
>>
>> It adds also display support in DTS files for the following boards:
>> - Exynos4210/Trats,
>> - Exynos4412/Trats2.
>>
>> The patchset is based on exynos_drm_next branch.
>>
>> It is the 3rd iteration of the patches, main changes:
>> - based on exynos_drm_next branch,
>> - added video interface bindings between DSI host and slave,
>>   it seems to me to be redundand, and I hope when video interface bindings
>>   will be stabilized it can become optional,
>> - GPIOs implemented using gpiod framework,
>> - removed controversial stuff (toshiba bridge implementation and arndale 
>> support),
>>   it will be send in another set of patches
>>
>> Other changes are described in individual patches.
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (12):
>>   drm/mipi_dsi: add flags to DSI messages
>>   drm/mipi_dsi: create dsi devices only for nodes with reg property
>>   drm/exynos: disallow fbdev initialization if no device is connected
>>   exynos/dsim: add DT bindings
>>   drm/exynos: add DSIM driver
>>   panel/s6e8aa0: add DT bindings
>>   drm/panel: add S6E8AA0 driver
>>   ARM: dts: exynos4: add MIPI DSI Master node
>>   ARM: dts: exynos4210-trats: add panel node
>>   ARM: dts: exynos4412-trats2: add panel node
>>   ARM: dts: exynos4210-trats: enable exynos/fimd node
>>   ARM: dts: exynos4412-trats2: enable exynos/fimd node
> Picked up this patch series.
>
> Thanks for your contribution,
> Inki Dae
>
>>  .../devicetree/bindings/panel/samsung,s6e8aa0.txt  |   56 +
>>  .../devicetree/bindings/video/exynos_dsim.txt  |   80 +
>>  arch/arm/boot/dts/exynos4.dtsi |   14 +
>>  arch/arm/boot/dts/exynos4210-trats.dts |   61 +
>>  arch/arm/boot/dts/exynos4412-trats2.dts|   70 +
>>  drivers/gpu/drm/drm_mipi_dsi.c |6 +-
>>  drivers/gpu/drm/exynos/Kconfig |9 +
>>  drivers/gpu/drm/exynos/Makefile|1 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   15 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1525 
>> 
>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   21 +
>>  drivers/gpu/drm/panel/Kconfig  |7 +
>>  drivers/gpu/drm/panel/Makefile |1 +
>>  drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1069 ++
>>  include/drm/drm_mipi_dsi.h |6 +
>>  16 files changed, 2941 insertions(+), 1 deletion(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
>>  create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>  create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c
>>
>> --
>> 1.8.3.2
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Synchronization between a crtc mode_set and page_flip?

On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja  wrote:
> Hi,
>
> I was trying to figure out how we are supposed to manage synchronization
> between a mode_set and a page_flip called on a crtc.
>
> Say, if a mode_set is immediately followed by a page_flip. The driver can't
> process the page_flip straight away since the hardware is still completing
> the mode_set.

I guess setcrtc is expected to be synchronous(ish).. so a lot of
userspace won't expect the first pageflip to fail with -EBUSY.

BR,
-R

> What is the driver supposed to do? Should it return -EBUSY? Or should it
> somehow queue the page_flip task internally?
>
> A lot of libdrm applications seem to call mode_set, and call a page_flip
> soon after it. They tend to bail out if page_flip returns an error, they
> don't try to do another page_flip if it fails the first time. Is this okay
> behaviour?
>
> Thanks,
> Archit
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix typo in spectre_golden_registers

2014-04-02 Thread Alex Deucher

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index dd545521..448da65 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -1095,7 +1095,7 @@ static const u32 spectre_golden_registers[] =
0x8a14, 0xf03f, 0x0007,
0x8b24, 0x, 0x00ff,
0x28350, 0x3f3f3fff, 0x0082,
-   0x28355, 0x003f, 0x,
+   0x28354, 0x003f, 0x,
0x3e78, 0x0001, 0x0002,
0x913c, 0x03df, 0x0004,
0xc768, 0x0008, 0x0008,
-- 
1.8.3.1

[PATCH] drm/radeon: fix endian swap on hawaii clear state buffer setup

2014-04-02 Thread Alex Deucher

Need to swap on BE.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 9bfd3d3..dd545521 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6542,8 +6542,8 @@ void cik_get_csb_buffer(struct radeon_device *rdev, 
volatile u32 *buffer)
buffer[count++] = cpu_to_le32(0x);
break;
case CHIP_HAWAII:
-   buffer[count++] = 0x3a00161a;
-   buffer[count++] = 0x002e;
+   buffer[count++] = cpu_to_le32(0x3a00161a);
+   buffer[count++] = cpu_to_le32(0x002e);
break;
default:
buffer[count++] = cpu_to_le32(0x);
-- 
1.8.3.1

[PATCH] drm/i915: fix command parser debug print format mismatches

2014-04-02 Thread Randy Dunlap

On 04/02/2014 01:24 AM, Jani Nikula wrote:
> Drop the cast from the pointer diff to fix:
> 
> drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects
> argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int'
> [-Wformat]
> 
> While at it, use %u for u32.
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Randy, try as I might, I wasn't able to coerce gcc to spit out that
> warning. Please enlighten me! (Does this fix the warn?)

Yes, it does.  Thanks.

Acked-by: Randy Dunlap 


> Thanks for the report.
> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 71ac3b4eaa0d..e5c4e99a22fb 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -811,10 +811,10 @@ int i915_parse_cmds(struct intel_ring_buffer *ring,
>   length = ((*cmd & desc->length.mask) + LENGTH_BIAS);
>  
>   if ((batch_end - cmd) < length) {
> - DRM_DEBUG_DRIVER("CMD: Command length exceeds batch 
> length: 0x%08X length=%d batchlen=%td\n",
> + DRM_DEBUG_DRIVER("CMD: Command length exceeds batch 
> length: 0x%08X length=%u batchlen=%td\n",
>*cmd,
>length,
> -  (unsigned long)(batch_end - cmd));
> +  batch_end - cmd);
>   ret = -EINVAL;
>   break;
>   }
> 


-- 
~Randy

[Bug 73911] Color Banding on radeon

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

--- Comment #22 from Paula Breton  ---
(In reply to comment #20)
> Created attachment 96751 [details] [review]
> testing patch
> 
> Does this patch help?

it doesn't look like it helps. same problem as before. my cursor has also
disappeared, but that might be a problem of that I haven't worked with the
kernel before at all.

-- 
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/20140402/bf4ac2b0/attachment-0001.html>

X.org doesn't start with 3.14: [KMS] drm report modesetting isn't supported

2014-04-02 Thread Justin Piszcz



> -Original Message-
> From: Bruno Pr?mont [mailto:bonbons at linux-vserver.org]
> Sent: Tuesday, April 01, 2014 4:22 PM
> To: Justin Piszcz
> Cc: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org
> Subject: Re: X.org doesn't start with 3.14: [KMS] drm report modesetting
isn't
> supported
> 
> Hi Justin,
> 
> CC-ing dri-devel as more KMS/radeon people will see it there.

[ .. ]

My issue:
[0.623399] [drm] Loading CEDAR Microcode
[0.623461] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin"
[0.623517] [drm:evergreen_init] *ERROR* Failed to load firmware!
[0.623573] radeon :05:00.0: Fatal error during GPU init
[0.623629] [drm] radeon: finishing device.

Somehow this option became unselected in my kernel configuration, although I
almost always usually run make oldconfig-- so I am not sure how it happened:
[ ]   Include in-kernel firmware blobs in kernel binary

Back to normal as per below:
-*- Userspace firmware loading support
 [*]   Include in-kernel firmware blobs in kernel binary
(radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin
radeon/CYPRESS_uvd.bin)
External firmware (/lib/firmware) Firmware blobs root directory

# pwd
/lib/firmware/radeon
# ls -l *CEDAR*pfp*
-rw-r--r-- 1 root root 4480 Feb 22 16:50 CEDAR_pfp.bin
#

[ .. ]

Thank you && sorry for the noise!

Justin.

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

2014-04-02 Thread Dave Airlie

On Tue, Apr 1, 2014 at 5:45 PM, Daniel Vetter  wrote:
> On Mon, Mar 31, 2014 at 06:03:24PM -0700, Matt Roper wrote:
>> On Fri, Mar 28, 2014 at 09:32:06AM +0100, Daniel Vetter wrote:
>> > On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote:
>> ...
>> > > +  * N.B., we call set_config() directly here rather than using
>> > > +  * drm_mode_set_config_internal.  We're reprogramming the same
>> > > +  * connectors that were already in use, so we shouldn't need the extra
>> > > +  * cross-CRTC fb refcounting to accomodate stealing connectors.
>> > > +  * drm_mode_setplane() already handles the basic refcounting for the
>> > > +  * framebuffers involved in this operation.
>> >
>> > Wrong. The current crtc helper logic disables all disconnected connectors
>> > forcefully on each set_config. Nope, I didn't make those semantics ... So
>> > I think we need to think a bit harder here again.
>> >
>> > See drm_helper_disable_unused_functions.
>>
>> I think I'm still missing something here; can you clarify what the
>> problematic case would be?
>>
>> I only see a call to __drm_helper_disable_unused_functions() in the CRTC
>> helper in cases where mode_changed = 1, which I don't believe it ever
>> should be through the setplane() calls.  We should just be updating the
>> framebuffer (and possibly panning) without touching any of the
>> connectors, so I don't see how unrelated CRTC's would get disabled.  Am
>> I overlooking another case here that the basic refcounting in setplane
>> doesn't already handle?
>
> Looking at drm_helper_disable_unused_functions we'll spot
>
> list_for_each_entry(connector, >mode_config.connector_list, 
> head) {
> if (!connector->encoder)
> continue;
> if (connector->status == connector_status_disconnected)
> connector->encoder = NULL;
> }
>
>
> So as soon as a connector is disconnected and you do _any_ kind of
> ->set_config call with modesetting helpers that crtc gets killed. Even if
> it's completely unrelated. Dave originally changed this with an imo rather
> thin justification:
>
> commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
> Author: Dave Airlie 
> Date:   Mon Aug 31 15:16:30 2009 +1000
>
> drm/kms: add explicit encoder disable function and detach harder.
>
> For shared tv-out and VGA encoders, we really need to know if
> the encoder is just being switched off temporarily in blanking
> or if we are really disabling it hard.
>
> Also we need to try harder to disconnect encoders from unused
> connectors so we can share more efficently.
>
> (shared encoders stuff is coming in radeon tv-out support)
>
> Signed-off-by: Dave Airlie 
>
> To me this always smelled like papering over broken userspace. I've killed
> this in the i915 modeset rewrite and we didn't really have angry users
> scaling our walls. But I'm not sure what'll happen if we do this for all
> other drivers.

I've had to look at this again recently, and while I still don't like
my commit, its
not papering over userspace, it might be papering over fbcon :-)

You don't have any hw that operates like this, so I'd be surprised if
you had users falling over,

The problem is if I have a single DAC encoder, with tv-out and VGA
connectors, and I unplug the VGA connector, and plug in the tv
connector, how do I get fbcon to pop-up,

Though that said this commit caused a regression that I'm not sure I
liked either, since I think we used to allow you to force a mode on
disconnected outputs, and this stops that from working, I noticed in a
virtual env.

Dave.

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

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

Sandeep  changed:

   What|Removed |Added

  Attachment #53616|0   |1
is obsolete||

--- Comment #14 from Sandeep  ---
Created attachment 96754
  --> https://bugs.freedesktop.org/attachment.cgi?id=96754=edit
dmesg_linux_3.13.6_after_suspend_and_resume

dmesg contents for Linux kernel 3.13.6

This was recorded after suspend and resume. After resume, LVDS panel is not
displaying anything (backlight off). Attempts to turn it on manually (using
xrandr) did not work.

-- 
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/20140402/b7221e41/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #48 from Swoorup  ---
I got the same issue here. 

After I suspend my machine and try to wake up, the screen does not display
anything else. And I'd have to blindly switch to tty terminal and type reboot.

Info:
Linux 3.13.8-1 (Arch linux)
Mesa - 10.1.0

Radeon 7520G

-- 
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/20140402/6b16fbbb/attachment.html>

[Bug 73911] Color Banding on radeon

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

--- Comment #21 from Paula Breton  ---
(In reply to comment #20)
> Created attachment 96751 [details] [review]
> testing patch
> 
> Does this patch help?

unfortunately I can't test it as of now, I don't have enough disk space to
compile the patched kernel. didn't know it would eat up my last 12GB.

-- 
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/20140402/80af0985/attachment.html>

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

On Tue, Apr 1, 2014 at 9:46 PM, Dave Airlie  wrote:
> On Tue, Apr 1, 2014 at 5:45 PM, Daniel Vetter  wrote:
>> commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
>> Author: Dave Airlie 
>> Date:   Mon Aug 31 15:16:30 2009 +1000
>>
>> drm/kms: add explicit encoder disable function and detach harder.
>>
>> For shared tv-out and VGA encoders, we really need to know if
>> the encoder is just being switched off temporarily in blanking
>> or if we are really disabling it hard.
>>
>> Also we need to try harder to disconnect encoders from unused
>> connectors so we can share more efficently.
>>
>> (shared encoders stuff is coming in radeon tv-out support)
>>
>> Signed-off-by: Dave Airlie 
>>
>> To me this always smelled like papering over broken userspace. I've killed
>> this in the i915 modeset rewrite and we didn't really have angry users
>> scaling our walls. But I'm not sure what'll happen if we do this for all
>> other drivers.
>
> I've had to look at this again recently, and while I still don't like
> my commit, its
> not papering over userspace, it might be papering over fbcon :-)
>
> You don't have any hw that operates like this, so I'd be surprised if
> you had users falling over,
>
> The problem is if I have a single DAC encoder, with tv-out and VGA
> connectors, and I unplug the VGA connector, and plug in the tv
> connector, how do I get fbcon to pop-up,
>
> Though that said this commit caused a regression that I'm not sure I
> liked either, since I think we used to allow you to force a mode on
> disconnected outputs, and this stops that from working, I noticed in a
> virtual env.

As discussed on irc I think we should be able to fix the issue with
fbcon by using an atomic modeset. The bug only happens when fbcon
tries to enable the newly plugged-in connector before it disabled the
old one and then can't get at the shared encoder needed to enable
either. If we have atomic modesets the crtc helpers can always first
disable all the unused stuff and then light up the new things, which
should make this work. So imo disabling this hunk as in the patch I've
just sent out looks like the way forward for primary planes and atomic
modeset.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCHv4 04/13] drm/shmobile: Restrict plane loops to only operate on legacy planes