se 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-by:
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 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
>> >>>
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.glisse at gmail.com]
>> Sent: Tuesday, May 08, 2012 3:18 AM
>> To: Dave Airlie
>> Cc: daeinki at gmail.com; Inki Dae; kyungmi
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:
>> https:/
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
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
? expects 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.glisse at gmail.com]
>> Sent: Thursday, May 10, 2012 3:33 AM
>> To: Inki Dae
>> Cc: airlied at li
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.
>> >
>> >> -Origina
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
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 -
>
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
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
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
On Tue, May 15, 2012 at 12:33 AM, Inki Dae wrote:
> Hi Jerome,
>
>> -Original Message-----
>> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>> Sent: Tuesday, May 15, 2012 4:27 AM
>> To: Inki Dae
>> Cc: airlied at linux.ie; dri-devel at lists.freede
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
d 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).
>
> Bump. ?Any takers?
2: make 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
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
>>>
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
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
t;
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> Cc: stable at 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
&
k_irqsave(>irq.sw_lock, irqflags);
>>> + ? ? ? spin_lock_irqsave(>irq.lock, irqflags);
>>> ? ? ? ?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] = false;
>>> ? ? ? ? ? ? ? ?radeon_irq_set(rdev);
>>> ? ? ? ?}
>>> - ? ? ? spin_unlock_irqrestore(>irq.sw_lock, irqflags);
>>> + ? ? ? spin_unlock_irqrestore(>irq.lock, irqflags);
>>> ?}
>>>
>>> ?void radeon_irq_kms_pflip_irq_get(struct radeon_device *rdev, int crtc)
>>> @@ -245,12 +253,12 @@ void radeon_irq_kms_pflip_irq_get(struct
>>> radeon_device *rdev, int crtc)
>>> ? ? ? ?if (crtc < 0 || crtc >= rdev->num_crtc)
>>> ? ? ? ? ? ? ? ?return;
>>>
>>> - ? ? ? spin_lock_irqsave(>irq.pflip_lock[crtc], irqflags);
>>> + ? ? ? spin_lock_irqsave(>irq.lock, irqflags);
>>> ? ? ? ?if (rdev->ddev->irq_enabled && (++rdev->irq.pflip_refcount[crtc] ==
>>> 1)) {
>>> ? ? ? ? ? ? ? ?rdev->irq.pflip[crtc] = true;
>>> ? ? ? ? ? ? ? ?radeon_irq_set(rdev);
>>> ? ? ? ?}
>>> - ? ? ? spin_unlock_irqrestore(>irq.pflip_lock[crtc], irqflags);
>>> + ? ? ? spin_unlock_irqrestore(>irq.lock, irqflags);
>>> ?}
>>>
>>> ?void radeon_irq_kms_pflip_irq_put(struct radeon_device *rdev, int crtc)
>>> @@ -260,12 +268,52 @@ void radeon_irq_kms_pflip_irq_put(struct
>>> radeon_device *rdev, int crtc)
>>> ? ? ? ?if (crtc < 0 || crtc >= rdev->num_crtc)
>>> ? ? ? ? ? ? ? ?return;
>>>
>>> - ? ? ? spin_lock_irqsave(>irq.pflip_lock[crtc], irqflags);
>>> + ? ? ? spin_lock_irqsave(>irq.lock, irqflags);
>>> ? ? ? ?BUG_ON(rdev->ddev->irq_enabled && rdev->irq.pflip_refcount[crtc] <=
>>> 0);
>>> ? ? ? ?if (rdev->ddev->irq_enabled && (--rdev->irq.pflip_refcount[crtc] ==
>>> 0)) {
>>> ? ? ? ? ? ? ? ?rdev->irq.pflip[crtc] = false;
>>> ? ? ? ? ? ? ? ?radeon_irq_set(rdev);
>>> ? ? ? ?}
>>> - ? ? ? spin_unlock_irqrestore(>irq.pflip_lock[crtc], irqflags);
>>> + ? ? ? spin_unlock_irqrestore(>irq.lock, irqflags);
>>> +}
>>> +
>>> +void radeon_irq_kms_enable_afmt(struct radeon_device *rdev, int block)
>>> +{
>>> + ? ? ? unsigned long irqflags;
>>> +
>>> + ? ? ? spin_lock_irqsave(>irq.lock, irqflags);
>>> + ? ? ? rdev->irq.afmt[block] = true;
>>> + ? ? ? radeon_irq_set(rdev);
>>> + ? ? ? spin_unlock_irqrestore(>irq.lock, irqflags);
>>> +
>>> +}
>>> +
>>> +void radeon_irq_kms_disable_afmt(struct radeon_device *rdev, int block)
>>> +{
>>> + ? ? ? unsigned long irqflags;
>>> +
>>> + ? ? ? spin_lock_irqsave(>irq.lock, irqflags);
>>> + ? ? ? rdev->irq.afmt[block] = false;
>>> + ? ? ? radeon_irq_set(rdev);
>>> + ? ? ? spin_unlock_irqrestore(>irq.lock, irqflags);
>>> ?}
>>>
>>
>> Should probably also add radeon_irq_kms_[en|dis]able_hpd() function
>> and call replaced the calls to *_irq_set() in the *_hpd_init() and
>> *_hpd_fini() callbacks for display hotplug.
>
> See attached follow on patch.
>
> Alex
Looks good
Reviewed-by: Jerome Glisse
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 Fri, Nov 16, 2012 at 12:05:40PM -0800, Aaron Plattner wrote:
> At the suggestion of a few drm developers, I'm looking at abstracting the
> buffer
> sharing mechanism away from the individual drm drivers and treating it as a
> low-level interface that kernel subsystems use to communicate,
On Wed, Nov 28, 2012 at 11:27:27AM +0100, Christian K?nig wrote:
> On 27.11.2012 19:07, j.glisse at gmail.com wrote:
> >From: Jerome Glisse
> >
> >There is a rare case, that seems to only happen accross suspend/resume
> >cycle, where a bo is associated with several dif
On Wed, Nov 28, 2012 at 10:05 AM, wrote:
> From: Jerome Glisse
>
> It make no sense to preserve caching state especialy when
> moving from vram to system. It burden the page allocator to
> match the vram caching (often WC) which just burn CPU cycle
> for no good reaso
On Wed, Nov 28, 2012 at 5:18 PM, Thomas Hellstrom
wrote:
> On 11/28/2012 09:09 PM, Jerome Glisse wrote:
>>
>> On Wed, Nov 28, 2012 at 10:05 AM, wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> It make no sense to preserve caching state espec
On Wed, Nov 28, 2012 at 4:51 PM, Marek Ol??k wrote:
> I think the problem with Radeon/TTM is much deeper. Let me demonstrate
> it on the following example.
>
> Unigine Heaven needs about 385MB of space for static resources, that's
> only 75% of my 512MB card. Yet, TTM is not capable of getting
On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
wrote:
> On 11/28/2012 04:58 PM, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> This patch add a minimum residency time configurable for each memory
>> pool (VRAM, GTT, ...). Intention is to avoid h
On Wed, Nov 28, 2012 at 6:13 PM, Jerome Glisse wrote:
> On Wed, Nov 28, 2012 at 5:18 PM, Thomas Hellstrom
> wrote:
>> On 11/28/2012 09:09 PM, Jerome Glisse wrote:
>>>
>>> On Wed, Nov 28, 2012 at 10:05 AM, wrote:
>>>>
>>>> From: Jerome
On Wed, Nov 28, 2012 at 6:44 PM, Alan Swanson wrote:
> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
>> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
>> wrote:
>> > On 11/28/2012 04:58 PM, j.glisse at gmail.com wrote:
>> >>
>> >>
On Thu, Nov 29, 2012 at 09:41:34AM +0100, Thomas Hellstrom wrote:
> On 11/29/2012 12:24 AM, Jerome Glisse wrote:
> >On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
> >wrote:
> >>On 11/28/2012 04:58 PM, j.glisse at gmail.com wrote:
> >>>From: Jerome Glisse
On Thu, Nov 29, 2012 at 08:20:17PM +0100, Marek Ol??k wrote:
> On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom
> wrote:
> > On 11/28/2012 10:51 PM, Marek Ol??k wrote:
> >>
> >> I think the problem with Radeon/TTM is much deeper. Let me demonstrate
> >> it on the following example.
> >>
> >>
On Thu, Nov 29, 2012 at 8:57 PM, Marek Ol??k wrote:
> On Thu, Nov 29, 2012 at 4:35 PM, wrote:
>> So as a followup is 2 patch. The first one just stop trying to move
>> object at each cs ioctl i believe it could be included in 3.7 as it
>> improve performances (especialy with vram change from
On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom
wrote:
> On 11/29/2012 10:58 PM, Marek Ol??k wrote:
>>
>>
>> What I tried to point out was that the synchronization shouldn't be
>> needed, because the CPU shouldn't do anything with the contents of
>> evicted buffers. The GPU moves the buffers,
On Fri, Nov 30, 2012 at 12:08 PM, Thomas Hellstrom
wrote:
> On 11/30/2012 05:30 PM, Jerome Glisse wrote:
>>
>> On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom
>> wrote:
>>>
>>> On 11/29/2012 10:58 PM, Marek Ol??k wrote:
>>>>
>>>&
On Fri, Nov 30, 2012 at 06:43:36PM +0100, Thomas Hellstrom wrote:
> On 11/30/2012 06:18 PM, Jerome Glisse wrote:
> >On Fri, Nov 30, 2012 at 12:08 PM, Thomas Hellstrom
> >wrote:
> >>On 11/30/2012 05:30 PM, Jerome Glisse wrote:
> >>>On Fri, Nov 30, 2012 at 4
On Fri, Nov 30, 2012 at 07:31:04PM +0100, Thomas Hellstrom wrote:
> On 11/30/2012 07:07 PM, Jerome Glisse wrote:
> >On Fri, Nov 30, 2012 at 06:43:36PM +0100, Thomas Hellstrom wrote:
> >>On 11/30/2012 06:18 PM, Jerome Glisse wrote:
> >>>On Fri, Nov 30, 2012
On Fri, Nov 30, 2012 at 09:35:49PM +0100, Thomas Hellstrom wrote:
> On 11/30/2012 08:25 PM, Jerome Glisse wrote:
> >On Fri, Nov 30, 2012 at 07:31:04PM +0100, Thomas Hellstrom wrote:
> >>On 11/30/2012 07:07 PM, Jerome Glisse wrote:
> >>>On Fri, Nov 30, 2012 at 06:4
On Fri, Nov 30, 2012 at 10:36:01PM +0100, Thomas Hellstrom wrote:
> On 11/30/2012 10:07 PM, Jerome Glisse wrote:
> >On Fri, Nov 30, 2012 at 09:35:49PM +0100, Thomas Hellstrom wrote:
> >>On 11/30/2012 08:25 PM, Jerome Glisse wrote:
> >>>On Fri, Nov 30, 2012 at 07:3
y tested, but I think it should work.
>
> First is fixing radeon not to crash on calling move_notify from release_list.
> Second moves the memory cleanup to ttm_bo_cleanup_memtype_use, which is more
> readable and a more logical place to put it.
> Third cleans up how ttm_bo_cle
On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
> >Op 18-10-12 13:55, Thomas Hellstrom schreef:
> >>On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
> >>>Op 18-10-12 13:02, Thomas Hellstrom schreef:
> On 10/18/2012 10:37 AM,
On Mon, Apr 07, 2014 at 04:17:21PM -0400, Alex Deucher wrote:
> There is actually quite a bit of variance based on
> the asic.
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/dce6_afmt.c | 14 ++
> drivers/gpu/drm/radeon/radeon.h|
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:
n Mon, May 6, 2013 at 10:32 AM, Alex Deucher wrote:
> On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
> wrote:
>> On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:
>>
>>> This patch series does:
>>> 1. max_bus_speed is used to set the device to gen2 speeds
>>> 2. on
On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote:
> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski
> wrote:
>> Signed-off-by: Andy Lutomirski
>> ---
>>
>> This needs careful review. I don't really know what this code does, nor
>> do I have the hardware. (I don't understand AGP and the
On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski wrote:
> A fair number of drivers (mostly graphics) add write-combining MTRRs.
> Most ignore errors and most add the MTRR even on PAT systems which don't
> need to use MTRRs.
This comment is wrong, as i said we need MTRR on PAT system for VRAM.
On Mon, May 13, 2013 at 8:15 AM, Paul Menzel
wrote:
> Dear Linux graphics folks,
>
>
> using the ASRock E350M1 with coreboot [1] and plugging in an external
> AMD graphics card,
>
> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
> ATI Cedar PRO [Radeon HD 5450/6350]
On Tue, May 14, 2013 at 8:58 AM, Alex Deucher wrote:
> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski
> wrote:
>> Reviewed-by: Daniel Vetter
>> Signed-off-by: Andy Lutomirski
>
> Reviewed-by: Alex Deucher
I believe it will break something but we could deal with the fallout
once it
On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski wrote:
> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse wrote:
>> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher
>> wrote:
>>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski
>>> wrote:
>>>> Reviewe
On Wed, May 15, 2013 at 2:22 PM, Andy Lutomirski wrote:
> On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse wrote:
>> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski
>> wrote:
>>> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse
>>> wrote:
>>>>
Hi Dave,
Can you please apply attached patch, it needs the following commit that
is available in Linus git :
d82fb31abc46620b7c22758c75707069f2763646
Cheers,
Jerome
-- next part --
>From af30cf3e368733d69529c76a8db1df51ebdb42b5 Mon Sep 17 00:00:00 2001
From: Kleber
On Wed, Nov 06, 2013 at 05:48:55PM +, Robin H. Johnson wrote:
> On Wed, Nov 06, 2013 at 12:16:31PM -0500, Alex Deucher wrote:
> > On Wed, Nov 6, 2013 at 12:14 PM, Robin H. Johnson
> > wrote:
> > > (Resending to dri-devel because the first one didn't make it).
> > >
> > > I apologize for not
> Gentoo Linux: Developer, Trustee & Infrastructure Lead
> E-Mail : robbat2 at gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://li
-off-by: Thomas Hellstrom
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 30 +-
> 1 file changed, 13 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
&
On Thu, Nov 7, 2013 at 11:52 AM, Alex Deucher wrote:
> On Wed, Nov 6, 2013 at 7:12 PM, Robin H. Johnson
> wrote:
> > On Wed, Nov 06, 2013 at 05:37:11PM -0500, Jerome Glisse wrote:
> >> On Wed, Nov 06, 2013 at 05:48:55PM +, Robin H. Johnson wrote:
> >> > O
On Thu, Nov 7, 2013 at 2:59 PM, Robin H. Johnson wrote:
> On Thu, Nov 07, 2013 at 11:52:13AM -0500, Alex Deucher wrote:
> > >> Culprit likely d1e3b5564834ea24dee6b364a172365f64865fe5 try reverting
> that one.
> > > Confirmed as the buggy commit via bisect.
> > > Then reverted in 3.12 and 3.12
On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote:
> > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding
> > wrote:
> > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
> > >> On Mon, Nov 18, 2013 at 8:29 AM,
On Tue, Oct 23, 2012 at 5:59 PM, wrote:
> From: Alex Deucher
>
> Copy and paste typo in the apci rework.
>
> Fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=49351
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeo
On Mon, Oct 22, 2012 at 02:51:24PM +0200, Thomas Hellstrom wrote:
> A couple of fixes for theoretical races discovered during the lockdep
> discussions with Maarten Lankhorst
>
For the serie
Reviewed-by: Jerome Glisse
On Thu, Oct 25, 2012 at 04:02:25PM +0200, Thomas Hellstrom wrote:
> Hi,
>
> This commit
>
> From 949c4a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
> From: Ilija Hadzic
> Date: Tue, 15 May 2012 16:40:10 -0400
> Subject: [PATCH] drm: track dev_mapping in more robust and flexible
On Wed, Sep 5, 2012 at 12:39 AM, Brad Campbell wrote:
> On 28/07/12 04:32, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> It seems we can not update the crtc scanout address. After disabling
>> crtc, update to base address do not take effect aft
On Thu, Sep 6, 2012 at 7:48 AM, Christian K?nig
wrote:
> When a VM is used on more than one ring we need to
> sync to the last user.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_cs.c |2 +-
> 1 file chang
On Mon, Sep 10, 2012 at 8:02 AM, Christian K?nig
wrote:
> On 10.09.2012 13:12, Michel D?nzer wrote:
>>
>> On Mon, 2012-09-10 at 11:13 +0200, Christian K?nig wrote:
>>>
>>> Only increase the higher 32bits if we really detect a wrap around.
>>>
>>> Fixes:
>>>
On Mon, Sep 10, 2012 at 11:38 AM, Michel D?nzer wrote:
> On Mon, 2012-09-10 at 14:02 +0200, Christian K?nig wrote:
>> On 10.09.2012 13:12, Michel D?nzer wrote:
>> > On Mon, 2012-09-10 at 11:13 +0200, Christian K?nig wrote:
>> >> Only increase the higher 32bits if we really detect a wrap around.
On Mon, Sep 10, 2012 at 11:52 AM, Jerome Glisse wrote:
> On Mon, Sep 10, 2012 at 11:38 AM, Michel D?nzer wrote:
>> On Mon, 2012-09-10 at 14:02 +0200, Christian K?nig wrote:
>>> On 10.09.2012 13:12, Michel D?nzer wrote:
>>> > On Mon, 2012-09-10 at 11:13 +0200, Chri
On Mon, Sep 10, 2012 at 4:13 PM, Dave Airlie wrote:
> It might be related to a hardware bug, or the algorithm is flawed in a
> way I currently don't see. Anyway the old code we had wasn't so picky
> about such problems and the patch just tries to make the current code as
On Mon, Sep 10, 2012 at 5:10 PM, Jerome Glisse wrote:
> On Mon, Sep 10, 2012 at 4:13 PM, Dave Airlie wrote:
>>>>>
>>>>>
>>>>>> It might be related to a hardware bug, or the algorithm is flawed in a
>>>>>> way I current
On Tue, Sep 11, 2012 at 6:23 AM, Michel D?nzer wrote:
> On Die, 2012-09-11 at 12:11 +0200, Christian K?nig wrote:
>>
>> How about this idea: Instead of increasing the upper 32bits we just use
>> the upper 32bits of the last emitted fence value?
>> E.g. see the attached patch. That both should
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> Roughly based on how nouveau is handling it. Instead of
> adding the bo_va when the address is set add the bo_va
> when the handle is opened, but set the address to zero
> until userspace tells us where to place it.
>
> This fixes another
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> It is unnecessary when we remove the va in drm_close.
>
> Signed-off-by: Christian K?nig
NAK there is case for which drm_close is not call like ib pool and
other iirc. This clear va is really a safety net.
> ---
>
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> Make the reserve non interruptible.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_gem.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
&
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> The no_wait param isn't used anywhere, and actually isn't
> very usefull at all.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_object.c |7 +++
> d
On Tue, Sep 11, 2012 at 10:09 AM, Christian K?nig
wrote:
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_gart.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> It doesn't really belong into the object functions,
> also rename it to avoid collisions with struct radeon_bo_va.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/rade
On Tue, Sep 11, 2012 at 10:09 AM, Christian K?nig
wrote:
> The end offset is exclusive not inclusive.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_gart.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
&
On Tue, Sep 11, 2012 at 10:09 AM, Christian K?nig
wrote:
> Even GPUs can have a null pointer dereference, so move
> the IB pool to another offset to catch those.
Reviewed-by: Jerome Glisse
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon.h |
On Wed, Sep 12, 2012 at 8:08 AM, Christian K?nig
wrote:
> On 11.09.2012 18:11, Jerome Glisse wrote:
>>
>> On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
>> wrote:
>>>
>>> Roughly based on how nouveau is handling it. Instead of
>>> adding
On Wed, Sep 12, 2012 at 1:13 PM, Christian K?nig
wrote:
> On 12.09.2012 15:54, Jerome Glisse wrote:
>>
>> On Wed, Sep 12, 2012 at 8:08 AM, Christian K?nig
>> wrote:
>>>
>>> On 11.09.2012 18:11, Jerome Glisse wrote:
>>>>
>>>>
On Thu, Sep 13, 2012 at 9:54 AM, Alex Deucher wrote:
> On Thu, Sep 13, 2012 at 4:33 AM, Christian K?nig
> wrote:
>> Only increase the higher 32bits if we really detect a wrap around.
>>
>> v2: instead of increasing the higher 32bits just use the higher
>> 32bits from the last emitted fence.
On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher wrote:
> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote:
>> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
>> wrote:
>>> PDE/PTE update code uses CP ring for memory writes.
>>> All page table entries are
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
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
701 - 800 of 1383 matches
Mail list logo
