Re: [PATCH v4] MAINTAINERS: move Milo Kim to credits

Greetings everyone, On Mon, 15 Feb 2021 at 08:52, Lee Jones wrote: > > On Fri, 12 Feb 2021, Krzysztof Kozlowski wrote: > > > Milo Kim's email in TI bounces with permanent error (550: Invalid > > recipient). Last email from him on LKML was in 2017. Move Milo Kim to > > credits and remove the

Re: [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE

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

Re: [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE

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

Re: [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE

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

Re: module loader dead code removal and cleanups v3

nce. So I > think it's safe to retire those export types now. > I believe you're spot on - based on reading through git log and checking the ML archives. Shame I didn't get to finish a similar series I had locally. Patches 11-13 match what I have here so: Reviewed-by: Emil Velikov HTH -Emil

Re: linux-next: build failure after merge of the drm-misc tree

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

Re: [PATCH v2 0/5] 180 degrees rotation support for NVIDIA Tegra DRM

On Tue, 16 Jun 2020 at 18:20, Dmitry Osipenko wrote: > > 16.06.2020 18:48, Emil Velikov пишет: > > On Tue, 16 Jun 2020 at 12:40, Dmitry Osipenko wrote: > >> > >> 16.06.2020 01:26, Emil Velikov пишет: > >>> Hi Dmitry, > >>> >

Re: [PATCH v2 0/5] 180 degrees rotation support for NVIDIA Tegra DRM

On Tue, 16 Jun 2020 at 12:40, Dmitry Osipenko wrote: > > 16.06.2020 01:26, Emil Velikov пишет: > > Hi Dmitry, > > > > On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko wrote: > >> > >> Hello! > >> > >> This series adds 180° display plan

Re: [PATCH 0/6] remove deprecated i2c_new_device API

Hi all, On Tue, 16 Jun 2020 at 13:12, Daniel Vetter wrote: > > On Mon, Jun 15, 2020 at 09:58:09AM +0200, Wolfram Sang wrote: > > I want to remove the above API this cycle, and just a few patches have > > not made it into 5.8-rc1. They have been reviewed and most had been > > promised to get into

Re: [PATCH v2 0/5] 180 degrees rotation support for NVIDIA Tegra DRM

Hi Dmitry, On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko wrote: > > Hello! > > This series adds 180° display plane rotation support to the NVIDIA Tegra > DRM driver which is needed for devices that have display panel physically > mounted upside-down, like Nexus 7 tablet device for example [1].

Re: [PATCH v2 5/5] drm/tegra: plane: Support 180° rotation

Hi all, Perhaps a silly question: On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko wrote: > > Combining horizontal and vertical reflections gives us 180 degrees of > rotation. > > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/drm/tegra/dc.c | 13 - > 1 file changed, 12

Re: (EXT) Re: [PATCH 3/4] drm/panel: simple: add CDTech S070PWS19HP-FC21 and S070SWV29HG-DC44

Hi Matthias, On Thu, 11 Jun 2020 at 08:54, Matthias Schiffer wrote: > On Wed, 2020-06-10 at 16:59 +0200, Sam Ravnborg wrote: > > On Wed, Jun 10, 2020 at 02:01:30PM +0200, Matthias Schiffer wrote: > > > + .vrefresh = 60, > > > > .vrefresh is no longer present, please drop. > > I based my

Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support

Hi Bartlomiej, On Tue, 2 Jun 2020 at 11:37, Bartlomiej Zolnierkiewicz wrote: > > > On 5/14/20 10:21 PM, Geert Uytterhoeven wrote: > > > These #ifdefs are relics from APUS (Amiga Power-Up System), which > > added a PPC board. APUS support was killed off a long time ago, > > when arch/ppc/ was

Re: [PATCH v3 1/2] linux/bits.h: fix unsigned less than zero warnings

c:49:25: note: in expansion of macro 'GENMASK' > 49 | unsigned int lsbmask = GENMASK(msbpos - 1, 0); > | ^~~ > > Fixes: 295bcca84916 ("linux/bits.h: add compile time sanity check of GENMASK > inputs") > Reported-by: kbuild test robot > Reported-by

Re: [PATCH] alpha: Fix build around srm_sysrq_reboot_op

e to fix the build. > > Fixes: 0f1c9688a194 ("tty/sysrq: alpha: export and use __sysrq_get_key_op()") > Cc: Emil Velikov > Cc: Guenter Roeck > Signed-off-by: Joerg Roedel Just coming back from 10 offline days and retracing my testing ... Seems that I've copied the wro

Re: [v2] drm/msm: add shutdown support for display platform_driver

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

Re: [v2] drm/msm: add shutdown support for display platform_driver

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

Re: [v2] drm/msm: add shutdown support for display platform_driver

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: [PATCH 1/7] drm/rockchip: prepare common code for cdns and rk dpi/dp driver

HI Sandor Yu On Mon, 1 Jun 2020 at 07:29, wrote: > > From: Sandor Yu > > - Extracted common fields from cdn_dp_device to a new cdns_mhdp_device > structure which will be used by two separate drivers later on. > - Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format, >

Re: [Linux-stm32] [PATCH v8 08/10] drm: stm: dw-mipi-dsi: let the bridge handle the HW version check

Hi Adrian, On Mon, 1 Jun 2020 at 10:14, Adrian Ratiu wrote: > > On Fri, 29 May 2020, Philippe CORNU wrote: > > Hi Adrian, and thank you very much for the patchset. Thank you > > also for having tested it on STM32F769 and STM32MP1. Sorry for > > the late response, Yannick and I will review it

Re: [PATCH] drm/vkms: Optimize compute_crc(), blend()

On Mon, 1 Jun 2020 at 01:25, Rodrigo Siqueira wrote: > > Hi, > > First of all, thanks a lot for all your patch. And thanks Emil for your > feedback. > > I have a suggestion here: > > Emil: > Could you give me your Acked-by or maybe Reviewed-by for the writeback > series? With that, I can finally

Re: [PATCH V4 3/3] drm/vkms: Add support for writeback

On Mon, 11 May 2020 at 12:55, Rodrigo Siqueira wrote: > # SPDX-License-Identifier: GPL-2.0-only > -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o > vkms_composer.o > +vkms-y := \ > + vkms_drv.o \ > + vkms_plane.o \ > + vkms_output.o \ > +

Re: [PATCH V4 2/3] drm/vkms: Compute CRC without change input data

On Tue, 12 May 2020 at 12:34, Emil Velikov wrote: > > Hi Rodrigo, > > On Mon, 11 May 2020 at 12:55, Rodrigo Siqueira > wrote: > > > > From: Rodrigo Siqueira > > > > The compute_crc() function is responsible for calculating the > > framebuffer CRC

Re: [PATCH V4 1/3] drm/vkms: Decouple crc operations from composer

Hi Rodrigo, On Mon, 11 May 2020 at 12:55, Rodrigo Siqueira wrote: > -static uint32_t _vkms_get_crc(struct vkms_composer *primary_composer, > - struct vkms_composer *cursor_composer) > +static int compose_planes(void **vaddr_out, > + struct

Re: [PATCH] drm/vkms: Optimize compute_crc(), blend()

On Sun, 31 May 2020 at 14:12, Sidong Yang wrote: > > Optimize looping pixels in compute_crc() and blend(). Calculate > src_offset in start of looping horizontally and increase it. > It's better than calculating in every pixels. > When you say "optimize" have you observed any actual benefits of

Re: [PATCH v3 066/105] drm/vc4: txp: Turn the TXP into a CRTC of its own

Hi Maxime, Have you considered splitting the series into several parts and focusing on merging one at a time? IIRC this the longest series _ever_ submitted to dri-devel, plus it seems to be growing with each revision. Due to the sheer volume, it's likely to miss various points - large or small

Re: [PATCH] drm: rcar-du: Fix build error

onnector_duplicate_state' > drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xe10): undefined reference to > `drm_atomic_helper_connector_destroy_state' > > Signed-off-by: Daniel Gomez Nicely spotted. AFAICT the only way this ever worked is if people had DRM_FBDEV_EMULATION, which is

Re: [PATCH 11/12] gpu/drm: Ingenic: Add support for the IPU

Hi Paul, Disclaimer: I don't know much about the hardware :-P On Sun, 17 May 2020 at 00:31, Paul Cercueil wrote: > > Add support for the Image Processing Unit (IPU) found in all Ingenic > SoCs. > Since the IPU is present on all devices supported, does it make sense to have it as separate

Re: [PATCH 0/2] drm: encoder_slave: some updates

On Wed, 13 May 2020 at 10:35, Emil Velikov wrote: > > Hi Wolfram, > > On Wed, 13 May 2020 at 10:10, Wolfram Sang > wrote: > > > > On Mon, Mar 16, 2020 at 05:39:05PM +0100, Wolfram Sang wrote: > > > While converting I2C users to new APIs, I found a refcountin

Re: get_maintainer.pl: unexpected behaviour for path/to//file

On Fri, 15 May 2020 at 18:22, Joe Perches wrote: > > On Fri, 2020-05-15 at 05:31 -0700, Joe Perches wrote: > > On Fri, 2020-05-15 at 11:52 +0100, Emil Velikov wrote: > > > Hi Joe, > > > > > > Recently I've noticed that get_maintainer behaves differently

Re: [PATCHv1 03/19] power: supply: core: add manufacture date properties

On 2020/05/15, Sebastian Reichel wrote: > Hi, > > On Fri, May 15, 2020 at 03:47:32PM +0100, Emil Velikov wrote: > > On 2020/05/13, Sebastian Reichel wrote: > > > Some smart batteries store their manufacture date, which is > > > useful to identify the batt

Re: [PATCHv1 13/19] power: supply: sbs-battery: add POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED support

OWER_SUPPLY_PROP_PRESENT - using the min/max seems wasteful, considering only one register is in s16 range while everything else is within u16 Regardless of the questions and trivial suggestions, the series looks spot on. For the lot: Reviewed-by: Emil Velikov -Emil P.S. The reg table is nearly complete only 0x01-0x07, 0x0E, 0x11, 0x1d-0x1f remain o/

Re: [PATCHv1 15/19] power: supply: sbs-battery: add ability to disable charger broadcasts

On 2020/05/13, Sebastian Reichel wrote: > From: Jean-Francois Dagenais > > In certain designs, it is possible to add a battery on a populated i2c > bus without an sbs compliant charger. In that case, the battery will > un-necessarily and sometimes un-desirably master the bus trying to write >

Re: [PATCHv1 03/19] power: supply: core: add manufacture date properties

Hi Sebastian, On 2020/05/13, Sebastian Reichel wrote: > Some smart batteries store their manufacture date, which is > useful to identify the battery and/or to know about the cell > quality. > Have you considered exposing this as a single file? Say following the ISO8601 format - -MM-DD.

Re: [PATCHv1 01/19] kobject: increase allowed number of uevent variables

he safe side I've checked systemd/udev. It's using ordered hashmap, so it's perfectly capable of handling the extra entries. Reviewed-by: Emil Velikov -Emil

Re: [PATCHv1 1/2] power: supply: gpio-charger: add charge-current-limit feature

Hi Sebastian, I've left a few trivial suggestions, although I suspect only one of them really matters. Namely - I think as-is the code changes the legacy behaviour when OF is missing. Mind you, this is my third time skimming through power/supply, so take it with a grain of salt. On 2020/05/13,

get_maintainer.pl: unexpected behaviour for path/to//file

%,authored:24/42=57%) Vasily Khoruzhick (commit_signer:26/42=62%) Krzysztof Kozlowski (commit_signer:5/42=12%,authored:5/42=12%) Emil Velikov (commit_signer:4/42=10%) dri-de...@lists.freedesktop.org (open list:DRM DRIVERS) linux-kernel@vger.kernel.org (open list) ./scripts/get_maintainer -F

Re: [PATCH 10/11] kernel/power: constify sysrq_key_op

On Thu, 14 May 2020 at 12:21, Rafael J. Wysocki wrote: > > On Wed, May 13, 2020 at 11:46 PM Emil Velikov > wrote: > > > > With earlier commits, the API no longer discards the const-ness of the > > sysrq_key_op. As such we can add the notation. > > > > Cc:

Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily

On Thu, 14 May 2020 at 08:16, Greg Kroah-Hartman wrote: > > On Wed, May 13, 2020 at 11:18:15PM +0100, Emil Velikov wrote: > > Hi Greg, > > > > On Fri, 2 Aug 2019 at 11:46, Greg Kroah-Hartman > > wrote: > > > > > > > > I have now d

Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily

Hi Greg, On Fri, 2 Aug 2019 at 11:46, Greg Kroah-Hartman wrote: > > I have now done this with patch 1/10. Here's the pull info if any > subsystem maintainer wants to suck this into their tree to provide the > ability for drivers to add/remove attribute groups easily. > > This is part of my

[PATCH 08/11] drm: constify sysrq_key_op

Signed-off-by: Emil Velikov --- Please keep me in the CC list, as I'm not subscribed to the list. IMHO it would be better if this gets merged this via the tty tree. --- drivers/gpu/drm/drm_fb_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 09/11] kdb: constify sysrq_key_op

With earlier commits, the API no longer discards the const-ness of the sysrq_key_op. As such we can add the notation. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-kernel@vger.kernel.org Cc: Jason Wessel Cc: Daniel Thompson Cc: kgdb-bugrep...@lists.sourceforge.net Signed-off-by: Emil

[PATCH 04/11] alpha: constify sysrq_key_op

-by: Emil Velikov --- Please keep me in the CC list, as I'm not subscribed to the list. IMHO it would be better if this gets merged this via the tty tree. --- arch/alpha/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel

[PATCH 10/11] kernel/power: constify sysrq_key_op

With earlier commits, the API no longer discards the const-ness of the sysrq_key_op. As such we can add the notation. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-kernel@vger.kernel.org Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: linux...@vger.kernel.org Signed-off-by: Em

[PATCH 07/11] sparc64: constify sysrq_key_op

With earlier commits, the API no longer discards the const-ness of the sysrq_key_op. As such we can add the notation. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-kernel@vger.kernel.org Cc: "David S. Miller" Cc: sparcli...@vger.kernel.org Signed-off-by: Emil Velikov --- Plea

[PATCH 01/11] tty/sysrq: alpha: export and use __sysrq_get_key_op()

op and constify the sysrq handling. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-kernel@vger.kernel.org Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: linux-al...@vger.kernel.org Signed-off-by: Emil Velikov --- Please keep me in the CC list, as I'm not subscribed to the list

[PATCH 06/11] powerpc/xmon: constify sysrq_key_op

Signed-off-by: Emil Velikov --- Please keep me in the CC list, as I'm not subscribed to the list. IMHO it would be better if this gets merged this via the tty tree. --- arch/powerpc/xmon/xmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/xmon/xmon.c b/arch

[PATCH 11/11] rcu: constify sysrq_key_op

With earlier commits, the API no longer discards the const-ness of the sysrq_key_op. As such we can add the notation. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-kernel@vger.kernel.org Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: r...@vger.kernel.org Signed-off-by: Em

[PATCH 05/11] MIPS: constify sysrq_key_op

With earlier commits, the API no longer discards the const-ness of the sysrq_key_op. As such we can add the notation. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-kernel@vger.kernel.org Cc: Thomas Bogendoerfer Cc: linux-m...@vger.kernel.org Signed-off-by: Emil Velikov --- Please keep me

[PATCH 02/11] tty/sysrq: constify the sysrq API

The user is not supposed to thinker with the underlying sysrq_key_op. Make that explicit by adding a handful of const notations. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-kernel@vger.kernel.org Signed-off-by: Emil Velikov --- Please keep me in the CC list, as I'm not subscribed

[PATCH 03/11] tty/sysrq: constify the the sysrq_key_op(s)

All the users threat them as immutable - annotate them as such. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-kernel@vger.kernel.org Signed-off-by: Emil Velikov --- Please keep me in the CC list, as I'm not subscribed to the list. IMHO it would be better if this gets merged this via the tty

Re: [PATCH 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge

Hi Vinod, Few high-level comments: - handful of functions always return 0 and the return value is never checked - switch to return void - annotate all (nearly) arrays as static const - consistently use multi_reg_write - in some cases non-const array will be fine, overwriting a few entries as

Re: [PATCH 0/2] drm: encoder_slave: some updates

| 15 +-- > > 1 file changed, 5 insertions(+), 10 deletions(-) > > Is there someone I should add to the CC list maybe? > The series is: Reviewed-by: Emil Velikov Unless someone beats me to it, I'll commit them to drm-misc later today. -Emil

Re: [PATCH -next] drm/mcde: dsi: Fix return value check in dev_err()

Hi all, On Tue, 12 May 2020 at 12:49, Linus Walleij wrote: > > On Tue, Apr 28, 2020 at 4:13 PM Wei Yongjun wrote: > > > In case of error, the function of_drm_find_bridge() returns NULL pointer > > not ERR_PTR(). The IS_ERR() test in the return value check should be > > replaced with NULL test.

Re: [PATCH V4 2/3] drm/vkms: Compute CRC without change input data

Hi Rodrigo, On Mon, 11 May 2020 at 12:55, Rodrigo Siqueira wrote: > > From: Rodrigo Siqueira > > The compute_crc() function is responsible for calculating the > framebuffer CRC value; due to the XRGB format, this function has to > ignore the alpha channel during the CRC computation. Therefore,

Re: [PATCH v6 2/3] drm: Add support for the LogiCVC display controller

On Thu, 7 May 2020 at 21:11, Paul Kocialkowski wrote: > > Hi Emil, > > Thanks for the review! > > On Mon 04 May 20, 14:28, Emil Velikov wrote: > > Just had a casual quick look for custom KMS properties, since new > > drivers made that mistake in the past. >

Re: [PATCH v6 2/3] drm: Add support for the LogiCVC display controller

Hi Paul, Just had a casual quick look for custom KMS properties, since new drivers made that mistake in the past. Thanks for not including any o/ I made a couple of trivial suggestions - if you agree, feel free to keep them as follow-up patches. On Thu, 30 Apr 2020 at 20:28, Paul Kocialkowski

Re: [RFC PATCH] modpost: check for static EXPORT_SYMBOL* functions

it will > be considered useful. > > Also, this kind of check could be implemented as a separate script instead. > Here is the implementation: > https://gist.github.com/evdenis/bf2322d094f0c02c0f60fe0a225848b2 > Personally I think this is a pretty good feature. If I did my numbers correctly, the above numbers show ~2% increase. Although one should be able to reduce that if people feel too strongly. That said, the patch is: Acked-by: Emil Velikov Can we make sure that patches for all issues are out (on the respective mailing lists, or merged) before this lands. HTH Emil

Re: [PATCH v3] gpu/drm_memory: fix a few warnings

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

Re: [Patch v2 01/10] drm/exynos: using dev_get_drvdata directly

> > Signed-off-by: Fuqian Huang Thanks for the update. This patch is: Reviewed-by: Emil Velikov -Emil

Re: [PATCH 06/30] drm/amdgpu: Use kmemdup rather than duplicating its implementation

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-by: Emil Velikov -Emil

Re: [PATCH 4.20 004/352] drm/vgem: Fix vgem_init to get drm device available.

arent in drm_dev_init. > This will make drm device available at "/sys/devices/platform/vgem" > in x86 chromebook. > > v2: rebase, address checkpatch typo and line over 80 characters > > Cc: Daniel Vetter > Signed-off-by: Deepak Sharma > Reviewed-by: Sean Paul >

Re: [PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups

Hi Shayenne, Welcome to DRM. As far as I can see you're a newcomer to kernel development, so I'd recommend watch a recent talk from Marc [1] He provides a very good introduction, both for newbies and for people willing the know the deeper reasons behind. That said, here's some suggestions: On

Re: [PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups

Hi Shayenne, Welcome to DRM. As far as I can see you're a newcomer to kernel development, so I'd recommend watch a recent talk from Marc [1] He provides a very good introduction, both for newbies and for people willing the know the deeper reasons behind. That said, here's some suggestions: On

Re: [PATCH 2/5] drm/virtio: add uapi for in and out explicit fences

On Tue, 30 Oct 2018 at 13:52, Gerd Hoffmann wrote: > > On Tue, Oct 30, 2018 at 11:31:04AM +, Emil Velikov wrote: > > HI Gerd, > > > > On Tue, 30 Oct 2018 at 06:11, Gerd Hoffmann wrote: > > > > > > Hi, > > > > > > > The ex

Re: [PATCH 2/5] drm/virtio: add uapi for in and out explicit fences

On Tue, 30 Oct 2018 at 13:52, Gerd Hoffmann wrote: > > On Tue, Oct 30, 2018 at 11:31:04AM +, Emil Velikov wrote: > > HI Gerd, > > > > On Tue, 30 Oct 2018 at 06:11, Gerd Hoffmann wrote: > > > > > > Hi, > > > > > > > The ex

Re: [RFC] drm: Allow DRM_IOCTL_MODE_MAP_DUMB for render nodes

On 7 August 2018 at 13:28, Daniel Vetter wrote: > On Tue, Aug 07, 2018 at 12:01:50PM +0100, Emil Velikov wrote: >> On 3 August 2018 at 20:50, Sean Paul wrote: >> > On Fri, Aug 03, 2018 at 06:03:50PM +0100, Emil Velikov wrote: >> >> On 3 August 2018 at 16:0

Re: [RFC] drm: Allow DRM_IOCTL_MODE_MAP_DUMB for render nodes

On 7 August 2018 at 13:28, Daniel Vetter wrote: > On Tue, Aug 07, 2018 at 12:01:50PM +0100, Emil Velikov wrote: >> On 3 August 2018 at 20:50, Sean Paul wrote: >> > On Fri, Aug 03, 2018 at 06:03:50PM +0100, Emil Velikov wrote: >> >> On 3 August 2018 at 16:0

Re: [PATCH v2 1/2] drm/blend: Add per-plane pixel blend mode property

Hi Lowry, Small drive-by suggestion. Haven't checked if others have pointed it out previously :-\ On 30 May 2018 at 12:23, Lowry Li wrote: > +/** > + * drm_plane_create_blend_mode_property - create a new blend mode property > + * @plane: drm plane > + * @supported_modes: bitmask of supported

Re: [PATCH v2 1/2] drm/blend: Add per-plane pixel blend mode property

Hi Lowry, Small drive-by suggestion. Haven't checked if others have pointed it out previously :-\ On 30 May 2018 at 12:23, Lowry Li wrote: > +/** > + * drm_plane_create_blend_mode_property - create a new blend mode property > + * @plane: drm plane > + * @supported_modes: bitmask of supported

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

On 20 March 2018 at 06:24, hl <h...@rock-chips.com> wrote: > Hi Emil, > > > > On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote: >> >> On 15 March 2018 at 02:35, hl <h...@rock-chips.com> wrote: >>> >>> Hi Emil, >>> >

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

On 20 March 2018 at 06:24, hl wrote: > Hi Emil, > > > > On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote: >> >> On 15 March 2018 at 02:35, hl wrote: >>> >>> Hi Emil, >>> >>> >>> >>> On Wednesday, March 14

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

On 15 March 2018 at 02:35, hl <h...@rock-chips.com> wrote: > Hi Emil, > > > > On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote: >> >> Hi Lin, >> >> On 14 March 2018 at 09:12, Lin Huang <h...@rock-chips.com> wrote: >>> >&g

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

On 15 March 2018 at 02:35, hl wrote: > Hi Emil, > > > > On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote: >> >> Hi Lin, >> >> On 14 March 2018 at 09:12, Lin Huang wrote: >>> >>> From: huang lin >>> >>

Re: [PATCH v4 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

On 14 March 2018 at 09:12, Lin Huang wrote: > From: huang lin > > The Innolux P097PFG panel is 9.7" panel with 1536X2048 > resolution, it reuse P079ZCA panel driver, so improve > p079ZCA dt-binding to support P097PFG. > > Change-Id:

Re: [PATCH v4 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

On 14 March 2018 at 09:12, Lin Huang wrote: > From: huang lin > > The Innolux P097PFG panel is 9.7" panel with 1536X2048 > resolution, it reuse P079ZCA panel driver, so improve > p079ZCA dt-binding to support P097PFG. > > Change-Id: I8704914898fe53b734d31fbe646df8aa5fd8b30d > Signed-off-by: Lin

Re: [PATCH v4 2/3] drm/panel: support Innolux P097PFG panel

On 14 March 2018 at 09:12, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse > the Innolux P079ZCA panel driver. > > Change-Id: I97923aa3735f707332681691b0231c9421b427d0 > Signed-off-by: Lin Huang > --- > Changes in v2: >

Re: [PATCH v4 2/3] drm/panel: support Innolux P097PFG panel

On 14 March 2018 at 09:12, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse > the Innolux P079ZCA panel driver. > > Change-Id: I97923aa3735f707332681691b0231c9421b427d0 > Signed-off-by: Lin Huang > --- > Changes in v2: > - None > Changes in v3: > - None > Changes

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

Hi Lin, On 14 March 2018 at 09:12, Lin Huang wrote: > From: huang lin > > Refactor Innolux P079ZCA panel driver, let it support > multi panel. > > Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2 > Signed-off-by: Lin Huang >

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

Hi Lin, On 14 March 2018 at 09:12, Lin Huang wrote: > From: huang lin > > Refactor Innolux P079ZCA panel driver, let it support > multi panel. > > Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2 > Signed-off-by: Lin Huang > --- > Changes in v2: > - Change regulator property name to meet

Re: [PATCH] video: fbdev: via: remove VLA usage

-reply-to` helps track the evolution of patches) > > This looks good to me: > Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com> > Same here Reviewed-by: Emil Velikov <emil.veli...@collabora.com> -Emil

Re: [PATCH] video: fbdev: via: remove VLA usage

s looks good to me: > Reviewed-by: Eric Engestrom > Same here Reviewed-by: Emil Velikov -Emil

Re: [PATCH] video: fbdev: via_aux_vt1632: remove VLA usage

Hi Gustavo, On 7 March 2018 at 19:54, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLA and replace it > with a fixed-length array instead. Also, remove variable 'len'. > What is the reason behind adding -Wvla? Is there a thread some that I can

Re: [PATCH] video: fbdev: via_aux_vt1632: remove VLA usage

Hi Gustavo, On 7 March 2018 at 19:54, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLA and replace it > with a fixed-length array instead. Also, remove variable 'len'. > What is the reason behind adding -Wvla? Is there a thread some that I can read up on? > Notice that

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

On 20 February 2018 at 13:12, Peter Zijlstra wrote: > On Tue, Feb 20, 2018 at 01:58:26PM +0100, Christian König wrote: >> amdgpu needs to verify if userspace sends us valid addresses and the simplest >> way of doing this is to check if the buffer object is locked with the

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

On 20 February 2018 at 13:12, Peter Zijlstra wrote: > On Tue, Feb 20, 2018 at 01:58:26PM +0100, Christian König wrote: >> amdgpu needs to verify if userspace sends us valid addresses and the simplest >> way of doing this is to check if the buffer object is locked with the ticket >> of the current

Re: [PATCH 1/8] clk: Add clk_bulk_alloc functions

HI Maciej, Just sharing a couple of fly-by ideas - please don't read too much into them. On 19 February 2018 at 15:43, Maciej Purski wrote: > When a driver is going to use clk_bulk_get() function, it has to > initialize an array of clk_bulk_data, by filling its id fields.

Re: [PATCH 1/8] clk: Add clk_bulk_alloc functions

HI Maciej, Just sharing a couple of fly-by ideas - please don't read too much into them. On 19 February 2018 at 15:43, Maciej Purski wrote: > When a driver is going to use clk_bulk_get() function, it has to > initialize an array of clk_bulk_data, by filling its id fields. > > Add a new function

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

On 17 January 2018 at 16:37, Daniel Thompson <daniel.thomp...@linaro.org> wrote: > > > On 17/01/18 14:36, Emil Velikov wrote: >> >> On 17 January 2018 at 14:01, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: >>> >>> Nothing in the entire tre

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

On 17 January 2018 at 16:37, Daniel Thompson wrote: > > > On 17/01/18 14:36, Emil Velikov wrote: >> >> On 17 January 2018 at 14:01, Daniel Vetter wrote: >>> >>> Nothing in the entire tree ever sets this, which means this is dead >>> code. Remove it

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

On 17 January 2018 at 14:01, Daniel Vetter wrote: > Nothing in the entire tree ever sets this, which means this is dead > code. Remove it. > > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han >

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

On 17 January 2018 at 14:01, Daniel Vetter wrote: > Nothing in the entire tree ever sets this, which means this is dead > code. Remove it. > > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Signed-off-by: Daniel Vetter > --- > drivers/video/backlight/generic_bl.c | 5 - Fly-by

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 4 December 2017 at 14:02, Jose Abreu wrote: > On 04-12-2017 13:16, Alexey Brodkin wrote: >> Option "kmsdev" "/dev/dri/card1" > > Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and > if you don't specify the busID it will fallback for the

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 4 December 2017 at 14:02, Jose Abreu wrote: > On 04-12-2017 13:16, Alexey Brodkin wrote: >> Option "kmsdev" "/dev/dri/card1" > > Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and > if you don't specify the busID it will fallback for the first > card that matches

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

On 1 December 2017 at 08:32, Philippe CORNU wrote: > Dear Nickey, > > Many thanks for your patch. > > I am sorry to say that but you can not add my "Acked-by" to this patch > because this code is different from the "original" one from Brian (which > got my "Acked-by"). >

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

On 1 December 2017 at 08:32, Philippe CORNU wrote: > Dear Nickey, > > Many thanks for your patch. > > I am sorry to say that but you can not add my "Acked-by" to this patch > because this code is different from the "original" one from Brian (which > got my "Acked-by"). > Small idea: I've seen

Re: [PATCH] drm/panel: support Innolux P097PFG panel

On 30 November 2017 at 06:13, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, > it refactor Innolux P079ZCA panel driver, let it support > multi panel, and add support P097PFG panel in this driver. > Couple of drive-by suggestions: Split the refactor

Re: [PATCH] drm/panel: support Innolux P097PFG panel

On 30 November 2017 at 06:13, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, > it refactor Innolux P079ZCA panel driver, let it support > multi panel, and add support P097PFG panel in this driver. > Couple of drive-by suggestions: Split the refactor vs new hw? >

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On 21 November 2017 at 15:07, <alexander.le...@verizon.com> wrote: > On Mon, Nov 20, 2017 at 11:21:52AM +0000, Emil Velikov wrote: >> - Document the autoselect process >>Information about about What, Why, and [ideally] How - analogous to >>the normal stable nomi

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On 21 November 2017 at 15:07, wrote: > On Mon, Nov 20, 2017 at 11:21:52AM +0000, Emil Velikov wrote: >> - Document the autoselect process >>Information about about What, Why, and [ideally] How - analogous to >>the normal stable nominations. >>Insert reference

  1   2   3   4   5   >