On Thu, Dec 6, 2012 at 5:52 AM, Maarten Lankhorst
wrote:
> Op 06-12-12 02:36, Jerome Glisse schreef:
>> On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst
>> wrote:
>>> This requires re-use of the seqno, which increases fairness slightly.
>>> Instead of spinni
On Thu, Nov 29, 2012 at 10:35 AM, wrote:
> From: Jerome Glisse
>
> The bo creation placement is where the bo will be. Instead of trying
> to move bo at each command stream let this work to another worker
> thread that will use more advance heuristic.
>
> Signed-off-by:
On Wed, Dec 12, 2012 at 8:07 AM, Daniel Vetter
wrote:
> Noticed while reviewing the fence locking in the radone pageflip
> handler.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On Fri, Dec 14, 2012 at 3:13 PM, Christian K?nig
wrote:
> On 14.12.2012 18:39, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> After lockup we need to resume fence to last sync sequence and not
>> last received sequence so that all thread waiting o
On Mon, Dec 17, 2012 at 4:11 AM, Christian K?nig
wrote:
> On 14.12.2012 21:33, Jerome Glisse wrote:
>>
>> On Fri, Dec 14, 2012 at 3:13 PM, Christian K?nig
>> wrote:
>>>
>>> On 14.12.2012 18:39, j.glisse at gmail.com wrote:
>>>>
>>>>
-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/ever
On Thu, Oct 27, 2011 at 12:12:09PM -0400, Alex Deucher wrote:
> On Wed, Oct 26, 2011 at 11:41 AM, wrote:
> > From: Jerome Glisse
> >
> > Cayman seems to be particularly sensitive to read cache returning
> > old data after bind/unbind to GTT. Flush read cache for GTT
them could get a bit painful. So I would like to see most of the
> stuff included into drm-next, even if we don't make use of the new
> functionality right now.
>
> Comments welcome,
> Christian.
So for all patches except the interface change see below
Reviewed-by: Jerome Glisse
On Wed, Oct 19, 2011 at 06:19:29PM -0400, Konrad Rzeszutek Wilk wrote:
> In TTM world the pages for the graphic drivers are kept in three different
> pools: write combined, uncached, and cached (write-back). When the pages
> are used by the graphic driver the graphic adapter via its built in MMU
>
unbind/destroy where bind is
responsible to allocate or not a ttm_tt and pages that goes
along with it. I will try to sketch up patches for all this
in next few days.
Reviewed-by: Jerome Glisse
Cheers,
Jerome Glisse
On Mon, Sep 12, 2011 at 9:57 AM, Ilija Hadzic
wrote:
>
> Related to this question, one thing that I noticed is that in some
> instances, I would not see any interrupts at all. Instead, all signaled
> fences would be taken care of next time somebody waits on one them (through
> radeon_fence_wait,
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
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
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/
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
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.
>>>
>>>
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
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
> functio
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 at
>> lists.freedesktop.org
>> Sent: Thursday, 26 April, 2012 10:11:12 AM
>>
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
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 mino
; - ? ? ? ? ? ? ? radeon_mutex_unlock(>ib_pool.mutex);
> - ? ? ? ? ? ? ? radeon_sa_bo_manager_fini(rdev, );
> - ? ? ? ? ? ? ? return 0;
> - ? ? ? }
> -
> - ? ? ? rdev->ib_pool.sa_manager = tmp;
> - ? ? ? INIT_LIST_HEAD(>ib_pool.sa_manager.sa_bo);
> ? ? ? ?for (i = 0;
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
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 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.glisse at gmail.com wrote:
>> From: Jerome Glisse
>>
>> Virtual address need to be fenced to know when we can safely remove it.
>> This patch also properly clea
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.glisse at gmail.com wrote:
>> >> From: Jerome
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.glisse at gmail.com wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> Virtual address need to be fenced to know when we
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
7 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
rade
On Fri, Feb 10, 2012 at 01:35:21PM -0500, j.glisse at 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
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
>
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:
On Thu, 2012-02-23 at 17:53 -0500, alexdeucher at 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
|5 +-
> drivers/gpu/drm/radeon/rv770.c|4 +-
> 22 files changed, 1236 insertions(+), 737 deletions(-)
>
All patch:
Reviewed-by: Jerome Glisse
Cheers,
Jerome
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
by: 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
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
M_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
t entry at the end 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/rad
On Wed, 2012-02-29 at 12:49 +0800, chenhc at 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
On Fri, Dec 23, 2011 at 01:19:43AM +, James Simmons wrote:
>
> > > Hi!
> > >
> > > ? ? ? ?I updated the openchrome tree and while testing on the AGP system
> > > discovered some interesting problems with the new TTM changes. The
> > > problems center around the ttm_tt_[un]populate which I
ttm tt rework modified the way we allocate and populate the
ttm_tt structure, the AGP side was missing some bit to properly
work. Fix those and fix radeon and nouveau AGP support.
Tested on radeon only so far.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13
On Wed, Jan 4, 2012 at 10:36 AM, James Simmons
wrote:
>
>> Attached is patch to fix this, so sorry about that, i must have lost my
>> agp change along the way when working on the patchset. This patch is not
>> extensively tested, i will do more testing tomorrow on more gpu, might
>> even found
On Wed, Jan 4, 2012 at 11:04 AM, James Simmons
wrote:
>
>> >> Attached is patch to fix this, so sorry about that, i must have lost my
>> >> agp change along the way when working on the patchset. This patch is not
>> >> extensively tested, i will do more testing tomorrow on more gpu, might
>> >>
On Wed, Jan 04, 2012 at 04:35:16PM -0500, Konrad Rzeszutek Wilk wrote:
> This reverts commit 5c2680ddbe14b24771d24841dd66881f90d3d740 otherwise
> when we unbind the device we get this:
> sh-4.1# echo ":00:0d.0" > unbind
> BUG: unable to handle kernel NULL pointer dereference at
On Tue, Dec 13, 2011 at 11:40:31AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> > On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> > >On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> > >
On Thu, Jan 5, 2012 at 4:48 PM, Konrad Rzeszutek Wilk
wrote:
> On Thu, Jan 05, 2012 at 01:31:55PM -0500, j.glisse at gmail.com wrote:
>> From: Jerome Glisse
>>
>> ttm might call the move notify with null new mem placement,
>> properly handle this case inside nouveau mo
On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
wrote:
> On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
>> > On Thu, 2012-01-05 at 13:31 -0500, j.glisse at gmail.com wrote:
>>
On Fri, Jan 06, 2012 at 11:53:35AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 11:51:03AM -0500, Jerome Glisse wrote:
> > On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
> > wrote:
> > > On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek W
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 724b41a..326b64a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++
On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > Still having difficulty to reproduce can you reproduce with the attached
> > printk debuging patch and provide the log (only few printk preceding the
> > oops or segfault are interesting).
>
>
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
>
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
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 helpers
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
On Thu, Jan 12, 2012 at 03:42:37PM -0500, alexdeucher at 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
On Sat, Jan 21, 2012 at 08:03:37PM +0100, Torsten Kaiser wrote:
> After updating to kernel 3.3-rc1 I have experienced a lockup of my GPU.
> I left my KDE desktop running until the screensaver turned off the
> monitors. But on key presses it would not turn back on. Ctrl+Alt+F1 to
> switch to
the radeon_mutex_lock helper.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 84
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_ring.c | 24 +-
3 files changed, 55 insertions(+), 55 deletions
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
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:
> &g
On Tue, Jan 24, 2012 at 05:17:18PM -0500, alexdeucher at 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.
>
>
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
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
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
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
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,
>> >>
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:
>>>
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:
>>>
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.glisse at 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 trigg
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.glisse at gmail.com wrote:
>>>>
>>>>
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 a
>> 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
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 +++
>
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
>
> Rev
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
> ---
>
901 - 1000 of 1383 matches
Mail list logo
