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 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: Em
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
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
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
No drivers set the callback, so remove it all together.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_gem.c | 22 +++---
include/drm/drm_drv.h | 8
include/drm/drm_gem.h | 5 +++--
3 files changed, 6 insertions(+), 29 deletions
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
With earlier patch we removed the normal overhead so now we can lift
the helper to the header, folding it __drm_object_put.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_gem.c | 19 ---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2
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
---
drivers/gpu/drm/drm_gem.c | 1 -
1 file changed, 1 deletion
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
On Thu, 7 May 2020 at 13:29, Vinay Simha B N wrote:
>
> Emil,
>
> Reply inline
>
> On Tue, 5 May 2020 at 9:35 PM, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently
>&
On Fri, 8 May 2020 at 09:16, Christian König wrote:
>
> Am 07.05.20 um 20:03 schrieb Sam Ravnborg:
> > Hi Emil.
> >
> > On Thu, May 07, 2020 at 04:07:52PM +0100, Emil Velikov wrote:
> >> From: Emil Velikov
> >>
> >> The driver does not hold stru
Hi Sam,
On Thu, 7 May 2020 at 19:01, Sam Ravnborg wrote:
>
> Hi Emil.
>
> On Thu, May 07, 2020 at 04:07:50PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There's little point in providing partial and ancient information about
> > the str
On Fri, 8 May 2020 at 07:27, Daniel Vetter wrote:
>
> On Thu, May 07, 2020 at 04:07:50PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There's little point in providing partial and ancient information about
> > the struct_mutex. Some driver
On Thu, 7 May 2020 at 19:14, Sam Ravnborg wrote:
>
> Hi Emil.
>
> On Thu, May 07, 2020 at 04:08:22PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Spelling out _unlocked for each and every driver is a annoying.
> > Especially if we consider how m
On Fri, 8 May 2020 at 07:33, Jani Nikula wrote:
>
> On Thu, 07 May 2020, Emil Velikov wrote:
> > 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
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.
>
On Thu, 7 May 2020 at 19:17, Sam Ravnborg wrote:
>
> Hi Emil.
> On Thu, May 07, 2020 at 04:07:46PM +0100, Emil Velikov wrote:
> > Hi all,
> >
> > Recently I had a look at the new dmabuf AMDGPU implementation.
> >
> > Seemingly it was using the wrong drm_ge
Hi Christian,
On Fri, 8 May 2020 at 10:23, Christian König wrote:
>
> Am 07.05.20 um 17:07 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Spelling out _unlocked for each and every driver is a annoying.
> > Especially if we consider how many drivers, do not k
On Fri, 8 May 2020 at 07:43, Daniel Vetter wrote:
>
> On Thu, May 07, 2020 at 04:07:55PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > With earlier patch we removed the normal overhead so now we can lift
> > the helper to the header, folding it __drm_obj
On Fri, 8 May 2020 at 07:40, Daniel Vetter wrote:
>
> On Thu, May 07, 2020 at 04:07:56PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Vast majority of DRM (core and drivers) are struct_mutex free.
> >
> > As such we have only a handful of cases w
On Tue, 5 May 2020 at 17:05, Emil Velikov wrote:
>
> From: Emil Velikov
>
> A few of the new panels create a local macro wrapping around
> mipi_dsi_dcs_write. At the same time, they don't really care about the
> command/payload split.
>
> mipi_dsi_dcs_write do
On Mon, 11 May 2020 at 21:43, Dave Airlie wrote:
>
> On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
> >
> > On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir
> > wrote:
> > >
> > > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > > Hi guys,
> > >
> > > > Well let's face it AGP i
Hi Thomas,
On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote:
>
> The suspend/resume helpers are unused. Also remove associated state
> from struct mga_device.
>
Although DPMS in it's traditional sense is no longer a thing, would it
make sense to keep this around for documentation purposes?
I
Hi Thomas,
On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote:
> static void mga_crtc_init(struct mga_device *mdev)
> {
> struct drm_device *dev = mdev->dev;
> - struct mga_crtc *mga_crtc;
> -
> - mga_crtc = kzalloc(sizeof(struct mga_crtc) +
> -
Hi Thomas,
On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote:
> @@ -1143,20 +1178,15 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
> WREG_CRT(13, 0);
> WREG_CRT(14, 0);
> WREG_CRT(15, 0);
> - WREG_CRT(19, pitch & 0xFF);
> -
This write has disappeared wi
in system memory, and are shadow-copied into VRAM during page
> flips. The shadow copy always starts at VRAM offset 0.
>
I suspect MGAG200_FLAG_HW_BUG_NO_STARTADD is left around for
documentation purposes?
I've made a few small comments, but regar
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,
>
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.
>
On Tue, 12 May 2020 at 19:34, Thomas Zimmermann wrote:
>
> Hi Emil
>
> Am 12.05.20 um 12:27 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote:
> >
> >> @@ -1143,20 +1178,15 @@ stati
On Tue, 12 May 2020 at 19:47, Thomas Zimmermann wrote:
>
> Hi
>
> Am 12.05.20 um 12:14 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote:
> >>
> >> The suspend/resume helpers are unused. Also rem
On Tue, 12 May 2020 at 20:48, Alex Deucher wrote:
> > >>
> > >> There's some AGP support code in the DRM core. Can some of that declared
> > >> as legacy?
> > >>
> > >> Specifically, what about these AGP-related ioctl calls? Can they be
> > >> declared as legacy? It would appear to me that KMS-ba
| 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
Hi Vinay,
On Thu, 7 May 2020 at 17:18, Emil Velikov wrote:
>
> On Thu, 7 May 2020 at 13:29, Vinay Simha B N wrote:
> >
> > Emil,
> >
> > Reply inline
> >
> > On Tue, 5 May 2020 at 9:35 PM, Emil Velikov
> > wrote:
> >&g
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 ne
All the users threat them as immutable - annotate them as such.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ker...@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 th
: 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/k
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-ker...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Please keep me in the CC list, as I'm not subscribed t
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-ker...@vger.kernel.org
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: linux...@vger.kernel.org
Signed-off-by: Em
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
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-ker...@vger.kernel.org
Cc: Jason Wessel
Cc: Daniel Thompson
Cc: kgdb-bugrep...@lists.sourceforge.net
Signed-off-by: Emil
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-ker...@vger.kernel.org
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Please
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-ker...@vger.kernel.org
Cc: "Paul E. McKenney"
Cc: Josh Triplett
Cc: r...@vger.kernel.org
Signed-off-by: Em
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-ker...@vger.kernel.org
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Please keep me in
sysrq op and
constify the sysrq handling.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ker...@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 t
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/gp
/broken, referring to nouveau in the help text.
Cc: Antonino Daplas
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
MAINTAINERS | 3 +--
arch/powerpc/configs/g5_defconfig | 2 --
arch
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 driv
Hi Hans,
On Thu, 30 Apr 2020 at 15:55, Hans de Goede wrote:
>
> Hi,
>
> On 4/30/20 4:52 PM, Ville Syrjälä wrote:
> > On Thu, Apr 30, 2020 at 02:47:00PM +0100, Emil Velikov wrote:
> >> Hi Hans,
> >>
> >> On Fr
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
On Fri, 5 Jun 2020 at 15:07, Emil Velikov wrote:
>
> On Wed, 3 Jun 2020 at 19:37, Roland Scheidegger wrote:
> >
> > Looks like a nice cleanup to me. (No idea if at some point there
> > actually was a reason for a return value...)
> >
> It was required up-to qu
On Thu, 4 Jun 2020 at 08:30, Daniel Vetter wrote:
>
> On Wed, Jun 03, 2020 at 06:04:34PM +0100, Emil Velikov wrote:
> > Add some information about pre-atomic modeset properties alongside a
> > list of suggestions how to handle the different instances.
> >
> &g
On Mon, 1 Jun 2020 at 18:42, Liviu Dudau wrote:
>
> Hi Emil,
>
> On Wed, May 20, 2020 at 12:54:17AM +0100, Emil Velikov 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:
>
i Laurent,
On Sun, 7 Jun 2020 at 00:02, Laurent Pinchart
wrote:
>
> Hi Emil,
>
> On Fri, Jun 05, 2020 at 03:58:53PM +0100, Emil Velikov wrote:
> > Hi Laurent,
> >
> > With the previous disclaimer in mind, the series is:
> > Reviewed-by: Emil Velikov
>
&
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 sti
Hi all,
On Thu, 4 Jun 2020 at 08:11, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a -64.9% regression of
> phoronix-test-suite.glmark2.800x600.score due to commit:
>
On one hand, I'm really happy to see performance testing happening
although this report is missing various crucial p
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 patche
r *fb,
> struct drm_rect *rect)
> bool full;
> void *tr;
>
> - if (!dbidev->enabled)
> + if (WARN_ON(!fb))
> return;
>
AFAICT no other driver has such WARN_ON. Let's drop that - it is
pretty confusing and misleading as-is.
With t
Hi Manasi,
On Sat, 13 Jun 2020 at 00:55, Manasi Navare wrote:
>
> From: Bhanuprakash Modem
>
> [Why]
> It's useful to know the min and max vrr range for IGT testing.
>
> [How]
> Expose the min and max vfreq for the connector via a debugfs file
> on the connector, "vrr_range".
>
> Example usage:
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 insertions
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]. Si
P_AST2000, NULL),
> AST_VGA_DEVICE(PCI_CHIP_AST2100, NULL),
> - /* AST_VGA_DEVICE(PCI_CHIP_AST1180, NULL), - don't bind to 1180
> for now */
Since we don't bind to this pciid, the (removed) code is never
used/dead. For the series:
Reviewed-by: Emil Veliko
Hi Linus,
On Sat, 13 Jun 2020 at 23:30, Linus Walleij wrote:
>
> The following bug appeared in the MCDE driver/display
> initialization during the recent merge window.
>
> First the place we call drm_fbdev_generic_setup() in the
> wrong place: this needs to be called AFTER calling
> drm_dev_regis
Hi Rong,
Thanks for the prompt reply and information. Can I suggest including
the suggested information in future reports.
I've included a command for each one, to aid automating things.
Namely:
Xorg: 1.20.4 (or None)
$ which Xorg 2>/dev/null || echo None && Xorg -version |& grep -o "X
Server.*"
On Tue, 16 Jun 2020 at 07:50, Daniel Vetter wrote:
>
> On Mon, Jun 15, 2020 at 11:35 PM Emil Velikov
> wrote:
> >
> > Hi Daniel,
> >
> > On Fri, 12 Jun 2020 at 17:01, Daniel Vetter wrote:
> > >
> > > The atomic helpers try really hard to
Hi 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
Hi Thomas,
On Tue, 16 Jun 2020 at 15:26, Thomas Zimmermann wrote:
>
> The original modesetting code set MISC to 0x2d, which is ,
> and
>
> With the conversion to atomic modesetting, accidentally
> got enabled as well. Revert this change and initialize MISC with a
> constant value of and . The
On Mon, 15 Jun 2020 at 22:47, Manasi Navare wrote:
>
> On Mon, Jun 15, 2020 at 10:36:28PM +0100, Emil Velikov wrote:
> > Hi Manasi,
> >
> > On Sat, 13 Jun 2020 at 00:55, Manasi Navare
> > wrote:
> > >
> > > From: Bhanuprakash Modem
> > &
On Tue, 16 Jun 2020 at 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 plane r
Hi all,
Inspired by Linus and my personal confusion with the report, allow me
to put some suggestions. Followed by an illustrative example.
On Wed, 10 Jun 2020 at 08:38, kernel test robot wrote:
>
> Hi Linus,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on dr
Hi all,
Allow me to compare this approach with some work Linus W [1] did a
while back, which I've just noticed.
Pauls' approach:
- Perhaps the shortest one possible
Porting an existing DSI panel to DBI is 3 lines of code - compat line
in the SPI/DSI bridge, a bus_type and
mipi_dsi_maybe_registe
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,
> >>>
>
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 drm-
On Wed, 17 Jun 2020 at 07:28, Thomas Zimmermann wrote:
> Maybe I can write a better commit message to highlight the change.
>
That would be amazing, thank you.
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.or
Hi Dan,
On Fri, 20 Mar 2020 at 13:23, Dan Carpenter wrote:
>
> If the "handles" allocation or the copy_from_user() fails then we leak
> "objs". It's supposed to be freed in panfrost_job_cleanup().
>
> Fixes: c117aa4d8701 ("drm: Add a drm_gem_objects_lookup helper")
> Signed-off-by: Dan Carpenter
Hi all,
Just a small fly-by idea.
On Thu, 19 Mar 2020 at 20:25, wrote:
>
> From: Deepak Rawat
>
> Surface define v4 added new member buffer_byte_stride. With this patch
> add buffer_byte_stride in surface metadata and create surface using new
> command if support is available.
>
> Also with thi
On Thu, 9 Apr 2020 at 12:53, Sam Ravnborg wrote:
>
> The samsung-s6e63j0x03 had a local way to handle backlight.
>
> Update the driver to use a devm_ based register function
> and utilize drm_panel backlight support. The changes results
> in a simpler driver with the same functionality.
>
> Signed
Hey Keith,
Most of the cool kids prefer gitlab MR, can you open one going forward?
That aside, here is some long overdue input on the patch itself.
My biggest concern that we expose the extension, even when it's not implemented.
The rest are rather minor - more documentation/comments, style fixes
From: Emil Velikov
No dev->struct_mutex anywhere to be seen.
Cc: Patrik Jakobsson
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
From: Emil Velikov
Use the drm_gem_object_put_unlocked in the documentation for
drm_gem_objects_lookup. The locked version of the helper should be used
solely by people who know exactly what they are doing.
Should prevent issues like ones adddressed with the next patch.
Signed-off-by: Emil
From: Emil Velikov
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg
Reviewed-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 658b52f7ffc6..2ce52c5917f8
)
Considering other have pending work, which may clash with this series
and the overall positive feedback (thanks everyone), I'm inclined to
merge the series to drm-misc-next on Monday evening.
-Emil
Emil Velikov (38):
drm: remove unused drm_gem.h include
drm/gem: use _unlocked referen
From: Emil Velikov
The mutex should be used, only by legacy drivers. Add a big warning to
deter people from using it.
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
Signed-off-by: Emil Velikov
---
include/drm/drm_device.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a
From: Emil Velikov
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_vm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 56197ae0b2f9..954baa8a2a8f 100644
--- a/drivers/gpu
801 - 900 of 2172 matches
Mail list logo
