Hi folks !
I've been tracking down some problems with the recent DRI on powerpc and
stumbled upon something that doesn't look right, and not necessarily
only for us.
Now it's possible that I haven't fully understood the code here and I
also don't know to what extent some of that behaviour is nece
by classic drivers, not by Gallium based drivers.
--
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/20140904/b0688a88/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/4771900d/attachment.html>
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/20140904/c31d0ec0/attachment.html>
On Wed, 2014-09-03 at 21:55 -0400, Jerome Glisse wrote:
> So i think we need to get a platform flags and or set_pages_array_wc|uc
> needs to fail and this would fallback to cached mapping if the fallback
> code still works. So if your arch properly return and error for those
> cache changing functi
On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> So in the meantime the attached patch should work, it just silently ignore
> the caching attribute request on non x86 instead of pretending that things
> are setup as expected and then latter the radeon ou nouveau hw unsetting
> the snoop b
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/acfc07b2/attachment.html>
eceiving 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/20140904/9087eea1/attachment.html>
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/20140904/35f98310/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/ac947037/attachment.html>
On Wed, 2014-09-03 at 22:36 -0400, Jerome Glisse wrote:
> On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> > On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > >
> > > > So in the meantime the at
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/48c7a3bd/attachment-0001.html>
quiet, but Linuxs on hearing much more ...
--
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/20140904/288b4bf6/attachment.html>
org/archives/dri-devel/attachments/20140904/c18e48dd/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/8e713e5d/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/3166ef04/attachment.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/20140904/e38eaeb5/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/7712f774/attachment.html>
On Wed, Sep 03, 2014 at 10:36:57PM -0400, Jerome Glisse wrote:
> On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> > On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > >
> > > > So in the meantime
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/20140904/15ebdcc1/attachment.html>
On 04.09.2014 10:55, Jerome Glisse wrote:
>
> While i agree about the issue of incoherent double map of same page, i
> think we have more issue. For instance lattely AMD have been pushing a
> lot of patches to move things to use uncached memory for radeon and as
> usual thoses patches comes with no
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/2796e230/attachment.html>
On 04.09.2014 11:36, Jerome Glisse wrote:
> On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
>> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
>>> On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
>>>
So in the meantime the attached patch should wor
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/6e437c5b/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/1dc072fe/attachment.html>
If the PIO resources haven't been assigned, then we have no choice
but try to use the MMIO version. This is the case for example on
POWER8 which doesn't support PIO at all.
Chips rev 0x20 or later have MMIO decoding enabled by default.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/a
Hi!
Let me try to bring some clarity and suggestions into this.
On 09/04/2014 02:12 AM, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> I've been tracking down some problems with the recent DRI on powerpc and
> stumbled upon something that doesn't look right, and not necessarily
> only for us.
>
>
We need to do it on machines without a BIOS such as POWER8. Also
for detection to work without triggering PCIe errors, we need
to enable VGA early on, inside ast_detect_chip().
While touching those files, replace a few hard coded register
numbers with the corresponding symbolic constant.
Signed-o
It looks like the AST2400 comes up with the DVO enable bit set,
which causes us to incorrectly assume we have a SIL164 regardless
of the value of the scratch registers setup by the BMC firmware.
So let's limit that test to the case where the chip has already
been setup by a BIOS.
Signed-off-by: B
Move the MMIO mangling to a separate routine and actually
disable the DVO output when using pure analog.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_dp501.c | 49 ++---
1 file changed, 31 insertions(+), 18 deletions(-)
diff --git a/drive
From: J?r?me Glisse
People interested in providing uncached or write combined mapping
on there architecture need to do the ground work inside there arch
specific code to allow to break the linear kernel mapping so that
page mapping attributes can be updated, in the meantime force cached
mapping f
What the code does is equivalent to the x86 code, so let's use
it as well
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_vm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 24e045c..ed02563 100644
Today, most callers of ttm_io_prot() check TTM_PL_FLAG_CACHED before
calling it since on some archs it will unconditionally create non-cached
mappings.
But not all callers do which is incorrect as far as I can tell.
Instead, move that check inside ttm_io_port() itself for all archs
and make power
On all current cache coherent powerpc processors, it is not legit
to map system memory non-cachable. This will cause aliases with
the linear mapping which can be fatal.
The TTM should generally avoid it after Jerome placement patches but
let's add a sanity check anyway to catch any possible remain
We need to do it on machines without a BIOS such as POWER8. Also
for detection to work without triggering PCIe errors, we need
to enable VGA early on, inside ast_detect_chip().
While touching those files, replace a few hard coded register
numbers with the corresponding symbolic constant.
Signed-
If the P2A has been used to target other SOC registers before that
call, we're going to hit the wrong place so make sure we set the
base address up properly before using it.
(P2A stands for PCIe to AHB bridge and is the bride that allows
accessing the AST's internal AHB bus using a relocatable 64
It looks like the AST2400 comes up with the DVO enable bit set,
which causes us to incorrectly assume we have a SIL164 regardless
of the value of the scratch registers setup by the BMC firmware.
So let's limit that test to the case where the chip has already
been setup by a BIOS.
Signed-off-by:
On 04.09.2014 16:47, Benjamin Herrenschmidt wrote:
> On all current cache coherent powerpc processors, it is not legit
> to map system memory non-cachable. This will cause aliases with
> the linear mapping which can be fatal.
>
> The TTM should generally avoid it after Jerome placement patches but
On Thu, 2014-09-04 at 16:19 +0900, Michel D?nzer wrote:
> > +#else /* CONFIG_X86 */
> > +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
> *placement)
> > +{
> > + if (*placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
> > + ttm->caching_state = tt_cached;
> > +
On 04.09.2014 16:54, Benjamin Herrenschmidt wrote:
> On Thu, 2014-09-04 at 16:19 +0900, Michel D?nzer wrote:
>>> +#else /* CONFIG_X86 */
>>> +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
>> *placement)
>>> +{
>>> + if (*placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
>>> +
On 04.09.2014 16:59, Michel D?nzer wrote:
> On 04.09.2014 16:54, Benjamin Herrenschmidt wrote:
>> On Thu, 2014-09-04 at 16:19 +0900, Michel D?nzer wrote:
+#else /* CONFIG_X86 */
+int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
>>> *placement)
+{
+ if (*placemen
On 09/04/2014 09:46 AM, Benjamin Herrenschmidt wrote:
> From: J?r?me Glisse
>
> People interested in providing uncached or write combined mapping
> on there architecture need to do the ground work inside there arch
> specific code to allow to break the linear kernel mapping so that
> page mapping
On Thu, 2014-09-04 at 09:44 +0200, Thomas Hellstrom wrote:
> > This will, from what I can tell, try to use the same caching mode as the
> > original object:
> >
> > if ((cur_placement & caching) != 0)
> > result |= (cur_placement & caching);
> >
> > And cur_placement comes from bo-
On Thu, 2014-09-04 at 16:59 +0900, Michel D?nzer wrote:
>
> Define 'not reliably'. I have uptimes of weeks, and I'm pretty sure I'm
> not alone, at least with AGP 1x it seems to work quite well for most
> people. So I don't see the justification for intentionally breaking it
> completely for al
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/0fab0f7b/attachment.html>
On 09/04/2014 10:06 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-09-04 at 09:44 +0200, Thomas Hellstrom wrote:
>
>>> This will, from what I can tell, try to use the same caching mode as the
>>> original object:
>>>
>>> if ((cur_placement & caching) != 0)
>>> result |= (cur_place
--
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/20140904/419f7adb/attachment.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/20140904/ad2f8dc2/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/05f2d77a/attachment-0001.html>
have a look at it
again.
--
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/20140904/4e0d4e19/attachment.html>
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/20140904/3727bb5e/attachment.html>
On Thu, 2014-09-04 at 16:52 +0900, Michel D?nzer wrote:
> > #endif
> > +#if defined(__powerpc__) && !defined(CONFIG_NOT_COHERENT_CACHE)
> > + /*
> > + * Using a non-cachable mapping of system memory on
> > + * cache coherent powerpc's can be fatal, let's make
> > + * sure this
On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote:
> Last time I tested, (and it seems like Michel is on the same track),
> writing with the CPU to write-combined memory was substantially faster
> than writing to cached memory, with the additional side-effect that CPU
> caches are le
Hi Linus,
just i915 and vmwgfx fixes,
i915 contains a bunch of fixes for recent regressions in outputs,
vmwgfx fixes a possible loop for ever and a bad return code.
Dave.
The following changes since commit 59753a805499f1ffbca4ac0a24b3dff67bf1:
Merge tag 'backlight-fixes-3.17' of
git://
On Thu, 2014-09-04 at 11:34 +0200, Daniel Vetter wrote:
> On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote:
> > Last time I tested, (and it seems like Michel is on the same track),
> > writing with the CPU to write-combined memory was substantially faster
> > than writing to cached
On Thu, Sep 4, 2014 at 9:03 AM, Gupta, Sourab wrote:
> On Wed, 2014-09-03 at 13:09 +, Daniel Vetter wrote:
>> On Wed, Sep 03, 2014 at 11:49:52AM +, Gupta, Sourab wrote:
>> > On Wed, 2014-09-03 at 10:58 +, Daniel Vetter wrote:
>> > > On Wed, Sep 03, 2014 at 03:39:55PM +0530, sourab.gupt
On 04.09.2014 18:34, Benjamin Herrenschmidt wrote:
> On Thu, 2014-09-04 at 16:52 +0900, Michel D?nzer wrote:
>>>#endif
>>> +#if defined(__powerpc__) && !defined(CONFIG_NOT_COHERENT_CACHE)
>>> + /*
>>> + * Using a non-cachable mapping of system memory on
>>> + * cache coherent powe
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/41fa3826/attachment.html>
On 09/04/2014 11:43 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-09-04 at 11:34 +0200, Daniel Vetter wrote:
>> On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote:
>>> Last time I tested, (and it seems like Michel is on the same track),
>>> writing with the CPU to write-combined me
-devel/attachments/20140904/627f9d1b/attachment.html>
So this is finally it. After all the work writing support for fences cross-dev
synchronization is now possible. :-)
The last 2 patches of this series are not needed for cross-dev to work. But
without it any waits on cross-device fences will be done synchronously.
I've previously tested this with
Allows importing reservation_objects from a dma-buf.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_gem_cma_helper.c| 5 +++--
drivers/gpu/drm/drm_prime.c | 2 +-
drivers/gpu/drm/msm/msm_drv.h | 2 +-
drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++--
drivers/g
This allows importing reservation objects from dma-bufs.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ast/ast_ttm.c| 2 +-
drivers/gpu/drm/bochs/bochs_mm.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-
dr
Not the whole world is a radeon! :-)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon.h | 11 -
drivers/gpu/drm/radeon/radeon_cs.c | 32 +
drivers/gpu/drm/radeon/radeon_display.c | 41 -
drivers/gpu/dr
Adds an extra argument to radeon_bo_create, which is used in radeon_prime.c.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/cik.c | 4 ++--
drivers/gpu/drm/radeon/evergreen.c| 6 +++---
drivers/gpu/drm/radeon/r600.c | 4 ++--
drivers/gpu/drm/radeon/r
Adds an extra argument to nouveau_bo_new, which is used in nouveau_prime.c.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.h| 1 +
drivers/gpu/drm/nouveau/nouveau_chan.c
Use the semaphore mechanism to make this happen, this uses signaling
from the cpu instead of signaling by the gpu.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon.h | 17 ++-
drivers/gpu/drm/radeon/radeon_cs.c| 30 ++---
drivers/gpu/drm/radeon/radeon_fence.
This requires allocating a fence sooner to annotate any
cross-dev fences, and making sure that enough memory is
available before emitting the fence.
The current seqno is written to the GART bo on completion,
and a list of finished fences is kept to allow arbitrary depth.
Signed-off-by: Maarten La
Am 04.09.2014 um 13:40 schrieb Maarten Lankhorst:
> Not the whole world is a radeon! :-)
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/radeon/radeon.h | 11 -
> drivers/gpu/drm/radeon/radeon_cs.c | 32 +
> drivers/gpu/drm/radeon/radeo
Am 04.09.2014 um 13:42 schrieb Maarten Lankhorst:
> Use the semaphore mechanism to make this happen, this uses signaling
> from the cpu instead of signaling by the gpu.
I'm not sure if this will work reliable when the semaphores are in
system memory. We might need to reserve some VRAM for them in
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/acc1c2a6/attachment-0001.html>
Hey,
Op 04-09-14 om 13:54 schreef Christian K?nig:
> Am 04.09.2014 um 13:42 schrieb Maarten Lankhorst:
>> Use the semaphore mechanism to make this happen, this uses signaling
>> from the cpu instead of signaling by the gpu.
>
> I'm not sure if this will work reliable when the semaphores are in sys
+
> /* Reinitialize corresponding vblank timestamp if high-precision
> query
> * available. Skip this step if query unsupported or failed. Will
> * reinitialize delayed at next vblank interrupt in that case.
> --
> 1.8.5.5
>
>
------ n
Am 04.09.2014 um 14:08 schrieb Maarten Lankhorst:
> Hey,
>
> Op 04-09-14 om 13:54 schreef Christian K?nig:
>> Am 04.09.2014 um 13:42 schrieb Maarten Lankhorst:
>>> Use the semaphore mechanism to make this happen, this uses signaling
>>> from the cpu instead of signaling by the gpu.
>> I'm not sure
On Thu, Sep 04, 2014 at 11:52:15AM +, Gupta, Sourab wrote:
> On Thu, 2014-09-04 at 10:01 +, Daniel Vetter wrote:
> > Interface design discussions should happen in public (so that
> > non-intel people can jump in, which happens rather often for other
> > drivers actually). But at least inclu
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/ac463558/attachment.html>
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/20140904/01a410f7/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/1b7b6bbc/attachment-0001.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/ad047194/attachment.html>
> I need to check the docs how to do this correctly,
The docs don't really cover this case.
For the GPU waiting on an address there is an extra document just for
this case which I don't have at hand right now. But IIRC it was
recommended to use the local memory of the device waiting on the
sema
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/683ad5c6/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/ad0d226a/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/534b5783/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/17efa872/attachment.html>
Hey,
Op 04-09-14 om 15:34 schreef Christian K?nig:
>> I need to check the docs how to do this correctly,
> The docs don't really cover this case.
>
> For the GPU waiting on an address there is an extra document just for this
> case which I don't have at hand right now. But IIRC it was recommended
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140904/520bd07c/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140904/ddb19548/attachment.html>
Hi,
In si_program_display_gap we have DISP1_GAP and DISP2_GAP.
Where are DISP3_GAP to DISP6_GAP? What does expect this hardware
block when more than 2 displays are connected? Is DISP2_GAP
actually stand for DISP[3-6]_GAP?
Still in the same function, what happened to the pipes for
DCCG_DISP[2-6]_
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/46ca10bf/attachment.html>
On Thu, Sep 04, 2014 at 03:52:20PM +0200, Sylvain BERTRAND wrote:
> Hi,
>
> In si_program_display_gap we have DISP1_GAP and DISP2_GAP.
>
> Where are DISP3_GAP to DISP6_GAP? What does expect this hardware
> block when more than 2 displays are connected? Is DISP2_GAP
> actually stand for DISP[3-6]_
On Wed, Sep 03, 2014 at 05:10:17PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Due to the upcoming atomic modesetting feature we need to separate
> some update functions into a check step that can fail and a commit
> step that should, ideally, never fail.
>
> The commit part can st
On Wed, Sep 03, 2014 at 05:10:18PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> As a preparation for atomic updates we need to split the code to check
> everything we are going to commit first. This patch starts the work to
> split intel_primary_plane_setplane() into check() and comm
On Wed, Sep 03, 2014 at 05:10:16PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Due to the upcoming atomic modesetting feature we need to separate
> some update functions into a check step that can fail and a commit
> step that should, ideally, never fail.
>
> This commit splits int
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/8b653eac/attachment.html>
desktop.org/archives/dri-devel/attachments/20140904/832b91d8/attachment.html>
ve it a try.
--
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/20140904/4dc47054/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/e8552757/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/6a2dba55/attachment.html>
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/f9c3266a/attachment.html>
hives/dri-devel/attachments/20140904/b194d598/attachment.html>
1 - 100 of 126 matches
Mail list logo
