[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

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

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





--- Comment #18 from Fernando Chaves   2013-01-04 
19:34:06 ---
Yes, everything works at 100% without Xen, both CLI and Xorg, even in CentOS.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

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

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





--- Comment #17 from Konrad Rzeszutek Wilk   
2013-01-04 19:26:35 ---
(In reply to comment #16)
> I'm sorry Konrad, but I don't know exactly what you mean when you say "run on
> bare metal".

without Xen.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 0/2] drm/exynos: add support for more resolutions to exynos5

[Rahul Sharma]

Please Abandon this patch set.

Same code is posted under new patch set at
http://comments.gmane.org/gmane.comp.video.dri.devel/78392

regards,
Rahul Sharma

On Tue, Dec 18, 2012 at 7:42 PM, Rahul Sharma  
wrote:
> This patch set adds support for more resolutions and refresh rates to Samsung
> Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).
>
> Given resoltuion will be supported or not, is decided by two factors:
> 1) Corresponding pixel clock is supported by hdmi PHY.
> 2) Mixer can generate the correspoding video timing.
>
> All standard resolutions and pixel rate combinations are verified for the 
> above
> limitations and are listed in hdmi driver. Any standard resolution supported 
> by
> the monitor/tv will be comapared against this list.
>
> We got 640x480, 720x576 and 1680x1050 and few more refresh rates enabled as a
> result to this exercise.
>
> Rahul Sharma (2):
>   drm/exynos: hdmi: add support for extra permissable resolutions
>   drm/exynos: mixer: add support for extra resolutions
>
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 1004 
> -
>  drivers/gpu/drm/exynos/exynos_mixer.c |8 +-
>  2 files changed, 358 insertions(+), 654 deletions(-)
>

radeon CS parser refactoring

[Alex Deucher]

On Fri, Jan 4, 2013 at 5:57 PM, Ilija Hadzic
 wrote:
>
> On Fri, 4 Jan 2013, Dave Airlie wrote:
>
>> Did you run these with pre-kms userspace etc to make sure it doesn't
>> cause regressions there?
>>
>
> I did some tests with UMS and shuffled a number of cards. As I feared, I ran
> into a number of unrelated problems, but in each case I have seen identical
> beahvior between the kernel with my patches and without. So as far as I can
> tell, my patches do not introduce regressions in legacy modes, althugh I am
> not sure about the coverage.
>
> Also, in one test, I think I have hit a genuine bug in ATI DDX (explained
> below).
>
> Below I describe what I saw with each card family. Maybe for some test cases
> I am missing some "magic" option in xorg.conf or maybe what I am seeing
> (mostly reduced feature set) is expected in UMS.
>
> * With an NI card (TURKS, HD6570 card), Xorg just plain tells me that the
>   card is supported in KMS only mode. So, I guess, that's it for that
>   card.

Evergreen was the last set of hardware supported by UMS.

>
> * A test with Evergreen (CEDAR) card works in UMS mode, but I can't
>   get 3D acceleration. I see these messages in Xorg log file:
>
> [37.024] (II) RADEON(0): No DRI yet on Evergreen

UMS support for evergreen is modesetting only.  No accel.

> .
> .
> [37.364] (II) AIGLX: Screen 0 is not DRI2 capable
> [37.364] (II) AIGLX: Screen 0 is not DRI capable
> [37.664] (II) AIGLX: Loaded and initialized swrast
> [37.664] (II) GLX: Initialized DRISWRAST GL provider for screen 0
>
>   Sounds like just a "property" of UMS to me, but I am not sure.
>   Nevertheless, the behavior with and without my kernel patches is
>   identical. Still, 2D copying should still be exercising the CS
>   parser, so there is some test coverage here.
>
> * A test with an R7xx card (RV730, E4690 card) results in a segfault in
>   DDX. Again, this is irrespective of my kernel patches, so I believe
>   that the bug has been there for a while and that it's in userland.
>   The crash occurs in r600_set_render_target() function and what causes
>   it is corrupted cb_conf->surface pointer. When the crash occurs it
>   has a value of 0x1, which doesn't look like something that would live
>   in .bss, .data or come from the heap. I didn't try other R6xx cards,
>   but I suspect that they may have the same problem because they share
>   the code in DDX. I don't know if UMS DDX will be maintained going
>   forward, so I don't know if it makes sense to open a bug for this.
>   BTW, DDX I am testing this with is 6.14.6

R6xx and r7xx are really all you need to worry about in this case.
R1xx-r5xx UMS uses a different kernel interface for command submission
and evergreen and later don't have UMS drm support.  UMS r6xx/r7xx
support used the same kernel interface for command submission but the
kernel side was much simpler.  Additionally, UMS requires the old
non-gallium 3D drivers.  It sounds like some other change in the ddx
broke UMS support for r6xx/r7xx.  UMS support was dropped for
xf86-video-ati 7.0.0, so we mostly want to try and avoid breaking
things for users with ancient userspace stacks and a new kernel.  That
said, I'm not sure there are that many UMS users left.

Alex

>
> * A test with R300 card (Radeon X300 card) works (again identically
>   with and without my patches), but again without 3D acceleration.
>   So it's similar result and comment as with the Evergreen test, though
>   relevant messages in Xorg log file are slightly different:
>
> [35.630] (EE) AIGLX error: r300 does not export required DRI extension
> [35.630] (EE) AIGLX: reverting to software rendering
> [35.915] (II) AIGLX: Loaded and initialized swrast
> [35.915] (II) GLX: Initialized DRISWRAST GL provider for screen 0
>
>   Again, I don't know if this is just the way things are in UMS mode or if
>   there is some configuration magic I need to do.
>
> So at this point I'd say that I have not seen anything that would indicate a
> regression in legacy mode, although the limitations I have hit make the
> tests more limited that I thought they would be (and KMS I tested quite a
> bit, so I am confident there).
>
> thanks,
>
> Ilija
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

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

Michael Dressel  changed:

   What|Removed |Added

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

--- Comment #54 from Michael Dressel  ---
The patch works for me, as alread reported. I have not tried a kernel including
the patch. But I still think this bug is fixed.

-- 
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/20130104/83152fcc/attachment.html>

[Bug 50941] Kernel does not compile

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

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





--- Comment #3 from JP Pozzi   2013-01-04 17:56:28 ---
Hello,

I try it but ACPI_VIDEO is reset to "m" whenever you "make menuconfig" or
compile the kernel. I can't find what other parameters are to be set to "y".

At least the kernel compile but I have some problems, after one or two hours
the
screen (or keyboard ?) get stuck and I have to connect from another machine
to stop properly the system. I get the same kind of "screen blocked" with the
3.7.1 kernel.

I try it but ACPI_VIDEO is reset to "m" whenever you "make menuconfig" or
compile the kernel. I can't find what other parameters are to be set to "y".
It is the same for 3.7.1 kernel.

Regards

JP P

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 42162] Display not enabled on resume (HP DV6)

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

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

--- Comment #12 from Johan Brannlund  ---
Correction: it's *not* a hard lockup - the laptop still responds to ping. It
may just be that the keyboard is not working after resume (or even that I
mistyped something when trying to reboot it by typing blind).

-- 
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/20130104/9d5a4249/attachment.html>

[RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron

[Maarten Lankhorst]

Op 04-01-13 16:34, Alex Deucher schreef:
> On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst
>  wrote:
>> vga-switcheroo with apple-gmux does not switch correctly on my system. The 
>> PCI
>> configuration space is not restored correctly, resulting in MSI not working 
>> after switch.
>>
>> Only useful item in dmesg is:
>>
>> [   33.922807] radeon :01:00.0: Refused to change power state, currently 
>> in D3
>>
>> I did some testing, dumping the difference in ms between first succesful 
>> switch
>> from D3 to D0, and it seems that there is slightly more than 20 ms 
>> difference when
>> the device is re-enabled through vga-switcheroo.
>>
>> So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not 
>> working
>> on my system after switcheroo-ing.
> I guess if it fixes it...  Has anyone seen similar problems on non-mac
> systems?  What is the delay normally set to?  It seems pretty
It's normally set to PCI_PM_D3_WAIT, 10 ms.
> innocuous other than potentially adding a little extra latency.  Do
> you think it makes sense to make it more like a quirk and only apply
> it to problematic systems or just apply across the board?
Quirking would be fine. Since there is a message in dmesg it would
be easy to identify when others hit the same issue, in which case
we could enable it all the time.

>> Signed-off-by: Maarten Lankhorst 
>>
>> ---
>>
>> This is a RFC patch since I feel what I'm doing is done in a hackish way,
>> but it seems only the D3->D0 transition during switcheroo enable is affected,
>> other transitions like suspend/resume and switcheroo poweroff seem 
>> unaffected.
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index 5515921..8816958 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev 
>> *pdev, enum vga_switchero
>> struct drm_device *dev = pci_get_drvdata(pdev);
>> pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
>> if (state == VGA_SWITCHEROO_ON) {
>> +   unsigned d3_delay = dev->pdev->d3_delay;
>> +
>> printk(KERN_INFO "radeon: switched on\n");
>> /* don't suspend or resume card normally */
>> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
>> +
>> +   if (dev->pdev->d3_delay < 20)
>> +   dev->pdev->d3_delay = 20;
>> +
>> radeon_resume_kms(dev);
>> +
>> +   dev->pdev->d3_delay = d3_delay;
>> +
>> dev->switch_power_state = DRM_SWITCH_POWER_ON;
>> drm_kms_helper_poll_enable(dev);
>> } else {
>>

[Bug 42162] Display not enabled on resume (HP DV6)

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

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

--- Comment #11 from Johan Brannlund  ---
I'll try bisecting when I have some spare time, but it's probably going to be a
few weeks.

-- 
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/20130104/d7241368/attachment.html>

[Bug 42162] Display not enabled on resume (HP DV6)

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

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

--- Comment #10 from Alex Deucher  ---
(In reply to comment #8)
> Resume still doesn't work with kernel 3.8-rc2. However, I now get a hard
> lockup on resume. Log attached.

Can you bisect to see what caused the hard lock?

-- 
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/20130104/af4058bc/attachment.html>

radeon CS parser refactoring

[Ilija Hadzic]

On Fri, 4 Jan 2013, Dave Airlie wrote:

> Did you run these with pre-kms userspace etc to make sure it doesn't
> cause regressions there?
>

I did some tests with UMS and shuffled a number of cards. As I feared, I 
ran into a number of unrelated problems, but in each case I have seen 
identical beahvior between the kernel with my patches and without. So as 
far as I can tell, my patches do not introduce regressions in legacy 
modes, althugh I am not sure about the coverage.

Also, in one test, I think I have hit a genuine bug in ATI DDX (explained 
below).

Below I describe what I saw with each card family. Maybe for some test 
cases I am missing some "magic" option in xorg.conf or maybe what I am 
seeing (mostly reduced feature set) is expected in UMS.

* With an NI card (TURKS, HD6570 card), Xorg just plain tells me that the
   card is supported in KMS only mode. So, I guess, that's it for that
   card.

* A test with Evergreen (CEDAR) card works in UMS mode, but I can't
   get 3D acceleration. I see these messages in Xorg log file:

[37.024] (II) RADEON(0): No DRI yet on Evergreen
.
.
[37.364] (II) AIGLX: Screen 0 is not DRI2 capable
[37.364] (II) AIGLX: Screen 0 is not DRI capable
[37.664] (II) AIGLX: Loaded and initialized swrast
[37.664] (II) GLX: Initialized DRISWRAST GL provider for screen 0

   Sounds like just a "property" of UMS to me, but I am not sure.
   Nevertheless, the behavior with and without my kernel patches is
   identical. Still, 2D copying should still be exercising the CS
   parser, so there is some test coverage here.

* A test with an R7xx card (RV730, E4690 card) results in a segfault in
   DDX. Again, this is irrespective of my kernel patches, so I believe
   that the bug has been there for a while and that it's in userland.
   The crash occurs in r600_set_render_target() function and what causes
   it is corrupted cb_conf->surface pointer. When the crash occurs it
   has a value of 0x1, which doesn't look like something that would live
   in .bss, .data or come from the heap. I didn't try other R6xx cards,
   but I suspect that they may have the same problem because they share
   the code in DDX. I don't know if UMS DDX will be maintained going
   forward, so I don't know if it makes sense to open a bug for this.
   BTW, DDX I am testing this with is 6.14.6

* A test with R300 card (Radeon X300 card) works (again identically
   with and without my patches), but again without 3D acceleration.
   So it's similar result and comment as with the Evergreen test, though
   relevant messages in Xorg log file are slightly different:

[35.630] (EE) AIGLX error: r300 does not export required DRI extension
[35.630] (EE) AIGLX: reverting to software rendering
[35.915] (II) AIGLX: Loaded and initialized swrast
[35.915] (II) GLX: Initialized DRISWRAST GL provider for screen 0

   Again, I don't know if this is just the way things are in UMS mode or if
   there is some configuration magic I need to do.

So at this point I'd say that I have not seen anything that would indicate 
a regression in legacy mode, although the limitations I have hit make the 
tests more limited that I thought they would be (and KMS I tested quite a 
bit, so I am confident there).

thanks,

Ilija

[Bug 42162] Display not enabled on resume (HP DV6)

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

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

--- Comment #9 from Johan Brannlund  ---
Created attachment 72514
  --> https://bugs.freedesktop.org/attachment.cgi?id=72514=edit
Suspend/resume log, kernel 3.8-rc2

-- 
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/20130104/0b156482/attachment.html>

[Bug 42162] Display not enabled on resume (HP DV6)

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

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

--- Comment #8 from Johan Brannlund  ---
Resume still doesn't work with kernel 3.8-rc2. However, I now get a hard lockup
on resume. Log attached.

-- 
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/20130104/317f88ef/attachment.html>

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

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

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





--- Comment #16 from Fernando Chaves   2013-01-04 
16:35:55 ---
I'm sorry Konrad, but I don't know exactly what you mean when you say "run on
bare metal".

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH v3] drm/exynos: let drm handle edid allocations

[Inki Dae]

Hi Rahul,

With this patch, I got a error like below,

# echo 1 > /sys/devices/vidi.5/connection
[  149.485000] [drm:exynos_drm_connector_get_modes] *ERROR* update
edid property failed(-22)

There is something wrong. Please check it out again.

2013/1/2 Rahul Sharma :
> There's no need to allocate edid twice and do a memcpy when drm helpers
> exist to do just that. This patch cleans that interaction up, and
> doesn't keep the edid hanging around in the connector.
>
> v3:
> - removed MAX_EDID as it is not used anymore.
>
> v2:
> - changed vidi_get_edid callback inside vidi driver.
>
> Signed-off-by: Sean Paul 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Seung-Woo Kim 
> ---
> This patch is based on branch "exynos-drm-next" at
> http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
>
>  drivers/gpu/drm/exynos/exynos_drm_connector.c | 37 
> ++-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 +--
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  9 +++
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |  4 +--
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 19 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 25 --
>  6 files changed, 50 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index ab37437..221ec72 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -18,7 +18,6 @@
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_encoder.h"
>
> -#define MAX_EDID 256
>  #define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\
> drm_connector)
>
> @@ -96,7 +95,9 @@ static int exynos_drm_connector_get_modes(struct 
> drm_connector *connector)
> to_exynos_connector(connector);
> struct exynos_drm_manager *manager = exynos_connector->manager;
> struct exynos_drm_display_ops *display_ops = manager->display_ops;
> -   unsigned int count;
> +   unsigned int count = 0;
> +   struct edid *edid = NULL;
> +   int ret;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> @@ -114,27 +115,25 @@ static int exynos_drm_connector_get_modes(struct 
> drm_connector *connector)
>  * because lcd panel has only one mode.
>  */
> if (display_ops->get_edid) {
> -   int ret;
> -   void *edid;
> -
> -   edid = kzalloc(MAX_EDID, GFP_KERNEL);
> -   if (!edid) {
> -   DRM_ERROR("failed to allocate edid\n");
> -   return 0;
> +   edid = display_ops->get_edid(manager->dev, connector);
> +   if (IS_ERR_OR_NULL(edid)) {
> +   ret = PTR_ERR(edid);
> +   edid = NULL;
> +   DRM_ERROR("Panel operation get_edid failed %d\n", 
> ret);
> +   goto out;
> }
>
> -   ret = display_ops->get_edid(manager->dev, connector,
> -   edid, MAX_EDID);
> -   if (ret < 0) {
> -   DRM_ERROR("failed to get edid data.\n");
> -   kfree(edid);
> -   edid = NULL;
> -   return 0;
> +   ret = drm_mode_connector_update_edid_property(connector, 
> edid);
> +   if (ret) {
> +   DRM_ERROR("update edid property failed(%d)\n", ret);
> +   goto out;
> }
>
> -   drm_mode_connector_update_edid_property(connector, edid);
> count = drm_add_edid_modes(connector, edid);
> -   kfree(edid);
> +   if (count < 0) {
> +   DRM_ERROR("Add edid modes failed %d\n", count);
> +   goto out;
> +   }
> } else {
> struct exynos_drm_panel_info *panel;
> struct drm_display_mode *mode = 
> drm_mode_create(connector->dev);
> @@ -161,6 +160,8 @@ static int exynos_drm_connector_get_modes(struct 
> drm_connector *connector)
> count = 1;
> }
>
> +out:
> +   kfree(edid);
> return count;
>  }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index b9e51bc..4606fac 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -148,8 +148,8 @@ struct exynos_drm_overlay {
>  struct exynos_drm_display_ops {
> enum exynos_drm_output_type type;
> bool (*is_connected)(struct device *dev);
> -   int (*get_edid)(struct device *dev, struct drm_connector *connector,
> -   u8 *edid, int len);
> +   struct edid *(*get_edid)(struct device *dev,
> +   struct 

[RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth

[Dave Airlie]

On Tue, Jan 1, 2013 at 11:21 AM, Marcin Slusarz
 wrote:
> On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
>> Check that the AGP aperture can be mapped. This follows a similar change
>> done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
>> the aperture can be mapped by the CPU.).
>>
>> The patch fixes the following error seen on G5 iMac:
>>
>>   nouveau E[ DRM] failed to create kernel channel, -12
>>
>> Reviewed-by: Michel D?nzer 
>> Signed-off-by: Aaro Koskinen 
>> ---
>
> This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=58806.
> For some (weird) reason Nouveau worked on this configuration on 3.6 kernel,
> so cc'ing stable at vger seems to be appropriate.

Cool I've picked this up and applied it for stable into fixes now.

Dave.

[PATCH] drm/exynos: fimd: modify condition in fimd resume

[Prathyush K]

Hi,

Please review this patch.

Regards,
Prathyush


On Thu, Dec 27, 2012 at 5:10 PM, Prathyush K wrote:

> If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
> call fimd_activate(false) and just returns. Similarily the check in
> fimd_resume should not resume if previously runtime_suspended.
> Instead the existing check does the opposite. So if fimd was not
> runtime suspended, suspend will turn off fimd but resume will not turn
> it on.  This patch fixes this issue by reversing the condition.
>
> Signed-off-by: Prathyush K 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..9accd466 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1046,7 +1046,7 @@ static int fimd_resume(struct device *dev)
>  * of pm runtime would still be 1 so in this case, fimd driver
>  * should be on directly not drawing on pm runtime interface.
>  */
> -   if (pm_runtime_suspended(dev)) {
> +   if (!pm_runtime_suspended(dev)) {
> int ret;
>
> ret = fimd_activate(ctx, true);
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130104/d66c8a92/attachment.html>

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

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

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





--- Comment #15 from Konrad Rzeszutek Wilk   
2013-01-04 16:00:10 ---
Let me ask again: Does it work properly under baremetal?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 58667] Random crashes on CAYMAN

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

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

--- Comment #23 from Alex Deucher  ---
(In reply to comment #22)
> "Is this a regression?  Does it happen with older versions of mesa or
> kernel?"
> Yes. Previous kernel 3.7 doesn't show this problem.

Can you bisect?  Is it the same commit Thomas landed on or another one?

-- 
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/20130104/144659c5/attachment.html>

[PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups

[Alex Deucher]

On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas  wrote:
> These are minor cleanups for drm_pcie_get_speed_cap_mask() to use
> standard #defines and PCIe capability accessors.  They depend on
> a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2.
>
> They don't address the issue of DRM devices directly below a host
> bridge that doesn't appear as a PCI device (the issue Lucas has
> been working on).
>
> I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask()
> to begin with.  Link speed seems like something fairly generic that should
> be handled in the core, not in individual drivers.  Sec 6.11, "Link Speed
> Management", in the PCIe 3.0 spec seems relevant and suggests that the
> hardware should automatically use the highest speed supported by both ends
> of the link unless software sets a lower maximum via Target Link Speed.
>
> But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to
> anything in the generic PCIe specs, so maybe this driver code is
> essentially quirks for misbehaving hardware?

At least for radeon, there is an asic specific sequence required to
change the PCIE gen link speed at runtime.  Depending on the bios, the
board may come up in the highest mode supported by either side or
something lower.  If it comes up at a lower speed than the hardware is
capable of, we can increase it in the driver to improve performance.
Additionally, you can select a lower link speed to save power.  I
don't know if there is a generic non-asic specific way to change the
link speed of a device at runtime, but I'm not really a PCI expert.

Alex

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

--- Comment #9 from Adam Jorgensen  ---
(In reply to comment #5)
> I'm assuming you are using mesa 9.x or newer based on the version info in
> the bug header.  Can you confirm?  xf86-video-ati 7.0.0 requires mesa 9.x. 
> Also, if the steam client is a 32-bit application and you are running a
> 64-bit distro, you will need to make sure your 32-bit 3D driver is up to
> date.  I suspect you have an out of date 32-bit 3D driver.

I can confirm that I am using Mesa 9.0.1 in conjunction with xf86-video-ati
7.0.0.

I *thought* I was running Steam as a 64-bit application but based on the lack
of an "ubuntu12_64" directory in my  ~/.local/share/Steam directory it seems
likely that my Steam installation is actually a 32-bit one.

I am using the latest emul-x86 libs (I'm running Sabayon Linux) but I also have
a separate 32-bit chroot for work purposes. I will try updating the chroot
environment (Since it's set up with the same distro) and installing Steam their
and testing it in that environment...

-- 
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/20130104/c92172a4/attachment.html>

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

--- Comment #8 from Adam Jorgensen  ---
Created attachment 72511
  --> https://bugs.freedesktop.org/attachment.cgi?id=72511=edit
glxinfo output

Output from glxinfo

-- 
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/20130104/83f45be9/attachment.html>

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

--- Comment #7 from Adam Jorgensen  ---
Created attachment 72510
  --> https://bugs.freedesktop.org/attachment.cgi?id=72510=edit
dmesg output

Output from dmesg after running Steam and triggering corruption

-- 
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/20130104/956fb689/attachment.html>

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

--- Comment #6 from Adam Jorgensen  ---
Created attachment 72509
  --> https://bugs.freedesktop.org/attachment.cgi?id=72509=edit
X.org log

My X.org log file

-- 
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/20130104/5ad131b6/attachment.html>

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

--- Comment #5 from Alex Deucher  ---
I'm assuming you are using mesa 9.x or newer based on the version info in the
bug header.  Can you confirm?  xf86-video-ati 7.0.0 requires mesa 9.x.  Also,
if the steam client is a 32-bit application and you are running a 64-bit
distro, you will need to make sure your 32-bit 3D driver is up to date.  I
suspect you have an out of date 32-bit 3D driver.

-- 
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/20130104/8757ba52/attachment.html>

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Stephen Warren]

On 01/04/2013 03:09 AM, Terje Bergstr?m wrote:
...
> I think we have now two ways to go forward with cons and pros:
>  1) Keep host1x and tegra-drm as separate driver
>+ Code almost done
>- we need dummy device and dummy driver
>- extra code and API when host1x creates dummy device and its passed
> to tegra-drm

Just to play devil's advocate:

I suspect that's only a few lines of code.

>- tegra-drm device would need to be a child of host1x device. Having
> virtual and real devices as host1x children sounds weird.

And I doubt that would cause problems.

>  2) Merge host1x and tegra-drm into one module. drm is a subcomponent,
> and whatever other personalities we wish would also be subcomponents of
> host1x. host1x calls tegra-drm directly to handle preparation for drm
> initialization. As they're in the same module, circular dependency is ok.
>+ Simpler conceptually (no dummy device/driver)
>+ Less code
>- Proposal doesn't yet exist

But that said, I agree this approach would be very reasonable; it seems
to me that host1x really is the main HW behind a DRM driver or a V4L2
driver or ... As such, it seems quite reasonable for a single struct
device to exist that represents host1x, and for the driver for that
device to register both a DRM and a V4L2 driver etc. The code could
physically be organized into separate modules, and under different
Kconfig options for configurability etc.

But either way, I'll let you (Thierry and Terje) work out which way to go.

[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

[Florian Mickler]

Dear Paul,

On Tue, 01 Jan 2013 04:43:39 +0100
Paul Menzel  wrote:

> So if nobody has a great idea, the roadmap looks as follows. Revert the
> patch, find out why the graphics driver chokes on the reduced blanking
> (report a bug) and commit the patch again.

I reported a bug at: https://bugzilla.kernel.org/show_bug.cgi?id=52281

Regards,
Flo
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130104/f11928cb/attachment.pgp>

[PATCH] drm/radeon: fix DMA CS parser for r6xx linear copy packet

[alexdeuc...@gmail.com]

From: Alex Deucher 

Was using the r7xx format.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/r600_cs.c |   31 ++-
 1 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 9ea13d0..03191a5 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2677,16 +2677,29 @@ int r600_dma_cs_parse(struct radeon_cs_parser *p)
}
p->idx += 7;
} else {
-   src_offset = ib[idx+2];
-   src_offset |= ((u64)(ib[idx+4] & 0xff)) << 32;
-   dst_offset = ib[idx+1];
-   dst_offset |= ((u64)(ib[idx+3] & 0xff)) << 32;
+   if (p->family >= CHIP_RV770) {
+   src_offset = ib[idx+2];
+   src_offset |= ((u64)(ib[idx+4] & 0xff)) 
<< 32;
+   dst_offset = ib[idx+1];
+   dst_offset |= ((u64)(ib[idx+3] & 0xff)) 
<< 32;

-   ib[idx+1] += (u32)(dst_reloc->lobj.gpu_offset & 
0xfffc);
-   ib[idx+2] += (u32)(src_reloc->lobj.gpu_offset & 
0xfffc);
-   ib[idx+3] += 
upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff;
-   ib[idx+4] += 
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
-   p->idx += 5;
+   ib[idx+1] += 
(u32)(dst_reloc->lobj.gpu_offset & 0xfffc);
+   ib[idx+2] += 
(u32)(src_reloc->lobj.gpu_offset & 0xfffc);
+   ib[idx+3] += 
upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff;
+   ib[idx+4] += 
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
+   p->idx += 5;
+   } else {
+   src_offset = ib[idx+2];
+   src_offset |= ((u64)(ib[idx+3] & 0xff)) 
<< 32;
+   dst_offset = ib[idx+1];
+   dst_offset |= ((u64)(ib[idx+3] & 
0xff)) << 16;
+
+   ib[idx+1] += 
(u32)(dst_reloc->lobj.gpu_offset & 0xfffc);
+   ib[idx+2] += 
(u32)(src_reloc->lobj.gpu_offset & 0xfffc);
+   ib[idx+3] += 
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
+   ib[idx+3] += 
(upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff) << 16;
+   p->idx += 4;
+   }
}
if ((src_offset + (count * 4)) > 
radeon_bo_size(src_reloc->robj)) {
dev_warn(p->dev, "DMA copy src buffer too small 
(%llu %lu)\n",
-- 
1.7.7.5

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Drivers/Gallium/r600

--- Comment #4 from Andreas Boll  ---
Please attach your xorg log and the outputs from dmesg and glxinfo.

-- 
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/20130104/6345e658/attachment-0001.html>

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

Andreas Boll  changed:

   What|Removed |Added

  Attachment #72497|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/20130104/4835b05d/attachment.html>

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

Andreas Boll  changed:

   What|Removed |Added

  Attachment #72495|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/20130104/ca55aebc/attachment.html>

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Boszormenyi Zoltan]

2013-01-04 08:40 keltez?ssel, Borislav Petkov ?rta:
> On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
>> From: Alex Deucher 
>> Date: Wed, 2 Jan 2013 18:30:21 -0500
>> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>>
>> count must be a multiple of 2.
>>
>> Cc: Borislav Petkov 
>> Cc: Markus Trippelsdorf 
>> Signed-off-by: Alex Deucher 
> Thanks, will run it on the box in question next week when I have access.
>
> Btw, you could add the note about count needing to be a multiple of 2 as
> a comment in the code below, for future reference.
>
>> ---
>>   drivers/gpu/drm/radeon/r600.c |4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
>> index 2aaf147..9f4ce5e 100644
>> --- a/drivers/gpu/drm/radeon/r600.c
>> +++ b/drivers/gpu/drm/radeon/r600.c
>> @@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
>>   
>>  for (i = 0; i < num_loops; i++) {
>>  cur_size_in_dw = size_in_dw;
>> -if (cur_size_in_dw > 0x)
>> -cur_size_in_dw = 0x;
>> +if (cur_size_in_dw > 0xFFFE)
>> +cur_size_in_dw = 0xFFFE;

How about any other odd numbers? Like 0xFFFB, or 0x0003?
They will get passed as is after this change, no? Shouldn't they
be also fixed? Something like this below?

   if (cur_size_in_dw & 0x0001)
cur_size_in_dw &= ~1;



>>  size_in_dw -= cur_size_in_dw;
>>  radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0, 
>> cur_size_in_dw));
>>  radeon_ring_write(ring, dst_offset & 0xfffc);
>> -- 
>> 1.7.7.5

[PATCH 3/3] drm/pci: Use PCI Express Capability accessors

[Bjorn Helgaas]

Use PCI Express Capability access functions to simplify this code a bit.
For non-PCIe devices or pre-PCIe 3.0 devices that don't implement the Link
Capabilities 2 register, pcie_capability_read_dword() reads a zero.

Since we're only testing whether the bits we care about are set, there's no
need to mask out the other bits we *don't* care about.

Signed-off-by: Bjorn Helgaas 
---
 drivers/gpu/drm/drm_pci.c |   21 +
 1 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 50e26f2..86102a0 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -469,41 +469,30 @@ EXPORT_SYMBOL(drm_pci_exit);
 int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
 {
struct pci_dev *root;
-   int pos;
-   u32 lnkcap = 0, lnkcap2 = 0;
+   u32 lnkcap, lnkcap2;

*mask = 0;
if (!dev->pdev)
return -EINVAL;

-   if (!pci_is_pcie(dev->pdev))
-   return -EINVAL;
-
root = dev->pdev->bus->self;

-   pos = pci_pcie_cap(root);
-   if (!pos)
-   return -EINVAL;
-
/* we've been informed via and serverworks don't make the cut */
if (root->vendor == PCI_VENDOR_ID_VIA ||
root->vendor == PCI_VENDOR_ID_SERVERWORKS)
return -EINVAL;

-   pci_read_config_dword(root, pos + PCI_EXP_LNKCAP, );
-   pci_read_config_dword(root, pos + PCI_EXP_LNKCAP2, );
-
-   lnkcap &= PCI_EXP_LNKCAP_SLS;
-   lnkcap2 &= 0xfe;
+   pcie_capability_read_dword(root, PCI_EXP_LNKCAP, );
+   pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, );

-   if (lnkcap2) { /* PCIE GEN 3.0 */
+   if (lnkcap2) {  /* PCIe r3.0-compliant */
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
*mask |= DRM_PCIE_SPEED_50;
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
*mask |= DRM_PCIE_SPEED_80;
-   } else {
+   } else {/* pre-r3.0 */
if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)

[PATCH 2/3] drm/pci: Set all supported speeds in speed cap mask for pre-3.0 devices

[Bjorn Helgaas]

For devices that conform to PCIe r3.0 and have a Link Capabilities 2
register, we test and report every bit in the Supported Link Speeds Vector
field.  For a device that supports both 2.5GT/s and 5.0GT/s, we set both
DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in the returned mask.

For pre-r3.0 devices, the Link Capabilities 0010b encoding
(PCI_EXP_LNKCAP_SLS_5_0GB) means that both 5.0GT/s and 2.5GT/s are
supported, so set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in this
case as well.

Signed-off-by: Bjorn Helgaas 
---
 drivers/gpu/drm/drm_pci.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 11c8add..50e26f2 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -507,7 +507,7 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 
*mask)
if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
-   *mask |= DRM_PCIE_SPEED_50;
+   *mask |= (DRM_PCIE_SPEED_25 | DRM_PCIE_SPEED_50);
}

DRM_INFO("probing gen 2 caps for device %x:%x = %x/%x\n", root->vendor, 
root->device, lnkcap, lnkcap2);

[PATCH 1/3] drm/pci: Use the standard #defines for PCIe Link Capability bits

[Bjorn Helgaas]

Use the standard #defines rather than bare numbers for the PCIe Link
Capabilities speed bits.

Signed-off-by: Bjorn Helgaas 
---
 drivers/gpu/drm/drm_pci.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 754bc96..11c8add 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -504,9 +504,9 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 
*mask)
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
*mask |= DRM_PCIE_SPEED_80;
} else {
-   if (lnkcap & 1)
+   if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
-   if (lnkcap & 2)
+   if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
*mask |= DRM_PCIE_SPEED_50;
}

[PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups

[Bjorn Helgaas]

These are minor cleanups for drm_pcie_get_speed_cap_mask() to use
standard #defines and PCIe capability accessors.  They depend on
a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2.

They don't address the issue of DRM devices directly below a host
bridge that doesn't appear as a PCI device (the issue Lucas has
been working on).

I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask()
to begin with.  Link speed seems like something fairly generic that should
be handled in the core, not in individual drivers.  Sec 6.11, "Link Speed
Management", in the PCIe 3.0 spec seems relevant and suggests that the
hardware should automatically use the highest speed supported by both ends
of the link unless software sets a lower maximum via Target Link Speed.

But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to
anything in the generic PCIe specs, so maybe this driver code is
essentially quirks for misbehaving hardware?

---

Bjorn Helgaas (3):
  drm/pci: Use the standard #defines for PCIe Link Capability bits
  drm/pci: Set all supported speeds in speed cap mask for pre-3.0 devices
  drm/pci: Use PCI Express Capability accessors


 drivers/gpu/drm/drm_pci.c |   27 ---
 1 files changed, 8 insertions(+), 19 deletions(-)

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Terje Bergström]

On 21.12.2012 23:19, Stephen Warren wrote:
> I see the situation more like:
> 
> * There's host1x hardware.
> 
> * There's a low-level driver just for host1x itself; the host1x driver.
> 
> * There's a high-level driver for the entire host1x complex of devices.
> That is tegradrm. There may be more high-level drivers in the future
> (e.g. v4l2 camera driver if it needs to aggregate a bunch of host1x
> sub-devices liek tegradrm does).
> 
> * The presence of the host1x DT node logically implies that both the two
> drivers in the previous two points should be instantiated.
> 
> * Linux instantiates a single device per DT node.
> 
> * So, it's host1x's responsibility to instantiate the other device(s). I
> think it's reasonable for the host1x driver to know exactly what
> features the host1x HW complex supports; raw host1x access being one,
> and the higher level concept of a tegradrm being another. So, it's
> reasonable for host1x to trigger the instantiation of tegradrm.
> 
> * If DRM core didn't stomp on the device object's drvdata (or whichever
> field it is), I would recommend not creating a dummy device at all, but
> rather having the host1x driver directly implement multiple driver
> interfaces. There are many examples like this already in the kernel,
> e.g. combined GPIO+IRQ driver, combined GPIO+IRQ+pinctrl driver, etc.

We had a phone call with Stephen yesterday, and I finally understood why
unbroken chain from DT to tegra-drm is important. The goals are to be
able to modprobe tegra-drm without ill effects, and to auto-load
tegra-drm module. I had been chasing a totally different goal.

Sorry about all the churn.

I think we have now two ways to go forward with cons and pros:
 1) Keep host1x and tegra-drm as separate driver
   + Code almost done
   - we need dummy device and dummy driver
   - extra code and API when host1x creates dummy device and its passed
to tegra-drm
   - tegra-drm device would need to be a child of host1x device. Having
virtual and real devices as host1x children sounds weird.

 2) Merge host1x and tegra-drm into one module. drm is a subcomponent,
and whatever other personalities we wish would also be subcomponents of
host1x. host1x calls tegra-drm directly to handle preparation for drm
initialization. As they're in the same module, circular dependency is ok.
   + Simpler conceptually (no dummy device/driver)
   + Less code
   - Proposal doesn't yet exist

Thierry, what do you think? I'd prefer option 2, as that keeps things
simple and still fulfills the requirements. We probably would redo the
patch "Remove redundant host1x" to actually move drm under host1x, and
adds calls from host1x to parse_dt() directly. We'd probably leave the
code otherwise mostly as it is now, so we'll drop whatever modifications
we've done so far in my proposals. You can later pick up some things
from our proposals if you want, but it's then up to you.

We could also later think about generalizing some of the list management
to belong to host1x, but that'd be a follow-up and we can decide that later.

Terje

WARNING when dpms turns monitor off with powered-off monitor

[Paul Slootman]

(Please CC me on replies, I'm not subscribed.)

Since linux kernel version 3.7(.1), whenever I have already turned my
monitor off and the X server's dpms settings engages after the timeout,
I get the following:

[245917.595824] [ cut here ]
[245917.595837] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1908 
ironlake_crtc_disable+0x5a/0x7a2()
[245917.595839] Hardware name: 
[245917.595840] Modules linked in: pci_stub vboxpci(O) vboxnetadp(O) 
vboxnetflt(O) vboxdrv(O) nfnetlink ufs ntfs vfat msdos fat jfs reiserfs nfsd 
nfs_acl nfs lockd fscache sunrpc xt_tcpudp xt_recent iptable_filter ip_tables 
x_tables xfs sha256_generic dm_crypt hwmon_vid loop firewire_sbp2 fuse wacom 
mcs7830 usbnet mii snd_hda_codec_realtek coretemp kvm_intel snd_hda_intel kvm 
snd_hda_codec iTCO_wdt snd_hwdep gpio_ich iTCO_vendor_support snd_pcm hisax 
snd_page_alloc snd_seq microcode i2c_i801 snd_seq_device lpc_ich mfd_core 
snd_timer isdn hfcpci mISDN_core snd mei soundcore btrfs libcrc32c zlib_deflate 
dm_mod crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper 
cryptd sr_mod xts firewire_ohci lrw cdrom gf128mul firewire_core sg crc_itu_t 
xhci_hcd e1000e
[245917.595911] Pid: 6036, comm: Xorg Tainted: GW  O 
3.7.1-vs2.3.5.3-wurtelws #4
[245917.595913] Call Trace:
[245917.595919]  [] ? warn_slowpath_common+0x76/0x8a
[245917.595923]  [] ? ironlake_crtc_disable+0x5a/0x7a2
[245917.595929]  [] ? set_restore_sigmask+0x2d/0x2d
[245917.595933]  [] ? should_resched+0x5/0x23
[245917.595937]  [] ? _cond_resched+0x6/0x1b
[245917.595941]  [] ? intel_crtc_update_dpms+0x57/0x66
[245917.595945]  [] ? intel_connector_dpms+0x2f/0x53
[245917.595951]  [] ? 
drm_mode_obj_set_property_ioctl+0x16a/0x1fb
[245917.595955]  [] ? 
drm_mode_connector_property_set_ioctl+0x2c/0x31
[245917.595959]  [] ? drm_ioctl+0x28c/0x36a
[245917.595964]  [] ? core_sys_select+0x1ae/0x1f9
[245917.595968]  [] ? 
drm_mode_obj_set_property_ioctl+0x1fb/0x1fb
[245917.595972]  [] ? vfs_ioctl+0x1e/0x31
[245917.595976]  [] ? do_vfs_ioctl+0x3ed/0x42f
[245917.595981]  [] ? ktime_get_ts+0x42/0x80
[245917.595984]  [] ? should_resched+0x5/0x23
[245917.595989]  [] ? recalc_sigpending+0x12/0x41
[245917.595993]  [] ? __set_task_blocked+0x5e/0x65
[245917.595997]  [] ? sys_ioctl+0x4d/0x7d
[245917.596000]  [] ? should_resched+0x5/0x23
[245917.596002]  [] ? _cond_resched+0x6/0x1b
[245917.596007]  [] ? system_call_fastpath+0x16/0x1b
[245917.596009] ---[ end trace 1494574d9cf0f782 ]---

Yes, sorry about the tainted kernel (virtualbox modules), if anyone
really thinks those could be involved I'll reboot (but I'd rather not...)

This happens every time. If the display is on when dpms is engaged then
there's no problem.

I have a i7-2600K CPU, ie. not ironlake but sandybridge.
Motherboard is an Intel DZ68BC.
Monitor is a Dell 3008WFP 2560x1600, connected by displayport.
I'm happy to supply more info if needed.

BTW, thanks for the 3.7(.1) kernel version, it's the first one that
displays correctly on my monitor everytime without needing to powercycle
my monitor. Sometimes when turning the monitor on it would
display "no signal, powering down" and go into standby; powercycling
would then help. Same thing if the monitor was turned off with dpms,
pressing a key would not turn it on (the first couple of times I thought
the whole system had hung). Occasionally it _would_ simply work...
Sometimes the picture was corrupt (e.g right half of the screen very
green with a hint of what should be displayed there. Sometimes pixels
would flicker...   Now with 3.7.1, after a couple of days, it looks
good! (Besides the WARNING in the kernel log :-)


Paul

[PATCH v2 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct

[Sean Paul]

On Fri, Jan 4, 2013 at 8:53 AM, Rahul Sharma  
wrote:
> This patch adds the display mode check operation to exynos_mixer_ops
> in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
> on the proposed display modes. These restriction needs to be considered
> during mode negotiation, which happens immediately after edid parsing.
>
> Both, mixer check-mode and hdmi check-timing callbacks are called one after
> another and ANDed result is returned back.
>
> Signed-off-by: Rahul Sharma 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12 
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  5 -
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 13 ++---
>  3 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> index 55793c4..1c06a11 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> @@ -125,9 +125,21 @@ static int drm_hdmi_get_edid(struct device *dev,
>  static int drm_hdmi_check_timing(struct device *dev, void *timing)
>  {
> struct drm_hdmi_context *ctx = to_context(dev);
> +   int ret = 0;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> +   /*
> +   * Both, mixer and hdmi should be able to handle the requested mode.
> +   * If any of the two fails, return mode as BAD.
> +   */
> +
> +   if (mixer_ops && mixer_ops->check_timing)
> +   ret = mixer_ops->check_timing(ctx->mixer_ctx->ctx, timing);
> +
> +   if (ret)
> +   return ret;
> +
> if (hdmi_ops && hdmi_ops->check_timing)
> return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 784a7e9..f5202af 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -32,7 +32,7 @@ struct exynos_hdmi_ops {
> bool (*is_connected)(void *ctx);
> int (*get_edid)(void *ctx, struct drm_connector *connector,
> u8 *edid, int len);
> -   int (*check_timing)(void *ctx, void *timing);
> +   int (*check_timing)(void *ctx, struct fb_videomode *timing);
> int (*power_on)(void *ctx, int mode);
>
> /* manager */
> @@ -58,6 +58,9 @@ struct exynos_mixer_ops {
> void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
> void (*win_commit)(void *ctx, int zpos);
> void (*win_disable)(void *ctx, int zpos);
> +
> +   /* display */
> +   int (*check_timing)(void *ctx, struct fb_videomode *timing);
>  };
>
>  void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2c46b6c..d9d742a 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1464,21 +1464,20 @@ static int hdmi_v14_check_timing(struct fb_videomode 
> *check_timing)
> return -EINVAL;
>  }
>
> -static int hdmi_check_timing(void *ctx, void *timing)
> +static int hdmi_check_timing(void *ctx, struct fb_videomode *timing)
>  {
> struct hdmi_context *hdata = ctx;
> -   struct fb_videomode *check_timing = timing;
>
> DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>
> -   DRM_DEBUG_KMS("[%d]x[%d] [%d]Hz [%x]\n", check_timing->xres,
> -   check_timing->yres, check_timing->refresh,
> -   check_timing->vmode);
> +   DRM_DEBUG_KMS("[%d]x[%d] [%d]Hz [%x]\n", timing->xres,
> +   timing->yres, timing->refresh,
> +   timing->vmode);
>
> if (hdata->type == HDMI_TYPE13)
> -   return hdmi_v13_check_timing(check_timing);
> +   return hdmi_v13_check_timing(timing);
> else
> -   return hdmi_v14_check_timing(check_timing);
> +   return hdmi_v14_check_timing(timing);
>  }
>
>  static void hdmi_set_acr(u32 freq, u8 *acr)
> --
> 1.8.0
>

[PATCH v2 2/4] drm/exynos: implement display-mode-check callback in mixer driver

[Sean Paul]

On Fri, Jan 4, 2013 at 8:53 AM, Rahul Sharma  
wrote:
> This patch adds the implementation of check_mode callback in the mixer

s/check_mode/check_timing/

> driver. Based on the mixer version, correct set of restrictions will be
> exposed by the mixer driver. A resolution will be acceptable only if passes
> the criteria set by mixer and hdmi IPs.
>
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 21db895..c1f2e7a 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -810,6 +810,29 @@ static void mixer_win_disable(void *ctx, int win)
> mixer_ctx->win_data[win].enabled = false;
>  }
>
> +int mixer_check_timing(void *ctx, struct fb_videomode *timing)
> +{
> +   struct mixer_context *mixer_ctx = ctx;
> +   unsigned int w, h;

xres and yres are defined as u32 in fb_videomode

> +
> +   w = timing->xres;
> +   h = timing->yres;
> +
> +   DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
> +   __func__, timing->xres, timing->yres,
> +   timing->refresh, (timing->vmode &
> +   FB_VMODE_INTERLACED) ? true : false);
> +
> +   if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16)
> +   return 0;
> +
> +   if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> +   (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> +   (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
> +   return 0;
> +
> +   return -EINVAL;
> +}
>  static void mixer_wait_for_vblank(void *ctx)
>  {
> struct mixer_context *mixer_ctx = ctx;
> @@ -947,6 +970,9 @@ static struct exynos_mixer_ops mixer_ops = {
> .win_mode_set   = mixer_win_mode_set,
> .win_commit = mixer_win_commit,
> .win_disable= mixer_win_disable,
> +
> +   /* display */
> +   .check_timing   = mixer_check_timing,
>  };
>
>  /* for pageflip event */
> --
> 1.8.0
>

radeon CS parser refactoring

[Alex Deucher]

On Wed, Jan 2, 2013 at 6:27 PM, Ilija Hadzic
 wrote:
> The following set of patches refactor the CS-parser logic
> in an effort to consolidate the code that is repeated across
> ASIC-specific files. All patches except #8 are function-neutral,
> that is they preserve the existing functionality of the driver.
> Patch #8 adds one extra check for WAIT_REG_MEM packet that I
> believe should be there.
>
> I have been running with these patches for about a month on several
> machines with Evergreen and NI GPUs without noticing any regressions.
> I also ran quick tests on all Radeon GPUs that I had around, which
> range from R300 through NI cards.
>
> The patches have been rebased to the current state of Dave's drm-next
> branch.

Looks good to me.  Nice clean up.  As long as there are no regressions
with UMS, consider them applied.

Thanks!

Alex

[RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron

[Alex Deucher]

On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst
 wrote:
> vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
> configuration space is not restored correctly, resulting in MSI not working 
> after switch.
>
> Only useful item in dmesg is:
>
> [   33.922807] radeon :01:00.0: Refused to change power state, currently 
> in D3
>
> I did some testing, dumping the difference in ms between first succesful 
> switch
> from D3 to D0, and it seems that there is slightly more than 20 ms difference 
> when
> the device is re-enabled through vga-switcheroo.
>
> So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not 
> working
> on my system after switcheroo-ing.

I guess if it fixes it...  Has anyone seen similar problems on non-mac
systems?  What is the delay normally set to?  It seems pretty
innocuous other than potentially adding a little extra latency.  Do
you think it makes sense to make it more like a quirk and only apply
it to problematic systems or just apply across the board?

Alex

>
> Signed-off-by: Maarten Lankhorst 
>
> ---
>
> This is a RFC patch since I feel what I'm doing is done in a hackish way,
> but it seems only the D3->D0 transition during switcheroo enable is affected,
> other transitions like suspend/resume and switcheroo poweroff seem unaffected.
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 5515921..8816958 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev 
> *pdev, enum vga_switchero
> struct drm_device *dev = pci_get_drvdata(pdev);
> pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
> if (state == VGA_SWITCHEROO_ON) {
> +   unsigned d3_delay = dev->pdev->d3_delay;
> +
> printk(KERN_INFO "radeon: switched on\n");
> /* don't suspend or resume card normally */
> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> +
> +   if (dev->pdev->d3_delay < 20)
> +   dev->pdev->d3_delay = 20;
> +
> radeon_resume_kms(dev);
> +
> +   dev->pdev->d3_delay = d3_delay;
> +
> dev->switch_power_state = DRM_SWITCH_POWER_ON;
> drm_kms_helper_poll_enable(dev);
> } else {
>

[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

[Vikas Sajjan]

Hi Mr. Figa,

Thanks for reviewing.

On 3 January 2013 16:29, Tomasz Figa  wrote:
> Hi Vikas,
>
> On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
>> From: Vikas Sajjan 
>>
>> Signed-off-by: Vikas Sajjan 
>> ---
>>  include/video/display.h |6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/include/video/display.h b/include/video/display.h
>> index b639fd0..fb2f437 100644
>> --- a/include/video/display.h
>> +++ b/include/video/display.h
>> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
>>
>>   void (*enable_hs)(struct video_source *src, bool enable);
>>
>> + /* frame related */
>> + int (*get_frame_done)(struct video_source *src);
>> + int (*clear_frame_done)(struct video_source *src);
>> + int (*set_early_blank_mode)(struct video_source *src, int power);
>> + int (*set_blank_mode)(struct video_source *src, int power);
>> +
>
> I'm not sure if all those extra ops are needed in any way.
>
> Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
> FB_BLANK_UNBLANK status, which basically equals to the already existing
> enable operation, while set_early_blank mode handles only
> FB_BLANK_POWERDOWN, being equal to disable callback.
>

Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
of now, but FB_BLANK_NORMAL will be supported in future.
If not for Exynos, i think it will be need for other SoCs which
support  FB_BLANK_UNBLANK and FB_BLANK_NORMAL.

> Both get_frame_done and clear_frame_done do not look at anything used at
> the moment and if frame done status monitoring will be ever needed, I
> think a better way should be implemented.
>
You are right, as of now Exynos MIPI DSI Panels are NOT using these
callbacks, but as you mentioned we will need frame done status
monitoring anyways, so i included these callbacks here. Will check, if
we can implement any better method.

> Best regards,
> --
> Tomasz Figa
> Samsung Poland R Center
> SW Solution Development, Linux Platform
>



-- 
Thanks and Regards
 Vikas Sajjan

[PATCH] drm/radeon: split r6xx and r7xx copy_dma functions

[alexdeuc...@gmail.com]

From: Alex Deucher 

- r6xx actually uses a slightly different packet format,
although both formats seem to work ok.
- r7xx doesn't have the count multiple of 2 limitation.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/r600.c|   10 ++--
 drivers/gpu/drm/radeon/radeon_asic.c |4 +-
 drivers/gpu/drm/radeon/radeon_asic.h |4 ++
 drivers/gpu/drm/radeon/rv770.c   |   74 ++
 4 files changed, 85 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 923f936..537e259 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2646,7 +2646,7 @@ int r600_copy_blit(struct radeon_device *rdev,
  * @num_gpu_pages: number of GPU pages to xfer
  * @fence: radeon fence object
  *
- * Copy GPU paging using the DMA engine (r6xx-r7xx).
+ * Copy GPU paging using the DMA engine (r6xx).
  * Used by the radeon ttm implementation to move pages if
  * registered as the asic copy callback.
  */
@@ -2669,8 +2669,8 @@ int r600_copy_dma(struct radeon_device *rdev,
}

size_in_dw = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT) / 4;
-   num_loops = DIV_ROUND_UP(size_in_dw, 0x);
-   r = radeon_ring_lock(rdev, ring, num_loops * 5 + 8);
+   num_loops = DIV_ROUND_UP(size_in_dw, 0xFFFE);
+   r = radeon_ring_lock(rdev, ring, num_loops * 4 + 8);
if (r) {
DRM_ERROR("radeon: moving bo (%d).\n", r);
radeon_semaphore_free(rdev, , NULL);
@@ -2693,8 +2693,8 @@ int r600_copy_dma(struct radeon_device *rdev,
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0, 
cur_size_in_dw));
radeon_ring_write(ring, dst_offset & 0xfffc);
radeon_ring_write(ring, src_offset & 0xfffc);
-   radeon_ring_write(ring, upper_32_bits(dst_offset) & 0xff);
-   radeon_ring_write(ring, upper_32_bits(src_offset) & 0xff);
+   radeon_ring_write(ring, (((upper_32_bits(dst_offset) & 0xff) << 
16) |
+(upper_32_bits(src_offset) & 0xff)));
src_offset += cur_size_in_dw * 4;
dst_offset += cur_size_in_dw * 4;
}
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 596bcbe..9056faf 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1140,9 +1140,9 @@ static struct radeon_asic rv770_asic = {
.copy = {
.blit = _copy_blit,
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
-   .dma = _copy_dma,
+   .dma = _copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = _copy_dma,
+   .copy = _copy_dma,
.copy_ring_index = R600_RING_TYPE_DMA_INDEX,
},
.surface = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 5f4882c..15d70e6 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -403,6 +403,10 @@ u32 rv770_page_flip(struct radeon_device *rdev, int crtc, 
u64 crtc_base);
 void r700_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc);
 void r700_cp_stop(struct radeon_device *rdev);
 void r700_cp_fini(struct radeon_device *rdev);
+int rv770_copy_dma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+  struct radeon_fence **fence);

 /*
  * evergreen
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 87c979c..1b2444f 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -887,6 +887,80 @@ static int rv770_mc_init(struct radeon_device *rdev)
return 0;
 }

+/**
+ * rv770_copy_dma - copy pages using the DMA engine
+ *
+ * @rdev: radeon_device pointer
+ * @src_offset: src GPU address
+ * @dst_offset: dst GPU address
+ * @num_gpu_pages: number of GPU pages to xfer
+ * @fence: radeon fence object
+ *
+ * Copy GPU paging using the DMA engine (r7xx).
+ * Used by the radeon ttm implementation to move pages if
+ * registered as the asic copy callback.
+ */
+int rv770_copy_dma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+ struct radeon_fence **fence)
+{
+   struct radeon_semaphore *sem = NULL;
+   int ring_index = rdev->asic->copy.dma_ring_index;
+   struct radeon_ring *ring = >ring[ring_index];
+   u32 size_in_dw, cur_size_in_dw;
+   int i, num_loops;
+   int r = 0;
+
+   r = radeon_semaphore_create(rdev, );
+   if (r) {
+   DRM_ERROR("radeon: moving bo (%d).\n", r);
+   return r;
+   }
+
+   size_in_dw = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT) / 4;
+   

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Alex Deucher]

On Fri, Jan 4, 2013 at 6:16 AM, Boszormenyi Zoltan  wrote:
> 2013-01-04 08:40 keltez?ssel, Borislav Petkov ?rta:
>
>> On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
>>>
>>> From: Alex Deucher 
>>> Date: Wed, 2 Jan 2013 18:30:21 -0500
>>> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>>>
>>> count must be a multiple of 2.
>>>
>>> Cc: Borislav Petkov 
>>> Cc: Markus Trippelsdorf 
>>> Signed-off-by: Alex Deucher 
>>
>> Thanks, will run it on the box in question next week when I have access.
>>
>> Btw, you could add the note about count needing to be a multiple of 2 as
>> a comment in the code below, for future reference.
>>
>>> ---
>>>   drivers/gpu/drm/radeon/r600.c |4 ++--
>>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/r600.c
>>> b/drivers/gpu/drm/radeon/r600.c
>>> index 2aaf147..9f4ce5e 100644
>>> --- a/drivers/gpu/drm/radeon/r600.c
>>> +++ b/drivers/gpu/drm/radeon/r600.c
>>> @@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
>>> for (i = 0; i < num_loops; i++) {
>>> cur_size_in_dw = size_in_dw;
>>> -   if (cur_size_in_dw > 0x)
>>> -   cur_size_in_dw = 0x;
>>> +   if (cur_size_in_dw > 0xFFFE)
>>> +   cur_size_in_dw = 0xFFFE;
>
>
> How about any other odd numbers? Like 0xFFFB, or 0x0003?
> They will get passed as is after this change, no? Shouldn't they
> be also fixed? Something like this below?
>
>   if (cur_size_in_dw & 0x0001)
>cur_size_in_dw &= ~1;


This function only deals with pages so they will always be even.

Alex

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

--- Comment #3 from Adam Jorgensen  ---
Created attachment 72498
  --> https://bugs.freedesktop.org/attachment.cgi?id=72498=edit
Current Status as of 04/01/2013

The Main Steam Window is now displayed perfectly, but drop-down menus and
pop-out windows are ALWAYS corrupt, even when maximised.

-- 
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/20130104/8eb1e636/attachment.html>

[PATCH v2 4/4] drm/exynos: hdmi: support extra resolutions using drm_display_mode timings

[Rahul Sharma]

From: Sean Paul 

This patch programs the core and timing generator registers using the
timing data provided in drm_display_mode and not using hard-coded
configurations.

Additional PHY configs has been added. This allows us to support more
permissible resolutions and refresh rates.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
Signed-off-by: Shirish S 
Signed-off-by: Akshay Saraswat 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1022 +-
 1 file changed, 374 insertions(+), 648 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d9d742a..f5eb986 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -88,6 +88,73 @@ struct hdmi_resources {
int regul_count;
 };

+struct hdmi_tg_regs {
+   u8 cmd[1];
+   u8 h_fsz[2];
+   u8 hact_st[2];
+   u8 hact_sz[2];
+   u8 v_fsz[2];
+   u8 vsync[2];
+   u8 vsync2[2];
+   u8 vact_st[2];
+   u8 vact_sz[2];
+   u8 field_chg[2];
+   u8 vact_st2[2];
+   u8 vact_st3[2];
+   u8 vact_st4[2];
+   u8 vsync_top_hdmi[2];
+   u8 vsync_bot_hdmi[2];
+   u8 field_top_hdmi[2];
+   u8 field_bot_hdmi[2];
+   u8 tg_3d[1];
+};
+
+struct hdmi_core_regs {
+   u8 h_blank[2];
+   u8 v2_blank[2];
+   u8 v1_blank[2];
+   u8 v_line[2];
+   u8 h_line[2];
+   u8 hsync_pol[1];
+   u8 vsync_pol[1];
+   u8 int_pro_mode[1];
+   u8 v_blank_f0[2];
+   u8 v_blank_f1[2];
+   u8 h_sync_start[2];
+   u8 h_sync_end[2];
+   u8 v_sync_line_bef_2[2];
+   u8 v_sync_line_bef_1[2];
+   u8 v_sync_line_aft_2[2];
+   u8 v_sync_line_aft_1[2];
+   u8 v_sync_line_aft_pxl_2[2];
+   u8 v_sync_line_aft_pxl_1[2];
+   u8 v_blank_f2[2]; /* for 3D mode */
+   u8 v_blank_f3[2]; /* for 3D mode */
+   u8 v_blank_f4[2]; /* for 3D mode */
+   u8 v_blank_f5[2]; /* for 3D mode */
+   u8 v_sync_line_aft_3[2];
+   u8 v_sync_line_aft_4[2];
+   u8 v_sync_line_aft_5[2];
+   u8 v_sync_line_aft_6[2];
+   u8 v_sync_line_aft_pxl_3[2];
+   u8 v_sync_line_aft_pxl_4[2];
+   u8 v_sync_line_aft_pxl_5[2];
+   u8 v_sync_line_aft_pxl_6[2];
+   u8 vact_space_1[2];
+   u8 vact_space_2[2];
+   u8 vact_space_3[2];
+   u8 vact_space_4[2];
+   u8 vact_space_5[2];
+   u8 vact_space_6[2];
+};
+
+struct hdmi_v14_conf {
+   int pixel_clock;
+   struct hdmi_core_regs core;
+   struct hdmi_tg_regs tg;
+   int cea_video_id;
+};
+
 struct hdmi_context {
struct device   *dev;
struct drm_device   *drm_dev;
@@ -106,6 +173,7 @@ struct hdmi_context {

/* current hdmiphy conf index */
int cur_conf;
+   struct hdmi_v14_confmode_conf;

struct hdmi_resources   res;

@@ -394,586 +462,132 @@ static const struct hdmi_v13_conf hdmi_v13_confs[] = {
 };

 /* HDMI Version 1.4 */
-static const u8 hdmiphy_conf27_027[32] = {
-   0x01, 0xd1, 0x2d, 0x72, 0x40, 0x64, 0x12, 0x08,
-   0x43, 0xa0, 0x0e, 0xd9, 0x45, 0xa0, 0xac, 0x80,
-   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xe3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf74_176[32] = {
-   0x01, 0xd1, 0x1f, 0x10, 0x40, 0x5b, 0xef, 0x08,
-   0x81, 0xa0, 0xb9, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x5a, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xa6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf74_25[32] = {
-   0x01, 0xd1, 0x1f, 0x10, 0x40, 0x40, 0xf8, 0x08,
-   0x81, 0xa0, 0xba, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x3c, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xa5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf148_5[32] = {
-   0x01, 0xd1, 0x1f, 0x00, 0x40, 0x40, 0xf8, 0x08,
-   0x81, 0xa0, 0xba, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x3c, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0x4b, 0x25, 0x03, 0x00, 0x00, 0x01, 0x00,
-};
-
-struct hdmi_tg_regs {
-   u8 cmd;
-   u8 h_fsz_l;
-   u8 h_fsz_h;
-   u8 hact_st_l;
-   u8 hact_st_h;
-   u8 hact_sz_l;
-   u8 hact_sz_h;
-   u8 v_fsz_l;
-   u8 v_fsz_h;
-   u8 vsync_l;
-   u8 vsync_h;
-   u8 vsync2_l;
-   u8 vsync2_h;
-   u8 vact_st_l;
-   u8 vact_st_h;
-   u8 vact_sz_l;
-   u8 vact_sz_h;
-   u8 field_chg_l;
-   u8 field_chg_h;
-   u8 vact_st2_l;
-   u8 vact_st2_h;
-   u8 vact_st3_l;
-   u8 vact_st3_h;
-   u8 vact_st4_l;
-   u8 vact_st4_h;
-   u8 vsync_top_hdmi_l;
-   u8 vsync_top_hdmi_h;
-   u8 vsync_bot_hdmi_l;
-   u8 vsync_bot_hdmi_h;
-   u8 field_top_hdmi_l;
-   u8 field_top_hdmi_h;
-   u8 field_bot_hdmi_l;
-   u8 field_bot_hdmi_h;
-   u8 tg_3d;
-};
-
-struct 

[PATCH v2 3/4] drm/exynos: mixer: set correct mode for range of resolutions

[Rahul Sharma]

With this patch, mixer driver find the correct resolution mode for
the range of resolutions, upto 1080 vertical lines. Resolution will
be categorized to NTSC SD, PAL SD or HD and the correct mode is
set to the mixer configuration register.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c1f2e7a..59ab776 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -283,13 +283,13 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
MXR_CFG_SCAN_PROGRASSIVE);

/* choosing between porper HD and SD mode */
-   if (height == 480)
+   if (height <= 480)
val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height == 576)
+   else if (height <= 576)
val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height == 720)
+   else if (height <= 720)
val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height == 1080)
+   else if (height <= 1080)
val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
else
val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-- 
1.8.0

[PATCH v2 2/4] drm/exynos: implement display-mode-check callback in mixer driver

[Rahul Sharma]

This patch adds the implementation of check_mode callback in the mixer
driver. Based on the mixer version, correct set of restrictions will be
exposed by the mixer driver. A resolution will be acceptable only if passes
the criteria set by mixer and hdmi IPs.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 21db895..c1f2e7a 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -810,6 +810,29 @@ static void mixer_win_disable(void *ctx, int win)
mixer_ctx->win_data[win].enabled = false;
 }

+int mixer_check_timing(void *ctx, struct fb_videomode *timing)
+{
+   struct mixer_context *mixer_ctx = ctx;
+   unsigned int w, h;
+
+   w = timing->xres;
+   h = timing->yres;
+
+   DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
+   __func__, timing->xres, timing->yres,
+   timing->refresh, (timing->vmode &
+   FB_VMODE_INTERLACED) ? true : false);
+
+   if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16)
+   return 0;
+
+   if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
+   (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
+   (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
+   return 0;
+
+   return -EINVAL;
+}
 static void mixer_wait_for_vblank(void *ctx)
 {
struct mixer_context *mixer_ctx = ctx;
@@ -947,6 +970,9 @@ static struct exynos_mixer_ops mixer_ops = {
.win_mode_set   = mixer_win_mode_set,
.win_commit = mixer_win_commit,
.win_disable= mixer_win_disable,
+
+   /* display */
+   .check_timing   = mixer_check_timing,
 };

 /* for pageflip event */
-- 
1.8.0

[PATCH v2 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct

[Rahul Sharma]

This patch adds the display mode check operation to exynos_mixer_ops
in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
on the proposed display modes. These restriction needs to be considered
during mode negotiation, which happens immediately after edid parsing.

Both, mixer check-mode and hdmi check-timing callbacks are called one after
another and ANDed result is returned back.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12 
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  5 -
 drivers/gpu/drm/exynos/exynos_hdmi.c | 13 ++---
 3 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 55793c4..1c06a11 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -125,9 +125,21 @@ static int drm_hdmi_get_edid(struct device *dev,
 static int drm_hdmi_check_timing(struct device *dev, void *timing)
 {
struct drm_hdmi_context *ctx = to_context(dev);
+   int ret = 0;

DRM_DEBUG_KMS("%s\n", __FILE__);

+   /*
+   * Both, mixer and hdmi should be able to handle the requested mode.
+   * If any of the two fails, return mode as BAD.
+   */
+
+   if (mixer_ops && mixer_ops->check_timing)
+   ret = mixer_ops->check_timing(ctx->mixer_ctx->ctx, timing);
+
+   if (ret)
+   return ret;
+
if (hdmi_ops && hdmi_ops->check_timing)
return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 784a7e9..f5202af 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -32,7 +32,7 @@ struct exynos_hdmi_ops {
bool (*is_connected)(void *ctx);
int (*get_edid)(void *ctx, struct drm_connector *connector,
u8 *edid, int len);
-   int (*check_timing)(void *ctx, void *timing);
+   int (*check_timing)(void *ctx, struct fb_videomode *timing);
int (*power_on)(void *ctx, int mode);

/* manager */
@@ -58,6 +58,9 @@ struct exynos_mixer_ops {
void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
void (*win_commit)(void *ctx, int zpos);
void (*win_disable)(void *ctx, int zpos);
+
+   /* display */
+   int (*check_timing)(void *ctx, struct fb_videomode *timing);
 };

 void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c46b6c..d9d742a 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1464,21 +1464,20 @@ static int hdmi_v14_check_timing(struct fb_videomode 
*check_timing)
return -EINVAL;
 }

-static int hdmi_check_timing(void *ctx, void *timing)
+static int hdmi_check_timing(void *ctx, struct fb_videomode *timing)
 {
struct hdmi_context *hdata = ctx;
-   struct fb_videomode *check_timing = timing;

DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);

-   DRM_DEBUG_KMS("[%d]x[%d] [%d]Hz [%x]\n", check_timing->xres,
-   check_timing->yres, check_timing->refresh,
-   check_timing->vmode);
+   DRM_DEBUG_KMS("[%d]x[%d] [%d]Hz [%x]\n", timing->xres,
+   timing->yres, timing->refresh,
+   timing->vmode);

if (hdata->type == HDMI_TYPE13)
-   return hdmi_v13_check_timing(check_timing);
+   return hdmi_v13_check_timing(timing);
else
-   return hdmi_v14_check_timing(check_timing);
+   return hdmi_v14_check_timing(timing);
 }

 static void hdmi_set_acr(u32 freq, u8 *acr)
-- 
1.8.0

[PATCH v2 0/4] drm/exynos: add support for extra resolutions to exynos5

[Rahul Sharma]

This patch set adds support for more resolutions and refresh rates to Samsung
Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).

Given resolution will be supported or not, is decided by two factors:
1) Corresponding pixel clock is supported by hdmi PHY.
2) Mixer supports the display mode.

V2:
- change mixer callback name to check_timing from check_mode
- callback parameter is changed to type "struct fb_videomode *" from "void *"
- organised the implementation of check_timing callback in mixer driver.

This patch series is based on branch "exynos-drm-next" at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

Rahul Sharma (3):
  drm/exynos: add display-mode-check operation to exynos_mixer_ops
struct
  drm/exynos: implement display-mode-check callback in mixer driver
  drm/exynos: mixer: set correct mode for range of resolutions

Sean Paul (1):
  drm/exynos: hdmi: support extra resolutions using drm_display_mode
timings

 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   12 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |5 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1035 +++---
 drivers/gpu/drm/exynos/exynos_mixer.c|   34 +-
 4 files changed, 426 insertions(+), 660 deletions(-)

-- 
1.8.0

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

--- Comment #2 from Adam Jorgensen  ---
Created attachment 72497
  --> https://bugs.freedesktop.org/attachment.cgi?id=72497=edit
Big Screen Mode works perfectly but is slow

The Big Screen mode seems to work fine, possibly because it functions as a pure
OpenGL application?

-- 
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/20130104/6d2460de/attachment.html>

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

--- Comment #1 from Adam Jorgensen  ---
Created attachment 72496
  --> https://bugs.freedesktop.org/attachment.cgi?id=72496=edit
Less corruption when Steam Windows are maximised

When a window is maximised the corruption is a lot less (Since the latest
version of the Steam Linux client is gone, except for drop-down menus and
pop-out windows (Like the Friend List) which are ALWAYS corrupt)

-- 
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/20130104/56e57f73/attachment.html>

[Bug 59015] New: Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages

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

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

  Priority: medium
Bug ID: 59015
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Steam Beta: Graphical Corruption in certain parts of
application tied to "kernel rejected CS" messages
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: adam.jorgensen.za at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 9.0
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 72495
  --> https://bugs.freedesktop.org/attachment.cgi?id=72495=edit
Major Graphical Corruption Occurring in Windows that are not Maximised

I am participating in the Steam Linux Beta and am experiencing graphical
corruption as captured in the screenshots attached to this ticket.

By starting Steam from the command-line I was able to observe logging messages
and noticed that every time a graphical corruption artifact occurs the
application outputs the message:

"radeon: The kernel rejected CS, see dmesg for more information."

An examination of dmesg reveals messages as follows:

"
[ 2491.179581] radeon :02:00.0: r600_cs_track_validate_cb invalid tiling 6
for 0 (0x08110668)
[ 2491.179588] radeon :02:00.0: r600_packet3_check:1913 invalid cmd stream
566
[ 2491.179592] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
"

Relevant system info:

1.6ghz Core i7 CPU
8gb DDR3 RAM
Radeon HD 4570 with 512mb DDR2 VRAM using open-source XF86 ATI 7.0.0 drivers
10gb free on root, 30+gb free on home
Kernel 3.6, X.org 1.12.4, KDE 4.9.4 running with OpenGL Compositing
Primary display is 1440x900 laptop LCD, secondary is 24" 1920x1080 LCD

-- 
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/20130104/b1934b3f/attachment-0001.html>

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Borislav Petkov]

On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
> From: Alex Deucher 
> Date: Wed, 2 Jan 2013 18:30:21 -0500
> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
> 
> count must be a multiple of 2.
> 
> Cc: Borislav Petkov 
> Cc: Markus Trippelsdorf 
> Signed-off-by: Alex Deucher 

Thanks, will run it on the box in question next week when I have access.

Btw, you could add the note about count needing to be a multiple of 2 as
a comment in the code below, for future reference.

> ---
>  drivers/gpu/drm/radeon/r600.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 2aaf147..9f4ce5e 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
>  
>   for (i = 0; i < num_loops; i++) {
>   cur_size_in_dw = size_in_dw;
> - if (cur_size_in_dw > 0x)
> - cur_size_in_dw = 0x;
> + if (cur_size_in_dw > 0xFFFE)
> + cur_size_in_dw = 0xFFFE;
>   size_in_dw -= cur_size_in_dw;
>   radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0, 
> cur_size_in_dw));
>   radeon_ring_write(ring, dst_offset & 0xfffc);
> -- 
> 1.7.7.5

-- 
Regards/Gruss,
Boris.

[PATCH v4] drm/exynos: let drm handle edid allocations

[Rahul Sharma]

There's no need to allocate edid twice and do a memcpy when drm helpers
exist to do just that. This patch cleans that interaction up, and
doesn't keep the edid hanging around in the connector.

v4:
- removed error check for drm_mode_connector_update_edid_property
which is expected to fail for Virtual Connectors like VIDI.
Thanks to Seung-Woo Kim.

v3:
- removed MAX_EDID as it is not used anymore.

v2:
- changed vidi_get_edid callback inside vidi driver.

Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
Signed-off-by: Seung-Woo Kim 
---
This patch is based on branch "exynos-drm-next" at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

 drivers/gpu/drm/exynos/exynos_drm_connector.c | 33 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  9 
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 19 ++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 25 
 6 files changed, 46 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index ab37437..4c5b685 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -18,7 +18,6 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_encoder.h"

-#define MAX_EDID 256
 #define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\
drm_connector)

@@ -96,7 +95,9 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
to_exynos_connector(connector);
struct exynos_drm_manager *manager = exynos_connector->manager;
struct exynos_drm_display_ops *display_ops = manager->display_ops;
-   unsigned int count;
+   struct edid *edid = NULL;
+   unsigned int count = 0;
+   int ret;

DRM_DEBUG_KMS("%s\n", __FILE__);

@@ -114,27 +115,21 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
 * because lcd panel has only one mode.
 */
if (display_ops->get_edid) {
-   int ret;
-   void *edid;
-
-   edid = kzalloc(MAX_EDID, GFP_KERNEL);
-   if (!edid) {
-   DRM_ERROR("failed to allocate edid\n");
-   return 0;
+   edid = display_ops->get_edid(manager->dev, connector);
+   if (IS_ERR_OR_NULL(edid)) {
+   ret = PTR_ERR(edid);
+   edid = NULL;
+   DRM_ERROR("Panel operation get_edid failed %d\n", ret);
+   goto out;
}

-   ret = display_ops->get_edid(manager->dev, connector,
-   edid, MAX_EDID);
-   if (ret < 0) {
-   DRM_ERROR("failed to get edid data.\n");
-   kfree(edid);
-   edid = NULL;
-   return 0;
+   count = drm_add_edid_modes(connector, edid);
+   if (count < 0) {
+   DRM_ERROR("Add edid modes failed %d\n", count);
+   goto out;
}

drm_mode_connector_update_edid_property(connector, edid);
-   count = drm_add_edid_modes(connector, edid);
-   kfree(edid);
} else {
struct exynos_drm_panel_info *panel;
struct drm_display_mode *mode = drm_mode_create(connector->dev);
@@ -161,6 +156,8 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
count = 1;
}

+out:
+   kfree(edid);
return count;
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b9e51bc..4606fac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -148,8 +148,8 @@ struct exynos_drm_overlay {
 struct exynos_drm_display_ops {
enum exynos_drm_output_type type;
bool (*is_connected)(struct device *dev);
-   int (*get_edid)(struct device *dev, struct drm_connector *connector,
-   u8 *edid, int len);
+   struct edid *(*get_edid)(struct device *dev,
+   struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
int (*check_timing)(struct device *dev, void *timing);
int (*power_on)(struct device *dev, int mode);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 55793c4..a17d752 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -108,18 +108,17 @@ static bool drm_hdmi_is_connected(struct device *dev)
return false;
 }

radeon CS parser refactoring

[Dave Airlie]

> The following set of patches refactor the CS-parser logic
> in an effort to consolidate the code that is repeated across
> ASIC-specific files. All patches except #8 are function-neutral,
> that is they preserve the existing functionality of the driver.
> Patch #8 adds one extra check for WAIT_REG_MEM packet that I
> believe should be there.
>
> I have been running with these patches for about a month on several
> machines with Evergreen and NI GPUs without noticing any regressions.
> I also ran quick tests on all Radeon GPUs that I had around, which
> range from R300 through NI cards.

Did you run these with pre-kms userspace etc to make sure it doesn't
cause regressions there?

Dave.

[git pull] radeon and minor nouveau fixes

[Dave Airlie]

Hi Linus,

Just a radeon pull from Alex, fixes a few regressions since 3.7 and 
reworks some of the reset handling, and two minor nouveau fixes I found on 
the list, Ben will be back next week to take care of the couple of larger 
nouveau patches that I see outstanding.

Dave.

The following changes since commit d5757dbe79870d825d0dec30074d48683e1d7e9a:

  Revert "drm: tegra: protect DC register access with mutex" (2012-12-30 
21:58:20 +1000)

are available in the git repository at:

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

for you to fetch changes up to eda85d6ad490923152544fba0473798b6cc0edf6:

  drm/nouveau: fix init with agpgart-uninorth (2013-01-04 16:04:33 +1000)


Aaro Koskinen (1):
  drm/nouveau: fix init with agpgart-uninorth

Alex Deucher (8):
  drm/radeon: add connector table for Mac G4 Silver
  drm/radeon/r6xx: fix DMA engine for ttm bo transfers
  drm/radeon: fix typo in evergreen dma fence
  drm/radeon: add GPU reset flags
  drm/radeon: switch to a finer grained reset for r6xx/7xx
  drm/radeon: switch to a finer grained reset for evergreen
  drm/radeon: switch to a finer grained reset for cayman/TN
  drm/radeon: switch to a finer grained reset for SI (v2)

Dave Airlie (1):
  Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux 
into drm-next

Guenter Roeck (1):
  drm: nouveau: Fix build warning seen if HWMON is undefined

Jerome Glisse (4):
  drm/radeon: add debugfs file for dma rings
  drm/radeon: improve ring debugfs printing
  drm/radeon: print dma status reg on lockup (v2)
  drm/radeon: reset dma engine on gpu reset (v2)

Niels Ole Salscheider (1):
  drm/radeon: Properly handle DDC probe for DP bridges

 drivers/gpu/drm/nouveau/nouveau_bo.c   |   2 +-
 drivers/gpu/drm/nouveau/nouveau_pm.c   |   4 +-
 drivers/gpu/drm/radeon/evergreen.c |  86 +--
 drivers/gpu/drm/radeon/evergreend.h|  14 +++-
 drivers/gpu/drm/radeon/ni.c| 106 +
 drivers/gpu/drm/radeon/nid.h   |   3 +-
 drivers/gpu/drm/radeon/r600.c  |  89 ++--
 drivers/gpu/drm/radeon/radeon.h|   5 ++
 drivers/gpu/drm/radeon/radeon_combios.c|  51 ++
 drivers/gpu/drm/radeon/radeon_connectors.c |  10 +--
 drivers/gpu/drm/radeon/radeon_display.c|  13 ++--
 drivers/gpu/drm/radeon/radeon_i2c.c|  10 ++-
 drivers/gpu/drm/radeon/radeon_mode.h   |   5 +-
 drivers/gpu/drm/radeon/radeon_ring.c   |  24 +--
 drivers/gpu/drm/radeon/si.c|  78 ++---
 drivers/gpu/drm/radeon/sid.h   |  18 +
 16 files changed, 416 insertions(+), 102 deletions(-)

[Bug 59015] New: Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 59015
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Steam Beta: Graphical Corruption in certain parts of
application tied to kernel rejected CS messages
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: adam.jorgensen...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 9.0
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 72495
  -- https://bugs.freedesktop.org/attachment.cgi?id=72495action=edit
Major Graphical Corruption Occurring in Windows that are not Maximised

I am participating in the Steam Linux Beta and am experiencing graphical
corruption as captured in the screenshots attached to this ticket.

By starting Steam from the command-line I was able to observe logging messages
and noticed that every time a graphical corruption artifact occurs the
application outputs the message:

radeon: The kernel rejected CS, see dmesg for more information.

An examination of dmesg reveals messages as follows:


[ 2491.179581] radeon :02:00.0: r600_cs_track_validate_cb invalid tiling 6
for 0 (0x08110668)
[ 2491.179588] radeon :02:00.0: r600_packet3_check:1913 invalid cmd stream
566
[ 2491.179592] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !


Relevant system info:

1.6ghz Core i7 CPU
8gb DDR3 RAM
Radeon HD 4570 with 512mb DDR2 VRAM using open-source XF86 ATI 7.0.0 drivers
10gb free on root, 30+gb free on home
Kernel 3.6, X.org 1.12.4, KDE 4.9.4 running with OpenGL Compositing
Primary display is 1440x900 laptop LCD, secondary is 24 1920x1080 LCD

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

--- Comment #1 from Adam Jorgensen adam.jorgensen...@gmail.com ---
Created attachment 72496
  -- https://bugs.freedesktop.org/attachment.cgi?id=72496action=edit
Less corruption when Steam Windows are maximised

When a window is maximised the corruption is a lot less (Since the latest
version of the Steam Linux client is gone, except for drop-down menus and
pop-out windows (Like the Friend List) which are ALWAYS corrupt)

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

--- Comment #2 from Adam Jorgensen adam.jorgensen...@gmail.com ---
Created attachment 72497
  -- https://bugs.freedesktop.org/attachment.cgi?id=72497action=edit
Big Screen Mode works perfectly but is slow

The Big Screen mode seems to work fine, possibly because it functions as a pure
OpenGL application?

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

--- Comment #3 from Adam Jorgensen adam.jorgensen...@gmail.com ---
Created attachment 72498
  -- https://bugs.freedesktop.org/attachment.cgi?id=72498action=edit
Current Status as of 04/01/2013

The Main Steam Window is now displayed perfectly, but drop-down menus and
pop-out windows are ALWAYS corrupt, even when maximised.

-- 
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/exynos: move finish page flip to a common place

[Rahul Sharma]

This patch implements the exynos_drm_crtc_finish_pageflip in
exynos_drm_crtc.c. This avoids the duplication of same code
in mixer, fimd and vidi.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
This patch is based on branch exynos-drm-next at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 32 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 30 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 30 +
 drivers/gpu/drm/exynos/exynos_mixer.c| 33 +++-
 5 files changed, 38 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index d59a03a..e29f262 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -393,3 +393,35 @@ void exynos_drm_crtc_disable_vblank(struct drm_device 
*dev, int crtc)
exynos_drm_fn_encoder(private-crtc[crtc], crtc,
exynos_drm_disable_vblank);
 }
+
+void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc)
+{
+   struct exynos_drm_private *dev_priv = dev-dev_private;
+   struct drm_pending_vblank_event *e, *t;
+   struct timeval now;
+   unsigned long flags;
+
+   DRM_DEBUG_KMS(%s\n, __FILE__);
+
+   spin_lock_irqsave(dev-event_lock, flags);
+
+   list_for_each_entry_safe(e, t, dev_priv-pageflip_event_list,
+   base.link) {
+   /* if event's pipe isn't same as crtc then ignore it. */
+   if (crtc != e-pipe)
+   continue;
+
+   do_gettimeofday(now);
+   e-event.sequence = 0;
+   e-event.tv_sec = now.tv_sec;
+   e-event.tv_usec = now.tv_usec;
+
+   list_move_tail(e-base.link, e-base.file_priv-event_list);
+   wake_up_interruptible(e-base.file_priv-event_wait);
+   drm_vblank_put(dev, crtc);
+   }
+
+   spin_unlock_irqrestore(dev-event_lock, flags);
+}
+
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 8ac3969..3e197e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -18,5 +18,6 @@
 int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr);
 int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int crtc);
 void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int crtc);
+void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc);
 
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..6dda825 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -663,34 +663,6 @@ static struct exynos_drm_manager fimd_manager = {
.display_ops= fimd_display_ops,
 };
 
-static void fimd_finish_pageflip(struct drm_device *drm_dev, int crtc)
-{
-   struct exynos_drm_private *dev_priv = drm_dev-dev_private;
-   struct drm_pending_vblank_event *e, *t;
-   struct timeval now;
-   unsigned long flags;
-
-   spin_lock_irqsave(drm_dev-event_lock, flags);
-
-   list_for_each_entry_safe(e, t, dev_priv-pageflip_event_list,
-   base.link) {
-   /* if event's pipe isn't same as crtc then ignore it. */
-   if (crtc != e-pipe)
-   continue;
-
-   do_gettimeofday(now);
-   e-event.sequence = 0;
-   e-event.tv_sec = now.tv_sec;
-   e-event.tv_usec = now.tv_usec;
-
-   list_move_tail(e-base.link, e-base.file_priv-event_list);
-   wake_up_interruptible(e-base.file_priv-event_wait);
-   drm_vblank_put(drm_dev, crtc);
-   }
-
-   spin_unlock_irqrestore(drm_dev-event_lock, flags);
-}
-
 static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
 {
struct fimd_context *ctx = (struct fimd_context *)dev_id;
@@ -710,7 +682,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
goto out;
 
drm_handle_vblank(drm_dev, manager-pipe);
-   fimd_finish_pageflip(drm_dev, manager-pipe);
+   exynos_drm_crtc_finish_pageflip(drm_dev, manager-pipe);
 
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(ctx-wait_vsync_event)) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3260035..b192308 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -379,34 +379,6 @@ static struct exynos_drm_manager vidi_manager = {
.display_ops= vidi_display_ops,
 };
 
-static void vidi_finish_pageflip(struct drm_device *drm_dev, int crtc)
-{
-   struct 

[PATCH] drm/exynos: move finish page flip to a common place

[Rahul Sharma]

This patch implements the exynos_drm_crtc_finish_pageflip in
exynos_drm_crtc.c. This avoids the duplication of same code
in mixer, fimd and vidi.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Stephane Marchesin marc...@chromium.org
---
This patch is based on branch exynos-drm-next at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 30 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 30 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 30 +
 drivers/gpu/drm/exynos/exynos_mixer.c| 33 +++-
 5 files changed, 36 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index d59a03a..e8894bc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -393,3 +393,33 @@ void exynos_drm_crtc_disable_vblank(struct drm_device 
*dev, int crtc)
exynos_drm_fn_encoder(private-crtc[crtc], crtc,
exynos_drm_disable_vblank);
 }
+
+void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc)
+{
+   struct exynos_drm_private *dev_priv = dev-dev_private;
+   struct drm_pending_vblank_event *e, *t;
+   struct timeval now;
+   unsigned long flags;
+
+   DRM_DEBUG_KMS(%s\n, __FILE__);
+
+   spin_lock_irqsave(dev-event_lock, flags);
+
+   list_for_each_entry_safe(e, t, dev_priv-pageflip_event_list,
+   base.link) {
+   /* if event's pipe isn't same as crtc then ignore it. */
+   if (crtc != e-pipe)
+   continue;
+
+   do_gettimeofday(now);
+   e-event.sequence = 0;
+   e-event.tv_sec = now.tv_sec;
+   e-event.tv_usec = now.tv_usec;
+
+   list_move_tail(e-base.link, e-base.file_priv-event_list);
+   wake_up_interruptible(e-base.file_priv-event_wait);
+   drm_vblank_put(dev, crtc);
+   }
+
+   spin_unlock_irqrestore(dev-event_lock, flags);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 8ac3969..3e197e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -18,5 +18,6 @@
 int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr);
 int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int crtc);
 void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int crtc);
+void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc);
 
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..6dda825 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -663,34 +663,6 @@ static struct exynos_drm_manager fimd_manager = {
.display_ops= fimd_display_ops,
 };
 
-static void fimd_finish_pageflip(struct drm_device *drm_dev, int crtc)
-{
-   struct exynos_drm_private *dev_priv = drm_dev-dev_private;
-   struct drm_pending_vblank_event *e, *t;
-   struct timeval now;
-   unsigned long flags;
-
-   spin_lock_irqsave(drm_dev-event_lock, flags);
-
-   list_for_each_entry_safe(e, t, dev_priv-pageflip_event_list,
-   base.link) {
-   /* if event's pipe isn't same as crtc then ignore it. */
-   if (crtc != e-pipe)
-   continue;
-
-   do_gettimeofday(now);
-   e-event.sequence = 0;
-   e-event.tv_sec = now.tv_sec;
-   e-event.tv_usec = now.tv_usec;
-
-   list_move_tail(e-base.link, e-base.file_priv-event_list);
-   wake_up_interruptible(e-base.file_priv-event_wait);
-   drm_vblank_put(drm_dev, crtc);
-   }
-
-   spin_unlock_irqrestore(drm_dev-event_lock, flags);
-}
-
 static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
 {
struct fimd_context *ctx = (struct fimd_context *)dev_id;
@@ -710,7 +682,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
goto out;
 
drm_handle_vblank(drm_dev, manager-pipe);
-   fimd_finish_pageflip(drm_dev, manager-pipe);
+   exynos_drm_crtc_finish_pageflip(drm_dev, manager-pipe);
 
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(ctx-wait_vsync_event)) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3260035..b192308 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -379,34 +379,6 @@ static struct exynos_drm_manager vidi_manager = {
.display_ops= vidi_display_ops,
 };
 
-static void vidi_finish_pageflip(struct 

Re: [PATCH] drm/exynos: Add device tree based discovery support for Exynos G2D

[Ajay kumar]

Hi Olof,

On Sun, Dec 30, 2012 at 11:57 AM, Olof Johansson o...@lixom.net wrote:
 Hi,

 On Thu, Dec 27, 2012 at 8:00 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
 This patch adds device tree match table for Exynos G2D controller.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
 b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 index 6ffa076..aa3d2e4 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 @@ -19,6 +19,7 @@
  #include linux/workqueue.h
  #include linux/dma-mapping.h
  #include linux/dma-attrs.h
 +#include linux/of.h

  #include drm/drmP.h
  #include drm/exynos_drm.h
 @@ -1240,6 +1241,14 @@ static int g2d_resume(struct device *dev)

  static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);

 +#ifdef CONFIG_OF
 +static const struct of_device_id exynos_g2d_match[] = {
 +   { .compatible = samsung,exynos-g2d-41 },

 What does -41 signify here?
This driver only supports G2D 4.1 version and not any lower versions of G2D!

 +   {},
 +};
 +MODULE_DEVICE_TABLE(of, exynos_g2d_match);
 +#endif
 +
  struct platform_driver g2d_driver = {
 .probe  = g2d_probe,
 .remove = __devexit_p(g2d_remove),
 @@ -1247,5 +1256,6 @@ struct platform_driver g2d_driver = {
 .name   = s5p-g2d,
 .owner  = THIS_MODULE,
 .pm = g2d_pm_ops,
 +   .of_match_table = of_match_ptr(exynos_g2d_match),

 Please provide bindings update, and cc devicetree-discuss for these
 kind of patches.
Ok. I will update with the Documentation for bindings, soon.

 -Olof

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

Re: [PATCH 2/4] drm/exynos: implement display-mode-check callback in mixer driver

[Sean Paul]

On Wed, Jan 2, 2013 at 10:37 PM, Rahul Sharma r.sh.o...@gmail.com wrote:
 On Wed, Jan 2, 2013 at 10:45 PM, Sean Paul seanp...@google.com wrote:
 On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma rahul.sha...@samsung.com 
 wrote:
 This patch adds the implementation of check_mode callback in the mixer
 driver. Based on the mixer version, correct set of restrictions will be
 exposed by the mixer driver. A resolution will be acceptable only if passes
 the criteria set by mixer and hdmi IPs.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Signed-off-by: Sean Paul seanp...@chromium.org
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c | 30 ++
  1 file changed, 30 insertions(+)

 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 21db895..093b374 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -810,6 +810,33 @@ static void mixer_win_disable(void *ctx, int win)
 mixer_ctx-win_data[win].enabled = false;
  }

 +int mixer_check_mode(void *ctx, void *mode)
 +{
 +   struct mixer_context *mixer_ctx = ctx;
 +   struct fb_videomode *check_mode = mode;

 Why not just pass fb_videomode in the first place?

 I kept the prototype same with check_timing in exynos_hdmi_ops or I
 should change in
 both the places.

Yeah, I think it should change in both places. The type doesn't need
to be opaque, IMO.


 +   unsigned int w, h;
 +
 +   w = check_mode-xres;
 +   h = check_mode-yres;
 +
 +   DRM_DEBUG_KMS(%s : xres=%d, yres=%d, refresh=%d, intl=%d\n,
 +   __func__, check_mode-xres, check_mode-yres,
 +   check_mode-refresh, (check_mode-vmode 
 +   FB_VMODE_INTERLACED) ? true : false);
 +
 +   if (mixer_ctx-mxr_ver == MXR_VER_16_0_33_0) {
 +   if ((w = 464  w = 720  h = 261  h = 576) ||
 +   (w = 1024  w = 1280 
 +   h = 576  h = 720) ||
 +   (w = 1664  w = 1920 
 +   h = 936  h = 1080))
 +   return 0;

 You could eliminate some of this spaghetti by doing:
if (mixer_ctx-mxr_ver != MXR_VER_16_0_33_0)
   return 0;

 I will do that.

 I have also added checks for min vertical lines (h = 936, h = 576,
 ..) which was
 not present in original patches. Due to this, 1920x540P was getting
 selected which
 is actually not supported by exy5 mixer.

 Above values are calculated by Min Horz lines *9 / 16.
 Please verify this part.


Yeah, I noticed that. I had assumed that the mixer could generate any
number of vertical lines from 0 to N where N is an upper bound defined
by the horizontal columns (from the HDMI Resolution Restriction
document). It's surprising to me that it can't generate that
resolution.

At any rate, you must have some information I don't, so it is what it is :)

Sean



 regards,
 Rahul Sharma.

 Then remove one level of indent from the big if statement.

 Sean

 +   } else {
 +   return 0;
 +   }
 +
 +   return -EINVAL;
 +}
  static void mixer_wait_for_vblank(void *ctx)
  {
 struct mixer_context *mixer_ctx = ctx;
 @@ -947,6 +974,9 @@ static struct exynos_mixer_ops mixer_ops = {
 .win_mode_set   = mixer_win_mode_set,
 .win_commit = mixer_win_commit,
 .win_disable= mixer_win_disable,
 +
 +   /* display */
 +   .check_mode = mixer_check_mode,
  };

  /* for pageflip event */
 --
 1.8.0

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

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Shuah Khan]

On Thu, Jan 3, 2013 at 7:12 AM, Deucher, Alexander
alexander.deuc...@amd.com wrote:
 -Original Message-
 From: Boszormenyi Zoltan [mailto:zbos...@pr.hu]
 Sent: Thursday, January 03, 2013 6:37 AM
 To: Alex Deucher
 Cc: Markus Trippelsdorf; lkml; dri-devel@lists.freedesktop.org; Deucher,
 Alexander; Borislav Petkov; Shuah Khan
 Subject: Re: radeon :02:00.0: GPU lockup CP stall for more than
 1msec

 2013-01-03 00:37 keltezéssel, Alex Deucher írta:
  On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
  mar...@trippelsdorf.de wrote:
  On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
  Please affected people can you test if patch :
  http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-
 on-r6xx-r7xx-evergen-ni-si-g.patch
 
  Fix the issue, you need to make sure you don't have the patch that
  disable dma on r6xx ie that line 977-978  1061-1062  in radeon_asic.c
  is :
.copy = r600_copy_dma,
.copy_ring_index = R600_RING_TYPE_DMA_INDEX,
  It fixes the issue for me. Thanks.
  The count is actually the count, not count - 1.  The real fix seems to
  be that r6xx requires 2 dw aligned transfers.  The attached patch
  fixes the issue for me.
 
  Alex

 I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly 
 garbage.
 Only some text, like Not on the list? below the users and small icons are
 visible
 but many user names are not rendered. http://tinypic.com/r/33xihit/6
 I am on Fedora 18/x86_64, Radeon HD6570.

 I don't think the issue you are seeing is related to this one.  Looks similar 
 to:
 https://bugs.freedesktop.org/show_bug.cgi?id=55574

 Alex


Tested the patch on 3.8-rc2 and didn't see any problems.

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

Hangcheck timer elapsed... GPU hung in 3.8.0-rc2

[J. Bruce Fields]

I got a crash after a few minutes of running 3.8.0-rc2, was able to
switch to a vt and look at dmesg:

  [  490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... 
GPU hung
  [  490.963019] [drm] capturing error event; look for more information in 
/debug/dri/0/i915_error_state
  [  492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... 
GPU hung
  [  492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring 
wedged!
  [  492.965621] [drm:i915_reset] *ERROR* Failed to reset chip.  

Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such
problem.

dmesg, config, and i915_error_state available from:

http://fieldses.org/~bfields/3.8-hang/

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

Re: Hangcheck timer elapsed... GPU hung in 3.8.0-rc2

[Josh Boyer]

On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields bfie...@fieldses.org wrote:
 I got a crash after a few minutes of running 3.8.0-rc2, was able to
 switch to a vt and look at dmesg:

   [  490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... 
 GPU hung
   [  490.963019] [drm] capturing error event; look for more information in 
 /debug/dri/0/i915_error_state
   [  492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... 
 GPU hung
   [  492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring 
 wedged!
   [  492.965621] [drm:i915_reset] *ERROR* Failed to reset chip.

 Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such
 problem.

I'm not questioning that you haven't seen that error in F17, but we have
had quite a few bug reports with similar error messages for a while now.
Apparently there are lots of ways GPUs can get hung, so they might be
different from what you're seeing.  Just wanted to point out that it
might not be a new 3.8 change that caused it.

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

Re: Hangcheck timer elapsed... GPU hung in 3.8.0-rc2

[J. Bruce Fields]

On Thu, Jan 03, 2013 at 04:16:24PM -0500, Josh Boyer wrote:
 On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields bfie...@fieldses.org wrote:
  I got a crash after a few minutes of running 3.8.0-rc2, was able to
  switch to a vt and look at dmesg:
 
[  490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer 
  elapsed... GPU hung
[  490.963019] [drm] capturing error event; look for more information in 
  /debug/dri/0/i915_error_state
[  492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer 
  elapsed... GPU hung
[  492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring 
  wedged!
[  492.965621] [drm:i915_reset] *ERROR* Failed to reset chip.
 
  Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such
  problem.
 
 I'm not questioning that you haven't seen that error in F17, but we have
 had quite a few bug reports with similar error messages for a while now.
 Apparently there are lots of ways GPUs can get hung, so they might be
 different from what you're seeing.  Just wanted to point out that it
 might not be a new 3.8 change that caused it.

OK, sure.  It reproduced very quickly after the upgrade, so I assumed it
was a regression.

I'm running 3.7.0 now which hasn't shown any problem.

I'll try a newer kernel again to see if it's really that easy for me to
reproduce.

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

Re: [PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

[Vikas Sajjan]

Hi Mr. Figa,

Thanks for reviewing.

On 3 January 2013 16:29, Tomasz Figa t.f...@samsung.com wrote:
 Hi Vikas,

 On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
 From: Vikas Sajjan vikas.saj...@linaro.org

 Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
 ---
  include/video/display.h |6 ++
  1 file changed, 6 insertions(+)

 diff --git a/include/video/display.h b/include/video/display.h
 index b639fd0..fb2f437 100644
 --- a/include/video/display.h
 +++ b/include/video/display.h
 @@ -117,6 +117,12 @@ struct dsi_video_source_ops {

   void (*enable_hs)(struct video_source *src, bool enable);

 + /* frame related */
 + int (*get_frame_done)(struct video_source *src);
 + int (*clear_frame_done)(struct video_source *src);
 + int (*set_early_blank_mode)(struct video_source *src, int power);
 + int (*set_blank_mode)(struct video_source *src, int power);
 +

 I'm not sure if all those extra ops are needed in any way.

 Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
 FB_BLANK_UNBLANK status, which basically equals to the already existing
 enable operation, while set_early_blank mode handles only
 FB_BLANK_POWERDOWN, being equal to disable callback.


Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
of now, but FB_BLANK_NORMAL will be supported in future.
If not for Exynos, i think it will be need for other SoCs which
support  FB_BLANK_UNBLANK and FB_BLANK_NORMAL.

 Both get_frame_done and clear_frame_done do not look at anything used at
 the moment and if frame done status monitoring will be ever needed, I
 think a better way should be implemented.

You are right, as of now Exynos MIPI DSI Panels are NOT using these
callbacks, but as you mentioned we will need frame done status
monitoring anyways, so i included these callbacks here. Will check, if
we can implement any better method.

 Best regards,
 --
 Tomasz Figa
 Samsung Poland RD Center
 SW Solution Development, Linux Platform




-- 
Thanks and Regards
 Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Terje Bergström]

On 21.12.2012 23:19, Stephen Warren wrote:
 I see the situation more like:
 
 * There's host1x hardware.
 
 * There's a low-level driver just for host1x itself; the host1x driver.
 
 * There's a high-level driver for the entire host1x complex of devices.
 That is tegradrm. There may be more high-level drivers in the future
 (e.g. v4l2 camera driver if it needs to aggregate a bunch of host1x
 sub-devices liek tegradrm does).
 
 * The presence of the host1x DT node logically implies that both the two
 drivers in the previous two points should be instantiated.
 
 * Linux instantiates a single device per DT node.
 
 * So, it's host1x's responsibility to instantiate the other device(s). I
 think it's reasonable for the host1x driver to know exactly what
 features the host1x HW complex supports; raw host1x access being one,
 and the higher level concept of a tegradrm being another. So, it's
 reasonable for host1x to trigger the instantiation of tegradrm.
 
 * If DRM core didn't stomp on the device object's drvdata (or whichever
 field it is), I would recommend not creating a dummy device at all, but
 rather having the host1x driver directly implement multiple driver
 interfaces. There are many examples like this already in the kernel,
 e.g. combined GPIO+IRQ driver, combined GPIO+IRQ+pinctrl driver, etc.

We had a phone call with Stephen yesterday, and I finally understood why
unbroken chain from DT to tegra-drm is important. The goals are to be
able to modprobe tegra-drm without ill effects, and to auto-load
tegra-drm module. I had been chasing a totally different goal.

Sorry about all the churn.

I think we have now two ways to go forward with cons and pros:
 1) Keep host1x and tegra-drm as separate driver
   + Code almost done
   - we need dummy device and dummy driver
   - extra code and API when host1x creates dummy device and its passed
to tegra-drm
   - tegra-drm device would need to be a child of host1x device. Having
virtual and real devices as host1x children sounds weird.

 2) Merge host1x and tegra-drm into one module. drm is a subcomponent,
and whatever other personalities we wish would also be subcomponents of
host1x. host1x calls tegra-drm directly to handle preparation for drm
initialization. As they're in the same module, circular dependency is ok.
   + Simpler conceptually (no dummy device/driver)
   + Less code
   - Proposal doesn't yet exist

Thierry, what do you think? I'd prefer option 2, as that keeps things
simple and still fulfills the requirements. We probably would redo the
patch Remove redundant host1x to actually move drm under host1x, and
adds calls from host1x to parse_dt() directly. We'd probably leave the
code otherwise mostly as it is now, so we'll drop whatever modifications
we've done so far in my proposals. You can later pick up some things
from our proposals if you want, but it's then up to you.

We could also later think about generalizing some of the list management
to belong to host1x, but that'd be a follow-up and we can decide that later.

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

Re: [PATCH] drm/exynos: fimd: modify condition in fimd resume

[Prathyush K]

Hi,

Please review this patch.

Regards,
Prathyush


On Thu, Dec 27, 2012 at 5:10 PM, Prathyush K prathyus...@samsung.comwrote:

 If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
 call fimd_activate(false) and just returns. Similarily the check in
 fimd_resume should not resume if previously runtime_suspended.
 Instead the existing check does the opposite. So if fimd was not
 runtime suspended, suspend will turn off fimd but resume will not turn
 it on.  This patch fixes this issue by reversing the condition.

 Signed-off-by: Prathyush K prathyus...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index bf0d9ba..9accd466 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -1046,7 +1046,7 @@ static int fimd_resume(struct device *dev)
  * of pm runtime would still be 1 so in this case, fimd driver
  * should be on directly not drawing on pm runtime interface.
  */
 -   if (pm_runtime_suspended(dev)) {
 +   if (!pm_runtime_suspended(dev)) {
 int ret;

 ret = fimd_activate(ctx, true);
 --
 1.8.0

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

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

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Boszormenyi Zoltan]

2013-01-04 08:40 keltezéssel, Borislav Petkov írta:

On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:

From: Alex Deucher alexander.deuc...@amd.com
Date: Wed, 2 Jan 2013 18:30:21 -0500
Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers

count must be a multiple of 2.

Cc: Borislav Petkov b...@alien8.de
Cc: Markus Trippelsdorf mar...@trippelsdorf.de
Signed-off-by: Alex Deucher alexander.deuc...@amd.com

Thanks, will run it on the box in question next week when I have access.

Btw, you could add the note about count needing to be a multiple of 2 as
a comment in the code below, for future reference.


---
  drivers/gpu/drm/radeon/r600.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2aaf147..9f4ce5e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
  
  	for (i = 0; i  num_loops; i++) {

cur_size_in_dw = size_in_dw;
-   if (cur_size_in_dw  0x)
-   cur_size_in_dw = 0x;
+   if (cur_size_in_dw  0xFFFE)
+   cur_size_in_dw = 0xFFFE;


How about any other odd numbers? Like 0xFFFB, or 0x0003?
They will get passed as is after this change, no? Shouldn't they
be also fixed? Something like this below?

  if (cur_size_in_dw  0x0001)
   cur_size_in_dw = ~1;




size_in_dw -= cur_size_in_dw;
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0, 
cur_size_in_dw));
radeon_ring_write(ring, dst_offset  0xfffc);
--
1.7.7.5


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

Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

[Florian Mickler]

Dear Paul,

On Tue, 01 Jan 2013 04:43:39 +0100
Paul Menzel paulepan...@users.sourceforge.net wrote:

 So if nobody has a great idea, the roadmap looks as follows. Revert the
 patch, find out why the graphics driver chokes on the reduced blanking
 (report a bug) and commit the patch again.

I reported a bug at: https://bugzilla.kernel.org/show_bug.cgi?id=52281

Regards,
Flo


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

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

Andreas Boll andreas.boll@gmail.com changed:

   What|Removed |Added

  Attachment #72495|text/plain  |image/png
  mime type||

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

Andreas Boll andreas.boll@gmail.com changed:

   What|Removed |Added

  Attachment #72497|text/plain  |image/png
  mime type||

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

Andreas Boll andreas.boll@gmail.com changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Drivers/Gallium/r600

--- Comment #4 from Andreas Boll andreas.boll@gmail.com ---
Please attach your xorg log and the outputs from dmesg and glxinfo.

-- 
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 0/2] drm/exynos: add support for more resolutions to exynos5

[Rahul Sharma]

Please Abandon this patch set.

Same code is posted under new patch set at
http://comments.gmane.org/gmane.comp.video.dri.devel/78392

regards,
Rahul Sharma

On Tue, Dec 18, 2012 at 7:42 PM, Rahul Sharma rahul.sha...@samsung.com wrote:
 This patch set adds support for more resolutions and refresh rates to Samsung
 Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).

 Given resoltuion will be supported or not, is decided by two factors:
 1) Corresponding pixel clock is supported by hdmi PHY.
 2) Mixer can generate the correspoding video timing.

 All standard resolutions and pixel rate combinations are verified for the 
 above
 limitations and are listed in hdmi driver. Any standard resolution supported 
 by
 the monitor/tv will be comapared against this list.

 We got 640x480, 720x576 and 1680x1050 and few more refresh rates enabled as a
 result to this exercise.

 Rahul Sharma (2):
   drm/exynos: hdmi: add support for extra permissable resolutions
   drm/exynos: mixer: add support for extra resolutions

  drivers/gpu/drm/exynos/exynos_hdmi.c  | 1004 
 -
  drivers/gpu/drm/exynos/exynos_mixer.c |8 +-
  2 files changed, 358 insertions(+), 654 deletions(-)

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

[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher ag...@yahoo.com ---
I'm assuming you are using mesa 9.x or newer based on the version info in the
bug header.  Can you confirm?  xf86-video-ati 7.0.0 requires mesa 9.x.  Also,
if the steam client is a 32-bit application and you are running a 64-bit
distro, you will need to make sure your 32-bit 3D driver is up to date.  I
suspect you have an out of date 32-bit 3D driver.

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

--- Comment #6 from Adam Jorgensen adam.jorgensen...@gmail.com ---
Created attachment 72509
  -- https://bugs.freedesktop.org/attachment.cgi?id=72509action=edit
X.org log

My X.org log file

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

--- Comment #7 from Adam Jorgensen adam.jorgensen...@gmail.com ---
Created attachment 72510
  -- https://bugs.freedesktop.org/attachment.cgi?id=72510action=edit
dmesg output

Output from dmesg after running Steam and triggering corruption

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

--- Comment #8 from Adam Jorgensen adam.jorgensen...@gmail.com ---
Created attachment 72511
  -- https://bugs.freedesktop.org/attachment.cgi?id=72511action=edit
glxinfo output

Output from glxinfo

-- 
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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to kernel rejected CS messages

[bugzilla-daemon]

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

--- Comment #9 from Adam Jorgensen adam.jorgensen...@gmail.com ---
(In reply to comment #5)
 I'm assuming you are using mesa 9.x or newer based on the version info in
 the bug header.  Can you confirm?  xf86-video-ati 7.0.0 requires mesa 9.x. 
 Also, if the steam client is a 32-bit application and you are running a
 64-bit distro, you will need to make sure your 32-bit 3D driver is up to
 date.  I suspect you have an out of date 32-bit 3D driver.

I can confirm that I am using Mesa 9.0.1 in conjunction with xf86-video-ati
7.0.0.

I *thought* I was running Steam as a 64-bit application but based on the lack
of an ubuntu12_64 directory in my  ~/.local/share/Steam directory it seems
likely that my Steam installation is actually a 32-bit one.

I am using the latest emul-x86 libs (I'm running Sabayon Linux) but I also have
a separate 32-bit chroot for work purposes. I will try updating the chroot
environment (Since it's set up with the same distro) and installing Steam their
and testing it in that environment...

-- 
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: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Alex Deucher]

On Fri, Jan 4, 2013 at 6:16 AM, Boszormenyi Zoltan zbos...@pr.hu wrote:
 2013-01-04 08:40 keltezéssel, Borislav Petkov írta:

 On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:

 From: Alex Deucher alexander.deuc...@amd.com
 Date: Wed, 2 Jan 2013 18:30:21 -0500
 Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers

 count must be a multiple of 2.

 Cc: Borislav Petkov b...@alien8.de
 Cc: Markus Trippelsdorf mar...@trippelsdorf.de
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com

 Thanks, will run it on the box in question next week when I have access.

 Btw, you could add the note about count needing to be a multiple of 2 as
 a comment in the code below, for future reference.

 ---
   drivers/gpu/drm/radeon/r600.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600.c
 b/drivers/gpu/drm/radeon/r600.c
 index 2aaf147..9f4ce5e 100644
 --- a/drivers/gpu/drm/radeon/r600.c
 +++ b/drivers/gpu/drm/radeon/r600.c
 @@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
 for (i = 0; i  num_loops; i++) {
 cur_size_in_dw = size_in_dw;
 -   if (cur_size_in_dw  0x)
 -   cur_size_in_dw = 0x;
 +   if (cur_size_in_dw  0xFFFE)
 +   cur_size_in_dw = 0xFFFE;


 How about any other odd numbers? Like 0xFFFB, or 0x0003?
 They will get passed as is after this change, no? Shouldn't they
 be also fixed? Something like this below?

   if (cur_size_in_dw  0x0001)
cur_size_in_dw = ~1;


This function only deals with pages so they will always be even.

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

[PATCH] drm/radeon: split r6xx and r7xx copy_dma functions

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

- r6xx actually uses a slightly different packet format,
although both formats seem to work ok.
- r7xx doesn't have the count multiple of 2 limitation.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/r600.c|   10 ++--
 drivers/gpu/drm/radeon/radeon_asic.c |4 +-
 drivers/gpu/drm/radeon/radeon_asic.h |4 ++
 drivers/gpu/drm/radeon/rv770.c   |   74 ++
 4 files changed, 85 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 923f936..537e259 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2646,7 +2646,7 @@ int r600_copy_blit(struct radeon_device *rdev,
  * @num_gpu_pages: number of GPU pages to xfer
  * @fence: radeon fence object
  *
- * Copy GPU paging using the DMA engine (r6xx-r7xx).
+ * Copy GPU paging using the DMA engine (r6xx).
  * Used by the radeon ttm implementation to move pages if
  * registered as the asic copy callback.
  */
@@ -2669,8 +2669,8 @@ int r600_copy_dma(struct radeon_device *rdev,
}
 
size_in_dw = (num_gpu_pages  RADEON_GPU_PAGE_SHIFT) / 4;
-   num_loops = DIV_ROUND_UP(size_in_dw, 0x);
-   r = radeon_ring_lock(rdev, ring, num_loops * 5 + 8);
+   num_loops = DIV_ROUND_UP(size_in_dw, 0xFFFE);
+   r = radeon_ring_lock(rdev, ring, num_loops * 4 + 8);
if (r) {
DRM_ERROR(radeon: moving bo (%d).\n, r);
radeon_semaphore_free(rdev, sem, NULL);
@@ -2693,8 +2693,8 @@ int r600_copy_dma(struct radeon_device *rdev,
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0, 
cur_size_in_dw));
radeon_ring_write(ring, dst_offset  0xfffc);
radeon_ring_write(ring, src_offset  0xfffc);
-   radeon_ring_write(ring, upper_32_bits(dst_offset)  0xff);
-   radeon_ring_write(ring, upper_32_bits(src_offset)  0xff);
+   radeon_ring_write(ring, (((upper_32_bits(dst_offset)  0xff)  
16) |
+(upper_32_bits(src_offset)  0xff)));
src_offset += cur_size_in_dw * 4;
dst_offset += cur_size_in_dw * 4;
}
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 596bcbe..9056faf 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1140,9 +1140,9 @@ static struct radeon_asic rv770_asic = {
.copy = {
.blit = r600_copy_blit,
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
-   .dma = r600_copy_dma,
+   .dma = rv770_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = r600_copy_dma,
+   .copy = rv770_copy_dma,
.copy_ring_index = R600_RING_TYPE_DMA_INDEX,
},
.surface = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 5f4882c..15d70e6 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -403,6 +403,10 @@ u32 rv770_page_flip(struct radeon_device *rdev, int crtc, 
u64 crtc_base);
 void r700_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc);
 void r700_cp_stop(struct radeon_device *rdev);
 void r700_cp_fini(struct radeon_device *rdev);
+int rv770_copy_dma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+  struct radeon_fence **fence);
 
 /*
  * evergreen
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 87c979c..1b2444f 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -887,6 +887,80 @@ static int rv770_mc_init(struct radeon_device *rdev)
return 0;
 }
 
+/**
+ * rv770_copy_dma - copy pages using the DMA engine
+ *
+ * @rdev: radeon_device pointer
+ * @src_offset: src GPU address
+ * @dst_offset: dst GPU address
+ * @num_gpu_pages: number of GPU pages to xfer
+ * @fence: radeon fence object
+ *
+ * Copy GPU paging using the DMA engine (r7xx).
+ * Used by the radeon ttm implementation to move pages if
+ * registered as the asic copy callback.
+ */
+int rv770_copy_dma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+ struct radeon_fence **fence)
+{
+   struct radeon_semaphore *sem = NULL;
+   int ring_index = rdev-asic-copy.dma_ring_index;
+   struct radeon_ring *ring = rdev-ring[ring_index];
+   u32 size_in_dw, cur_size_in_dw;
+   int i, num_loops;
+   int r = 0;
+
+   r = radeon_semaphore_create(rdev, sem);
+   if (r) {
+   DRM_ERROR(radeon: moving bo (%d).\n, r);
+   return r;
+   }
+
+   size_in_dw = 

[Bug 58667] Random crashes on CAYMAN

[bugzilla-daemon]

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

--- Comment #23 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #22)
 Is this a regression?  Does it happen with older versions of mesa or
 kernel?
 Yes. Previous kernel 3.7 doesn't show this problem.

Can you bisect?  Is it the same commit Thomas landed on or another 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

Re: [RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron

[Alex Deucher]

On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
 configuration space is not restored correctly, resulting in MSI not working 
 after switch.

 Only useful item in dmesg is:

 [   33.922807] radeon :01:00.0: Refused to change power state, currently 
 in D3

 I did some testing, dumping the difference in ms between first succesful 
 switch
 from D3 to D0, and it seems that there is slightly more than 20 ms difference 
 when
 the device is re-enabled through vga-switcheroo.

 So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not 
 working
 on my system after switcheroo-ing.

I guess if it fixes it...  Has anyone seen similar problems on non-mac
systems?  What is the delay normally set to?  It seems pretty
innocuous other than potentially adding a little extra latency.  Do
you think it makes sense to make it more like a quirk and only apply
it to problematic systems or just apply across the board?

Alex


 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

 ---

 This is a RFC patch since I feel what I'm doing is done in a hackish way,
 but it seems only the D3-D0 transition during switcheroo enable is affected,
 other transitions like suspend/resume and switcheroo poweroff seem unaffected.

 diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
 b/drivers/gpu/drm/radeon/radeon_device.c
 index 5515921..8816958 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev 
 *pdev, enum vga_switchero
 struct drm_device *dev = pci_get_drvdata(pdev);
 pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
 if (state == VGA_SWITCHEROO_ON) {
 +   unsigned d3_delay = dev-pdev-d3_delay;
 +
 printk(KERN_INFO radeon: switched on\n);
 /* don't suspend or resume card normally */
 dev-switch_power_state = DRM_SWITCH_POWER_CHANGING;
 +
 +   if (dev-pdev-d3_delay  20)
 +   dev-pdev-d3_delay = 20;
 +
 radeon_resume_kms(dev);
 +
 +   dev-pdev-d3_delay = d3_delay;
 +
 dev-switch_power_state = DRM_SWITCH_POWER_ON;
 drm_kms_helper_poll_enable(dev);
 } else {

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

Re: radeon CS parser refactoring

[Alex Deucher]

On Wed, Jan 2, 2013 at 6:27 PM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
 The following set of patches refactor the CS-parser logic
 in an effort to consolidate the code that is repeated across
 ASIC-specific files. All patches except #8 are function-neutral,
 that is they preserve the existing functionality of the driver.
 Patch #8 adds one extra check for WAIT_REG_MEM packet that I
 believe should be there.

 I have been running with these patches for about a month on several
 machines with Evergreen and NI GPUs without noticing any regressions.
 I also ran quick tests on all Radeon GPUs that I had around, which
 range from R300 through NI cards.

 The patches have been rebased to the current state of Dave's drm-next
 branch.

Looks good to me.  Nice clean up.  As long as there are no regressions
with UMS, consider them applied.

Thanks!

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

Re: [PATCH v2 2/4] drm/exynos: implement display-mode-check callback in mixer driver

[Sean Paul]

On Fri, Jan 4, 2013 at 8:53 AM, Rahul Sharma rahul.sha...@samsung.com wrote:
 This patch adds the implementation of check_mode callback in the mixer

s/check_mode/check_timing/

 driver. Based on the mixer version, correct set of restrictions will be
 exposed by the mixer driver. A resolution will be acceptable only if passes
 the criteria set by mixer and hdmi IPs.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Signed-off-by: Sean Paul seanp...@chromium.org
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c | 26 ++
  1 file changed, 26 insertions(+)

 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 21db895..c1f2e7a 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -810,6 +810,29 @@ static void mixer_win_disable(void *ctx, int win)
 mixer_ctx-win_data[win].enabled = false;
  }

 +int mixer_check_timing(void *ctx, struct fb_videomode *timing)
 +{
 +   struct mixer_context *mixer_ctx = ctx;
 +   unsigned int w, h;

xres and yres are defined as u32 in fb_videomode

 +
 +   w = timing-xres;
 +   h = timing-yres;
 +
 +   DRM_DEBUG_KMS(%s : xres=%d, yres=%d, refresh=%d, intl=%d\n,
 +   __func__, timing-xres, timing-yres,
 +   timing-refresh, (timing-vmode 
 +   FB_VMODE_INTERLACED) ? true : false);
 +
 +   if (mixer_ctx-mxr_ver == MXR_VER_0_0_0_16)
 +   return 0;
 +
 +   if ((w = 464  w = 720  h = 261  h = 576) ||
 +   (w = 1024  w = 1280  h = 576  h = 720) ||
 +   (w = 1664  w = 1920  h = 936  h = 1080))
 +   return 0;
 +
 +   return -EINVAL;
 +}
  static void mixer_wait_for_vblank(void *ctx)
  {
 struct mixer_context *mixer_ctx = ctx;
 @@ -947,6 +970,9 @@ static struct exynos_mixer_ops mixer_ops = {
 .win_mode_set   = mixer_win_mode_set,
 .win_commit = mixer_win_commit,
 .win_disable= mixer_win_disable,
 +
 +   /* display */
 +   .check_timing   = mixer_check_timing,
  };

  /* for pageflip event */
 --
 1.8.0

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

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

[bugzilla-daemon]

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





--- Comment #15 from Konrad Rzeszutek Wilk konrad.w...@oracle.com  2013-01-04 
16:00:10 ---
Let me ask again: Does it work properly under baremetal?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- 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: [RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron

[Maarten Lankhorst]

Op 04-01-13 16:34, Alex Deucher schreef:
 On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst
 maarten.lankho...@canonical.com wrote:
 vga-switcheroo with apple-gmux does not switch correctly on my system. The 
 PCI
 configuration space is not restored correctly, resulting in MSI not working 
 after switch.

 Only useful item in dmesg is:

 [   33.922807] radeon :01:00.0: Refused to change power state, currently 
 in D3

 I did some testing, dumping the difference in ms between first succesful 
 switch
 from D3 to D0, and it seems that there is slightly more than 20 ms 
 difference when
 the device is re-enabled through vga-switcheroo.

 So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not 
 working
 on my system after switcheroo-ing.
 I guess if it fixes it...  Has anyone seen similar problems on non-mac
 systems?  What is the delay normally set to?  It seems pretty
It's normally set to PCI_PM_D3_WAIT, 10 ms.
 innocuous other than potentially adding a little extra latency.  Do
 you think it makes sense to make it more like a quirk and only apply
 it to problematic systems or just apply across the board?
Quirking would be fine. Since there is a message in dmesg it would
be easy to identify when others hit the same issue, in which case
we could enable it all the time.

 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

 ---

 This is a RFC patch since I feel what I'm doing is done in a hackish way,
 but it seems only the D3-D0 transition during switcheroo enable is affected,
 other transitions like suspend/resume and switcheroo poweroff seem 
 unaffected.

 diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
 b/drivers/gpu/drm/radeon/radeon_device.c
 index 5515921..8816958 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev 
 *pdev, enum vga_switchero
 struct drm_device *dev = pci_get_drvdata(pdev);
 pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
 if (state == VGA_SWITCHEROO_ON) {
 +   unsigned d3_delay = dev-pdev-d3_delay;
 +
 printk(KERN_INFO radeon: switched on\n);
 /* don't suspend or resume card normally */
 dev-switch_power_state = DRM_SWITCH_POWER_CHANGING;
 +
 +   if (dev-pdev-d3_delay  20)
 +   dev-pdev-d3_delay = 20;
 +
 radeon_resume_kms(dev);
 +
 +   dev-pdev-d3_delay = d3_delay;
 +
 dev-switch_power_state = DRM_SWITCH_POWER_ON;
 drm_kms_helper_poll_enable(dev);
 } else {


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

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

[bugzilla-daemon]

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





--- Comment #16 from Fernando Chaves ferna...@supergg.com.br  2013-01-04 
16:35:55 ---
I'm sorry Konrad, but I don't know exactly what you mean when you say run on
bare metal.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- 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 42162] Display not enabled on resume (HP DV6)

[bugzilla-daemon]

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

--- Comment #8 from Johan Brannlund freedesktop-b...@nullinfinity.org ---
Resume still doesn't work with kernel 3.8-rc2. However, I now get a hard lockup
on resume. Log attached.

-- 
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 42162] Display not enabled on resume (HP DV6)

[bugzilla-daemon]

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

--- Comment #9 from Johan Brannlund freedesktop-b...@nullinfinity.org ---
Created attachment 72514
  -- https://bugs.freedesktop.org/attachment.cgi?id=72514action=edit
Suspend/resume log, kernel 3.8-rc2

-- 
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 42162] Display not enabled on resume (HP DV6)

[bugzilla-daemon]

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

--- Comment #11 from Johan Brannlund freedesktop-b...@nullinfinity.org ---
I'll try bisecting when I have some spare time, but it's probably going to be a
few weeks.

-- 
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 42162] Display not enabled on resume (HP DV6)

[bugzilla-daemon]

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

--- Comment #12 from Johan Brannlund freedesktop-b...@nullinfinity.org ---
Correction: it's *not* a hard lockup - the laptop still responds to ping. It
may just be that the keyboard is not working after resume (or even that I
mistyped something when trying to reboot it by typing blind).

-- 
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/radeon: fix DMA CS parser for r6xx linear copy packet

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Was using the r7xx format.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/r600_cs.c |   31 ++-
 1 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 9ea13d0..03191a5 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2677,16 +2677,29 @@ int r600_dma_cs_parse(struct radeon_cs_parser *p)
}
p-idx += 7;
} else {
-   src_offset = ib[idx+2];
-   src_offset |= ((u64)(ib[idx+4]  0xff))  32;
-   dst_offset = ib[idx+1];
-   dst_offset |= ((u64)(ib[idx+3]  0xff))  32;
+   if (p-family = CHIP_RV770) {
+   src_offset = ib[idx+2];
+   src_offset |= ((u64)(ib[idx+4]  0xff)) 
 32;
+   dst_offset = ib[idx+1];
+   dst_offset |= ((u64)(ib[idx+3]  0xff)) 
 32;
 
-   ib[idx+1] += (u32)(dst_reloc-lobj.gpu_offset  
0xfffc);
-   ib[idx+2] += (u32)(src_reloc-lobj.gpu_offset  
0xfffc);
-   ib[idx+3] += 
upper_32_bits(dst_reloc-lobj.gpu_offset)  0xff;
-   ib[idx+4] += 
upper_32_bits(src_reloc-lobj.gpu_offset)  0xff;
-   p-idx += 5;
+   ib[idx+1] += 
(u32)(dst_reloc-lobj.gpu_offset  0xfffc);
+   ib[idx+2] += 
(u32)(src_reloc-lobj.gpu_offset  0xfffc);
+   ib[idx+3] += 
upper_32_bits(dst_reloc-lobj.gpu_offset)  0xff;
+   ib[idx+4] += 
upper_32_bits(src_reloc-lobj.gpu_offset)  0xff;
+   p-idx += 5;
+   } else {
+   src_offset = ib[idx+2];
+   src_offset |= ((u64)(ib[idx+3]  0xff)) 
 32;
+   dst_offset = ib[idx+1];
+   dst_offset |= ((u64)(ib[idx+3]  
0xff))  16;
+
+   ib[idx+1] += 
(u32)(dst_reloc-lobj.gpu_offset  0xfffc);
+   ib[idx+2] += 
(u32)(src_reloc-lobj.gpu_offset  0xfffc);
+   ib[idx+3] += 
upper_32_bits(src_reloc-lobj.gpu_offset)  0xff;
+   ib[idx+3] += 
(upper_32_bits(dst_reloc-lobj.gpu_offset)  0xff)  16;
+   p-idx += 4;
+   }
}
if ((src_offset + (count * 4))  
radeon_bo_size(src_reloc-robj)) {
dev_warn(p-dev, DMA copy src buffer too small 
(%llu %lu)\n,
-- 
1.7.7.5

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

[Bug 50941] Kernel does not compile

[bugzilla-daemon]

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





--- Comment #3 from JP Pozzi jp.po...@izzop.net  2013-01-04 17:56:28 ---
Hello,

I try it but ACPI_VIDEO is reset to m whenever you make menuconfig or
compile the kernel. I can't find what other parameters are to be set to y.

At least the kernel compile but I have some problems, after one or two hours
the
screen (or keyboard ?) get stuck and I have to connect from another machine
to stop properly the system. I get the same kind of screen blocked with the
3.7.1 kernel.

I try it but ACPI_VIDEO is reset to m whenever you make menuconfig or
compile the kernel. I can't find what other parameters are to be set to y.
It is the same for 3.7.1 kernel.

Regards

JP P

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- 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 56405] Distorted graphics on Radeon HD 6620G

[bugzilla-daemon]

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

Michael Dressel mdrs...@t-online.de changed:

   What|Removed |Added

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

--- Comment #54 from Michael Dressel mdrs...@t-online.de ---
The patch works for me, as alread reported. I have not tried a kernel including
the patch. But I still think this bug is fixed.

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