Thanks for having a look Daniel.
On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
>
> On Wed, Feb 05, 2020 at 05:48:39PM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > This commit reworks the permission handling of the two ioctls. In
> > particular
On Tue, 11 Feb 2020 at 08:06, Pekka Paalanen wrote:
>
> On Mon, 10 Feb 2020 19:01:06 +0000
> Emil Velikov wrote:
>
> > Thanks for having a look Daniel.
> >
> > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> > >
> > > On Wed, Feb
On Mon, 10 Feb 2020 at 21:54, Daniel Vetter wrote:
>
> On Mon, Feb 10, 2020 at 8:01 PM Emil Velikov wrote:
> >
> > Thanks for having a look Daniel.
> >
> > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> > >
> > > On Wed, Feb 05, 2020 at 05
On Mon, 10 Feb 2020 at 08:10, Thomas Zimmermann wrote:
>
> Hi
>
> Am 07.02.20 um 17:41 schrieb Daniel Vetter:
> > On Fri, Feb 07, 2020 at 03:16:02PM +0100, Thomas Zimmermann wrote:
> >> Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
> >> the set function, drm_helper_connector_d
From: Emil Velikov
This commit reworks the permission handling of the two ioctls. In
particular it enforced the CAP_SYS_ADMIN check only, if:
- we're issuing the ioctl from process other than the one which opened
the node, and
- we are, or were master in the past
This ensures that we:
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,
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 17:56, Gurchetan Singh
wrote:
>
> Minor cleanup, change:
>
> - file_priv--> file,
> - drm_file --> file.
>
> Signed-off-by: Gurchetan Singh
Reviewed-by: Emil Velikov
-Emil
___
dri-d
- int id;
> - char dbgname[TASK_COMM_LEN];
> + int handle;
>
> /* can't create contexts without 3d renderer */
> if (!vgdev->has_virgl_3d)
... namely this here.
With either of the two dropped:
Reviewed-by: Emil Velikov
-Emil
_
On Wed, 19 Feb 2020 at 17:56, Gurchetan Singh
wrote:
>
> Use an atomic variable to track whether a context has been
> initiated.
>
> v5: Fix possible race and sleep via mutex (@olv)
>
> Signed-off-by: Gurchetan Singh
Reviewed-by:
; + virtio_gpu_create_context(dev, file);
> objs = virtio_gpu_array_from_handles(file, &args->bo_handle, 1);
> if (objs == NULL)
> return -ENOENT;
> @@ -371,6 +373,7 @@ static int virtio_gpu_transfer_to_host_ioc
On Wed, 19 Feb 2020 at 17:57, Gurchetan Singh
wrote:
>
> We'll have to do something like this eventually, and this
> conveys we want a Virgl context by default.
>
> Signed-off-by: Gurchetan Singh
Reviewed-by: Emil Velikov
HTH
Emil
_
pipe_config(struct
> 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 ob
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
lp 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lis
it one, 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
___
dri-devel mailing
n be a completely separate patch.
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
e same 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
tes 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
___
dri-devel mai
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 g
Hi John,
On Thu, 20 Feb 2020 at 08:45, John Bates wrote:
>
> The previous code was not thread safe and caused
> undefined behavior from spurious duplicate resource IDs.
> In this patch, an atomic_t is used instead. We no longer
> see any duplicate IDs in tests with this change.
>
> Signed-off-by:
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 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 j
On Mon, 24 Feb 2020 at 11:06, Gerd Hoffmann wrote:
>
> On Fri, Feb 21, 2020 at 04:54:02PM -0800, Gurchetan Singh wrote:
> > On Fri, Feb 21, 2020 at 3:06 PM Chia-I Wu wrote:
> > >
> > > On Wed, Feb 19, 2020 at 2:34 PM Gurchetan Singh
> > > wrote:
> > > >
> > > > For old userspace, initialization
function pointers.
> >
> > Signed-off-by: Laurent Pinchart
>
> I wonder whether there's some magic somewhere we could do to enlist the
> cocci army to create the constify patches for us ...
>
IIRC some drivers still manually thinker with their struct drm_driver ;-)
That said, t
ct anyone to ever collect
> :-)
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Hawking Zhang
> Cc: Xiaojie Yuan
> Cc: Evan Quan
> Cc: "Tianci.Yin"
> Cc: "Marek Olšák"
> Cc: Hans de Goede
> Signed-off-by: Dani
On Sat, 22 Feb 2020 at 17:54, Daniel Vetter wrote:
>
> It's the last user, and more importantly, it's the last non-legacy
> user of anything in drm_pci.c.
>
> The only tricky bit is the agp initialization. But a close look shows
> that radeon does not use the drm_agp midlayer (the main use of that
On Sat, 22 Feb 2020 at 17:54, Daniel Vetter wrote:
>
> Only user left is the shadow attach for legacy drivers.
>
> Signed-off-by: Daniel Vetter
Going the extra step, as outlined in 2/3 would be great. But if the
series goes as-is, 2/3 and 3/3 are:
Reviewed-by: Emil Vel
> + port = of_parse_phandle(dev->of_node, "ports", i);
> + if (!port)
> + break;
> +
> + if (!of_device_is_available(port->parent)) {
> + of_node_put(port);
> + continue;
> +
On Fri, 21 Feb 2020 at 11:15, Kevin Tang wrote:
>
> Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>
> Cc: Orson Zhai
> Cc: Baolin Wang
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
> -
Hi Thomas,
On Tuesday, 25 February 2020, Thomas Zimmermann wrote:
> Non-KMS drivers store state in struct drm_driver. This bloats the
> structure for KMS drivers and prevents it from being declared with
> 'static const' qualifiers. Moving the non-KMS state into a separate
> data structure resolv
Hi Sebastian,
On Mon, 24 Feb 2020 at 16:55, Sebastian Andrzej Siewior
wrote:
>
> I noticed that there is a prototype for vmw_fifo_ping_host_locked() but
> no function. Then I looked further and noticed more functions which are
> not used anymore or functions protoypes which remained after the
> f
/nouveau: 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 Laure
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_
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 con
Hi Kevin,
There's a few small suggestions, although overall the driver looks a lot better.
On Thu, 27 Feb 2020 at 08:14, Kevin Tang wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/dpu/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +ifdef CONFIG_ARM64
> +KBUILD_CFLAGS
On Wed, 19 Feb 2020 at 13:27, Emil Velikov wrote:
>
> From: Emil Velikov
>
> This commit reworks the permission handling of the two ioctls. In
> particular it enforced the CAP_SYS_ADMIN check only, if:
> - we're issuing the ioctl from process other than the one which
Hi Andrzej,
On Tue, 3 Mar 2020 at 12:01, Andrzej Pietrasiewicz
wrote:
>
> The new struct contains afbc-specific data.
>
> The new function can be used by drivers which support afbc to complete
> the preparation of struct drm_afbc_framebuffer. It must be called after
> allocating the said struct a
Hi Andrzej,
On Tue, 3 Mar 2020 at 12:01, Andrzej Pietrasiewicz
wrote:
>
> Consolidating framebuffer creation into one function will make it easier
> to transition to generic afbc-aware helpers.
>
I'd suggest keeping the refactor a bit simpler.
Say - first folds the functions together. Then do the
Hi Andrzej,
On Tue, 3 Mar 2020 at 12:01, Andrzej Pietrasiewicz
wrote:
> * Returns:
> * Pointer to a &drm_framebuffer on success or an error pointer on failure.
> */
> struct drm_framebuffer *
> -drm_gem_fb_create_with_funcs(struct drm_device *dev, struct drm_file *file,
> -
Hi Andrzej,
On Tue, 3 Mar 2020 at 12:02, Andrzej Pietrasiewicz
wrote:
> +static struct drm_framebuffer *
> +rockchip_fb_create(struct drm_device *dev, struct drm_file *file,
> + const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + struct drm_afbc_framebuffer *afbc_fb;
> +
On Mon, 3 Feb 2020 at 08:11, Benjamin Gaignard wrote:
>
> Fix kernel doc comments to avoid warnings when compiling with W=1.
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/drm_context.c | 145
> ++
> 1 file changed, 61 insertions(+), 84 dele
On Thu, 5 Mar 2020 at 13:15, tang pengchuan wrote:
> On Tue, Mar 3, 2020 at 2:29 AM Emil Velikov wrote:
>> Have you seen a case where the 0 or default case are reached? AFAICT they
>> will
>> never trigger. So one might as well use:
>>
>> switch (
On Tue, 3 Mar 2020 at 16:51, Emil Velikov wrote:
> > + objs = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> > + if (!objs) {
> > + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> > +
On Fri, 6 Mar 2020 at 14:00, Pekka Paalanen wrote:
>
> On Wed, 19 Feb 2020 13:27:28 +0000
> Emil Velikov wrote:
>
> > From: Emil Velikov
> >
>
> ...
>
> > +/*
> > + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when
> &
On Mon, 9 Mar 2020 at 08:38, Pekka Paalanen wrote:
>
> On Fri, 6 Mar 2020 18:51:22 +0000
> Emil Velikov wrote:
>
> > On Fri, 6 Mar 2020 at 14:00, Pekka Paalanen wrote:
> > >
> > > On Wed, 19 Feb 2020 13:27:28 +
> > > Emil Vel
On Mon, 9 Mar 2020 at 13:13, Emil Velikov wrote:
> > OTOH, if applications exist that rely on drop-master failing in this
> > specific case, making drop-master succeed would break them. That might
> > include a buggy set-master path that was written, but does not actually
>
On Mon, 9 Mar 2020 at 18:36, Emil Velikov wrote:
>
> On Mon, 9 Mar 2020 at 13:13, Emil Velikov wrote:
>
> > > OTOH, if applications exist that rely on drop-master failing in this
> > > specific case, making drop-master succeed would break them. That might
> >
7;m going to go 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&#x
return ERR_PTR(-ENOMEM);
> +
The underlying implementation in drm_get_format_info() will throw a
WARN_ON() if we return NULL.
Returning ENOMEM here is misleading and EINVAL sounds better IMHO.
Regardless, of the above 1-5 are:
Reviewed-by: Emil Velikov
I don't know
On Wed, 11 Mar 2020 at 14:56, Andrzej Pietrasiewicz
wrote:
>
> This patch adds support for afbc handling. afbc is a compressed format
> which reduces the necessary memory bandwidth.
>
> Co-developed-by: Mark Yao
> Signed-off-by: Mark Yao
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/g
On Mon, 2 Mar 2020 at 18:29, Emil Velikov wrote:
>
> On Wed, 19 Feb 2020 at 13:27, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > This commit reworks the permission handling of the two ioctls. In
> > particular it enforced the CAP_SYS_ADMIN check only
From: Emil Velikov
As requested by Adam, provide different error message for when the
device has an existing master. An audit of the following projects, shows
that the errno is used only for printf() purposes.
xorg/xserver
xorg/drivers/xf86-video-ati
xorg/drivers/xf86-video-amdgpu
xorg/drivers
From: Emil Velikov
This commit reworks the permission handling of the two ioctls. In
particular it enforced the CAP_SYS_ADMIN check only, if:
- we're issuing the ioctl from process other than the one which opened
the node, and
- we are, or were master in the past
This ensures that we:
Hey Kevin,
On Sun, 15 Mar 2020 at 23:19, Kevin Tang wrote:
>
> Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>
> Cc: Orson Zhai
> Cc: Baolin Wang
> Cc: Chunyan Zhang
> Signed-off-by: Kev
Hi all,
On Thu, 16 Jan 2020 at 07:37, Thomas Zimmermann wrote:
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 7cf3cf936547..23d2f51fc1d4 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm
Hi Ezequiel,
The first patch looks spot on. I'll commit it in a moment.
On Mon, 22 Jul 2019 at 17:08, Ezequiel Garcia wrote:
>
> This option finds the first connected connector and then
> sets its preferred mode on it.
>
> Set this option to be set when no mode or plane is set
> explicitily. Thi
On Thu, 27 Jun 2019 at 22:37, John Stultz wrote:
>
> Often there are many similar modes, which cannot be selected
> via modetest due to its simple string matching.
>
> This change adds a mode index in the display output, which can
> then be used to specify a specific modeline to be set.
>
> Cc: Il
f-by: 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 Vu
Hi Thomas,
On Thu, 23 Jan 2020 at 09:21, Thomas Zimmermann wrote:
> @@ -174,12 +174,22 @@ struct drm_crtc_state {
> * @no_vblank:
> *
> * Reflects the ability of a CRTC to send VBLANK events. This state
> -* usually depends on the pipeline configuration, and th
From: Emil Velikov
This commit reworks the permission handling of the two ioctls. In
particular it enforced the CAP_SYS_ADMIN check only, if:
- we're issuing the ioctl from process other than the one which opened
the node, and
- we are, or were master in the past
This allows fo
From: Emil Velikov
Current validation requires that we're authenticated, even though we can
bypass (by design) the authentication when using a render node.
Let's address the former by following the design decision.
v2: Add simpler validation in the ioctls themselves (Boris)
Cc: Al
On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
wrote:
>
> Hi Emil,
>
> On Fri, 1 Nov 2019 13:03:13 +
> Emil Velikov wrote:
>
> > From: Emil Velikov
> >
> > As mentioned by Christian, for drivers which support only primary nodes
> > this ch
Hi Thomas,
On Tue, 26 Nov 2019 at 10:15, Thomas Zimmermann wrote:
>
> Adds a conversion function that extracts the device type from the
> PCI id-table flags. Allows for storing additional information in the
> other flag bits.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 81da87f63a1e ("drm: Repl
On Wed, 27 Nov 2019 at 18:04, Daniel Vetter wrote:
>
> On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote:
> > On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
> > wrote:
> > >
> > > Hi Emil,
> > >
> > > On Fri, 1 Nov 2019 13:03:
On 2019/11/27, Thomas Zimmermann wrote:
> Hi Emil
>
> Am 27.11.19 um 17:29 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Tue, 26 Nov 2019 at 10:15, Thomas Zimmermann wrote:
> >>
> >> Adds a conversion function that extracts the device type from th
,himax8279d10p" (Sam)
>
> V1:
> - Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> panel.
>
> Signed-off-by: Jerry Han
> Reviewed-by: Sam Ravnborg
> Reviewed-by: Derek Basehore
> Reviewed-by: Emil Velikov
Please don't add t
Hi Thomas,
On Tue, 26 Nov 2019 at 13:47, Thomas Zimmermann wrote:
>
> The infrastruture for atomic modesetting allows us to use the generic
> code for dirty-FB and damage handling. Switch over udl and remove the
> driver's implementation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu
ode motion from the dead
code removal.
Not a big deal though:
Reviewed-by: Emil Velikov
There's few comments for follow-up work below.
> +static int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
> +int width, int height)
> +{
> +
On Wed, 27 Nov 2019 at 18:37, Daniel Vetter wrote:
>
> On Wed, Nov 27, 2019 at 06:32:56PM +, Emil Velikov wrote:
> > On Wed, 27 Nov 2019 at 18:04, Daniel Vetter wrote:
> > >
> > > On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote:
> > >
From: Emil Velikov
Up-to recently the only driver which required these was vmwgfx.
With commit 9c84aeba67cc ("drm/vmwgfx: Kill unneeded legacy security
features") the driver no longer sets them, so we can drop the unused
infra.
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-of
Hi Thomas,
On Tue, 3 Dec 2019 at 10:04, Thomas Zimmermann wrote:
>
> Declarations of drm_legacy_pci_{init,exit}() are being moved to
> drm_legacy.h. CONFIG_DRM_LEGACY protects the implementation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_pci.c | 4
> include/drm/drm
On Tue, 3 Dec 2019 at 11:06, Emil Velikov wrote:
>
> Hi Thomas,
>
> On Tue, 3 Dec 2019 at 10:04, Thomas Zimmermann wrote:
> >
> > Declarations of drm_legacy_pci_{init,exit}() are being moved to
> > drm_legacy.h. CONFIG_DRM_LEGACY protects the implementation.
> drm/savage: Don't include
> drm/sis: Don't include
> drm/tdfx: Don't include
> drm/via: Don't include
>
Slightly leaning about getting 01 <> 02 swapped, but regardless the series is:
Reviewed-by: Emil Velikov
-Emil
_
On Wed, 4 Dec 2019 at 13:24, Thomas Zimmermann wrote:
>
> The damage-handler code now invokes dma_buf_{begin,end}_access()
> for imported buffers. These calls were missing from the page-flip
> and modesetting code paths.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_fb.c |
pp code out of udl_damage_handler()
> drm/udl: Begin/end access to imported buffers in damage-handler
> drm/udl: Remove field lost_pixels from struct udl_device
>
There's a bugfix request in 6/7.
Regardless if you squash it in or choose to
good point. I wasn't aware of this macro.
>
While at it, please keep bitfields close to the respective registers.
Don't know much about the driver to review this, for 1&2
Reviewed-by: Emil Velikov
I'll look at 4/4 first thing tomorrow.
Thanks
Emil
_
quot; (Sam)
>
> V1:
> - Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> panel.
>
> Signed-off-by: Jerry Han
> Reviewed-by: Sam Ravnborg
> Reviewed-by: Derek Basehore
> Reviewed-by: Emil Velikov
v9 looks much better t
Hi Thomas,
On Thu, 5 Dec 2019 at 16:01, Thomas Zimmermann wrote:
>
> Before updating the display from the console's shadow buffer, the dirty
> worker now waits for a vblank. This allows several screen updates to pile
> up and acts as a rate limiter. If a DRM master is present, it could
> interfer
llows us to trivially change
from DPMS_OFF to DPMS_SUSPEND or DPMS_STANDBY at any random point.
As-is the series is:
Reviewed-by: Emil Velikov
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Welcome to DRM Kevin,
On Tue, 10 Dec 2019 at 08:40, Kevin Tang wrote:
>
> From: Kevin Tang
>
> Adds drm support for the Unisoc's display subsystem.
>
> This is drm device and gem driver. This driver provides support for the
> Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
D
Hi Kevin,
On Tue, 10 Dec 2019 at 08:41, Kevin Tang wrote:
>
> From: Kevin Tang
>
> Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>
> Cc: Orson Zhai
> Cc: Baolin Wang
> Cc: Chunyan Zhang
Hi Jerry,
On Sat, 3 Aug 2019 at 03:11, Jerry Han wrote:
>
> Hi Emil:
>
> thanks for you advice.
>
Please use interleaved posting style - top posting is generally discouraged.
See the wikipedia article for details [1]. Here [2] is now to do that for Gmail.
> V1: https://patchwork.freedesktop.org/
On Sat, 3 Aug 2019 at 15:37, Sam Ravnborg wrote:
>
> Hi Jerry.
>
> On Sat, Aug 03, 2019 at 10:40:44AM +0800, Jerry Han wrote:
> > V1: https://patchwork.freedesktop.org/patch/287425/
> > V2: https://patchwork.freedesktop.org/patch/289843/
> > V3: https://patchwork.freedesktop.org/patch/290393/
> >
On 2019/08/05, Laurent Pinchart wrote:
> Hi Sam,
>
> Thank you for the patch.
>
> On Sun, Aug 04, 2019 at 10:16:35PM +0200, Sam Ravnborg wrote:
> > Many panel drivers duplicate logic to prevent prepare to be called
> > for a panel that is already prepared.
> > Likewise for enable.
> >
> > Implem
ies.
>
> Sam
>
Thanks for working on this Sam.
Patches 1-13 are:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, 5 Aug 2019 at 16:37, Deepak Singh Rawat wrote:
>
> Hi Emil,
>
> Thanks for doing this. Looks good to me. By the way I think Thomas had
> a patch to get rid of legacy locking mechanism. I don't know when it
> will go upstream. With that we no need for the below check.
>
Agreed the patches w
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 to
Hi Ben,
On Thu, 23 May 2019 at 01:19, Ben Skeggs wrote:
>
> On Thu, 23 May 2019 at 01:03, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > Cc: Ben Skeggs
> > Cc: nouv...@lists.freedesktop.org
> > Signed-off-by: Emil Velikov
> Thanks!
>
S
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.
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.
&g
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 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 least
.
>
Hear, hear.
> Sean
>
> Sean Paul (5):
> Revert "drm/vgem: drop DRM_AUTH usage from the driver"
> Revert "drm/msm: drop DRM_AUTH usage from the driver"
> Revert "drm/nouveau: remove open-coded drm_invalid_op()"
>
For these three:
Acked-by:
re imported BOs are used.
> Signed-off-by: Rob Herring
> Signed-off-by: Sean Paul
Regardless of the above nitpick, with the patch order fixed the series is:
Reviewed-by: Emil Velikov
... in case you haven't picked it already.
-Emil
_
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
- /dev/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
o see if there is a privacy-screen (and to 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
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 Mon, 17 May 2021 at
301 - 400 of 2172 matches
Mail list logo
