Hi Tvrtko
Sorry for the delay, real life and other obligations got in the way.
On Thu, 8 Jun 2023 at 15:26, Tvrtko Ursulin
wrote:
> On 21/04/2023 13:13, Emil Velikov wrote:
> Are you okay if I just paste your very fine explanation verbatim, with
> credits?
>
Yes, feel free to
Hi Dmitry,
Saw v3 fly by, so I had a quick look. Original RB still stands,
although I noticed a couple of non-blocking nitpicks.
On Sun, 21 May 2023 at 22:00, Dmitry Osipenko
wrote:
> -static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
> +static int
polish this commit
is:
Reviewed-by: Emil Velikov
I also had a brief look at 01/10, although I cannot find many
references for the pid <> tguid mappings. Be that on the kernel side
or userspace - do you have any links that I can educate myself?
Thanks
Emil
drm_gem_object *obj = >base;
> +
> + dma_resv_assert_held(shmem->base.resv);
> +
> + drm_WARN_ON(obj->dev, obj->import_attach);
> +
Ditto.
With that the series is:
Reviewed-by; Emil Velikov
HTH
-Emil
e inline
spec mention).
But that is for another day.
As-is the series is:
Reviewed-by: Emil Velikov
HTH
Emil
On Tue, 15 Feb 2022 at 16:37, Simon Ser wrote:
>
> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov
> wrote:
>
> > On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote:
> > >
> > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov
> >
On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote:
>
> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov
> wrote:
>
> > Greetings everyone,
> >
> > Padron for joining in so late o/
> >
> > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote:
>
Greetings everyone,
Padron for joining in so late o/
On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
>
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> DYNDBG_BITMAP_DESC(__gvt_debug, "dyndbg bitmap desc",
> { "gvt: cmd: ", "command processing" },
> { "gvt: core: ", "core help" },
> { "gvt: dpy: ", "display help" },
> { "gvt: el: ", "help" },
>
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> +struct dyndbg_bitdesc {
> + /* bitpos is inferred from index in containing array */
> + char *prefix;
> + char *help;
AFAICT these two should also be constant, right?
> +int param_set_dyndbg(const char *instr, const
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> Use of this new data member will be rare, it might be worth redoing
> this as a separate/sub-type to keep the base case.
>
> Signed-off-by: Jim Cromie
> ---
> include/linux/moduleparam.h | 11 +--
> 1 file changed, 9
Hi Desmond,
Couple of small suggestions, with those the series is:
Reviewed-by: Emil Velikov
On Tue, 29 Jun 2021 at 04:38, Desmond Cheong Zhi Xi
wrote:
> @@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
> struct drm_master *master;
>
On Fri, 4 Jun 2021 at 16:49, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Currently as the workaround is applied the screen flickers. As a result
> we do not achieve seamless boot experience.
>
> Avoiding the issue in the common use-case might be hard, although we can
>
On Fri, 4 Jun 2021 at 15:08, Ville Syrjälä
wrote:
>
> On Fri, Jun 04, 2021 at 02:47:16PM +0100, Emil Velikov wrote:
> > On Wed, 26 May 2021 at 17:21, Emil Velikov wrote:
> > >
> > > Hi Ville,
> > >
> > > On Tue, 18 May 2021 at 12:17, Ville Syrj
From: Emil Velikov
Currently as the workaround is applied the screen flickers. As a result
we do not achieve seamless boot experience.
Avoiding the issue in the common use-case might be hard, although we can
resolve it for dual GPU setups - when the "other" GPU is primary and/
On Wed, 26 May 2021 at 17:21, Emil Velikov wrote:
>
> Hi Ville,
>
> On Tue, 18 May 2021 at 12:17, Ville Syrjälä
> wrote:
> >
> > On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> > > Hi Ville,
> > >
> > > On
which
> GPU,output combo it should be mapped). So if CONFIG_DRM_PRIVACY_SCREEN
> is enabled and drm.ko is builtin then it must be builtin too, at which
> point it is easiest to just make it part of drm.ko .
>
Yes, the initialisation is called from core drm - it has to happen somewhere.
What I was
v/null
> +++ b/include/drm/drm_privacy_screen_consumer.h
> +#include
Ditto
> --- /dev/null
> +++ b/include/drm/drm_privacy_screen_driver.h
> +#include
Ditto
I like how you avoided leaking any DRM details within the new code,
modulo the includes above. With above tweaks, the
Hi Ville,
On Tue, 18 May 2021 at 12:17, Ville Syrjälä
wrote:
>
> On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> > Hi Ville,
> >
> > On Mon, 17 May 2021 at 18:24, Ville Syrjälä
> > wrote:
> > >
> > > On Sun, May 16, 2021 at 06
On Tue, 18 May 2021 at 12:17, Ville Syrjälä
wrote:
>
> On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> > Hi Ville,
> >
> > On Mon, 17 May 2021 at 18:24, Ville Syrjälä
> > wrote:
> > >
> > > On Sun, May 16, 2021 at 06:14:32PM +0
Hi Ville,
On Mon, 17 May 2021 at 18:24, Ville Syrjälä
wrote:
>
> On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote:
> > From: Vivek Das Mohapatra
> >
> > This patch is to do with seamless handover, eg when the sequence is
> > bootloader → plymouth
ra
Signed-off-by: Emil Velikov
---
Greetings all,
This patch has been downstream for a while now yet it seems perfectly
reasonable thing to have in the Linux kernel.
https://github.com/ValveSoftware/steamos_kernel/commit/5431b5b1999c3d3b5efee817fb3373fbbd473063
drivers/gpu/drm/i915/display/i
On Tue, 4 May 2021 at 15:58, Simon Ser wrote:
>
> Continuing on that idea to push for enabling the cap in more cases: do
> we have a policy to require new drivers to always support modifiers?
>
> That would be nice, even if it's just about enabling LINEAR.
Sounds perfectly reasonable IMHO. I
Hi Daniel,
Thanks for the extra clarification.
On Tue, 27 Apr 2021 at 13:22, Daniel Vetter wrote:
>
> On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote:
> > Hi Daniel,
> >
> > On Tue, 27 Apr 2021 at 10:20, Daniel Vetter wrote:
> >
> &
quot;. Yet no drivers do "if (config->allow_fb_modifiers)".
Sadly, nothing comes to mind atm wrt alternative wording.
With the WARN_ON() added or s/must/should/ in the documentation, the series is:
Reviewed-by: Emil Velikov
HTH
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, 12 Feb 2021 at 15:16, Chris Wilson wrote:
>
> Quoting Emil Velikov (2021-02-12 14:57:56)
> > Hi Chris,
> >
> > On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote:
> > >
> > > Register with /proc/gpu to provide the client runtimes for generic
Hi Chris,
On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote:
>
> Register with /proc/gpu to provide the client runtimes for generic
> top-like overview, e.g. gnome-system-monitor can use this information to
> show the per-process multi-GPU usage.
>
Exposing this information to userspace sounds
On Fri, 12 Feb 2021 at 14:01, Michel Dänzer wrote:
>
> On 2021-02-12 1:57 p.m., Emil Velikov wrote:
> > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> >>
> >> Userspace has discovered the functionality offered by SYS_kcmp and has
> >> started to d
On Fri, 12 Feb 2021 at 13:14, Simon Ser wrote:
>
> On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov
> wrote:
>
> > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> > >
> > > Userspace has discovered the functionality offered by SYS_kcmp
On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
>
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf)
As you rightfully
Hi Stephen,
On Wed, 17 Jun 2020 at 08:03, Stephen Rothwell wrote:
>
> Hi Thomas,
>
> On Wed, 17 Jun 2020 08:33:24 +0200 Thomas Zimmermann
> wrote:
> >
> > We recently dropped the _unlock() suffix from drm_gem_object_put(). This
> > patch should be ok.
>
> Yes, but what it shows is that the
On Mon, 15 Jun 2020 at 22:47, Manasi Navare wrote:
>
> On Mon, Jun 15, 2020 at 10:36:28PM +0100, Emil Velikov wrote:
> > Hi Manasi,
> >
> > On Sat, 13 Jun 2020 at 00:55, Manasi Navare
> > wrote:
> > >
> > > From: Bhanuprakash Modem
> > &
On Tue, 16 Jun 2020 at 07:50, Daniel Vetter wrote:
>
> On Mon, Jun 15, 2020 at 11:35 PM Emil Velikov
> wrote:
> >
> > Hi Daniel,
> >
> > On Fri, 12 Jun 2020 at 17:01, Daniel Vetter wrote:
> > >
> > > The atomic helpers try really hard to
Hi Manasi,
On Sat, 13 Jun 2020 at 00:55, Manasi Navare wrote:
>
> From: Bhanuprakash Modem
>
> [Why]
> It's useful to know the min and max vrr range for IGT testing.
>
> [How]
> Expose the min and max vfreq for the connector via a debugfs file
> on the connector, "vrr_range".
>
> Example usage:
t; struct drm_rect *rect)
> bool full;
> void *tr;
>
> - if (!dbidev->enabled)
> + if (WARN_ON(!fb))
> return;
>
AFAICT no other driver has such WARN_ON. Let's drop that - it is
pretty confusing and misleading as-is.
With that, patches 7/8
Hi Ville
I don't fully grok the i915 changes to provide meaningful review.
There are couple of small comments below, but regardless of those
Patches 01-11 and 14-16 are:
Reviewed-by: Emil Velikov
On Tue, 28 Apr 2020 at 18:20, Ville Syrjala
wrote:
> The downs
ahead and let the maintainers know I'm going to push this
> (since there's some minor changes here outside of drm-misc), and push this to
> drm-misc-next. Then I'll go and write some patches to remove the leftover amd
> bits and drop the callback for good (I'll cc it to you as well).
>
T
Hi Pankaj,
On Mon, 2 Mar 2020 at 16:33, Pankaj Bharadiya
wrote:
>
> This series addresses below drm_fb_helper tasks from
> Documentation/gpu/todo.rst.
>
> - The max connector argument for drm_fb_helper_init() isn't used
> anymore and can be removed.
>
> - The helper doesn't keep an array of
On Mon, 2 Mar 2020 at 15:58, Emil Velikov wrote:
>
> On Mon, 2 Mar 2020 at 13:08, Pankaj Bharadiya
> wrote:
> >
> > This series addresses below drm_fb_helper tasks from
> > Documentation/gpu/todo.rst.
> >
> > - The max connector argument for drm_fb_helper_
Fix unused variable warning
> drm/bridge: remove unused variable warning in tc358764_detach
> drm/fb-helper: Remove drm_fb_helper add, add_all and remove connector
> functions
> drm/todo: Update drm_fb_helper tasks
>
With 6/9 and 7/9 squashed into 1/9, as suggested by Laurent + the
w
On Fri, 21 Feb 2020 at 16:04, Ville Syrjälä
wrote:
>
> On Thu, Feb 20, 2020 at 10:55:18AM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > Let's just c
On Thu, 20 Feb 2020 at 14:28, Ville Syrjälä
wrote:
>
> On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > struct drm_display_m
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> struct drm_display_mode is extremely fat. Put it on diet.
>
> Some stats for the whole series:
>
> 64bit sizeof(struct drm_display_mode):
> 200 -> 136 bytes (-32%)
>
> 64bit bloat-o-meter -c drm.ko:
> add/remove: 1/0
s on 64bit and 120 bytes on
> 32bit. With a bit more work we should be able to get this
> below the two cacheline mark even on 64bit.
>
> Signed-off-by: Ville Syrjälä
Patches 07-12 are:
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing
e for struct drm_display_info, although we
should be carefull since that info sets passed to userspace.
Regardless, this patch is:
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
be a completely separate patch.
This patch is:
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
t; Cc: Sean Paul
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@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
___
Intel-gfx mailing
e, moving them to
include/drm/.
There are other drivers doing the same thing... not sure if that's
worth it though.
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
it.
>
There's a limit to the madness that coccinelle can take :-P
Other drrs functions already use intel_dp, so might as well be consistent.
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesk
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: V
uct
> drm_display_mode *mode,
>
> mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
>
> - mode->hsync = drm_mode_hsync(mode);
With this gone, we could make drm_mode_hsync() internal and move it to
drm_foo_internal.h.
Making it obvious that driv
On Wed, 19 Feb 2020 at 16:22, Daniel Vetter wrote:
>
> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote:
> >
> > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote:
> > >
> > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman
> > > wrote:
>
On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote:
>
> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote:
> > > Hi Daniel,
> > >
> > > Thank you for the patch.
> > >
> > > On Wed, Feb 19, 2020 at 11:20:33AM +0100,
Imre Deak
Seems like it this can happen only in vgpu cases which explains
why it was not raised earlier. Regardless:
Reviewed-by: Emil Velikov
Aside: might want to do similar patch for mesa. Be that for
classic/i965, gallium/iris and/or the Vulkan
On Tue, 6 Aug 2019 at 11:14, Daniel Stone wrote:
> The idea I had a few weeks ago was to have dim use 'git push
> --push-option fdo.pushedWithDim=this-was-pushed-with-dim-and-not-manually',
> then have the hooks on the server side check for that option and
> refuse any direct pushes. (Or at
On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote:
>
> On Tue, Aug 6, 2019 at 11:40 AM Emil Velikov wrote:
> > On Tue, 6 Aug 2019 at 08:34, Daniel Vetter wrote:
> > >
> > > On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote:
> > > >
> >
On Tue, 6 Aug 2019 at 08:34, Daniel Vetter wrote:
>
> On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote:
> >
> > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard
> > wrote:
> > >
> > > Hi Daniel, Dave,
> > >
> > > Here is the first (and pretty late) drm-misc-next PR.
> > >
> > > It's pretty big due
n 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_connector.h
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
On Wed, 3 Jul 2019 at 09:19, Vasilev, Oleg wrote:
>
> On Tue, 2019-07-02 at 14:38 +0100, Emil Velikov wrote:
> > Hi Oleg,
> >
> > On Mon, 1 Jul 2019 at 09:00, Oleg Vasilev
> > wrote:
> > > Currently, downstream port type is only reported in debugfs. This
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
Hi Oleg,
On Mon, 1 Jul 2019 at 09:00, Oleg Vasilev wrote:
>
> Currently, downstream port type is only reported in debugfs. This
> information should be considered important since it reflects the actual
> physical connector type. Some userspace (e.g. window compositors)
> may want to show this
On 2019/06/28, Matt Roper wrote:
> On Fri, Jun 28, 2019 at 05:14:51PM +0100, Emil Velikov wrote:
> > Hi Matt,
> >
> > Thanks for the enlightening input :-)
> >
> > On 2019/06/25, Matt Roper wrote:
> >
> > > PLANE_CURSOR is basically just an indi
Hi Matt,
Thanks for the enlightening input :-)
On 2019/06/25, Matt Roper wrote:
> PLANE_CURSOR is basically just an indication that that specific plane is
> the one that's also hooked up to the legacy cursor ioctls; like Ville
> says, it shouldn't directly indicate that the plane is less
>
On Mon, 24 Jun 2019 at 09:21, Daniel Vetter wrote:
> > drm_legacy.h
> > - needs drm_map_type and drm_map_flags. Seems legit.
>
> enum in uapi, sweet (never do this, it's not portable across compilers,
> #defines all the way).
Don't look too closely then
$ git grep enum -- include/uapi/drm/ | wc
On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
wrote:
>
> On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > Hi all,
> >
> > Recently I have been looking at i915 and its rather interesting planes.
> >
> > In particular newer hardware is
Hi all,
Recently I have been looking at i915 and its rather interesting planes.
In particular newer hardware is capable of using 3 universal planes and
a separate cursor-only plane. At the same time only 1 top-most plane can
be enabled - lets calls those plane3 or cursor.
Hence currently the
cumentation changes.
> - Typos and nits (Sam).
>
> Cc: Sam Ravnborg
> Cc: Eric Anholt
> Cc: Emil Velikov
> Signed-off-by: Daniel Vetter
> ---
Had a quick read and it looks reasonable.
Acked-by: Emil Velikov
HTH
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Eric Anholt
> Cc: Emil Velikov
> Signed-off-by: Daniel Vetter
> ---
Git's --color-moved=zebra detects nearly everything as moves. Couple of
return statements and a dma_buf_put() do not get flagged up, but I've
confirmed the reshuttle was OK
On 2019/06/17, Emil Velikov wrote:
> Hi Daniel,
>
> On Fri, 14 Jun 2019 at 21:36, Daniel Vetter wrote:
> >
> > Hi all,
> >
> > So I figured let's get going and polish the docs for the last part of drm
> > core/helpers that hasn't yet seen some neat p
- might be good idea to split this up a bit and merge it
into a few pieces?
Should make the churn much more manageable.
> drm/prime: Unconditionally set up the prime file private
> drm/prime: Make DRIVER_PRIME a no-op
> drm/prime: Actually remove DRIVER_PRIME everywhere
Patch set#1
Reviewe
On 2019/06/17, james qian wang (Arm Technology China) wrote:
> On Fri, Jun 14, 2019 at 10:35:23PM +0200, Daniel Vetter wrote:
> > Read the docs, komeda is not an old enough driver for this :-)
> >
> > Signed-off-by: Daniel Vetter
> > Cc: "James (Qian) Wang"
> > Cc: Liviu Dudau
> > ---
> >
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 2019/06/14, Daniel Vetter wrote:
> Drivers must fill out the handle_to_fd and fd_to_handle hooks to
> enable export/import prime functionality already. The additional
> DRIVER_PRIME flag doesn't serve any real purpose, since the overall
> flag doesn't even tell you whether import or export or
On 2019/06/14, Daniel Vetter wrote:
> Yes this is a bit a big patch, but since it's essentially a complete
> rewrite of all the prime docs I didn't see how to better split it up.
>
> Changes:
> - Consistently point to drm_gem_object_funcs as the preferred hooks,
> where applicable.
>
> -
ly clear, also add a comment to DRM_UNLOCKED.
>
> v2: Don't forget about drm_ioc32.c (Michel). Not a source of copypasta
> mistakes when creating driver ioctl tables, but better to be
> consistent.
>
Personally I would omit the "Not a source of copupasta..." note.
> Cc: M
ra
> Cc: Tomeu Vizoso
> Cc: Emil Velikov
> Cc: Benjamin Gaignard
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 2019/05/27, Thomas Hellstrom wrote:
> On 5/27/19 10:17 AM, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> &
On 2019/05/27, Christian König wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> &
On 2019/05/27, Jani Nikula wrote:
> On Mon, 27 May 2019, 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
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.
Note: the outstanding DRM_AUTH instances are:
- legacy DRI1 ioctls, which are already
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu
On 2019/04/17, Emil Velikov wrote:
> On 2019/04/17, Christian König wrote:
> > This is to work around problems with libva and vainfo.
> >
> This part reverts a commit from 2013. Something I would wager that will cause
> multiple problems across the board.
>
> If we loo
On 2019/04/17, Christian König wrote:
> This is to work around problems with libva and vainfo.
>
This part reverts a commit from 2013. Something I would wager that will cause
multiple problems across the board.
If we look at the intel libva driver in particular, as-is this will cause all
get
On 2019/01/25, Daniel Vetter wrote:
> On Fri, Jan 25, 2019 at 02:46:55PM +0000, Emil Velikov wrote:
> > On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote:
> > >
> > > This is only used by drm_irq_install(), which is an optional helper.
> > > And the right cho
> 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 comm
On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote:
>
> It's 0.
>
I'd add a bit more information here. Feel free to reuse as much/little
of the following:
Both macros evaluate to 0. At the same time flag is already set to
zero since the struct is kzalloc'd in framebuffer_alloc().
As called by
On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote:
>
> This is only used by drm_irq_install(), which is an optional helper.
> And the right choice is to set it for all pci devices, and not for
> everything else.
>
Can you please add some information (or reference) why it's the right choice?
On 2019/01/14, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 08:54:08AM +0000, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> &
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
From: Emil Velikov
This static inline function doesn't modify any state.
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reviewed-by: Daniel Vetter
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include
On Mon, 5 Nov 2018 at 14:54, Imre Deak wrote:
>
> Fix typo in struct field initializer.
>
> Fixes: 3a6eb795641c ("drm/vgem: create a render node for vgem")
> Cc: Emil Velikov
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
>
> me.
>> - best_encoder atomic cleanup is done (it's now the default, not even
>> exported anymore)
>> - bunch of smaller things
>>
>> v2:
>> - Explain why the drm_legacy.ko task is dropped (Emil).
>> - typos (Sam).
>>
>> v3: Fix typo (Ilia
On 4 September 2018 at 13:19, Daniel Vetter wrote:
> On Mon, Sep 03, 2018 at 06:38:44PM +0100, Emil Velikov wrote:
>> On 3 September 2018 at 17:54, Daniel Vetter wrote:
>>
>> > -Hide legacy cruft better
>> > -
>> > -
>> >
On 3 September 2018 at 17:54, Daniel Vetter wrote:
> -Hide legacy cruft better
> -
> -
> -Way back DRM supported only drivers which shadow-attached to PCI devices with
> -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge
> -of the entire
Hi Dan,
On 22 August 2018 at 12:44, Daniel Vetter wrote:
> Hi all,
>
> I think it's time to brainstorm a bit about the gitlab migration. Basic
> reasons:
>
> - fd.o admins want to deprecate shell accounts and hand-rolled
> infrastructure, because it's a pain to keep secure
>
> - gitlab will
On 4 July 2018 at 13:34, Daniel Vetter wrote:
> On Wed, Jul 04, 2018 at 01:03:18PM +0100, Emil Velikov wrote:
>> Hi Daniel,
>>
>> On 4 July 2018 at 10:29, Daniel Vetter wrote:
>> > dma_fence_default_wait is the default now, same for the trivial
>> > enable
Hi Daniel,
On 4 July 2018 at 10:29, Daniel Vetter wrote:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> v2: Also remove the relase hook, dma_fence_free is the default.
>
> Signed-off-by: Daniel Vetter
> Cc: Jani Nikula
> Cc: Joonas
On 24 April 2018 at 20:14, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.veli...@gmail.com>
> wrote:
>> On 13 April 2018 at 11:00, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
>>> This tries to
1 - 100 of 274 matches
Mail list logo
