On Thu, Nov 14, 2013 at 05:40:36PM -0200, Rodrigo Vivi wrote:
> On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote:
> > On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi
> > wrote:
> > > On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote:
> > >> From: Duncan Laurie
> > >>
> >
u 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/20131115/85ee9947/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/c4dc6ccc/attachment.html>
hments/20131115/0b588b14/attachment.html>
ecause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/789855fa/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/36428b32/attachment.html>
Hi Linus,
This is a combo of -next and some -fixes that came in in the intervening time,
Highlights:
new drivers: ARM Armada driver for Marvell Armada 510 SOCs
Intel: Broadwell initial support under a default off switch,
Stereo/3D HDMI mode support
Valleyview improvements
D
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/20131115/fffee7a4/attachment.html>
llowing boot.
Then switch to 3.12-rc7 to send journal.
--
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/20131115/24945daa/attachment.html>
The commit "drm/ttm: make ttm reservation calls behave like reservation calls"
introduced a false lockdep warning on vmwgfx that hit on surface eviction,
due to a recursive reservation.
The fix silences the warning by using a tryreserve, which is not optimal, but
will do for now
If no reservation ticket is given to the execbuf reservation utilities,
try reservation with non-blocking semantics.
This is intended for eviction paths that use the execbuf reservation
utilities for convenience rather than for deadlock avoidance.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/
A lockdep warning is hit when evicting surfaces and reserving the backup
buffer. Since this buffer can only be reserved by the process holding the
surface reservation or by the buffer eviction processes that use tryreserve,
there is no real deadlock here, but there's no other way to silence lockdep
On Fre, 2013-11-15 at 08:49 +0100, Jochen Rollwagen wrote:
> I think there are two issues here: the first is the missing alignment
> workaround, since i'll be upgrading to 3.4.69 anyway i'll insert some
> diagnostic messages in radeon_device.c and see what happens.
Yes, please do that before spe
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/aa3bc2e9/attachment-0001.html>
vel/attachments/20131115/c1876690/attachment.html>
u 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/20131115/81675e4c/attachment.html>
On Fri, Nov 15, 2013 at 12:39:32AM +0100, Daniel Vetter wrote:
> On Thu, Nov 14, 2013 at 05:40:36PM -0200, Rodrigo Vivi wrote:
> > On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote:
> > > On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi
> > > wrote:
> > > > On Wed, Nov 13, 2013 at 05:59
On Fri, Nov 15, 2013 at 12:24:32AM -0800, Thomas Hellstrom wrote:
> A lockdep warning is hit when evicting surfaces and reserving the backup
> buffer. Since this buffer can only be reserved by the process holding the
> surface reservation or by the buffer eviction processes that use tryreserve,
> t
Hi Dave,
As promised bdw fixes come separate for now. Just a few minior things.
Cheers, Daniel
The following changes since commit ad40f83f5a89f6d723fd4db424b531f8dd7d3b49:
Merge branch 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux
into drm-next (2013-11-14 09:53:15 +1000)
are
On 11/15/2013 10:29 AM, Daniel Vetter wrote:
> On Fri, Nov 15, 2013 at 12:24:32AM -0800, Thomas Hellstrom wrote:
>> A lockdep warning is hit when evicting surfaces and reserving the backup
>> buffer. Since this buffer can only be reserved by the process holding the
>> surface reservation or by the
Forgot this one liner was necessary to fix module reload issues introduced
earlier in the pull
Thanks,
Dave.
The following changes since commit 0846c728e20a0cd1e43fb75a3015f3b176a26466:
Merge branch 'drm-nouveau-next' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (201
(so X fails and I get kicked back to
login screen) and check those logs.
--
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/20131115/
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/23fd6bc3/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/982c11d2/attachment.html>
Preparing for the future eDP panels.
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index a92c375..e2dbde6 100644
--- a/include/drm/drm_dp_he
Debug print the capabilities, and flag an error if the panel does not
support adjusting backlight through the BL_PWM_DIM pin, requiring
backlight control through DPCD.
I haven't seen such panels yet, but it's a matter of time. Give
ourselves a reminder when we need to fix this for real.
Signed-of
rtc_hdisplay;
> > + mode->hsync_len = in_mode->crtc_hsync_end -
> in_mode->crtc_hsync_start;
> > + mode->hbpd = (hblank - mode->hsync_len) / 2;
> > + mode->hfpd = hblank - mode->hsync_len - mode->hbpd;
> > +
> > + mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode);
>
> What about simply copying contents of in_mode to driver context
> and then calculating clkdiv at commit time? You could get rid
> of the fimd_mode_data struct and most of this function.
>
> Otherwise, the patch looks fine.
>
> Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/a0b458c8/attachment-0001.html>
Hi Sean, Tomasz,
On Mon, Nov 11, 2013 at 6:03 AM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 12:13:05 Sean Paul wrote:
>> This patch uses the mode passed into mode_set to configure fimd instead
>> of directly using the panel from context. This will allow us to move
>> the exy
ng 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/20131115/99de5c9c/attachment.html>
||
--
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/20131115/24b8ba83/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=31682
J?r?me Glisse changed:
What|Removed |Added
CC||glisse at freedesktop.org
--- Comment #6
https://bugzilla.kernel.org/show_bug.cgi?id=31682
--- Comment #7 from Alan ---
You only need to use the GART trick if you might not have enough memory to
allocate twice the memory needed for the framebuffer. If you can afford the
memory then allocate two copies and write each text blit into both.
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/990e162f/attachment.html>
From: Michel D?nzer
Signed-off-by: Marek Ol??k
---
radeon/radeon_surface.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index d5c45c4..56e2e4a 100644
--- a/radeon/radeon_surface.c
+++ b/radeon
From: Michel D?nzer
Bug fixes and simplification by Marek.
We have to use the tile index of 0 for non-MSAA depth-stencil after all.
Signed-off-by: Marek Ol??k
---
include/drm/radeon_drm.h | 11 +
radeon/radeon_surface.c | 620 ++-
radeon/radeon_sur
ttachments/20131115/ce28110e/attachment-0001.html>
||
--
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/20131115/8a913c19/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/6d9d62e8/attachment.html>
|--- |WONTFIX
--
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/20131115/c5b182e6/attachment.html>
From: Ian Romanick
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kernel work.
v3: Fix compile failures
On Fri, 2013-11-15 at 10:38 +0530, Shirish S wrote:
> The current solution checks for the existing RB mode,
> if available in the edid block returns by adding it,
> but does not populate the connector with the modes
> of same resolution but which are non-rb modes.
>
> As a result the probing and l
On Fri, Nov 15, 2013 at 12:55 PM, Marek Ol??k wrote:
> From: Michel D?nzer
>
> Bug fixes and simplification by Marek.
> We have to use the tile index of 0 for non-MSAA depth-stencil after all.
>
> Signed-off-by: Marek Ol??k
> ---
> include/drm/radeon_drm.h | 11 +
> radeon/radeon_surface.c |
On Fri, Nov 15, 2013 at 10:41:57AM -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> I would have just used the drmIoctl interface directly in Mesa, but the
> ioctl needs some data from the drm_intel_context that is not exposed
> outside libdrm.
>
> This ioctl is in the drm-intel-next tree as
d8
After update to the latest git version everything returned to normal. Thanks.
--
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/20131115/0b94b7f5/attachment.html>
|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/b1b9d376/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/67232265/attachment.html>
From: Stephen Warren
Tegra's clock driver now provides an implementation of the common
reset API (include/linux/reset.h). Use this instead of the old Tegra-
specific API; that will soon be removed.
Cc: treding at nvidia.com
Cc: pdeschrijver at nvidia.com
Cc: linux-tegra at vger.kernel.org
Cc: li
From: Stephen Warren
Tegra's clock driver now provides an implementation of the common
reset API (include/linux/reset.h). Use this instead of the old Tegra-
specific API; that will soon be removed.
Cc: treding at nvidia.com
Cc: pdeschrijver at nvidia.com
Cc: linux-tegra at vger.kernel.org
Cc: li
Hi Dave,
Some fixes for radeon for 3.13. Mostly CI stability fixes. I think
I've tracked down the stability problems with dpm on Trinity/Richland,
so I'm going to enable that by default now.
The following changes since commit a3483353ca4e6dbeef2ed62ebed01af109b5b27a:
drm: check for !kdev
On Fri, Nov 15, 2013 at 1:54 PM, Stephen Warren
wrote:
> From: Stephen Warren
>
> Tegra's clock driver now provides an implementation of the common
> reset API (include/linux/reset.h). Use this instead of the old Tegra-
> specific API; that will soon be removed.
>
> Cc: treding at nvidia.com
> C
On Tue, Oct 29, 2013 at 08:12:32AM +, Shirish S wrote:
> This patch adds dt support to hdmiphy config settings
> as it is board specific and depends on the signal pattern
> of board.
>
> Signed-off-by: Shirish S
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt | 34 +
> d
From: Stephen Warren
This series implements a common reset framework driver for Tegra, and
updates all relevant Tegra drivers to use it. It also removes the custom
DMA bindings and replaced them with the standard DMA DT bindings.
Historically, the Tegra clock driver has exported a custom API for
With the current implementation of collecting edid modes,
in case rb mode exists for a non rb mode of same resolution and
vrefresh, the non-rb mode is never fed to display controller to be
probed, as a result we lose on using the non-rb mode, if the display
controller does not support rb mode but
/git/linux/drivers/gpu/drm/nouveau/core/subdev/mc/base.c: In function
'nouveau_mc_intr':
/git/linux/drivers/gpu/drm/nouveau/core/subdev/mc/base.c:43:25: warning: unused
variable 'device' [-Wunused-variable]
Signed-off-by: Wanlong Gao
---
drivers/gpu/drm/nouveau/core/subdev/mc/base.c | 1 -
1 f
The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.
As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixe
Some system's ACPI video backlight control interface is broken and the
native backlight control interface should be used by default. This patch
sets the use_native_backlight parameter to true for those systems so
that video backlight control interface will not be created. To be
specific, the ThinkP
I think there are two issues here: the first is the missing alignment
workaround, since i'll be upgrading to 3.4.69 anyway i'll insert some
diagnostic messages in radeon_device.c and see what happens. But i'm
pretty certain now that this isn't the cause for the lockups. They are
probably (quite
The comment suggests that intention was to limit 16M cards to save memory while
code did something a bit different.
32bpp is a lot more useful with today's apps, such as Weston's fbdev backend
and 32M cards are probably hardly used in apps where dedicating a bit more to
pinned console would matter
Hi,
On 09/19/2013 11:41 PM, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King
> ---
> arch/powerpc/kernel/vio.c |
Building with the attached random configuration file,
drivers/gpu/drm/nouveau/nouveau_hwmon.c: In function ?nouveau_hwmon_init?:
drivers/gpu/drm/nouveau/nouveau_hwmon.c:633:2: error: ?hwmon? undeclared (first
use in this function)
hwmon->hwmon = NULL;
^
drivers/gpu/drm/nouveau/nouveau_hwmon.c:
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/20131115/729c690d/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=64781
--- Comment #4 from Giannis ---
Can I do something else to help?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=64781
Raymond changed:
What|Removed |Added
CC||superquad.vortex2 at gmail.com
--- Comment #5 f
https://bugzilla.kernel.org/show_bug.cgi?id=64781
--- Comment #6 from Giannis ---
and why before 3.10-RC1 kernel, audio was fine?
--
You are receiving this mail because:
You are watching the assignee of the bug.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new version of libdrm has been released. The main motivation for this
release is the addition of the reset status query ioctl for the Intel
kernel module. Access to this ioctl will be necessary for Mesa 10.0.
Alex Deucher (2):
radeon: add haw
65 matches
Mail list logo
