From: Emil Velikov
There's little point in providing partial and ancient information about
the struct_mutex. Some drivers are using it, new ones should not.
As-it this only provides for confusion.
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg
Reviewed-by: Daniel V
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Add helper, which will allow us to transition the drivers one by one,
dropping the suffix.
v2
From: Emil Velikov
Vast majority of DRM (core and drivers) are struct_mutex free.
As such we have only a handful of cases where the locked helper should
be used. Make that stand out a little bit better.
Done via the following script:
__from=drm_gem_object_put
__to=drm_gem_object_put_locked
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
The comment that struct_mutex must be held is misleading. It is only
required when .gem_free_object() is used.
Since that one is going with the next patches, drop the reference.
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg
Reviewed-by: Daniel Vetter
---
drivers/gpu
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
The driver does not hold struct_mutex, thus using the locked version of
the helper is incorrect.
Cc: Alex Deucher
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
Fixes: a39414716ca0 ("drm/amdgpu: add independent DMA-buf import v9"):
Signed-off-by: Emil Veli
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
As of last commit, all the drivers have been updated away from the
_unlocked helper. As such we can now remove the transient #define.
v2: keep sed and #define removal separate
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg (v1
From: Emil Velikov
No drivers set the callback, so remove it all together.
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem.c | 22 +++---
include/drm/drm_drv.h | 8
include/drm/drm_gem.h | 5
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
__from
From: Emil Velikov
With earlier patch we removed the overhead so now we can lift the helper
into the header effectively folding it with __drm_object_put.
v2: drop struct_mutex references (Daniel)
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg (v1)
Reviewed-by: Daniel Vetter
---
drivers
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:
Add the COMPILE_TEST conditional, so that people can at least build test
the drivers.
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: Mali DP Maintainers
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
Please merge through the ARM tree.
Aside: would make sense to have the tree
esktop.org
Signed-off-by: Emil Velikov
---
Compile tested only. Please test locally and merge through your tree.
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 26
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drive
ned-off-by: Emil Velikov
---
Compile tested only. Please test locally and merge through your tree.
---
drivers/gpu/drm/arm/malidp_drv.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_d
On Wed, 6 May 2020 at 02:32, Sandy Huang wrote:
>
> Hi Emil Velikov,
>
> 在 2020/5/5 下午11:16, Emil Velikov 写道:
> > From: Emil Velikov
> >
> > The function vop_cfg_done() is a simple VOP_REG_SET(). As such it should
> > be done under a reg_lock. A quick lo
On Mon, 23 Mar 2020 at 12:13, Dan Carpenter wrote:
>
> On Mon, Mar 23, 2020 at 11:13:22AM +, Emil Velikov wrote:
> > Hi Dan,
> >
> > On Fri, 20 Mar 2020 at 13:23, Dan Carpenter
> > wrote:
> > >
> > > If the "handles" allocation or t
On Thu, 17 Aug 2017 at 12:34, Jani Nikula wrote:
>
> On Thu, 17 Aug 2017, Michael Tretter wrote:
> > Using plain echo to set the "force" connector attribute fails with
> > -EINVAL, because echo appends a newline to the output.
> >
> > Replace strcmp with sysfs_streq to also accept strings that en
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
On Thu, 14 May 2020 at 15:35, Hans de Goede wrote:
>
> Hi,
>
> On 5/14/20 11:53 AM, Emil Velikov wrote:
> > Hi Hans,
> >
> > On Thu, 30 Apr 2020 at 15:55, Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 4/30/20 4:52 PM, Ville S
On Thu, 14 May 2020 at 14:28, Bartlomiej Zolnierkiewicz
wrote:
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 1b2f5f31fb6f..cad3e4bc5e52 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -868,6 +868,7 @@ config FB_ATMEL
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Emil Velikov
Acked-by: Daniel Vetter (v1)
---
Hi all unless, there are
devel@lists.freedesktop.org
Signed-off-by: Emil Velikov
Acked-by: Daniel Vetter (v1)
---
MAINTAINERS | 3 +--
drivers/video/fbdev/Kconfig | 4
drivers/video/fbdev/nvidia/nvidia.c | 3 +++
drivers/video/fbdev/riva/fbdev.c| 3 +++
4 files changed, 11 insertions(+), 2 dele
From: Emil Velikov
The question of "what process is this pid" keeps on popping up, so lets
print the process name alongside the pid.
Cc: Mauro Rossi
Cc: Bob Beckett
Cc: Pekka Paalanen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 7 ---
drivers/gpu/drm/drm_io
From: Emil Velikov
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 9b79bfc60ad7..97f7793b693f 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu
On Mon, 18 May 2020 at 10:22, Jani Nikula wrote:
>
> On Sun, 17 May 2020, Emil Velikov wrote:
> > On Thu, 17 Aug 2017 at 12:34, Jani Nikula
> > wrote:
> >>
> >> On Thu, 17 Aug 2017, Michael Tretter wrote:
> >> > Using plain echo to set the "
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 module?
Hi Benjamin,
On Mon, 18 May 2020 at 01:45, Benjamin Herrenschmidt
wrote:
>
> On Sun, 2020-05-17 at 23:05 +0100, Emil Velikov wrote:
> > As mentioned in earlier commit, the riva and nvidia fbdev drivers
> > have
> > seen no love over the years, are short on features a
Hi Michael,
On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote:
>
> Emil Velikov writes:
> > As mentioned in earlier commit, the riva and nvidia fbdev drivers have
> > seen no love over the years, are short on features and overall below par
> >
> > Users a
On Mon, 18 May 2020 at 13:48, Bartlomiej Zolnierkiewicz
wrote:
>
>
> On 5/18/20 1:19 PM, Emil Velikov wrote:
> > Hi Michael,
> >
> > On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote:
> >>
> >> Emil Velikov writes:
> >>> As mentioned
On Sat, 16 May 2020 at 22:23, Chris Wilson wrote:
>
> drivers/gpu/drm/drm_client_modeset.c: In function
> ‘drm_client_firmware_config’:
> ./include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0
> is always false [-Wtype-limits]
>__builtin_constant_p((l) > (h)), (l) > (h)
l in the constant expression.
Fixes: 295bcca84916 ("linux/bits.h: add compile time sanity check of
GENMASK inputs")
Cc: Rikard Falkeborn
Cc: Linus Torvalds
Cc: Chris Wilson
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
>From some quick testing, this works as e
> `drm_atomic_helper_connector_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
helper for creating BOs with cached mappings
> * update udl on the new helper
>
> Thomas Zimmermann (2):
> drm/shmem-helper: Add .gem_create_object helper that sets map_cached
> flag
> drm/udl: Use GEM vmap/mmap function from SHMEM helpers
>
For the seri
l in the constant expression.
v2: drop accidental !
Fixes: 295bcca84916 ("linux/bits.h: add compile time sanity check of
GENMASK inputs")
Cc: Rikard Falkeborn
Cc: Linus Torvalds
Cc: Chris Wilson
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reported-by: kbuild test
Hi Rohan,
As a high-level question: how does this compare to VC4_LABEL_BO?
Is it possible to implement to replace or partially implement the vc4
one with this infra?
IMHO this is something to aim for.
A handful of ideas and suggestions below:
On Thu, 14 May 2020 at 16:05, Rohan Garg wrote:
>
On Mon, 18 May 2020 at 12:10, Liviu Dudau wrote:
>
> On Sun, May 17, 2020 at 08:36:53PM +0100, Emil Velikov wrote:
> > Add the COMPILE_TEST conditional, so that people can at least build test
> > the drivers.
> >
> > Cc: Liviu Dudau
>
> Acked-by: Liviu Du
Hi Sam,
On Sun, 17 May 2020 at 20:02, Sam Ravnborg wrote:
>
> Increase readability of fb_notifier_callback() by removing
> a few indent levels.
> No functional change.
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
> drivers/video/backlight/backl
On Sun, 17 May 2020 at 20:02, Sam Ravnborg wrote:
>
> The backlight support has two properties that express the state:
> - power
> - state
>
> It is un-documented and easy to get wrong.
> Add backlight_is_blank() helper to make it simpler for drivers
> to get the check of the state correct.
>
> A
Hi Sam,
On Sun, 17 May 2020 at 20:02, Sam Ravnborg wrote:
> --- a/drivers/video/backlight/88pm860x_bl.c
> +++ b/drivers/video/backlight/88pm860x_bl.c
> @@ -123,13 +123,7 @@ static int pm860x_backlight_update_status(struct
> backlight_device *bl)
> {
> int brightness = bl->props.brightn
Hi Sam,
It's a little weird to see this series, just after I mentioned that I
had one in the works.
Either way, patches 2 and 16 need some work. Although if you prefer
that can be done as follow-up.
For the rest:
Reviewed-by: Emil Velikov
n't looked into this patch in detail, but allowing to call *_put()
> > functions with NULL and nothing bad happens is rather common practice.
> >
> > On the other hand I agree that this might cause a performance problem.
> > How many sites do we have which could call drm_gem_object_put() with NULL?
>
> Just to put this in a tiny bit of perspective, for i915.ko
>
> add/remove: 0/0 grow/shrink: 141/20 up/down: 2211/-525 (1686)
>
> We've had flame wars for less. (Because it's easy to argue over little
> changes.) Now this is just from this patch and not the revert...
> The revert has no effect on code size.
If we play the revert game thing will never end with having it fixed :-(
I'd suggest sticking with the NULL check, maybe even a WARN to aid
debug the 240 usecases.
For the patch:
Fixes: b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and
__drm_gem_object_put()")
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 20 May 2020 at 14:30, Emil Velikov wrote:
>
> On Wed, 20 May 2020 at 14:17, Chris Wilson wrote:
> >
> > Quoting Christian König (2020-05-20 13:54:55)
> > > Am 20.05.20 um 14:49 schrieb Chris Wilson:
> > > > Quoting Christian König (2020-05-20
/0xa9
> [ 11.584440] RIP: 0033:0x7f0ef80f7227
>
> Reported-by: Nirmoy Das
> Fixes: b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and
> __drm_gem_object_put()")
> Signed-off-by: Chris Wilson
> Cc: Nirmoy Das
> Cc: Emil Velikov
> Cc: Christian König .
> Ack
On Thu, 21 May 2020 at 01:07, Rohan Garg wrote:
>
> Hey Emil
> I've applied all the suggestions except the ones I discuss below.
>
> >
> > As a high-level question: how does this compare to VC4_LABEL_BO?
> > Is it possible to implement to replace or partially implement the vc4
> > one with this in
Hi Thomas,
On Fri, 22 May 2020 at 14:53, Thomas Zimmermann wrote:
>
> The kirin driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> these defaults and .dumb_create in struct drm_driver. All remaining
> ope
On Fri, 22 May 2020 at 18:48, Sam Ravnborg wrote:
>
> Hi Thomas.
>
> On Fri, May 22, 2020 at 03:52:26PM +0200, Thomas Zimmermann wrote:
> > Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
> > helpers.
> This part is fine, I like that the naming is somehow consistent.
>
> > An intern
re's a small comment in the kirin patch - with that resolved the series is:
Acked-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Rikard,
On 2020/05/19, Rikard Falkeborn wrote:
> + Andrew et al who recieved mail from the build robot this morning about
> the same issue.
>
> On Tue, May 19, 2020 at 10:14:52PM +0100, Emil Velikov wrote:
> > Recently the GENMASK_INPUT_CHECK() was added, aiming to cat
- ifdef check around the sysfs handling - only Linux has comprehensive
sysfs
- compile and run-time test
Cc: Chih-Wei Huang
Cc: Mauro Rossi
Signed-off-by: Emil Velikov
---
Chih-Wei, Mauro
Here is a quick WIP which should get you going. I have _not_ tested it
so it might need some polish
On Thu, 28 May 2020 at 10:46, /wrote:
>
> Simon Ser 於 2020年5月25日 週一 上午3:25寫道：
> > On Sunday, May 24, 2020 8:53 PM, Daniel Vetter wrote:
> > > On Sat, May 23, 2020 at 5:44 PM Mauro Rossi issor.or...@gmail.com wrote:
> > >
> > > > OpenByFB is introduced to overcome GPU driver loading order issue
>
Hi all,
I realise this has landed, so a small FYI comment.
On Sat, 9 May 2020 at 15:16, Noralf Trønnes wrote:
> +int drm_client_framebuffer_flush(struct drm_client_buffer *buffer, struct
> drm_rect *rect)
> +{
> + if (!buffer || !buffer->fb || !buffer->fb->funcs->dirty)
Hmm cannot think
Hi Rohan,
On Thu, 28 May 2020 at 14:38, Rohan Garg wrote:
>
> Introduce tests to cover the new generic labeling ioctl's
> being reviewed here [1].
>
> Signed-off-by: Rohan Garg
>
> [1] https://patchwork.freedesktop.org/series/77267/
>
> Signed-off-by: Rohan Garg
> ---
> include/drm-uapi/drm.h
On Mon, 25 May 2020 at 13:41, Thomas Zimmermann wrote:
>
> Hi Emil
>
> Am 22.05.20 um 20:11 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Fri, 22 May 2020 at 14:53, Thomas Zimmermann wrote:
> >>
> >> The kirin driver uses the default imple
On Sun, 24 May 2020 at 19:35, Daniel Vetter wrote:
>
> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes wrote:
> >
> >
> >
> > Den 24.05.2020 18.13, skrev Paul Cercueil:
> > > Hi list,
> > >
> > > I'd like to open a discussion about the current support of MIPI DSI and
> > > DBI panels.
> > >
> > >
Hi Niklas,
On Fri, 22 May 2020 at 07:56, Niklas Söderlund
wrote:
>
> Bayer formats are used with cameras and contain green, red and blue
> components, with alternating lines of red and green, and blue and green
> pixels in different orders. For each block of 2x2 pixels there is one
> pixel with a
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 (l
On Tue, 5 May 2020 at 17:05, Emil Velikov wrote:
>
> Currently the function heap allocates when we have any payload. Where in
> many case the payload is 1 byte - ouch.
>
> From casual observation, vast majority of the payloads are smaller than
> 8 bytes - so use a stack array
cheidegger
Signed-off-by: Emil Velikov
---
VMWare team, I'm planning to push this via drm-misc. Review, ack and
comments are appreciated.
---
drivers/gpu/drm/drm_auth.c | 33 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 +++
include/drm/drm_drv.h
The variables are already the exact same value or will be overwritten
shortly afterwords. In either case there's no functional difference.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_auth.c | 3 +--
1 file changed, 1 insertion(+), 2 dele
On Sat, 30 May 2020 at 08:48, Sam Ravnborg wrote:
>
> Hi Emil.
>
> On Fri, May 29, 2020 at 10:48:07PM +0100, Emil Velikov wrote:
> > The variables are already the exact same value or will be overwritten
> > shortly afterwords. In either case there's no function
Vetter
Cc: VMware Graphics
Cc: Roland Scheidegger
Signed-off-by: Emil Velikov
Cc: Sam Ravnborg
Reviewed-by: Sam Ravnborg
---
VMWare team, I'm planning to push this via drm-misc. Review, ack and
comments are appreciated.
---
drivers/gpu/drm/drm_auth.c | 32 +++
Ian King
Signed-off-by: Emil Velikov
---
Colin, pretty sure that this should address couple of Coverity warnings.
Yet I didn't check their web UI thingy.
---
drivers/gpu/drm/drm_auth.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_aut
On Sat, 30 May 2020 at 14:18, Sam Ravnborg wrote:
>
> Hi Emil.
> On Sat, May 30, 2020 at 01:46:40PM +0100, Emil Velikov wrote:
> > Currently the ret handling is all over the place - with two redundant
> > assignments and another one addressed earlier.
> >
> >
HI Laurent,
>From a quick glance the series looks really good and neat. Then again,
I don't know much about the hardware to provide meaningful review.
A couple of small ideas below.
On Sat, 30 May 2020 at 04:11, Laurent Pinchart
wrote:
> +#define LCDC_AS_BUF0x220
> +#define
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 the
rk?
Something like the following helps:
... 90 degrees rotated, albeit in the opposite direction. Add a quirk for this.
With that the series is:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.f
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 vkms
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
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 \
> + vkms_crt
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 a
0bwa_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 217,
> + .height = 136,
> + },
> + .delay = {
> + .prepare = 1000,
> + .enable = 1000,
> + .unprepare = 1000,
> +
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 a
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,
> vide
mentation fixed (pointer
by Daniel) patches 1-12 are:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
On Tue, 2 Jun 2020 at 01:31, Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg wrote:
> >
> > The Seiko 70WVW2T is a discontinued product, but may be used somewhere.
> > Tested on a proprietary product.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Søren Andersen
> > Cc
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
901 - 1000 of 2172 matches
Mail list logo
