On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> Hi all,
>
> Meh, I've wanted to port the small set of helpers nouveau already has to
> handle per open fd gpu virtual address spaces to core drm, so that I could
> reuse them for i915. Just to go one small step towards unifying drivers in
> dr
On Mon, Jan 09, 2012 at 10:07:02AM +0100, Thomas Hellstrom wrote:
> On 01/06/2012 04:51 PM, James Simmons wrote:
> You can achieve what you want by either adding a new domain so you would
> have
> system, vram, agp, pcidma and object can be bound to one and only one. Or
> you
> >>
On Thu, Jan 05, 2012 at 10:21:31PM -0500, Alex Deucher wrote:
> On Thu, Jan 5, 2012 at 9:30 PM, Marek Olšák wrote:
> > People can start using transform feedback on r6xx with this.
> >
> > Strict CS checking will be implemented later.
We really need to have checking in the same patch, otherwise so
On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > Hi all,
> > >
> > > Meh, I've wanted to port the small set of he
On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> > Hi!
> >
> > When TTM was originally written, it was assumed that GPU apertures
> > could address pages directly, and that the CPU could access those
> > pages with
On Thu, Jan 12, 2012 at 03:42:37PM -0500, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Packet2 is only one dword.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c |3 ++-
> 1 files changed, 2 in
0x2d0 [radeon]
>
> The big WARN() has nothing to do with the culprit - which is that
> the firmware was not loaded. So lets remove the WARN() from the TTM DMA code.
>
> Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/ttm/ttm_page_allo
On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
> In some cases mem will be null in nouveau_vm_map_sg, resulting in a crash
> at drivers/gpu/drm/nouveau/nouveau_vm.c:84. It seems to be easy enough to
> reproduce, so I can test patches if needed.
>
> Martin
>
How do you trigge
Cheers,
Jerome
>From 84e7f3d46d2a4ac226343e195b806820accdf2fe Mon Sep 17 00:00:00 2001
From: Jerome Glisse
Date: Mon, 23 Jan 2012 11:52:15 -0500
Subject: [PATCH] drm/radeon: avoid deadlock if GPU lockup is detected in
ib_pool_get
If GPU lockup is detected in ib_pool get we are holding the ib_pool
mutex that w
2012/1/24 Rafał Miłecki :
> Hey,
>
> I want to do some RE-ing and I'm looking for libsegfault to trace Xorg
> driver ops. Unfortunately I can't find libsegfault at
> http://people.freedesktop.org/~glisse/ anymore.
>
> Can someone share this, please?
>
> --
> Rafał
You better of using valgrind. I a
On Sun, Jan 22, 2012 at 01:33:16PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2012 at 12:57:50AM +0100, Martin Nyhus wrote:
> > On Monday 16. January 2012 21:30:59 Jerome Glisse wrote:
> > > On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
> > >
On Tue, Jan 24, 2012 at 05:17:18PM -0500, alexdeuc...@gmail.com wrote:
> From: Marek Olšák
>
> v2: agd5f: add strmout CS checking, copy_dw register checking
>
> v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
> will incorrectly patch the command stream for certain regs.
>
> v4: a
On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs wrote:
> On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
>> On 01/25/2012 10:41 AM, Ben Skeggs wrote:
>> >
>> > My main concern is that we blindly and unnecessarily set up GPU bindings
>> > and
>> > end up with unnecessary code in TTM, and f
On Tue, Jan 24, 2012 at 7:12 PM, Martin Nyhus wrote:
> On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse
> wrote:
>> Can you please both test if attached patch fix it for you ?
>
> Thanks. It looks good too me, but it crashes a little later due to vma->node
> being inva
On Wed, Jan 25, 2012 at 1:21 PM, Thomas Hellstrom wrote:
> On 01/25/2012 07:12 PM, Dave Airlie wrote:
>>
>> On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom
>> wrote:
>>>
>>> On 01/25/2012 04:37 PM, Jerome Glisse wrote:
>>>>
>>&g
> dc97b3409a790d2a21aac6e5cdb99558b5944119 is the first bad commit
> commit dc97b3409a790d2a21aac6e5cdb99558b5944119
> Author: Jerome Glisse
> Date: Fri Nov 18 11:47:03 2011 -0500
>
> Hmm?
>
> Linus
Ben Skeggs patch fix this issue.
Cheers,
Jerome
_
On Tue, Jan 24, 2012 at 7:16 PM, Alexandre Demers
wrote:
> I suppose I can stop bisecting kernel about this possible lock and close
> the bug then?
>
> --
> Alexandre Demers
Yes, unless the bug is something else as the error message could be
ignored and it wasn't
harmfull. ie even without that pa
On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel Dänzer wrote:
> On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
> > Userspace currently busywaits for fences to complete; on my workload, this
> > busywait consumes 10% of the available CPU time.
> >
> > Provide an ioctl so that userspac
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
>
>
> Some comments below.
>
> > + struct radeon_device *rdev = dev->dev_private;
> > + struct drm_gem_object *gobj;
> > + struct radeon_bo *robj;
> > + void *buffer_data;
> > + uint32_t *fence_data;
> > + int r = 0;
> > +
On Tue, Jan 31, 2012 at 02:13:00PM -0500, Alex Deucher wrote:
> On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse wrote:
> > On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
> >>
> >>
> >> Some comments below.
> >>
> >&g
Hi,
I plan to do a libdrm release on friday because ddx/mesa work i have
been doing depends on thing i added to libdrm/radeon. Is anybody else
working on some libdrm related code that would need a release ?
I can hold off the release a bit but i would really like not to.
Cheers,
Jerome
_
On Thu, Feb 02, 2012 at 07:13:21PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 01, 2012 at 07:10:10PM -0500, Jerome Glisse wrote:
> > Hi,
> >
> > I plan to do a libdrm release on friday because ddx/mesa work i have
> > been doing depends on thing i added to lib
On Thu, Feb 02, 2012 at 07:13:21PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 01, 2012 at 07:10:10PM -0500, Jerome Glisse wrote:
> > Hi,
> >
> > I plan to do a libdrm release on friday because ddx/mesa work i have
> > been doing depends on thing i added to lib
g gen7 packets in use.
Eugeni Dodonov (1):
intel: query for LLC support
Jeremy Huddleston (1):
Don't build Intel DRM if $CHOST is not i?86-* or x86_64-*
Jerome Glisse (5):
radeon: add surface allocator helper v10
radeon: surface fix macro -> micro tile fallback
On Fri, Feb 10, 2012 at 01:35:21PM -0500, j.gli...@gmail.com wrote:
> From: Jerome Glisse
>
> For 6xx+. Required for mesa to use htile support for HiZ/HiS.
> Userspace will check radeon version 2.14 with is bumped either
> by tiling patch or stream out patch.
>
> Signe
On Tue, Feb 14, 2012 at 10:38:11AM +0300, Dan Carpenter wrote:
> We store stuff in texdw[7] so this array needs to have 8 elements.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Jerome Glisse
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/rad
On Wed, Feb 15, 2012 at 05:32:35PM +0800, Chen Jie wrote:
> Hi,
>
> Status update about the problem 'Occasionally "GPU lockup" after
> resuming from suspend.'
>
> First, this could happen when system returns from a STR(suspend to
> ram) or STD(suspend to disk, aka hibernation).
> When returns fro
On Thu, Feb 16, 2012 at 05:21:10PM +0800, Chen Jie wrote:
> Hi,
>
> 在 2012年2月15日 下午11:53，Jerome Glisse 写道：
> > To me it looks like the CP is trying to fetch memory but the
> > GPU memory controller fail to fullfill cp request. Did you
> > check the PCI configuration
2012/2/23 Christian König
> So don't confuse devs by doing so.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/r600.c | 15 +--
> 1 files changed, 1 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> in
2012/2/23 Mathias Fröhlich
>
> Christian,
>
> On Thursday, February 23, 2012 15:18:42 Christian König wrote:
> > The function radeon_bo_list_validate can cause a
> > bo to move, resulting in a different sync_obj
> > and a dependency to wait for this move to finish.
> >
> > Signed-off-by: Christia
On Thu, 2012-02-23 at 17:53 -0500, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Required for future functionality.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/r520.c|2 +-
> drivers/gpu/drm/rad
.c| 5 +-
> drivers/gpu/drm/radeon/rv770.c|4 +-
> 22 files changed, 1236 insertions(+), 737 deletions(-)
>
All patch:
Reviewed-by: Jerome Glisse
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 2012-02-23 at 15:18 +0100, Christian König wrote:
> Not all rings use PM4, so the cs_parser also needs to be per ring.
>
> Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon.h |4 +-
> drivers/gpu/drm/radeon/ra
Christian König
> > Reviewed-by: Alex Deucher
>
> For the series:
>
> Reviewed-by: Alex Deucher
Same
Reviewed-by: Jerome Glisse
>
> > ---
> > drivers/gpu/drm/radeon/radeon.h|1 -
> > drivers/gpu/drm/radeon/radeon_cs.c | 21 ++---
On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
> 在 2012年2月17日 下午5:27，Chen Jie 写道：
> >> One good way to test gart is to go over GPU gart table and write a
> >> dword using the GPU at end of each page something like 0xCAFEDEAD
> >> or somevalue that is unlikely to be already set. And then go ove
On Mon, 2012-02-27 at 10:44 +0800, Chen Jie wrote:
> Hi,
>
> For this occasional GPU lockup when returns from STR/STD, I find
> followings(when the problem happens):
>
> The value of SRBM_STATUS is whether 0x20002040 or 0x20003040.
> Which means:
> * HI_RQ_PENDING(There is a HI/BIF request pendin
_SQ_TEX_DIM_1D:
> case V_038000_SQ_TEX_DIM_2D:
I think if array field are properly initialized this shouldn't be an
issue. But anyway this patch is needed.
Reviewed-by: Jerome Glisse
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
of the
> function instead.
>
> Signed-off-by: Alex Deucher
> Cc: Jerome Glisse
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_gart.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gar
On Wed, 2012-02-29 at 12:49 +0800, che...@lemote.com wrote:
> > On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
> >> 在 2012年2月17日 下午5:27，Chen Jie 写道：
> >> >> One good way to test gart is to go over GPU gart table and write a
> >> >> dword using the GPU at end of each page something like 0xCAFED
On Thu, 2012-03-01 at 14:28 +0800, Aaron.Chen 陈俊杰 wrote:
> Hi,
>
>
>
> I’m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai
> Office. We have developed a kernel driver for all our graphics chips. We
> really want to know the way to submit a kernel driver to kernel.org. I ha
lled that frees all
> of the kdata and dpage information in the chunks array. So this
> information should not be freed in radeon_cs_parser_init as well.
>
> Signed-off-by: Julia Lawall
Reviewed-by: Jerome Glisse
>
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 16 +
On Sat, 2012-03-17 at 14:14 -0700, Linus Torvalds wrote:
> On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie wrote:
> >
> > I did however get a flashback in google to this:
> >
> > http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html
> >
> > Linus don't think we ever did work out
On Mon, 2012-03-19 at 23:11 +0800, Scott Fang wrote:
> In function ttm_tt_set_caching
> ,,,
>
> if (ttm->caching_state == tt_cached)
> drm_clflush_pages(ttm->pages, ttm->num_pages);
>
> for (i = 0; i < ttm->num_pages; ++i) {
> cur_page = ttm->pages[i];
> if (li
On Tue, 2012-03-20 at 17:18 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon.h | 32 ++
> drivers/gpu/drm/radeon/si.c | 1005
> +++
> drivers/gpu/drm/radeon/sid.h| 201 +
m/radeon/sid.h| 886 ++
> include/drm/drm_pciids.h| 54 +
> include/drm/radeon_drm.h|3 +
> 35 files changed, 7230 insertions(+), 144 deletions(-)
> create mode 100644 drivers/gpu/drm/radeon/si.c
> create mode 100644 driver
On Tue, 2012-03-20 at 17:18 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/Makefile |2 +-
> drivers/gpu/drm/radeon/radeon_asic.h |3 +
> drivers/gpu/drm/radeon/si.c | 486
>
On Tue, 2012-03-20 at 17:18 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Sets up the VM and adds support for the new VM ioctls.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/si.c | 328
> ++
> drivers/gpu/drm/radeon/si
k(KERN_ERR "got only %d of %d user
>> >>>> pages\n",
>> >>>> + n, n_pages);
>> >>>> + goto cleanup;
>> >>>> + }
>> >>>> + }
>> >>>> +
>> >>>> + *copy_vma = vb2_get_vma(vma);
>> >>>> + if (!*copy_vma) {
>> >>>> + printk(KERN_ERR "failed to copy vma\n");
>> >>>> + ret = -ENOMEM;
>> >>>> + goto cleanup;
>> >>>> + }
>> >>>
>> >>> Do we really need to make a copy of the VMA ? The only reason why we
>> >>> store a pointer to it is to check the flags in vb2_dc_put_userptr(). We
>> >>> could store the flags instead and avoid vb2_get_dma()/vb2_put_dma()
>> >>> calls altogether.
>> >>
>> >> I remember that there was a very good reason of copying this vma
>> >> structure.
>> >> You caught me on 'cargo-cult' programming.
>> >> I will do some reverse engineering and try to answer it soon.
>> >
>> > OK :-) I'm not copying the VMA in the OMAP3 ISP driver, which is why this
>> > caught my eyes. If you find the reason why copying it is needed, please
>> > add a comment to the code.
>>
>> The reason of copying vma was that 'struct vma' has no reference counters.
>> Therefore it could be deleted after mm lock is freed, ending with freeing
>> its all pages belonging to vma. To prevent it, a copy of vma is created.
>> Notice that inside vb2_get_vma the callback open is called for original
>> vma, preventing memory from being released. On vb2_put_vma the
>> complementary close is called.
>
> Feel free to prove me wrong, but I think get_user_pages() is enough to prevent
> the pages from being freed, even if the VMA is deleted.
>
> However, there's one subtle issue that we will need to deal with when we will
> implement cache management. It took me a lot of time to debug and fix it when
> I was working on the OMAP3 ISP driver, so I'll explain it in the hope that
> someone will find it later when dealing with the same problems :-)
>
> When a buffer is queued, the OMAP3 ISP driver cleans up the cache using the
> userspace mapping addresses (for USERPTR buffers). This might be a bad thing,
> but that's the way we currently implement that.
>
> A prior get_user_pages() call will make sure pages are not freed, but due to
> optimization in the lockless memory management algorithms the userspace
> mapping can disappear: the kernel might consider that a page can be freed,
> remove its userspace mapping, and then find out that the page is locked. It
> will then move on without restoring the userspace mapping, which will be
> restored when the next page fault occurs.
>
> When cleaning the cache using the userspace mapping addresses, any page for
> which the userspace mapping has been removed will trigger a page fault. The
> page fault handler (do_page_fault() in arm/arch/mm/fault.c) will try to
> read_lock mmap_sem. If it fails, it will check if the page fault occured in
> userspace context, or from a known exception location. As neither condition is
> true, it will panic.
>
> The solution I found to this issue was to lock the VMA. This ensured that the
> userspace mapping would stay in place. See isp_video_buffer_lock_vma() in
> drivers/media/video/omap3isp/ispqueue.c. You could use a similar approach here
> if you want to ensure that userspace mappings are not removed, but once again
> I don't think that's needed (until we get to cache handling) as
> get_user_pages() will ensure that the pages are not freed.
I think the proper solution is to not use any user allocated memory and always
use dma-buf. Some evil process thread might unlock the vma behind your back
and you back to the original issue.
The linux memory management is not designed to easily allow use of user
allocated memory by a device to do dma to/from it, at least not for the usecase
where dma operation might happen over long period of time.
I guess some VMA change might help but this might also be hurt full and i am
not familiar enough with the whole memory management to venture a guess on
what kind if implication there is.
Cheers,
Jerome Glisse
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Apr 17, 2012 at 4:19 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> If AGP is placed in the middle, the size_af is off-by-one, it results
> in VRAM being placed at 0x7fff instead of 0x800.
>
> Reported-by: russiane39 on #radeon
>
> Signed-off-by: Dave Airl
On Thu, Apr 19, 2012 at 4:40 PM, Thierry Reding
wrote:
> * Dave Airlie wrote:
>> On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding
>> wrote:
>> > Before posting the next round of patches I wanted to clarify whether we
>> > need
>> > to take the Tegra driver through staging. Lucas brought this up r
2012/4/19 Christian König :
> This includes mostly fixes for multi ring lockups and GPU resets, but it
> should general improve the behavior of the kernel mode driver in case
> something goes badly wrong.
>
> On the other hand it completely rewrites the IB pool and semaphore handling,
> so I thi
2012/4/21 Christian König :
> Interesting, I'm pretty sure that I haven't touched the locking order of the
> cs_mutex vs. vm_mutex.
>
> Maybe it is just some kind of side effect, going to locking into it anyway.
>
> Christian.
>
It's the using, init path take lock in different order than cs path
2012/4/21 Christian König :
> On 20.04.2012 01:47, Jerome Glisse wrote:
>>
>> 2012/4/19 Christian König:
>>>
>>> This includes mostly fixes for multi ring lockups and GPU resets, but it
>>> should general improve the behavior of the kernel mode dri
2012/4/21 Christian König :
> On 21.04.2012 16:08, Jerome Glisse wrote:
>>
>> 2012/4/21 Christian König:
>>>
>>> Interesting, I'm pretty sure that I haven't touched the locking order of
>>> the
>>> cs_mutex vs. vm_mutex.
>>>
&
2012/4/21 Christian König :
> On 21.04.2012 17:57, Dave Airlie wrote:
>>
>> 2012/4/21 Jerome Glisse:
>>>
>>> 2012/4/21 Christian König:
>>>>
>>>> On 21.04.2012 16:08, Jerome Glisse wrote:
>>>>>
>>>>> 2012/4/21
On Mon, Apr 23, 2012 at 8:26 AM, Treeve Jelbert wrote:
> On Monday 23 April 2012 12:18:55 Michel Dänzer wrote:
>> On Mon, 2012-04-23 at 11:18 +0200, Treeve Jelbert wrote:
>> > Linux-3.3.3
>> >
>> > $ dmesg|grep drm
>> > [drm] Initialized drm 1.1.0 20060810
>> > [drm] radeon defaulting to userspace
On Wed, Apr 25, 2012 at 9:46 AM, Alex Deucher wrote:
> 2012/4/25 Dave Airlie :
>> 2012/4/25 Christian König :
>>> On 21.04.2012 16:14, Jerome Glisse wrote:
>>>>
>>>> 2012/4/21 Christian König:
>>>>>
>>>>> On 20.04.
On Wed, Apr 25, 2012 at 9:40 AM, Alex Deucher wrote:
> On Wed, Apr 25, 2012 at 9:19 AM, Michel Dänzer wrote:
>> On Mit, 2012-04-25 at 14:46 +0200, Christian König wrote:
>>> Aligning offset can make it bigger than tmp->offset
>>> leading to an overrun bug in the following subtraction.
>>>
>>> Sig
2012/4/25 Christian König :
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 1c43
2012/4/25 Christian König :
> On 25.04.2012 16:36, Jerome Glisse wrote:
>>
>> NAK i would rather have a full dump as i described. I can do a patch
>> for that if you want.
>>
> I don't stick with those files neither, just wanted to restore the same
> fu
On Wed, Apr 25, 2012 at 5:53 PM, Luca Tettamanti wrote:
> Hi Jerome,
>
> On Wed, Apr 25, 2012 at 9:03 PM, wrote:
>> From: Jerome Glisse
>>
>> This add a command buffer dumping facilities, that will
>> dump command buffer and all associated bo that most lik
2012/4/26 David Airlie :
>
>
> - Original Message -
>> From: "Christian König"
>> To: "j glisse"
>> Cc: "Jerome Glisse" , dri-devel@lists.freedesktop.org
>> Sent: Thursday, 26 April, 2012 10:11:12 AM
>> Subject: Re:
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
> Hi Dave,
>
> if nobody has a last moment concern please include the following patches in
> drm-next.
>
> Except for some minor fixes they have already been on the list for quite some
> time,
> but I intentional left out the debugfs relat
On Mon, Apr 30, 2012 at 11:12 AM, Jerome Glisse wrote:
> On Mon, Apr 30, 2012 at 10:50 AM, Christian König
> wrote:
>> Hi Dave,
>>
>> if nobody has a last moment concern please include the following patches in
>> drm-next.
>>
>> Except for some minor fi
return 0;
> - }
> -
> - rdev->ib_pool.sa_manager = tmp;
> - INIT_LIST_HEAD(&rdev->ib_pool.sa_manager.sa_bo);
> for (i = 0; i < RADEON_IB_POOL_SIZE; i++) {
> rdev->ib_pool.ibs[i].fence = NULL;
>
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
> Make the suballocator self containing to locking.
>
> v2: split the bugfix into a seperate patch.
>
> Signed-off-by: Christian König
I would say NAK but i don't have better solution yet to the issue.
Idea is that cs mutex protect the SA,
On Mon, Apr 30, 2012 at 11:37 AM, Christian König
wrote:
> On 30.04.2012 17:12, Jerome Glisse wrote:
>>
>> On Mon, Apr 30, 2012 at 11:12 AM, Jerome Glisse
>> wrote:
>>>
>>> On Mon, Apr 30, 2012 at 10:50 AM, Christian König
>>> wrote:
>>
On Tue, May 1, 2012 at 8:22 AM, Christian König wrote:
> On 30.04.2012 17:45, Jerome Glisse wrote:
>>
>> On Mon, Apr 30, 2012 at 10:50 AM, Christian König
>> wrote:
>>>
>>> With that in place clients are automatically blocking
>>> until their
can be found at :
> http://people.freedesktop.org/~glisse/reset/
>
> Cheers,
> Jerome Glisse
>
Of course i sent the wrong patch 9 & 10 correct one:
http://people.freedesktop.org/~glisse/reset/0009-drm-radeon-improve-sa-allocator.patch
http://people.freedesktop.org/~glisse/reset/0010-drm-radeon-sa-al
On Wed, May 2, 2012 at 12:00 AM, wrote:
> Ok so i reread stuff and the :
> drm/radeon: add general purpose fence signaled callback
> is a big NAK actually. It change the paradigm. Moving most of
> the handling into the irq process which is something i am intimatly
> convinced we should avoid.
>
>
On Wed, May 2, 2012 at 7:25 AM, Christian König wrote:
> On 02.05.2012 12:32, Dave Airlie wrote:
>>
>> On Wed, May 2, 2012 at 10:04 AM, Christian König
>> wrote:
>>>
>>> On 02.05.2012 06:04, Jerome Glisse wrote:
>>>>
>>>> On Wed
rk.
>
> Cheers,
> Christian.
>
I am ok with this 17 patchset, i just sent 3 patch on top of those 17 that
bring back some other of the previous cleanup.
So for the 17
Reviewed-by: Jerome Glisse
Cheers,
Jerome
___
dri-deve
On Thu, May 3, 2012 at 7:39 AM, Christian König wrote:
> On 03.05.2012 09:21, Michel Dänzer wrote:
>>
>> On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> This convert fence to use uint64_t se
On Thu, May 3, 2012 at 4:19 AM, Christian König wrote:
> On 02.05.2012 18:01, Jerome Glisse wrote:
>>
>> On Wed, May 2, 2012 at 9:11 AM, Christian König
>> wrote:
>>>
>>> Hi Dave,
>>>
>>> there still seems to be the need for some furth
On Thu, May 3, 2012 at 12:29 PM, Alex Deucher wrote:
> On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse wrote:
>> On Thu, May 3, 2012 at 7:39 AM, Christian König
>> wrote:
>>> On 03.05.2012 09:21, Michel Dänzer wrote:
>>>>
>>>> On Mit, 201
On Thu, May 3, 2012 at 12:39 PM, Christian König
wrote:
> On 03.05.2012 18:32, Jerome Glisse wrote:
>>
>> On Thu, May 3, 2012 at 4:19 AM, Christian König
>> wrote:
>>>
>>> On 02.05.2012 18:01, Jerome Glisse wrote:
>>>>
>>>&
On Thu, May 3, 2012 at 1:20 PM, Alex Deucher wrote:
> 2012/5/3 Jerome Glisse :
>> On Thu, May 3, 2012 at 12:39 PM, Christian König
>> wrote:
>>> On 03.05.2012 18:32, Jerome Glisse wrote:
>>>>
>>>> On Thu, May 3, 2012 at 4:19 AM, Christian Kö
On Thu, May 3, 2012 at 1:28 PM, Christian König wrote:
> On 03.05.2012 19:20, Alex Deucher wrote:
>>
>> 2012/5/3 Jerome Glisse:
>>>
>>> On Thu, May 3, 2012 at 12:39 PM, Christian König
>>> wrote:
>>>>
>>>> On 03.05.2012 18:3
On Thu, May 3, 2012 at 12:34 PM, Jerome Glisse wrote:
> On Thu, May 3, 2012 at 12:29 PM, Alex Deucher wrote:
>> On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse wrote:
>>> On Thu, May 3, 2012 at 7:39 AM, Christian König
>>> wrote:
>>>> On 03.05.2012 09:
On Thu, May 3, 2012 at 5:04 PM, Alex Deucher wrote:
> On Thu, May 3, 2012 at 4:46 PM, Jerome Glisse wrote:
>> On Thu, May 3, 2012 at 12:34 PM, Jerome Glisse wrote:
>>> On Thu, May 3, 2012 at 12:29 PM, Alex Deucher wrote:
>>>> On Thu, May 3, 2012 at 11:56 AM, Jero
On Fri, May 4, 2012 at 10:44 AM, Michel Dänzer wrote:
> On Fre, 2012-05-04 at 10:28 -0400, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> It seems imac pannel doesn't like whe we change the hot plug setup
>> and then refuse to work. This should fix
On Mon, May 7, 2012 at 7:42 AM, Christian König wrote:
> Hi Jerome & everybody on the list,
>
> this gathers together every patch we developed over the last week or so and
> which is not already in drm-next.
>
> I've run quite some tests with them yesterday and today and as far as I can
> see hamm
On Mon, May 7, 2012 at 7:42 AM, Christian König wrote:
> From: Jerome Glisse
>
> This convert fence to use uint64_t sequence number intention is
> to use the fact that uin64_t is big enough that we don't need to
> care about wrap around.
>
> Tested with and without wri
f those fence to complete.
>
> v2: We need to be able to let hole point to the list_head, otherwise
> try free will never free the first allocation of the list. Also
> stop calling radeon_fence_signalled more than necessary.
>
> Signed-off-by: Christian König
> Signed-off-b
On Mon, May 7, 2012 at 11:04 AM, Christian König
wrote:
> On 07.05.2012 16:39, Jerome Glisse wrote:
>>
>> On Mon, May 7, 2012 at 7:42 AM, Christian König
>> wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> This convert fence to use uint64_t sequ
On Mon, May 7, 2012 at 10:34 AM, Jerome Glisse wrote:
> On Mon, May 7, 2012 at 7:42 AM, Christian König
> wrote:
>> Hi Jerome & everybody on the list,
>>
>> this gathers together every patch we developed over the last week or so and
>> which is not already in d
> On 07.05.2012 17:23, Jerome Glisse wrote:
>>
>> On Mon, May 7, 2012 at 7:42 AM, Christian König
>> wrote:
>>>
>>> A startover with a new idea for a multiple ring allocator.
>>> Should perform as well as a normal ring allocator as long
>>>
On Mon, May 7, 2012 at 3:38 AM, Michel Dänzer wrote:
> On Son, 2012-05-06 at 18:29 +0200, Rafał Miłecki wrote:
>> 2012/5/6 Dave Airlie :
>> > On Sun, May 6, 2012 at 5:19 PM, Rafał Miłecki wrote:
>> >> 2012/5/6 Rafał Miłecki :
>> >>> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
>> >>> b/driver
On Sat, May 5, 2012 at 6:22 AM, Dave Airlie wrote:
> On Sat, May 5, 2012 at 11:19 AM, wrote:
>> Hi Dave,
>>
>> 2012. 4. 25. 오후 7:15 Dave Airlie 작성:
>>
>>> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote:
this feature could be used to use memory region allocated by malloc() in
user
>
On Mon, May 7, 2012 at 1:59 PM, Jerome Glisse wrote:
>> On 07.05.2012 17:23, Jerome Glisse wrote:
>>>
>>> On Mon, May 7, 2012 at 7:42 AM, Christian König
>>> wrote:
>>>>
>>>> A startover with a new idea for a multiple ring allocator.
>&
On Mon, May 7, 2012 at 4:38 PM, Christian König wrote:
> On 07.05.2012 20:52, Jerome Glisse wrote:
>>
>> On Mon, May 7, 2012 at 1:59 PM, Jerome Glisse wrote:
>>>>
>>>> On 07.05.2012 17:23, Jerome Glisse wrote:
>>>>>
>>>>&g
On Tue, May 8, 2012 at 6:23 AM, Christian König wrote:
> On 07.05.2012 23:28, Jerome Glisse wrote:
>>
>> On Mon, May 7, 2012 at 4:38 PM, Christian König
>> wrote:
>>>
>>> On 07.05.2012 20:52, Jerome Glisse wrote:
>>>>
>>>
On Tue, May 8, 2012 at 3:59 AM, Inki Dae wrote:
> Hi Jerome,
>
>> -Original Message-----
>> From: Jerome Glisse [mailto:j.gli...@gmail.com]
>> Sent: Tuesday, May 08, 2012 3:18 AM
>> To: Dave Airlie
>> Cc: daei...@gmail.com; Inki Dae; kyungmin.p...@samsung
On Wed, May 9, 2012 at 9:40 AM, Alex Deucher wrote:
> On Fri, May 4, 2012 at 11:06 AM, wrote:
>> From: Jerome Glisse
>>
>> It seems imac pannel doesn't like whe we change the hot plug setup
>> and then refuse to work. This help but doesn't fully fix:
>&g
On Wed, May 9, 2012 at 9:34 AM, Christian König wrote:
> Hi Dave & Jerome and everybody on the list,
>
> I can't find any more bugs and also I'm out of things to test, so I really
> hope that this is the last incarnation of this patchset, and if Jerome is
> ok with it it should now be included int
On Wed, May 9, 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. and to guarantee the pages to user space not to be
> swapped out, the VMAs within the user space would be locked and then unlocked
> when the pages are r
xpects argument of type ‘long unsigned int’, but argument 3 has
> type ‘long long int’ [-Wformat]
>
> Signed-off-by: Dave Airlie
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_fence.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
On Wed, May 9, 2012 at 10:45 AM, Jerome Glisse wrote:
> On Wed, May 9, 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. and to guarantee the pages to user space not to be
>> swapped out, the
On Wed, May 9, 2012 at 10:44 PM, Inki Dae wrote:
> Hi Jerome,
>
> Thank you again.
>
>> -Original Message-----
>> From: Jerome Glisse [mailto:j.gli...@gmail.com]
>> Sent: Thursday, May 10, 2012 3:33 AM
>> To: Inki Dae
>> Cc: airl...@linux.ie; dri-
On Thu, May 10, 2012 at 11:31 AM, Daniel Vetter wrote:
> On Thu, May 10, 2012 at 11:05:07AM -0400, Jerome Glisse wrote:
>> On Wed, May 9, 2012 at 10:44 PM, Inki Dae wrote:
>> > Hi Jerome,
>> >
>> > Thank you again.
>> >
>> >> -Orig
501 - 600 of 1443 matches
Mail list logo
