ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140113/6371684f/attachment.html>
fore further testing.
--
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/20140113/b30c2347/attachment.html>
9 vddc: 1000 vddci: 1000
--
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/20140113/d3625bc9/attachment-0001.html>
ceiving 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/20140113/649f9636/attachment.html>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/dd0dbd59/attachment.html>
I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8
git. Maybe it's obvious.
Sorry about that.
Bob
Forwarded Message
From: Bob Gleitsmann
To: bskeggs at redhat.com
Cc: nouveau at lists.freedesktop.org, dri-devel at lists.freedesktop.org
Subject: [PATCH] Fix
We are seeking nominations for candidates for election to the X.Org
Foundation Board of Directors. All X.Org Foundation members are
eligible for election to the board.
Nominations for the 2014 election are now open and will remain open
until 23.59 GMT on 12 February 2013.
The Board consists of d
https://bugzilla.kernel.org/show_bug.cgi?id=68301
--- Comment #3 from Niels Ole Salscheider
---
> Make sure your kernel has this patch:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=f244d8b623dae7a7bc695b0336f67729b95a9736
My kernel has this patch but it does no
https://bugzilla.kernel.org/show_bug.cgi?id=60639
--- Comment #17 from Alex Deucher ---
Created attachment 121911
--> https://bugzilla.kernel.org/attachment.cgi?id=121911&action=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are watching the assignee of t
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/9c59db71/attachment-0001.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/306a5eda/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/761b9d08/attachment.html>
know.
--
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/20140113/d4746459/attachment.html>
debug flag, and run the application through the new version
of Mesa.
--
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/20140
https://bugzilla.kernel.org/show_bug.cgi?id=68301
--- Comment #2 from Alex Deucher ---
Do graphics work ok for you with runpm=1? I.e., is it just compute that's
causing a problem?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=68301
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/78ab2780/attachment-0001.html>
output?
--
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/20140113/cf5074ff/attachment.html>
ogs for you on my RV730 AGP (1 GB) with Celestia, Blender,
FreeCAD,...
--
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/20140113/7da9ed61/attachment.html>
On Mon, 13 Jan 2014 16:35:01 +
Russell King - ARM Linux wrote:
> Ah, I see. It's a thread about your DRM driver, and about the lack of
> audio on 1080 resolutions. Taking it in context, the reported issue
> appears to be lack of video when 1080p is selected, but the display
> doesn't suppor
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/84217346/attachment.html>
On Mon, Jan 13, 2014 at 06:24:55PM +0100, Jean-Francois Moine wrote:
> On Mon, 13 Jan 2014 16:35:01 +
> Russell King - ARM Linux wrote:
>
> > Ah, I see. It's a thread about your DRM driver, and about the lack of
> > audio on 1080 resolutions. Taking it in context, the reported issue
> > app
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #9 from Alex Deucher ---
(In reply to kilobug from comment #4)
> Sorry, but it seems even worse : I get the "lockup" as often, but it doesn't
> recover from it anymore. Either the system fully freeze after a lockup (with
> garbage on t
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/44f2a4ef/attachment.html>
ill
see the error from comment 3.
I need a test case in order to commit this patch. Could you post the output of
R600_DEBUG=cs from an unmodified kernel *without* this patch applied.
--
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/20140113/86e10962/attachment.html>
On Mon, 13 Jan 2014 16:13:34 +
Russell King - ARM Linux wrote:
> Sorry, I don't see what bearing your response to my reply has.
Simply that NXP people better like to use the cea mode.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinej
his 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/20140113/ab97db60/attachment.html>
On Sat, 11 Jan 2014 18:18:32 +
Russell King - ARM Linux wrote:
> On Thu, Jan 09, 2014 at 12:04:48PM +0100, Jean-Francois Moine wrote:
> > This patch uses the tda998x video format tied to the CEA mode.
> > This reduces the number of i2c exchanges.
>
> It is my understanding that one of the ma
On Sat, 11 Jan 2014 18:26:02 +
Russell King - ARM Linux wrote:
> > div = 148500 / mode->clock;
> > + if (div != 0) {
> > + div--;
> > + if (div > 3)
> > + div = 3;
> > + }
>
> As the driver currently stands, we know that the clock divider works
On Mon, Jan 13, 2014 at 05:22:20PM +0100, Jean-Francois Moine wrote:
> On Mon, 13 Jan 2014 16:13:34 +
> Russell King - ARM Linux wrote:
>
> > Sorry, I don't see what bearing your response to my reply has.
>
> Simply that NXP people better like to use the cea mode.
Ah, I see. It's a thread
On Mon, 13 Jan 2014, Thierry Reding wrote:
> The intel_encoder_crtc_ok() is a duplicate of the drm_encoder_crtc_ok()
> function that used to be only available in the DRM CRTC helpers. It has
> recently been moved to the core, so the duplicate can now be dropped.
>
> Acked-by: Daniel Vetter
> Sign
On Mon, Jan 13, 2014 at 05:07:07PM +0100, Jean-Francois Moine wrote:
> On Sat, 11 Jan 2014 18:18:32 +
> Russell King - ARM Linux wrote:
>
> > On Thu, Jan 09, 2014 at 12:04:48PM +0100, Jean-Francois Moine wrote:
> > > This patch uses the tda998x video format tied to the CEA mode.
> > > This re
The head number of a given display controller is fixed in hardware and
required to program outputs appropriately. Relying on the driver probe
order to determine this number will not work, since that could yield a
situation where the second head was probed first and would be assigned
head number 0 i
The mask of possible CRTCs that an output (DRM encoder) can be attached
to is relative to the position within the DRM device's list of CRTCs.
Deferred probing can cause this to not match the pipe number associated
with a CRTC. Use the newly introduced drm_crtc_mask() to compute the
mask by looking
The Tegra DRM driver assumes that CRTCs are probed in the order listed
in the DT. While DT makes no such guarantees in the first place, this
used to work fine. With the introduction of the panel support, however,
more often than not one of the CRTCs will defer probing (caused by the
panel not havin
On Mon, 13 Jan 2014, Thierry Reding wrote:
> From: Russell King
>
> The encoder possible_crtcs mask identifies which CRTCs can be bound to
> a particular encoder. Each bit from bit 0 defines an index in the list
> of CRTCs held in the DRM mode_config crtc_list. Rather than having
> drivers tryi
The intel_encoder_crtc_ok() is a duplicate of the drm_encoder_crtc_ok()
function that used to be only available in the DRM CRTC helpers. It has
recently been moved to the core, so the duplicate can now be dropped.
Acked-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
Changes in v3:
- replace
Using the new drm_crtc_mask() function, drm_encoder_crtc_ok() can now be
written in a significantly shorter way, so it can be moved to a header
file and be made static inline.
Signed-off-by: Thierry Reding
---
Changes in v3:
- new patch
drivers/gpu/drm/drm_crtc_helper.c | 13 -
incl
From: Russell King
The encoder possible_crtcs mask identifies which CRTCs can be bound to
a particular encoder. Each bit from bit 0 defines an index in the list
of CRTCs held in the DRM mode_config crtc_list. Rather than having
drivers trying to track the position of their CRTCs in the list, ex
This series is a continuation of a patch posted earlier by Russell. It
addresses some comments from the initial posting as well as from some
discussion on IRC.
Patch 2 moves the drm_encoder_crtc_ok() function from the CRTC helpers
into the core so that patch 3 can reuse it to get rid of the duplic
Hi
On Mon, Jan 13, 2014 at 2:55 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 13, 2014 at 02:50:46PM +0100, David Herrmann wrote:
>> Hi Russel
>>
>> On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
>> wrote:
>> > On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
>> >>
Hi Russel
On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
>> Does that -1 ever make sense? We don't support mode-object-hotplugging
>> so all "drm_crtc" objects are known at initialization time. I'd rather
>> put a
On Mon, Jan 13, 2014 at 1:59 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 13, 2014 at 01:56:27PM -0500, Rob Clark wrote:
>>
>> dropping this #include is already in my 3.14-rc1 pull req..
>>
>> do we need this in 3.13 too?
>
> That depends how it's ending up in my build tree of Linus' tip, plu
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/26056d00/attachment.html>
On Mon, Jan 13, 2014 at 02:50:46PM +0100, David Herrmann wrote:
> Hi Russel
>
> On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
> >> Does that -1 ever make sense? We don't support mode-object-hotplugging
> >> s
Thanks to Fengguang Wu for spotting a missing static cast.
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-buf.c | 102 +++
include/linux/dma-buf.h | 12 ++
2 files changed, 114 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers
Signed-off-by: Maarten Lankhorst
---
include/linux/reservation.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..92c4851b5a39 100644
--- a/include/linux/reservation.h
+++ b/inclu
Android syncpoints can be mapped to a timeline. This removes the need
to maintain a separate api for synchronization. I've left the android
trace events in place, but the core fence events should already be
sufficient for debugging.
v2:
- Call fence_remove_callback in sync_fence_free if not all fe
This allows reservation objects to be used in dma-buf. it's required
for implementing polling support on the fences that belong to a dma-buf.
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-buf.c | 22 --
drivers/gpu/drm/drm_prime.c
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. T
The kernel fence implementation doesn't use event queues, but needs
to perform the same wake up. The symbol is not exported, since the
fence implementation is not built as a module.
Signed-off-by: Maarten Lankhorst
---
include/linux/wait.h |1 +
kernel/sched/core.c |2 +-
2 files change
The following series implements fence and converts dma-buf and
android sync to use it. Patch 6 and 7 add support for polling
to dma-buf, blocking until all fences are signaled.
---
Maarten Lankhorst (7):
sched: allow try_to_wake_up to be used internally outside of core.c
fence: dma-bu
Hi
On Mon, Jan 13, 2014 at 12:46 PM, Thierry Reding
wrote:
> From: Russell King
>
> The encoder possible_crtcs mask identifies which CRTCs can be bound to
> a particular encoder. Each bit from bit 0 defines an index in the list
> of CRTCs held in the DRM mode_config crtc_list. Rather than havi
.
--
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/20140113/77eb2db0/attachment.html>
On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
> Does that -1 ever make sense? We don't support mode-object-hotplugging
> so all "drm_crtc" objects are known at initialization time. I'd rather
> put a BUG() here than a silent -1. This also makes drm_crtc_mask()
> redundant.
I disa
Replace an open-coded occurrence by a call to the new drm_crtc_mask()
helper.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/i915/intel_display.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/i
From: Russell King
The encoder possible_crtcs mask identifies which CRTCs can be bound to
a particular encoder. Each bit from bit 0 defines an index in the list
of CRTCs held in the DRM mode_config crtc_list. Rather than having
drivers trying to track the position of their CRTCs in the list, ex
This series is a continuation of a patch posted earlier by Russell. It
addresses some comments from the initial posting as well as from some
discussion on IRC.
Patch 2 makes use of the new functions to replace an open-coded version
in the i915 driver, as suggested by David Herrmann. I've left Davi
Dave,
First 3.14 pull request for vmwgfx,
I hope to be able squeeze in one more with a huge device update,
but lets see what happens.
Anyway, nothing big here, Three more code cleanup patches from Rashika
Kheria, and one TTM/vmwgfx patch from me that tightens security around TTM
objects enough f
Dave,
Some code cleanup by Rashika Keria,
VM stuff for ttm:
-Use PFNMAP instead of MIXEDMAP where possible for performance
-Refuse to fault imported pages, an initial step to support dma-bufs
better from within TTM.
-Correctly set page mapping and -index members. These are needed in various
places
On Mon, Jan 13, 2014 at 4:31 AM, Maarten Lankhorst
wrote:
> The kernel fence implementation doesn't use event queues, but needs
> to perform the same wake up. The symbol is not exported, since the
> fence implementation is not built as a module.
>
> Signed-off-by: Maarten Lankhorst
> ---
> inclu
On 01/13/2014 07:21 AM, Thierry Reding wrote:
> The head number of a given display controller is fixed in hardware and
> required to program outputs appropriately. Relying on the driver probe
> order to determine this number will not work, since that could yield a
> situation where the second head
t; tegra_dc *dc)
> - rgb->output.encoder.possible_crtcs = 1 << dc->pipe;
> + rgb->output.encoder.possible_crtcs = drm_crtc_mask(&dc->base);
For me, on top of either next-20140109 or next-20140113, this causes:
> drivers/gpu/drm/tegra/rgb.c: In function ?tegra_dc_rgb
On Sat, 11 Jan 2014 18:51:14 +
Russell King - ARM Linux wrote:
> On Thu, Jan 09, 2014 at 12:06:39PM +0100, Jean-Francois Moine wrote:
> > This patch adds the active aspect as 'picture' in the HDMI AVI frame
> > and also some comments about this frame.
>
> Yes, this should've been set. It's
c: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/dcd5222e/attachment-0001.pgp>
le at it, perhaps the drmMsg() and drmDebugPrint() functions should
be similarily annotated as well?
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/20140113/8e4e1d5c/attachment.pgp>
Reviewed-by: Ian Romanick
On 01/12/2014 10:34 AM, Keith Packard wrote:
> the drmServerInfo member, debug_print, takes a printf format string
> and varargs list. Tell the compiler about it.
>
> Signed-off-by: Keith Packard
> ---
> xf86drm.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 del
Am Samstag, den 11.01.2014, 11:23 +0800 schrieb Shawn Guo:
> On Fri, Jan 10, 2014 at 03:22:24PM +0100, Philipp Zabel wrote:
> > Due to the voltage divider on the HPD line, the HDMI connector on
> > imx6q-sabrelite doesn't reliably detect connected DVI monitors.
> > This patch allows to use the RX_S
Am Samstag, den 11.01.2014, 11:40 + schrieb Russell King - ARM
Linux:
> On Sat, Jan 11, 2014 at 12:31:19PM +0100, Robert Schwebel wrote:
> > On Fri, Jan 10, 2014 at 11:23:37PM +, Russell King - ARM Linux wrote:
> > > We do this in DT by providing a "superdevice" node which specifies
> > > t
On Sat, Jan 11, 2014 at 4:23 PM, Paul Menzel
wrote:
> Dear Linux developers,
>
>
> as reported in the channel #radeon on , I am not able
> to dump the Video BIOS on my Asus U38N-C4010H with AMD Radeon HD 7600G
> (Trinity A8-4555M).
>
> I am using Debian Sid/unstable with Linux version 3.12-1-amd64
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/c7aa201e/attachment.html>
Hi Dave,
Black screen fixes, one for hsw+bdw each and a regression fix for
locking+load detection.
Cheers, Daniel
The following changes since commit 47f956477dc6173f8882e8ea0fa9e8edb8a7d942:
MAINTAINERS: Updates for drm/i915 (2014-01-07 09:33:16 +0100)
are available in the git repository at
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/66c09c40/attachment-0001.html>
On Sun, Jan 12, 2014 at 02:08:43PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> Signed-off-by: Geert Uytterhoeven
Queued for -next, thanks for the patch.
-Daniel
> ---
> include/uapi/drm/i915_drm.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/i
be
a great idea!
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/6d7caf33/attachment.pgp>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/90cb94dc/attachment.html>
The problem affects nv40 cards during booting. It comes from there being
two places where subdev arrays are maintained. A commit was recently
added to make the two equal. However, the struct nouveau_device version
ends up being referenced before it is initialized. The problem arises
during the crea
On 29/10/13 19:06, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> i915 doesn't need this kludge for most platforms. Although we do
> appear to need something similar on certain platforms, but we can
> be more accurate when we apply the adjustment since we know exactly
> why the
nature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/4d659310/attachment-0001.pgp>
On 29/10/13 19:06, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> Preparation for moving the early vblank IRQ logic into
> radeon_get_crtc_scanoutpos().
>
> Signed-off-by: Ville Syrj?l?
Tiny compile fix needed for this one. The function prototype for
radeon_get_crtc_scanoutpo
On 29/10/13 19:06, ville.syrjala at linux.intel.com wrote:
> So I took another look at the vblank timestamping code, and got a bit
> excited. The result is this patchset.
>
> Summary of changes:
> - kill crtc->hwmode dependency
> - eliminate a bunch of 64bit math
> - fix timestamps for stere
tarting the X server by restarting GDM with `sudo service gdm3
restart`.
--
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/2014011
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/97326e6c/attachment.html>
.
*** This bug has been marked as a duplicate of bug 73530 ***
--
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/20140113/df05d
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/00bfcf33/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/bcfdba00/attachment-0001.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140113/42cbff7e/attachment.html>
88 matches
Mail list logo
