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 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,
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 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
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
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
>>
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 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
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/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
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
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
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.
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
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
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
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 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 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
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
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
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 :
> 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 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 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 :
> 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/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
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
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
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 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
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
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, 2012-03-20 at 17:18 -0400, alexdeucher at 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
On Tue, 2012-03-20 at 17:18 -0400, alexdeucher at 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
> +
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, alexdeucher at 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| 20
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
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
>
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/radeon.h | 32 ++
> drivers/gpu/drm/radeon/si.c | 1005
> +++
> drivers/gpu/drm/radeon/sid.h| 201 +
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 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
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 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 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
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 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
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
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 0xCA
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, 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
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
_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
_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
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
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
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
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 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
.c| 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 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
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 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
.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 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
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
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
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
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
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
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 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 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 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 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 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
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
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 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
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
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
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 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 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 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 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 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 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 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 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
> ?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
> 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 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
901 - 1000 of 1443 matches
Mail list logo
