On Thu, May 10, 2012 at 10:51 PM, KOSAKI Motohiro
wrote:
> (5/10/12 8:50 PM), Minchan Kim wrote:
>>
>> Hi KOSAKI,
>>
>> On 05/11/2012 02:53 AM, KOSAKI Motohiro wrote:
>>
>> let's assume that one application want to allocate user space memory
>> region using malloc() and then write somethin
On Fri, May 11, 2012 at 6:10 AM, Christian König
wrote:
> Even more heretic than the last one. The mutex is
> probably good for something, I just can't see what
> that is at the moment.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h | 1 -
> drivers/gpu/drm/
On Fri, May 11, 2012 at 10:41 AM, Jerome Glisse wrote:
> On Fri, May 11, 2012 at 6:10 AM, Christian König
> wrote:
>> Even more heretic than the last one. The mutex is
>> probably good for something, I just can't see what
>> that is at the moment.
>>
On Fri, May 11, 2012 at 5:20 PM, KOSAKI Motohiro
wrote:
> (5/10/12 11:01 PM), Jerome Glisse wrote:
>>
>> On Thu, May 10, 2012 at 10:51 PM, KOSAKI Motohiro
>> wrote:
>>>
>>> (5/10/12 8:50 PM), Minchan Kim wrote:
>>>>
>>>>
>>
On Fri, May 11, 2012 at 6:59 PM, KOSAKI Motohiro
wrote:
>> My point is this ioctl will be restricted to one user (Xserver if i
>> understand) and only this user, there is no fork in it so no need to
>> worry about fork, just setting the vma as locked will be enough.
>>
>> But i don't want people r
On Fri, May 11, 2012 at 7:54 AM, Christian König
wrote:
> On 11.05.2012 12:12, Dave Airlie wrote:
>>
>> On Fri, May 11, 2012 at 11:10 AM, Christian König
>> wrote:
>>>
>>> Hi everybody,
>>>
>>> well the following patches remove the cs and vram mutex from the radeon
>>> driver
>>> and so are some
On Mon, May 14, 2012 at 2:17 AM, Inki Dae wrote:
> this feature is used to import user space region allocated by malloc() or
> mmaped into a gem. for this, we uses get_user_pages() to get all the pages
> to VMAs within user address space. However we should pay attention to use
> this userptr featu
On Tue, May 15, 2012 at 12:33 AM, Inki Dae wrote:
> Hi Jerome,
>
>> -Original Message-----
>> From: Jerome Glisse [mailto:j.gli...@gmail.com]
>> Sent: Tuesday, May 15, 2012 4:27 AM
>> To: Inki Dae
>> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
On Thu, May 17, 2012 at 10:41 AM, Dave Airlie wrote:
> On Wed, May 16, 2012 at 10:22 PM, wrote:
>> From: Jerome Glisse
>>
>> This try to identify the faulty user command stream that caused
>> lockup. If it finds one it create big blob that contains all
>>
On Sat, May 19, 2012 at 2:56 PM, Daniel Vetter wrote:
> On Thu, May 17, 2012 at 03:41:30PM +0100, Dave Airlie wrote:
>> On Wed, May 16, 2012 at 10:22 PM, wrote:
>> > From: Jerome Glisse
>> >
>> > This try to identify the faulty user command stream that ca
>> Tested on a Lenovo T500 against a DP->VGA adaptor (which turns out to be
>> an ST Microelectronics chip, who knew) and an HP LP2480zx (which does
>> not advertise OUI support, but also harmlessly returns 0s for the OUI
>> registers if you read them anyway).
>
> Bum
ake sure to setup VM for sg bos as well.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 17 +
use new helpers + add reimporting
>
> Signed-off-by: Alex Deucher
> Signed-off-by: Dave Airlie
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/Makefile | 2 +-
> drivers/gpu/drm/radeon/evergreen_blit_kms.c | 2 +-
> drivers/gpu/drm/radeon/r6
On Thu, May 17, 2012 at 6:07 PM, wrote:
> Ok this time is final version, i added a bunch of flags to cmd buffer
> to make the userspace tools life easier.
>
> Cheers,
> Jerome
>
So updated libdrm patch :
http://people.freedesktop.org/~glisse/lockup/0001-radeon-add-rati-dumping-helper.patch
Also
On Wed, May 23, 2012 at 8:34 AM, Christian König
wrote:
> On 23.05.2012 11:27, Dave Airlie wrote:
>>
>> On Thu, May 17, 2012 at 7:28 PM, wrote:
>>>
>>> So here is improved patchset, where i splited ground work necessary
>>> for the dumping into their own patch. The debugfs improvement could
>>> p
On Wed, May 23, 2012 at 5:27 AM, Dave Airlie wrote:
> On Thu, May 17, 2012 at 7:28 PM, wrote:
>> So here is improved patchset, where i splited ground work necessary
>> for the dumping into their own patch. The debugfs improvement could
>> probably be usefull to intel instead of having i915 have
On Wed, May 23, 2012 at 12:04 PM, Alex Deucher wrote:
> On Wed, May 23, 2012 at 8:34 AM, Christian König
> wrote:
>> On 23.05.2012 11:27, Dave Airlie wrote:
>>>
>>> On Thu, May 17, 2012 at 7:28 PM, wrote:
So here is improved patchset, where i splited ground work necessary
for the
On Wed, May 23, 2012 at 12:08 PM, Dave Airlie wrote:
> On Wed, May 23, 2012 at 3:48 PM, Jerome Glisse wrote:
>> On Wed, May 23, 2012 at 8:34 AM, Christian König
>> wrote:
>>> On 23.05.2012 11:27, Dave Airlie wrote:
>>>>
>>>> On Thu, May 17,
On Wed, May 23, 2012 at 12:41 PM, Dave Airlie wrote:
> On Wed, May 23, 2012 at 5:26 PM, Jerome Glisse wrote:
>> On Wed, May 23, 2012 at 12:08 PM, Dave Airlie wrote:
>>> On Wed, May 23, 2012 at 3:48 PM, Jerome Glisse wrote:
>>>> On Wed, May 23, 2012 at 8:34 A
t;
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 31 +--
> 1 files changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
&
;> BUG_ON(rdev->ddev->irq_enabled && rdev->irq.sw_refcount[ring] <= 0);
>>> if (rdev->ddev->irq_enabled && (--rdev->irq.sw_refcount[ring] == 0))
>>> {
>>> rdev->irq.sw_int[ring] = fals
On Thu, May 31, 2012 at 4:15 PM, Christian König
wrote:
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h | 23 ++-
> drivers/gpu/drm/radeon/radeon_fence.c | 73
> +
> 2 files changed, 85 insertions(+), 11 deletions(-)
>
>
On Sun, Jun 3, 2012 at 10:09 AM, Christian König
wrote:
> Locking mutex in different orders just screams for
> deadlocks, and some testing showed that it is actually
> quite easy to trigger them.
>
> Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
> Cc: sta.
On Mon, Jun 4, 2012 at 8:40 AM, Martin Peres wrote:
> Le 04/06/2012 13:30, Christian König a écrit :
>>
>> On 04.06.2012 10:44, Lauri Kasanen wrote:
>>>
>>> So the issue is the location of the info, not the format. I'd be more
>>> than happy to split it into six files (default_core_clock,
>>> curr
On Mon, Jun 4, 2012 at 11:02 AM, Martin Peres wrote:
> Le 04/06/2012 16:31, Jerome Glisse a écrit :
>
>>
>> I don't think sysfs is the way to go, i am pretty sure that power
>> management will change drasticly again in the future especialy btw
>> discret and
On Mon, Jun 4, 2012 at 12:29 PM, Lauri Kasanen wrote:
> On Mon, 04 Jun 2012 18:18:10 +0200
> Christian König wrote:
>> > My experience is that things that are true today for GPU, are not
>> > tomorrow. Yes there will still be clock/voltage, but there could be
>> > new complete different things, l
On Mon, Jun 4, 2012 at 1:01 PM, Martin Peres wrote:
> Le 04/06/2012 17:18, Jerome Glisse a écrit :
>
>>
>> My experience is that things that are true today for GPU, are not
>> tomorrow. Yes there will still be clock/voltage, but there could be
>> new complete differ
On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres wrote:
> Answers inlined.
>
> Le 04/06/2012 19:19, Jerome Glisse a écrit :
>
>>
>> My point is that there is no way for power management to find an API
>> that fits all GPU. If i were to do it now, i would have one ioct
On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres wrote:
>> Answers inlined.
>>
>> Le 04/06/2012 19:19, Jerome Glisse a écrit :
>>
>>>
>>> My point is that there is no way for power management to find
On Sat, Jun 9, 2012 at 12:15 PM, Boszormenyi Zoltan wrote:
> 2012-06-09 16:57 keltezéssel, j.gli...@gmail.com írta:
>>
>> From: Jerome Glisse
>>
>> Fix regresson since the introduction of command stream checking on
>> evergreen (thread referenced below). Issue
uces a regression where
>> metadata accounting is leaked if a buffer object is
>> initialized with an illegal size. This is also fixed with this commit.
>>
>> v2: Fixed an error path and removed an unused variable.
>>
>> Signed-off-by: Thomas Hellstrom
>&g
On Wed, Jun 13, 2012 at 4:11 PM, Joakim Plate wrote:
> Michel Dänzer daenzer.net> writes:
>
>> > >
>> > > From the GLX_OML_sync_control spec:
>> > >
>> > > The Unadjusted System Time (or UST) is a 64-bit monotonically
>> > > increasing counter [...]
>> > >
>
> From what I can t
On Thu, Jun 14, 2012 at 12:04 AM, llittle了了 wrote:
> Yes, I transplant the radeon_driver from 64bit_kernel to a mini 32bit_os.
> The purpose is to open radeon_benchmark or Xorg in the mini_32bit_os.
> So, I think ring_test success means GPU work correctly and smmothly.
>
> But ,my ring_test in t
On Thu, Jun 14, 2012 at 1:19 PM, Joakim Plate wrote:
>
>> >
>> > From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000.
> Only
>> > issue is that changing it will break any app relying on it being REALTIME
> clock.
>> >
>>
>> App that rely on it being anything special are badly
On Thu, Jun 14, 2012 at 2:17 PM, Jerome Glisse wrote:
> On Thu, Jun 14, 2012 at 1:19 PM, Joakim Plate wrote:
>>
>>> >
>>> > From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000.
>> Only
>>> > issue is that changing it will
: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 10 +++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 79642cd..7ae6066 1
I intend to do a libdrm release this week, anybody that want to ride along ?
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Jun 27, 2012 at 5:19 AM, Michel Dänzer wrote:
> On Die, 2012-06-26 at 17:04 -0400, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> After unrecovered GPU lockup avoid any GPU activities to avoid
>> things like kernel segfault and alike to happen in any of
ull
> page table. This limits us to only 2 VMs active at any
> given time on SI. This will be rectified and the code can
> be reunified once we move to two level page tables.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> Cc: sta...@vger.kernel.or
On Thu, Jun 28, 2012 at 5:50 PM, wrote:
> From: Alex Deucher
>
> It was stuck right in the middle of the gart functions.
> Move next to the bm_disable function and where it is used.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/
On Fri, Jun 29, 2012 at 11:23 AM, Alex Deucher wrote:
> On Fri, Jun 29, 2012 at 10:49 AM, Michel Dänzer wrote:
>> On Don, 2012-06-28 at 17:53 -0400, alexdeuc...@gmail.com wrote:
>>> From: Alex Deucher
>>>
>>> Cayman and trinity allow for variable sized VM page
>>> tables, but SI requires that al
On Fri, Jun 29, 2012 at 12:14 PM, Michel Dänzer wrote:
> On Fre, 2012-06-29 at 11:28 -0400, Jerome Glisse wrote:
>> On Fri, Jun 29, 2012 at 11:23 AM, Alex Deucher wrote:
>> > On Fri, Jun 29, 2012 at 10:49 AM, Michel Dänzer wrote:
>> >> On Don, 2012-06-28 at 17:5
On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer wrote:
> On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote:
>> On 29.06.2012 17:09, Michel Dänzer wrote:
>> > On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote:
>> >> Hold the ring lock the whole time the reset is in progress,
>> >> oth
On Mon, Jul 2, 2012 at 11:58 AM, Christian König
wrote:
> On 02.07.2012 17:41, Jerome Glisse wrote:
>>
>> On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer
>> wrote:
>>>
>>> On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote:
>>>>
>>&g
On Mon, Jul 2, 2012 at 11:58 AM, Christian König
wrote:
> On 02.07.2012 17:41, Jerome Glisse wrote:
>>
>> On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer
>> wrote:
>>>
>>> On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote:
>>>>
>>&g
On Mon, Jul 2, 2012 at 11:39 AM, wrote:
> From: Jerome Glisse
>
> GPU reset need to be exclusive, one happening at a time. For this
> add a rw semaphore so that any path that trigger GPU activities
> have to take the semaphore as a reader thus allowing concurency.
>
> Th
On Mon, Jul 2, 2012 at 12:26 PM, Christian König
wrote:
> On 02.07.2012 17:39, j.gli...@gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> GPU reset need to be exclusive, one happening at a time. For this
>> add a rw semaphore so that any path that trigger G
On Mon, Jul 2, 2012 at 1:05 PM, Christian König wrote:
> On 02.07.2012 18:41, Jerome Glisse wrote:
>>
>> On Mon, Jul 2, 2012 at 12:26 PM, Christian König
>> wrote:
>>>
>>> On 02.07.2012 17:39, j.gli...@gmail.com wrote:
>>>>
>>>> Fro
On Tue, Jul 3, 2012 at 5:26 AM, Christian König wrote:
> On 02.07.2012 19:27, Jerome Glisse wrote:
>>
>> On Mon, Jul 2, 2012 at 1:05 PM, Christian König
>> wrote:
>>>
>>> On 02.07.2012 18:41, Jerome Glisse wrote:
>>>>
>>>&g
On Tue, Jul 3, 2012 at 10:52 AM, Christian König
wrote:
> On 03.07.2012 16:09, Jerome Glisse wrote:
>>
>> On Tue, Jul 3, 2012 at 5:26 AM, Christian König
>> wrote:
>>>
>>> [SNIP]
>>>
>>> Yeah, but I thought that fixing those oops as t
>> Reviewed-by: Michel Dänzer
>
> For the series:
>
> Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
>> ---
>> drivers/gpu/drm/radeon/radeon.h |2 +-
>> drivers/gpu/drm/radeon/radeon_fence.c | 33
>> +
&
On Mon, Jul 9, 2012 at 6:41 AM, Christian König wrote:
> It's not critical, but the current code isn't
> 100% correct.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/ni.c | 133
> ++-
> 1 file changed, 56 insertions(+), 77 deletions(-)
On Mon, Jul 9, 2012 at 6:42 AM, Christian König wrote:
> Signed-off-by: Christian König
Bit too complex to my taste, what about attached patch, it's lot
simpler. (Haven't tested
the patch but it should work)
Cheers,
Jerome
> ---
> drivers/gpu/drm/radeon/radeon.h |3 +++
> drivers/gpu
are already in system memory or their content
>> can be easily reinitialized.
>>
>> The last three patches implement the actual tracking and restoring of
>> commands
>> in case of a lockup. Please take a look and review.
>
> Patches 3, 5 and 14 are
>
> Review
On Mon, Jul 9, 2012 at 11:48 AM, Christian König
wrote:
> On 09.07.2012 17:36, Jerome Glisse wrote:
>>
>> On Mon, Jul 9, 2012 at 6:42 AM, Christian König
>> wrote:
>>>
>>> Signed-off-by: Christian König
>>
>> Bit too complex to my taste, what
tead of storing it into memory
>
Why using scratch register ? To minimize bus activities ?
> Signed-off-by: Jerome Glisse
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/evergreen.c |8 +++-
> drivers/gpu/drm/radeon/ni.c | 11 ++-
On Fri, Jul 13, 2012 at 10:08 AM, Christian König
wrote:
> Const IBs are executed on the CE not the CP, so we can't
> fence them in the normal way.
>
> So submit them directly before the IB instead, just as
> the documentation says.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/rade
;>>>>> Before emitting any indirect buffer, emit the offset of the next
>>>>>>>>> valid ring content if any. This allow code that want to resume
>>>>>>>>> ring to resume ring right after ib that caused GPU
On Tue, Jul 17, 2012 at 5:50 AM, Christian König
wrote:
> On 13.07.2012 16:17, Tom Stellard wrote:
>>
>> On Fri, Jul 13, 2012 at 04:08:15PM +0200, Christian König wrote:
>>>
>>> Const IBs are executed on the CE not the CP, so we can't
>>> fence them in the normal way.
>>>
>>> So submit them direct
On Tue, Jul 17, 2012 at 6:25 PM, Alex Deucher wrote:
> On Tue, Jul 17, 2012 at 4:54 PM, wrote:
>> From: Jerome Glisse
>>
>> To have kernel behave like VGA/DVI we need to retrain link
>> on hotplug. For this to happen with need to report that
>> we need to link
On Thu, Jul 19, 2012 at 5:34 PM, Alex Deucher wrote:
> On Thu, Jul 19, 2012 at 5:12 PM, wrote:
>> From: Jerome Glisse
>>
>> We should not turn off the connector neither try to retrain DP link
>> if a passive DP adaptor is connected to a DP port.
>>
>&g
On Fri, Jul 20, 2012 at 4:47 AM, Christian König
wrote:
> On 20.07.2012 07:34, Dave Airlie wrote:
>>
>> Hi,
>>
>> I've just merged Linus tree into drm-next and fixes up the conflicts,
>> some in i915, one in radeon.
>>
>> Can you guys check that they look correct after it?
>
> Have to test it a bi
On Fri, Jul 20, 2012 at 10:32 AM, Christian König
wrote:
> On 20.07.2012 16:12, Jerome Glisse wrote:
>>
>> On Fri, Jul 20, 2012 at 4:47 AM, Christian König
>> wrote:
>>>
>>> On 20.07.2012 07:34, Dave Airlie wrote:
>>>>
>>>> Hi,
>&
On Thu, Jul 19, 2012 at 10:59 PM, Dave Airlie wrote:
> Hi all,
>
> sorry been v. busy with travelling, jet lag, X.org, Fedora, and
> completely fell off the -next tree.
>
> So I've spent a few hours gathering stuff up and throwing them into
> -next, I've pushed out
> drm-next, drm-core-next branch
On Tue, Jul 24, 2012 at 4:41 PM, Alex Deucher wrote:
> On Tue, Jul 24, 2012 at 4:29 PM, wrote:
>> From: Jerome Glisse
>>
>> The external encoder need to be setup again before enabling the
>> transmiter. This seems to be only needed on some trinity/aruba
>> to
On Thu, Jul 26, 2012 at 8:35 PM, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 7:24 PM, wrote:
>> From: Jerome Glisse
>>
>> When we change start address of vram for the GPU memory controller
>> we need to make sure that nothing in the GPU still use the old vram
>
On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák wrote:
> If we don't need stencil, don't allocate it.
> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>
> v2: actually do it correctly
Big NAK
We need to allocate stencil and depth no matter what. Otherwise it
will lockup.
On Mon, Jul 30, 2012 at 11:17 AM, Christian König
wrote:
> On 30.07.2012 16:56, Jerome Glisse wrote:
>>
>> On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák wrote:
>>>
>>> If we don't need stencil, don't allocate it.
>>> If we need only sten
On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher wrote:
> On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher wrote:
>> On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák wrote:
>>> On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse wrote:
>>>> On Sun, Jul 29, 2012 at 1:04 PM, M
On Mon, Jul 30, 2012 at 1:03 PM, Alex Deucher wrote:
> On Mon, Jul 30, 2012 at 12:52 PM, Jerome Glisse wrote:
>> On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher wrote:
>>> On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher
>>> wrote:
>>>> On Mon, Jul 3
On Tue, Jul 31, 2012 at 10:56 AM, Alex Deucher wrote:
> On Fri, Jul 27, 2012 at 4:32 PM, wrote:
>> So first patch is a fix in itself, smallest possible and should go to
>> stable. Second patch is an improvement as a first step to flicker free
>> boot.
>
> First patch looks ok. In mc_stop we sho
On Fri, Aug 3, 2012 at 11:53 AM, wrote:
> From: Alex Deucher
>
> Better safe than sorry.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon.h | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
>
On Fri, Aug 3, 2012 at 4:16 PM, Greg KH wrote:
> On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> Virtual address need to be fenced to know when we can safely remove it.
>> This patch also properly clear the p
On Fri, Aug 3, 2012 at 4:47 PM, Greg KH wrote:
> On Fri, Aug 03, 2012 at 04:31:22PM -0400, Jerome Glisse wrote:
>> On Fri, Aug 3, 2012 at 4:16 PM, Greg KH wrote:
>> > On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote:
>> >> From: Jerome Glisse
&g
On Mon, Aug 6, 2012 at 12:06 PM, Christian König
wrote:
> On 04.08.2012 11:07, Christian König wrote:
>>
>> On 03.08.2012 23:26, j.gli...@gmail.com wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> Virtual address need to be fenced to know when we
On Mon, Aug 6, 2012 at 12:55 PM, Christian König
wrote:
> On 06.08.2012 18:30, Jerome Glisse wrote:
>>
>> On Mon, Aug 6, 2012 at 12:06 PM, Christian König
>> wrote:
>>>
>>> [SNIP]
>>>
>>> Additional to that patch we still need a minor fix
On Wed, Aug 8, 2012 at 10:36 AM, wrote:
> From: Jerome Glisse
>
> Use the ttm bo delayed destruction queue so that we don't block
> userspace when destroying bo. The virtual address destruction
> will happen at same time as the real bo destruction when everythings
&g
On Wed, Aug 8, 2012 at 11:19 AM, Michel Dänzer wrote:
> On Mit, 2012-08-08 at 10:36 -0400, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> Use the ttm bo delayed destruction queue so that we don't block
>> userspace when destroying bo. The virtual addre
On Thu, Aug 9, 2012 at 10:34 AM, Marek Olšák wrote:
> Signed-off-by: Marek Olšák
Some comment inline that need a v2 at least for version otherwise
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/r600.c | 12 +++
> drivers/gpu/drm/radeon/r600d.h
On Thu, Aug 9, 2012 at 10:34 AM, Marek Olšák wrote:
> Signed-off-by: Marek Olšák
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/r600_cs.c | 52
> +++---
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/d
t (namely for depth-stencil resolve and
> blitting between MSAA resources).
>
> Signed-off-by: Marek Olšák
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c |7 +++
> drivers/gpu/drm/radeon/r600_cs.c |7 ++-
> drivers/gpu/dr
On Thu, Aug 9, 2012 at 10:37 AM, Marek Olšák wrote:
Reviewed-by: Jerome Glisse
> ---
> radeon/radeon_surface.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 874a0
Reviewed-by: Jerome Glisse
On Thu, Aug 9, 2012 at 10:38 AM, Marek Olšák wrote:
> ---
> radeon/radeon_surface.c | 37 +++--
> 1 file changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
On Thu, Aug 9, 2012 at 11:44 AM, Alex Deucher wrote:
> On Thu, Aug 9, 2012 at 10:57 AM, Jerome Glisse wrote:
>> On Thu, Aug 9, 2012 at 10:34 AM, Marek Olšák wrote:
>>> Signed-off-by: Marek Olšák
>>
>> Some comment inline that need a v2 at least for version otherw
y: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 17 ++---
> 1 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 7ae6066..2c2c901
On Fri, Aug 10, 2012 at 1:29 PM, wrote:
> From: Alex Deucher
>
> It was only used for dynpm, but has been replaced with
> a better implementation using fences. Remove it.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon
On Fri, Feb 1, 2013 at 7:24 AM, Meelis Roos wrote:
> I have a test PC with AMD 760MPX chipset (Tyan S2466 Tiger MPX board)
> and Radeon RV100-based AGP card where radeon KMS modesetting does not
> work (does not work with any kernel tried so far (2.6.32, 3.2, 3.7,
> 3.8-rc6).
>
> >From dmesg with
On Mon, Feb 4, 2013 at 2:21 PM, Daniel Vetter wrote:
> On Mon, Feb 4, 2013 at 7:34 PM, wrote:
>> From: Jerome Glisse
>>
>> We need to take reference on the sync object while holding the
>> fence spinlock but at the same time we don't want to allocate
>> m
On Tue, Feb 12, 2013 at 8:40 AM, wrote:
> From: Alex Deucher
>
> hdmi audio works fine. The warning just confuses users.
>
> fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=44341
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> Cc: sta...@vger.kern
On Sun, Feb 24, 2013 at 6:18 PM, Syam Sidhardhan wrote:
> kfree on NULL pointer is a no-op.
>
> Signed-off-by: Syam Sidhardhan
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c |6 ++
> drivers/gpu/drm/radeon/radeon_pm.c |
On Fri, Mar 15, 2013 at 9:50 AM, wrote:
> From: Alex Deucher
>
> Richland APUs are a new version of the Trinity APUs
> with performance and power management improvements.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
For the serie:
Reviewed-by: Jerome Glis
CIE Gen2 speeds on ppc64.
Looks good to me but we probably want some one from the pci side to take a look
Reviewed-by: Jerome Glisse
>
> Lucas Kannebley Tavares (3):
> pci: added pcie_get_speed_cap_mask function
> drm: removed drm_pcie_get_speed_cap_mask function
> ppc64:
So i am facing a dilema regarding tiling on radeonsi. Given that we now
have a fixed table of tiling mode this put more pressure on the kernel
userspace api. I see either 2 solutions.
Enforce kernel to set at fixed index in the table best tiling mode for
given gpu for given format, such as DEPTH32
On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse wrote:
> So i am facing a dilema regarding tiling on radeonsi. Given that we now
> have a fixed table of tiling mode this put more pressure on the kernel
> userspace api. I see either 2 solutions.
>
> Enforce kernel to set at fixed ind
On Tue, Apr 2, 2013 at 4:32 PM, Alex Deucher wrote:
> On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse wrote:
> > So i am facing a dilema regarding tiling on radeonsi. Given that we now
> have
> > a fixed table of tiling mode this put more pressure on the kernel
> userspace
&g
On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer wrote:
> On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> > So i am facing a dilema regarding tiling on radeonsi. Given that we
> > now have a fixed table of tiling mode this put more pressure on the
> > kernel userspac
gt; Christian.
For all patch i don't comment on (all patch but first one and second one iirc)
you got my
Reviewed-by: Jerome Glisse
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Apr 03, 2013 at 01:18:30AM +0200, Christian König wrote:
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon
On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel Dänzer wrote:
> On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote:
> > On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer
> > wrote:
> > On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> > >
On Wed, Apr 03, 2013 at 05:53:55PM +0200, Christian König wrote:
> Am 03.04.2013 16:53, schrieb Jerome Glisse:
> >On Wed, Apr 03, 2013 at 01:18:31AM +0200, Christian König wrote:
> >>[SNIP]
> >>
> >> /* hardcode those limit for now */
> >> #define
601 - 700 of 1443 matches
Mail list logo
