https://bugs.freedesktop.org/show_bug.cgi?id=105018
--- Comment #37 from L.S.S. ---
Attempted to lock the screen and leave it blank for a while to see what
happens, and it seems for the first time there are still errors related to
VBLANK, but they appear minor as the system woke up just fine.
I
This commit adds regular vblank events simulated through hrtimers, which
is a feature required by VKMS to mimic real hardware. Notice that
keeping the periodicity as close as possible to the one specified in
user space represents a vital constraint. In this sense, the callback
function implements
Hi Dave,
Nothing really big just a bunch improvements and a few fixes for Core
and Drivers. We have a cross subsystem merge here for fbcon.
Regards,
Gustavo
drm-misc-next-2018-07-04:
drm-misc-next for 4.19:
UAPI Changes:
v3d: add fourcc modicfier for fourcc for the Broadcom UIF format (Eric
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #23 from dwagner ---
Just for the record: At this point, I can say that with
amggpu.vm_update_mode=3 4.17.2-ARCH runs at least for hours,
not only the minutes it runs without this option before crashing.
I cannot, however, say that
https://bugs.freedesktop.org/show_bug.cgi?id=99528
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #8 from Timothy
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #16 from dwagner ---
(In reply to Andrey Grodzovsky from comment #15)
> We have only minor differences but I can't reproduce it. Maybe the resume
> failure is indeed due the eviction failure during suspend. Is S3 failure is
>
https://bugs.freedesktop.org/show_bug.cgi?id=107115
Jan Vesely changed:
What|Removed |Added
Depends on||87738
--- Comment #2 from Jan Vesely ---
https://bugs.freedesktop.org/show_bug.cgi?id=87738
Jan Vesely changed:
What|Removed |Added
Blocks||107115
Referenced Bugs:
Since KFD is only supported by a single GPU driver now (amdgpu), it
makes sense to merge the two. This has been raised on the amd-gfx list
before and I've been putting it off to avoid more churn while I was
working on upstreaming KFD. Now seems a good time to pick this up again.
At this stage
On Wed, Jul 4, 2018 at 7:22 PM, Emil Velikov wrote:
> On 4 July 2018 at 13:34, Daniel Vetter wrote:
>> On Wed, Jul 04, 2018 at 01:03:18PM +0100, Emil Velikov wrote:
>>> Hi Daniel,
>>>
>>> On 4 July 2018 at 10:29, Daniel Vetter wrote:
>>> > dma_fence_default_wait is the default now, same for the
On Wed, Jul 4, 2018 at 5:44 PM, Daniel Stone wrote:
> Hi,
> The atomic API being super-explicit about how userspace sequences its
> calls is great and all, but having shared global state implicitly
> dragged in is kind of ruining my day.
>
> Currently on Intel, Weston sometimes fails on hotplug,
https://bugs.freedesktop.org/show_bug.cgi?id=107115
--- Comment #1 from darkbasic ---
Awesome, I really hope that you will succeed!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=99553
--- Comment #18 from Greg V ---
Added a bug for darktable specifically: bug 107115
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=107115
Greg V changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Greg V changed:
What|Removed |Added
Depends on||107115
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=107115
Bug ID: 107115
Summary: Make darktable OpenCL support work on Clover and
RadeonSI
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: FreeBSD
Please check on lines 150-153. Both branches appear to be the same.
thanks,
julia
Courriel original
Objet: [radeon-alex:drm-next-4.19-wip 126/132]
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:150:1-3: WARNING: possible
condition with no effect (if == else)
Date: 04.07.2018 15:10
On 2018-07-04 01:54 PM, Gustavo A. R. Silva wrote:
>
>
> On 07/04/2018 12:51 PM, Harry Wentland wrote:
> [..]
@@ -145,8 +145,8 @@ static bool calculate_fb_and_fractional_fb_divider(
* of fractional feedback decimal point and the fractional FB Divider
precision
*
On 2018-07-04 01:27 PM, Kees Cook wrote:
> As already done treewide, switch from open-coded multiplication to
> 2-factor allocation helper.
>
> Signed-off-by: Kees Cook
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 8
> 1 file
On 2018-07-04 03:38 AM, Michel Dänzer wrote:
> On 2018-07-04 03:13 AM, Gustavo A. R. Silva wrote:
>> Add suffix ULL to constant 5 and cast variables target_pix_clk_khz and
>> feedback_divider to uint64_t in order to avoid multiple potential integer
>> overflows and give the compiler complete
On 4 July 2018 at 13:34, Daniel Vetter wrote:
> On Wed, Jul 04, 2018 at 01:03:18PM +0100, Emil Velikov wrote:
>> Hi Daniel,
>>
>> On 4 July 2018 at 10:29, Daniel Vetter wrote:
>> > dma_fence_default_wait is the default now, same for the trivial
>> > enable_signaling implementation.
>> >
>> > v2:
On Thu, Jul 5, 2018 at 12:17 AM, Matthias Brugger wrote:
>
>
> On 03/07/18 09:11, Lee Jones wrote:
>> On Mon, 25 Jun 2018, Matthias Brugger wrote:
>>> On 30/04/18 12:18, Lee Jones wrote:
On Fri, 27 Apr 2018, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The
On Wed, 04 Jul 2018, Matthias Brugger wrote:
>
>
> On 03/07/18 09:11, Lee Jones wrote:
> > On Mon, 25 Jun 2018, Matthias Brugger wrote:
> >> On 30/04/18 12:18, Lee Jones wrote:
> >>> On Fri, 27 Apr 2018, matthias@kernel.org wrote:
> >>>
> From: Matthias Brugger
>
> The MMSYS
https://bugs.freedesktop.org/show_bug.cgi?id=99426
Francesco Balestrieri changed:
What|Removed |Added
Priority|medium |lowest
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=89214
Francesco Balestrieri changed:
What|Removed |Added
Assignee|marius.c.v...@intel.com |dri-devel@lists.freedesktop
From: Deepak Rawat
Since svga device introduced new 64bit SVGA3dSurfaceAllFlags, vmwgfx
now stores the surface flags internally as SVGA3dSurfaceAllFlags.
For legacy surface define commands, only lower 32-bit is used.
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Reviewed-by: Brian
From: Deepak Rawat
Support for SVGA3D_SURFACE_MULTISAMPLE and surface mob size according
to sample count.
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Reviewed-by: Brian Paul
Reviewed-by: Thomas Hellstrom
Reviewed-by: Charmaine Lee
Signed-off-by: Thomas Hellstrom
---
From: Deepak Rawat
New ioctls DRM_VMW_GB_SURFACE_CREATE_EXT and DRM_VMW_GB_SURFACE_REF_EXT
are added which support 64-bit wide svga device surface flags, quality
level and multisample pattern.
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Reviewed-by: Brian Paul
Reviewed-by: Thomas
From: Deepak Rawat
A boolean flag in device private structure to specify if the device
support SM4_1.
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Reviewed-by: Brian Paul
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 18
From: Neha Bhende
A new command to support Intra-Surface-Copy.
Signed-off-by: Neha Bhende
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 28 +
1 file changed, 28 insertions(+)
diff --git
From: Neha Bhende
The device exposes a new capability register. Add upport for it.
Signed-off-by: Neha Bhende
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 +
..f1b803d34c59 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -43,10 +43,10 @@
#include
#define VMWGFX_DRIVER_NAME "vmwgfx"
-#define VMWGFX_DRIVER_DATE "20180322"
+#define VMWGFX_DRIVER_DATE "20180704"
#define
From: Deepak Rawat
SVGA device added new command SVGA3dCmdDefineGBSurface_v3 which allows
64-bit SVGA3dSurfaceAllFlags. This commit adds support for
SVGA3dCmdDefineGBSurface_v3 command in vmwgfx.
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Reviewed-by: Brian Paul
Reviewed-by:
This series introduces a header update and support for multisample surfaces.
Mesa support will follow in a couple of weeks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jun 29, 2018 at 11:47:40AM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> switches to using a kmalloc allocation and moves all the size calculations
> to the start to do an allocation. If an upper bounds on the mode timing
> calculations
Hi,
The atomic API being super-explicit about how userspace sequences its
calls is great and all, but having shared global state implicitly
dragged in is kind of ruining my day.
Currently on Intel, Weston sometimes fails on hotplug, because a
commit which only enables CRTC B (not touching CRTC A
Den 03.07.2018 19.18, skrev Mikulas Patocka:
On Tue, 3 Jul 2018, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Sunday, June 03, 2018 11:46:29 AM Mikulas Patocka wrote:
I have a USB display adapter using the udlfb driver and I use it on an ARM
board that doesn't have any graphics card. When I
From: Michel Dänzer
Fixes the BUG_ON spuriously triggering under the following
circumstances:
* reservation_object_reserve_shared is called with shared_count ==
shared_max - 1, so obj->staged is freed in preparation of an in-place
update.
* reservation_object_add_shared_fence is called
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
Acked-by: Hans Verkuil
Acked-for-MFD-by: Lee Jones
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed,
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Acked-for-MFD-by: Lee Jones
---
include/linux/mfd/cros_ec_commands.h | 81
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
Acked-by: Hans
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at
Hi All,
The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
through it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device
On Tuesday, July 03, 2018 01:18:57 PM Mikulas Patocka wrote:
>
> On Tue, 3 Jul 2018, Bartlomiej Zolnierkiewicz wrote:
>
> >
> > Hi,
> >
> > On Sunday, June 03, 2018 11:46:29 AM Mikulas Patocka wrote:
> > > I have a USB display adapter using the udlfb driver and I use it on an ARM
> > > board
https://bugs.freedesktop.org/show_bug.cgi?id=106306
--- Comment #4 from gr...@sub.red ---
> wattman functionality doesn't work at all;
> pp_od_clk_voltage prints nothing and doesn't accept anything. Is wattman
> even implemented for CI?
@Alex Deucher: Currently on 4.17.3 w/ dpm and the situation
On Wed, Jul 4, 2018 at 10:15 AM, Daniel Vetter wrote:
> On Wed, Jul 4, 2018 at 4:06 PM, Rob Clark wrote:
>> On Wed, Jul 4, 2018 at 9:23 AM, Archit Taneja wrote:
>>>
>>>
>>> On Wednesday 04 July 2018 12:28 AM, Rob Clark wrote:
On Tue, Jul 3, 2018 at 12:56 PM, Sean Paul wrote:
>
On Wed, 4 Jul 2018, Daniel Vetter wrote:
> On Sun, Jun 03, 2018 at 11:46:29AM -0400, Mikulas Patocka wrote:
> > I have a USB display adapter using the udlfb driver and I use it on an ARM
> > board that doesn't have any graphics card. When I plug the adapter in, the
> > console is properly
https://bugs.freedesktop.org/show_bug.cgi?id=106168
gr...@sub.red changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 2018-07-04 05:46 AM, Dan Carpenter wrote:
> The ->info[] array has DAL_IRQ_SOURCES_NUMBER elements so this condition
> should be >= instead of > or we could read one element beyond the end of
> the array.
>
> Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
> Signed-off-by: Dan
On 28.06.2018 18:44, Maciej Purski wrote:
> Current link mode values do not allow to enable packed pixel modes.
>
> Select packed pixel clock mode, if needed, every time the link mode
> register gets updated.
>
> Signed-off-by: Maciej Purski
Queued all three patches to drm-misc-fixes.
Regards
On Wed, Jul 4, 2018 at 4:06 PM, Rob Clark wrote:
> On Wed, Jul 4, 2018 at 9:23 AM, Archit Taneja wrote:
>>
>>
>> On Wednesday 04 July 2018 12:28 AM, Rob Clark wrote:
>>>
>>> On Tue, Jul 3, 2018 at 12:56 PM, Sean Paul wrote:
The bridge loses its hw state when the cable is unplugged. If
On Wed, Jul 4, 2018 at 9:23 AM, Archit Taneja wrote:
>
>
> On Wednesday 04 July 2018 12:28 AM, Rob Clark wrote:
>>
>> On Tue, Jul 3, 2018 at 12:56 PM, Sean Paul wrote:
>>>
>>> The bridge loses its hw state when the cable is unplugged. If we detect
>>> this case in the hpd handler, reset its
On Wednesday 04 July 2018 12:28 AM, Rob Clark wrote:
On Tue, Jul 3, 2018 at 12:56 PM, Sean Paul wrote:
The bridge loses its hw state when the cable is unplugged. If we detect
this case in the hpd handler, reset its state.
Reported-by: Rob Clark
Signed-off-by: Sean Paul
Tested-by: Rob
On Wed, 04 Jul 2018, Neil Armstrong wrote:
> Hi Lee,
>
> On 04/07/2018 09:47, Lee Jones wrote:
> > On Fri, 01 Jun 2018, Neil Armstrong wrote:
> >
> >> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> >> when the CEC feature bit is present.
> >>
> >> Signed-off-by: Neil
Hi Lee,
On 04/07/2018 09:47, Lee Jones wrote:
> On Fri, 01 Jun 2018, Neil Armstrong wrote:
>
>> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
>> when the CEC feature bit is present.
>>
>> Signed-off-by: Neil Armstrong
>> Reviewed-by: Enric Balletbo i Serra
>> Acked-by:
On Wed, Jul 04, 2018 at 01:03:18PM +0100, Emil Velikov wrote:
> Hi Daniel,
>
> On 4 July 2018 at 10:29, Daniel Vetter wrote:
> > dma_fence_default_wait is the default now, same for the trivial
> > enable_signaling implementation.
> >
> > v2: Also remove the relase hook, dma_fence_free is the
https://bugs.freedesktop.org/show_bug.cgi?id=105819
--- Comment #7 from AmirAli Akbari ---
Same problem on RX 460 card when running imagemagick's "mogrify" command. I'm
using Arch linux with latest stable version of kernel, mesa, and X.
$ mogrify -resize 400x300 piv.jpg
[ 3091.155960] amdgpu
On Wed, Jul 04, 2018 at 12:48:10PM +0300, Dan Carpenter wrote:
> The > should be >= here so that we don't read beyond the end of the
> dma->buflist[] array.
>
> Signed-off-by: Dan Carpenter
Uh, another root-hole driver ... Applied, thanks for the patch.
-Daniel
>
> diff --git
Am Dienstag, 3. Juli 2018, 14:16:28 CEST schrieb Andrzej Hajda:
> On 18.06.2018 12:28, Heiko Stuebner wrote:
> > __dw_mipi_dsi_probe() does all the grabbing of resources and does it using
> > devm-helpers. So this is happening on each try of master bringup possibly
> > slowing down things a lot.
>
On Wed, 04 Jul 2018, Daniel Vetter wrote:
> Hi Lee,
>
> On Wed, Jul 4, 2018 at 12:34 PM, Lee Jones wrote:
> > On Wed, 04 Jul 2018, Daniel Vetter wrote:
> >> On Wed, Jul 04, 2018 at 10:38:16AM +0100, Lee Jones wrote:
> >> > On Wed, 04 Jul 2018, Lee Jones wrote:
> >> >
> >> > > > Jani spotted
Hi Rob Herring,
Thanks for your review.
在 2018/7/4 2:25, Rob Herring 写道:
On Tue, Jun 26, 2018 at 03:15:39PM +0800, Sandy Huang wrote:
This path add support rv1108 and px30 rgb output interface driver.
Bindings are for h/w, not drivers.
I will update at next version as following:
This patch
Hi Daniel,
On 4 July 2018 at 10:29, Daniel Vetter wrote:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> v2: Also remove the relase hook, dma_fence_free is the default.
>
> Signed-off-by: Daniel Vetter
> Cc: Jani Nikula
> Cc: Joonas
Hi Lee,
On Wed, Jul 4, 2018 at 12:34 PM, Lee Jones wrote:
> On Wed, 04 Jul 2018, Daniel Vetter wrote:
>> On Wed, Jul 04, 2018 at 10:38:16AM +0100, Lee Jones wrote:
>> > On Wed, 04 Jul 2018, Lee Jones wrote:
>> >
>> > > > Jani spotted this when reviewing my earlier patch to remove the driver
>> >
On 03/07/18 19:18, Russell King - ARM Linux wrote:
> Can someone provide a deeper explanation about exactly what this
> property represents please?
>
> Does this represent the range of YCbCr values _into_ a YCbCr-to-RGB
> conversion (in other words, the range of values in the framebuffer),
> or
On 04/07/18 12:58, Russell King - ARM Linux wrote:
>> Hm maybe I misunderstood, but I thought the COLOR_RANGE is on the input
>> side.
> If that's the case, I should force it to only indicate support for
> limited range, while programming the CSC to produce full range RGB
> on its output (see
On Tue, Jul 03, 2018 at 05:18:57PM +0100, Russell King - ARM Linux wrote:
> Can someone provide a deeper explanation about exactly what this
> property represents please?
>
> Does this represent the range of YCbCr values _into_ a YCbCr-to-RGB
> conversion (in other words, the range of values in
On Wed, Jul 4, 2018 at 11:58 AM, Russell King - ARM Linux
wrote:
> On Wed, Jul 04, 2018 at 11:24:10AM +0200, Daniel Vetter wrote:
>> On Wed, Jul 04, 2018 at 10:05:41AM +0100, Russell King - ARM Linux wrote:
>> > On Wed, Jul 04, 2018 at 10:26:04AM +0200, Daniel Vetter wrote:
>> > > On Tue, Jul 03,
Am Dienstag, 3. Juli 2018, 17:06:48 CEST schrieb Andrzej Hajda:
> On 18.06.2018 12:28, Heiko Stuebner wrote:
> > >From a specified output port of one dsi controller this function allows to
> > iterate over the list of registered dsi controllers trying to find a second
> > instance connected to the
Am Dienstag, 3. Juli 2018, 14:42:49 CEST schrieb Andrzej Hajda:
> On 18.06.2018 12:28, Heiko Stuebner wrote:
> > When the panel-driver is build as a module it currently fails hard as the
> > panel cannot be probed directly:
> >
> > dw_mipi_dsi_bind()
> > __dw_mipi_dsi_probe()
> > creates dsi
On Wed, 04 Jul 2018, Daniel Vetter wrote:
> On Wed, Jul 04, 2018 at 10:38:16AM +0100, Lee Jones wrote:
> > On Wed, 04 Jul 2018, Lee Jones wrote:
> >
> > > > Jani spotted this when reviewing my earlier patch to remove the driver
> > > > internal usage of this field in
> > > >
> > > > commit
On Wed, Jul 04, 2018 at 10:38:16AM +0100, Lee Jones wrote:
> On Wed, 04 Jul 2018, Lee Jones wrote:
>
> > > Jani spotted this when reviewing my earlier patch to remove the driver
> > > internal usage of this field in
> > >
> > > commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
> > > Author: Daniel
https://bugzilla.kernel.org/show_bug.cgi?id=200387
--- Comment #28 from phoenix (fe...@feldspaten.org) ---
Hi Michel, Hi Christian,
that makes sense, I test it on a clean environment. Sorry, that I should have
done that in the first place :-/
--
You are receiving this mail because:
You are
The > should be >= here so that we don't read beyond the end of the
dma->buflist[] array.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/savage/savage_state.c
b/drivers/gpu/drm/savage/savage_state.c
index 2db89bed52e8..7559a820bd43 100644
--- a/drivers/gpu/drm/savage/savage_state.c
The ->info[] array has DAL_IRQ_SOURCES_NUMBER elements so this condition
should be >= instead of > or we could read one element beyond the end of
the array.
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Dan Carpenter
diff --git
This doesn't affect runtime because in the current code "idx" is always
valid.
First, we read from "vgdev->capsets[idx].max_size" before checking
whether "idx" is within bounds. And secondly the bounds check is off by
one so we could end up reading one element beyond the end of the
The ARRAY_SIZE() macro is type size_t. If s6e8aa0_dcs_read() returns a
negative error code, then "ret < ARRAY_SIZE(id)" is false because the
negative error code is type promoted to a high positive value.
Fixes: 02051ca06371 ("drm/panel: add S6E8AA0 driver")
Signed-off-by: Dan Carpenter
diff
On Wed, 04 Jul 2018, Lee Jones wrote:
> > Jani spotted this when reviewing my earlier patch to remove the driver
> > internal usage of this field in
> >
> > commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
> > Author: Daniel Vetter
> > Date: Wed Apr 25 19:42:52 2018 +0200
> >
> >
Am 04.07.2018 um 11:29 schrieb Daniel Vetter:
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
v2: Add misplaced hunk of kerneldoc from a different patch.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo
Hi,
On 07/04/2018 10:35 AM, Daniel Vetter wrote:
On Tue, Jul 03, 2018 at 09:14:50PM +0200, Thomas Hellstrom wrote:
From: Sinclair Yeh
vmw_kms_atomic_check_modeset() is currently checking config using the
legacy state, which is updated after a commit has happened.
This means
> Jani spotted this when reviewing my earlier patch to remove the driver
> internal usage of this field in
>
> commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
> Author: Daniel Vetter
> Date: Wed Apr 25 19:42:52 2018 +0200
>
> backlight: Nuke BL_CORE_DRIVER1
FYI, sending patches like this
On Mon, Jul 02, 2018 at 01:24:40PM +0300, Ville Syrjälä wrote:
> On Mon, Jul 02, 2018 at 10:12:21AM +0200, Daniel Vetter wrote:
> > This interface allows pretty much unlimited kernel memory allocations,
> > which isn't all that great. But we allow that anyway for any drm
> > master client (through
Am 04.07.2018 um 11:09 schrieb Michel Dänzer:
On 2018-07-04 10:31 AM, Christian König wrote:
Am 26.06.2018 um 16:31 schrieb Michel Dänzer:
From: Michel Dänzer
Fixes the BUG_ON spuriously triggering under the following
circumstances:
* ttm_eu_reserve_buffers processes a list containing
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Also remove the ->signaled callback, vgem can't peek ahead with a
fastpath, returning false is the default implementation.
Signed-off-by: Daniel Vetter
Cc: Kees Cook
Cc: Cihangir Akturk
Cc: Sean
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
v2: Add misplaced hunk of kerneldoc from a different patch.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc:
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
v2: Also remove the relase hook, dma_fence_free is the default.
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Colin
Hi all,
This is a resend of my dma-buf cleanup with the patches that didn't yet
get and ack/r-b. Feedback very much welcome.
Thanks, Daniel
Daniel Vetter (5):
drm/i915: Remove unecessary dma_fence_ops
drm/msm: Remove unecessary dma_fence_ops
drm/nouveau: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
v2: Also remove the relase hook, dma_fence_free is the default.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
dma_fence_default_wait is the default now.
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
On Wed, Jul 04, 2018 at 10:05:41AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 04, 2018 at 10:26:04AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 03, 2018 at 05:18:57PM +0100, Russell King - ARM Linux wrote:
> > > Can someone provide a deeper explanation about exactly what this
> > >
On Wed, Jul 04, 2018 at 10:58:25AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists
> > > listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc.
> >
> > Yeah, maintainers entry with you as maintainer plus dri-devel as
On Thu, May 03, 2018 at 03:32:38PM +0100, Daniel Thompson wrote:
> On Thu, May 03, 2018 at 04:15:17PM +0200, Daniel Vetter wrote:
> > Jani spotted this when reviewing my earlier patch to remove the driver
> > internal usage of this field in
> >
> > commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
On 2018-07-04 10:31 AM, Christian König wrote:
> Am 26.06.2018 um 16:31 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> Fixes the BUG_ON spuriously triggering under the following
>> circumstances:
>>
>> * ttm_eu_reserve_buffers processes a list containing multiple BOs using
>> the same
Hi,
> > Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists
> > listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc.
>
> Yeah, maintainers entry with you as maintainer plus dri-devel as mailing
> list plus drm-misc as repo would be good. Just grep for drm-misc.git
On Tuesday 03 July 2018 09:50 PM, Alex Deucher wrote:
On Mon, Jul 2, 2018 at 5:48 PM, Daniel Kurtz wrote:
Hi Alex,
On Sun, Apr 15, 2018 at 9:48 PM Agrawal, Akshu wrote:
On 4/13/2018 9:45 PM, Daniel Kurtz wrote:
Commit 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for
On Sun, Jun 03, 2018 at 11:46:29AM -0400, Mikulas Patocka wrote:
> I have a USB display adapter using the udlfb driver and I use it on an ARM
> board that doesn't have any graphics card. When I plug the adapter in, the
> console is properly displayed, however when I unplug and re-plug the
>
https://bugzilla.kernel.org/show_bug.cgi?id=200387
--- Comment #27 from Christian König (christian.koe...@amd.com) ---
(In reply to Michel Dänzer from comment #26)
> BTW, ideally you should only test with the kernel's own amdgpu driver, not
> with amdgpu-pro, because the later uses its own copies
Whole series is Acked-by: Christian König .
BTW: With patch #2 you created quite some noise in the news:
https://www.tomshardware.com/news/amd-vega-20-pcie-4.0,37389.html
Cheers,
Christian.
Am 25.06.2018 um 23:06 schrieb Alex Deucher:
This series exports some pcie helper functions for use by
On Tue, Jul 03, 2018 at 09:14:50PM +0200, Thomas Hellstrom wrote:
> From: Sinclair Yeh
>
> vmw_kms_atomic_check_modeset() is currently checking config using the
> legacy state, which is updated after a commit has happened.
>
> This means vmw_kms_atomic_check_modeset() will reject an invalid
1 - 100 of 141 matches
Mail list logo
