which means we can have
> many resources attached to a single buffer object or resource. In that case
> the buffer object is given the highest priority of the attached resources.
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Deepak Rawat
Fwiw patches 1-3 are:
Reviewed-by: Emil Veliko
Hi Gerd,
On 2019/06/19, Gerd Hoffmann wrote:
> +/**
> + * drm_gem_array_from_handles -- lookup an array of gem handles.
> + *
> + * @drm_file: drm file-private structure to use for the handle look up
> + * @handles: the array of handles to lookup.
> + * @nents: the numer of handles.
> + *
> + * R
Hi Gerd,
On 2019/06/19, Gerd Hoffmann wrote:
> -static void virtio_gpu_init_ttm_placement(struct virtio_gpu_object *vgbo)
> +static const struct drm_gem_object_funcs v3d_gem_funcs = {
s/v3d/virtio/g
Doubt I'll have the time for a proper review - just this and the 1/12 nits :-\
HTH
Emil
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.
Acked-by: Emil Velikov
-Emil
clusively
> documentation 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 har
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 capable o
On 2019/06/14, Koenig, Christian wrote:
> Am 14.06.19 um 17:53 schrieb Emil Velikov:
> > On 2019/06/14, Koenig, Christian wrote:
> >> Am 14.06.19 um 14:09 schrieb Emil Velikov:
> >>> On 2019/05/27, Emil Velikov wrote:
> >>> [SNIP]
> >>> Hi
Hi Yannick,
On Mon, 17 Jun 2019 at 08:18, Yannick Fertré wrote:
> @@ -155,15 +154,17 @@ static __maybe_unused int drv_resume(struct device *dev)
> struct ltdc_device *ldev = ddev->dev_private;
> int ret;
>
> + if (WARN_ON(!ldev->suspend_state))
> + return -ENO
On 2019/06/21, Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian
> wrote:
> >
> > Am 21.06.19 um 11:09 schrieb Daniel Vetter:
> > > On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote:
> > >> Am 20.06.19 um 18:30 schr
On 2019/06/21, Koenig, Christian wrote:
> No this should apply to all drivers, not just amdgpu.
>
> > While I suggested:
> > - keeping amdgpu consistent with the rest
> > - exposing the KConfig option for the whole of the kernel, and
> > - merging it alongside this work
> >
> > So I effectiv
On 2019/06/21, Koenig, Christian wrote:
> Am 21.06.19 um 12:53 schrieb Emil Velikov:
> > On 2019/06/21, Koenig, Christian wrote:
> >> [SNIP]
> >> Well partially. That RADV broke is unfortunate, but we have done so many
> >> customized userspace stuff both
, 2019 at 12:31 PM Koenig, Christian
> > > > wrote:
> > > >> Am 21.06.19 um 12:20 schrieb Emil Velikov:
> > > >>> In particular, that user-space will "remove" render nodes.
> > > >> Yes, that is my main concern here. You basically make re
On 2019/06/21, Koenig, Christian wrote:
> Am 21.06.19 um 13:58 schrieb Emil Velikov:
> > On 2019/06/21, Koenig, Christian wrote:
> >> Am 21.06.19 um 12:53 schrieb Emil Velikov:
> >>> On 2019/06/21, Koenig, Christian wrote:
> >>>> [SNIP]
> >>>
On Fri, 21 Jun 2019 at 15:01, Yannick FERTRE wrote:
>
> Hi Emil,
>
> The msm driver tests the return value & set state to NULL if no error is
> detected.
>
> the ltdc driver tests the return value & force to suspend if an error is
> detected.
>
> It's not exactly the same.
>
D'oh I've misread that
d files, and most
> are header files anyways.
>
All of my glorious 23 patches to nouveau are meant to be under MIT.
Acked-by: Emil Velikov
> Another change might be to add the SPDX identifier to files *with*
> the MIT boilerplate, but I didn't want to do
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 2019/06/25, Andrzej Pietrasiewicz wrote:
> Hi Russell,
>
> W dniu 25.06.2019 o 12:03, Russell King - ARM Linux admin pisze:
> > On Tue, Jun 25, 2019 at 11:46:34AM +0200, Andrzej Pietrasiewicz wrote:
> > > It is difficult for a user to know which of the i2c adapters is for which
> > > drm connec
On Wed, 26 Jun 2019 at 13:55, Sam Ravnborg wrote:
>
> On Thu, Apr 25, 2019 at 11:18:42AM +0800, Jerry Han wrote:
> > The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and
> > connected to DSI using four lanes.
> >
> > V8:
> > - Modify communication address
> >
> > V7:
> > - Add the in
On Wed, 26 Jun 2019 at 15:29, Sam Ravnborg wrote:
>
> Hi Emil.
>
> > >
> > > Thanks,
> > > patch applied to drm-misc-next and will be pushed out soon.
> > >
> > Isn't an ack/rb from a DT maintainer a requirement before being picked
> > via the DRM trees?
> > It used to be a thing, although it coul
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
> featu
: Michel Dänzer
> ---
> amdgpu/amdgpu_bo.c | 35 +++
> 1 file changed, 15 insertions(+), 20 deletions(-)
>
Fwiw patches 1-3 are:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedeskt
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
c: Alex Deucher
> Cc: "Christian König"
> Cc: Junwei Zhang
> Cc: Greg Kroah-Hartman
> Cc: Hans de Goede
> Cc: CK Hu
> Cc: Benjamin Gaignard
> Cc: Laurent Pinchart
> Cc: Jani Nikula
> Cc: Emil Velikov
> Cc: Eric Anholt
> Cc: "Noralf Trønnes&
On Sun, 23 Jun 2019 at 11:36, Sam Ravnborg wrote:
> -int mga_driver_fence_wait(struct drm_device *dev, unsigned int *sequence)
> +void mga_driver_fence_wait(struct drm_device *dev, unsigned int *sequence)
> {
> drm_mga_private_t *dev_priv = (drm_mga_private_t *) dev->dev_private;
>
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
;
Thanks for fixing these. One nit pick: the commit message should start
with "drm/amdgpu:" as you can see from git log.
With that:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Jerry,
On Thu, 25 Apr 2019 at 08:40, Jerry Han wrote:
>
> Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> panel.
>
> V8:
> - Modify communication address
>
> V7:
> - Add the information of the reviewer
> - Remove unnecessary delays, The udelay_range code gracefully retu
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.
me extra work to do.
>
Keeping the comment sounds reasonable IMHO. Although I'm less sure
about EXPORT_SYMBOL.
If you have WIP series that makes use of it, sure. Otherwise any
driver wants to use it, they can trivially reinstate that.
With the nitpicks above, for the series:
Reviewed-by:
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 inf
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 Fri, 14 Jun 2019 at 19:02, Koenig, Christian
wrote:
>
> Am 14.06.19 um 19:33 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Currently the AMDGPU_CTX_PRIORITY_* defines are used in both
> > drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priority.
From: Emil Velikov
With later commit we'll rework DRM core authentication handling.
Namely unauthenticated master will be allowed with, DRM_AUTH ioctls.
Since vmwgfx does additional master locking and DRM_AUTH handling, this
will not matter almost all cases.
The only exception being usin
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 wh
From: Emil Velikov
With earlier commits we've removed DRM_AUTH for driver ioctls annotated
with DRM_AUTH | DRM_RENDER_ALLOW, as the protection it introduces is
effectively not existent.
With next commit, we'll effectively do the same for DRM core.
Yet the AMD developers have voice
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
On Wed, 3 Jul 2019 at 14:48, Koenig, Christian wrote:
>
> Well this is still a NAK.
>
> As stated previously please just don't remove DRM_AUTH and keep the
> functionality as it is.
>
AFAICT nobody was in favour of your suggestion to remove DRM_AUTH from
the handle to/from fd ioclts.
Thus this se
On Wed, 3 Jul 2019 at 15:33, Koenig, Christian wrote:
> Am 03.07.2019 16:00 schrieb Emil Velikov :
>
> On Wed, 3 Jul 2019 at 14:48, Koenig, Christian
> wrote:
> >
> > Well this is still a NAK.
> >
> > As stated previously please just don't remove DRM_A
On Wed, 3 Jul 2019 at 15:58, Koenig, Christian wrote:
> Am 03.07.2019 16:51 schrieb Emil Velikov :
>
> On Wed, 3 Jul 2019 at 15:33, Koenig, Christian
> wrote:
> > Am 03.07.2019 16:00 schrieb Emil Velikov :
> >
> > On Wed, 3 Jul 2019 at 14:48, Koenig, Christian
&g
eads to smaller code and also reduce the chances of mistakes.
> Suggestion to use kmemdup rather than using kmalloc/kzalloc + memset.
>
> Signed-off-by: Fuqian Huang
Fuqian please add reviewed-by and other tags when sending new revisions.
Fwiw the patch is:
Reviewed-
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 wh
Hi Gerd,
On Tue, 2 Jul 2019 at 15:19, Gerd Hoffmann wrote:
> .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
I think that you can drop this entry-point. AFAICT it's only purpose
is to return an error - something already handled by core DRM when the
function pointer is NUL
gt; Cc: Maxime Ripard
> > Cc: Sean Paul
>
> From irc:
>
> Acked-by: Maxime Ripard
>
Fwiw:
Acked-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
les. Other *.c files of the same module can't use it,
> despite all other modules can. Relying on the fact that this is the
> internal function and it's not a crucial part of the API, the patch
> removes the EXPORT_SYMBOL marking of drm_client_close.
>
> Signed-off-by
t;
> Signed-off-by: Fuqian Huang
Thanks for the update. This patch is:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
t;
> Signed-off-by: Fuqian Huang
This patch is:
Reviewed-by: Emil Velikov
-Emil
t;
> Signed-off-by: Fuqian Huang
> ---
This patch is:
Reviewed-by: Emil Velikov
-Emil
ent scenario since all the current format
descriptions have 1+ planes.
Should we add a test (alike the ones in 6/20) to ensure, that no entry
has 0 planes? Is it even worth it or I'm a bit too paranoid?
The above comments apply to 2/20.
With the name sug
On Tue, 2 Apr 2019 at 15:51, Maxime Ripard wrote:
>
> Hi Emil,
>
> On Tue, Apr 02, 2019 at 10:43:31AM +0100, Emil Velikov wrote:
> > On Tue, 19 Mar 2019 at 21:57, Maxime Ripard
> > wrote:
> > > drm_format_num_planes() is basically a lookup in the drm_format_i
up dim. Can we volunteer
you for the task ;-)
> > Either way, since you've built-tested these (and conflicts are a
> > matter of #include) for the lot:
> > Acked-by: Emil Velikov
> Just to be sure. Was this an Ack for the full series or only this patch?
> I started proc
On 2019/07/15, Fuqian Huang wrote:
> kzalloc has already zeroed the memory during the allocation.
> So memset is unneeded.
>
> Signed-off-by: Fuqian Huang
> ---
> Changes in v3:
> - Fix subject prefix: gpu/drm -> drm/amdgpu
>
Review
- Use actual commit rather than the merge commit in the commit message
>
> drivers/video/fbdev/mmp/fb/mmpfb.c | 1 -
> 1 file changed, 1 deletion(-)
>
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.o
Hi Qian,
On 2019/07/12, Qian Cai wrote:
> Maybe one of the non-DRM maintainers (Andrew, Thomas or Greg) who cares a bit
> about SPDX can pick this up. It occurs to me none of DRM maintainers cares
> about
> this as there is no feedback from any of them for months since v1.
>
AFAICT there are a c
uveau_drm *drm = nouveau_drm(dev);
> struct nvkm_i2c_aux *aux;
> u8 dpcd[8];
> + u8 port_cap[DP_MAX_DOWNSTREAM_PORTS] = {0};
IIRC clang will complain about {0}. How about we make this a {}.
Regardless of the above nitpick, the series is:
Reviewed-by: Emil Velikov
Thanks for the follow-up :-)
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
rg
> Cc: Kevin Brace
> Cc: Thomas Hellstrom
> Cc: "Gustavo A. R. Silva"
> Cc: Mike Marshall
> Cc: Ira Weiny
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: Michel Dänzer
> ---
> drivers/gpu/drm/via/via_drv.h | 15 +++
> 1 file changed, 1
On Sat, 20 Jul 2019 at 09:46, Sam Ravnborg wrote:
>
> VIA_WAIT_ON() is a direct copy of DRM_WAIT_ON() from
> drm_os_linux.h.
> The copy is made so we can avoid the dependency on the legacy header.
> A more involved approach had been to introduce wait_event_* but for this
> legacy driver the simple
Cc: Ira Weiny
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: Michel Dänzer
> ---
> drivers/gpu/drm/via/via_drv.h | 3 +++
> 1 file changed, 3 insertions(+)
>
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-deve
thus avoiding to pull in drm_os_linux.h
>
> Signed-off-by: Sam Ravnborg
> Cc: Kevin Brace
> Cc: Thomas Hellstrom
> Cc: "Gustavo A. R. Silva"
> Cc: Mike Marshall
> Cc: Ira Weiny
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: Michel Dänzer
> ---
> dr
On Mon, 22 Jul 2019 at 17:17, Sam Ravnborg wrote:
>
> Hi Emil.
>
> On Mon, Jul 22, 2019 at 04:38:39PM +0100, Emil Velikov wrote:
> > On Sat, 20 Jul 2019 at 09:46, Sam Ravnborg wrote:
> > >
> > > The DRM_READ, DRM_WRITE macros comes from the deprecated drm_
From: Emil Velikov
Current comment mentions /dev/drm which hasn't been a thing even before
the code was merged into the kernel ;-)
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fil
From: Emil Velikov
Realistically no drivers, but vmwgfx care about the DRM_AUTH flag here.
Follow-up work in this driver will properly isolate primary clients from
different master realms, thus we'll no longer need to parse _any_ ioctl
flags.
Until that work lands, add a local workaround
From: Emil Velikov
As mentioned by Christian, for drivers which support only primary nodes
this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
For others, this check in particular will be a noop. So let's remove it
as suggested by Christian.
Cc: Alex Deucher
Cc: Chri
From: Emil Velikov
With later commit we'll rework DRM core authentication handling.
Namely unauthenticated master will be allowed with, DRM_AUTH ioctls.
Since vmwgfx does additional master locking and DRM_AUTH handling, this
will not matter almost all cases.
The only exception being usin
On 2019/07/22, Sam Ravnborg wrote:
> Hi Email.
>
> > > > IMHO a far better idea is to expand these macros as static inline
> > > > functions.
> > > > The extra bonus here is that the pseudo-magical VIA_BASE will also
> > > > disappear.
> > > >
> > > > Since all the VIA_READ8 are used for masking
On 2019/07/22, Emil Velikov wrote:
> From: Emil Velikov
>
> Realistically no drivers, but vmwgfx care about the DRM_AUTH flag here.
>
> Follow-up work in this driver will properly isolate primary clients from
> different master realms, thus we'll no longer need to pa
d cruft
> in the drm subsystem.
>
> v4:
> - Use a more standard variant for via_write8_mask() (Emil)
>
Thank you. The series is:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 2019/07/25, Noralf Trønnes wrote:
> This makes the tiny drivers visible by default without having to enable a
> knob.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/Makefile| 2 +-
> drivers/gpu/drm/tinydrm/Kconfig | 37 +++--
> 2 files changed,
Hi Jan,
On 2019/07/30, Jan Sebastian Götte wrote:
> Signed-off-by: Jan Sebastian Götte
> ---
> include/uapi/drm/gdepaper_drm.h | 62 +
> 1 file changed, 62 insertions(+)
> create mode 100644 include/uapi/drm/gdepaper_drm.h
>
> diff --git a/include/uapi/drm/gdepa
On 2019/07/30, Noralf Trønnes wrote:
>
>
> Den 30.07.2019 15.53, skrev Emil Velikov:
> > On 2019/07/25, Noralf Trønnes wrote:
> >> This makes the tiny drivers visible by default without having to enable a
> >> knob.
> >>
> >> Signed-off-by: Nora
- 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
Hi Jerry,
Can you please disable HTML emails for the Gmail web client and reply
inline. There are multiple articles how to do that.
On 2019/07/26, Jerry Han wrote:
> Hi Emil Velikov:
>
> First of all, thank you for your comments.
>
> > Hi Jerry,
> >
> > On Thu, 2
Hi Jerry,
On 2019/07/29, Jerry Han wrote:
>
> From 9c63ed65469e075430a07f89012cd116c427bd6f Mon Sep 17 00:00:00 2001
> From: Jerry Han
> Date: Mon, 29 Jul 2019 11:30:48 +0800
> Subject: [PATCH] [v9] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
>
Please submit patches as outlined in the docu
On 2019/07/31, Jan Sebastian Götte wrote:
> Hi Emil,
>
> thank you for your comments.
>
> On 7/30/19 11:08 PM, Emil Velikov wrote:
> > On 2019/07/30, Jan Sebastian Götte wrote:
> >> Signed-off-by: Jan Sebastian Götte
> >> ---
>
On 2019/07/30, Daniel Vetter wrote:
> On Tue, Jul 30, 2019 at 4:30 PM Noralf Trønnes wrote:
> >
> >
> >
> > Den 29.07.2019 21.55, skrev Noralf Trønnes:
> > > Signed-off-by: Noralf Trønnes
> > > ---
> > > drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 179 ++-
> > > 1 file changed
On Tue, 30 Jul 2019 at 18:33, Noralf Trønnes wrote:
> Den 30.07.2019 19.12, skrev Emil Velikov:
> > On 2019/07/30, Daniel Vetter wrote:
> >> On Tue, Jul 30, 2019 at 4:30 PM Noralf Trønnes wrote:
> >>>
> >>>
> >>>
> >>> Den 29
From: Emil Velikov
Realistically no drivers, but vmwgfx care about the DRM_AUTH flag here.
Follow-up work in this driver will properly isolate primary clients from
different master realms, thus we'll no longer need to parse _any_ ioctl
flags.
Until that work lands, add a local workaround
From: Emil Velikov
As mentioned by Christian, for drivers which support only primary nodes
this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
For others, this check in particular will be a noop. So let's remove it
as suggested by Christian.
Cc: Alex Deucher
Cc
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
> drm_dev_re
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:
>
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 2022/07/05, Dmitry Osipenko wrote:
> On 7/5/22 18:45, Gerd Hoffmann wrote:
> > Hi,
> >
> >>> Also note that pci is not the only virtio transport we have.
> >>
> >> The VirtIO indeed has other transports, but only PCI is really supported
> >> in case of the VirtIO-GPU in kernel and in Qemu/cro
On 2022/07/05, Gerd Hoffmann wrote:
> Hi,
>
> > > Also note that pci is not the only virtio transport we have.
> >
> > The VirtIO indeed has other transports, but only PCI is really supported
> > in case of the VirtIO-GPU in kernel and in Qemu/crosvm, AFAICT. Hence
> > only the PCI transport wa
Hi Adrian,
On Thu, 31 Oct 2019 at 14:26, Adrian Ratiu wrote:
>
> Having a generic Synopsis DesignWare MIPI-DSI host controller bridge
> driver is a very good idea, however the current implementation has
> hardcoded quite a lot of the register layouts used by the two supported
> SoC vendors, STM a
From: Emil Velikov
With later commit we'll rework DRM authentication handling. Namely
DRM_AUTH will not be a requirement for DRM_RENDER_ALLOW ioctls.
Since vmwgfx does isolation for primary clients in different master
realms, the DRM_AUTH can be dropped.
The only place where authentic
From: Emil Velikov
As of earlier commit we have address space separation. Yet we forgot to
remove the respective comment and DRM_AUTH in the ioctl declaration.
Cc: Tomeu Vizoso
Cc: David Airlie
Cc: Daniel Vetter
Cc: Robin Murphy
Cc: Steven Price
Fixes: 7282f7645d06 ("drm/pan
From: Emil Velikov
Move the render_client hunk for require_exist alongside the rest.
Keeping all the reasons why an existing object is needed, in a single
place makes it easier to follow.
Cc: VMware Graphics
Cc: Thomas Hellstrom
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx
From: Emil Velikov
As mentioned by Christian, for drivers which support only primary nodes
this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
For others, this check in particular will be a noop. So let's remove it
as suggested by Christian.
Cc: Alex Deucher
Cc
From: Emil Velikov
With earlier commit 9c84aeba67cc ("drm/vmwgfx: Kill unneeded legacy
security features") we removed the no longer applicable validation, as
we now have isolation of primary clients from different master realms.
As of last commit, we're explicitly checking for au
On Fri, 1 Nov 2019 at 13:34, Steven Price wrote:
>
> On 01/11/2019 13:03, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > As of earlier commit we have address space separation. Yet we forgot to
> > remove the respective comment and DRM_AUTH in the ioctl declara
On Fri, 1 Nov 2019 at 13:05, Emil Velikov wrote:
>
> From: Emil Velikov
>
> As mentioned by Christian, for drivers which support only primary nodes
> this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
>
> For others, this check in particular will be a noo
On Fri, 1 Nov 2019 at 13:05, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Move the render_client hunk for require_exist alongside the rest.
> Keeping all the reasons why an existing object is needed, in a single
> place makes it easier to follow.
>
> Cc: VMware Graphics
On Fri, 8 Nov 2019 at 15:55, Steven Price wrote:
>
> On 08/11/2019 13:10, Emil Velikov wrote:
> > On Fri, 1 Nov 2019 at 13:34, Steven Price wrote:
> >>
> >> On 01/11/2019 13:03, Emil Velikov wrote:
> >>> From: Emil Velikov
> >>>
> >&
On Tue, 12 Nov 2019 at 12:54, Thomas Hellstrom wrote:
>
> On 11/1/19 2:05 PM, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > With earlier commit 9c84aeba67cc ("drm/vmwgfx: Kill unneeded legacy
> > security features") we removed the no longer a
r
> words the layout is abstracted away via the regmap).
>
> Suggested-by: Boris Brezillon
> Reviewed-by: Neil Armstrong
> Reviewed-by: Emil Velikov
I should have been clearer earlier - I didn't quite review the patch.
Is is now though.
Reviewed-by: Emil Velikov
Admittedly a couple
>
> Suggested-by: Boris Brezillon
> Reviewed-by: Neil Armstrong
> Reviewed-by: Emil Velikov
With the extra const mentioned below the patch is:
Reviewed-by: Emil Velikov
> +
> +static struct dw_mipi_dsi_variant dw_mipi_dsi_v130_v131_layout = {
It's a non-const her
> - drm: imx: Support Synopsys DesignWare MIPI DSI host controller
> Signed-off-by: Liu Ying
>
> - ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
> Signed-off-by: Liu Ying
>
> Reviewed-by: Neil Armstrong
> Reviewed-by: Emil Velikov
With the const nitpick b
On Wed, 6 Nov 2019 at 16:31, Adrian Ratiu wrote:
>
> Reviewed-by: Neil Armstrong
> Reviewed-by: Emil Velikov
Please drop this one. I'm not that experienced in DT to provide
meaningful review.
Actually, I've just noticed that respective maintainers/lists are not
CC'd o
On Wed, 11 Dec 2019 at 09:18, tang pengchuan wrote:
>
> Hi
>
> Emil Velikov 于2019年12月11日周三 上午1:14写道：
>>
>> Hi Kevin,
>>
>> On Tue, 10 Dec 2019 at 08:41, Kevin Tang wrote:
>> >
>> > From: Kevin Tang
>> >
>> > Adds DPU(
201 - 300 of 2172 matches
Mail list logo
