All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Gerd Hoffmann <kraxel@redhat.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: airlied@linux.ie, puck.chen@hisilicon.com,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	z.liuxinliang@hisilicon.com, hdegoede@redhat.com,
	kong.kongxinwei@hisilicon.com, ray.huang@amd.com,
	zourongrong@gmail.com, sam@ravnborg.org,
	christian.koenig@amd.com
Subject: Re: [PATCH 1/2] drm: Add drm_gem_vram_{pin/unpin}_reserved() and convert mgag200
Date: Tue, 21 May 2019 12:57:02 +0200	[thread overview]
Message-ID: <e9841344-ea79-0904-4ca7-638687cdb66d@suse.de> (raw)
In-Reply-To: <20190521103546.ehrrboraeoe2e6fh@sirius.home.kraxel.org>


[-- Attachment #1.1.1: Type: text/plain, Size: 1856 bytes --]

Hi

Am 21.05.19 um 12:35 schrieb Gerd Hoffmann:
>   Hi,
> 
>> I think would be good to have a lockdep_assert_held here for the ww_mutex.
>>
>> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
>> we call the structure tracking the fences+lock the "reservation", but the
>> naming scheme used is _lock/_unlock.
>>
>> I think would be good to be consistent with that, and use _locked here.
>> Especially for a very simplified vram helper like this one I expect that's
>> going to lead to less wtf moments by driver writers :-)
>>
>> Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align
>> more with what we now have in dma-buf.
> 
> Given that mgag200 is the only user I think the best way forward is to
> improve the mgag200 cursor handling so we can just drop the _reserved
> variants ...
> 
> When looking at mga_crtc_cursor_set() I suspect the easierst way to do
> that would be to simply pin the cursor bo's at driver_load time, then we
> don't have to bother with pinning in mga_crtc_cursor_set() at all.
> 
> Thomas, as you have test hardware, can you look into this?

Sure, that's the plan. May take a few days, though.

I'd like to see all of the locking/reservation gone from the helper API.
By using bochs' PRIME helpers, the generic console could probably be
used in mgag200 and ast. That would remove the remaining calls from
mgag200 and ast.

Best regards
Thomas


> thanks,
>   Gerd
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2019-05-21 10:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 16:27 [PATCH 0/2] Add BO reservation to GEM VRAM pin/unpin/push_to_system Thomas Zimmermann
2019-05-16 16:27 ` [PATCH 1/2] drm: Add drm_gem_vram_{pin/unpin}_reserved() and convert mgag200 Thomas Zimmermann
2019-05-16 16:27 ` Thomas Zimmermann
2019-05-20 16:19   ` Daniel Vetter
2019-05-20 16:26     ` Daniel Vetter
2019-05-20 19:24       ` Koenig, Christian
2019-05-20 19:26         ` Daniel Vetter
2019-05-20 19:24       ` Koenig, Christian
2019-05-20 16:26     ` Daniel Vetter
2019-05-21 10:35     ` Gerd Hoffmann
2019-05-21 10:57       ` Thomas Zimmermann
2019-05-21 10:57       ` Thomas Zimmermann [this message]
2019-05-21 11:35       ` Thomas Zimmermann
2019-05-21 11:35       ` Thomas Zimmermann
2019-05-21 10:35     ` Gerd Hoffmann
2019-05-16 16:27 ` [PATCH 2/2] drm: Reserve/unreserve GEM VRAM BOs from within pin/unpin functions Thomas Zimmermann
2019-05-16 16:27 ` Thomas Zimmermann
2019-05-17 11:17 ` [PATCH 0/2] Add BO reservation to GEM VRAM pin/unpin/push_to_system Gerd Hoffmann
2019-05-20 16:19   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9841344-ea79-0904-4ca7-638687cdb66d@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@linux.ie \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=kong.kongxinwei@hisilicon.com \
    --cc=kraxel@redhat.com \
    --cc=puck.chen@hisilicon.com \
    --cc=ray.huang@amd.com \
    --cc=sam@ravnborg.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=z.liuxinliang@hisilicon.com \
    --cc=zourongrong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.