Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver

2013-10-01 Thread Tushar Behera 
On 30 August 2013 12:29, Rahul Sharma rahul.sha...@samsung.com wrote:
 Exynos hdmiphy operations and configs are kept inside
 the hdmi driver. Hdmiphy related code is tightly coupled
 with hdmi IP driver.

 This patche moves hdmiphy related code to hdmiphy driver.
 It will help in cleanly supporting the hdmiphy variations
 in further SoCs.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---

 +static const struct i2c_device_id hdmiphy_id[] = {
 +   { },
 +};
 +

[ snip ]

 +   .id_table   = hdmiphy_id,

This is fixing a regression on v3.12 kernel (same as patch 5/7 in this
series). Would you please split this and send it as a separate patch
for v3.12?

-- 
Tushar Behera
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH/RFC v3 00/19] Common Display Framework

2013-10-01 Thread Tomi Valkeinen 
On 09/08/13 20:14, Laurent Pinchart wrote:
 Hi everybody,
 
 Here's the third RFC of the Common Display Framework.


Hi,

I've been trying to adapt the latest CDF RFC for OMAP. I'm trying to gather
some notes here about what I've discovered or how I see things. Some of these I
have mentioned earlier, but I'm trying to collect them here nevertheless.

I do have my branch with working DPI panel, TFP410 encoder, DVI-connector and
DSI command mode panel drivers, and modifications to make omapdss work with
CDF.  However, it's such a big hack, that I'm not going to post it. I hope I
will have time to work on it to get something publishable to have something
more concrete to present. But for the time being I have to move to other tasks
for a while, so I thought I'd better post some comments when I still remember
something about this.

Using Linux buses for DBI/DSI
=

I still don't see how it would work. I've covered this multiple times in
previous posts so I'm not going into more details now.

I implemented DSI (just command mode for now) as a video bus but with bunch of
extra ops for sending the control messages.

Call model
==

It may be that I just don't get how things are supposed to work with the RFC's
ops, but I couldn't figure out how to use it in practice. I tried it for a few
days, but got nowhere, and I then went with the proven model that's used in
omapdss, where display entities handle calling the ops of the upstream
entities.

That's not to say the RFC's model doesn't work. I just didn't figure it out.
And I guess it was more difficult to understand how to use it as the controller
stuff is not implemented yet.

It would be good to have a bit more complex cases in the RFC, like changing and
verifying videomodes, fetching them via EDID, etc.

Multiple inputs/outputs
===

I think changing the model from single-input  single output to multiple inputs
and outputs increases the difficulty of the implementation considerably. That's
not a complaint as such, just an observation. I do think multiple inputs 
outputs is a good feature. Then again, all the use cases I have only have
single input/output, so I've been wondering if there's some middle road, in
which we somehow allow multiple inputs  outputs, but only implement the
support for single input  output.

I've cut the corners in my tests by just looking at a single enabled input or
output from an entity, and ignoring the rest (which I don't have in my use
cases).

Internal connections


The model currently only represents connections between entities. With multiple
inputs  outputs I think it's important to maintain also connections inside the
entity. Say, we have an entity with two inputs and two outputs. If one output
is enabled, which one of the inputs needs to be enabled and configured also?
The current model doesn't give any solution to that.

I haven't implemented this, as in my use cases I have just single inputs and
outputs, so I can follow the pipeline trivially.

Central entity
==

If I understand the RFC correctly, there's a central entity that manages all
other entities connected to it. This central entity would normally be the
display controller. I don't like this model, as it makes it difficult or
impossible to manage situations where an entity is connected to two display
controllers (even if only one of the display controllers would be connected at
a time). It also makes this one display entity fundamentally different from the
others, which I don't like.

I think all the display entities should be similar. They would all register
themselves to the CDF framework, which in turn would be used by somebody. This
somebody could be the display controller driver, which is more or less how I've
implemented it.

Media entity/pads
=

Using media_entity and media_pad fits quite well for CDF, but... It is quite
cumbersome to use. The constant switching between media_entity and
display_entity needs quite a lot of code in total, as it has to be done almost
everywhere.

And somehow I'd really like to combine the entity and port into one struct so
that it would be possible to just do:

src-ops-foo(src, ...);

instead of

src-ops-foo(src, srcport, ...);

One reason is that the latter is more verbose (not only the call, you also need
to get srcport from somewhere), but also that as far as the caller is
concerned, there's no reason to manage the entity and the port as separate
things. You just want a particular video source/sink to do something, and
whether that source/sink is port 5 of entity foo is irrelevant.

The callee, of course, needs to check which port is being operated. However,
if, say, 90% of the display entities have just one input and one output port,
the port parameter can be ignored for those entities, simplifying the code.

And while media_entity can be embedded into display_entity, media_pad and
media_link cannot be embedded into anything.

Re: [Intel-gfx] [PATCH 2/3] drm/i915/dp: use drm_edid_duplicate

2013-10-01 Thread Jani Nikula 
On Tue, 01 Oct 2013, Dave Airlie airl...@gmail.com wrote:
 Did you compile or boot this? I get a warning since you are using edid
 uninitialised, I guess you meant to duplicate intel_connector-edid.

Hi Dave, quite embarrassing, I thought I did, obviously didn't. Updated
patch follows.


BR,
Jani.



 Dave.

  drivers/gpu/drm/i915/intel_dp.c |8 +---
  1 file changed, 1 insertion(+), 7 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c 
 b/drivers/gpu/drm/i915/intel_dp.c
 index 95a3159..aed9d67 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -2920,18 +2920,12 @@ intel_dp_get_edid(struct drm_connector *connector, 
 struct i2c_adapter *adapter)
 /* use cached edid if we have one */
 if (intel_connector-edid) {
 struct edid *edid;
 -   int size;

 /* invalid edid */
 if (IS_ERR(intel_connector-edid))
 return NULL;

 -   size = (intel_connector-edid-extensions + 1) * EDID_LENGTH;
 -   edid = kmemdup(intel_connector-edid, size, GFP_KERNEL);
 -   if (!edid)
 -   return NULL;
 -
 -   return edid;
 +   return drm_edid_duplicate(edid);
 }

 return drm_get_edid(connector, adapter);
 --
 1.7.9.5

 ___
 Intel-gfx mailing list
 intel-...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/dp: use drm_edid_duplicate

2013-10-01 Thread Jani Nikula 
v2: duplicate intel_connector-edid, not uninitialized edid (Dave Airlie).

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5614365..6030394 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2969,19 +2969,11 @@ intel_dp_get_edid(struct drm_connector *connector, 
struct i2c_adapter *adapter)
 
/* use cached edid if we have one */
if (intel_connector-edid) {
-   struct edid *edid;
-   int size;
-
/* invalid edid */
if (IS_ERR(intel_connector-edid))
return NULL;
 
-   size = (intel_connector-edid-extensions + 1) * EDID_LENGTH;
-   edid = kmemdup(intel_connector-edid, size, GFP_KERNEL);
-   if (!edid)
-   return NULL;
-
-   return edid;
+   return drm_edid_duplicate(intel_connector-edid);
}
 
return drm_get_edid(connector, adapter);
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69983] [r600g, bisected] Screen corruption in Firefox and World of Warcraft

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69983

--- Comment #6 from Michel Dänzer mic...@daenzer.net ---
Have you tried a clean build, i.e. after at least make clean?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69983] [r600g, bisected] Screen corruption in Firefox and World of Warcraft

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69983

--- Comment #7 from Chris Rankin ranki...@googlemail.com ---
(In reply to comment #6)
 Have you tried a clean build, i.e. after at least make clean?

When I bisected this, I was performing make distclean each time.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Use of pci_map_page in nouveau, radeon TTM.

2013-10-01 Thread Thomas Hellstrom 

On 10/01/2013 12:34 PM, Lucas Stach wrote:

Am Dienstag, den 01.10.2013, 12:16 +0200 schrieb Thomas Hellstrom:

Jerome, Konrad

Forgive an ignorant question, but it appears like both Nouveau and
Radeon may use pci_map_page() when populating TTMs on
pages obtained using the ordinary (not DMA pool). These pages will, if I
understand things correctly, not be pages allocated with
DMA_ALLOC_COHERENT.

  From what I understand, at least for the corresponding dma_map_page()
it's illegal for the CPU to access these pages without calling
dma_sync_xx_for_cpu(). And before the device is allowed to access them
again, you need to call dma_sync_xx_for_device().
So mapping for PCI really invalidates the TTM interleaved CPU / device
access model.


That's right. The API says you need to sync for device or cpu, but on
x86 you can get away with not doing so, as on x86 the calls end up just
being WB buffer flushes.


OK, but what about the cases where the dma subsystem allocates a bounce 
buffer?

(Although I think the TTM page selection works around this situation).
Perhaps at the very least this deserves a comment in the code...


For ARM, or similar non-coherent arches you absolutely have to do the
syncs, or you'll end up with different contents in cache vs sysram. For
my nouveau on ARM work I introduced some simple helpers to do the right
thing. And it really isn't hard doing the syncs at the right points in
time, just sync for CPU when getting a cpu_prep ioctl and then sync for
device when validating a buffer for GPU use.


Yes, this will probably work for drivers where a buffer is either bound 
for CPU or for GPU,
however, on drivers using user-space sub-allocation of buffers, or for 
partial updates of
vertex buffers etc. that isn't sufficient. In that case one either has 
to use coherent memory
or implement an elaborate scheme where we sync for device and kill 
user-space mappings on validation and
sync for cpu in the cpu fault handler. Unfortunately the latter triggers 
a fence wait for the

whole buffer, not just the part of the buffer we want to write to.


Regards,
Lucas


Regards,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69983] [r600g, bisected] Screen corruption in Firefox and World of Warcraft

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69983

--- Comment #8 from Jos van Wolput wol...@onsneteindhoven.nl ---
(In reply to comment #6)
 Have you tried a clean build, i.e. after at least make clean?

Yes, I did make clean to get a clean build.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60858] [radeon HD 4570m] Error setting UVD clocks

2013-10-01 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60858

--- Comment #17 from Pinak Ahuja pinak.ah...@gmail.com ---
Would it be useful to look into the clock calculation code or is my BIOS buggy?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Use of pci_map_page in nouveau, radeon TTM.

2013-10-01 Thread Lucas Stach 
Am Dienstag, den 01.10.2013, 13:13 +0200 schrieb Thomas Hellstrom:
 On 10/01/2013 12:34 PM, Lucas Stach wrote:
  Am Dienstag, den 01.10.2013, 12:16 +0200 schrieb Thomas Hellstrom:
  Jerome, Konrad
 
  Forgive an ignorant question, but it appears like both Nouveau and
  Radeon may use pci_map_page() when populating TTMs on
  pages obtained using the ordinary (not DMA pool). These pages will, if I
  understand things correctly, not be pages allocated with
  DMA_ALLOC_COHERENT.
 
From what I understand, at least for the corresponding dma_map_page()
  it's illegal for the CPU to access these pages without calling
  dma_sync_xx_for_cpu(). And before the device is allowed to access them
  again, you need to call dma_sync_xx_for_device().
  So mapping for PCI really invalidates the TTM interleaved CPU / device
  access model.
 
  That's right. The API says you need to sync for device or cpu, but on
  x86 you can get away with not doing so, as on x86 the calls end up just
  being WB buffer flushes.
 
 OK, but what about the cases where the dma subsystem allocates a bounce 
 buffer?
 (Although I think the TTM page selection works around this situation).
 Perhaps at the very least this deserves a comment in the code...

Not doing the the sync_for_* is always a violation of the dma-mapping
API and will rightfully fail on systems relying on those mechanisms to
do proper dma memory handling, bounce buffers are just one of those
cases.

 
  For ARM, or similar non-coherent arches you absolutely have to do the
  syncs, or you'll end up with different contents in cache vs sysram. For
  my nouveau on ARM work I introduced some simple helpers to do the right
  thing. And it really isn't hard doing the syncs at the right points in
  time, just sync for CPU when getting a cpu_prep ioctl and then sync for
  device when validating a buffer for GPU use.
 
 Yes, this will probably work for drivers where a buffer is either bound 
 for CPU or for GPU,
 however, on drivers using user-space sub-allocation of buffers, or for 
 partial updates of
 vertex buffers etc. that isn't sufficient. In that case one either has 
 to use coherent memory
 or implement an elaborate scheme where we sync for device and kill 
 user-space mappings on validation and
 sync for cpu in the cpu fault handler. Unfortunately the latter triggers 
 a fence wait for the
 whole buffer, not just the part of the buffer we want to write to.
 
Yeah, either you have to use dma coherent memory, or implement some
scheme where you only sync subregions of a buffer. Though having to call
a cpu_prepare_subbuffer ioctl might just kill all benefits you got from
using userspace suballocation. So using coherent mem for those buffers
seems like a safe bet.

I already implemented some of this in the nouveau nv50 MESA driver which
uses userspace suballocation, but unfortunately I can't do any serious
performance measurements, as the system setup has other unrelated
bottlenecks.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #140 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #139)
 
 I tried exiting early out of a few other functions like rv6xx_dpm_init, but
 haven't had any better results.  I put a printk statement in _init, which
 never got printed.. Could we never make it there?  I couldn't find anything
 that comes before _init...

rv6xx_dpm_init() doesn't actually touch the hw, it just initializes the driver
structures used by dpm.  Try returning early in rv6xx_setup_asic().

The order at module load time looks like:

dpm_init()
dpm_setup_asic()
dpm_enable()
dpm_set_power_state()

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Prevent use of uninitialised values whilst loading edid firmware

2013-10-01 Thread Chris Wilson 
 CC  drivers/gpu/drm/drm_edid_load.o
drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’: 
include/linux/err.h:39:17: warning: ‘edid’ may be used uninitialised in this 
function [-Wuninitialized]
drivers/gpu/drm/drm_edid_load.c:141:22: note: ‘edid’ was declared here

In the process, we can make the error handling more resilient.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/drm_edid_load.c |   75 +--
 1 file changed, 32 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 271b42b..4b57a4c 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -136,59 +136,51 @@ static u8 generic_edid[GENERIC_EDIDS][128] = {
 static u8 *edid_load(struct drm_connector *connector, const char *name,
const char *connector_name)
 {
-   const struct firmware *fw;
+   const struct firmware *fw = NULL;
struct platform_device *pdev;
-   u8 *fwdata = NULL, *edid, *new_edid;
-   int fwsize, expected;
-   int builtin = 0, err = 0;
+   u8 *fwdata, *edid;
+   int fwsize, expected, err, builtin;
int i, valid_extensions = 0;
bool print_bad_edid = !connector-bad_edid_counter || (drm_debug  
DRM_UT_KMS);
 
pdev = platform_device_register_simple(connector_name, -1, NULL, 0);
-   if (IS_ERR(pdev)) {
-   DRM_ERROR(Failed to register EDID firmware platform device 
-   for connector \%s\\n, connector_name);
-   err = -EINVAL;
-   goto out;
-   }
-
-   err = request_firmware(fw, name, pdev-dev);
-   platform_device_unregister(pdev);
+   if (!IS_ERR(pdev)) {
+   err = request_firmware(fw, name, pdev-dev);
+   platform_device_unregister(pdev);
+   } else
+   err = PTR_ERR(pdev);
 
-   if (err) {
+   if (err == 0) {
+   fwdata = (u8 *)fw-data;
+   fwsize = fw-size;
+   builtin = 0;
+   } else {
i = 0;
while (i  GENERIC_EDIDS  strcmp(name, generic_edid_name[i]))
i++;
-   if (i  GENERIC_EDIDS) {
-   err = 0;
-   builtin = 1;
-   fwdata = generic_edid[i];
-   fwsize = sizeof(generic_edid[i]);
+   if (i = GENERIC_EDIDS) {
+   DRM_ERROR(Requesting EDID firmware \%s\ failed 
(err=%d)\n,
+   name, err);
+   edid = ERR_PTR(err);
+   goto out;
}
-   }
 
-   if (err) {
-   DRM_ERROR(Requesting EDID firmware \%s\ failed (err=%d)\n,
-   name, err);
-   goto out;
-   }
-
-   if (fwdata == NULL) {
-   fwdata = (u8 *) fw-data;
-   fwsize = fw-size;
+   fwdata = generic_edid[i];
+   fwsize = sizeof(generic_edid[i]);
+   builtin = 1;
}
 
expected = (fwdata[0x7e] + 1) * EDID_LENGTH;
if (expected != fwsize) {
DRM_ERROR(Size of EDID firmware \%s\ is invalid 
(expected %d, got %d)\n, name, expected, (int) fwsize);
-   err = -EINVAL;
+   edid = ERR_PTR(-EINVAL);
goto relfw_out;
}
 
edid = kmemdup(fwdata, fwsize, GFP_KERNEL);
if (edid == NULL) {
-   err = -ENOMEM;
+   edid = ERR_PTR(-ENOMEM);
goto relfw_out;
}
 
@@ -197,7 +189,7 @@ static u8 *edid_load(struct drm_connector *connector, const 
char *name,
DRM_ERROR(Base block of EDID firmware \%s\ is invalid ,
name);
kfree(edid);
-   err = -EINVAL;
+   edid = ERR_PTR(-EINVAL);
goto relfw_out;
}
 
@@ -210,19 +202,18 @@ static u8 *edid_load(struct drm_connector *connector, 
const char *name,
}
 
if (valid_extensions != edid[0x7e]) {
+   u8 *new_edid;
+
edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
DRM_INFO(Found %d valid extensions instead of %d in EDID data 
\%s\ for connector \%s\\n, valid_extensions,
edid[0x7e], name, connector_name);
edid[0x7e] = valid_extensions;
+
new_edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,
-   GFP_KERNEL);
-   if (new_edid == NULL) {
-   err = -ENOMEM;
-   kfree(edid);
-   goto relfw_out;
-   }
-   edid = new_edid;
+   GFP_KERNEL);
+   if (new_edid)
+   edid = new_edid;
}
 
DRM_INFO(Got %s

[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69723

--- Comment #11 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #10)
 Just to be sure: vddc is associated only to sclk and vddci to mclk, right?
 

Not exactly.  Mclk is tied to vddci (memory interface voltage), but both mclk
and sclk (and the core display clock) are tied to vddc (core voltage).

 Also, how are a new freq and a new voltage applied to the card? Are they
 applied simultanously or sequentially? In the second case, we must be sure
 to raise voltage before frequency when pushing the performances up, while we
 should low the frequency before lowering the voltage when we are slowing
 down.

The actual adjustments are done by a microcontroller on the GPU.  You pass a
set of structures defining the performance levels within the power state to the
microcontroller and the microcontroller handles the switching.  It takes into
account all of the ordering and chip state dependencies.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 7/9] drm/i915: Add 180 degree sprite rotation support

2013-10-01 Thread ville . syrjala 
From: Ville Syrjälä ville.syrj...@linux.intel.com

The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.

The upper layers are not yet plugged in.

v2: HSW handles the rotated buffer offset automagically

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_sprite.c | 37 +
 3 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 96fd2ce..ca5cc60 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3518,6 +3518,7 @@
 #define   DVS_YUV_ORDER_UYVY   (116)
 #define   DVS_YUV_ORDER_YVYU   (216)
 #define   DVS_YUV_ORDER_VYUY   (316)
+#define   DVS_ROTATE_180   (115)
 #define   DVS_DEST_KEY (12)
 #define   DVS_TRICKLE_FEED_DISABLE (114)
 #define   DVS_TILED(110)
@@ -3588,6 +3589,7 @@
 #define   SPRITE_YUV_ORDER_UYVY(116)
 #define   SPRITE_YUV_ORDER_YVYU(216)
 #define   SPRITE_YUV_ORDER_VYUY(316)
+#define   SPRITE_ROTATE_180(115)
 #define   SPRITE_TRICKLE_FEED_DISABLE  (114)
 #define   SPRITE_INT_GAMMA_ENABLE  (113)
 #define   SPRITE_TILED (110)
@@ -3661,6 +3663,7 @@
 #define   SP_YUV_ORDER_UYVY(116)
 #define   SP_YUV_ORDER_YVYU(216)
 #define   SP_YUV_ORDER_VYUY(316)
+#define   SP_ROTATE_180(115)
 #define   SP_TILED (110)
 #define _SPALINOFF (VLV_DISPLAY_BASE + 0x72184)
 #define _SPASTRIDE (VLV_DISPLAY_BASE + 0x72188)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9173baa..d9882e5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -370,6 +370,7 @@ struct intel_plane {
unsigned int crtc_w, crtc_h;
uint32_t src_x, src_y;
uint32_t src_w, src_h;
+   unsigned int rotation;
 
/* Since we need to change the watermarks before/after
 * enabling/disabling the planes, we need to store the parameters here
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index e001d2c..a23f8bd 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -60,6 +60,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
sprctl = ~SP_PIXFORMAT_MASK;
sprctl = ~SP_YUV_BYTE_ORDER_MASK;
sprctl = ~SP_TILED;
+   sprctl = ~SP_ROTATE_180;
 
switch (fb-pixel_format) {
case DRM_FORMAT_YUYV:
@@ -128,6 +129,14 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
fb-pitches[0]);
linear_offset -= sprsurf_offset;
 
+   if (intel_plane-rotation == BIT(DRM_ROTATE_180)) {
+   sprctl |= SP_ROTATE_180;
+
+   x += src_w;
+   y += src_h;
+   linear_offset += src_h * fb-pitches[0] + src_w * pixel_size;
+   }
+
if (obj-tiling_mode != I915_TILING_NONE)
I915_WRITE(SPTILEOFF(pipe, plane), (y  16) | x);
else
@@ -233,6 +242,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
sprctl = ~SPRITE_RGB_ORDER_RGBX;
sprctl = ~SPRITE_YUV_BYTE_ORDER_MASK;
sprctl = ~SPRITE_TILED;
+   sprctl = ~SPRITE_ROTATE_180;
 
switch (fb-pixel_format) {
case DRM_FORMAT_XBGR:
@@ -304,6 +314,17 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
   pixel_size, fb-pitches[0]);
linear_offset -= sprsurf_offset;
 
+   if (intel_plane-rotation == BIT(DRM_ROTATE_180)) {
+   sprctl |= SPRITE_ROTATE_180;
+
+   /* HSW does this automagically in hardware */
+   if (!IS_HASWELL(dev)) {
+   x += src_w;
+   y += src_h;
+   linear_offset += src_h * fb-pitches[0] + src_w * 
pixel_size;
+   }
+   }
+
/* HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET
 * register */
if (IS_HASWELL(dev))
@@ -429,6 +450,7 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
dvscntr = ~DVS_RGB_ORDER_XBGR;
dvscntr = ~DVS_YUV_BYTE_ORDER_MASK;
dvscntr = ~DVS_TILED;
+   dvscntr = ~DVS_ROTATE_180;
 
switch (fb-pixel_format) {
case DRM_FORMAT_XBGR:
@@ -482,6 +504,14 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
   pixel_size, fb-pitches[0]);
linear_offset -= dvssurf_offset;
 
+   if (intel_plane-rotation ==

[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69723

--- Comment #12 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #11)
 (In reply to comment #10)
  Just to be sure: vddc is associated only to sclk and vddci to mclk, right?
  
 
 Not exactly.  Mclk is tied to vddci (memory interface voltage), but both
 mclk and sclk (and the core display clock) are tied to vddc (core voltage).
 
  Also, how are a new freq and a new voltage applied to the card? Are they
  applied simultanously or sequentially? In the second case, we must be sure
  to raise voltage before frequency when pushing the performances up, while we
  should low the frequency before lowering the voltage when we are slowing
  down.
 
 The actual adjustments are done by a microcontroller on the GPU.  You pass a
 set of structures defining the performance levels within the power state to
 the microcontroller and the microcontroller handles the switching.  It takes
 into account all of the ordering and chip state dependencies.

I was asking, just in case there was a manual control over the process and I
would have been in a situation where the card was too near of its limits.

I changed a little something in the code yesterday and I was lucky enough to
not have any hangs. I just want to be sure it is because of this little change
I've made and not some obscure planets alignment. I'll test it further today
and I'll let you know.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] tty/vt: add con_bind and con_unbind functions

2013-10-01 Thread Ville Syrjälä 
On Thu, Sep 26, 2013 at 08:06:00PM -0300, Paulo Zanoni wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com
 
 The consoles who need to do something when unbinding or binding can
 optionally implement these functions.
 
 The current problem I'm trying to solve is that when i915+fbcon is
 loaded on Haswell, if we disable the power well (to save power) the
 VGA interface gets completely disabled, so when we unbind fbcon we
 need to restore the VGA interface to allow vgacon to work.

We don't need to make it work. No one else does, and in the general case
it's even impossible since on some hardware that would definitely
corrupt the state that the real driver is attempting to use. The only
case where it might be nice to restore vgacon is on i915 unload, but no
one else does that either AFAIK, so I would not waste any cycles on
attempting that.

 
 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/tty/vt/vt.c | 6 ++
  include/linux/console.h | 2 ++
  2 files changed, 8 insertions(+)
 
 diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
 index 9a8e8c5..beb5986 100644
 --- a/drivers/tty/vt/vt.c
 +++ b/drivers/tty/vt/vt.c
 @@ -3014,6 +3014,9 @@ static int do_bind_con_driver(const struct consw *csw, 
 int first, int last,
   if (retval)
   goto err;
  
 + if (csw-con_bind)
 + csw-con_bind();
 +
   if (!(con_driver-flag  CON_DRIVER_FLAG_INIT)) {
   csw-con_startup();
   con_driver-flag |= CON_DRIVER_FLAG_INIT;
 @@ -3152,6 +3155,9 @@ int do_unbind_con_driver(const struct consw *csw, int 
 first, int last, int deflt
   if (!con_is_bound(csw))
   goto err;
  
 + if (csw-con_unbind)
 + csw-con_unbind();
 +
   first = max(first, con_driver-first);
   last = min(last, con_driver-last);
  
 diff --git a/include/linux/console.h b/include/linux/console.h
 index 7571a16..5cd2c35 100644
 --- a/include/linux/console.h
 +++ b/include/linux/console.h
 @@ -65,6 +65,8 @@ struct consw {
* Restore the console to its pre-debug state as closely as possible.
*/
   int (*con_debug_leave)(struct vc_data *);
 + void(*con_bind)(void);
 + void(*con_unbind)(void);
  };
  
  extern const struct consw *conswitchp;
 -- 
 1.8.3.1
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Use of pci_map_page in nouveau, radeon TTM.

2013-10-01 Thread Konrad Rzeszutek Wilk 
On Tue, Oct 01, 2013 at 12:16:16PM +0200, Thomas Hellstrom wrote:
 Jerome, Konrad
 
 Forgive an ignorant question, but it appears like both Nouveau and
 Radeon may use pci_map_page() when populating TTMs on
 pages obtained using the ordinary (not DMA pool). These pages will,
 if I understand things correctly, not be pages allocated with
 DMA_ALLOC_COHERENT.

Not always. That depends if the SWIOTLB buffer has been enabled.
Which happens if you have Calgary IOMMU, AMD GART and if you
run under Xen.
 
 From what I understand, at least for the corresponding
 dma_map_page() it's illegal for the CPU to access these pages
 without calling
 dma_sync_xx_for_cpu(). And before the device is allowed to access
 them again, you need to call dma_sync_xx_for_device().

Correct.

 So mapping for PCI really invalidates the TTM interleaved CPU /
 device access model.

Unless you use the TTM DMA one which allocates them from the
coherent pool - in which case they are already mapped.

Granted the part of using DMA export/import API is not finished
(so moving from TTM pool to a V4L for example) and it will blow
up with the right mix.
 
 Or did I miss something here?

That is it. But for most of the use cases the drivers have been
able to skirt this restriction b/c the pci_map_page/pci_unmap_page
setup a DMA mapping that is static (until the pci_unmap_page) and
on x86 the memory is coherent. So the map is good irregardless
of the PCI devices. Naturally if you have multitple IOMMUs per bridge
this all falls apart :-(

This all falls flat also with non-coherent memory and I believe
that is what some of the PA-RISC folks are hitting their heads
against.

And probably also on ARM once they start using these chipsets.

 
 Thanks,
 Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-intel 3D support

2013-10-01 Thread Daniel Vetter 
On Tue, Oct 1, 2013 at 4:54 PM, LECOUSIN Etienne etienne.lecou...@maatel.fr
 wrote:

 I’m very interrested by Diamen Lespiau’s work on intel 3D support,
 including intel-gpu-tools and drm.

 I’ve seen that his work will be merged in the next linux kernel revision,
 is that mean that it will be for the 3.12 final kernel ? else which one and
 when do you expect it ?


It's already in the linux-next tree and should show up in Dave Airlie's
drm-next tree in about 2 weeks. It'll land (presuming nothing really
terrible shows up) in 3.13.

Cheers, Daniel

PS: Please always cc: mailing lists so that googleother people can also
see your question.
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64649] Anomaly 2 (Steam) exits with divide by 0 in r600g

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=64649

Kai k...@dev.carbon-project.org changed:

   What|Removed |Added

  Attachment #79573|0   |1
is obsolete||

--- Comment #19 from Kai k...@dev.carbon-project.org ---
Created attachment 86915
  -- https://bugs.freedesktop.org/attachment.cgi?id=86915action=edit
Full GDB backtrace for Anomaly 2 (2013-10-02)

Still an issue with current Git HEAD on an X.org 1.14.2 (ie. with OpenGL 3.1
available).

The stack is:
Kernel: 3.11.2
libdrm: 2.4.46
Mesa: master/aac75f877da1d106f6fd7bbd238d1d1d35a0c8e8
X.Org: 1.14.2

Current dmesg output is:
 traps: Renderer[12757] trap divide error ip:f53c1896 sp:f0bfede0 error:0 in 
 r600_dri.so[f4f06000+11a]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [libdrm] Stereo 3D v3

2013-10-01 Thread Damien Lespiau 
On Mon, Sep 30, 2013 at 01:41:13PM +0100, Damien Lespiau wrote:
 The kernel series has been pushed to drm-intel, the libdrm patches should
 follow if there isn't any objection.

Swiftly pushed.

-- 
Damien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69922] Juniper (HD 5770): Hibernate partially broken since LInux kernel 3.10

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69922

--- Comment #1 from Alex Deucher ag...@yahoo.com ---
Please attach your xorg log and dmesg output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Prevent use of uninitialised values whilst loading edid firmware

2013-10-01 Thread Chris Wilson 
On Tue, Oct 01, 2013 at 06:49:42PM +0300, Ville Syrjälä wrote:
 On Tue, Oct 01, 2013 at 02:06:13PM +0100, Chris Wilson wrote:
   CC  drivers/gpu/drm/drm_edid_load.o
  drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’: 
  include/linux/err.h:39:17: warning: ‘edid’ may be used uninitialised in 
  this function [-Wuninitialized]
  drivers/gpu/drm/drm_edid_load.c:141:22: note: ‘edid’ was declared here
  
  In the process, we can make the error handling more resilient.
  
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  ---
   drivers/gpu/drm/drm_edid_load.c |   75 
  +--
   1 file changed, 32 insertions(+), 43 deletions(-)
  
  diff --git a/drivers/gpu/drm/drm_edid_load.c 
  b/drivers/gpu/drm/drm_edid_load.c
  index 271b42b..4b57a4c 100644
  --- a/drivers/gpu/drm/drm_edid_load.c
  +++ b/drivers/gpu/drm/drm_edid_load.c
  @@ -136,59 +136,51 @@ static u8 generic_edid[GENERIC_EDIDS][128] = {
   static u8 *edid_load(struct drm_connector *connector, const char *name,
  const char *connector_name)
   {
  -   const struct firmware *fw;
  +   const struct firmware *fw = NULL;
  struct platform_device *pdev;
  -   u8 *fwdata = NULL, *edid, *new_edid;
  -   int fwsize, expected;
  -   int builtin = 0, err = 0;
  +   u8 *fwdata, *edid;
 
 Orthogonal issue, but fwdata, generic_edid and generic_edid_names could
 all be const.
 
  +   int fwsize, expected, err, builtin;
  int i, valid_extensions = 0;
  bool print_bad_edid = !connector-bad_edid_counter || (drm_debug  
  DRM_UT_KMS);
   
  pdev = platform_device_register_simple(connector_name, -1, NULL, 0);
  -   if (IS_ERR(pdev)) {
  -   DRM_ERROR(Failed to register EDID firmware platform device 
  -   for connector \%s\\n, connector_name);
  -   err = -EINVAL;
  -   goto out;
  -   }
  -
  -   err = request_firmware(fw, name, pdev-dev);
  -   platform_device_unregister(pdev);
  +   if (!IS_ERR(pdev)) {
  +   err = request_firmware(fw, name, pdev-dev);
  +   platform_device_unregister(pdev);
  +   } else
  +   err = PTR_ERR(pdev);
   
  -   if (err) {
  +   if (err == 0) {
  +   fwdata = (u8 *)fw-data;
  +   fwsize = fw-size;
  +   builtin = 0;
  +   } else {
  i = 0;
  while (i  GENERIC_EDIDS  strcmp(name, generic_edid_name[i]))
  i++;
  -   if (i  GENERIC_EDIDS) {
  -   err = 0;
  -   builtin = 1;
  -   fwdata = generic_edid[i];
  -   fwsize = sizeof(generic_edid[i]);
  +   if (i = GENERIC_EDIDS) {
  +   DRM_ERROR(Requesting EDID firmware \%s\ failed 
  (err=%d)\n,
  +   name, err);
  +   edid = ERR_PTR(err);
  +   goto out;
 
 Due to the 'if (fw)' check in the cleanup code, you could eliminate
 the out label.
 
  }
  -   }
   
  -   if (err) {
  -   DRM_ERROR(Requesting EDID firmware \%s\ failed (err=%d)\n,
  -   name, err);
  -   goto out;
  -   }
  -
  -   if (fwdata == NULL) {
  -   fwdata = (u8 *) fw-data;
  -   fwsize = fw-size;
  +   fwdata = generic_edid[i];
  +   fwsize = sizeof(generic_edid[i]);
  +   builtin = 1;
  }
   
  expected = (fwdata[0x7e] + 1) * EDID_LENGTH;
 
 Not your bug, but we're missing a check for fwsize  0x7e.
 
 Can't spot any real bugs, so w/ or w/o the out label idea:
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

Might as well spend the time to fix up the little warts whilst we are
here, so expect a v2 shortly.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69961] Regression: Xserver fails to start

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69961

--- Comment #5 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #4)
 I am getting segmentation fault on startx after building glamor with

That looks like https://bugs.freedesktop.org/show_bug.cgi?id=69463#c7 though,
not related to the glamor_xv_init issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts

2013-10-01 Thread Peter Hurley 

On 09/30/2013 01:27 PM, Peter Hurley wrote:

On 09/03/2013 09:45 PM, Ben Skeggs wrote:

Well, we can't just go around breaking stuff deliberately for the
people still using them!

I've blacklisted them myself and merged the patch.


Ben,

This patch causes my dual-head Quadro FX570 (G84) to fail to idle when
dragging a window around.

It loops for the full timeout (15 sec.) in nouveau_gem_ioctl_cpu_prep() --
ie., never reaches required fence sequence #.


FWIW, I can get the binary 319.32 driver to run this hardware
with MSIs on [1] and not crash in similar circumstances.

But repeating the testing on 3.12.0-rc2/3 has proved challenging.
Although I have the binary driver running on 3.12.0-rc2, the
userspace won't fully come up and I haven't figured out why
(it's an old userspace that I don't use regularly, so it could
be some other problem).

Regards,
Peter Hurley

[1] lspci -vvv -nn on 3.2.x

02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84GL [Quadro FX 
570] [10de:040e] (rev a1) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation Device [10de:0474]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 94
Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at c000 (64-bit, prefetchable) [size=256M]
Region 3: Memory at dc00 (64-bit, non-prefetchable) [size=32M]
Region 5: I/O ports at cc80 [size=128]
[virtual] Expansion ROM at dfc0 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: fee1100c  Data: 41c9
Capabilities: [78] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 512ns, L1 
4us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ 
Unsupported-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #8, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 
512ns, L1 4us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- 
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
SpeedDis-, Selectable De-emphasis: -6dB
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100 v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed- WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [128 v1] Power Budgeting ?
Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 
?
Kernel driver in use: nvidia
Kernel modules: nvidia_319_updates, nouveau, nvidiafb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69723

--- Comment #13 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #12)
 (In reply to comment #11)
  (In reply to comment #10)
   Just to be sure: vddc is associated only to sclk and vddci to mclk, right?
   
  
  Not exactly.  Mclk is tied to vddci (memory interface voltage), but both
  mclk and sclk (and the core display clock) are tied to vddc (core voltage).
  
   Also, how are a new freq and a new voltage applied to the card? Are they
   applied simultanously or sequentially? In the second case, we must be sure
   to raise voltage before frequency when pushing the performances up, while 
   we
   should low the frequency before lowering the voltage when we are slowing
   down.
  
  The actual adjustments are done by a microcontroller on the GPU.  You pass a
  set of structures defining the performance levels within the power state to
  the microcontroller and the microcontroller handles the switching.  It takes
  into account all of the ordering and chip state dependencies.
 
 I was asking, just in case there was a manual control over the process and I
 would have been in a situation where the card was too near of its limits.
 
 I changed a little something in the code yesterday and I was lucky enough to
 not have any hangs. I just want to be sure it is because of this little
 change I've made and not some obscure planets alignment. I'll test it
 further today and I'll let you know.

Well, it was only luck it seems... I'll send a patch though, since it
simplifies a couple of lines.

I'll have to continue digging.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 2/4] drm/tegra: Add runtime pm support for gr2d

2013-10-01 Thread Stephen Warren 
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
 From: Mayuresh Kulkarni mkulka...@nvidia.com
 
 This far we have enabled gr2d clock on device probe and disabled
 it on device deinitialisation. This patch adds runtime pm support
 for the hardware unit allowing dynamic power management. If pm
 runtime is not enabled, gr2d clock is enabled in device probe and

 diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c

 @@ -327,11 +336,48 @@ static int __exit gr2d_remove(struct platform_device 
 *pdev)
   host1x_syncpt_free(gr2d-client.syncpts[i]);
  
   host1x_channel_free(gr2d-channel);
 +
 + if (pm_runtime_enabled(pdev-dev))
 + pm_runtime_disable(pdev-dev);
 + else
 + gr2d_runtime_suspend(pdev-dev);

This code is slightly different to the code in e.g.
sound/soc/tegra/tegra20_i2s.c:remove(), whereas the code in probe() is
identical. I'm not sure whether there's some advantage in this version?
If so, perhaps the sound drivers should be updated to be consistent. If
not, perhaps this driver should do the same thing as the I2S driver, so
we keep the drivers consistent, and provide the same example code
everywhere.

 +static int gr2d_runtime_suspend(struct device *dev)
 +{
 + struct gr2d *gr2d;
 +
 + gr2d = dev_get_drvdata(dev);
 + if (!gr2d)
 + return -EINVAL;

Presumably, gr2d will never be NULL here, unless there's some chronic
bug. Can't we re-write those last 5 lines as simply:

struct gr2d *grd2 = dev_get_drvdata(dev);

If that's not valid, we should probably update the audio drivers (and
perhaps others) too.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/5] drm/i915: redisable VGA when we disable the power well

2013-10-01 Thread Ville Syrjälä 
On Tue, Oct 01, 2013 at 04:47:04PM +0300, Ville Syrjälä wrote:
 On Thu, Sep 26, 2013 at 08:05:58PM -0300, Paulo Zanoni wrote:
  From: Paulo Zanoni paulo.r.zan...@intel.com
  
  VGA whack-a-mole!
  
  We need VGA to be disabled whenever our driver is working. So even
  without reproducible bugs this patch makes sense, but we do have a bug
  solved by this patch.
  
  If you boot a Haswell machine with eDP+HDMI, then kill your display
  manager and run:
  echo 0  /sys/class/vtconsole/vtcon1/bind
  you'll get thousands of unclaimed register messages. Notice that
  since we have eDP+HDMI, the power well is *enabled* when we run the
  command, but if you look at dmesg you'll see that at some point during
  the boot we disabled it and then reenabled it. This patch solves this
  problem.
  
  I didn't do a deep analysis of the problem, but I guess vgacon gets
  seriously confused when it sees that the VGA plane is enabled.
  
  Besides the command above, this problem can also be reproduced by the
  module_reload test from intel-gpu-tools.
  
  Fixes regression introduced by:
  commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
  Author: Paulo Zanoni paulo.r.zan...@intel.com
  drm/i915: switch disable_power_well default value to 1
  
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
  Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
  ---
   drivers/gpu/drm/i915/intel_display.c | 2 +-
   drivers/gpu/drm/i915/intel_drv.h | 1 +
   drivers/gpu/drm/i915/intel_pm.c  | 6 ++
   3 files changed, 8 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 665fa8f..065ffed 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -10232,7 +10232,7 @@ static void intel_init_quirks(struct drm_device 
  *dev)
   }
   
   /* Disable the VGA plane that we never use */
  -static void i915_disable_vga(struct drm_device *dev)
  +void i915_disable_vga(struct drm_device *dev)
   {
  struct drm_i915_private *dev_priv = dev-dev_private;
  u8 sr1;
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index a17a86a..e63646a 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -678,6 +678,7 @@ void
   ironlake_check_encoder_dotclock(const struct intel_crtc_config 
  *pipe_config,
  int dotclock);
   bool intel_crtc_active(struct drm_crtc *crtc);
  +void i915_disable_vga(struct drm_device *dev);
   void i915_disable_vga_mem(struct drm_device *dev);
   
   
  diff --git a/drivers/gpu/drm/i915/intel_pm.c 
  b/drivers/gpu/drm/i915/intel_pm.c
  index 2ac1c2f..7a8af95 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -5329,6 +5329,12 @@ static void __intel_set_power_well(struct drm_device 
  *dev, bool enable)
  if (wait_for((I915_READ(HSW_PWR_WELL_DRIVER) 
HSW_PWR_WELL_STATE_ENABLED), 20))
  DRM_ERROR(Timeout enabling power well\n);
  +
  +   if (I915_READ(i915_vgacntrl_reg(dev)) !=
  +   VGA_DISP_DISABLE) {
  +   i915_disable_vga(dev);
  +   i915_disable_vga_mem(dev);
  +   }
 
 Hmm. That makes no sense.
 
 So somehow the thrice cursed BIOS re-enabled the VGA plane behind our
 back? That really shouldn't cause any problems other than maybe
 corrupting the display or something. In any case it has nothing to do
 with vga resource decode.
 
 The real problem seems to be that vgacon is poking at vga resources we
 apparently decode but can't handle. If your patch really fixes it then
 it would seem to BIOS also enabled VGA memory decode. But that still
 doesn't explain the unclaimed register errors, as that would require
 the power well to be off. But since you say HDMI is enabled, the power
 well must be on as well. So all I can say is wtf?

Actually I tried it on my HSW, and the vga_cntrl reg always comes back
as 0x80002900 after the power well has been off, which is the reset
value. So your code w/ the '!=' comparoson would assume that the VGA plane
is enabled even though it might not be. We should fix all the VGA plane
enabled checks to use '' instead of '!='.

But if your patch actually fixes things, then I guess the BIOS really
must have re-enabled vga memory decode and that's where the errors
are coming from. Otherwise if it's just about vga registers, then
redisabling vga memory decode and vga plane should have no effect on
the outcome.

One idea would be to lift the lid_notify hack from intel_lvds.c and plug
it into eDP and see if that makes a difference...

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 4/4] gpu: host1x: Add runtime pm support for host1x

2013-10-01 Thread Stephen Warren 
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
 From: Mayuresh Kulkarni mkulka...@nvidia.com
 
 This patch adds runtime pm support for host1x hardware unit. This
 allows host1x clock to be turned off when it is idle. If pm runtime
 is not configured, we enable host1x clock in device probe and disable
 it in remove.

 diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c

 +static int host1x_runtime_suspend(struct device *dev);
 +static int host1x_runtime_resume(struct device *dev);

You could avoid having these prototypes by simply putting the function
bodies earlier on in the file, somewhere before they're used. I don't
care much either way, but I've certainly seen some people care about
this and ask for them to be moved.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65611] UVD accelerated decoding causes hangs (ARUBA - HD 7540D)

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=65611

--- Comment #5 from Christian König deathsim...@vodafone.de ---
(In reply to comment #4)
 Still didn't work properly though as XBMC seems to not bother asking the
 driver what it can do and just blindly assumes that every format is
 available...

Which is pretty much the reason why I haven't fixed it so far, you also need to
fix the applications as well. MPEG1 isn't supported either, but pretty much
every application is ignoring the decoder capabilities.

Anyway if you want to write a patch to start fixing those issues feel free to
do so, any help is always welcome.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60858] [radeon HD 4570m] Error setting UVD clocks

2013-10-01 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60858

--- Comment #18 from Christian König christian.koe...@amd.com ---
(In reply to Pinak Ahuja from comment #17)
 Would it be useful to look into the clock calculation code or is my BIOS
 buggy?

The calculation seems to be fine, it's either your BIOS that has incorrect
information or you hardware is wired somehow special.

Anyway I can't find a solution to this problem without access to the hardware,
sorry.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #141 from Bryan Quigley gquigs+b...@gmail.com ---
In /r600_dpm.c - void r600_start_dpm(struct radeon_device *rdev)

+   //return; //returning here works

r600_enable_sclk_control(rdev, true);

+   return; //returning here doesn't.

Will just try setting it to false next..

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #142 from Bryan Quigley gquigs+b...@gmail.com ---
-   r600_enable_sclk_control(rdev, true);
+   r600_enable_sclk_control(rdev, false);
Does indeed fix it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #143 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #142)
 -   r600_enable_sclk_control(rdev, true);
 +   r600_enable_sclk_control(rdev, false);
 Does indeed fix it.

Unfortunately, that disables dynamic engine scaling which on your particular
board pretty much disables dpm since the voltage and mclk are static :(

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69729

--- Comment #25 from pasqual milvaques pasqual.milvaq...@gmail.com ---
Is there any provision about when the patches will be included in the stable
kernel? 3.11.3 is out today and doesn't contain the fix

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69729

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

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

--- Comment #26 from Alex Deucher ag...@yahoo.com ---
Fix went into 3.12 this week.  Should show up in the 3.11 stable series any
time now.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58d327da9721f7a0f6e46c8dfa5cc5546fd7078a

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69671] rv790 hdmi sound regression since fix audio dto calculation on DCE3+ (v3)

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69671

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

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

--- Comment #6 from Alex Deucher ag...@yahoo.com ---
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58d327da9721f7a0f6e46c8dfa5cc5546fd7078a

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63599] [r600] SUMO2 GPU lockup CP stall (kernel 3.2.47, 3.4, 3.8, 3.9, 3.10)

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=63599

--- Comment #29 from wojtek wojta...@wp.pl ---
Created attachment 86938
  -- https://bugs.freedesktop.org/attachment.cgi?id=86938action=edit
sumo2.patch

simple patch that's fix problem on my system :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=57919

--- Comment #22 from Alex Deucher ag...@yahoo.com ---
Created attachment 86939
  -- https://bugs.freedesktop.org/attachment.cgi?id=86939action=edit
possible fix

Does this patch fix the issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70019] New: [RV670] GPU lockup and screen garbage on splash screen and in GNOME

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70019

  Priority: medium
Bug ID: 70019
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [RV670] GPU lockup and screen garbage on splash screen
and in GNOME
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: nikoa...@gmail.com
  Hardware: x86 (IA32)
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 86941
  -- https://bugs.freedesktop.org/attachment.cgi?id=86941action=edit
lspci -vv

While showing splash screen and after logging into Cinnamon in Mint 13.04 with
Mesa, X.org module from git and kernel 3.11.3, there is only garbage on the
screen with log entries about GPU lockup in dmesg.

Software versions:
Kernel 3.11.3 (x86)
linux-firmware 1.113
X.org 1.13.3
xf86-video-radeon 7.2.0+git1310011603.67fb82
Mesa 9.3~git1310011106.eb0a57

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70019] [RV670] GPU lockup and screen garbage on splash screen and in GNOME

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70019

--- Comment #1 from Nikolay Amiantov nikoa...@gmail.com ---
Created attachment 86942
  -- https://bugs.freedesktop.org/attachment.cgi?id=86942action=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70019] [RV670] GPU lockup and screen garbage on splash screen and in GNOME

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70019

--- Comment #3 from Nikolay Amiantov nikoa...@gmail.com ---
Also, it was running with dpm=1 aspm=0 now, but disabling dpm (or removing all
options, which should be the same) doesn't help a bit. ASPM option was tried
just in case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/5] Add some missing bits for exynos5250-snow

2013-10-01 Thread Sean Paul 
This set adds some missing devicetree nodes to the exynos5250-snow file as well
as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in
the exynos5250-snow board.

Sean


Sean Paul (5):
 ARM: dts: Add fimd display-timings for exynos5250-snow
 ARM: dts: Add dp-controller node to exynos5250-snow
 drm/bridge: Add PTN3460 bridge driver
 drm/exynos: Initialize ptn3460 if present
 ARM: dts: Add ptn3460 to exynos5250-snow

Documentation/devicetree/bindings/drm/bridge/ptn3460.txt |  27 
+
arch/arm/boot/dts/exynos5250-snow.dts|  48 

drivers/gpu/drm/Kconfig  |   2 ++
drivers/gpu/drm/Makefile |   1 +
drivers/gpu/drm/bridge/Kconfig   |   4 
drivers/gpu/drm/bridge/Makefile  |   3 +++
drivers/gpu/drm/bridge/ptn3460.c | 349 
+
drivers/gpu/drm/exynos/exynos_drm_core.c |  44 
+++-
include/drm/bridge/ptn3460.h |  36 
+
9 files changed, 513 insertions(+), 1 deletion(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] ARM: dts: Add dp-controller node to exynos5250-snow

2013-10-01 Thread Sean Paul 
This patch adds the dp-controller node to the exynos5250-snow board dts
file.

Signed-off-by: Sean Paul seanp...@chromium.org
---
 arch/arm/boot/dts/exynos5250-snow.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index e5af3f2..780511a 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -190,6 +190,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
 
+   dp-controller {
+   samsung,color-space = 0;
+   samsung,dynamic-range = 0;
+   samsung,ycbcr-coeff = 0;
+   samsung,color-depth = 1;
+   samsung,link-rate = 0x0a;
+   samsung,lane-count = 2;
+
+   pinctrl-names = default;
+   pinctrl-0 = dp_hpd;
+   };
+
fimd: fimd@1440 {
display-timings {
native-mode = lcd_timing;
-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] ARM: dts: Add fimd display-timings for exynos5250-snow

2013-10-01 Thread Sean Paul 
This patch adds the internal panel timings to the exynos5250-snow board
dts file.

Signed-off-by: Sean Paul seanp...@chromium.org
---
 arch/arm/boot/dts/exynos5250-snow.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index e79331d..e5af3f2 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -190,6 +190,23 @@
samsung,vbus-gpio = gpx1 1 0;
};
 
+   fimd: fimd@1440 {
+   display-timings {
+   native-mode = lcd_timing;
+   lcd_timing: 1366x768 {
+   clock-frequency = 70589280;
+   hactive = 1366;
+   vactive = 768;
+   hfront-porch = 40;
+   hback-porch = 40;
+   hsync-len = 32;
+   vback-porch = 10;
+   vfront-porch = 12;
+   vsync-len = 6;
+   };
+   };
+   };
+
fixed-rate-clocks {
xxti {
compatible = samsung,clock-xxti;
-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm/bridge: Add PTN3460 bridge driver

2013-10-01 Thread Sean Paul 
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.

Signed-off-by: Sean Paul seanp...@chromium.org
---
 .../devicetree/bindings/drm/bridge/ptn3460.txt |  27 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/bridge/Kconfig |   4 +
 drivers/gpu/drm/bridge/Makefile|   3 +
 drivers/gpu/drm/bridge/ptn3460.c   | 349 +
 include/drm/bridge/ptn3460.h   |  36 +++
 7 files changed, 422 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
 create mode 100644 drivers/gpu/drm/bridge/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/Makefile
 create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
 create mode 100644 include/drm/bridge/ptn3460.h

diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt 
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+   - compatible: nxp,ptn3460
+   - reg: i2c address of the bridge
+   - powerdown-gpio: OF device-tree gpio specification
+   - reset-gpio: OF device-tree gpio specification
+   - edid-emulation: The EDID emulation entry to use
+   +---++--+
+   | Value | Resolution | Description  |
+   |   0   |  1024x768  | NXP Generic  |
+   |   1   |  1920x1080 | NXP Generic  |
+   |   2   |  1920x1080 | NXP Generic  |
+   |   3   |  1600x900  | Samsung LTM200KT |
+   |   4   |  1920x1080 | Samsung LTM230HT |
+   |   5   |  1366x768  | NXP Generic  |
+   |   6   |  1600x900  | ChiMei M215HGE   |
+   +---++--+
+
+Example:
+   ptn3460-bridge@20 {
+   compatible = nxp,ptn3460;
+   reg = 0x20;
+   powerdown-gpio = gpy2 5 1 0 0;
+   reset-gpio = gpx1 5 1 0 0;
+   edid-emulation = 5;
+   };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
 source drivers/gpu/drm/qxl/Kconfig
 
 source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC)  += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_MSM) += msm/
 obj-y  += i2c/
+obj-y  += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+   tristate PTN3460 DP/LVDS bridge
+   depends on DRM  I2C
+   ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+
+#include drmP.h
+#include drm_edid.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+#include bridge/ptn3460.h
+
+#define PTN3460_EDID_ADDR  0x0
+#define PTN3460_EDID_EMULATION_ADDR0x84
+#define PTN3460_EDID_ENABLE_EMULATION  0
+#define PTN3460_EDID_EMULATION_SELECTION   1
+#define PTN3460_EDID_SRAM_LOAD_ADDR0x85
+
+struct ptn3460_bridge {
+   struct drm_connector connector;
+   struct i2c_client *client;
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;
+   struct edid *edid;
+

[PATCH 4/5] drm/exynos: Initialize ptn3460 if present

2013-10-01 Thread Sean Paul 
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).

Signed-off-by: Sean Paul seanp...@chromium.org
---
 drivers/gpu/drm/exynos/exynos_drm_core.c | 44 +++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
  * option) any later version.
  */
 
+#include linux/of_i2c.h
 #include drm/drmP.h
+#include drm/bridge/ptn3460.h
 #include exynos_drm_drv.h
 #include exynos_drm_encoder.h
 #include exynos_drm_connector.h
@@ -20,6 +22,40 @@
 
 static LIST_HEAD(exynos_drm_subdrv_list);
 
+struct bridge_init {
+   struct i2c_client *client;
+   struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+   bridge-client = NULL;
+   bridge-node = of_find_node_by_name(NULL, name);
+   if (!bridge-node)
+   return false;
+
+   bridge-client = of_find_i2c_device_by_node(bridge-node);
+   if (!bridge-client)
+   return false;
+
+   return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+   struct drm_encoder *encoder)
+{
+   struct bridge_init bridge;
+   int ret;
+
+   if (find_bridge(ptn3460-bridge, bridge)) {
+   ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+   if (!ret)
+   return 1;
+   }
+   return 0;
+}
+
 static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
 {
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device *dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+   subdrv-encoder = encoder;
+
+   if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+   ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+   if (ret)
+   return 0;
+   }
 
/*
 * create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device *dev,
goto err_destroy_encoder;
}
 
-   subdrv-encoder = encoder;
subdrv-connector = connector;
 
return 0;
-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] ARM: dts: Add ptn3460 to exynos5250-snow

2013-10-01 Thread Sean Paul 
This patch adds a node for the ptn3460 DP-LVDS chip in the
exynos5250-snow board dts file.

Signed-off-by: Sean Paul seanp...@chromium.org
---
 arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 780511a..122fc1f 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -33,6 +33,13 @@
sd3_bus4: sd3-bus-width4 {
samsung,pin-drv = 0;
};
+
+   ptn3460_gpios: ptn3460-gpios {
+   samsung,pins = gpy2-5, gpx1-5;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
};
 
gpio-keys {
@@ -190,6 +197,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
 
+   i2c@12CD {
+   ptn3460-bridge@20 {
+   compatible = nxp,ptn3460;
+   reg = 0x20;
+   powerdown-gpio = gpy2 5 0;
+   reset-gpio = gpx1 5 0;
+   edid-emulation = 5;
+   pinctrl-names = default;
+   pinctrl-0 = ptn3460_gpios;
+   };
+   };
+
dp-controller {
samsung,color-space = 0;
samsung,dynamic-range = 0;
-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70019] [RV670] GPU lockup and screen garbage on splash screen and in GNOME

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70019

--- Comment #4 from Nikolay Amiantov nikoa...@gmail.com ---
One last thing: everything seems okay at login screen, but not before and
after, and from logs it looks like GPU is resetting successfully. Also,
consoles work.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70019] [RV670] GPU lockup and screen garbage on splash screen and in GNOME

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70019

--- Comment #5 from Alex Deucher ag...@yahoo.com ---
Might be a duplicate of bug 69983.  Does reverting to an older version of mesa
fix the issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56081

--- Comment #13 from wojtek wojta...@wp.pl ---
you can try
https://bugs.freedesktop.org/show_bug.cgi?id=63599#c29

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67107] Xorg starts and crashes with DPM enable

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67107

--- Comment #13 from Adam Honse calcprogramm...@gmail.com ---
To follow up with my previous comment, I tried disabling the discrete GPU.  In
my case I disable it AFTER the radeon module is loaded (because doing it the
other way around causes errors that lag the machine to an unusable state).  The
machine has no means of disabling it in the BIOS so I use the acpi_call kernel
module with the turn_off_gpu script from here:
https://github.com/mkottman/acpi_call/

What I did was start the laptop with dpm=1 and gdm set to not start
automatically so I'd boot to a text console.  Radeon module loads at boot and
KMS sets the console to the appropriate resolution.  Then I insmod the
acpi_call.ko and run the turn-off-gpu script which turns off the discrete GPU. 
Then I started gdm, logged in, and ran glxgears to confirm that the integrated
GPU was working (ran fine) and looked at Xorg.0.log to confirm radeon.dpm=1 (it
did).  This was on battery power, haven't tested plugged in.  I'm downloading
Open Arena now to see if gaming performance is improved.  Using xrandr
--listproviders confirms that only one GPU is active and available which is the
integrated one.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption

2013-10-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69689

--- Comment #4 from Johannes Jordan freedesk...@lanrules.de ---
I still have the problem and I can reproduce it. I am very willing to help in
debugging the issue if you give me directions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 2/4] drm/tegra: Add runtime pm support for gr2d

2013-10-01 Thread Arto Merilainen 

On 10/01/2013 09:14 PM, Stephen Warren wrote:

On 09/24/2013 06:05 AM, Arto Merilainen wrote:

diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c



@@ -327,11 +336,48 @@ static int __exit gr2d_remove(struct platform_device 
*pdev)
host1x_syncpt_free(gr2d-client.syncpts[i]);

host1x_channel_free(gr2d-channel);
+
+   if (pm_runtime_enabled(pdev-dev))
+   pm_runtime_disable(pdev-dev);
+   else
+   gr2d_runtime_suspend(pdev-dev);


This code is slightly different to the code in e.g.
sound/soc/tegra/tegra20_i2s.c:remove(), whereas the code in probe() is
identical. I'm not sure whether there's some advantage in this version?
If so, perhaps the sound drivers should be updated to be consistent. If
not, perhaps this driver should do the same thing as the I2S driver, so
we keep the drivers consistent, and provide the same example code
everywhere.


Hmm. I cannot immediately see any advantage in this version... I will 
update the patch.





+static int gr2d_runtime_suspend(struct device *dev)
+{
+   struct gr2d *gr2d;
+
+   gr2d = dev_get_drvdata(dev);
+   if (!gr2d)
+   return -EINVAL;


Presumably, gr2d will never be NULL here, unless there's some chronic
bug. Can't we re-write those last 5 lines as simply:

struct gr2d *grd2 = dev_get_drvdata(dev);

If that's not valid, we should probably update the audio drivers (and
perhaps others) too.


I think you are correct. I cannot see any reason why that check is required.

- Arto
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 4/4] gpu: host1x: Add runtime pm support for host1x

2013-10-01 Thread Arto Merilainen 

On 10/01/2013 09:17 PM, Stephen Warren wrote:

On 09/24/2013 06:05 AM, Arto Merilainen wrote:

From: Mayuresh Kulkarni mkulka...@nvidia.com

This patch adds runtime pm support for host1x hardware unit. This
allows host1x clock to be turned off when it is idle. If pm runtime
is not configured, we enable host1x clock in device probe and disable
it in remove.



diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c



+static int host1x_runtime_suspend(struct device *dev);
+static int host1x_runtime_resume(struct device *dev);


You could avoid having these prototypes by simply putting the function
bodies earlier on in the file, somewhere before they're used. I don't
care much either way, but I've certainly seen some people care about
this and ask for them to be moved.


Will fix.

- Arto

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel