Hello Alex and Christian,
RV730 (AGP) need badly
From b6c2b4faf90230ef9cf1a81f36cbccda4a606c59 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 8 Sep 2014 13:16:39 -0400
Subject: [PATCH] drm/radeon: only use me/pfp sync on evergreen+
The packet seems to cause hangs on some 7xx asics.
b
Am 12.09.2014 00:14, schrieb Alex Deucher:
> On Thu, Sep 11, 2014 at 6:12 PM, Dieter N?tzel
> wrote:
>> Hello Alex and Christian,
>>
>> RV730 (AGP) need badly
>>
>> From b6c2b4faf90230ef9cf1a81f36cbccda4a606c59 Mon Sep 17 00:00:00 2001
>> From: Alex Deucher
>> Date: Mon, 8 Sep 2014 13:16:39 -0
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/7efd5178/attachment.html>
ions work).
--
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/20140912/32964a6d/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140912/b38c2fdc/attachment.html>
On 10 September 2014 19:29, Jean-Francois Moine wrote:
> This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.
>
> The CODEC handles both I2S and S/PDIF inputs.
> It maintains the audio format and rate constraints according
> to the HDMI device parameters (EDID) and does dynamic in
Hi Linus,
ast, i915, radeon and msm fixes, all over the place, all fixing build
issues, regressions, oopses or failure to detect cards.
Dave.
The following changes since commit 7ec62d421bdf29cb31101ae2689f7f3a9906289a:
Merge branch 'for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/g
On Thu, Sep 11, 2014 at 05:59:40PM +0100, Lionel Landwerlin wrote:
> When using Mesa and LibVA in the same process, one would like to be
> able bind buffers from the output of the decoder to a GL texture
> through an EGLImage.
>
> LibVA can reuse buffers allocated by Gbm through a file descriptor.
From: Johannes Berg
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through
On Thu, 11 Sep 2014, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> 7e4bf45dbd99a965c7b5d5944c6dc4246f171eb5 introduced the regression.
> We fix it by doing the right assignment of crtc_y
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83747
> Signed-off-by: Gustavo Padovan
Thank
Hi Dave,
So updated vblank-rework pull request, now with the polish that Mario
requested applied (and reviewed by him). Also with backmerge like you've
requested for easier merging.
The neat thing this finally allows is to immediately disable the vblank
interrupt on the last drm_vblank_put if the
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/cdcf3e55/attachment.html>
On Fri, Sep 12, 2014 at 10:12:37AM +0300, Jani Nikula wrote:
> On Thu, 11 Sep 2014, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > 7e4bf45dbd99a965c7b5d5944c6dc4246f171eb5 introduced the regression.
> > We fix it by doing the right assignment of crtc_y
> >
> > Bugzilla: https://bugs.fre
Hi
On Thu, Sep 11, 2014 at 10:53 PM, Kees Cook wrote:
> While zone->name is currently hard coded, the call to kobject_init_and_add()
> should follow the more defensive argument list usage (as already done in
> other places in ttm_memory.c) where "%s" is used instead of directly passing
> in a var
Hi Andrzej,
On 2014? 09? 09? 22:16, Andrzej Hajda wrote:
> Adding reference to framebuffer should be accompanied with removing
> reference to old framebuffer assigned to the plane.
> This patch removes following warning:
>
> [ 95.038017] WARNING: CPU: 1 PID: 3067 at drivers/gpu/drm/drm_crtc.c:5
On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
> Hi Andrzej,
>
> On 2014? 09? 09? 22:16, Andrzej Hajda wrote:
> > Adding reference to framebuffer should be accompanied with removing
> > reference to old framebuffer assigned to the plane.
> > This patch removes following warning:
> >
>
On 2014? 09? 12? 17:57, Daniel Vetter wrote:
> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
>> Hi Andrzej,
>>
>> On 2014? 09? 09? 22:16, Andrzej Hajda wrote:
>>> Adding reference to framebuffer should be accompanied with removing
>>> reference to old framebuffer assigned to the plane.
On 09/12/2014 10:57 AM, Daniel Vetter wrote:
> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
>> Hi Andrzej,
>>
>> On 2014? 09? 09? 22:16, Andrzej Hajda wrote:
>>> Adding reference to framebuffer should be accompanied with removing
>>> reference to old framebuffer assigned to the plane.
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/c96f585a/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=73841
Jani Nikula changed:
What|Removed |Added
Status|NEEDINFO|ASSIGNED
Component|Video(DRI - Int
Hopefully I got this right this time :)
-
Lionel
When using Mesa and LibVA in the same process, one would like to be
able bind buffers from the output of the decoder to a GL texture
through an EGLImage.
LibVA can reuse buffers allocated by Gbm through a file descriptor. It
will then wrap it into a drm_intel_bo with
drm_intel_bo_gem_create_from_p
https://bugzilla.kernel.org/show_bug.cgi?id=73841
Christian K?nig changed:
What|Removed |Added
CC||deathsimple at vodafone.de
--- Comment
On Fri, Sep 12, 2014 at 11:27:07AM +0100, Lionel Landwerlin wrote:
> When using Mesa and LibVA in the same process, one would like to be
> able bind buffers from the output of the decoder to a GL texture
> through an EGLImage.
>
> LibVA can reuse buffers allocated by Gbm through a file descriptor.
On 2014? 09? 12? 18:27, Andrzej Hajda wrote:
> On 09/12/2014 10:57 AM, Daniel Vetter wrote:
>> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
>>> Hi Andrzej,
>>>
>>> On 2014? 09? 09? 22:16, Andrzej Hajda wrote:
Adding reference to framebuffer should be accompanied with removing
On 09/12/2014 12:45 PM, Inki Dae wrote:
> On 2014? 09? 12? 18:27, Andrzej Hajda wrote:
>> On 09/12/2014 10:57 AM, Daniel Vetter wrote:
>>> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
Hi Andrzej,
On 2014? 09? 09? 22:16, Andrzej Hajda wrote:
> Adding reference to fram
https://bugzilla.kernel.org/show_bug.cgi?id=73841
Jani Nikula changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 2014? 09? 12? 20:04, Andrzej Hajda wrote:
> On 09/12/2014 12:45 PM, Inki Dae wrote:
>> On 2014? 09? 12? 18:27, Andrzej Hajda wrote:
>>> On 09/12/2014 10:57 AM, Daniel Vetter wrote:
On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
> Hi Andrzej,
>
> On 2014? 09? 09? 22:16
Bjorn,
What is missing to get these two patches pushed to Linus?
Bruno
On Thu, 28 Aug 2014 22:47:50 +0200 Bruno Pr?mont wrote:
> On Tue, 26 August 2014 Andreas Noever wrote:
> > On Sun, Aug 24, 2014 at 11:09 PM, Bruno Pr?mont wrote:
> > > With commit 20cde694027e boot video device detection wa
From: Christian K?nig
The PD/PTs reservation object now contains everything needed.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_vm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index b53576e.
From: Christian K?nig
That's useless when all callers drop the reservation
immediately after calling the function.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_kms.c | 2 --
drivers/gpu/drm/radeon/radeon_vm.c | 4 ++--
3 files ch
Similar to the already pushed patches for allowing concurrent buffers use from
different engines this set of patches allows concurrent VM use from different
engines at the same time.
Please review and comment,
Christian.
From: Christian K?nig
Use ring structure instead of index and provide vm_id and pd_addr separately.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/cik.c | 23 ++-
drivers/gpu/drm/radeon/cik_sdma.c| 22 +-
drivers/gpu/drm/radeon/ni.
From: Christian K?nig
This allows us to add the real execution fence as shared.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.c | 19 ++
drivers/gpu/drm/radeon/radeon_object.h | 2 ++
drivers/gpu/drm/radeon/radeon_vm.c | 65 +--
From: Christian K?nig
This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 60 +
1 file changed, 60 insertions(+)
diff --git a/d
From: Christian K?nig
Previously we just allocated space for four hardware semaphores
in each software semaphore object. Make software semaphore objects
represent only one hardware semaphore address again by splitting
the sync code into it's own object.
Signed-off-by: Christian K?nig
---
drive
From: Christian K?nig
Note for each fence if it's a VM page table update or not. This allows
us to determine the last VM update in a sync object and so to figure
out if we need to flush the TLB or not.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 18 ++
From: Christian K?nig
Use multiple VMIDs for each VM, one for each ring. That allows
us to execute flushes separately on each ring, still not ideal
cause in a lot of cases rings can share IDs.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/cik.c | 4 +--
drivers/gpu/drm/radeo
From: Christian K?nig
This allows us to finally remove the VM fence and
so allow concurrent use of it from different engines.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 7 +++
drivers/gpu/drm/radeon/radeon_cs.c | 5 -
drivers/gpu/drm/radeon/radeon_vm.c |
From: Christian K?nig
We never invalidate PD entries and making them valid can
run with other users in parallel.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drive
From: Christian K?nig
Only invalidating PTEs needs to be executed synchronized to using the PT.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_vm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/rade
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/d59dea2c/attachment.html>
eon driver loaded? Can you bisect the kernel
to determine what commit broke your card?
--
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/attachm
Signed-off-by: Lionel Landwerlin
---
xf86atomic.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/xf86atomic.h b/xf86atomic.h
index db2f619..bc482c9 100644
--- a/xf86atomic.h
+++ b/xf86atomic.h
@@ -96,4 +96,13 @@ typedef struct { uint_t atomic; } atomic_t;
#error libdrm requires ato
When using Mesa and LibVA in the same process, one would like to be
able bind buffers from the output of the decoder to a GL texture
through an EGLImage.
LibVA can reuse buffers allocated by Gbm through a file descriptor. It
will then wrap it into a drm_intel_bo with
drm_intel_bo_gem_create_from_p
Signed-off-by: Lionel Landwerlin
---
intel/intel_bufmgr_gem.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 1e2dd77..bf6745d 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1157,7
This is getting bigger than expected. Adding the locking that Chris
suggested on IRC.
Thanks for taking time to review Chris.
-
Lionel
Signed-off-by: Lionel Landwerlin
---
intel/intel_bufmgr_gem.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index bf6745d..4e34f75 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1783,6 +1783,7 @@ drm_intel_
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/ee0c3c8b/attachment-0001.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/60369604/attachment.html>
iving 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/20140912/eb4c9997/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/85292237/attachment.html>
Hello everyone,
to allow concurrent buffer access by different engines beyond the
multiple readers/single writer model that we currently use in radeon and
other drivers we need some kind of synchonization object exposed to
userspace.
My initial patch set for this used (or rather abused) zero s
Classification: Unclassified
OS: All
Reporter: darkbasic at linuxsystems.it
Hardware: Other
Status: NEW
Version: XOrg CVS
Component: DRM/Radeon
Product: DRI
HD 7950
Linux 3.17.0-rc2-core-avx-i-drm-next-3.18 20140912
llvm 3.6 git
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/cc89afc0/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/65fbad41/attachment-0001.html>
On Fri, Sep 12, 2014 at 11:27:41AM +0200, Andrzej Hajda wrote:
> On 09/12/2014 10:57 AM, Daniel Vetter wrote:
> > On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
> >> Hi Andrzej,
> >>
> >> On 2014? 09? 09? 22:16, Andrzej Hajda wrote:
> >>> Adding reference to framebuffer should be accompa
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/48f7d3d3/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/20140912/4f4daccd/attachment.html>
it be possible that I get SSH access to the crashed
system?
--
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/20140912
On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian K?nig wrote:
> Hello everyone,
>
> to allow concurrent buffer access by different engines beyond the multiple
> readers/single writer model that we currently use in radeon and other
> drivers we need some kind of synchonization object exposed to u
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140912/1c7819b9/attachment-0001.html>
On Fri, Sep 12, 2014 at 5:19 AM, Bruno Pr?mont
wrote:
> Bjorn,
>
> What is missing to get these two patches pushed to Linus?
Sorry, I've been working on some other regressions and overlooked this
one. If you open a bugzilla report and mark it as a regression, that
will help keep this on my radar
On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter wrote:
> On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian K?nig wrote:
>> Hello everyone,
>>
>> to allow concurrent buffer access by different engines beyond the multiple
>> readers/single writer model that we currently use in radeon and other
>> d
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/a2f0c5c5/attachment.html>
On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote:
> On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter wrote:
> > On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian K?nig wrote:
> >> Hello everyone,
> >>
> >> to allow concurrent buffer access by different engines beyond the multiple
> >>
The comment says that the caller must hold the dev->event_lock
spinlock, so let's enforce this.
A quick audit over all driver shows that except for the one place in
i915 which motivated this all callers fullfill this requirement
already.
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Si
On Fri, Sep 12, 2014 at 10:50:49AM -0400, Jerome Glisse wrote:
> On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter wrote:
> > > On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian K?nig wrote:
> > >> Hello everyone,
> > >>
> > >> to a
On Fri, Sep 12, 2014 at 03:40:56PM +0200, Daniel Vetter wrote:
> The comment says that the caller must hold the dev->event_lock
> spinlock, so let's enforce this.
>
> A quick audit over all driver shows that except for the one place in
> i915 which motivated this all callers fullfill this requirem
On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse wrote:
> On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote:
>> On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter wrote:
>> > On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian K?nig wrote:
>> >> Hello everyone,
>> >>
>> >> to allow concurr
On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote:
> On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse wrote:
> > On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote:
> >> On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter wrote:
> >> > On Fri, Sep 12, 2014 at 03:23:22PM +0200, Chr
On Fri, Sep 12, 2014 at 04:23:29PM +0100, Chris Wilson wrote:
> On Fri, Sep 12, 2014 at 03:40:56PM +0200, Daniel Vetter wrote:
> > The comment says that the caller must hold the dev->event_lock
> > spinlock, so let's enforce this.
> >
> > A quick audit over all driver shows that except for the one
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/8add15b1/attachment.html>
On Fri, Sep 12, 2014 at 11:33 AM, Jerome Glisse wrote:
> On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote:
>> On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse
>> wrote:
>> > On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote:
>> >> On Fri, Sep 12, 2014 at 4:09 PM, Daniel Ve
Hi Dave,
So here's the header cleanup, rebased on top of drm-next. Two new header
files are created here:
- drivers/gpu/drm/drm_internal.h for non-legacy drm.ko private
declarations.
- include/drm/drm_legacy.h for legacy interfaces used by non-kms drivers.
And of course lots fo stuff gets shu
Am 12.09.2014 um 17:33 schrieb Jerome Glisse:
> On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote:
>> On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse
>> wrote:
>>> On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote:
On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter wrote:
On Fri, Sep 12, 2014 at 05:42:57PM +0200, Christian K?nig wrote:
> Am 12.09.2014 um 17:33 schrieb Jerome Glisse:
> >On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote:
> >>On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse
> >>wrote:
> >>>On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Ve
On Fri, Sep 12, 2014 at 05:58:09PM +0200, Christian K?nig wrote:
> Am 12.09.2014 um 17:48 schrieb Jerome Glisse:
> >On Fri, Sep 12, 2014 at 05:42:57PM +0200, Christian K?nig wrote:
> >>Am 12.09.2014 um 17:33 schrieb Jerome Glisse:
> >>>On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote:
>
On Fri, Sep 12, 2014 at 05:34:56PM +0200, Daniel Vetter wrote:
> On Fri, Sep 12, 2014 at 04:23:29PM +0100, Chris Wilson wrote:
> > On Fri, Sep 12, 2014 at 03:40:56PM +0200, Daniel Vetter wrote:
> > > The comment says that the caller must hold the dev->event_lock
> > > spinlock, so let's enforce thi
> As Daniel said using fd is most likely the way we want to do it but this
> remains vague.
Separating the discussion if it should be an fd or not. Using an fd
sounds fine to me in general, but I have some concerns as well.
For example what was the maximum number of opened FDs per process again?
Am 12.09.2014 um 17:48 schrieb Jerome Glisse:
> On Fri, Sep 12, 2014 at 05:42:57PM +0200, Christian K?nig wrote:
>> Am 12.09.2014 um 17:33 schrieb Jerome Glisse:
>>> On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote:
On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse
wrote:
On Mon, Sep 08, 2014 at 10:38:07AM +0200, Johannes Berg wrote:
> On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:
>
> > > + /*
> > > + * this seems racy, but I don't see a notifier or such on
> > > + * a struct device to know when it goes away?
> > > + */
> > > + if (devcd->failing_
On Fri, 12 Sep 2014 18:08:23 +0200
Christian K?nig wrote:
> > As Daniel said using fd is most likely the way we want to do it but this
> > remains vague.
> Separating the discussion if it should be an fd or not. Using an fd
> sounds fine to me in general, but I have some concerns as well.
>
> F
it :/
--
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/20140912/84571884/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/6429a5db/attachment.html>
On Fri, Sep 12, 2014 at 05:58:09PM +0200, Christian K?nig wrote:
> pass in a list of fences to wait for before beginning a command
submission.
The Android implementation has a mechanism for combining multiple sync
points into a brand new single sync pt. Thus APIs only ever need to take
in a si
On Fri, Sep 12, 2014 at 01:03:51PM -0400, Peter Hurley wrote:
> On 09/12/2014 12:04 PM, Chris Wilson wrote:
> > On Fri, Sep 12, 2014 at 05:34:56PM +0200, Daniel Vetter wrote:
> >> On Fri, Sep 12, 2014 at 04:23:29PM +0100, Chris Wilson wrote:
> >>> On Fri, Sep 12, 2014 at 03:40:56PM +0200, Daniel Ve
Hi Dave,
Usual pile of random drm patches all over. One i915 one in here for the
hdmi doubleclock stuff since I've put both of Clint's patches into this
branch.
Rebased just now only to check what you've merged already, otherwise this
has been hanging out in -nightly for quite a while.
Cheers, D
On 09/12/2014 01:25 PM, Daniel Vetter wrote:
> On Fri, Sep 12, 2014 at 01:03:51PM -0400, Peter Hurley wrote:
>> On 09/12/2014 12:04 PM, Chris Wilson wrote:
>>> On Fri, Sep 12, 2014 at 05:34:56PM +0200, Daniel Vetter wrote:
On Fri, Sep 12, 2014 at 04:23:29PM +0100, Chris Wilson wrote:
> On
On 09/12/2014 12:04 PM, Chris Wilson wrote:
> On Fri, Sep 12, 2014 at 05:34:56PM +0200, Daniel Vetter wrote:
>> On Fri, Sep 12, 2014 at 04:23:29PM +0100, Chris Wilson wrote:
>>> On Fri, Sep 12, 2014 at 03:40:56PM +0200, Daniel Vetter wrote:
The comment says that the caller must hold the dev->e
eiving 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/20140912/e2fd4ca7/attachment.html>
ce I went to LLVM 3.6, even
though it doesn't build Mesa with it on 32-bit. Maybe it's fixed, just have to
wait for LLVM to update.
--
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/20140912/72b390e8/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=84431
Bug ID: 84431
Summary: Kernel crash when unloading radeon module for
switcheroo card
Product: Drivers
Version: 2.5
Kernel Version: all
Hardware: All
OS:
https://bugzilla.kernel.org/show_bug.cgi?id=84431
Pali Roh?r changed:
What|Removed |Added
Attachment #149991|0 |1
is patch|
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/a3978fba/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140912/a12b19b6/attachment-0001.html>
onitor but not a duel
setup?
--
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/20140912/ba21889f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=84431
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
https://bugzilla.kernel.org/show_bug.cgi?id=84431
--- Comment #2 from Pali Roh?r ---
I can, but I do not know if this is proper way how to fix it. I still think
that root of bug is in function vga_switcheroo_init_domain_pm_ops() which
overwrite dev->pm_domain, but does not restore it when driver/
https://bugzilla.kernel.org/show_bug.cgi?id=84431
--- Comment #3 from Alex Deucher ---
Created attachment 150001
--> https://bugzilla.kernel.org/attachment.cgi?id=150001&action=edit
patch 1/3
How about this patch set?
--
You are receiving this mail because:
You are watching the assignee of t
1 - 100 of 105 matches
Mail list logo
