On Fri, 21 Apr 2023 at 12:23, Tvrtko Ursulin
wrote:
> On 21/04/2023 11:26, Emil Velikov wrote:
> > On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
> >
> >> +/**
> >> + * enum drm_gem_object_status - bitmask of object state for fdinfo
> >> reporting
&g
ly_
> + * become puregeable until it becomes idle. The status gem object func does
nit: s/puregeable/purgeable/
I think we want a similar note in the drm-usage-stats.rst file.
With the above the whole series is:
Reviewed-by: Emil Velikov
Fwiw: Keeping the i915 patch as part of this ser
? Consistency across drivers and all that.
>
> Hmm, I guess I could _also_ store the overridden comm/cmdline in
> drm_file. I still need to track it in ctx (msm_file_private) because
> I could need it after the file is closed.
>
> Maybe it could be useful to have a gl extension to let the app set a
> name on the context so that this is useful beyond native-ctx (ie.
> maybe it would be nice to see that "chrome: lwn.net" is using less gpu
> memory than "chrome: phoronix.com", etc)
>
/me awaits for the series to hit the respective websites ;-)
But seriously - the series from Tvrtko (thanks for the link, will
check in a moment) makes sense. Although given the livespan issue
mentioned above, I don't think it's applicable here.
So if it were me, I would consider the two orthogonal for the
short/mid term. Fwiw this and patch 1/3 are:
Reviewed-by: Emil Velikov
HTH
-Emil
DRIVER_RENDER |
> DRIVER_ATOMIC |
> DRIVER_MODESET |
> + DRIVER_SYNCOBJ_TIMELINE |
This line should probably be its own patch. AFAICT it was supported
since ab723b7a992a19b843f798b183f53f7472f598c8, although explicitly
kept disabled until there's userspace/turnip support.
With the above line removed, the patch is:
Reviewed-by: Emil Velikov
HTH
Emil
s &= ~DRM_GEM_OBJECT_PURGEABLE;
Is MSM capable of marking the object as both purgeable and resident or
is this to catch other drivers? Should we add a note to the
documentation above - resident memory cannot be purgeable
> + }
> +
> + if (s & DRM_GEM_OBJECT_ACTIVE) {
> + size.active += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
Ditto.
With the above nits, the patch is:
Reviewed-by: Emil Velikov
HTH
Emil
On Tue, 2 Jun 2020 at 17:10, Sai Prakash Ranjan
wrote:
>
> Hi Emil,
>
> On 2020-06-02 21:09, Emil Velikov wrote:
> > On Tue, 2 Jun 2020 at 15:49, Sai Prakash Ranjan
> > wrote:
> >>
> >> Hi Emil,
> >>
> >> On 2020-06-02 19:43, Emil V
On Tue, 2 Jun 2020 at 15:49, Sai Prakash Ranjan
wrote:
>
> Hi Emil,
>
> On 2020-06-02 19:43, Emil Velikov wrote:
> > Hi Krishna,
> >
> > On Tue, 2 Jun 2020 at 08:17, Krishna Manikandan
> > wrote:
> >>
> >> Define shutdown callback for displa
Hi Krishna,
On Tue, 2 Jun 2020 at 08:17, Krishna Manikandan wrote:
>
> Define shutdown callback for display drm driver,
> so as to disable all the CRTCS when shutdown
> notification is received by the driver.
>
> This change will turn off the timing engine so
> that no display transactions are re
t; Cc: Sean Paul
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä
Perhaps the msm team has a WIP which makes use of it ?
Otherwise:
Reviewed-by: Emil Velikov
-Emil
___
Freedreno mailing
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
- already handled in hdmi/sor
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 6 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 12 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 6 +-
> drivers/gpu/drm/zte/zx_vga.c | 6 +-
> include/drm/drm_co
t;
> Signed-off-by: Fuqian Huang
This patch is:
Reviewed-by: Emil Velikov
I think you want to add Jordan's ack-by from [1]
-Emil
[1] https://lists.freedesktop.org/archives/dri-devel/2019-July/224928.html
___
Freedreno mailing list
Freedreno@l
On Fri, 28 Jun 2019 at 17:45, Daniel Vetter wrote:
>
> On Fri, Jun 28, 2019 at 06:01:14PM +0200, Andrzej Pietrasiewicz wrote:
> > It is difficult for a user to know which of the i2c adapters is for which
> > drm connector. This series addresses this problem.
> >
> > The idea is to have a symbolic
On Mon, 1 Jul 2019 at 13:37, Emil Velikov wrote:
>
> Hi Fuqian,
>
> On Mon, 1 Jul 2019 at 08:13, Fuqian Huang wrote:
> >
> > Using dev_get_drvdata directly.
> >
> > Signed-off-by: Fuqian Huang
> > ---
> > drivers/gpu/drm/msm/adreno/adreno_device.
Hi Fuqian,
On Mon, 1 Jul 2019 at 08:13, Fuqian Huang wrote:
>
> Using dev_get_drvdata directly.
>
> Signed-off-by: Fuqian Huang
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
> drivers/gpu/drm/msm/disp/m
On 2019/06/14, Daniel Vetter wrote:
> Split out to make the functional changes stick out more.
>
Since this patch flew-by, as standalone one (intentionally or not) I'd
add, anything vaguely like:
"Core users of DRIVER_PRIME were removed from core with prior patches."
HTH
Emil
___
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Rob Clark
Cc: Sean Paul
Cc: freedreno@lists.freedesktop.org
Cc: David Airlie
Cc
2 +-
> drivers/gpu/drm/vc4/vc4_drv.c| 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> drivers/staging/vboxvideo/vbox_drv.c | 2 +-
Local grep shows one more non-legacy entry in
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
With that file addressed and trivial
On Tue, 30 Oct 2018 at 18:15, Rob Clark wrote:
>
> On Tue, Oct 30, 2018 at 1:34 PM Emil Velikov wrote:
> >
> > On Tue, 30 Oct 2018 at 17:19, Rob Clark wrote:
> > > On Tue, Oct 30, 2018 at 11:27 AM Emil Velikov
> > > wrote:
> >
> > > > >
On Tue, 30 Oct 2018 at 17:19, Rob Clark wrote:
> On Tue, Oct 30, 2018 at 11:27 AM Emil Velikov
> wrote:
> > > > NOTE: if bisecting a build error takes you hear, try a clean build.
> > > > There are a bunch of ways things can go wrong if you still have
&
On Thu, 25 Oct 2018 at 10:32, Eric Engestrom wrote:
>
> On Tuesday, 2018-10-23 10:49:26 -0400, mesa-dev-boun...@lists.freedesktop.org
> wrote:
> > In the pursuit of lowering driver overhead, it became clear that some
> > amount of redesign of how libdrm_freedreno constructs the submit ioctl
> > w
Hi Jordan,
I might be a bit late for the party, so consider the following jfyi.
On 24 July 2018 at 17:33, Jordan Crouse wrote:
> +void drm_puts(struct drm_printer *p, const char *str)
One could easily use the compiler to detect if drm_printf or drm_puts
should be used. See the trace_printk defi
On 28 March 2018 at 17:22, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently the error pointer returned by msm_alloc_stolen_fb gets passed
> to drm_framebuffer_remove. The latter handles only NULL pointers, thus
> a nasty crash will occur.
>
> Drop the unnecessa
From: Emil Velikov
Currently the error pointer returned by msm_alloc_stolen_fb gets passed
to drm_framebuffer_remove. The latter handles only NULL pointers, thus
a nasty crash will occur.
Drop the unnecessary fail label and the associated checks - both err and
fb will be set at this stage.
Cc
From: Emil Velikov
Currently the error pointer returned by msm_alloc_stolen_fb gets passed
to drm_framebuffer_remove. The latter handles only NULL pointers, thus
a nasty crash will occur.
Drop the unnecessary fail label and the associated checks - both err and
fb will be set at this stage.
Cc
On 22 March 2018 at 18:03, Harry Wentland wrote:
> On 2018-03-22 01:54 PM, Emil Velikov wrote:
>> Hi Ville,
>>
>> On 22 March 2018 at 15:22, Ville Syrjala
>> wrote:
>>> From: Ville Syrjälä
>>>
>>> I really just wanted to fix i915 to re
Hi Ville,
On 22 March 2018 at 15:22, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I really just wanted to fix i915 to re-enable its planes afer load
> detection (a two line patch). This is what I actually ended up with
> after I ran into a framebuffer refcount leak with said two line patch.
>
On 10 August 2017 at 20:29, Joe Kniss wrote:
> On Wed, Aug 9, 2017 at 4:13 PM, Joe Kniss wrote:
>> On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes wrote:
>>>
>>> Den 09.08.2017 01.42, skrev Joe Kniss:
Because all drivers currently use gem objects for framebuffer planes,
the virtua
Small correction: the commit title should say NoKMS (no !).
-Emil
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
From: Emil Velikov
As mentioned in the commit message, Xserver has sufficient fallbacks
when the video driver does not implement ScheduleSwap, ScheduleWaitMSC
and GetMSC.
As such we can "fake it" and advertise v4, instead of the current v3.
Cc: freedreno@lists.freedesktop.org
Cc:
PROP_
> - Updated uses of the defines to the new prefix
> - Removed include from drm_rect.c
> - Stopped using the BIT() macro
>
Reviewed-by: Emil Velikov
-Emil
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
On 13 March 2017 at 17:00, Rob Clark wrote:
> On Mon, Mar 13, 2017 at 12:43 PM, Arnd Bergmann wrote:
>> The newly added a5xx support fails to build when debugfs is diabled:
>>
>> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs'
>> has no member named 'show'
>> drivers/g
On 6 March 2017 at 20:27, Sean Paul wrote:
> Fixes the following compilation error when CONFIG_DEBUG_FS undefined:
>
> CC [M] drivers/gpu/drm/msm/adreno/a5xx_gpu.o
> ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:863:3: error: unknown field ‘show’
> specified in initializer
> ../drivers/gpu/drm/msm/ad
On 6 February 2017 at 19:57, Rob Clark wrote:
> On Mon, Feb 6, 2017 at 2:20 PM, Emil Velikov wrote:
>> Hi Jordan,
>>
>> On 6 February 2017 at 17:39, Jordan Crouse wrote:
>>> Modify the 'pad' member of struct drm_msm_gem_info to 'hint'. If the
&
Hi Jordan,
On 6 February 2017 at 17:39, Jordan Crouse wrote:
> Modify the 'pad' member of struct drm_msm_gem_info to 'hint'. If the
> user sets 'hint' to non-zero it means that they want a IOVA for the
> GEM object instead of a mmap() offset. Return the iova in the 'offset'
> member.
>
> Signed-o
there are any non-trivial commits from someone other than myself.
>
Glad to see us (almost) there :-)
Acked-by: Emil Velikov
Emil
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
37 matches
Mail list logo
