[Bug 44919] Wayland clients segfault

[bugzilla-daemon]

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

--- Comment #4 from Damien Grassart  2012-01-20 02:51:07 
PST ---
Hi, I can confirm this issue also happens with a r600 card. Here's an example
of my backtrace from the weston-desktop-shell client crashing:

#0  0x74601fba in st_framebuffer_validate.isra.3 () from
/home/damien/lib/dri/r600_dri.so
#1  0x74603469 in st_api_make_current () from
/home/damien/lib/dri/r600_dri.so
#2  0x745bbe8f in driBindContext () from
/home/damien/lib/dri/r600_dri.so
#3  0x771bde90 in dri2_make_current () from
/home/damien/lib/libEGL.so.1
#4  0x771b6159 in eglMakeCurrent () from /home/damien/lib/libEGL.so.1
#5  0x7771e58d in cairo_egl_device_create () from
/home/damien/lib/libcairo.so.2
#6  0x00409545 in init_egl (d=0x620630) at window.c:2822
#7  display_create (argc=0x7fffde0c, argv=0x7fffde00,
option_entries=) at window.c:2926
#8  0x004040a6 in main (argc=1, argv=0x7fffdf58) at
desktop-shell.c:672

When I build mesa from commit 21b28d520ff218d165e86aa71dbd02050a3aa0cd (just
before the first bad commit), then it works fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] MAINTAINERS: Add dma-buf sharing framework maintainer

[Dave Airlie]

On Thu, Jan 19, 2012 at 10:39 AM, Daniel Vetter  wrote:
> On Thu, Jan 19, 2012 at 03:04:25PM +0530, Sumit Semwal wrote:
>> Adding maintainer info for dma-buf buffer sharing framework;
>> some mailing lists interested in this work are also added.
>>
>> Signed-off-by: Sumit Semwal 
>> Signed-off-by: Sumit Semwal 
>> Acked-by: Arnd Bergmann 
>
> Acked-by: Daniel Vetter 

Acked-by: Dave Airlie 

Should just send to Linus with these acks in it.

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

Re: [PATCH] MAINTAINERS: Add dma-buf sharing framework maintainer

[Dave Airlie]

On Fri, Jan 20, 2012 at 11:17 AM, Sumit Semwal  wrote:
>
> On Jan 20, 2012 4:33 PM, "Dave Airlie"  wrote:
>>
>> On Thu, Jan 19, 2012 at 10:39 AM, Daniel Vetter  wrote:
>> > On Thu, Jan 19, 2012 at 03:04:25PM +0530, Sumit Semwal wrote:
>> >> Adding maintainer info for dma-buf buffer sharing framework;
>> >> some mailing lists interested in this work are also added.
>> >>
>> >> Signed-off-by: Sumit Semwal 
>> >> Signed-off-by: Sumit Semwal 
>> >> Acked-by: Arnd Bergmann 
>> >
>> > Acked-by: Daniel Vetter 
>>
>> Acked-by: Dave Airlie 
>>
>> Should just send to Linus with these acks in it.
> Thanks Daniel and Dave!
> Dave,
> Would it be OK for you to queue it through your for-linus, or just the patch
> to Linus will be enough ?

Send it to Linus direct, hopefully he notices it.

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

Re: [Linaro-mm-sig] [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

[Laurent Pinchart]

Hi Summit,

Sorry for the late review. I know that this code is now in mainline, but I 
still have a couple of comments. I'll send patches if you agree with them.

On Monday 26 December 2011 10:23:15 Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
> 
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
> 
> The framework allows:
> - creation of a buffer object, its association with a file pointer, and
>associated allocator-defined operations on that buffer. This operation
> is called the 'export' operation.
> - different devices to 'attach' themselves to this exported buffer object,
> to facilitate backing storage negotiation, using dma_buf_attach() API. -
> the exported buffer object to be shared with the other entity by asking
> for its 'file-descriptor (fd)', and sharing the fd across.
> - a received fd to get the buffer object back, where it can be accessed
> using the associated exporter-defined operations.
> - the exporter and user to share the scatterlist associated with this
> buffer object using map_dma_buf and unmap_dma_buf operations.
> 
> Atleast one 'attach()' call is required to be made prior to calling the
> map_dma_buf() operation.
> 
> Couple of building blocks in map_dma_buf() are added to ease introduction
> of sync'ing across exporter and users, and late allocation by the exporter.
> 
> For this first version, this framework will work with certain conditions:
> - *ONLY* exporter will be allowed to mmap to userspace (outside of this
>framework - mmap is not a buffer object operation),
> - currently, *ONLY* users that do not need CPU access to the buffer are
>allowed.
> 
> More details are there in the documentation patch.
> 
> This is based on design suggestions from many people at the
> mini-summits[1], most notably from Arnd Bergmann , Rob
> Clark  and Daniel Vetter .
> 
> The implementation is inspired from proof-of-concept patch-set from
> Tomasz Stanislawski , who demonstrated buffer
> sharing between two v4l2 devices. [2]
> 
> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
> [2]: http://lwn.net/Articles/454389
> 
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Dave Airlie 
> Reviewed-and-Tested-by: Rob Clark 
> ---
>  drivers/base/Kconfig|   10 ++
>  drivers/base/Makefile   |1 +
>  drivers/base/dma-buf.c  |  291
> +++ include/linux/dma-buf.h | 
> 176 
>  4 files changed, 478 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/base/dma-buf.c
>  create mode 100644 include/linux/dma-buf.h
> 

[snip]

> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> new file mode 100644
> index 000..e38ad24
> --- /dev/null
> +++ b/drivers/base/dma-buf.c
> @@ -0,0 +1,291 @@

[snip]

> +/**
> + * dma_buf_export - Creates a new dma_buf, and associates an anon file
> + * with this buffer, so it can be exported.
> + * Also connect the allocator specific data and ops to the buffer.
> + *
> + * @priv:[in]Attach private data of allocator to this buffer
> + * @ops: [in]Attach allocator-defined dma buf ops to the new buffer.
> + * @size:[in]Size of the buffer
> + * @flags:   [in]mode flags for the file.
> + *
> + * Returns, on success, a newly created dma_buf object, which wraps the
> + * supplied private data and operations for dma_buf_ops. On either missing
> + * ops, or error in allocating struct dma_buf, will return negative error.
> + *
> + */
> +struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
> + size_t size, int flags)
> +{
> + struct dma_buf *dmabuf;
> + struct file *file;
> +
> + if (WARN_ON(!priv || !ops
> +   || !ops->map_dma_buf
> +   || !ops->unmap_dma_buf
> +   || !ops->release)) {
> + return ERR_PTR(-EINVAL);
> + }
> +
> + dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
> + if (dmabuf == NULL)
> + return ERR_PTR(-ENOMEM);
> +
> + dmabuf->priv = priv;
> + dmabuf->ops = ops;

dmabuf->ops will never but NULL, but (see below)

> + dmabuf->size = size;
> +
> + file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
> +
> + dmabuf->file = file;
> +
> + mutex_init(&dmabuf->lock);
> + INIT_LIST_HEAD(&dmabuf->attachments);
> +
> + return dmabuf;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_export);

[snip]

> +/**
> + * dma_buf_attach - Add the device to dma_buf's attachments list;
> optionally, + * calls attach() of dma_buf_ops to allow device-specific
> attach functionality + * @dmabuf: [in]buffer to attach device to.
> + * @dev: [in]device to be attached.
> + *
> + * Returns struct dma_buf_attachment * for this attachment; may return
> negative + * error codes.
> + *
> + 

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #55818|application/octet-stream|text/plain
  mime type||
  Attachment #55818|0   |1
   is patch||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 44995] New: Missing support for MGA G200eW WPCM450 [102b:0532]

[bugzilla-daemon]

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

 Bug #: 44995
   Summary: Missing support for MGA G200eW WPCM450 [102b:0532]
Classification: Unclassified
   Product: Mesa
   Version: unspecified
  Platform: Other
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/MGA
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: lenlen1...@gmail.com


Please add support for MGA G200eW WPCM450 pci id 102b:0532

06:03.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA G200eW
WPCM450 [102b:0532] (rev 0a) (prog-if 00 [VGA controller])
Subsystem: Dell PowerEdge R610 MGA G200eW WPCM450 [1028:0236]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 

If you need more info please ask me. I'll feel in this ticket.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

[bugzilla-daemon]

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

Dave Airlie  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Dave Airlie  2012-01-20 08:41:35 
PST ---
This chip has no 3D engine, what would mesa be supporting in it?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

[GIT PULL]: dma-buf tree: maintainer update

[Semwal, Sumit]

Hi Linus,

Post the merge of dma-buf tree that was (very kindly) sent by Dave
Airlie, various people involved in this project feel it is natural and
practical for me to be the maintainer of this code.

This is my first pull request to you, which only changes the
MAINTAINERS file - could you please pull from it? [If you'd just
prefer the patch, I could post that out as well.]

Thanks and best regards,
~Sumit.

The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:

  Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)

are available in the git repository at:
  git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git for-linus-3.3

Sumit Semwal (1):
  MAINTAINERS: Add dma-buf sharing framework maintainer

 MAINTAINERS |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

[bugzilla-daemon]

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

--- Comment #2 from antonella  2012-01-20 09:10:28 PST ---
Could we have a /dev/dri/card0 entry for this card?
I tried to run an EGL app under xorg on this card and work fine.
But when i tried to run without X with EGL_PLATFORM=drm or fbdev doesn't work
because i think it cannot open /dev/dri/card0. The same code works fine on
intel/radeon/nouveau on console without X.

Is there any solution or workaround? The kernel seems that doesn't load the mga
module because doesn't recognize this pci id.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  2012-01-20 09:13:31 PST ---
There is no KMS driver for mga cards.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

[bugzilla-daemon]

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

--- Comment #4 from Dave Airlie  2012-01-20 09:28:19 
PST ---
This card has no EGL capabilties to expose.

Unless the application is going to run on top of a sw rendering EGL stack.

But there is no KMS driver for this card at the moment to even do that on top
off.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

[bugzilla-daemon]

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

--- Comment #5 from antonella  2012-01-20 10:12:56 PST ---
Thank you David. 
As i understand if there is no kms driver for this card i think that there is
no way to run this application out of an xserver session (i.e. in a gnome
terminal) also if i want to go on software rendering?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] dma-buf: Use EXPORT_SYMBOL

[Konrad Rzeszutek Wilk]

On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell  wrote:
> > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > > issue, and not really an interface".  The dma-buf infrastructure is
> > > explicitly intended as an interface between modules/drivers, so it
> > > should use EXPORT_SYMBOL instead.
> > 
> > + Konrad, Arnd, Mauro: there were strong objections on using
> > EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I

I am going to defer to what David Airlie recommends.

> > suggest we first arrive at a consensus before merging this patch.
> 
> This discussion seems to have stagnated; how do we move forward here?
> 
> Sumit, as the primary author and new maintainer (congrats!) of the
> dma-buf infrastructure, it seems like it's really your call how to
> proceed.  I'd still like to see this be something that we can use from
> the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have
> argued in this thread.  It really seems to me that this change on a
> technical level won't have any adverse effect on the scenarios where it
> can be used today, but it will allow it to be used more widely, which
> will prevent duplication and fragmentation in the future and be greatly
> appreciated by users of hardware such as Optimus.
> 
> Let me know if you have any questions.
> 
> Thanks,
> Robert
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42616] New: Radeon Kernel Mode Setting sets wrong mode

[bugzilla-daemon]

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

   Summary: Radeon Kernel Mode Setting sets wrong mode
   Product: Drivers
   Version: 2.5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: thomas.jo...@utoronto.ca
Regression: No


I have a Radeon HD 3470, connected to a Dell P2010H monitor via Display Port.

The monitor's native resolution is 1600x900, and everything works correctly
with UMS, however if I use KMS I cannot use that mode, I can use at least
1024x768, 1280x1024, and 1152x864 with KMS, but no matter how I try I cannot
get it to work in 1600x900. I have tried with the CVT timings, (reduced
blanking and not) and with the ones provided in the monitor's EDID.

If I attempt to set any of those modes (the 1600x900) with KMS on the monitor
claims that I'm using an unsupported mode. UMS works just fine though.

I'm running Fedora, and I don't think this is a regression in the kernel since
I don't think this computer has ever worked with KMS.

Right now what I've done is I have set the kernel command line to boot with
1152x864 and KMS, then I tried to use xrandr to change modes and the monitor
just complained.

dmesg doesn't seem to have anything useful to say, and neither does Xorg.0.log

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

[bugzilla-daemon]

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


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #1 from Alex Deucher   2012-01-20 19:13:28 
---
Please attach your xorg log, 'xrandr --verbose' output, and dmesg output from
both KMS and UMS.

-- 
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: radeon issues on MacBook Pro 8,2

[Alex Deucher]

On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee
 wrote:
> On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
>> > >  2. Occasional long delays when suspending. When this happens I see
>> > >    messages like following in dmesg:
>> > >
>> > >      [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 
>> > > 5secs aborting
>> > >      [drm:atom_execute_table_locked] *ERROR* atombios stuck executing 
>> > > D44E (len 62, WS 0, PS 0) @ 0xD46A
>> > >
>> > >    Sometimes one of suspend or resume hangs completely, but I can't
>> > >    tell which and am not sure whether or not it's related. I'm also
>> > >    testing a Mac Mini with the exact same card which does not seem to
>> > >    suffer from this issue.
>> > >
>> > >    I ran a bisections that identified f8d0edd (drm/radeon/kms: improve
>> > >    DP detect logic) as introducing problems with suspend, and reverting
>> > >    this patch on top of 3.2.1 does seem to eliminate both issues.
>> > >
>> >
>> > That patch doesn't really affect the modesetting paths directly; it
>> > looks like a red herring to me.
>>
>> Perhaps. I just started a run of 200 s3 cycles with the patch reverted
>> to see if I can reproduce the issues. I can usually trigger the problem
>> with 15 or fewer s3 cycles.
>
> The machine completed 200 s3 cycles with the patch reverted without long
> delays, hangs, or any atombios error messages. Without reverting it
> doesn't get through many at all before experiencing the errors and long
> delays or hangs.
>
> I added a printout of the connector status resulting from the logic that
> was changed by f8d0edd. With the logic prior to this commit it
> consistently returns the status as disconnected, which is correct as I
> have nothing connected. But with the improved logic the status is
> sometimes reported as connected, and these coincide with the atombios
> errors.
>

Do any of the disconnected displayport connectors get misdetected as
connected during normal operation or does it only happen during
suspend/resume?

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

[Bug 42616] Radeon Kernel Mode Setting sets wrong mode

[bugzilla-daemon]

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





--- Comment #2 from W Thomas Jones   2012-01-20 
19:45:17 ---
Created an attachment (id=72137)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72137)
UMS Xorg.0.log

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

[bugzilla-daemon]

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





--- Comment #3 from W Thomas Jones   2012-01-20 
19:47:03 ---
Created an attachment (id=72138)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72138)
xrandr --verbose UMS

the "1600x900Dell" mode is from me explicitly adding a modeline from the EDID
data while I was trying to make it work with KMS

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

[PATCH] drm/radeon/kms: add some missing semaphore init

[alexdeucher]

From: Alex Deucher 

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c  |1 +
 drivers/gpu/drm/radeon/evergreend.h |1 +
 drivers/gpu/drm/radeon/ni.c |1 +
 drivers/gpu/drm/radeon/nid.h|1 +
 4 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index ccde2c9..5bd7bae 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1455,6 +1455,7 @@ int evergreen_cp_resume(struct radeon_device *rdev)
 #endif
WREG32(CP_RB_CNTL, tmp);
WREG32(CP_SEM_WAIT_TIMER, 0x0);
+   WREG32(CP_SEM_INCOMPLETE_TIMER_CNTL, 0x0);
 
/* Set the write pointer delay */
WREG32(CP_RB_WPTR_DELAY, 0);
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index b502216..74713d4 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -108,6 +108,7 @@
 #defineCP_RB_WPTR_ADDR_HI  0xC11C
 #defineCP_RB_WPTR_DELAY0x8704
 #defineCP_SEM_WAIT_TIMER   0x85BC
+#defineCP_SEM_INCOMPLETE_TIMER_CNTL0x85C8
 #defineCP_DEBUG0xC1FC
 
 
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3211372..db09065 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1219,6 +1219,7 @@ int cayman_cp_resume(struct radeon_device *rdev)
RREG32(GRBM_SOFT_RESET);
 
WREG32(CP_SEM_WAIT_TIMER, 0x0);
+   WREG32(CP_SEM_INCOMPLETE_TIMER_CNTL, 0x0);
 
/* Set the write pointer delay */
WREG32(CP_RB_WPTR_DELAY, 0);
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index f9df2a6..9a7f3b6 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -222,6 +222,7 @@
 #defineSCRATCH_UMSK0x8540
 #defineSCRATCH_ADDR0x8544
 #defineCP_SEM_WAIT_TIMER   0x85BC
+#defineCP_SEM_INCOMPLETE_TIMER_CNTL0x85C8
 #defineCP_COHER_CNTL2  0x85E8
 #define CP_ME_CNTL 0x86D8
 #defineCP_ME_HALT  (1 << 
28)
-- 
1.7.7.5

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

[PATCH] drm/radeon/kms/dce3+: add support for hw i2c using atom

[alexdeucher]

From: Alex Deucher 

Starting with DCE3 hardware, atom contains a general purpose
ProcessI2cChannelTransaction similar to ProcessAuxChannelTransaction.

Add an implementation using the atom tables for DCE3+ hardware.

This should be a little less CPU intensive than bit banging and
may work better in certain cases.

Enable it by setting the radeon hw_i2c module parameter to 1.  E.g.,
radeon.hw_i2c=1
on the kernel command line in grub.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/Makefile   |2 +-
 drivers/gpu/drm/radeon/atombios_i2c.c |  139 +
 drivers/gpu/drm/radeon/radeon_i2c.c   |   21 +
 3 files changed, 161 insertions(+), 1 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/atombios_i2c.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 2139fe8..8410415 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -71,7 +71,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_blit_kms.o radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
evergreen_blit_kms.o \
radeon_trace_points.o ni.o cayman_blit_shaders.o atombios_encoders.o \
-   radeon_semaphore.o radeon_sa.o
+   radeon_semaphore.o radeon_sa.o atombios_i2c.o
 
 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c 
b/drivers/gpu/drm/radeon/atombios_i2c.c
new file mode 100644
index 000..44d87b6
--- /dev/null
+++ b/drivers/gpu/drm/radeon/atombios_i2c.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright 2011 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Alex Deucher
+ *
+ */
+#include "drmP.h"
+#include "radeon_drm.h"
+#include "radeon.h"
+#include "atom.h"
+
+#define TARGET_HW_I2C_CLOCK 50
+
+/* these are a limitation of ProcessI2cChannelTransaction not the hw */
+#define ATOM_MAX_HW_I2C_WRITE 2
+#define ATOM_MAX_HW_I2C_READ  255
+
+static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan,
+u8 slave_addr, u8 flags,
+u8 *buf, u8 num)
+{
+   struct drm_device *dev = chan->dev;
+   struct radeon_device *rdev = dev->dev_private;
+   PROCESS_I2C_CHANNEL_TRANSACTION_PS_ALLOCATION args;
+   int index = GetIndexIntoMasterTable(COMMAND, 
ProcessI2cChannelTransaction);
+   unsigned char *base;
+   u16 out;
+
+   memset(&args, 0, sizeof(args));
+
+   base = (unsigned char *)rdev->mode_info.atom_context->scratch;
+
+   if (flags & HW_I2C_WRITE) {
+   if (num > ATOM_MAX_HW_I2C_WRITE) {
+   DRM_ERROR("hw i2c: tried to write too many bytes (%d vs 
2)\n", num);
+   return -EINVAL;
+   }
+   memcpy(&out, buf, num);
+   args.lpI2CDataOut = cpu_to_le16(out);
+   } else {
+   if (num > ATOM_MAX_HW_I2C_READ) {
+   DRM_ERROR("hw i2c: tried to read too many bytes (%d vs 
255)\n", num);
+   return -EINVAL;
+   }
+   }
+
+   args.ucI2CSpeed = TARGET_HW_I2C_CLOCK;
+   args.ucRegIndex = 0;
+   args.ucTransBytes = num;
+   args.ucSlaveAddr = slave_addr << 1;
+   args.ucLineNumber = chan->rec.i2c_id;
+
+   atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*)&args);
+
+   /* error */
+   if (args.ucStatus != HW_ASSISTED_I2C_STATUS_SUCCESS) {
+   DRM_DEBUG_KMS("hw_i2c error\n");
+   return -EIO;
+   }
+
+   if (!(flags & HW_I2C_WRITE))
+   memcpy(buf, base, num);
+
+   return 0;
+}
+
+int radeon_atom_hw_i2c_xfer(struct i2c_adapter *i2c_adap,
+   struct i2c_msg *msgs, int num)
+{
+   struct radeon_i2c_chan *i2c = i2c_ge

[PATCH] drm/radeon/kms: move disp eng pll setup to init path

[alexdeucher]

From: Alex Deucher 

We really only need to set it up once on init or resume
rather than on every mode set.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c  |   56 +++
 drivers/gpu/drm/radeon/radeon_device.c  |6 ++-
 drivers/gpu/drm/radeon/radeon_display.c |6 ++-
 drivers/gpu/drm/radeon/radeon_mode.h|1 +
 4 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 0fda830..807b89b 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -355,15 +355,12 @@ static void atombios_crtc_set_timing(struct drm_crtc 
*crtc,
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*)&args);
 }
 
-static void atombios_disable_ss(struct drm_crtc *crtc)
+static void atombios_disable_ss(struct radeon_device *rdev, int pll_id)
 {
-   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct radeon_device *rdev = dev->dev_private;
u32 ss_cntl;
 
if (ASIC_IS_DCE4(rdev)) {
-   switch (radeon_crtc->pll_id) {
+   switch (pll_id) {
case ATOM_PPLL1:
ss_cntl = RREG32(EVERGREEN_P1PLL_SS_CNTL);
ss_cntl &= ~EVERGREEN_PxPLL_SS_EN;
@@ -379,7 +376,7 @@ static void atombios_disable_ss(struct drm_crtc *crtc)
return;
}
} else if (ASIC_IS_AVIVO(rdev)) {
-   switch (radeon_crtc->pll_id) {
+   switch (pll_id) {
case ATOM_PPLL1:
ss_cntl = RREG32(AVIVO_P1PLL_INT_SS_CNTL);
ss_cntl &= ~1;
@@ -406,13 +403,11 @@ union atom_enable_ss {
ENABLE_SPREAD_SPECTRUM_ON_PPLL_V3 v3;
 };
 
-static void atombios_crtc_program_ss(struct drm_crtc *crtc,
+static void atombios_crtc_program_ss(struct radeon_device *rdev,
 int enable,
 int pll_id,
 struct radeon_atom_ss *ss)
 {
-   struct drm_device *dev = crtc->dev;
-   struct radeon_device *rdev = dev->dev_private;
int index = GetIndexIntoMasterTable(COMMAND, 
EnableSpreadSpectrumOnPPLL);
union atom_enable_ss args;
 
@@ -479,7 +474,7 @@ static void atombios_crtc_program_ss(struct drm_crtc *crtc,
} else if (ASIC_IS_AVIVO(rdev)) {
if ((enable == ATOM_DISABLE) || (ss->percentage == 0) ||
(ss->type & ATOM_EXTERNAL_SS_MASK)) {
-   atombios_disable_ss(crtc);
+   atombios_disable_ss(rdev, pll_id);
return;
}
args.lvds_ss_2.usSpreadSpectrumPercentage = 
cpu_to_le16(ss->percentage);
@@ -491,7 +486,7 @@ static void atombios_crtc_program_ss(struct drm_crtc *crtc,
} else {
if ((enable == ATOM_DISABLE) || (ss->percentage == 0) ||
(ss->type & ATOM_EXTERNAL_SS_MASK)) {
-   atombios_disable_ss(crtc);
+   atombios_disable_ss(rdev, pll_id);
return;
}
args.lvds_ss.usSpreadSpectrumPercentage = 
cpu_to_le16(ss->percentage);
@@ -702,11 +697,9 @@ union set_pixel_clock {
 /* on DCE5, make sure the voltage is high enough to support the
  * required disp clk.
  */
-static void atombios_crtc_set_dcpll(struct drm_crtc *crtc,
+static void atombios_crtc_set_dcpll(struct radeon_device *rdev,
u32 dispclk)
 {
-   struct drm_device *dev = crtc->dev;
-   struct radeon_device *rdev = dev->dev_private;
u8 frev, crev;
int index;
union set_pixel_clock args;
@@ -996,7 +989,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock, 
&fb_div, &frac_fb_div,
  &ref_div, &post_div);
 
-   atombios_crtc_program_ss(crtc, ATOM_DISABLE, radeon_crtc->pll_id, &ss);
+   atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, &ss);
 
atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id, 
radeon_crtc->pll_id,
  encoder_mode, radeon_encoder->encoder_id, 
mode->clock,
@@ -1019,7 +1012,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
ss.step = step_size;
}
 
-   atombios_crtc_program_ss(crtc, ATOM_ENABLE, 
radeon_crtc->pll_id, &ss);
+   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
radeon_crtc->pll_id, &ss);
}
 }
 
@@ -1494,6 +1487,24 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 
 }
 
+void radeon_atom_dcpll_init(struct radeon_device *rdev)
+{
+   /* always

[PATCH 1/2] drm/radeon/kms: move panel mode setup into encoder mode set

[alexdeucher]

From: Alex Deucher 

Needs to happen earlier in the mode set.

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_dp.c   |   22 ++
 drivers/gpu/drm/radeon/atombios_encoders.c |   11 +++
 drivers/gpu/drm/radeon/radeon_mode.h   |3 +++
 3 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 6fb335a..a71557c 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -549,8 +549,8 @@ bool radeon_dp_getdpcd(struct radeon_connector 
*radeon_connector)
return false;
 }
 
-static void radeon_dp_set_panel_mode(struct drm_encoder *encoder,
-struct drm_connector *connector)
+int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
+struct drm_connector *connector)
 {
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
@@ -558,7 +558,7 @@ static void radeon_dp_set_panel_mode(struct drm_encoder 
*encoder,
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
 
if (!ASIC_IS_DCE4(rdev))
-   return;
+   return panel_mode;
 
if (radeon_connector_encoder_get_dp_bridge_encoder_id(connector) ==
ENCODER_OBJECT_ID_NUTMEG)
@@ -572,14 +572,7 @@ static void radeon_dp_set_panel_mode(struct drm_encoder 
*encoder,
panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
}
 
-   atombios_dig_encoder_setup(encoder,
-  ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
-  panel_mode);
-
-   if ((connector->connector_type == DRM_MODE_CONNECTOR_eDP) &&
-   (panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
-   radeon_write_dpcd_reg(radeon_connector, 
DP_EDP_CONFIGURATION_SET, 1);
-   }
+   return panel_mode;
 }
 
 void radeon_dp_set_link_config(struct drm_connector *connector,
@@ -717,6 +710,8 @@ static void radeon_dp_set_tp(struct 
radeon_dp_link_train_info *dp_info, int tp)
 
 static int radeon_dp_link_train_init(struct radeon_dp_link_train_info *dp_info)
 {
+   struct radeon_encoder *radeon_encoder = 
to_radeon_encoder(dp_info->encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
u8 tmp;
 
/* power up the sink */
@@ -732,7 +727,10 @@ static int radeon_dp_link_train_init(struct 
radeon_dp_link_train_info *dp_info)
radeon_write_dpcd_reg(dp_info->radeon_connector,
  DP_DOWNSPREAD_CTRL, 0);
 
-   radeon_dp_set_panel_mode(dp_info->encoder, dp_info->connector);
+   if ((dp_info->connector->connector_type == DRM_MODE_CONNECTOR_eDP) &&
+   (dig->panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
+   radeon_write_dpcd_reg(dp_info->radeon_connector, 
DP_EDP_CONFIGURATION_SET, 1);
+   }
 
/* set the lane count on the sink */
tmp = dp_info->dp_lane_count;
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index f1f06ca..a3a9166 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1811,10 +1811,21 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
*encoder,
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
if (ASIC_IS_DCE4(rdev)) {
+   struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = 
radeon_encoder->enc_priv;
+
+   if (!connector)
+   dig->panel_mode = 
DP_PANEL_MODE_EXTERNAL_DP_MODE;
+   else
+   dig->panel_mode = 
radeon_dp_get_panel_mode(encoder, connector);
+
/* disable the transmitter */
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
/* setup and enable the encoder */
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);
+   atombios_dig_encoder_setup(encoder,
+  
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
+  dig->panel_mode);
 
/* enable the transmitter */
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index 8cb19f3..d34dcb6 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -362,6 +362,7 @@ struct radeon_encoder_atom_dig {
struct backlight_device *bl_dev;
int dpm

[PATCH 2/2] drm/radeon/kms: rework modeset sequence for DCE41 and DCE5

[alexdeucher]

From: Alex Deucher 

dig transmitter control table only has ENABLE/DISABLE actions
on DCE4.1/DCE5.

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

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_encoders.c |   19 ---
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index a3a9166..79a4880 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1341,7 +1341,8 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, 
int mode)
switch (mode) {
case DRM_MODE_DPMS_ON:
/* some early dce3.2 boards have a bug in their transmitter 
control table */
-   if ((rdev->family == CHIP_RV710) || (rdev->family == 
CHIP_RV730))
+   if ((rdev->family == CHIP_RV710) || (rdev->family == 
CHIP_RV730) ||
+   ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
else
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
@@ -1351,8 +1352,6 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, 
int mode)
 
ATOM_TRANSMITTER_ACTION_POWER_ON);
radeon_dig_connector->edp_on = true;
}
-   if (ASIC_IS_DCE4(rdev))
-   atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_DP_VIDEO_OFF, 0);
radeon_dp_link_train(encoder, connector);
if (ASIC_IS_DCE4(rdev))
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
@@ -1363,7 +1362,10 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder 
*encoder, int mode)
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
-   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE_OUTPUT, 0, 0);
+   if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
+   else
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE_OUTPUT, 0, 0);
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && 
connector) {
if (ASIC_IS_DCE4(rdev))
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_DP_VIDEO_OFF, 0);
@@ -1810,7 +1812,7 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
-   if (ASIC_IS_DCE4(rdev)) {
+   if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
struct radeon_encoder_atom_dig *dig = 
radeon_encoder->enc_priv;
 
@@ -1819,13 +1821,16 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
*encoder,
else
dig->panel_mode = 
radeon_dp_get_panel_mode(encoder, connector);
 
-   /* disable the transmitter */
-   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
/* setup and enable the encoder */
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);
atombios_dig_encoder_setup(encoder,
   
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
   dig->panel_mode);
+   } else if (ASIC_IS_DCE4(rdev)) {
+   /* disable the transmitter */
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
+   /* setup and enable the encoder */
+   atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);
 
/* enable the transmitter */
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
-- 
1.7.7.5

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

[PATCH 1/2] drm/radeon/kms: use drm_detect_hdmi_monitor for picking encoder mode

[alexdeucher]

From: Alex Deucher 

We were previously just checking for audio.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_encoders.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 79a4880..f2f14a2 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -432,7 +432,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DVII:
case DRM_MODE_CONNECTOR_HDMIB: /* HDMI-B is basically DL-DVI; analog 
works fine */
-   if (drm_detect_monitor_audio(radeon_connector->edid) &&
+   if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
@@ -443,7 +443,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_DVID:
case DRM_MODE_CONNECTOR_HDMIA:
default:
-   if (drm_detect_monitor_audio(radeon_connector->edid) &&
+   if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
@@ -457,7 +457,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if ((dig_connector->dp_sink_type == 
CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
return ATOM_ENCODER_MODE_DP;
-   else if (drm_detect_monitor_audio(radeon_connector->edid) &&
+   else if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
 radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
-- 
1.7.7.5

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

[PATCH 2/2] drm/radeon/kms: refine TMDS dual link checks

[alexdeucher]

From: Alex Deucher 

HDMI 1.3 defines single link clocks up to 340 Mhz.
Refine the current dual link checks to only enable
dual link for DVI > 165 Mhz or HDMI > 340 Mhz if the
hw supports HDMI 1.3 (DCE3+).

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

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |4 +-
 drivers/gpu/drm/radeon/atombios_encoders.c |   57 -
 drivers/gpu/drm/radeon/radeon_encoders.c   |   77 
 drivers/gpu/drm/radeon/radeon_mode.h   |4 ++
 4 files changed, 105 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 807b89b..8919352 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -518,6 +518,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
int encoder_mode = 0;
u32 dp_clock = mode->clock;
int bpc = 8;
+   bool is_duallink = false;
 
/* reset the pll flags */
pll->flags = 0;
@@ -552,6 +553,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (connector && connector->display_info.bpc)
bpc = connector->display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
+   is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(encoder) 
!= ENCODER_OBJECT_ID_NONE)) {
if (connector) {
@@ -647,7 +649,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (dig->coherent_mode)
args.v3.sInput.ucDispPllConfig 
|=

DISPPLL_CONFIG_COHERENT_MODE;
-   if (mode->clock > 165000)
+   if (is_duallink)
args.v3.sInput.ucDispPllConfig 
|=

DISPPLL_CONFIG_DUAL_LINK;
}
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index f2f14a2..b88c460 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -57,22 +57,6 @@ static inline bool radeon_encoder_is_digital(struct 
drm_encoder *encoder)
}
 }
 
-static struct drm_connector *
-radeon_get_connector_for_encoder_init(struct drm_encoder *encoder)
-{
-   struct drm_device *dev = encoder->dev;
-   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
-   struct drm_connector *connector;
-   struct radeon_connector *radeon_connector;
-
-   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   radeon_connector = to_radeon_connector(connector);
-   if (radeon_encoder->devices & radeon_connector->devices)
-   return connector;
-   }
-   return NULL;
-}
-
 static bool radeon_atom_mode_fixup(struct drm_encoder *encoder,
   struct drm_display_mode *mode,
   struct drm_display_mode *adjusted_mode)
@@ -253,7 +237,7 @@ atombios_dvo_setup(struct drm_encoder *encoder, int action)
/* R4xx, R5xx */
args.ext_tmds.sXTmdsEncoder.ucEnable = action;
 
-   if (radeon_encoder->pixel_clock > 165000)
+   if (radeon_dig_monitor_is_duallink(encoder, 
radeon_encoder->pixel_clock))
args.ext_tmds.sXTmdsEncoder.ucMisc |= 
PANEL_ENCODER_MISC_DUAL;
 
args.ext_tmds.sXTmdsEncoder.ucMisc |= 
ATOM_PANEL_MISC_888RGB;
@@ -265,7 +249,7 @@ atombios_dvo_setup(struct drm_encoder *encoder, int action)
/* DFP1, CRT1, TV1 depending on the type of port */
args.dvo.sDVOEncoder.ucDeviceType = 
ATOM_DEVICE_DFP1_INDEX;
 
-   if (radeon_encoder->pixel_clock > 165000)
+   if (radeon_dig_monitor_is_duallink(encoder, 
radeon_encoder->pixel_clock))

args.dvo.sDVOEncoder.usDevAttr.sDigAttrib.ucAttribute |= 
PANEL_ENCODER_MISC_DUAL;
break;
case 3:
@@ -349,7 +333,7 @@ atombios_digital_setup(struct drm_encoder *encoder, int 
action)
} else {
if (dig->linkb)
args.v1.ucMisc |= 
PANEL_ENCODER_MISC_TMDS_LINKB;
-   if (radeon_encoder->pixel_clock > 165000)
+   

Fwd: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

[Eugeni Dodonov]

Looks like a CC to dri-devel got forgotten originally, so forwarding it
properly.

-- Forwarded message --
From: Eugeni Dodonov 
Date: Thu, Jan 5, 2012 at 09:34
Subject: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus
is not responding
To: intel-...@lists.freedesktop.org
Cc: Eugeni Dodonov 


This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.

Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.

This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
and improve overall edid detection timing by 10-30% in most cases, and by
a much larger margin in case of phantom outputs (up to 30x in one worst
case).

Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s

Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s

Reviewed-by: Chris Wilson 
Reviewed-by: Keith Packard 
Tested-by: Sean Finney 
Tested-by: Soren Hansen 
Tested-by: Hernando Torque 
Tested-by: Mike Lothian 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov 
---
 drivers/gpu/drm/drm_edid.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3e927ce..fb6c26c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -266,6 +266,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
   }
   };
   ret = i2c_transfer(adapter, msgs, 2);
+   if (ret == -ENXIO) {
+   DRM_DEBUG_KMS("drm: skipping non-existent adapter
%s\n",
+   adapter->name);
+   break;
+   }
   } while (ret != 2 && --retries);

   return ret == 2 ? 0 : -1;
--
1.7.8

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



-- 
Eugeni Dodonov

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

[Bug 42616] Radeon Kernel Mode Setting sets wrong mode

[bugzilla-daemon]

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





--- Comment #4 from W Thomas Jones   2012-01-20 
20:11:38 ---
Created an attachment (id=72139)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72139)
dmesg UMS

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

[bugzilla-daemon]

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





--- Comment #5 from W Thomas Jones   2012-01-20 
20:11:54 ---
Created an attachment (id=72140)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72140)
dmesg KMS

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

[bugzilla-daemon]

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





--- Comment #6 from W Thomas Jones   2012-01-20 
20:12:08 ---
Created an attachment (id=72141)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72141)
KMS Xorg log

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

[bugzilla-daemon]

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





--- Comment #7 from W Thomas Jones   2012-01-20 
20:12:25 ---
Created an attachment (id=72142)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72142)
KMS xrandr --verbose

-- 
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: radeon issues on MacBook Pro 8,2

[Alex Deucher]

On Fri, Jan 20, 2012 at 4:12 PM, Seth Forshee
 wrote:
> On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote:
>> On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee
>>  wrote:
>> > On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
>> >> > >  2. Occasional long delays when suspending. When this happens I see
>> >> > >    messages like following in dmesg:
>> >> > >
>> >> > >      [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 
>> >> > > 5secs aborting
>> >> > >      [drm:atom_execute_table_locked] *ERROR* atombios stuck executing 
>> >> > > D44E (len 62, WS 0, PS 0) @ 0xD46A
>> >> > >
>> >> > >    Sometimes one of suspend or resume hangs completely, but I can't
>> >> > >    tell which and am not sure whether or not it's related. I'm also
>> >> > >    testing a Mac Mini with the exact same card which does not seem to
>> >> > >    suffer from this issue.
>> >> > >
>> >> > >    I ran a bisections that identified f8d0edd (drm/radeon/kms: improve
>> >> > >    DP detect logic) as introducing problems with suspend, and 
>> >> > > reverting
>> >> > >    this patch on top of 3.2.1 does seem to eliminate both issues.
>> >> > >
>> >> >
>> >> > That patch doesn't really affect the modesetting paths directly; it
>> >> > looks like a red herring to me.
>> >>
>> >> Perhaps. I just started a run of 200 s3 cycles with the patch reverted
>> >> to see if I can reproduce the issues. I can usually trigger the problem
>> >> with 15 or fewer s3 cycles.
>> >
>> > The machine completed 200 s3 cycles with the patch reverted without long
>> > delays, hangs, or any atombios error messages. Without reverting it
>> > doesn't get through many at all before experiencing the errors and long
>> > delays or hangs.
>> >
>> > I added a printout of the connector status resulting from the logic that
>> > was changed by f8d0edd. With the logic prior to this commit it
>> > consistently returns the status as disconnected, which is correct as I
>> > have nothing connected. But with the improved logic the status is
>> > sometimes reported as connected, and these coincide with the atombios
>> > errors.
>> >
>>
>> Do any of the disconnected displayport connectors get misdetected as
>> connected during normal operation or does it only happen during
>> suspend/resume?
>
> So far I've only seen them during suspend/resume.

Can you track down who is calling the connector->detect() callbacks
during suspend and resume?

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

Re: radeon issues on MacBook Pro 8,2

[Pasi Kärkkäinen]

On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote:
> > On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee
> >  wrote:
> > > I'm seeing several issues related to the radeon driver on a MacBook Pro
> > > 8,2 with the following graphics card:
> > >
> > >  ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
> > >
> > > All problems were observed when using kernel version 3.2.1. None are
> > > seen when using fglrx.
> > >
> > >  1. Excessive power draw. When using the radeon driver ACPI reports a
> > >    power draw of about 30W on an idle desktop. Using fglrx brings this
> > >    number down to 15W.
> > 
> > The power saving features of the open source driver are not yet as
> > good as the closed source driver.  Please see the power management
> > section of this page (http://wiki.x.org/wiki/RadeonFeature) for more
> > info on the options currently available.
> 
> The dynpm option makes a small difference, saving about 2W. I did notice
> an ocassional flash on the screen with this option, and the same flash
> each time I changed the power options.
> 

Btw how do you measure the power draw? 


> The only thing that improves things significatnly is the "low" profile
> method, which gets it down to about 18.5W.
> 

I have older radeon (Mobility HD3650) and only the "low" profile makes it 
usable.. 
the "default" profile will overheat the laptop and crash it, or then Linux does 
automatic emergency thermal shutdown to protect the laptop.

If I boot some Linux livecd the laptop will basicly overheat and shutdown by 
itself
before the desktop is loaded from the livecd.. :( 

-- Pasi

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

[Bug 45018] New: [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

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

 Bug #: 45018
   Summary: [bisected] rendering regression since added support
for virtual address space on cayman v11
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: alexandre.f.dem...@gmail.com


Created attachment 55888
  --> https://bugs.freedesktop.org/attachment.cgi?id=55888
Good rendering

When testing RenderFeatTest.bin64, the shadows on test07 are not rendered
correctly anymore. Bisecting identified the following commit as culprit:

bb1f0cf3508630a9a93512c79badf8c493c46743 is the first bad commit
commit bb1f0cf3508630a9a93512c79badf8c493c46743
Author: Jerome Glisse 
Date:   Fri Dec 2 10:20:29 2011 -0500

r600g: add support for virtual address space on cayman v11

I'll be attaching pictures to show the regression.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

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

--- Comment #1 from Alexandre Demers  2012-01-20 
22:03:32 UTC ---
By the way, I'm using latest drm and kernel from git. I have pcie_gen2 enabled.
I'm running Ubuntu Oneiric with a HD6950.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

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

--- Comment #2 from Alexandre Demers  2012-01-20 
22:04:48 PST ---
Created attachment 55889
  --> https://bugs.freedesktop.org/attachment.cgi?id=55889
Bad rendering

Projected shadows are not rendered correctly anymore.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 44955] Screen flickers after LVDS turned off and back on with MacBook Pro 8,2 (Radeon HD 6600M)

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

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

--- Comment #3 from Seth Forshee  2012-01-19 
18:11:28 PST ---
(In reply to comment #2)
> Do these patches help?
> http://people.freedesktop.org/~agd5f/dce_fixes/
> They are against drm-next or Linus' tree.

Yes, those patches eliminate the flicker.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44919] Wayland clients segfault

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

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

--- Comment #4 from Damien Grassart  2012-01-20 
02:51:07 PST ---
Hi, I can confirm this issue also happens with a r600 card. Here's an example
of my backtrace from the weston-desktop-shell client crashing:

#0  0x74601fba in st_framebuffer_validate.isra.3 () from
/home/damien/lib/dri/r600_dri.so
#1  0x74603469 in st_api_make_current () from
/home/damien/lib/dri/r600_dri.so
#2  0x745bbe8f in driBindContext () from
/home/damien/lib/dri/r600_dri.so
#3  0x771bde90 in dri2_make_current () from
/home/damien/lib/libEGL.so.1
#4  0x771b6159 in eglMakeCurrent () from /home/damien/lib/libEGL.so.1
#5  0x7771e58d in cairo_egl_device_create () from
/home/damien/lib/libcairo.so.2
#6  0x00409545 in init_egl (d=0x620630) at window.c:2822
#7  display_create (argc=0x7fffde0c, argv=0x7fffde00,
option_entries=) at window.c:2926
#8  0x004040a6 in main (argc=1, argv=0x7fffdf58) at
desktop-shell.c:672

When I build mesa from commit 21b28d520ff218d165e86aa71dbd02050a3aa0cd (just
before the first bad commit), then it works fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] MAINTAINERS: Add dma-buf sharing framework maintainer

[Dave Airlie]

On Thu, Jan 19, 2012 at 10:39 AM, Daniel Vetter  wrote:
> On Thu, Jan 19, 2012 at 03:04:25PM +0530, Sumit Semwal wrote:
>> Adding maintainer info for dma-buf buffer sharing framework;
>> some mailing lists interested in this work are also added.
>>
>> Signed-off-by: Sumit Semwal 
>> Signed-off-by: Sumit Semwal 
>> Acked-by: Arnd Bergmann 
>
> Acked-by: Daniel Vetter 

Acked-by: Dave Airlie 

Should just send to Linus with these acks in it.

Dave.

[PATCH] MAINTAINERS: Add dma-buf sharing framework maintainer

[Dave Airlie]

On Fri, Jan 20, 2012 at 11:17 AM, Sumit Semwal  
wrote:
>
> On Jan 20, 2012 4:33 PM, "Dave Airlie"  wrote:
>>
>> On Thu, Jan 19, 2012 at 10:39 AM, Daniel Vetter  wrote:
>> > On Thu, Jan 19, 2012 at 03:04:25PM +0530, Sumit Semwal wrote:
>> >> Adding maintainer info for dma-buf buffer sharing framework;
>> >> some mailing lists interested in this work are also added.
>> >>
>> >> Signed-off-by: Sumit Semwal 
>> >> Signed-off-by: Sumit Semwal 
>> >> Acked-by: Arnd Bergmann 
>> >
>> > Acked-by: Daniel Vetter 
>>
>> Acked-by: Dave Airlie 
>>
>> Should just send to Linus with these acks in it.
> Thanks Daniel and Dave!
> Dave,
> Would it be OK for you to queue it through your for-linus, or just the patch
> to Linus will be enough ?

Send it to Linus direct, hopefully he notices it.

Dave.

[Linaro-mm-sig] [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

[Laurent Pinchart]

Hi Summit,

Sorry for the late review. I know that this code is now in mainline, but I 
still have a couple of comments. I'll send patches if you agree with them.

On Monday 26 December 2011 10:23:15 Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
> 
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
> 
> The framework allows:
> - creation of a buffer object, its association with a file pointer, and
>associated allocator-defined operations on that buffer. This operation
> is called the 'export' operation.
> - different devices to 'attach' themselves to this exported buffer object,
> to facilitate backing storage negotiation, using dma_buf_attach() API. -
> the exported buffer object to be shared with the other entity by asking
> for its 'file-descriptor (fd)', and sharing the fd across.
> - a received fd to get the buffer object back, where it can be accessed
> using the associated exporter-defined operations.
> - the exporter and user to share the scatterlist associated with this
> buffer object using map_dma_buf and unmap_dma_buf operations.
> 
> Atleast one 'attach()' call is required to be made prior to calling the
> map_dma_buf() operation.
> 
> Couple of building blocks in map_dma_buf() are added to ease introduction
> of sync'ing across exporter and users, and late allocation by the exporter.
> 
> For this first version, this framework will work with certain conditions:
> - *ONLY* exporter will be allowed to mmap to userspace (outside of this
>framework - mmap is not a buffer object operation),
> - currently, *ONLY* users that do not need CPU access to the buffer are
>allowed.
> 
> More details are there in the documentation patch.
> 
> This is based on design suggestions from many people at the
> mini-summits[1], most notably from Arnd Bergmann , Rob
> Clark  and Daniel Vetter .
> 
> The implementation is inspired from proof-of-concept patch-set from
> Tomasz Stanislawski , who demonstrated buffer
> sharing between two v4l2 devices. [2]
> 
> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
> [2]: http://lwn.net/Articles/454389
> 
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Dave Airlie 
> Reviewed-and-Tested-by: Rob Clark 
> ---
>  drivers/base/Kconfig|   10 ++
>  drivers/base/Makefile   |1 +
>  drivers/base/dma-buf.c  |  291
> +++ include/linux/dma-buf.h | 
> 176 
>  4 files changed, 478 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/base/dma-buf.c
>  create mode 100644 include/linux/dma-buf.h
> 

[snip]

> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> new file mode 100644
> index 000..e38ad24
> --- /dev/null
> +++ b/drivers/base/dma-buf.c
> @@ -0,0 +1,291 @@

[snip]

> +/**
> + * dma_buf_export - Creates a new dma_buf, and associates an anon file
> + * with this buffer, so it can be exported.
> + * Also connect the allocator specific data and ops to the buffer.
> + *
> + * @priv:[in]Attach private data of allocator to this buffer
> + * @ops: [in]Attach allocator-defined dma buf ops to the new buffer.
> + * @size:[in]Size of the buffer
> + * @flags:   [in]mode flags for the file.
> + *
> + * Returns, on success, a newly created dma_buf object, which wraps the
> + * supplied private data and operations for dma_buf_ops. On either missing
> + * ops, or error in allocating struct dma_buf, will return negative error.
> + *
> + */
> +struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
> + size_t size, int flags)
> +{
> + struct dma_buf *dmabuf;
> + struct file *file;
> +
> + if (WARN_ON(!priv || !ops
> +   || !ops->map_dma_buf
> +   || !ops->unmap_dma_buf
> +   || !ops->release)) {
> + return ERR_PTR(-EINVAL);
> + }
> +
> + dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
> + if (dmabuf == NULL)
> + return ERR_PTR(-ENOMEM);
> +
> + dmabuf->priv = priv;
> + dmabuf->ops = ops;

dmabuf->ops will never but NULL, but (see below)

> + dmabuf->size = size;
> +
> + file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
> +
> + dmabuf->file = file;
> +
> + mutex_init(&dmabuf->lock);
> + INIT_LIST_HEAD(&dmabuf->attachments);
> +
> + return dmabuf;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_export);

[snip]

> +/**
> + * dma_buf_attach - Add the device to dma_buf's attachments list;
> optionally, + * calls attach() of dma_buf_ops to allow device-specific
> attach functionality + * @dmabuf: [in]buffer to attach device to.
> + * @dev: [in]device to be attached.
> + *
> + * Returns struct dma_buf_attachment * for this attachment; may return
> negative + * error codes.
> + *
> + 

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #55818|application/octet-stream|text/plain
  mime type||
  Attachment #55818|0   |1
   is patch||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44995] New: Missing support for MGA G200eW WPCM450 [102b:0532]

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

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

 Bug #: 44995
   Summary: Missing support for MGA G200eW WPCM450 [102b:0532]
Classification: Unclassified
   Product: Mesa
   Version: unspecified
  Platform: Other
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/MGA
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: lenlen1982 at gmail.com


Please add support for MGA G200eW WPCM450 pci id 102b:0532

06:03.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA G200eW
WPCM450 [102b:0532] (rev 0a) (prog-if 00 [VGA controller])
Subsystem: Dell PowerEdge R610 MGA G200eW WPCM450 [1028:0236]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 

If you need more info please ask me. I'll feel in this ticket.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

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

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

Dave Airlie  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Dave Airlie  2012-01-20 
08:41:35 PST ---
This chip has no 3D engine, what would mesa be supporting in it?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[GIT PULL]: dma-buf tree: maintainer update

[Semwal, Sumit]

Hi Linus,

Post the merge of dma-buf tree that was (very kindly) sent by Dave
Airlie, various people involved in this project feel it is natural and
practical for me to be the maintainer of this code.

This is my first pull request to you, which only changes the
MAINTAINERS file - could you please pull from it? [If you'd just
prefer the patch, I could post that out as well.]

Thanks and best regards,
~Sumit.

The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:

  Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)

are available in the git repository at:
  git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git for-linus-3.3

Sumit Semwal (1):
  MAINTAINERS: Add dma-buf sharing framework maintainer

 MAINTAINERS |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

[Bug 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

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

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

--- Comment #2 from antonella  2012-01-20 09:10:28 PST 
---
Could we have a /dev/dri/card0 entry for this card?
I tried to run an EGL app under xorg on this card and work fine.
But when i tried to run without X with EGL_PLATFORM=drm or fbdev doesn't work
because i think it cannot open /dev/dri/card0. The same code works fine on
intel/radeon/nouveau on console without X.

Is there any solution or workaround? The kernel seems that doesn't load the mga
module because doesn't recognize this pci id.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

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

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

--- Comment #3 from Alex Deucher  2012-01-20 09:13:31 PST 
---
There is no KMS driver for mga cards.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

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

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

--- Comment #4 from Dave Airlie  2012-01-20 
09:28:19 PST ---
This card has no EGL capabilties to expose.

Unless the application is going to run on top of a sw rendering EGL stack.

But there is no KMS driver for this card at the moment to even do that on top
off.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44995] Missing support for MGA G200eW WPCM450 [102b:0532]

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

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

--- Comment #5 from antonella  2012-01-20 10:12:56 PST 
---
Thank you David. 
As i understand if there is no kms driver for this card i think that there is
no way to run this application out of an xserver session (i.e. in a gnome
terminal) also if i want to go on software rendering?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] dma-buf: Use EXPORT_SYMBOL

[Konrad Rzeszutek Wilk]

On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell  
> > wrote:
> > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > > issue, and not really an interface". ?The dma-buf infrastructure is
> > > explicitly intended as an interface between modules/drivers, so it
> > > should use EXPORT_SYMBOL instead.
> > 
> > + Konrad, Arnd, Mauro: there were strong objections on using
> > EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I

I am going to defer to what David Airlie recommends.

> > suggest we first arrive at a consensus before merging this patch.
> 
> This discussion seems to have stagnated; how do we move forward here?
> 
> Sumit, as the primary author and new maintainer (congrats!) of the
> dma-buf infrastructure, it seems like it's really your call how to
> proceed.  I'd still like to see this be something that we can use from
> the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have
> argued in this thread.  It really seems to me that this change on a
> technical level won't have any adverse effect on the scenarios where it
> can be used today, but it will allow it to be used more widely, which
> will prevent duplication and fragmentation in the future and be greatly
> appreciated by users of hardware such as Optimus.
> 
> Let me know if you have any questions.
> 
> Thanks,
> Robert

[Bug 42616] New: Radeon Kernel Mode Setting sets wrong mode

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

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

   Summary: Radeon Kernel Mode Setting sets wrong mode
   Product: Drivers
   Version: 2.5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: thomas.jones at utoronto.ca
Regression: No


I have a Radeon HD 3470, connected to a Dell P2010H monitor via Display Port.

The monitor's native resolution is 1600x900, and everything works correctly
with UMS, however if I use KMS I cannot use that mode, I can use at least
1024x768, 1280x1024, and 1152x864 with KMS, but no matter how I try I cannot
get it to work in 1600x900. I have tried with the CVT timings, (reduced
blanking and not) and with the ones provided in the monitor's EDID.

If I attempt to set any of those modes (the 1600x900) with KMS on the monitor
claims that I'm using an unsupported mode. UMS works just fine though.

I'm running Fedora, and I don't think this is a regression in the kernel since
I don't think this computer has ever worked with KMS.

Right now what I've done is I have set the kernel command line to boot with
1152x864 and KMS, then I tried to use xrandr to change modes and the monitor
just complained.

dmesg doesn't seem to have anything useful to say, and neither does Xorg.0.log

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

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

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


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #1 from Alex Deucher   2012-01-20 
19:13:28 ---
Please attach your xorg log, 'xrandr --verbose' output, and dmesg output from
both KMS and UMS.

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

radeon issues on MacBook Pro 8,2

[Alex Deucher]

On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee
 wrote:
> On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
>> > > ?2. Occasional long delays when suspending. When this happens I see
>> > > ? ?messages like following in dmesg:
>> > >
>> > > ? ? ?[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 
>> > > 5secs aborting
>> > > ? ? ?[drm:atom_execute_table_locked] *ERROR* atombios stuck executing 
>> > > D44E (len 62, WS 0, PS 0) @ 0xD46A
>> > >
>> > > ? ?Sometimes one of suspend or resume hangs completely, but I can't
>> > > ? ?tell which and am not sure whether or not it's related. I'm also
>> > > ? ?testing a Mac Mini with the exact same card which does not seem to
>> > > ? ?suffer from this issue.
>> > >
>> > > ? ?I ran a bisections that identified f8d0edd (drm/radeon/kms: improve
>> > > ? ?DP detect logic) as introducing problems with suspend, and reverting
>> > > ? ?this patch on top of 3.2.1 does seem to eliminate both issues.
>> > >
>> >
>> > That patch doesn't really affect the modesetting paths directly; it
>> > looks like a red herring to me.
>>
>> Perhaps. I just started a run of 200 s3 cycles with the patch reverted
>> to see if I can reproduce the issues. I can usually trigger the problem
>> with 15 or fewer s3 cycles.
>
> The machine completed 200 s3 cycles with the patch reverted without long
> delays, hangs, or any atombios error messages. Without reverting it
> doesn't get through many at all before experiencing the errors and long
> delays or hangs.
>
> I added a printout of the connector status resulting from the logic that
> was changed by f8d0edd. With the logic prior to this commit it
> consistently returns the status as disconnected, which is correct as I
> have nothing connected. But with the improved logic the status is
> sometimes reported as connected, and these coincide with the atombios
> errors.
>

Do any of the disconnected displayport connectors get misdetected as
connected during normal operation or does it only happen during
suspend/resume?

Alex

[Bug 42616] Radeon Kernel Mode Setting sets wrong mode

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

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





--- Comment #2 from W Thomas Jones   2012-01-20 
19:45:17 ---
Created an attachment (id=72137)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72137)
UMS Xorg.0.log

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

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

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





--- Comment #3 from W Thomas Jones   2012-01-20 
19:47:03 ---
Created an attachment (id=72138)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72138)
xrandr --verbose UMS

the "1600x900Dell" mode is from me explicitly adding a modeline from the EDID
data while I was trying to make it work with KMS

-- 
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] drm/radeon/kms: add some missing semaphore init

[alexdeuc...@gmail.com]

From: Alex Deucher 

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c  |1 +
 drivers/gpu/drm/radeon/evergreend.h |1 +
 drivers/gpu/drm/radeon/ni.c |1 +
 drivers/gpu/drm/radeon/nid.h|1 +
 4 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index ccde2c9..5bd7bae 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1455,6 +1455,7 @@ int evergreen_cp_resume(struct radeon_device *rdev)
 #endif
WREG32(CP_RB_CNTL, tmp);
WREG32(CP_SEM_WAIT_TIMER, 0x0);
+   WREG32(CP_SEM_INCOMPLETE_TIMER_CNTL, 0x0);

/* Set the write pointer delay */
WREG32(CP_RB_WPTR_DELAY, 0);
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index b502216..74713d4 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -108,6 +108,7 @@
 #defineCP_RB_WPTR_ADDR_HI  0xC11C
 #defineCP_RB_WPTR_DELAY0x8704
 #defineCP_SEM_WAIT_TIMER   0x85BC
+#defineCP_SEM_INCOMPLETE_TIMER_CNTL0x85C8
 #defineCP_DEBUG0xC1FC


diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3211372..db09065 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1219,6 +1219,7 @@ int cayman_cp_resume(struct radeon_device *rdev)
RREG32(GRBM_SOFT_RESET);

WREG32(CP_SEM_WAIT_TIMER, 0x0);
+   WREG32(CP_SEM_INCOMPLETE_TIMER_CNTL, 0x0);

/* Set the write pointer delay */
WREG32(CP_RB_WPTR_DELAY, 0);
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index f9df2a6..9a7f3b6 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -222,6 +222,7 @@
 #defineSCRATCH_UMSK0x8540
 #defineSCRATCH_ADDR0x8544
 #defineCP_SEM_WAIT_TIMER   0x85BC
+#defineCP_SEM_INCOMPLETE_TIMER_CNTL0x85C8
 #defineCP_COHER_CNTL2  0x85E8
 #define CP_ME_CNTL 0x86D8
 #defineCP_ME_HALT  (1 << 
28)
-- 
1.7.7.5

[PATCH] drm/radeon/kms/dce3+: add support for hw i2c using atom

[alexdeuc...@gmail.com]

From: Alex Deucher 

Starting with DCE3 hardware, atom contains a general purpose
ProcessI2cChannelTransaction similar to ProcessAuxChannelTransaction.

Add an implementation using the atom tables for DCE3+ hardware.

This should be a little less CPU intensive than bit banging and
may work better in certain cases.

Enable it by setting the radeon hw_i2c module parameter to 1.  E.g.,
radeon.hw_i2c=1
on the kernel command line in grub.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/Makefile   |2 +-
 drivers/gpu/drm/radeon/atombios_i2c.c |  139 +
 drivers/gpu/drm/radeon/radeon_i2c.c   |   21 +
 3 files changed, 161 insertions(+), 1 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/atombios_i2c.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 2139fe8..8410415 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -71,7 +71,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_blit_kms.o radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
evergreen_blit_kms.o \
radeon_trace_points.o ni.o cayman_blit_shaders.o atombios_encoders.o \
-   radeon_semaphore.o radeon_sa.o
+   radeon_semaphore.o radeon_sa.o atombios_i2c.o

 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c 
b/drivers/gpu/drm/radeon/atombios_i2c.c
new file mode 100644
index 000..44d87b6
--- /dev/null
+++ b/drivers/gpu/drm/radeon/atombios_i2c.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright 2011 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Alex Deucher
+ *
+ */
+#include "drmP.h"
+#include "radeon_drm.h"
+#include "radeon.h"
+#include "atom.h"
+
+#define TARGET_HW_I2C_CLOCK 50
+
+/* these are a limitation of ProcessI2cChannelTransaction not the hw */
+#define ATOM_MAX_HW_I2C_WRITE 2
+#define ATOM_MAX_HW_I2C_READ  255
+
+static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan,
+u8 slave_addr, u8 flags,
+u8 *buf, u8 num)
+{
+   struct drm_device *dev = chan->dev;
+   struct radeon_device *rdev = dev->dev_private;
+   PROCESS_I2C_CHANNEL_TRANSACTION_PS_ALLOCATION args;
+   int index = GetIndexIntoMasterTable(COMMAND, 
ProcessI2cChannelTransaction);
+   unsigned char *base;
+   u16 out;
+
+   memset(&args, 0, sizeof(args));
+
+   base = (unsigned char *)rdev->mode_info.atom_context->scratch;
+
+   if (flags & HW_I2C_WRITE) {
+   if (num > ATOM_MAX_HW_I2C_WRITE) {
+   DRM_ERROR("hw i2c: tried to write too many bytes (%d vs 
2)\n", num);
+   return -EINVAL;
+   }
+   memcpy(&out, buf, num);
+   args.lpI2CDataOut = cpu_to_le16(out);
+   } else {
+   if (num > ATOM_MAX_HW_I2C_READ) {
+   DRM_ERROR("hw i2c: tried to read too many bytes (%d vs 
255)\n", num);
+   return -EINVAL;
+   }
+   }
+
+   args.ucI2CSpeed = TARGET_HW_I2C_CLOCK;
+   args.ucRegIndex = 0;
+   args.ucTransBytes = num;
+   args.ucSlaveAddr = slave_addr << 1;
+   args.ucLineNumber = chan->rec.i2c_id;
+
+   atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*)&args);
+
+   /* error */
+   if (args.ucStatus != HW_ASSISTED_I2C_STATUS_SUCCESS) {
+   DRM_DEBUG_KMS("hw_i2c error\n");
+   return -EIO;
+   }
+
+   if (!(flags & HW_I2C_WRITE))
+   memcpy(buf, base, num);
+
+   return 0;
+}
+
+int radeon_atom_hw_i2c_xfer(struct i2c_adapter *i2c_adap,
+   struct i2c_msg *msgs, int num)
+{
+   struct radeon_i2c_chan *i2c = i2c_get

[PATCH] drm/radeon/kms: move disp eng pll setup to init path

[alexdeuc...@gmail.com]

From: Alex Deucher 

We really only need to set it up once on init or resume
rather than on every mode set.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c  |   56 +++
 drivers/gpu/drm/radeon/radeon_device.c  |6 ++-
 drivers/gpu/drm/radeon/radeon_display.c |6 ++-
 drivers/gpu/drm/radeon/radeon_mode.h|1 +
 4 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 0fda830..807b89b 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -355,15 +355,12 @@ static void atombios_crtc_set_timing(struct drm_crtc 
*crtc,
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*)&args);
 }

-static void atombios_disable_ss(struct drm_crtc *crtc)
+static void atombios_disable_ss(struct radeon_device *rdev, int pll_id)
 {
-   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct radeon_device *rdev = dev->dev_private;
u32 ss_cntl;

if (ASIC_IS_DCE4(rdev)) {
-   switch (radeon_crtc->pll_id) {
+   switch (pll_id) {
case ATOM_PPLL1:
ss_cntl = RREG32(EVERGREEN_P1PLL_SS_CNTL);
ss_cntl &= ~EVERGREEN_PxPLL_SS_EN;
@@ -379,7 +376,7 @@ static void atombios_disable_ss(struct drm_crtc *crtc)
return;
}
} else if (ASIC_IS_AVIVO(rdev)) {
-   switch (radeon_crtc->pll_id) {
+   switch (pll_id) {
case ATOM_PPLL1:
ss_cntl = RREG32(AVIVO_P1PLL_INT_SS_CNTL);
ss_cntl &= ~1;
@@ -406,13 +403,11 @@ union atom_enable_ss {
ENABLE_SPREAD_SPECTRUM_ON_PPLL_V3 v3;
 };

-static void atombios_crtc_program_ss(struct drm_crtc *crtc,
+static void atombios_crtc_program_ss(struct radeon_device *rdev,
 int enable,
 int pll_id,
 struct radeon_atom_ss *ss)
 {
-   struct drm_device *dev = crtc->dev;
-   struct radeon_device *rdev = dev->dev_private;
int index = GetIndexIntoMasterTable(COMMAND, 
EnableSpreadSpectrumOnPPLL);
union atom_enable_ss args;

@@ -479,7 +474,7 @@ static void atombios_crtc_program_ss(struct drm_crtc *crtc,
} else if (ASIC_IS_AVIVO(rdev)) {
if ((enable == ATOM_DISABLE) || (ss->percentage == 0) ||
(ss->type & ATOM_EXTERNAL_SS_MASK)) {
-   atombios_disable_ss(crtc);
+   atombios_disable_ss(rdev, pll_id);
return;
}
args.lvds_ss_2.usSpreadSpectrumPercentage = 
cpu_to_le16(ss->percentage);
@@ -491,7 +486,7 @@ static void atombios_crtc_program_ss(struct drm_crtc *crtc,
} else {
if ((enable == ATOM_DISABLE) || (ss->percentage == 0) ||
(ss->type & ATOM_EXTERNAL_SS_MASK)) {
-   atombios_disable_ss(crtc);
+   atombios_disable_ss(rdev, pll_id);
return;
}
args.lvds_ss.usSpreadSpectrumPercentage = 
cpu_to_le16(ss->percentage);
@@ -702,11 +697,9 @@ union set_pixel_clock {
 /* on DCE5, make sure the voltage is high enough to support the
  * required disp clk.
  */
-static void atombios_crtc_set_dcpll(struct drm_crtc *crtc,
+static void atombios_crtc_set_dcpll(struct radeon_device *rdev,
u32 dispclk)
 {
-   struct drm_device *dev = crtc->dev;
-   struct radeon_device *rdev = dev->dev_private;
u8 frev, crev;
int index;
union set_pixel_clock args;
@@ -996,7 +989,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock, 
&fb_div, &frac_fb_div,
  &ref_div, &post_div);

-   atombios_crtc_program_ss(crtc, ATOM_DISABLE, radeon_crtc->pll_id, &ss);
+   atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, &ss);

atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id, 
radeon_crtc->pll_id,
  encoder_mode, radeon_encoder->encoder_id, 
mode->clock,
@@ -1019,7 +1012,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
ss.step = step_size;
}

-   atombios_crtc_program_ss(crtc, ATOM_ENABLE, 
radeon_crtc->pll_id, &ss);
+   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
radeon_crtc->pll_id, &ss);
}
 }

@@ -1494,6 +1487,24 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)

 }

+void radeon_atom_dcpll_init(struct radeon_device *rdev)
+{
+   /* always set DCPLL

[PATCH 1/2] drm/radeon/kms: move panel mode setup into encoder mode set

[alexdeuc...@gmail.com]

From: Alex Deucher 

Needs to happen earlier in the mode set.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_dp.c   |   22 ++
 drivers/gpu/drm/radeon/atombios_encoders.c |   11 +++
 drivers/gpu/drm/radeon/radeon_mode.h   |3 +++
 3 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 6fb335a..a71557c 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -549,8 +549,8 @@ bool radeon_dp_getdpcd(struct radeon_connector 
*radeon_connector)
return false;
 }

-static void radeon_dp_set_panel_mode(struct drm_encoder *encoder,
-struct drm_connector *connector)
+int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
+struct drm_connector *connector)
 {
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
@@ -558,7 +558,7 @@ static void radeon_dp_set_panel_mode(struct drm_encoder 
*encoder,
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;

if (!ASIC_IS_DCE4(rdev))
-   return;
+   return panel_mode;

if (radeon_connector_encoder_get_dp_bridge_encoder_id(connector) ==
ENCODER_OBJECT_ID_NUTMEG)
@@ -572,14 +572,7 @@ static void radeon_dp_set_panel_mode(struct drm_encoder 
*encoder,
panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
}

-   atombios_dig_encoder_setup(encoder,
-  ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
-  panel_mode);
-
-   if ((connector->connector_type == DRM_MODE_CONNECTOR_eDP) &&
-   (panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
-   radeon_write_dpcd_reg(radeon_connector, 
DP_EDP_CONFIGURATION_SET, 1);
-   }
+   return panel_mode;
 }

 void radeon_dp_set_link_config(struct drm_connector *connector,
@@ -717,6 +710,8 @@ static void radeon_dp_set_tp(struct 
radeon_dp_link_train_info *dp_info, int tp)

 static int radeon_dp_link_train_init(struct radeon_dp_link_train_info *dp_info)
 {
+   struct radeon_encoder *radeon_encoder = 
to_radeon_encoder(dp_info->encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
u8 tmp;

/* power up the sink */
@@ -732,7 +727,10 @@ static int radeon_dp_link_train_init(struct 
radeon_dp_link_train_info *dp_info)
radeon_write_dpcd_reg(dp_info->radeon_connector,
  DP_DOWNSPREAD_CTRL, 0);

-   radeon_dp_set_panel_mode(dp_info->encoder, dp_info->connector);
+   if ((dp_info->connector->connector_type == DRM_MODE_CONNECTOR_eDP) &&
+   (dig->panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
+   radeon_write_dpcd_reg(dp_info->radeon_connector, 
DP_EDP_CONFIGURATION_SET, 1);
+   }

/* set the lane count on the sink */
tmp = dp_info->dp_lane_count;
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index f1f06ca..a3a9166 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1811,10 +1811,21 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
*encoder,
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
if (ASIC_IS_DCE4(rdev)) {
+   struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = 
radeon_encoder->enc_priv;
+
+   if (!connector)
+   dig->panel_mode = 
DP_PANEL_MODE_EXTERNAL_DP_MODE;
+   else
+   dig->panel_mode = 
radeon_dp_get_panel_mode(encoder, connector);
+
/* disable the transmitter */
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
/* setup and enable the encoder */
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);
+   atombios_dig_encoder_setup(encoder,
+  
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
+  dig->panel_mode);

/* enable the transmitter */
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index 8cb19f3..d34dcb6 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -362,6 +362,7 @@ struct radeon_encoder_atom_dig {
struct backlight_device *bl_dev;
int dpms_mode;

[PATCH 2/2] drm/radeon/kms: rework modeset sequence for DCE41 and DCE5

[alexdeuc...@gmail.com]

From: Alex Deucher 

dig transmitter control table only has ENABLE/DISABLE actions
on DCE4.1/DCE5.

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_encoders.c |   19 ---
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index a3a9166..79a4880 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1341,7 +1341,8 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, 
int mode)
switch (mode) {
case DRM_MODE_DPMS_ON:
/* some early dce3.2 boards have a bug in their transmitter 
control table */
-   if ((rdev->family == CHIP_RV710) || (rdev->family == 
CHIP_RV730))
+   if ((rdev->family == CHIP_RV710) || (rdev->family == 
CHIP_RV730) ||
+   ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
else
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
@@ -1351,8 +1352,6 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, 
int mode)
 
ATOM_TRANSMITTER_ACTION_POWER_ON);
radeon_dig_connector->edp_on = true;
}
-   if (ASIC_IS_DCE4(rdev))
-   atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_DP_VIDEO_OFF, 0);
radeon_dp_link_train(encoder, connector);
if (ASIC_IS_DCE4(rdev))
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
@@ -1363,7 +1362,10 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder 
*encoder, int mode)
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
-   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE_OUTPUT, 0, 0);
+   if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
+   else
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE_OUTPUT, 0, 0);
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && 
connector) {
if (ASIC_IS_DCE4(rdev))
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_DP_VIDEO_OFF, 0);
@@ -1810,7 +1812,7 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
-   if (ASIC_IS_DCE4(rdev)) {
+   if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
struct radeon_encoder_atom_dig *dig = 
radeon_encoder->enc_priv;

@@ -1819,13 +1821,16 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
*encoder,
else
dig->panel_mode = 
radeon_dp_get_panel_mode(encoder, connector);

-   /* disable the transmitter */
-   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
/* setup and enable the encoder */
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);
atombios_dig_encoder_setup(encoder,
   
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
   dig->panel_mode);
+   } else if (ASIC_IS_DCE4(rdev)) {
+   /* disable the transmitter */
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
+   /* setup and enable the encoder */
+   atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_SETUP, 0);

/* enable the transmitter */
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
-- 
1.7.7.5

[PATCH 1/2] drm/radeon/kms: use drm_detect_hdmi_monitor for picking encoder mode

[alexdeuc...@gmail.com]

From: Alex Deucher 

We were previously just checking for audio.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_encoders.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 79a4880..f2f14a2 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -432,7 +432,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DVII:
case DRM_MODE_CONNECTOR_HDMIB: /* HDMI-B is basically DL-DVI; analog 
works fine */
-   if (drm_detect_monitor_audio(radeon_connector->edid) &&
+   if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
@@ -443,7 +443,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_DVID:
case DRM_MODE_CONNECTOR_HDMIA:
default:
-   if (drm_detect_monitor_audio(radeon_connector->edid) &&
+   if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
@@ -457,7 +457,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if ((dig_connector->dp_sink_type == 
CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
return ATOM_ENCODER_MODE_DP;
-   else if (drm_detect_monitor_audio(radeon_connector->edid) &&
+   else if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
 radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
-- 
1.7.7.5

[PATCH 2/2] drm/radeon/kms: refine TMDS dual link checks

[alexdeuc...@gmail.com]

From: Alex Deucher 

HDMI 1.3 defines single link clocks up to 340 Mhz.
Refine the current dual link checks to only enable
dual link for DVI > 165 Mhz or HDMI > 340 Mhz if the
hw supports HDMI 1.3 (DCE3+).

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

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |4 +-
 drivers/gpu/drm/radeon/atombios_encoders.c |   57 -
 drivers/gpu/drm/radeon/radeon_encoders.c   |   77 
 drivers/gpu/drm/radeon/radeon_mode.h   |4 ++
 4 files changed, 105 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 807b89b..8919352 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -518,6 +518,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
int encoder_mode = 0;
u32 dp_clock = mode->clock;
int bpc = 8;
+   bool is_duallink = false;

/* reset the pll flags */
pll->flags = 0;
@@ -552,6 +553,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (connector && connector->display_info.bpc)
bpc = connector->display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
+   is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(encoder) 
!= ENCODER_OBJECT_ID_NONE)) {
if (connector) {
@@ -647,7 +649,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (dig->coherent_mode)
args.v3.sInput.ucDispPllConfig 
|=

DISPPLL_CONFIG_COHERENT_MODE;
-   if (mode->clock > 165000)
+   if (is_duallink)
args.v3.sInput.ucDispPllConfig 
|=

DISPPLL_CONFIG_DUAL_LINK;
}
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index f2f14a2..b88c460 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -57,22 +57,6 @@ static inline bool radeon_encoder_is_digital(struct 
drm_encoder *encoder)
}
 }

-static struct drm_connector *
-radeon_get_connector_for_encoder_init(struct drm_encoder *encoder)
-{
-   struct drm_device *dev = encoder->dev;
-   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
-   struct drm_connector *connector;
-   struct radeon_connector *radeon_connector;
-
-   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   radeon_connector = to_radeon_connector(connector);
-   if (radeon_encoder->devices & radeon_connector->devices)
-   return connector;
-   }
-   return NULL;
-}
-
 static bool radeon_atom_mode_fixup(struct drm_encoder *encoder,
   struct drm_display_mode *mode,
   struct drm_display_mode *adjusted_mode)
@@ -253,7 +237,7 @@ atombios_dvo_setup(struct drm_encoder *encoder, int action)
/* R4xx, R5xx */
args.ext_tmds.sXTmdsEncoder.ucEnable = action;

-   if (radeon_encoder->pixel_clock > 165000)
+   if (radeon_dig_monitor_is_duallink(encoder, 
radeon_encoder->pixel_clock))
args.ext_tmds.sXTmdsEncoder.ucMisc |= 
PANEL_ENCODER_MISC_DUAL;

args.ext_tmds.sXTmdsEncoder.ucMisc |= 
ATOM_PANEL_MISC_888RGB;
@@ -265,7 +249,7 @@ atombios_dvo_setup(struct drm_encoder *encoder, int action)
/* DFP1, CRT1, TV1 depending on the type of port */
args.dvo.sDVOEncoder.ucDeviceType = 
ATOM_DEVICE_DFP1_INDEX;

-   if (radeon_encoder->pixel_clock > 165000)
+   if (radeon_dig_monitor_is_duallink(encoder, 
radeon_encoder->pixel_clock))

args.dvo.sDVOEncoder.usDevAttr.sDigAttrib.ucAttribute |= 
PANEL_ENCODER_MISC_DUAL;
break;
case 3:
@@ -349,7 +333,7 @@ atombios_digital_setup(struct drm_encoder *encoder, int 
action)
} else {
if (dig->linkb)
args.v1.ucMisc |= 
PANEL_ENCODER_MISC_TMDS_LINKB;
-   if (radeon_encoder->pixel_clock > 165000)
+

Fwd: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

[Eugeni Dodonov]

Looks like a CC to dri-devel got forgotten originally, so forwarding it
properly.

-- Forwarded message --
From: Eugeni Dodonov 
Date: Thu, Jan 5, 2012 at 09:34
Subject: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus
is not responding
To: intel-gfx at lists.freedesktop.org
Cc: Eugeni Dodonov 


This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.

Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.

This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
and improve overall edid detection timing by 10-30% in most cases, and by
a much larger margin in case of phantom outputs (up to 30x in one worst
case).

Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s

Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s

Reviewed-by: Chris Wilson 
Reviewed-by: Keith Packard 
Tested-by: Sean Finney 
Tested-by: Soren Hansen 
Tested-by: Hernando Torque 
Tested-by: Mike Lothian 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov 
---
 drivers/gpu/drm/drm_edid.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3e927ce..fb6c26c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -266,6 +266,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
   }
   };
   ret = i2c_transfer(adapter, msgs, 2);
+   if (ret == -ENXIO) {
+   DRM_DEBUG_KMS("drm: skipping non-existent adapter
%s\n",
+   adapter->name);
+   break;
+   }
   } while (ret != 2 && --retries);

   return ret == 2 ? 0 : -1;
--
1.7.8

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



-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120120/de08ae41/attachment.htm>

[Bug 42616] Radeon Kernel Mode Setting sets wrong mode

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

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





--- Comment #4 from W Thomas Jones   2012-01-20 
20:11:38 ---
Created an attachment (id=72139)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72139)
dmesg UMS

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

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

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





--- Comment #5 from W Thomas Jones   2012-01-20 
20:11:54 ---
Created an attachment (id=72140)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72140)
dmesg KMS

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

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

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





--- Comment #6 from W Thomas Jones   2012-01-20 
20:12:08 ---
Created an attachment (id=72141)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72141)
KMS Xorg log

-- 
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 42616] Radeon Kernel Mode Setting sets wrong mode

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

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





--- Comment #7 from W Thomas Jones   2012-01-20 
20:12:25 ---
Created an attachment (id=72142)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72142)
KMS xrandr --verbose

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

radeon issues on MacBook Pro 8,2

[Alex Deucher]

On Fri, Jan 20, 2012 at 4:12 PM, Seth Forshee
 wrote:
> On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote:
>> On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee
>>  wrote:
>> > On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
>> >> > > ?2. Occasional long delays when suspending. When this happens I see
>> >> > > ? ?messages like following in dmesg:
>> >> > >
>> >> > > ? ? ?[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 
>> >> > > 5secs aborting
>> >> > > ? ? ?[drm:atom_execute_table_locked] *ERROR* atombios stuck executing 
>> >> > > D44E (len 62, WS 0, PS 0) @ 0xD46A
>> >> > >
>> >> > > ? ?Sometimes one of suspend or resume hangs completely, but I can't
>> >> > > ? ?tell which and am not sure whether or not it's related. I'm also
>> >> > > ? ?testing a Mac Mini with the exact same card which does not seem to
>> >> > > ? ?suffer from this issue.
>> >> > >
>> >> > > ? ?I ran a bisections that identified f8d0edd (drm/radeon/kms: improve
>> >> > > ? ?DP detect logic) as introducing problems with suspend, and 
>> >> > > reverting
>> >> > > ? ?this patch on top of 3.2.1 does seem to eliminate both issues.
>> >> > >
>> >> >
>> >> > That patch doesn't really affect the modesetting paths directly; it
>> >> > looks like a red herring to me.
>> >>
>> >> Perhaps. I just started a run of 200 s3 cycles with the patch reverted
>> >> to see if I can reproduce the issues. I can usually trigger the problem
>> >> with 15 or fewer s3 cycles.
>> >
>> > The machine completed 200 s3 cycles with the patch reverted without long
>> > delays, hangs, or any atombios error messages. Without reverting it
>> > doesn't get through many at all before experiencing the errors and long
>> > delays or hangs.
>> >
>> > I added a printout of the connector status resulting from the logic that
>> > was changed by f8d0edd. With the logic prior to this commit it
>> > consistently returns the status as disconnected, which is correct as I
>> > have nothing connected. But with the improved logic the status is
>> > sometimes reported as connected, and these coincide with the atombios
>> > errors.
>> >
>>
>> Do any of the disconnected displayport connectors get misdetected as
>> connected during normal operation or does it only happen during
>> suspend/resume?
>
> So far I've only seen them during suspend/resume.

Can you track down who is calling the connector->detect() callbacks
during suspend and resume?

Alex

radeon issues on MacBook Pro 8,2

[Pasi Kärkkäinen]

On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote:
> > On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee
> >  wrote:
> > > I'm seeing several issues related to the radeon driver on a MacBook Pro
> > > 8,2 with the following graphics card:
> > >
> > > ?ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
> > >
> > > All problems were observed when using kernel version 3.2.1. None are
> > > seen when using fglrx.
> > >
> > > ?1. Excessive power draw. When using the radeon driver ACPI reports a
> > > ? ?power draw of about 30W on an idle desktop. Using fglrx brings this
> > > ? ?number down to 15W.
> > 
> > The power saving features of the open source driver are not yet as
> > good as the closed source driver.  Please see the power management
> > section of this page (http://wiki.x.org/wiki/RadeonFeature) for more
> > info on the options currently available.
> 
> The dynpm option makes a small difference, saving about 2W. I did notice
> an ocassional flash on the screen with this option, and the same flash
> each time I changed the power options.
> 

Btw how do you measure the power draw? 


> The only thing that improves things significatnly is the "low" profile
> method, which gets it down to about 18.5W.
> 

I have older radeon (Mobility HD3650) and only the "low" profile makes it 
usable.. 
the "default" profile will overheat the laptop and crash it, or then Linux does 
automatic emergency thermal shutdown to protect the laptop.

If I boot some Linux livecd the laptop will basicly overheat and shutdown by 
itself
before the desktop is loaded from the livecd.. :( 

-- Pasi

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

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

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

--- Comment #1 from Alexandre Demers  
2012-01-20 22:03:32 UTC ---
By the way, I'm using latest drm and kernel from git. I have pcie_gen2 enabled.
I'm running Ubuntu Oneiric with a HD6950.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] MAINTAINERS: Add dma-buf sharing framework maintainer

[Sumit Semwal]

On Jan 20, 2012 4:33 PM, "Dave Airlie"  wrote:
>
> On Thu, Jan 19, 2012 at 10:39 AM, Daniel Vetter  wrote:
> > On Thu, Jan 19, 2012 at 03:04:25PM +0530, Sumit Semwal wrote:
> >> Adding maintainer info for dma-buf buffer sharing framework;
> >> some mailing lists interested in this work are also added.
> >>
> >> Signed-off-by: Sumit Semwal 
> >> Signed-off-by: Sumit Semwal 
> >> Acked-by: Arnd Bergmann 
> >
> > Acked-by: Daniel Vetter 
>
> Acked-by: Dave Airlie 
>
> Should just send to Linus with these acks in it.
Thanks Daniel and Dave!
Dave,
Would it be OK for you to queue it through your for-linus, or just the
patch to Linus will be enough ?
>
> Dave.
-- next part ------
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120120/1eb9ee97/attachment.html>

radeon issues on MacBook Pro 8,2

[Seth Forshee]

On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> > > ?2. Occasional long delays when suspending. When this happens I see
> > > ? ?messages like following in dmesg:
> > >
> > > ? ? ?[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 
> > > 5secs aborting
> > > ? ? ?[drm:atom_execute_table_locked] *ERROR* atombios stuck executing 
> > > D44E (len 62, WS 0, PS 0) @ 0xD46A
> > >
> > > ? ?Sometimes one of suspend or resume hangs completely, but I can't
> > > ? ?tell which and am not sure whether or not it's related. I'm also
> > > ? ?testing a Mac Mini with the exact same card which does not seem to
> > > ? ?suffer from this issue.
> > >
> > > ? ?I ran a bisections that identified f8d0edd (drm/radeon/kms: improve
> > > ? ?DP detect logic) as introducing problems with suspend, and reverting
> > > ? ?this patch on top of 3.2.1 does seem to eliminate both issues.
> > >
> > 
> > That patch doesn't really affect the modesetting paths directly; it
> > looks like a red herring to me.
> 
> Perhaps. I just started a run of 200 s3 cycles with the patch reverted
> to see if I can reproduce the issues. I can usually trigger the problem
> with 15 or fewer s3 cycles.

The machine completed 200 s3 cycles with the patch reverted without long
delays, hangs, or any atombios error messages. Without reverting it
doesn't get through many at all before experiencing the errors and long
delays or hangs. 

I added a printout of the connector status resulting from the logic that
was changed by f8d0edd. With the logic prior to this commit it
consistently returns the status as disconnected, which is correct as I
have nothing connected. But with the improved logic the status is
sometimes reported as connected, and these coincide with the atombios
errors.

Seth

[PATCH] dma-buf: Use EXPORT_SYMBOL

[Robert Morell]

On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell  wrote:
> > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > issue, and not really an interface". ?The dma-buf infrastructure is
> > explicitly intended as an interface between modules/drivers, so it
> > should use EXPORT_SYMBOL instead.
> 
> + Konrad, Arnd, Mauro: there were strong objections on using
> EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I
> suggest we first arrive at a consensus before merging this patch.

This discussion seems to have stagnated; how do we move forward here?

Sumit, as the primary author and new maintainer (congrats!) of the
dma-buf infrastructure, it seems like it's really your call how to
proceed.  I'd still like to see this be something that we can use from
the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have
argued in this thread.  It really seems to me that this change on a
technical level won't have any adverse effect on the scenarios where it
can be used today, but it will allow it to be used more widely, which
will prevent duplication and fragmentation in the future and be greatly
appreciated by users of hardware such as Optimus.

Let me know if you have any questions.

Thanks,
Robert

[PATCH] drm: remove master fd restriction on mode setting getters

[Mandeep Singh Baines]

Its useful to be able to call the mode setting getter ioctls.
Not requiring master fd, enables writing a simple program which
can query the state of the video system.

Since these ioctls are only "getters" there is no security or
synchronization issues which would require master fd. Opening
an new fd is already protected by the file permissions on the
device file.

Signed-off-by: Mandeep Singh Baines 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Ilija Hadzic 
Cc: Jesse Barnes 
Cc: Stephane Marchesin 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_drv.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index ebf7d3f..d166bd0 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -135,23 +135,23 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
DRM_AUTH|DRM_UNLOCKED),

-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANE, drm_mode_getplane, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPLANE, drm_mode_setplane, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR, drm_mode_cursor_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl, 
DRM_MASTER|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl, 
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETGAMMA, drm_mode_gamma_set_ioctl, 
DRM_MASTER|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_mode_attachmode_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_mode_detachmode_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl, 
DRM_MASTER | DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY, 
drm_mode_connector_property_set_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-- 
1.7.3.4

radeon issues on MacBook Pro 8,2

[Seth Forshee]

On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote:
> On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee
>  wrote:
> > On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> >> > > ?2. Occasional long delays when suspending. When this happens I see
> >> > > ? ?messages like following in dmesg:
> >> > >
> >> > > ? ? ?[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 
> >> > > 5secs aborting
> >> > > ? ? ?[drm:atom_execute_table_locked] *ERROR* atombios stuck executing 
> >> > > D44E (len 62, WS 0, PS 0) @ 0xD46A
> >> > >
> >> > > ? ?Sometimes one of suspend or resume hangs completely, but I can't
> >> > > ? ?tell which and am not sure whether or not it's related. I'm also
> >> > > ? ?testing a Mac Mini with the exact same card which does not seem to
> >> > > ? ?suffer from this issue.
> >> > >
> >> > > ? ?I ran a bisections that identified f8d0edd (drm/radeon/kms: improve
> >> > > ? ?DP detect logic) as introducing problems with suspend, and reverting
> >> > > ? ?this patch on top of 3.2.1 does seem to eliminate both issues.
> >> > >
> >> >
> >> > That patch doesn't really affect the modesetting paths directly; it
> >> > looks like a red herring to me.
> >>
> >> Perhaps. I just started a run of 200 s3 cycles with the patch reverted
> >> to see if I can reproduce the issues. I can usually trigger the problem
> >> with 15 or fewer s3 cycles.
> >
> > The machine completed 200 s3 cycles with the patch reverted without long
> > delays, hangs, or any atombios error messages. Without reverting it
> > doesn't get through many at all before experiencing the errors and long
> > delays or hangs.
> >
> > I added a printout of the connector status resulting from the logic that
> > was changed by f8d0edd. With the logic prior to this commit it
> > consistently returns the status as disconnected, which is correct as I
> > have nothing connected. But with the improved logic the status is
> > sometimes reported as connected, and these coincide with the atombios
> > errors.
> >
> 
> Do any of the disconnected displayport connectors get misdetected as
> connected during normal operation or does it only happen during
> suspend/resume?

So far I've only seen them during suspend/resume.

radeon issues on MacBook Pro 8,2

[Seth Forshee]

On Fri, Jan 20, 2012 at 04:39:31PM -0500, Alex Deucher wrote:
> On Fri, Jan 20, 2012 at 4:12 PM, Seth Forshee
>  wrote:
> > On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote:
> >> On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee
> >>  wrote:
> >> > On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> >> >> > > ?2. Occasional long delays when suspending. When this happens I see
> >> >> > > ? ?messages like following in dmesg:
> >> >> > >
> >> >> > > ? ? ?[drm:atom_op_jump] *ERROR* atombios stuck in loop for more 
> >> >> > > than 5secs aborting
> >> >> > > ? ? ?[drm:atom_execute_table_locked] *ERROR* atombios stuck 
> >> >> > > executing D44E (len 62, WS 0, PS 0) @ 0xD46A
> >> >> > >
> >> >> > > ? ?Sometimes one of suspend or resume hangs completely, but I can't
> >> >> > > ? ?tell which and am not sure whether or not it's related. I'm also
> >> >> > > ? ?testing a Mac Mini with the exact same card which does not seem 
> >> >> > > to
> >> >> > > ? ?suffer from this issue.
> >> >> > >
> >> >> > > ? ?I ran a bisections that identified f8d0edd (drm/radeon/kms: 
> >> >> > > improve
> >> >> > > ? ?DP detect logic) as introducing problems with suspend, and 
> >> >> > > reverting
> >> >> > > ? ?this patch on top of 3.2.1 does seem to eliminate both issues.
> >> >> > >
> >> >> >
> >> >> > That patch doesn't really affect the modesetting paths directly; it
> >> >> > looks like a red herring to me.
> >> >>
> >> >> Perhaps. I just started a run of 200 s3 cycles with the patch reverted
> >> >> to see if I can reproduce the issues. I can usually trigger the problem
> >> >> with 15 or fewer s3 cycles.
> >> >
> >> > The machine completed 200 s3 cycles with the patch reverted without long
> >> > delays, hangs, or any atombios error messages. Without reverting it
> >> > doesn't get through many at all before experiencing the errors and long
> >> > delays or hangs.
> >> >
> >> > I added a printout of the connector status resulting from the logic that
> >> > was changed by f8d0edd. With the logic prior to this commit it
> >> > consistently returns the status as disconnected, which is correct as I
> >> > have nothing connected. But with the improved logic the status is
> >> > sometimes reported as connected, and these coincide with the atombios
> >> > errors.
> >> >
> >>
> >> Do any of the disconnected displayport connectors get misdetected as
> >> connected during normal operation or does it only happen during
> >> suspend/resume?
> >
> > So far I've only seen them during suspend/resume.
> 
> Can you track down who is calling the connector->detect() callbacks
> during suspend and resume?

I got two different stack traces, see below.

And to slightly amend my statement above, I'm only seeing the wrong
status returned on the suspend side of things. The status during resume
always seems to be correct.

 Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu
 Call Trace:
  [] radeon_dp_detect+0x1de/0x230 [radeon]
  [] output_poll_execute+0xbd/0x1a0 [drm_kms_helper]
  [] ? drm_helper_mode_fill_fb_struct+0x30/0x30 
[drm_kms_helper]
  [] process_one_work+0x11a/0x480
  [] worker_thread+0x164/0x370
  [] ? manage_workers.isra.30+0x130/0x130
  [] kthread+0x8c/0xa0
  [] kernel_thread_helper+0x4/0x10
  [] ? flush_kthread_worker+0xa0/0xa0
  [] ? gs_change+0x13/0x13

 Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu
 Call Trace:
  [] radeon_dp_detect+0x1de/0x230 [radeon]
  [] drm_helper_probe_single_connector_modes+0x2c3/0x380 
[drm_kms_helper]
  [] drm_fb_helper_hotplug_event+0xf2/0x150 [drm_kms_helper]
  [] radeon_fb_output_poll_changed+0x15/0x20 [radeon]
  [] radeon_output_poll_changed+0x15/0x20 [radeon]
  [] output_poll_execute+0x190/0x1a0 [drm_kms_helper]
  [] ? drm_helper_mode_fill_fb_struct+0x30/0x30 
[drm_kms_helper]
  [] process_one_work+0x11a/0x480
  [] worker_thread+0x164/0x370
  [] ? manage_workers.isra.30+0x130/0x130
  [] kthread+0x8c/0xa0
  [] kernel_thread_helper+0x4/0x10
  [] ? flush_kthread_worker+0xa0/0xa0
  [] ? gs_change+0x13/0x13

radeon issues on MacBook Pro 8,2

[Seth Forshee]

On Fri, Jan 20, 2012 at 11:09:29PM +0200, Pasi K?rkk?inen wrote:
> On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> > On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote:
> > > On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee
> > >  wrote:
> > > > I'm seeing several issues related to the radeon driver on a MacBook Pro
> > > > 8,2 with the following graphics card:
> > > >
> > > > ?ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
> > > >
> > > > All problems were observed when using kernel version 3.2.1. None are
> > > > seen when using fglrx.
> > > >
> > > > ?1. Excessive power draw. When using the radeon driver ACPI reports a
> > > > ? ?power draw of about 30W on an idle desktop. Using fglrx brings this
> > > > ? ?number down to 15W.
> > > 
> > > The power saving features of the open source driver are not yet as
> > > good as the closed source driver.  Please see the power management
> > > section of this page (http://wiki.x.org/wiki/RadeonFeature) for more
> > > info on the options currently available.
> > 
> > The dynpm option makes a small difference, saving about 2W. I did notice
> > an ocassional flash on the screen with this option, and the same flash
> > each time I changed the power options.
> > 
> 
> Btw how do you measure the power draw? 

You can get the instantaneous rate from the data under
/proc/acpi/battery, but I use a tool called powerstat [1], written by my
colleague Colin King. The advantage of powerstat is that it samples the
ACPI data over a period of time and reports the average and standard
deviation. That way I have a better idea of how much power is really
being drawn and the quality of the value reported.

[1] http://kernel.ubuntu.com/git?p=cking/powerstat.git