On Tuesday 29 of October 2013 12:12:55 Sean Paul wrote:
> This patch renames the display_op power_on to dpms to accurately reflect
> what the function does.
>
> The side-effect of this patch is that the new hdmi dpms callback is now
> invoked twice in the dpms path. This is safe and will be dealt
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.
Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.
Apply the protections from
commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie
Date: Sat Aug 14 20:20
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.
Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.
Apply the protections from
commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie
Date: Sat Aug 14 20:20
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.
Apply the protections from
commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie
Date: Sat Aug 14 20:20:
On Tuesday 29 of October 2013 12:12:54 Sean Paul wrote:
> This patch removes the call from encoder dpms into connector dpms (which
> will then call back into encoder dpms through the helper function). The
> callback is likely to keep connector->dpms in the right state when
> initiating dpms from cr
On Tuesday 29 of October 2013 12:12:53 Sean Paul wrote:
> This patch removes the apply() manager callback in favor of putting the
> relevant commits in the individual drivers. This will mitigate some of
> the difference between the suspend/resume path and the dpms path
>
> Signed-off-by: Sean Paul
Hi Dave,
So here's the Broadwell pull request. From a kernel driver pov there's
two areas with big changes in Broadwell:
- Completely new enumerated interrupt bits. On the plus side it now looks
fairly unform and sane.
- Completely new pagetable layout.
To ensure minimal impact on existing plat
On Fri, Nov 08, 2013 at 10:10:31AM +0200, Jani Nikula wrote:
> Fix CONFIG_ACPI=n build fail
>
> CC drivers/gpu/drm/i915/intel_opregion.o
> drivers/gpu/drm/i915/intel_opregion.c: In function ?intel_opregion_setup?:
> drivers/gpu/drm/i915/intel_opregion.c:879:2: error: ?asle_work? undeclared
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/f03452ca/attachment-0001.html>
On 11/08/2013 06:19 PM, Daniel Vetter wrote:
> On Fri, Nov 8, 2013 at 11:02 AM, Thomas Hellstrom
> wrote:
>> It seems like prime_handle_from_fd needs to be paired with a GEM_CLOSE ioctl
>> instead of a new generic HANDLE_CLOSE ioctl.
>>
>> This oversight is not really a big problem but there are
On Tue, Nov 05, 2013 at 02:00:08PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> We only depend on the intel-gtt module for GTT frobbign on older gens.
> The intel_agp module is optional, except for UMS and some old XvMC
> userland on gen3. So make AGP support optional
On Fri, Nov 8, 2013 at 9:50 AM, Thomas Hellstrom
wrote:
> This, however comes with two implications
> 1) Once a DMA-buf is added, it stays alive at least until someone removes
> the gem name of the exporting object, regardless whether there are any
> external users or not. I think this is OK, but
On Fri, Nov 8, 2013 at 11:02 AM, Thomas Hellstrom
wrote:
> It seems like prime_handle_from_fd needs to be paired with a GEM_CLOSE ioctl
> instead of a new generic HANDLE_CLOSE ioctl.
>
> This oversight is not really a big problem but there are two solutions:
> 1) Create a new ioctl called HANDLE_
On Fri, Nov 08, 2013 at 01:34:56PM +0100, Thierry Reding wrote:
> On Fri, Nov 08, 2013 at 01:08:03PM +0300, Dan Carpenter wrote:
> > I've shifted the __user markup to make Sparse happy.
> >
> > drivers/gpu/drm/tegra/drm.c:138:18: warning: incorrect type in initializer
> > (different address space
On Fri, Nov 8, 2013 at 4:01 PM, Tomasz Figa wrote:
> Hi Inki, Sean,
>
> On Thursday 07 of November 2013 14:48:28 Inki Dae wrote:
>> Hi Sean,
>>
>> When are you going to post your next version? Need more time? Other
>> DRM drivers have been merged to drm-next except Exynos. So plz hurry
>> up if y
From: Dave Airlie
Though I'm not really happy with how ugly this code is now.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 0b5c781..ba1f8
On 11/08/2013 02:32 PM, Matt Turner wrote:
> On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie wrote:
>> Since we seemed to have some confusion over this I'll state it clearly here.
>>
>> You should not merge kernel interface and ioctls to libdrm until they
>> have appeared in a git commit upstream wit
https://bugzilla.kernel.org/show_bug.cgi?id=63101
--- Comment #15 from Kertesz Laszlo ---
Created attachment 113871
--> https://bugzilla.kernel.org/attachment.cgi?id=113871&action=edit
dmesg, kernel next-20131108 until it froze
Tried the next-20131108 kernel.
Still crashes, but now
On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie wrote:
> Since we seemed to have some confusion over this I'll state it clearly here.
>
> You should not merge kernel interface and ioctls to libdrm until they
> have appeared in a git commit upstream with a stable id, this
> generally means drm-next, b
Hi Dave,
A few more patches for 3.13. The big one here is Hawaii support.
I wanted to get that out sooner, but was sick earlier this week. That
said, it's mostly self contained, so it shouldn't impact other asics.
The rest are just bug fixes and a merge fix.
The following changes since commit 9
x that I did earlier).
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/a9f00eaa/attachment-0001.pgp>
redit
people who've come up with the same patch at the same time.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives
18.10.2013 23:41, Alex Deucher kirjoitti:
> Needed by the hda driver to properly set up synchronization
> on the audio side.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 37
> drivers/gpu/drm/radeon/evergreend.h | 38
> ++
I've shifted the __user markup to make Sparse happy.
drivers/gpu/drm/tegra/drm.c:138:18: warning: incorrect type in initializer
(different address spaces)
drivers/gpu/drm/tegra/drm.c:138:18:expected struct drm_tegra_cmdbuf
[noderef] *cmdbufs
drivers/gpu/drm/tegra/drm.c:138:18:got void *[
copy_from_user() returns the number of bytes remaining if it fails, but
we want to return -EFAULT here.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 28e1781..fd3ff3b 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/
Hi Inki, Sean,
On Thursday 07 of November 2013 14:48:28 Inki Dae wrote:
> Hi Sean,
>
> When are you going to post your next version? Need more time? Other
> DRM drivers have been merged to drm-next except Exynos. So plz hurry
> up if you want to merge this re-factoring patch series during merge
op 07-11-13 22:11, Rom Lemarchand schreef:
> Hi Maarten, I tested your changes and needed the attached patch: behavior
> now seems equivalent as android sync. I haven't tested performance.
>
> The issue resolved by this patch happens when i_b < b->num_fences and i_a
>> = a->num_fences (or vice vers
op 07-11-13 22:11, Rom Lemarchand schreef:
> Hi Maarten, I tested your changes and needed the attached patch: behavior
> now seems equivalent as android sync. I haven't tested performance.
>
> The issue resolved by this patch happens when i_b < b->num_fences and
> i_a >= a->num_fences (or vice vers
On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
>
>> Weird. I wonder if there is an issue with cache snoops on PPC. We
>> currently use the gart in cached mode (GPU snoops CPU cache) with
>> cached pages. I wonder if we need to use u
Hi!
It seems like prime_handle_from_fd needs to be paired with a GEM_CLOSE
ioctl instead of a new generic HANDLE_CLOSE ioctl.
This oversight is not really a big problem but there are two solutions:
1) Create a new ioctl called HANDLE_CLOSE or something similar.
2) Use the GEM_CLOSE ioctl, but ad
Fix CONFIG_ACPI=n build fail
CC drivers/gpu/drm/i915/intel_opregion.o
drivers/gpu/drm/i915/intel_opregion.c: In function ?intel_opregion_setup?:
drivers/gpu/drm/i915/intel_opregion.c:879:2: error: ?asle_work? undeclared
(first use in this function)
drivers/gpu/drm/i915/intel_opregion.c:879
On 11/08/2013 09:06 AM, Daniel Vetter wrote:
> On Thu, Nov 07, 2013 at 11:18:54PM -0800, Thomas Hellstrom wrote:
>> In this context, a "doomed" object is an object whose refcount has reached
>> zero, but that has not yet been freed.
>>
>> To avoid mutual refcounting vmwgfx need to have a non-refcou
On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
> Weird. I wonder if there is an issue with cache snoops on PPC. We
> currently use the gart in cached mode (GPU snoops CPU cache) with
> cached pages. I wonder if we need to use uncached pages on PPC.
There is no such issue and no known b
On Thu, Nov 07, 2013 at 11:18:54PM -0800, Thomas Hellstrom wrote:
> In this context, a "doomed" object is an object whose refcount has reached
> zero, but that has not yet been freed.
>
> To avoid mutual refcounting vmwgfx need to have a non-refcounted pointer to
> a dma-buf in a lookup structure.
e or less time to lockup the card (1 - slowest, 4 fastest).
>> Secondly, if you write that the fix "should be incorporated in the
>> current code", i'm somewhat lost because it definitely isn't there.
> It's in the kernel now.
>
Wellno. I checked the 3.4.64 kernel sources after my last Mail
and the code isn't in the drivers/gpu/drm/radeon sources. But of course
i might have overlooked something.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/d68cf6ab/attachment-0001.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/0c8ec3c6/attachment-0001.html>
oblem.
Forget this, I'm getting tired and I didn't realized that we were already
making sure we were maxing the value if it was smaller.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/a2007217/attachment-0001.html>
droid side about renaming dma-fence to
> syncpoint, and getting it in mainline?
>
> ~Maarten
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/8245f7ee/attachment-0001.html>
encounter stability problem.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/ac2f14c0/attachment-0001.html>
g to your knowledge that could have more chance of hanging
when switching performance levels that would be less vulnerable with a fixed
mclk and vddci?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/23b48fa0/attachment-0001.html>
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131108/2bba9bdc/attachment.html>
44 matches
Mail list logo
