not skip to error paths after
> that. Other drivers do this the same for out-fence and similar things.
>
> Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> Cc: Rob Clark
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Chri
On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> >
> > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
> > >
> > > Originally drm_sched_job_init was the point of no return, after which
> > &g
On Fri, Aug 6, 2021 at 11:41 AM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
> >
> > On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter wrote:
> > >
> > > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> > > >
>
On Fri, Aug 6, 2021 at 12:11 PM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 8:57 PM Rob Clark wrote:
> >
> > On Fri, Aug 6, 2021 at 11:41 AM Daniel Vetter
> > wrote:
> > >
> > > On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
> > > >
On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote:
>
> - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT,
> but because it doesn't use the drm/scheduler it handles fences from
> the wrong context with a synchronous dma_fence_wait. See
> submit_fence_sync() leading to ms
rm_sched_job doesn't escape anywhere at all.
>
> For robustness it's still better to align with other drivers here and
> not bail out after job_arm().
>
> v3: I misplaced drm_sched_job_arm by _one_ line! Thanks to Rob for
> testing and debug help.
>
> Cc: Rob Clark
> C
On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
>
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
t seem to care much,
> - and it probably makes sense to lift this into dma-resv.c code as a
> proper concept, so that drivers don't have to hack up their own
> solution each on their own.
>
> v2: Improve commit message per Lucas' suggestion.
>
> Cc: Lucas Stach
't seem to care much,
> - and it probably makes sense to lift this into dma-resv.c code as a
> proper concept, so that drivers don't have to hack up their own
> solution each on their own.
>
> v2: Improve commit message per Lucas' suggestion.
>
> Cc: Lucas Stach
On Tue, Jul 13, 2021 at 9:58 AM Daniel Vetter wrote:
>
> On Tue, Jul 13, 2021 at 6:51 PM Rob Clark wrote:
> >
> > On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter
> > wrote:
> > >
> > > There's only one exclusive slot, and we must not break the ord
On Tue, Apr 9, 2019 at 8:27 AM Eric Engestrom wrote:
>
> On Tuesday, 2019-04-09 12:59:13 +0100, Eric Engestrom wrote:
> > On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> > > Generated using make headers_install from the drm-next
> > > tree - git://anongit.freedesktop.org/drm/drm
> > >
On Tue, Jul 19, 2016 at 1:19 PM, Matt Roper wrote:
> On Tue, Jul 19, 2016 at 12:30:56PM -0400, Lyude wrote:
>> Now that we update the watermark values atomically, we still need to fix
>> the case of how we update watermarks when we haven't added or removed
>> pipes.
>>
>> When we haven't added or
On Tue, Sep 3, 2019 at 12:07 PM Daniel Vetter wrote:
>
> The -modesetting ddx has a totally broken idea of how atomic works:
> - doesn't disable old connectors, assuming they get auto-disable like
> with the legacy setcrtc
> - assumes ASYNC_FLIP is wired through for the atomic ioctl
> - not a si
On Fri, Sep 13, 2019 at 4:52 AM Jani Nikula wrote:
>
> Allow better abstraction of the drm_debug global variable in the
> future. No functional changes.
>
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
>
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker driv
On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko
wrote:
>
> On 6/19/22 20:53, Rob Clark wrote:
> ...
> >> +static unsigned long
> >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> >> +struct shrink_cont
()
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker
On Tue, Jun 28, 2022 at 5:51 AM Dmitry Osipenko
wrote:
>
> On 6/28/22 15:31, Robin Murphy wrote:
> > ->8-
> > [ 68.295951] ==
> > [ 68.295956] WARNING: possible circular locking dependency detected
> > [ 68.295963] 5.19.0-rc3+ #400
From: Rob Clark
drive-by cleanup
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 319936f91ac5
On Thu, Nov 4, 2021 at 8:04 PM Sean Paul wrote:
>
> From: Sean Paul
>
> Just me with another revision of HDCP support for msm.
>
> This v4 patch series is mostly a retread of v3 with the following
> changes:
> - rebased on Bjorn's displayport-controller register refactor
> - another change to the
On Thu, Nov 4, 2021 at 8:05 PM Sean Paul wrote:
>
> From: Sean Paul
>
> This patch adds the register ranges required for HDCP key injection and
> HDCP TrustZone interaction as described in the dt-bindings for the
> sc7180 dp controller. Now that these are supported, change the
> compatible string
On Sun, Jun 5, 2022 at 9:47 AM Daniel Vetter wrote:
>
> On Fri, 27 May 2022 at 01:55, Dmitry Osipenko
> wrote:
> >
> > Introduce a common DRM SHMEM shrinker framework that allows to reduce
> > code duplication among DRM drivers by replacing theirs custom shrinker
> > implementations with the gene
gt; >>>> drm-engine-video-enhance: 0 ns
> >>>>
> >>>> v2:
> >>>>* Update for removal of name and pid.
> >>>>
> >>>> v3:
> >>>>* Use drm_driver.name.
> >>>>
> >>
t; thing missing afaict.
>
> v4: Fixup i915 fixup ...
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> References:
> https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> Cc
> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > References:
> > https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > Cc: Maxime Ripard
> > Tested-by: Maxime
On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar wrote:
>
> Hi Rob and Daniel
>
> On 4/7/2022 3:51 PM, Rob Clark wrote:
> > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang
> > wrote:
> >>
> >>
> >>
> >> On 3/31/2022 8:20 AM, Daniel Vetter w
On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
>
> On Wed, 02 Feb 2022, Laurent Pinchart
> wrote:
> > Hi Jani,
> >
> > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> >> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj
to
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Chris Healy
> Acked-by: Christian König
> Reviewed-by: Umesh Nerlige Ramappa # v3
Acked-by: Rob Clark
> ---
> Documentation/gpu/drm-usage-stats.rst | 6 ++
> Documentation/gpu/i915.rst | 28 +
>
On Wed, Jan 19, 2022 at 7:09 AM Daniel Vetter wrote:
>
> On Thu, Jan 06, 2022 at 04:55:35PM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Proposal to standardise the fdinfo text format as optionally output by DRM
> > drivers.
> >
> > Idea is that a simple but, well defined, spec w
me to revisit the
struct_mutex usage since we moved to per-object-locks.. the downside,
I suppose, of kernel generally working ok and this not being a big
enough fire to bubble up to the top of my todo list
BR,
-R
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
>
using struct_mutex, it seems to be using
> dma_resv_lock for general buffer state protection?
>
> v2:
> - Add comment to explain why the ww ticket setup is separate (Rob)
> - Fix up error handling, we need to make sure we don't call
> ww_acquire_fini without _init.
>
>
On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
>
> On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > pre-merge CI.
>
> Thanks for the suggestion! I implemented something like this for Mesa:
>
> https://gitlab.freedesk
On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote:
>
> Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI onl
On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote:
>
> On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote:
> >
> > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > > On
On Sat, Apr 4, 2020 at 11:41 AM Rob Clark wrote:
>
> On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote:
> >
> > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne
> > wrote:
> > >
> > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> >
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote:
>
> On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI only
On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote:
>
> On 2020-04-06 6:34 p.m., Rob Clark wrote:
> >
> > The ideal thing would be to be able to click any jobs that we want to
> > run, say "arm64_a630_gles31", and for gitlab to realize that it needs
> >
From: Rob Clark
The driver should be in control of this.
Signed-off-by: Rob Clark
---
It is possible that this was masking bugs (ie. not setting appropriate
pgprot) in drivers. I don't have a particularly good idea for tracking
those down (since I don't have the hw for most drivers
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 10 ++
drivers/gpu/drm/drm_gem_vram_helper.c | 6 --
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/etnaviv
From: Rob Clark
Since there is no real device associated with VGEM, it is impossible to
end up with appropriate dev->dma_ops, meaning that we have no way to
invalidate the shmem pages allocated by VGEM. So, at least on platforms
without drm_cflush_pages(), we end up with corruption when ca
From: Rob Clark
The driver should be in control of this.
Signed-off-by: Rob Clark
---
It is possible that this was masking bugs (ie. not setting appropriate
pgprot) in drivers. I don't have a particularly good idea for tracking
those down (since I don't have the hw for most drivers
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
v3: rebased on drm-tip
drivers/gpu/drm/drm_gem.c | 8
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c | 4
From: Rob Clark
Since there is no real device associated with VGEM, it is impossible to
end up with appropriate dev->dma_ops, meaning that we have no way to
invalidate the shmem pages allocated by VGEM. So, at least on platforms
without drm_cflush_pages(), we end up with corruption when ca
On Tue, Jul 16, 2019 at 4:39 PM Eric Anholt wrote:
>
> Rob Clark writes:
>
> > From: Rob Clark
> >
> > Since there is no real device associated with VGEM, it is impossible to
> > end up with appropriate dev->dma_ops, meaning that we have no way to
> &g
On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter wrote:
>
> The stuff never really worked, and leads to lots of fun because it
> out-of-order frees atomic states. Which upsets KASAN, among other
> things.
>
> For async updates we now have a more solid solution with the
> ->atomic_async_check and ->at
On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote:
>
> On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter wrote:
> >
> > The stuff never really worked, and leads to lots of fun because it
> > out-of-order frees atomic states. Which upsets KASAN, among other
> > things.
&g
On Thu, Oct 22, 2020 at 12:16 PM Daniel Vetter wrote:
>
> On Thu, Oct 22, 2020 at 7:22 PM Rob Clark wrote:
> >
> > On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote:
> > >
> > > On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter
> > > wrote:
> > &
On Fri, Oct 23, 2020 at 9:00 AM Daniel Vetter wrote:
>
> On Fri, Oct 23, 2020 at 5:02 PM Rob Clark wrote:
> >
> > On Thu, Oct 22, 2020 at 12:16 PM Daniel Vetter
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 7:22 PM Rob Clark wrote:
> > > &
ly also disallow get_vaddr() on imported buffers.
BR,
-R
>
> But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by
> calling dma_buf_vmap is the wrong thing to do.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: linux-arm-...@vg
On Mon, May 11, 2020 at 8:29 AM Daniel Vetter wrote:
>
> On Mon, May 11, 2020 at 5:24 PM Rob Clark wrote:
> >
> > On Mon, May 11, 2020 at 2:36 AM Daniel Vetter
> > wrote:
> > >
> > > I honestly don't exactly understand what's going on he
On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote:
>
> On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
> >
> > We could also do stuff like reducing the amount of tests we run on each
> > commit, and punt some testing to a per-weekend test-run or someting
> > like that. We don't *need* to know ab
t since this involves the board and lots more
> people it'll take a while to get there. For now this is good enough I
> think.
s/includs/includes/
But spelling aside,
Acked-by: Rob Clark
> For the text itself I went with the same blurb as the Wayland project,
> didn't feel
On Sun, Aug 14, 2016 at 8:02 PM, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
>
> I moved the main bits to be the first diffs, shouldn't affect anything
> when applying the patch, but I wanted to ask:
> I don't like the hard-coded `32` the appears in both kmalloc() and
> snprintf()
On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom wrote:
> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
>> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
>> > +typedef char drm_format_name_buf[32];
>>
>> Please don't use a typedef for this, just define the maximum size of
>> charac
On Sun, Nov 6, 2016 at 4:47 AM, Christian König
wrote:
> Am 05.11.2016 um 17:49 schrieb Rob Clark:
>>
>> On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom wrote:
>>>
>>> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
>>>>
>&
]
> Signed-off-by: Daniel Vetter
>
> Cc: Rob Clark
> Cc: Christian König
> Suggested-by: Ville Syrjälä
> Signed-off-by: Eric Engestrom
Thanks,
Acked-by: Rob Clark
> ---
>
> v2: use single-field struct instead of typedef to let the compiler
> enforc
On Tue, Feb 23, 2016 at 9:33 PM, Thulasimani, Sivakumar
wrote:
>
>
> On 2/24/2016 3:41 AM, Lyude wrote:
>>
>> As it turns out, resuming DP MST is racey since we don't make sure MST
>> is ready before we start modesetting, it just usually happens to be
>> ready in time. This isn't the case on all s
On Feb 29 2016 or thereabouts, Daniel Vetter wrote:
> On Mon, Feb 22, 2016 at 02:22:49PM -0500, Lyude wrote:
> > These warnings still seem to be present with DP MST configurations. They
> > don't actually indicate any impending doom, so we may as well use
> > I915_STATE_WARN_ON() here to help quiet
On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>>
>>
>> On 2/24/2016 3:41 AM, Lyude wrote:
>> >As it turns out, resuming DP MST is racey since we don't make sure MST
>> >is ready before we start modesetting, it just
On Mon, Feb 29, 2016 at 7:47 PM, Thulasimani, Sivakumar
wrote:
>
>
> On 3/1/2016 5:03 AM, Rob Clark wrote:
>>
>> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
>>>
>>> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>>&
On Wed, Mar 2, 2016 at 4:29 AM, Daniel Vetter wrote:
> On Mon, Feb 29, 2016 at 06:33:42PM -0500, Rob Clark wrote:
>> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
>> > On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>> >>
>>
On Fri, Mar 11, 2016 at 5:07 AM, Timo Aaltonen wrote:
> 29.02.2016, 16:47, Hans de Goede kirjoitti:
>> sna has no meaningfull accel for gen9+, this causes problems with i.e.
>> apps using XVideo since the sprite XVideo support does not work well
>> for many apps.
>>
>> Therefor it is better to jus
yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh
git urls for folks who have push access work fine).. although it has
worked for me a couple times today, given enough time.
(not sure if we have github/etc mirrors somewhere? I do have a github
clone of mesa which is up to dat
; need to handle such conversion in the caller. The only challenge are
>> those callers that wish to differentiate the error code between the
>> nonblocking busy check and potentially blocking wait.
>>
>> v2: 9 is only 0 in German.
>>
>> Signed-off-by: Chris Wilson
>&g
e [2]).
>
> msm and omap still lack r-bs/acks.
>
> Entire series available here:
> git://github.com/vsyrjala/linux.git chv_mirror_4
>
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Jilai Wang
> Cc: Archit Taneja
>
> Ville Syrjälä (15):
> drm: Add drm_rotat
On Mon, Feb 6, 2017 at 1:23 PM, Daniel Stone wrote:
> Hi,
>
> On 6 February 2017 at 17:59, Daniel Vetter wrote:
>> On Mon, Feb 06, 2017 at 10:39:28AM -0700, Jordan Crouse wrote:
>>> This initial series implements 4 ringbuffers to give sufficient coverage
>>> for the
>>> range of priority levels
On Fri, Oct 16, 2015 at 12:23 PM, Daniel Vetter wrote:
> In
>
> commit bbb1e52402b2a288b09ae37e8182599931c7e9df
> Author: Rob Clark
> Date: Tue Aug 25 15:35:58 2015 -0400
>
> drm/fb-helper: atomic restore_fbdev_mode()..
>
> we've forgotten to do the
t;>> Feature originally added in:
>>>
>>> commit e3eb3250d84ef97b766312345774367b6a310db8
>>> Author: Rob Clark
>>> Date: Thu Feb 5 14:41:52 2015 +
>>>
>>> drm: add support for tiled/compressed/etc modifier in addfb2
>>&
On Wed, May 17, 2017 at 8:00 PM, Ben Widawsky wrote:
> On 17-05-17 13:31:44, Daniel Vetter wrote:
>>
>> On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
>>>
>>> On 17-05-03 17:08:27, Daniel Vetter wrote:
>>> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>>> > > +stru
On Wed, May 17, 2017 at 8:38 PM, Rob Clark wrote:
> On Wed, May 17, 2017 at 8:00 PM, Ben Widawsky wrote:
>> On 17-05-17 13:31:44, Daniel Vetter wrote:
>>>
>>> On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
>>>>
>>>> On 17-05-03 1
On Tue, Feb 28, 2017 at 7:55 AM, Joe Perches wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches
for drm/msm part:
Acked-by: Rob Clark
> --
On Thu, Dec 22, 2016 at 11:07 PM, Mark yao wrote:
> Hi Chris Wilson
>
> We port drm_mm to my internal kernel, with high load test, found following
> crash:
>
> [49451.856244]
> ==
> [49451.856350] BUG: KASAN: wild-memory-access on add
On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky wrote:
>
> +struct drm_format_modifier {
> + /* Bitmask of formats in get_plane format list this info
> +* applies to. */
> + uint64_t formats;
re: the uabi, I'd suggest to at least make this 'u32 offset; u32
formats'.. we can keep
On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
wrote:
> On Wed, Jan 11, 2017 at 08:43:16PM -0500, Rob Clark wrote:
>> On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky wrote:
>> >
>> > +struct drm_format_modifier {
>> > + /* Bitmask of format
therwise) to
> systemd-logind.
> """
>
> v2:
> * Fixed typo in commit text and added a fine historical explanation
>from Emil.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: "Christian König"
> Cc: Daniel Vetter
> Acked-by: Christian
so skip on inactive crtc (Ville)
>
> Link:
> https://lore.kernel.org/dri-devel/dfc21f18-7e1e-48f0-c05a-d659b9c90...@linaro.org/
> Fixes: d39e48ca80c0 ("drm/atomic-helper: Set fence deadline for vblank")
> Cc: Ville Syrjälä
> Cc: Rob Clark
> Cc: Daniel Vetter
> Cc:
_gpu_top does not do.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Rob Clark
> Cc: Christian König
> Acked-by: Christian König
Reviewed-by: Rob Clark
> ---
> tools/gputop.c| 260 ++
> tools/meson.build | 5 +
> 2 fil
On Thu, Apr 6, 2023 at 4:08 AM Tvrtko Ursulin
wrote:
>
>
> On 05/04/2023 18:57, Rob Clark wrote:
> > On Tue, Jan 31, 2023 at 3:33 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Rudimentary vendor agnostic example
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 3 ++-
drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 3 ++-
drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915
On Thu, Apr 13, 2023 at 6:07 AM Tvrtko Ursulin
wrote:
>
>
> On 12/04/2023 23:42, Rob Clark wrote:
> > From: Rob Clark
>
> There is more do to here to remove my client->id fully (would now be
> dead code) so maybe easiest if you drop this patch and I do it after you
&g
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Add support to dump GEM stats to fdinfo.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> Documentation/gpu/drm-usage-stats.rst | 12 +++
> drivers/gpu/drm/drm_file.c| 52 +++
> i
On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
wrote:
>
>
> On 17/04/2023 20:39, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Add support to dump GEM
On Tue, Apr 18, 2023 at 3:47 AM Tvrtko Ursulin
wrote:
>
>
> On 17/04/2023 17:20, Christian König wrote:
> > Am 17.04.23 um 17:56 schrieb Tvrtko Ursulin:
> >> From: Tvrtko Ursulin
> >>
> >> Add support to dump GEM stats to fdinfo.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> Documentat
On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 14:49, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 17/04/2023 20:39, Rob Clark wrote:
> >>>
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Show how more driver specific set of memory stats could be shown,
> more specifically where object can reside in multiple regions, showing all
> the supported stats, and where there is more to show than just user v
On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 15:39, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Show how more driver specific set of
On Tue, Apr 18, 2023 at 7:46 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 15:36, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 18/04/2023 14:49, Rob Clark wrote:
> >>>
On Tue, Apr 18, 2023 at 9:44 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 17:13, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 7:46 AM Tvrtko Ursulin
> > wrote:
> >> On 18/04/2023 15:36, Rob Clark wrote:
> >>> On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursuli
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> For drivers who only wish to show one memory region called 'system,
> and only account the GEM buffer object handles under it.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/drm_file.c | 45 +++
On Wed, Apr 19, 2023 at 6:16 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 18:18, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> For drivers who only wish to show on
On Wed, Apr 19, 2023 at 7:06 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 17:08, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
> > wrote:
> >> On 18/04/2023 15:39, Rob Clark wrote:
> >>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursuli
On Thu, Apr 20, 2023 at 6:14 AM Tvrtko Ursulin
wrote:
>
>
> On 19/04/2023 15:32, Rob Clark wrote:
> > On Wed, Apr 19, 2023 at 6:16 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 18/04/2023 18:18, Rob Clark wrote:
> >>>
On Thu, Apr 20, 2023 at 6:11 AM Tvrtko Ursulin
wrote:
>
>
> On 19/04/2023 15:38, Rob Clark wrote:
> > On Wed, Apr 19, 2023 at 7:06 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 18/04/2023 17:08, Rob Clark wrote:
> >>> On Tue, Apr 18,
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency accordingly. An immediate deadline can be
>>
> >> Objects with multiple possible placements are reported in multiple regions
> >> for
> >> total and shared sizes, while other categories are counted only for the
> >> currently active region.
> >>
> >> Signed-off-by: Tvrtko Ursulin
On Fri, Jun 9, 2023 at 7:12 AM Tvrtko Ursulin
wrote:
>
>
> On 09/06/2023 13:44, Iddamsetty, Aravind wrote:
> > On 09-06-2023 17:41, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> I need a new flavour of the drm_gem_prime_fd_to_handle helper, one which
> >> will return a reference to a
From: Rob Clark
Because eb_composite_fence_create() drops the fence_array reference
after creation of the sync_file, only the sync_file holds a ref to the
fence. But fd_install() makes that reference visable to userspace, so
it must be the last thing we do with the fence.
Signed-off-by: Rob
1 - 100 of 239 matches
Mail list logo
