[Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
On Sun, 6 Nov 2011 20:13:49 +0100
Daniel Vetter wrote:
> ... instead of get_user_pages, because that fails on non page-backed
> user addresses like e.g. a gtt mapping of a bo.
>
> To get there essentially copy the vfs read path into pagecache. We
> can't call that right away because we have to take care of bit17
> swizzling. To not deadlock with our own pagefault handler we need
> to completely drop struct_mutex, reducing the atomicty-guarantees
> of our userspace abi. Implications for racing with other gem ioctl:
>
> - execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
> already the risk of the pwrite call not being atomic, no degration.
> - read/write access to mmaps: already fully racy, no degration.
> - set_tiling: Calling set_tiling while reading/writing is already
> pretty much undefined, now it just got a bit worse. set_tiling is
> only called by libdrm on unused/new bos, so no problem.
> - set_domain: When changing to the gtt domain while copying (without any
> read/write access, e.g. for synchronization), we might leave unflushed
> data in the cpu caches. The clflush_object at the end of pwrite_slow
> takes care of this problem.
> - truncating of purgeable objects: the shmem_read_mapping_page call could
> reinstate backing storage for truncated objects. The check at the end
> of pwrite_slow takes care of this.
>
> v2:
> - add missing intel_gtt_chipset_flush
> - add __ to copy_from_user_swizzled as suggest by Chris Wilson.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c | 126
> ---
> 1 files changed, 64 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6fa24bc..f9efebb 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -58,6 +58,7 @@ static void i915_gem_free_object_tail(struct
> drm_i915_gem_object *obj);
>
> static int i915_gem_inactive_shrink(struct shrinker *shrinker,
> struct shrink_control *sc);
> +static void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
>
> /* some bookkeeping */
> static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
> @@ -385,6 +386,32 @@ i915_gem_shmem_pread_fast(struct drm_device *dev,
> return 0;
> }
>
> +static inline int
> +__copy_from_user_swizzled(char __user *gpu_vaddr, int gpu_offset,
> + const char *cpu_vaddr,
> + int length)
> +{
> + int ret, cpu_offset = 0;
> +
> + while (length > 0) {
> + int cacheline_end = ALIGN(gpu_offset + 1, 64);
> + int this_length = min(cacheline_end - gpu_offset, length);
> + int swizzled_gpu_offset = gpu_offset ^ 64;
> +
> + ret = __copy_from_user(gpu_vaddr + swizzled_gpu_offset,
> +cpu_vaddr + cpu_offset,
> +this_length);
> + if (ret)
> + return ret + length;
> +
> + cpu_offset += this_length;
> + gpu_offset += this_length;
> + length -= this_length;
> + }
> +
> + return 0;
> +}
> +
Bikeshed, but I would much prefer a #define for the swizzle
bit/cacheline size.
> /**
> * This is the fallback shmem pread path, which allocates temporary storage
> * in kernel space to copy_to_user into outside of the struct_mutex, so we
> @@ -841,71 +868,36 @@ i915_gem_shmem_pwrite_slow(struct drm_device *dev,
> struct drm_file *file)
> {
> struct address_space *mapping =
> obj->base.filp->f_path.dentry->d_inode->i_mapping;
> - struct mm_struct *mm = current->mm;
> - struct page **user_pages;
> ssize_t remain;
> - loff_t offset, pinned_pages, i;
> - loff_t first_data_page, last_data_page, num_pages;
> - int shmem_page_offset;
> - int data_page_index, data_page_offset;
> - int page_length;
> - int ret;
> - uint64_t data_ptr = args->data_ptr;
> - int do_bit17_swizzling;
> + loff_t offset;
> + char __user *user_data;
> + int shmem_page_offset, page_length, ret;
> + int obj_do_bit17_swizzling, page_do_bit17_swizzling;
>
> + user_data = (char __user *) (uintptr_t) args->data_ptr;
> remain = args->size;
>
> - /* Pin the user pages containing the data. We can't fault while
> - * holding the struct mutex, and all of the pwrite implementations
> - * want to hold it while dereferencing the user data.
> - */
> - first_data_page = data_ptr / PAGE_SIZE;
> - last_data_page = (data_ptr + args->size - 1) / PAGE_SIZE;
> - num_pages = last_data_page - first_data_page + 1;
> -
> - user_pages = drm_malloc_ab(num_pages, sizeof(struct page *));
> - if (user_pages == NULL)
> - return -ENOMEM;
> -
> - mutex_unlock(>struct_mutex);
> - down_read(>mmap_sem);
> -
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||MOVED --- Comment #7 from Marek Ol??k 2011-11-20 13:16:27 PST --- OK, closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Sat, Nov 19, 2011 at 16:32, Keith Packard wrote: > On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov > wrote: > >> Just one question I caught on 2nd read. Shouldn't we have #else within >> this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is >> not defined, we'll always disable rc6. > > Oops! Thanks for catching this. Here's a new version of that function > (the rest of the patch is the same). This one has explicit conditions > for Ironlake and Sandybridge (when CONFIG_INTEL_IOMMU is set), allowing > the Ivybridge and Sandybridge-without-IOMMU cases to take the default > path. This will also cause all future chips to enable rc6 by default. Great, I think it catches all cases now. Reviewed-by: Eugeni Dodonov Thanks! -- Eugeni Dodonov
[Intel-gfx] [PATCH 01/13] drm/i915: fall through pwrite_gtt_slow to the shmem slow path
On Sun, 6 Nov 2011 20:13:48 +0100 Daniel Vetter wrote: > The gtt_pwrite slowpath grabs the userspace memory with > get_user_pages. This will not work for non-page backed memory, like a > gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit > -EFAULT in the gtt paths. > > Now the shmem paths have exactly the same problem, but this way we > only need to rearrange the code in one write path. > > v2: v1 accidentaly falls back to shmem pwrite for phys objects. Fixed. > > Signed-Off-by: Daniel Vetter It would be nice if there was some way to notify users that pwriting a gtt mmapped address can be really damn slow. That's also the one behavior change this patch introduces. It's possible that some SW was expecting to get a, "fast path" and would deal with the -EFAULT if it didn't get it. Presumably subsequent patches in this series fix this up further, so instead of figuring out all the failure conditions pwrite can cause, let's just go with Acked-by: Ben Widawsky
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #6 from Tom Stellard 2011-11-20 09:54:59 PST --- (In reply to comment #4) > This fixes the error, but the leader portraits still aren't being rendered, so > I guess there is some other problem causing this. I'll have to bisect to find > out exactly what it is. This bug can be closed once the above fix or > something > equivalent is committed to mater. I found the real problem, shaders are being failed for having too many varyings / uniforms (Bug 42930 and Bug 43121). When those shaders compile successfully, the portraits are rendered, and I don't get the "refusing to render" error. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #5 from Marek Ol??k 2011-11-20 09:33:32 PST --- The problem is there are no vertex attribs which are per-vertex (i.e. not constant and not per-instance), therefore there is nothing to compute the max index from. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #4 from Tom Stellard 2011-11-20 08:11:12 PST --- (In reply to comment #3) > I pushed the branch anyway because it fixes some other bugs. > > What happens if you do in r300_draw_vbo: > > info.max_index = max_count == ~0 ? 0xff : max_count - 1; This fixes the error, but the leader portraits still aren't being rendered, so I guess there is some other problem causing this. I'll have to bisect to find out exactly what it is. This bug can be closed once the above fix or something equivalent is committed to mater. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
RFC: Radeon multi ring support branch
On Fri, Nov 18, 2011 at 11:34 AM, Jerome Glisse wrote: > On Fri, Nov 18, 2011 at 07:44:19AM -0500, Alex Deucher wrote: >> 2011/11/17 Alex Deucher : >> > 2011/11/17 Christian K?nig : >> >> On 16.11.2011 01:24, Jerome Glisse wrote: >> >>> >> >>> Well as we don't specify on which value semaphore should wait on, i am >> >>> prety sure the first ring to increment the semaphore will unblock all >> >>> waiter. So if you have ring1 that want to wait on ring2 and ring3 as >> >>> soon as >> >>> ring2 or ring3 is done ring1 will go one while either ring2 or ring3 >> >>> might >> >>> not be done. I will test that tomorrow but from doc i have it seems so. >> >>> Thus >> >>> it will be broken with more than one ring, that would mean you have to >> >>> allocate one semaphore for each ring couple you want to synchronize. Note >> >>> that the usual case will likely be sync btw 2 ring. >> >> >> >> Good point, but I played with it a bit more today and it is just behaving >> >> as >> >> I thought it would be. A single signal command will just unblock a single >> >> waiter, even if there are multiple waiters currently for this semaphore, >> >> the >> >> only thing you can't tell is which waiter will come first. >> >> >> >> I should also note that the current algorithm will just emit multiple wait >> >> operations to a single ring, and spread the signal operations to all other >> >> rings we are interested in. That isn't very efficient, but should indeed >> >> work quite fine. >> >> >> >>> After retesting the first patch ?drm/radeon: fix debugfs handling is NAK >> >>> a complete no go. >> >>> >> >>> Issue is that radeon_debugfs_cleanup is call after rdev is free. This >> >>> is why i used a static array. I forgot about that, i should have put a >> >>> comment. I guess you built your kernel without debugfs or that you >> >>> didn't tested to reload the module. >> >> >> >> Mhm, I have tested it, seen the crash, and didn't thought that this is a >> >> problem. Don't ask me why I can't understand it myself right now. >> >> >> >> Anyway, I moved the unregistering of the files into a separate function, >> >> which is now called from radeon_device_fini instead of >> >> radeon_debugfs_cleanup. That seems to work fine, at least if I haven't >> >> missed something else. >> >> >> >> I also merged your indention fixes and the fix for the never allocated >> >> semaphores and pushed the result into my public repository >> >> (http://cgit.freedesktop.org/~deathsimple/linux), so please take another >> >> look at it. >> > >> > I've got a few other patches to enable further functionality in the >> > mring patches. >> > - per ring fence interrupts >> > - add some additional ring fields to better handle different ring types >> > >> > http://people.freedesktop.org/~agd5f/mrings/ >> > >> >> FYI, I updated these later last night. >> >> Alex >> > > Ok so reviewed the patch serie, please Christian keep v2, v3, ... > informations, i find this usefull. I put updated patch at > http://people.freedesktop.org/~glisse/mrings/ > > Couple of fixes there, indentation, and also i changed the testing > parameter to be a bit flag which make our life easier when we want > to only test the semaphore stuff and not the bo move. > > Cheers, > Jerome > Found a major bug introduced by patch 15, rewrote it. Reuploaded the whole series at http://people.freedesktop.org/~glisse/mrings/ Issue is that all the fence list should be initialized only once from asic init callback. Commit message has bigger explanation. Cheers, Jerome
[PATCH] drm/ttm: callback move_notify any time bo placement change v3
On Sat, Nov 19, 2011 at 3:45 PM, Thomas Hellstrom
wrote:
> On 11/19/2011 12:32 AM, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> Previously we were calling back move_notify in error path when the
>> bo is returned to it's original position or when destroy the bo.
>> When destroying the bo set the new mem placement as NULL when calling
>> back in the driver.
>>
>> Updating nouveau to deal with NULL placement properly.
>>
>> v2: reserve the object before calling move_notify in bo destroy path
>> ? ? at that point ttm should be the only piece of code interacting
>> ? ? with the object so atomic_set is safe here.
>> v3: callback move notify only once the bo is in its new position
>> ? ? call move notify want swaping out the buffer
>>
>> Reviewed-by: Jerome Glisse
>> ---
>> ?drivers/gpu/drm/nouveau/nouveau_bo.c | ? ?4 ++--
>> ?drivers/gpu/drm/ttm/ttm_bo.c ? ? ? ? | ? 17 +
>> ?2 files changed, 15 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> index 857bca4..f12dd0f 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> @@ -815,10 +815,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo,
>> struct ttm_mem_reg *new_mem)
>> ? ? ? ?struct nouveau_vma *vma;
>>
>> ? ? ? ?list_for_each_entry(vma,>vma_list, head) {
>> - ? ? ? ? ? ? ? if (new_mem->mem_type == TTM_PL_VRAM) {
>> + ? ? ? ? ? ? ? if (new_mem&& ?new_mem->mem_type == TTM_PL_VRAM) {
>> ? ? ? ? ? ? ? ? ? ? ? ?nouveau_vm_map(vma, new_mem->mm_node);
>> ? ? ? ? ? ? ? ?} else
>> - ? ? ? ? ? ? ? if (new_mem->mem_type == TTM_PL_TT&&
>> + ? ? ? ? ? ? ? if (new_mem&& ?new_mem->mem_type == TTM_PL_TT&&
>> ? ? ? ? ? ? ? ?nvbo->page_shift == vma->vm->spg_shift) {
>> ? ? ? ? ? ? ? ? ? ? ? ?nouveau_vm_map_sg(vma, 0, new_mem->
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?num_pages<< ?PAGE_SHIFT,
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index de7ad99..0c1d821 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -147,6 +147,12 @@ static void ttm_bo_release_list(struct kref
>> *list_kref)
>> ? ? ? ?BUG_ON(!list_empty(>lru));
>> ? ? ? ?BUG_ON(!list_empty(>ddestroy));
>>
>> + ? ? ? /* force bo to reserved, at this point we should be the only owner
>> */
>> + ? ? ? atomic_set(>reserved, 1);
>> + ? ? ? if (bdev->driver->move_notify)
>> + ? ? ? ? ? ? ? bdev->driver->move_notify(bo, NULL);
>> + ? ? ? atomic_set(>reserved, 0);
>>
>
> We can actually do this from the top of ttm_bo_cleanup_memtype_use(). Then
> we should catch all current and future use-cases and you wouldn't need the
> fake reserving, because at that point, we're already reserved.
>
>> +
>> ? ? ? ?if (bo->ttm)
>> ? ? ? ? ? ? ? ?ttm_tt_destroy(bo->ttm);
>> ? ? ? ?atomic_dec(>glob->bo_count);
>> @@ -404,9 +410,6 @@ static int ttm_bo_handle_move_mem(struct
>> ttm_buffer_object *bo,
>> ? ? ? ? ? ? ? ?}
>> ? ? ? ?}
>>
>> - ? ? ? if (bdev->driver->move_notify)
>> - ? ? ? ? ? ? ? bdev->driver->move_notify(bo, mem);
>> -
>> ? ? ? ?if (!(old_man->flags& ?TTM_MEMTYPE_FLAG_FIXED)&&
>> ? ? ? ?!(new_man->flags& ?TTM_MEMTYPE_FLAG_FIXED))
>> ? ? ? ? ? ? ? ?ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve,
>> no_wait_gpu, mem);
>> @@ -419,6 +422,9 @@ static int ttm_bo_handle_move_mem(struct
>> ttm_buffer_object *bo,
>> ? ? ? ?if (ret)
>> ? ? ? ? ? ? ? ?goto out_err;
>>
>> + ? ? ? if (bdev->driver->move_notify)
>> + ? ? ? ? ? ? ? bdev->driver->move_notify(bo, mem);
>> +
>>
>
>> ?moved:
>> ? ? ? ?if (bo->evicted) {
>> ? ? ? ? ? ? ? ?ret = bdev->driver->invalidate_caches(bdev,
>> bo->mem.placement);
>> @@ -1872,9 +1878,12 @@ static int ttm_bo_swapout(struct ttm_mem_shrink
>> *shrink)
>> ? ? ? ?if (bo->bdev->driver->swap_notify)
>> ? ? ? ? ? ? ? ?bo->bdev->driver->swap_notify(bo);
>>
>> + ? ? ? if (bo->bdev->driver->move_notify)
>> + ? ? ? ? ? ? ? bo->bdev->driver->move_notify(bo, NULL);
>> +
>>
>
> Hmm. On second thought, we could use swap_notify() for this, I missed we
> already had that and that's what vmwgfx once used for exactly the same
> purpose.
>
>
>> ? ? ? ?ret = ttm_tt_swapout(bo->ttm, bo->persistent_swap_storage);
>> -out:
>>
>> +out:
>>
>
> Whitespace.
>
> /Thomas
>
>
Attached updated patch
Cheers,
Jerome
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-ttm-callback-move_notify-any-time-bo-placement-c.patch
Type: application/octet-stream
Size: 3037 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2020/a32e587e/attachment.obj>
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #3 from Marek Ol??k 2011-11-20 07:35:27 PST --- I pushed the branch anyway because it fixes some other bugs. What happens if you do in r300_draw_vbo: info.max_index = max_count == ~0 ? 0xff : max_count - 1; -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 11:54 PM, Jerome Glisse wrote:
>
>> As mentioned previously, and in the discussion with Ben, the page tables
>> would not need to be rebuilt on each CS. They would be rebuilt only on the
>> first CS following a move_notify that caused a page table invalidation.
>>
>> move_notify:
>> if (is_incompatible(new_mem_type)) {
>> bo->page_tables_invalid = true;
>> invalidate_page_tables(bo);
>> }
>>
>> command_submission:
>> if (bo->page_tables_invalid) {
>>set_up_page_tables(bo);
>>bo->page_tables_invalid = false;
>> }
>>
> Why is it different from updating page table in move notify ? I don't
> see any bonus here, all the information we need are already available
> in move_notify.
>
>
I've iterated the pros of this approach at least two times before, but
for completeness let's do it again:
8<
1) TTM doesn't need to care about the driver re-populating its GPU page
tables.
Since swapin is handled from the tt layer not the bo layer, this makes it a
bit easier on us.
2) Transition to page-faulted GPU virtual maps is straightforward and
consistent. A non-page-faulting driver sets up the maps at CS time, A
pagefaulting driver can set them up directly from an irq handler without
reserving, since the bo is properly fenced or pinned when the pagefault
happens.
3) A non-page-faulting driver knows at CS time exactly which
page-table-entries really do need populating, and can do this more
efficiently.
8<-
And some extra items like partially populated TTMs that were mentioned
elsewhere.
>> Memory types in TTM are completely orthogonal to allowed GPU usage. The GPU
>> may access a bo if it's reserved, fenced or pinned, regardless of its
>> placement.
>>
>> A TT memory type is a *single* GPU aperture that may be mapped from the
>> aperture side by the CPU (AGP). It may also be used by a single unmappable
>> aperture that wants to use TTM's range management and eviction (vmwgfx GMR).
>> The driver can define more than one such memory type (psb), but a bo can
>> only be placed in one of those at a time, so this approach is unsuitable for
>> multiple apertures pointing to the same pages.
>>
> radeon virtual memory have a special address space, the system address
> space, it's managed by ttm through a TTM_TT (exact same code as
> current one). All the other address space are not managed by ttm but
> we require a bo to be bound to ttm_tt to be use, thought we can relax
> that. That's the reason why i consider system placement as different.
>
>
Yes for Radeon system memory may be different, and that's fine. But as
also previously mentioned we're trying to design a generic interface
here, in which we need to consider GPU- mappable system memory.
I think the pros of this interface design compared to populating in
bo_move are pretty well established, so can you please explain why you
keep arguing against it? What is it that I have missed?
/Thomas
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2020/38163bf1/attachment.html>
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sun, Nov 20, 2011 at 4:30 AM, Thomas Hellstrom
wrote:
> On 11/19/2011 11:54 PM, Jerome Glisse wrote:
>
> As mentioned previously, and in the discussion with Ben, the page tables
> would not need to be rebuilt on each CS. They would be rebuilt only on the
> first CS following a move_notify that caused a page table invalidation.
>
> move_notify:
> if (is_incompatible(new_mem_type)) {
> ?bo->page_tables_invalid = true;
> ?invalidate_page_tables(bo);
> }
>
> command_submission:
> if (bo->page_tables_invalid) {
> ? set_up_page_tables(bo);
> ? bo->page_tables_invalid = false;
> }
>
>
> Why is it different from updating page table in move notify ? I don't
> see any bonus here, all the information we need are already available
> in move_notify.
>
>
>
> I've iterated the pros of this approach at least two times before, but for
> completeness let's do it again:
>
> 8<
>
> 1) TTM doesn't need to care about the driver re-populating its GPU page
> tables.
> Since swapin is handled from the tt layer not the bo layer, this makes it a
> bit easier on us.
> 2) Transition to page-faulted GPU virtual maps is straightforward and
> consistent. A non-page-faulting driver sets up the maps at CS time, A
> pagefaulting driver can set them up directly from an irq handler without
> reserving, since the bo is properly fenced or pinned when the pagefault
> happens.
> 3) A non-page-faulting driver knows at CS time exactly which
> page-table-entries really do need populating, and can do this more
> efficiently.
>
> 8<-
>
> And some extra items like partially populated TTMs that were mentioned
> elsewhere.
If done in move_notify i don't see why 1 would be different or 2. I
agree that in some case 3 is true. Given when move notify is call the
ttm_tt is always fully populated at that point (only exception is in
destroy path but it's a special on its own). If driver populate in
move_notify is doesn't change anything from ttm pov.
> Memory types in TTM are completely orthogonal to allowed GPU usage. The GPU
> may access a bo if it's reserved, fenced or pinned, regardless of its
> placement.
>
> A TT memory type is a *single* GPU aperture that may be mapped from the
> aperture side by the CPU (AGP). It may also be used by a single unmappable
> aperture that wants to use TTM's range management and eviction (vmwgfx GMR).
> The driver can define more than one such memory type (psb), but a bo can
> only be placed in one of those at a time, so this approach is unsuitable for
> multiple apertures pointing to the same pages.
>
>
> radeon virtual memory have a special address space, the system address
> space, it's managed by ttm through a TTM_TT (exact same code as
> current one). All the other address space are not managed by ttm but
> we require a bo to be bound to ttm_tt to be use, thought we can relax
> that. That's the reason why i consider system placement as different.
>
>
>
> Yes for Radeon system memory may be different, and that's fine. But as also
> previously mentioned we're trying to design a generic interface here, in
> which we need to consider GPU- mappable system memory.
>
> I think the pros of this interface design compared to populating in bo_move
> are pretty well established, so can you please explain why you keep arguing
> against it? What is it that I have missed?
>
> /Thomas
It's just i absolutely see no diff in doing it in move_notify (point 1
and 2 doesn't change from my pov). I fail to see the pro that's all.
Cheers,
Jerome
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #2 from Tom Stellard 2011-11-19 20:48:46 PST --- (In reply to comment #1) > Could you try this branch? > > git://people.freedesktop.org/~mareko/mesa vbufmgr-fixes Still they same problem, but now max_index is -2 instead of -1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #1 from Marek Ol??k 2011-11-19 20:22:03 PST --- Could you try this branch? git://people.freedesktop.org/~mareko/mesa vbufmgr-fixes -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43073] Trine not working on Radeon HD6520G
https://bugs.freedesktop.org/show_bug.cgi?id=43073 Sandeep changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43073] Trine not working on Radeon HD6520G
https://bugs.freedesktop.org/show_bug.cgi?id=43073 --- Comment #4 from Sandeep 2011-11-19 19:22:12 PST --- That was the case, libstdc++6 in trine directory was the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm_edid: support CEA video modes
Another user confirming the working of the patch from xbmc forums: http://forum.xbmc.org/showpost.php?p=940016=31 Any news on when this will be in master ? Thanks 2011/11/13 Christian Schmidt > TFT/plasma televisions and projectors have become commonplace, and so > has the use of PCs to drive them. Add the video modes specified by an > EDID's CEA extension to the mode database for a connector. > > Before: > [1.158869] [drm:drm_mode_debug_printmodeline], Modeline > 19:"1920x1080i" 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 > [1.158875] [drm:drm_mode_debug_printmodeline], Modeline > 18:"1920x1080i" 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15 > [1.158882] [drm:drm_mode_debug_printmodeline], Modeline > 20:"1920x1080" 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5 > > After: > [1.144175] [drm:drm_mode_debug_printmodeline], Modeline > 22:"1920x1080" 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 > [1.144179] [drm:drm_mode_debug_printmodeline], Modeline > 21:"1920x1080" 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15 > [1.144187] [drm:drm_mode_debug_printmodeline], Modeline > 30:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 > [1.144190] [drm:drm_mode_debug_printmodeline], Modeline > 29:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 > [1.144192] [drm:drm_mode_debug_printmodeline], Modeline > 25:"1920x1080" 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5 > [1.144195] [drm:drm_mode_debug_printmodeline], Modeline > 24:"1280x720" 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5 > [1.144198] [drm:drm_mode_debug_printmodeline], Modeline > 23:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 > [1.144201] [drm:drm_mode_debug_printmodeline], Modeline 27:"720x576" > 50 27000 720 732 796 864 576 581 586 625 0x40 0xa > [1.144203] [drm:drm_mode_debug_printmodeline], Modeline 26:"720x480" > 60 27000 720 736 798 858 480 489 495 525 0x40 0xa > [1.144206] [drm:drm_mode_debug_printmodeline], Modeline 28:"640x480" > 60 25175 640 656 752 800 480 490 492 525 0x40 0xa > > > Signed-off-by: Christian Schmidt > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2020/e3c72495/attachment.html>
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: > On 11/19/2011 01:26 AM, Ben Skeggs wrote: > > On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: > > > >> On 11/18/2011 06:26 PM, Ben Skeggs wrote: > >> > >>> On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: > >>> > >>> > On 11/18/2011 02:15 PM, Ben Skeggs wrote: > > > > On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: > > > > > > > >> Jerome, > >> > >> I don't like this change for the following reasons > >> > >> > >> > > -snip- > > > > > > > > > >>> One can take advantage of move notify callback but, there are > >>> corner case where bind/unbind might be call without move notify > >>> being call (in error path mostly). So to make sure that each > >>> virtual address space have a consistent view of wether a buffer > >>> object is backed or not by system page it's better to pass the > >>> buffer object to bind/unbind. > >>> > >>> > >>> > > As I discussed previously with Jerome on IRC, I believe the move_notify > > hook is sufficient. I fixed a couple of issues back with it back when I > > implemented support for this in nouveau. > > > > Jerome did point out two issues however, which I believe can be solved > > easily enough. > > > > The first was that the error path after move_notify() has been called > > doesn't reverse the move_notify() too, leaving incorrect page table > > entries. This, I think, could easily be solved by swapping bo->mem and > > mem, and re-calling move_notify() to have the driver reverse whatever it > > did. > > > > The second issue is that apparently move_notify() doesn't get called in > > the destroy path. Nouveau's GEM layer takes care of this for our > > userspace bos, and we don't use any kernel bos that are mapped into a > > channel's address space so we don't hit it. This can probably be solved > > easily enough too I expect. > > > > Ben. > > > > > > > > > OK. I understand. Surely if a move_notify is missing somewhere, that can > easily be fixed. > > It might be good if we can outline how the virtual tables are set up. In > my world, the following would happen: > > 1) Pre command submission: > > a) reserve bo > b) call ttm_bo_validate to set placement. move_notify will tear down any > existing GPU page tables for the bo. > c) Set up GPU page tables. > > > >>> Nouveau doesn't do this exactly. I wanted to avoid having to check if a > >>> bo was bound to a particular address space on every command submission. > >>> > >>> > >> It perhaps might be a good idea to revisit this? > >> I think using move_notify to set up a new placement before the data has > >> actually been moved is very fragile and not the intended use. That would > >> also save you from having to handle error paths. Also how do you handle > >> swapouts? > >> > > I don't see how it's fragile, there's only the one error path after that > > point that needs to undo it. And, what *is* the expected use then? I > > see it as "tell the driver the buffer is moving so it can do whatever is > > necessary as a result". > > > > Swapouts are a missed case though, indeed. > > > > > >> A quick check in c) that the virtual map hasn't been torn down by a > >> move_notify and, in that case, rebuild it would probably be next to > >> free. The virtual GPU mapping would then be valid only after validation > >> and while the bo is fenced or pinned. > >> > > This alone doesn't solve the swapouts issue either unless you're also > > wanting us to unmap once a buffer becomes unfenced, which would lead to > > loads of completely unnecessary map/unmaps. > > > > Ben. > > > > I think you misunderstand me a little. > The swapout issue should be handled by calling a move_notify() to kill > the virtual GPU mappings. > > However, when moving data that has page tables pointing to it, one > should (IMHO) do: > > 1) Kill the old page tables > 2) Move the object > 3) Set up new page tables on demand. > > This is done by TTM for CPU page tables and I think that should be done > also for GPU page tables. move_notify() should be responsible for 1), > The driver execbuf for 3), and 3) needs only to be done for the > particular ring / fifo which is executing commands that touch the buffer. > > This leaves a clear and well-defined requirement on TTM: > Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. > > With the latest patch from jerome: > Notify the
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 11:54 PM, Jerome Glisse wrote:
As mentioned previously, and in the discussion with Ben, the page tables
would not need to be rebuilt on each CS. They would be rebuilt only on the
first CS following a move_notify that caused a page table invalidation.
move_notify:
if (is_incompatible(new_mem_type)) {
bo-page_tables_invalid = true;
invalidate_page_tables(bo);
}
command_submission:
if (bo-page_tables_invalid) {
set_up_page_tables(bo);
bo-page_tables_invalid = false;
}
Why is it different from updating page table in move notify ? I don't
see any bonus here, all the information we need are already available
in move_notify.
I've iterated the pros of this approach at least two times before, but
for completeness let's do it again:
8
1) TTM doesn't need to care about the driver re-populating its GPU page
tables.
Since swapin is handled from the tt layer not the bo layer, this makes it a
bit easier on us.
2) Transition to page-faulted GPU virtual maps is straightforward and
consistent. A non-page-faulting driver sets up the maps at CS time, A
pagefaulting driver can set them up directly from an irq handler without
reserving, since the bo is properly fenced or pinned when the pagefault
happens.
3) A non-page-faulting driver knows at CS time exactly which
page-table-entries really do need populating, and can do this more
efficiently.
8-
And some extra items like partially populated TTMs that were mentioned
elsewhere.
Memory types in TTM are completely orthogonal to allowed GPU usage. The GPU
may access a bo if it's reserved, fenced or pinned, regardless of its
placement.
A TT memory type is a *single* GPU aperture that may be mapped from the
aperture side by the CPU (AGP). It may also be used by a single unmappable
aperture that wants to use TTM's range management and eviction (vmwgfx GMR).
The driver can define more than one such memory type (psb), but a bo can
only be placed in one of those at a time, so this approach is unsuitable for
multiple apertures pointing to the same pages.
radeon virtual memory have a special address space, the system address
space, it's managed by ttm through a TTM_TT (exact same code as
current one). All the other address space are not managed by ttm but
we require a bo to be bound to ttm_tt to be use, thought we can relax
that. That's the reason why i consider system placement as different.
Yes for Radeon system memory may be different, and that's fine. But as
also previously mentioned we're trying to design a generic interface
here, in which we need to consider GPU- mappable system memory.
I think the pros of this interface design compared to populating in
bo_move are pretty well established, so can you please explain why you
keep arguing against it? What is it that I have missed?
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sun, Nov 20, 2011 at 4:30 AM, Thomas Hellstrom thellst...@vmware.com wrote:
On 11/19/2011 11:54 PM, Jerome Glisse wrote:
As mentioned previously, and in the discussion with Ben, the page tables
would not need to be rebuilt on each CS. They would be rebuilt only on the
first CS following a move_notify that caused a page table invalidation.
move_notify:
if (is_incompatible(new_mem_type)) {
bo-page_tables_invalid = true;
invalidate_page_tables(bo);
}
command_submission:
if (bo-page_tables_invalid) {
set_up_page_tables(bo);
bo-page_tables_invalid = false;
}
Why is it different from updating page table in move notify ? I don't
see any bonus here, all the information we need are already available
in move_notify.
I've iterated the pros of this approach at least two times before, but for
completeness let's do it again:
8
1) TTM doesn't need to care about the driver re-populating its GPU page
tables.
Since swapin is handled from the tt layer not the bo layer, this makes it a
bit easier on us.
2) Transition to page-faulted GPU virtual maps is straightforward and
consistent. A non-page-faulting driver sets up the maps at CS time, A
pagefaulting driver can set them up directly from an irq handler without
reserving, since the bo is properly fenced or pinned when the pagefault
happens.
3) A non-page-faulting driver knows at CS time exactly which
page-table-entries really do need populating, and can do this more
efficiently.
8-
And some extra items like partially populated TTMs that were mentioned
elsewhere.
If done in move_notify i don't see why 1 would be different or 2. I
agree that in some case 3 is true. Given when move notify is call the
ttm_tt is always fully populated at that point (only exception is in
destroy path but it's a special on its own). If driver populate in
move_notify is doesn't change anything from ttm pov.
Memory types in TTM are completely orthogonal to allowed GPU usage. The GPU
may access a bo if it's reserved, fenced or pinned, regardless of its
placement.
A TT memory type is a *single* GPU aperture that may be mapped from the
aperture side by the CPU (AGP). It may also be used by a single unmappable
aperture that wants to use TTM's range management and eviction (vmwgfx GMR).
The driver can define more than one such memory type (psb), but a bo can
only be placed in one of those at a time, so this approach is unsuitable for
multiple apertures pointing to the same pages.
radeon virtual memory have a special address space, the system address
space, it's managed by ttm through a TTM_TT (exact same code as
current one). All the other address space are not managed by ttm but
we require a bo to be bound to ttm_tt to be use, thought we can relax
that. That's the reason why i consider system placement as different.
Yes for Radeon system memory may be different, and that's fine. But as also
previously mentioned we're trying to design a generic interface here, in
which we need to consider GPU- mappable system memory.
I think the pros of this interface design compared to populating in bo_move
are pretty well established, so can you please explain why you keep arguing
against it? What is it that I have missed?
/Thomas
It's just i absolutely see no diff in doing it in move_notify (point 1
and 2 doesn't change from my pov). I fail to see the pro that's all.
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #3 from Marek Olšák mar...@gmail.com 2011-11-20 07:35:27 PST --- I pushed the branch anyway because it fixes some other bugs. What happens if you do in r300_draw_vbo: info.max_index = max_count == ~0 ? 0xff : max_count - 1; -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #4 from Tom Stellard tstel...@gmail.com 2011-11-20 08:11:12 PST --- (In reply to comment #3) I pushed the branch anyway because it fixes some other bugs. What happens if you do in r300_draw_vbo: info.max_index = max_count == ~0 ? 0xff : max_count - 1; This fixes the error, but the leader portraits still aren't being rendered, so I guess there is some other problem causing this. I'll have to bisect to find out exactly what it is. This bug can be closed once the above fix or something equivalent is committed to mater. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #5 from Marek Olšák mar...@gmail.com 2011-11-20 09:33:32 PST --- The problem is there are no vertex attribs which are per-vertex (i.e. not constant and not per-instance), therefore there is nothing to compute the max index from. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #6 from Tom Stellard tstel...@gmail.com 2011-11-20 09:54:59 PST --- (In reply to comment #4) This fixes the error, but the leader portraits still aren't being rendered, so I guess there is some other problem causing this. I'll have to bisect to find out exactly what it is. This bug can be closed once the above fix or something equivalent is committed to mater. I found the real problem, shaders are being failed for having too many varyings / uniforms (Bug 42930 and Bug 43121). When those shaders compile successfully, the portraits are rendered, and I don't get the refusing to render error. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: callback move_notify any time bo placement change v3
On Sat, Nov 19, 2011 at 3:45 PM, Thomas Hellstrom thellst...@vmware.com wrote:
On 11/19/2011 12:32 AM, j.gli...@gmail.com wrote:
From: Jerome Glissejgli...@redhat.com
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back in the driver.
Updating nouveau to deal with NULL placement properly.
v2: reserve the object before calling move_notify in bo destroy path
at that point ttm should be the only piece of code interacting
with the object so atomic_set is safe here.
v3: callback move notify only once the bo is in its new position
call move notify want swaping out the buffer
Reviewed-by: Jerome Glissejgli...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 17 +
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 857bca4..f12dd0f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -815,10 +815,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo,
struct ttm_mem_reg *new_mem)
struct nouveau_vma *vma;
list_for_each_entry(vma,nvbo-vma_list, head) {
- if (new_mem-mem_type == TTM_PL_VRAM) {
+ if (new_mem new_mem-mem_type == TTM_PL_VRAM) {
nouveau_vm_map(vma, new_mem-mm_node);
} else
- if (new_mem-mem_type == TTM_PL_TT
+ if (new_mem new_mem-mem_type == TTM_PL_TT
nvbo-page_shift == vma-vm-spg_shift) {
nouveau_vm_map_sg(vma, 0, new_mem-
num_pages PAGE_SHIFT,
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index de7ad99..0c1d821 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -147,6 +147,12 @@ static void ttm_bo_release_list(struct kref
*list_kref)
BUG_ON(!list_empty(bo-lru));
BUG_ON(!list_empty(bo-ddestroy));
+ /* force bo to reserved, at this point we should be the only owner
*/
+ atomic_set(bo-reserved, 1);
+ if (bdev-driver-move_notify)
+ bdev-driver-move_notify(bo, NULL);
+ atomic_set(bo-reserved, 0);
We can actually do this from the top of ttm_bo_cleanup_memtype_use(). Then
we should catch all current and future use-cases and you wouldn't need the
fake reserving, because at that point, we're already reserved.
+
if (bo-ttm)
ttm_tt_destroy(bo-ttm);
atomic_dec(bo-glob-bo_count);
@@ -404,9 +410,6 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
}
}
- if (bdev-driver-move_notify)
- bdev-driver-move_notify(bo, mem);
-
if (!(old_man-flags TTM_MEMTYPE_FLAG_FIXED)
!(new_man-flags TTM_MEMTYPE_FLAG_FIXED))
ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve,
no_wait_gpu, mem);
@@ -419,6 +422,9 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
if (ret)
goto out_err;
+ if (bdev-driver-move_notify)
+ bdev-driver-move_notify(bo, mem);
+
moved:
if (bo-evicted) {
ret = bdev-driver-invalidate_caches(bdev,
bo-mem.placement);
@@ -1872,9 +1878,12 @@ static int ttm_bo_swapout(struct ttm_mem_shrink
*shrink)
if (bo-bdev-driver-swap_notify)
bo-bdev-driver-swap_notify(bo);
+ if (bo-bdev-driver-move_notify)
+ bo-bdev-driver-move_notify(bo, NULL);
+
Hmm. On second thought, we could use swap_notify() for this, I missed we
already had that and that's what vmwgfx once used for exactly the same
purpose.
ret = ttm_tt_swapout(bo-ttm, bo-persistent_swap_storage);
-out:
+out:
Whitespace.
/Thomas
Attached updated patch
Cheers,
Jerome
0001-drm-ttm-callback-move_notify-any-time-bo-placement-c.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Radeon multi ring support branch
On Fri, Nov 18, 2011 at 11:34 AM, Jerome Glisse j.gli...@gmail.com wrote: On Fri, Nov 18, 2011 at 07:44:19AM -0500, Alex Deucher wrote: 2011/11/17 Alex Deucher alexdeuc...@gmail.com: 2011/11/17 Christian König deathsim...@vodafone.de: On 16.11.2011 01:24, Jerome Glisse wrote: Well as we don't specify on which value semaphore should wait on, i am prety sure the first ring to increment the semaphore will unblock all waiter. So if you have ring1 that want to wait on ring2 and ring3 as soon as ring2 or ring3 is done ring1 will go one while either ring2 or ring3 might not be done. I will test that tomorrow but from doc i have it seems so. Thus it will be broken with more than one ring, that would mean you have to allocate one semaphore for each ring couple you want to synchronize. Note that the usual case will likely be sync btw 2 ring. Good point, but I played with it a bit more today and it is just behaving as I thought it would be. A single signal command will just unblock a single waiter, even if there are multiple waiters currently for this semaphore, the only thing you can't tell is which waiter will come first. I should also note that the current algorithm will just emit multiple wait operations to a single ring, and spread the signal operations to all other rings we are interested in. That isn't very efficient, but should indeed work quite fine. After retesting the first patch drm/radeon: fix debugfs handling is NAK a complete no go. Issue is that radeon_debugfs_cleanup is call after rdev is free. This is why i used a static array. I forgot about that, i should have put a comment. I guess you built your kernel without debugfs or that you didn't tested to reload the module. Mhm, I have tested it, seen the crash, and didn't thought that this is a problem. Don't ask me why I can't understand it myself right now. Anyway, I moved the unregistering of the files into a separate function, which is now called from radeon_device_fini instead of radeon_debugfs_cleanup. That seems to work fine, at least if I haven't missed something else. I also merged your indention fixes and the fix for the never allocated semaphores and pushed the result into my public repository (http://cgit.freedesktop.org/~deathsimple/linux), so please take another look at it. I've got a few other patches to enable further functionality in the mring patches. - per ring fence interrupts - add some additional ring fields to better handle different ring types http://people.freedesktop.org/~agd5f/mrings/ FYI, I updated these later last night. Alex Ok so reviewed the patch serie, please Christian keep v2, v3, ... informations, i find this usefull. I put updated patch at http://people.freedesktop.org/~glisse/mrings/ Couple of fixes there, indentation, and also i changed the testing parameter to be a bit flag which make our life easier when we want to only test the semaphore stuff and not the bo move. Cheers, Jerome Found a major bug introduced by patch 15, rewrote it. Reuploaded the whole series at http://people.freedesktop.org/~glisse/mrings/ Issue is that all the fence list should be initialized only once from asic init callback. Commit message has bigger explanation. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||MOVED --- Comment #7 from Marek Olšák mar...@gmail.com 2011-11-20 13:16:27 PST --- OK, closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Sat, Nov 19, 2011 at 16:32, Keith Packard kei...@keithp.com wrote: On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov eug...@dodonov.net wrote: Just one question I caught on 2nd read. Shouldn't we have #else within this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is not defined, we'll always disable rc6. Oops! Thanks for catching this. Here's a new version of that function (the rest of the patch is the same). This one has explicit conditions for Ironlake and Sandybridge (when CONFIG_INTEL_IOMMU is set), allowing the Ivybridge and Sandybridge-without-IOMMU cases to take the default path. This will also cause all future chips to enable rc6 by default. Great, I think it catches all cases now. Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com Thanks! -- Eugeni Dodonov ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: max PWM is zero
So, anybody gets the same message? I'm trying the 3.2-rc2 and it gives the same message. Again, if you need someone to make tests, or test some patches, I'm able to do this. * Uma vida sem desafios é uma vida sem razão * * A life without challanges is a non reason life * On Tue, 15 Nov 2011, Marcos Paulo de Souza wrote: Hi lkml, I'm using the kernel 3.2-rc1 and I'm getting the following message in my dmesg: fixme: max PWM is zero. I don't remember if this message was here before... I'm trying to verify what is causing this. I found this waring message in the drivers/gpu/drm/i915/intel_panel.c. There is a comment above this message, talking about put a code to query mode clock or hw clock to set the max PWM. Bellow is my lspci. I will be happy if you continue to cc me, and if you need any test, I'm able to do this. 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 09) Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information: Len=0a ? Kernel driver in use: agpgart-intel Kernel modules: intel-agp 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f800 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 Flags: bus master, fast devsel, latency 0 Memory at f840 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 3 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) (prog-if 00 [UHCI]) Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at 1820 [size=32] Capabilities: [50] PCI Advanced Features Kernel driver in use: uhci_hcd 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) (prog-if 00 [UHCI]) Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 Flags: bus master, medium devsel, latency 0, IRQ 21 I/O ports at 1840 [size=32] Capabilities: [50] PCI Advanced Features Kernel driver in use: uhci_hcd 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) (prog-if 00 [UHCI]) Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at 1860 [size=32] Capabilities: [50] PCI Advanced Features Kernel driver in use: uhci_hcd 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) (prog-if 20 [EHCI]) Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 Flags: bus master, medium devsel, latency 0, IRQ 19 Memory at f8704000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: ehci_hcd 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at f870 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [130] Root Complex Link Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=03, sec-latency=0 I/O behind bridge: 2000-2fff Memory behind bridge: f400-f5ff Prefetchable memory behind bridge: f000-f1ff Capabilities: [40] Express Root Port (Slot+), MSI 00 Capabilities: [80] MSI: Enable+ Count=1/1 Maskable-
Re: [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver
On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote: On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang fengguang...@intel.com wrote: However when in X, -mode_set won't be called at all. Only -get_modes and -detect are called... The desktop software will call mode_set when it configures the monitor. Otherwise, it's not being used (and so shouldn't have audio routed to it by default). Keith, I experimented playing HDMI audio in X, and during the time unplug and plug the monitor. The HDMI audio/graphics all continue to work when plugged in the monitor again. Here is the dmesg showed for the plug event, no -mode_set is called at all... [ 1296.469103] [drm:drm_mode_getconnector], [CONNECTOR:5:?] [ 1296.475442] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] [ 1296.483649] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0x83f4, result 1 [ 1296.493417] [drm:intel_crt_detect], CRT detected via hotplug [ 1296.562579] [drm:drm_edid_to_eld], ELD: no CEA Extension found [ 1296.564700] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] probed modes : [ 1296.567609] [drm:drm_mode_debug_printmodeline], Modeline 24:1024x768 60 65000 1024 1048 1184 1344 768 771 777 806 0x48 0xa [ 1296.572112] [drm:drm_mode_debug_printmodeline], Modeline 23:1024x768 75 78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5 [ 1296.576561] [drm:drm_mode_debug_printmodeline], Modeline 25:800x600 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5 [ 1296.579109] [drm:drm_mode_debug_printmodeline], Modeline 19:800x600 60 4 800 840 968 1056 600 601 605 628 0x40 0x5 [ 1296.581403] [drm:drm_mode_debug_printmodeline], Modeline 20:640x480 75 31500 640 656 720 840 480 481 484 500 0x40 0xa [ 1296.584027] [drm:drm_mode_debug_printmodeline], Modeline 21:640x480 60 25200 640 656 752 800 480 490 492 525 0x40 0xa [ 1296.587294] [drm:drm_mode_debug_printmodeline], Modeline 22:720x400 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [ 1296.589849] [drm:drm_mode_getconnector], [CONNECTOR:5:?] [ 1296.593635] [drm:drm_mode_getconnector], [CONNECTOR:8:?] [ 1296.595157] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:HDMI-A-1] [ 1296.608219] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:HDMI-A-1] disconnected [ 1296.610732] [drm:drm_mode_getconnector], [CONNECTOR:8:?] [ 1296.611939] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:HDMI-A-1] [ 1296.624882] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:HDMI-A-1] disconnected [ 1296.627445] [drm:drm_mode_getconnector], [CONNECTOR:12:?] [ 1296.628814] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:HDMI-A-2] [ 1296.750591] [drm:drm_detect_monitor_audio], Monitor has basic audio support [ 1296.873062] [drm:drm_edid_to_eld], ELD monitor SONY TV [ 1296.874819] HDMI: DVI dual 0, max TMDS clock 5, latency present 0 0, video latency 0 81, audio latency 114 208 [ 1296.877018] [drm:drm_edid_to_eld], ELD size 8, SAD count 1 [ 1296.878468] [drm:drm_mode_debug_printmodeline], Modeline 45:1920x1080i 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 [ 1296.880862] [drm:drm_mode_prune_invalid], Not using 1920x1080i mode 7 [ 1296.882454] [drm:drm_mode_debug_printmodeline], Modeline 44:1920x1080i 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 [ 1296.885996] [drm:drm_mode_prune_invalid], Not using 1920x1080i mode 7 [ 1296.887573] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:HDMI-A-2] probed modes : [ 1296.889507] [drm:drm_mode_debug_printmodeline], Modeline 37:1920x1080 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x48 0x5 [ 1296.892084] [drm:drm_mode_debug_printmodeline], Modeline 43:1280x720 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5 [ 1296.894657] [drm:drm_mode_debug_printmodeline], Modeline 41:1280x720 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 [ 1296.897053] [drm:drm_mode_debug_printmodeline], Modeline 32:720x576 50 27000 720 732 796 864 576 581 586 625 0x40 0xa [ 1296.899603] [drm:drm_mode_debug_printmodeline], Modeline 29:720x480 60 27000 720 736 798 858 480 489 495 525 0x40 0xa [ 1296.901979] [drm:drm_mode_getconnector], [CONNECTOR:12:?] [ 1296.906084] [drm:drm_mode_getconnector], [CONNECTOR:13:?] [ 1296.907545] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:DP-1] [ 1296.909659] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e [ 1296.913429] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e [ 1296.917418] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e [ 1296.920908] [drm:intel_dp_detect], DPCD: [ 1296.922663] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:DP-1] disconnected [ 1296.924543] [drm:drm_mode_getconnector], [CONNECTOR:13:?] [ 1296.925793] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:DP-1] [ 1296.927920] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e [ 1296.931393]
Re: [Intel-gfx] [PATCH 01/13] drm/i915: fall through pwrite_gtt_slow to the shmem slow path
On Sun, 6 Nov 2011 20:13:48 +0100 Daniel Vetter daniel.vet...@ffwll.ch wrote: The gtt_pwrite slowpath grabs the userspace memory with get_user_pages. This will not work for non-page backed memory, like a gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit -EFAULT in the gtt paths. Now the shmem paths have exactly the same problem, but this way we only need to rearrange the code in one write path. v2: v1 accidentaly falls back to shmem pwrite for phys objects. Fixed. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch It would be nice if there was some way to notify users that pwriting a gtt mmapped address can be really damn slow. That's also the one behavior change this patch introduces. It's possible that some SW was expecting to get a, fast path and would deal with the -EFAULT if it didn't get it. Presumably subsequent patches in this series fix this up further, so instead of figuring out all the failure conditions pwrite can cause, let's just go with Acked-by: Ben Widawsky b...@bwidawsk.net ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Bug#649448: udev loading radeon drivers garbles screen output
On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote: reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3 severity 649448 important retitle 649448 radeon (evergreen): random-looking pattern of pixels when firmware not installed tags 649448 + upstream quit Hi Martin, Martin von Gagern wrote: Version: 3.0.0-3 [...] Just installed a wheezy setup using debootstrap, adding grub-pc and linux-image-amd64 after the chroot was created. The kernel boots, the initrd seems all right. When the main system boots up, udev gets launced pretty early. Soon after it is started, the screen turns into a pretty random-looking pattern of pixels, making the console pretty unusable. This also happens in recovery i.e. single-user mode. [...] Possible workarounds seem to include: [...] - Adding a line blacklist radeon to /etc/modprobe.d/blacklist.conf, followed by running depmod -a. [...] [ 150.125768] r600_cp: Failed to load firmware radeon/SUMO2_pfp.bin [ 150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 150.125859] radeon :00:01.0: disabling GPU acceleration Yes, the radeon driver currently copes poorly when firmware is missing. Compare [1], [2], [3]. [...] Not having GPU accelleration due to lack of free firmware is acceptable. Not having a usable text console can be a real problem. Agreed. The radeon driver should be bailing out when firmware is missing for cards that need it, but that is not working for some reason. [...] At the time I converted the radeon driver to load external firmware, it was apparently only required for 3D acceleration and both KMS and 2D acceleration of X worked without it, at least on those systems I tested (which were quite old, R100-R300 families). Therefore failure to load firmware would only result in DRM (3D acceleration support) being disabled. However, it looks like driver support for the R600 family onward now absolutely requires the 'RLC' firmware blobs: commit d8f60cfc93452d0554f6a701aa8e3236cbee4636 Author: Alex Deucher alexdeuc...@gmail.com Date: Tue Dec 1 13:43:46 2009 -0500 drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3) And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the 'MC' firmware blobs: commit 0af62b0168043896a042b005ff88caa77dd94d04 Author: Alex Deucher alexdeuc...@gmail.com Date: Thu Jan 6 21:19:31 2011 -0500 drm/radeon/kms: add ucode loader for NI Therefore I think that at least r600_init(), rv770_init(), evergreen_init() and cayman_init() should be treating failure to load firmware as a fatal error. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
On Sun, 6 Nov 2011 20:13:49 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 126
---
1 files changed, 64 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6fa24bc..f9efebb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -58,6 +58,7 @@ static void i915_gem_free_object_tail(struct
drm_i915_gem_object *obj);
static int i915_gem_inactive_shrink(struct shrinker *shrinker,
struct shrink_control *sc);
+static void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
/* some bookkeeping */
static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
@@ -385,6 +386,32 @@ i915_gem_shmem_pread_fast(struct drm_device *dev,
return 0;
}
+static inline int
+__copy_from_user_swizzled(char __user *gpu_vaddr, int gpu_offset,
+ const char *cpu_vaddr,
+ int length)
+{
+ int ret, cpu_offset = 0;
+
+ while (length 0) {
+ int cacheline_end = ALIGN(gpu_offset + 1, 64);
+ int this_length = min(cacheline_end - gpu_offset, length);
+ int swizzled_gpu_offset = gpu_offset ^ 64;
+
+ ret = __copy_from_user(gpu_vaddr + swizzled_gpu_offset,
+cpu_vaddr + cpu_offset,
+this_length);
+ if (ret)
+ return ret + length;
+
+ cpu_offset += this_length;
+ gpu_offset += this_length;
+ length -= this_length;
+ }
+
+ return 0;
+}
+
Bikeshed, but I would much prefer a #define for the swizzle
bit/cacheline size.
/**
* This is the fallback shmem pread path, which allocates temporary storage
* in kernel space to copy_to_user into outside of the struct_mutex, so we
@@ -841,71 +868,36 @@ i915_gem_shmem_pwrite_slow(struct drm_device *dev,
struct drm_file *file)
{
struct address_space *mapping =
obj-base.filp-f_path.dentry-d_inode-i_mapping;
- struct mm_struct *mm = current-mm;
- struct page **user_pages;
ssize_t remain;
- loff_t offset, pinned_pages, i;
- loff_t first_data_page, last_data_page, num_pages;
- int shmem_page_offset;
- int data_page_index, data_page_offset;
- int page_length;
- int ret;
- uint64_t data_ptr = args-data_ptr;
- int do_bit17_swizzling;
+ loff_t offset;
+ char __user *user_data;
+ int shmem_page_offset, page_length, ret;
+ int obj_do_bit17_swizzling, page_do_bit17_swizzling;
+ user_data = (char __user *) (uintptr_t) args-data_ptr;
remain = args-size;
- /* Pin the user pages containing the data. We can't fault while
- * holding the struct mutex, and all of the pwrite implementations
- * want to hold it while dereferencing the user data.
- */
- first_data_page = data_ptr / PAGE_SIZE;
- last_data_page = (data_ptr + args-size - 1) / PAGE_SIZE;
- num_pages = last_data_page - first_data_page + 1;
-
- user_pages = drm_malloc_ab(num_pages, sizeof(struct page *));
- if (user_pages == NULL)
- return -ENOMEM;
-
- mutex_unlock(dev-struct_mutex);
- down_read(mm-mmap_sem);
- pinned_pages = get_user_pages(current, mm, (uintptr_t)args-data_ptr,
-
[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver
On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
or DP_AUDIO_OUTPUT_ENABLE accordingly. So that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.
A new callback -hotplug() is added to struct drm_connector_funcs which
will be called immediately after -detect() knowing that the monitor is
either plugged or unplugged.
It's noticed that X may not call -mode_set() at monitor hot plug, so it's
necessary to call drm_edid_to_eld() earlier at -detect() time rather than
in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
in -hotplug.
The call sequence on hot plug is
(the difference part lies in -mode_set vs -hotplug)
- KMS console
-detect
drm_edid_to_eld
-mode_set
intel_write_eld
set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- X
-detect
drm_edid_to_eld
-hotplug
intel_write_eld
set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
On hot remove, the call sequence is
-hotplug
clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
cc: Wang Zhenyu zhenyu.z.w...@intel.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/drm_crtc_helper.c |5 ++-
drivers/gpu/drm/i915/intel_dp.c| 44 +--
drivers/gpu/drm/i915/intel_hdmi.c | 31 +++
drivers/gpu/drm/i915/intel_modes.c |2 -
include/drm/drm_crtc.h |1
5 files changed, 71 insertions(+), 12 deletions(-)
--- linux.orig/drivers/gpu/drm/i915/intel_dp.c 2011-11-21 11:26:09.0
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c 2011-11-21 14:12:21.0
+0800
@@ -28,6 +28,7 @@
#include linux/i2c.h
#include linux/slab.h
#include linux/export.h
+#include drm/drm_edid.h
#include drmP.h
#include drm.h
#include drm_crtc.h
@@ -1970,20 +1971,44 @@ intel_dp_detect(struct drm_connector *co
if (status != connector_status_connected)
return status;
- if (intel_dp-force_audio) {
- intel_dp-has_audio = intel_dp-force_audio 0;
- } else {
- edid = intel_dp_get_edid(connector, intel_dp-adapter);
- if (edid) {
- intel_dp-has_audio = drm_detect_monitor_audio(edid);
- connector-display_info.raw_edid = NULL;
- kfree(edid);
- }
+ edid = intel_dp_get_edid(connector, intel_dp-adapter);
+ if (edid) {
+ intel_dp-has_audio = drm_detect_monitor_audio(edid);
+ drm_edid_to_eld(connector, edid);
+ connector-display_info.raw_edid = NULL;
+ kfree(edid);
}
+ if (intel_dp-force_audio)
+ intel_dp-has_audio = intel_dp-force_audio 0;
+
return connector_status_connected;
}
+static void intel_dp_hotplug(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_device *dev = intel_dp-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = intel_dp-base.base.crtc;
+
+ DRM_DEBUG_DRIVER(DisplayPort hotplug status %d crtc %p eld %#x\n,
+connector-status,
+crtc,
+(unsigned int)connector-eld[0]);
+
+ if (connector-status == connector_status_disconnected) {
+ intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
+ } else if (connector-status == connector_status_connected crtc) {
+ intel_write_eld(intel_dp-base.base, crtc-mode);
+ intel_dp-DP |= DP_AUDIO_OUTPUT_ENABLE;
+ } else {
+ return;
+ }
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2168,7 @@ static const struct drm_connector_funcs
.detect = intel_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = intel_dp_set_property,
+ .hotplug = intel_dp_hotplug,
.destroy = intel_dp_destroy,
};
--- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c2011-11-21
11:26:09.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_hdmi.c 2011-11-21 14:12:26.0
+0800
@@ -337,6 +337,7 @@ intel_hdmi_detect(struct drm_connector *
status = connector_status_connected;
intel_hdmi-has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
intel_hdmi-has_audio = drm_detect_monitor_audio(edid);
+ drm_edid_to_eld(connector, edid);
}
connector-display_info.raw_edid = NULL;
kfree(edid);
@@ -350,6 +351,35 @@ intel_hdmi_detect(struct drm_connector *
return
