Trying to resolve the remaining bugs today. Expect an v3 of the patch
this evening or Monday morning.
Cheers,
Christian.
On 04.10.2012 16:32, Dmitry Cherkasov wrote:
v2: setup and alloc number of contiguous PTs if possible
Warning: Heaven benchmark /sometimes/ fails with this patch after
10
On 09.11.2012 16:45, Rafał Miłecki wrote:
2012/11/9 Thierry Reding thierry.red...@avionic-design.de:
+/* all fields little endian */
+struct hdmi_audio_infoframe {
+ /* PB0 */
+ u8 csum;
+
+ /* PB1 */
+ unsigned cc:3; /* channel count */
+ unsigned res1:1;
+
Hi Dmitry,
as I already noted in our internal discussion, the first step to
hierarchical page table support should be to cleanup the set_page
interface. Please see the attached patch, it does exactly this. I
suggest that you rebase on it and try to don't touch the chipset
specific code in
On 13.09.2012 20:42, Jerome Glisse wrote:
On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
dcherkas...@gmail.com wrote:
PDE/PTE update code
Looks good in general, some minor comments below:
On 14.09.2012 19:49, Dmitry Cherkasov wrote:
From: Christian König deathsim...@vodafone.de
Cleanup the interface in preparation for hierarchical page tables.
v2: * add incr parameter to set_page for simple scattered PTs uptates
* added PDE
On 14.09.2012 19:49, Dmitry Cherkasov wrote:
PDE/PTE update code uses CP ring for memory writes.
All page table entries are preallocated for now in alloc_pt().
It is made as whole because it's hard to divide it to several patches
that compile and doesn't break anything being applied separately.
On 17.12.2012 22:31, Paul Bolle wrote:
On an (outdated) laptop the radeon driver (almost always) prints, during
the first resume of each session:
[drm] crtc 1 is connected to a TV
This message is a bit puzzling as, as far as I know, no TV has ever
been connected to this laptop. Anyhow,
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
} while (atomic64_xchg(rdev-fence_drv[ring].last_seq, seq) seq);
- if (wake) {
+ if (wake)
Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
Op 19-08-13 14:35, Christian König schreef:
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
} while (atomic64_xchg(rdev-fence_drv
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so
Am 20.08.2013 15:21, schrieb Maarten Lankhorst:
Op 20-08-13 11:51, Christian König schreef:
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock
- off);
^
Silence this warning by using min_t(). Since cur_size will never be
negative and its upper bound is PAGE_SIZE, we can change its type to
size_t and use min_t(size_t, [...]) here.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
Reviewed-by: Christian König
Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
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.
Can't we make that just dma_buf[offset] != 0 instead? As far as I know
this
Am 17.02.2014 18:27, schrieb Rob Clark:
On Mon, Feb 17, 2014 at 11:56 AM, Christian König
deathsim...@vodafone.de wrote:
Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until
Am 17.02.2014 19:24, schrieb Rob Clark:
On Mon, Feb 17, 2014 at 12:36 PM, Christian König
deathsim...@vodafone.de wrote:
Am 17.02.2014 18:27, schrieb Rob Clark:
On Mon, Feb 17, 2014 at 11:56 AM, Christian König
deathsim...@vodafone.de wrote:
Am 17.02.2014 16:56, schrieb Maarten Lankhorst
), 256MB GDDR3.
Bisected to this commit:
commit f9eaf9ae782d6480f179850e27e6f4911ac10227
Author: Christian König christian.koe...@amd.com
Date: Tue Oct 29 20:14:47 2013 +0100
drm/radeon: rework and fix reset detection v2
Stop fiddling with jiffies, always wait
Am 07.05.2013 23:13, schrieb Parag Warudkar:
On Tue, May 7, 2013 at 4:44 AM, Christian König deathsim...@vodafone.de wrote:
The patch shouldn't be necessary because just removing the firmware should
have pretty much the same effect.
Soon distros will ship the UVD firmware by default
Am 15.05.2013 22:57, schrieb Yinghai Lu:
On Wed, May 15, 2013 at 8:20 AM, Christian König
christian.koe...@amd.com wrote:
Am 15.05.2013 16:46, schrieb Yinghai Lu:
On Wed, May 15, 2013 at 2:46 AM, Christian König
christian.koe...@amd.com wrote:
Hi guys,
the following commit breaks booting my
Am 16.05.2013 11:41, schrieb Christian König:
Am 15.05.2013 22:57, schrieb Yinghai Lu:
On Wed, May 15, 2013 at 8:20 AM, Christian König
christian.koe...@amd.com wrote:
Am 15.05.2013 16:46, schrieb Yinghai Lu:
On Wed, May 15, 2013 at 2:46 AM, Christian König
christian.koe...@amd.com wrote
Hi everybody,
the following crash happens when booting one of our E350 based test
system in EFI mode, booting with in BIOS compatibility mode works fine.
Bisecting initially turned out to be commit
8d57470d8f859635deffe3919d7d4867b488b85a, but that turned out to be a
false positive and
Am 16.05.2013 17:17, schrieb Yinghai Lu:
On Thu, May 16, 2013 at 5:49 AM, Christian König
christian.koe...@amd.com wrote:
Am 16.05.2013 11:41, schrieb Christian König:
Ups, the board DOES have a serial port, and I've got a log now that shows
the mentioned patch above isn't the root cause
Am 16.05.2013 17:42, schrieb Yinghai Lu:
On Thu, May 16, 2013 at 8:23 AM, Christian König
christian.koe...@amd.com wrote:
Am 16.05.2013 17:17, schrieb Yinghai Lu:
On Thu, May 16, 2013 at 5:49 AM, Christian König
christian.koe...@amd.com wrote:
Am 16.05.2013 11:41, schrieb Christian König
Am 17.05.2013 19:54, schrieb Yinghai Lu:
On Fri, May 17, 2013 at 2:43 AM, Christian König
christian.koe...@amd.com wrote:
Am 16.05.2013 17:42, schrieb Yinghai Lu:
On Thu, May 16, 2013 at 8:23 AM, Christian König
christian.koe...@amd.com wrote:
Am 16.05.2013 17:17, schrieb Yinghai Lu
new add one fill the hole between two exsiting
ranges. In the case when [mem 0x0010-0x6bff] is the hole between
[mem 0x-0x000f] and [mem 0x6c00-0x6e7f].
Fix the add_range_with_merge by calling itself recursively.
Reported-by: Christian König christian.koe...@amd.com
Am 08.10.2013 16:33, schrieb Jerome Glisse:
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in
Hi guys,
the following commit breaks booting my E350 based test system in EFI mode:
commit 8d57470d8f859635deffe3919d7d4867b488b85a
Author: Yinghai Lu ying...@kernel.org
Date: Fri Nov 16 19:38:58 2012 -0800
x86, mm: setup page table in top-down
This commit was supposed to fix it but
Am 15.05.2013 16:46, schrieb Yinghai Lu:
On Wed, May 15, 2013 at 2:46 AM, Christian König
christian.koe...@amd.com wrote:
Hi guys,
the following commit breaks booting my E350 based test system in EFI mode:
commit 8d57470d8f859635deffe3919d7d4867b488b85a
Author: Yinghai Lu ying...@kernel.org
Yeah, agree. That function is quite critical for command stream parsing
and patching.
Christian.
Am 20.05.2014 18:16, schrieb Marek Olšák:
I think the function should stay in the header file. It's used in
performance-critical code, so we want it to be inlined.
Marek
On Fri, May 16, 2014 at
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian König schreef:
+/* did fence get signaled after we enabled the sw irq? */
+if
(atomic64_read(fence-rdev-fence_drv[fence-ring].last_seq) =
fence-seq) {
+radeon_irq_kms_sw_irq_put(fence-rdev, fence
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian König schreef:
+/* did fence get signaled after we enabled the sw irq? */
+if
(atomic64_read(fence-rdev-fence_drv
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian König schreef:
+/* did
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
op 15-05-14 18:13, Christian König schreef:
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole approach collides with the way we
do reset handling from a conceptual point of view. Every IOCTL or
other call
Am 19.05.2014 15:35, schrieb Maarten Lankhorst:
op 19-05-14 14:30, Christian König schreef:
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole approach collides
Am 01.06.2014 01:10, schrieb Rickard Strandqvist:
There is a risk that the variable will be used without being initialized.
This was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
On the one
Am 02.06.2014 12:09, schrieb Maarten Lankhorst:
Changes since v1:
- Fixed interaction with reset handling.
+ Use exclusive_lock, either with trylock or blocking.
+ Bump sw irq refcount in the recovery function to prevent fiddling
with irq registers during gpu recovery.
- Add radeon
). Bisection blames:
3b333c55485fef0089ae7398906599d000df195e is the first bad commit
commit 3b333c55485fef0089ae7398906599d000df195e
Author: Christian König christian.koe...@amd.com
Date: Thu Apr 24 18:39:59 2014 +0200
drm/radeon: avoid high jitter with small frac divs
Signed
, Christian König wrote:
Hi Ken,
*sigh* did I already mentioned that I hate PLLs? As soon as you fix
something another use case immediately starts to break.
Please provide dmesg output created with drm.debug=0xe with and without the
patch breaking it.
Thanks in advance,
Christian
+ /* did fence get signaled after we enabled the sw irq? */
+ if (atomic64_read(fence-rdev-fence_drv[fence-ring].last_seq) =
fence-seq) {
+ radeon_irq_kms_sw_irq_put(fence-rdev, fence-ring);
+ return false;
+ }
+
+ fence-fence_wake.flags = 0;
+
Am 02.06.2014 15:14, schrieb Maarten Lankhorst:
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Splitted out version, I've noticed that I forgot to convert
: use a mutex to properly lock srbm instanced registers
drm/radeon/dpm: require rlc for dpm
drm/radeon: make missing smc ucode non-fatal
Christian König (5):
drm/radeon: fix halting UVD
drm/radeon: only save UVD bo when we have open handles
drm/radeon: stop
+ /* We are living in a monstruous world in which you can have the pci
+* root complex behind an hypertransport link which can not address
+* anything above 32bit (well hypertransport specification says 40bits
+* but hardware such as SIS761 only support 32bits).
That
Am 23.04.2014 23:36, schrieb Woody Suwalski:
Dave Airlie wrote:
On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Dave, mind sending me a pull request for drm fixes?
There's now at least these two:
- drm/radeon/aux: fix hpd assignment for aux bus
-
Am 24.04.2014 00:04, schrieb Ed Tomlinson:
On Wednesday 23 April 2014 07:54:17 Dave Airlie wrote:
On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Dave, mind sending me a pull request for drm fixes?
There's now at least these two:
- drm/radeon/aux: fix
no easter eggs, its a bit larger than I'd
like, but I included a patch that just moves code from one file to another
and I'd like to avoid merge conflicts with that later, so it makes it seem
worse than it is,
Christian König (2):
drm/radeon: apply more strict limits for PLL params v2
drm
Is this a regression? UVD is released for quite a while.
Make sure you have updated firmware installed as well.
Christian.
Am 20.04.2014 14:26, schrieb Borislav Petkov:
Hey guys,
while we're on the topic, I'm seeing this on an older F14h laptop
(E-350). I'm guessing the UVD won't get up on
Am 15.04.2014 00:13, schrieb Deucher, Alexander:
-Original Message-
From: Christoph Jaeger [mailto:christophjae...@linux.com]
Sent: Monday, April 14, 2014 6:10 PM
To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie
Cc: dri-de...@lists.freedesktop.org;
Hi Borislav,
that's a known issue and should be fixed in the next rc, see this
bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
You might also want to try my branch with 3.15 fixes which includes the
necessary patch for this:
; Deucher, Alexander
Subject: [PATCH] drm/radeon: memory leak on bo reservation failure.
On bo reservation failure, we end up leaking fpriv.
Fixes: 5e386b574cf7e1 (drm/radeon: fix missing bo reservation)
Cc: sta...@vger.kernel.org
Cc: Christian König christian.koe...@amd.com
Cc: Alex Deucher
for the old and the new kernel.
Christian.
Am 15.04.2014 15:06, schrieb Alex Deucher:
On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov b...@alien8.de wrote:
Hi Christian,
On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
Hi Borislav,
that's a known issue and should be fixed
Am 16.04.2014 10:32, schrieb Kertesz Laszlo:
Borislav Petkov wrote:
On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote:
Turning off modesetting basically disables the driver.
Well, in my case, I was using the radeon.modeset=0 variant to rule out
issues in x.org. And in my
Am 11.07.2014 18:05, schrieb Jerome Glisse:
On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
To support HSA on KV, we need to limit the number of vmids and pipes
that are available for radeon's use with KV.
This patch reserves VMIDs 8-15 for KFD (so radeon can only use VMIDs
0-7)
Am 21.07.2014 09:01, schrieb Daniel Vetter:
On Sun, Jul 20, 2014 at 01:46:53PM -0400, Jerome Glisse wrote:
On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
Forgot to cc mailing list on cover letter. Sorry.
As a continuation to the existing discussion, here is a v2 patch series
Am 21.07.2014 14:36, schrieb Oded Gabbay:
On 20/07/14 20:46, Jerome Glisse wrote:
On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
Forgot to cc mailing list on cover letter. Sorry.
As a continuation to the existing discussion, here is a v2 patch series
restructured with a cleaner
Am 22.07.2014 06:05, schrieb Dave Airlie:
On 9 July 2014 22:29, Maarten Lankhorst maarten.lankho...@canonical.com wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/radeon/radeon.h| 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60
Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian König wrote:
Am 22.07.2014 06:05, schrieb Dave Airlie:
On 9 July 2014 22:29, Maarten Lankhorst maarten.lankho...@canonical.com wrote
Am 22.07.2014 15:26, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian König wrote:
Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian König wrote:
Am
copy_from_user to figure
out if a fence is signaled or not.
Returning false all the time is probably not a good idea either.
Christian.
Am 22.07.2014 16:05, schrieb Maarten Lankhorst:
op 22-07-14 14:19, Christian König schreef:
Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 01
Am 22.07.2014 16:27, schrieb Maarten Lankhorst:
op 22-07-14 16:24, Christian König schreef:
No, you really shouldn't be doing much in the check anyway, it's meant to be a
lightweight check. If you're not ready yet because of a lockup simply return
not signaled yet.
It's not only the lockup
Am 22.07.2014 16:44, schrieb Maarten Lankhorst:
op 22-07-14 15:45, Christian König schreef:
Am 22.07.2014 15:26, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian König wrote:
Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 01:46:07PM +0200
Am 22.07.2014 16:47, schrieb Maarten Lankhorst:
op 22-07-14 16:39, Christian König schreef:
Am 22.07.2014 16:27, schrieb Maarten Lankhorst:
op 22-07-14 16:24, Christian König schreef:
No, you really shouldn't be doing much in the check anyway, it's meant to be a
lightweight check. If you're
Am 22.07.2014 17:17, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 3:45 PM, Christian König
deathsim...@vodafone.de wrote:
Would that be something you can agree to?
No, the whole enable_signaling stuff should go away. No callback from the
driver into the fence code, only the other way around
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
christian.koe...@amd.com wrote:
Drivers exporting fences need to provide a fence-signaled and a fence-wait
function, everything else like fence-enable_signaling or calling
fence_signaled() from
Vetter:
On Tue, Jul 22, 2014 at 5:59 PM, Christian König
deathsim...@vodafone.de wrote:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
christian.koe...@amd.com wrote:
Drivers exporting fences need to provide a fence-signaled and a
fence-wait
function
Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
op 22-07-14 17:59, Christian König schreef:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
christian.koe...@amd.com wrote:
Drivers exporting fences need to provide a fence-signaled and a fence-wait
Am 23.07.2014 08:50, schrieb Oded Gabbay:
On 22/07/14 14:15, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
On 22/07/14 12:21, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay oded.gab...@amd.com
wrote:
Exactly, just prevent userspace from
Am 23.07.2014 09:09, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Can we somehow avoid the need to call fence_signal() at all? The interrupts at
least on radeon are way to unreliable for such a thing. Can enable_signalling
Am 23.07.2014 09:06, schrieb Maarten Lankhorst:
op 23-07-14 08:52, Christian König schreef:
Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
op 22-07-14 17:59, Christian König schreef:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
christian.koe
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
deathsim...@vodafone.de wrote:
It's not a locking problem I'm talking about here. Radeons lockup handling
kicks in when anything calls into the driver from the outside, if you have a
fence wait function
Am 23.07.2014 09:32, schrieb Maarten Lankhorst:
op 23-07-14 09:15, Christian König schreef:
Am 23.07.2014 09:09, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Can we somehow avoid the need to call fence_signal() at all
by another
driver waiting patiently for radeon to finish rendering which never
happens because the whole thing is locked up and we don't get a chance
to recover.
Christian.
Am 23.07.2014 09:51, schrieb Maarten Lankhorst:
op 23-07-14 09:37, Christian König schreef:
Am 23.07.2014 09:31
Am 23.07.2014 10:07, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:58 AM, Christian König
deathsim...@vodafone.de wrote:
Just imagine an application using prime is locking up Radeon and because of
that gets killed by the user. Nothing else in the system would use the
Radeon hardware any more
Am 23.07.2014 10:01, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:37 AM, Christian König
christian.koe...@amd.com wrote:
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
deathsim...@vodafone.de wrote:
It's not a locking problem I'm talking about
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
In this case if the sync was to i915 the i915 lockup procedure would take care
of itself. It wouldn't fix radeon, but it would at least unblock your intel
Am 23.07.2014 10:54, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:46 AM, Christian König
deathsim...@vodafone.de wrote:
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
In this case if the sync
Am 23.07.2014 11:30, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
christian.koe...@amd.com wrote:
You submit a job to the hardware and then block the job to wait for radeon
to be finished? Well than this would indeed require a hardware reset, but
wouldn't that make
Am 23.07.2014 11:38, schrieb Maarten Lankhorst:
op 23-07-14 11:36, Christian König schreef:
Am 23.07.2014 11:30, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
christian.koe...@amd.com wrote:
You submit a job to the hardware and then block the job to wait for radeon
Am 23.07.2014 11:44, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The scheduler needs to keep track of a lot of fences, so I think we'll
have to register callbacks, not a simple wait function. We must keep
track of all the non-i915 fences
Am 23.07.2014 11:55, schrieb Maarten Lankhorst:
op 23-07-14 11:47, Christian König schreef:
Am 23.07.2014 11:44, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The scheduler needs to keep track of a lot of fences, so I think we'll
have
Am 11.07.2014 18:22, schrieb Alex Deucher:
On Fri, Jul 11, 2014 at 12:18 PM, Christian König
christian.koe...@amd.com wrote:
Am 11.07.2014 18:05, schrieb Jerome Glisse:
On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
To support HSA on KV, we need to limit the number of vmids
Am 11.07.2014 23:18, schrieb Jerome Glisse:
On Thu, Jul 10, 2014 at 10:51:29PM +, Gabbay, Oded wrote:
On Thu, 2014-07-10 at 18:24 -0400, Jerome Glisse wrote:
On Fri, Jul 11, 2014 at 12:45:27AM +0300, Oded Gabbay wrote:
This patch set implements a Heterogeneous System Architecture
(HSA)
Am 14.07.2014 09:38, schrieb Michel Dänzer:
On 11.07.2014 06:50, Oded Gabbay wrote:
@@ -5876,8 +5871,13 @@ int cik_ib_parse(struct radeon_device *rdev, struct
radeon_ib *ib)
*/
int cik_vm_init(struct radeon_device *rdev)
{
- /* number of VMs */
- rdev-vm_manager.nvm = 16;
+
I vote for HSA module that expose ioctl and is an intermediary with the
kernel driver that handle the hardware. This gives a single point for
HSA hardware and yes this enforce things for any hardware manufacturer.
I am more than happy to tell them that this is it and nothing else if
they want to
Am 27.07.2014 um 13:05 schrieb Oded Gabbay:
On 21/07/14 05:42, Jerome Glisse wrote:
On Thu, Jul 17, 2014 at 04:29:22PM +0300, Oded Gabbay wrote:
From: Ben Goz ben@amd.com
The kernel queue module enables the amdkfd to establish kernel
queues, not exposed to user space.
The kernel queues
Am 17.07.2014 13:57, schrieb Oded Gabbay:
On 11/07/14 19:36, Jerome Glisse wrote:
On Fri, Jul 11, 2014 at 12:50:08AM +0300, Oded Gabbay wrote:
The KFD driver should be loaded when the radeon driver is loaded and
should be finalized when the radeon driver is removed.
This patch adds a function
Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
V1 had a nasty bug breaking gpu lockup recovery. The fix is not
allowing radeon_fence_driver_check_lockup to take exclusive_lock,
and kill it during lockup recovery instead.
Hi Maarten,
Sorry for the delay. I've got way to much todo recently.
Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
On 01-08-14 18:35, Christian König wrote:
Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
V1 had
Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
op 04-08-14 10:36, Christian König schreef:
Hi Maarten,
Sorry for the delay. I've got way to much todo recently.
Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
On 01-08-14 18:35, Christian König wrote:
Am 31.07.2014 um 17:33 schrieb
Am 23.07.2014 12:52, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 12:13 PM, Christian König
christian.koe...@amd.com wrote:
And the dma-buf would still have fences belonging to both drivers, and it
would still call from outside the driver.
Calling from outside the driver is fine as long
into it or help with the
patch, but the general approach sounds valid to me.
Regards,
Christian.
Am 23.07.2014 16:05, schrieb Maarten Lankhorst:
op 23-07-14 15:16, Maarten Lankhorst schreef:
op 23-07-14 14:36, Christian König schreef:
Am 23.07.2014 12:52, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 12
.
Am 04.08.2014 um 15:34 schrieb Maarten Lankhorst:
Hey,
op 04-08-14 13:57, Christian König schreef:
Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
op 04-08-14 10:36, Christian König schreef:
Hi Maarten,
Sorry for the delay. I've got way to much todo recently.
Am 01.08.2014 um 19:46
Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
op 04-08-14 16:37, Christian König schreef:
It'a pain to deal with gpu reset.
Yeah, well that's nothing new.
I've now tried other solutions but that would mean reverting to the old style
during gpu lockup recovery, and only running
Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
op 04-08-14 16:45, Christian König schreef:
Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
op 04-08-14 16:37, Christian König schreef:
It'a pain to deal with gpu reset.
Yeah, well that's nothing new.
I've now tried other solutions
Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst:
op 04-08-14 17:04, Christian König schreef:
Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
op 04-08-14 16:45, Christian König schreef:
Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
op 04-08-14 16:37, Christian König schreef:
It'a pain
Is this possible and if not, why not?
Long story short on modern hardware the VGA console is just an emulation
working on top of the real hardware. When the driver wants to talk to
the real hardware it must simply disable the VGA emulation first.
But to me all points why you don't like the
Am 22.12.2014 um 20:18 schrieb Oded Gabbay:
On 12/22/2014 09:00 PM, Andi Kleen wrote:
On Mon, Dec 22, 2014 at 10:49:40AM -0800, Andi Kleen wrote:
On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote:
On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay oded.gab...@amd.com wrote:
amdkfd
Am 29.12.2014 um 09:16 schrieb Laurent Pinchart:
Hi Oded,
On Sunday 28 December 2014 13:36:50 Oded Gabbay wrote:
On 12/26/2014 11:19 AM, Laurent Pinchart wrote:
On Thursday 25 December 2014 14:20:59 Thierry Reding wrote:
On Mon, Dec 22, 2014 at 01:07:13PM +0200, Oded Gabbay wrote:
This
the module load dependencies in
the next kernel release.
For now the patch is Reviewed-by: Christian König christian.koe...@amd.com
---
drivers/gpu/drm/radeon/radeon_kfd.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c
b/drivers/gpu/drm
1 - 100 of 1497 matches
Mail list logo
