Am 30.08.2017 um 20:02 schrieb Alex Deucher:
Fixes the tarball generation.
fixes: 9d133dd08720d80dfc8ce098bf0972 (tests/amdgpu: add uvd encode unit tests)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=102391
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
tests/amdgpu/Ma
On Wed, 30 Aug 2017, Himanshu Jha wrote:
> kfree on NULL pointer is a no-op and therefore checking is redundant.
IMO the code has more clarity as it is.
BR,
Jani.
>
> Signed-off-by: Himanshu Jha
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 6 ++
> 1 file changed, 2 insertions(+), 4 del
https://bugs.freedesktop.org/show_bug.cgi?id=102301
Andrew changed:
What|Removed |Added
Summary|4.12, AMD A10-9600P,|AMD A10-9600P, AMD-Vi:
|AMD-
On Wed, Aug 30, 2017 at 10:55 PM, Rhys Kidd wrote:
> Signed-off-by: Rhys Kidd
> ---
> .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 1 +
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +++
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 +
> drivers/gpu/drm/nouveau/n
On Tue, Aug 29, 2017 at 08:56:15PM -0400, Jerome Glisse wrote:
> I will wait for people to test and for result of my own test before
> reposting if need be, otherwise i will post as separate patch.
>
> > But from a _very_ quick read-through this looks fine. But it obviously
> > needs testing.
> >
kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/i915/intel_opregion.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
ind
kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
ind
As noted in patch2:
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a
mechanism to define new behavior that is known to fail on older kernels
without the support. Define a new MAP_VALIDATE f
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Wednesday, August 30, 2017 5:10 PM
> To: Eric Anholt
> Cc: Alex Deucher; alsa-de...@alsa-project.org; Liam Girdwood; Maling list -
> DRI developers; rajeev kumar; amd-gfx list; Mukunda, Vijendar; Deucher,
> Alexande
On Wed, Aug 30, 2017 at 11:49:02AM -0700, Eric Anholt wrote:
> Mark Brown writes:
> > You need to get someone from the DRM side to pay attention to the second
> > patch and you need to stop resending the first patch since as has been
> > pointed out a few times now you need to stop sending the fi
On 30 August 2017 at 11:20, Forest Crossman wrote:
> Hi, all,
>
> I recently bough a bunch of udl-compatible DisplayLink adapters and
> have been trying to use them in Linux, but have been running into some
> issues:
>
> - Output is limited to 16-bit color, but the device is capable of 24-bit
> c
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #29 from Robin ---
As I will pass on my R9 290 and switch to an RX 580, please let me know if you
need any extra information from either card before I no longer have the R9 290.
--
You are receiving this mail because:
You are the a
Hey Linus,
Two fixes in the queue for 4.13 final, hopefully that is it.
Dave.
The following changes since commit cc4a41fe5541a73019a864883297bd5043aa6d98:
Linux 4.13-rc7 (2017-08-27 17:20:40 -0700)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux tags/dr
Mark Brown writes:
> [ Unknown signature status ]
> On Wed, Aug 30, 2017 at 09:33:35AM -0400, Alex Deucher wrote:
>
>> Any comments? Can this patch set go in? This is the second time I've
>> resent it since the addressing the initial feedback. Does anyone have
>> a preference on which tree?
>
The ARM reference designs in the Versatile family: Integrator,
Versatile and RealView can make use of the new DRM driver as well.
We just need to create a bit of platform-specific code for them
that we isolate to its own file.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/Makefile
The silcon and components around the PL111 may require some
variants to perform special set-up of the display. Add two
callbacks to manage this.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_display.c | 7 +++
drivers/gpu/drm/pl111/pl111_drm.h | 3 +++
2 files changed, 10
We detect and enable the use of the PL110 variant, an earlier
incarnation of PL111. The only real difference is that the
control and interrupt enable registers have swapped place.
The Versatile AB and Versatile PB have a variant inbetween
PL110 and PL111, it is PL110 but they have already swapped t
The old codebase has a delay between enabling and powering up the
PL11x.
According to the manual for PL110, ARM DDI 0161E page 1-5 and
the PL111 manual ARM DDI 0293C page 1-6, the power sequence should
be such that once Vdd is stable (which we assume it is at boot)
LCDEN is enabled first and then
This adds all the main control registers to the debugfs
register file. This was helpful for my debugging so it will
likely help others as well.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/pl111/p
This replaces the custom connector in the PL111 with the
panel bridge helper.
This works nicely for all standard panels, but since there
are several PL11x-based systems that will need to use the dumb
VGA connector bridge we use drm_of_find_panel_or_bridge()
and make some headroom for dealing with
The header file contains prototypes for two nonexisting
functions. Get rid of them.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_drm.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index 5c685bfc8fdc.
Hi folks,
here is the first few patches to enhance the PL111 with the following
objectives:
- Consolidation - use the panel bridge, which I figured out after some
tinkering (yes I will fix TVE200 too).
- Handle the PL110 variant
- Handle the power-on delay documented in both manuals
- Add callb
Fixes the tarball generation.
fixes: 9d133dd08720d80dfc8ce098bf0972 (tests/amdgpu: add uvd encode unit tests)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=102391
Signed-off-by: Alex Deucher
---
tests/amdgpu/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/te
On Wed, Aug 30, 2017 at 6:31 PM, Noralf Trønnes wrote:
>
> Den 28.08.2017 23.56, skrev Daniel Vetter:
>>
>> On Mon, Aug 28, 2017 at 07:17:48PM +0200, Noralf Trønnes wrote:
>>>
>>> Support device unplugging to make tinydrm suitable for USB devices.
>>>
>>> Cc: David Lechner
>>> Signed-off-by: Nora
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Wednesday, August 30, 2017 11:19 AM
> To: Alex Deucher
> Cc: amd-gfx list; Maling list - DRI developers; Dave Airlie; alsa-devel@alsa-
> project.org; Mukunda, Vijendar; rajeev kumar; pe...@perex.cz; Liam
> Girdwood;
Den 28.08.2017 23.56, skrev Daniel Vetter:
On Mon, Aug 28, 2017 at 07:17:48PM +0200, Noralf Trønnes wrote:
Support device unplugging to make tinydrm suitable for USB devices.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 69 ++
From: Hans Verkuil
Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.
While I have heard of SoCs that use the GPIO pin for CEC (apparently an
early RockChip SoC used that), the main use-case of this driver is to
function as a debugging tool.
By connecting the CEC line
From: Hans Verkuil
Add an entry for the CEC GPIO driver.
Signed-off-by: Hans Verkuil
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index eb930ebecfcb..5ef0d34ef502 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3205,6 +3205,15 @@ F:
From: Hans Verkuil
This driver adds support for CEC implementations that use a pull-up
GPIO pin. While SoCs exist that do this, the primary use-case is to
turn a single-board computer into a cheap CEC debugger.
Together with 'cec-ctl --monitor-pin' you can do low-level CEC bus
monitoring and do
From: Hans Verkuil
Add support for two new low-level events: PIN_HPD_LOW and PIN_HPD_HIGH.
This is specifically meant for use with the upcoming cec-gpio driver
and makes it possible to trace when the HPD pin changes. Some HDMI
sinks do strange things with the HPD and this makes it easy to debug
From: Hans Verkuil
Document these new CEC events.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
b/Documentation/media/uapi/cec/cec-ioc-dq
From: Hans Verkuil
Document the bindings for the cec-gpio module for hardware where the
CEC pin and optionally the HPD pin are connected to GPIO pins.
Signed-off-by: Hans Verkuil
---
.../devicetree/bindings/media/cec-gpio.txt | 22 ++
1 file changed, 22 insertions(+
On Wed, Aug 30, 2017 at 09:33:35AM -0400, Alex Deucher wrote:
> Any comments? Can this patch set go in? This is the second time I've
> resent it since the addressing the initial feedback. Does anyone have
> a preference on which tree?
You need to get someone from the DRM side to pay attention
On Wed, Aug 30, 2017 at 10:30:24AM +0200, Daniel Vetter wrote:
> On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote:
> > On 08/30/2017 07:47 AM, Arvind Yadav wrote:
> > > vmw_fence_ops are not supposed to change at runtime. Functions
> > > "dma_fence_init" working with const vmw_fenc
https://bugs.freedesktop.org/show_bug.cgi?id=101528
Alexander Tsoy changed:
What|Removed |Added
See Also||https://bugzilla.kernel.org
https://bugs.freedesktop.org/show_bug.cgi?id=102013
--- Comment #21 from Michel Dänzer ---
(In reply to Ilia Mirkin from comment #20)
> does EXA support DRI3?
DRI3 is disabled by default with EXA due to bug 95475 (probably unfixable with
the current EXA design).
> If not, does disabling DRI3 wi
https://bugs.freedesktop.org/show_bug.cgi?id=102013
Michel Dänzer changed:
What|Removed |Added
Attachment #133881|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=102013
--- Comment #20 from Ilia Mirkin ---
One quick drive-by observation... does EXA support DRI3? If not, does disabling
DRI3 with glamor "fix" things?
--
You are receiving this mail because:
You are the assignee for the bug.__
On Wednesday, 30 August 2017 17:17:36 EEST Daniel Vetter wrote:
> On Wed, Aug 30, 2017 at 05:10:43PM +0300, Laurent Pinchart wrote:
> > Hi Maarten,
> >
> > Thank you for the patch.
> >
> > On Wednesday, 30 August 2017 15:17:51 EEST Maarten Lankhorst wrote:
> > > Currently we neatly track the crtc
https://bugs.freedesktop.org/show_bug.cgi?id=102013
--- Comment #19 from Amr Ibrahim ---
Created attachment 133881
--> https://bugs.freedesktop.org/attachment.cgi?id=133881&action=edit
Xorg log after Option "AccelMethod" "glamor"
7.7.0 with Option "AccelMethod" "glamor" is buggy.
--
You are
On Wed, Aug 30, 2017 at 05:10:43PM +0300, Laurent Pinchart wrote:
> Hi Maarten,
>
> Thank you for the patch.
>
> On Wednesday, 30 August 2017 15:17:51 EEST Maarten Lankhorst wrote:
> > Currently we neatly track the crtc state, but forget to look at
> > plane/connector state.
> >
> > When doing a
On Tue, Aug 29, 2017 at 02:29:08PM -0300, Fabio Estevam wrote:
> Hi Thierry,
>
> On Fri, Aug 18, 2017 at 12:08 PM, Thierry Reding
> wrote:
>
> > I've applied, though somewhat reluctantly, this to drm-misc-next without
> > Rob's Acked-by, but the device tree bindings look trivial enough.
>
> Was
Hi Maarten,
Thank you for the patch.
On Wednesday, 30 August 2017 15:17:51 EEST Maarten Lankhorst wrote:
> Currently we neatly track the crtc state, but forget to look at
> plane/connector state.
>
> When doing a nonblocking modeset, immediately followed by a setprop
> before the modeset complet
https://bugs.freedesktop.org/show_bug.cgi?id=102013
--- Comment #18 from Michel Dänzer ---
Did you test 7.7.0 with
Option "AccelMethod" "glamor"
? The default switched from EXA to glamor between 7.7.0 and 7.9.0.
--
You are receiving this mail because:
You are the assignee for the bug.___
Den 30.08.2017 09.29, skrev Daniel Vetter:
On Tue, Aug 29, 2017 at 06:17:25PM +0200, Noralf Trønnes wrote:
Den 28.08.2017 23.41, skrev Daniel Vetter:
On Mon, Aug 28, 2017 at 07:17:44PM +0200, Noralf Trønnes wrote:
Support device unplug by introducing a new initialization function:
drm_fb_help
Op 30-08-17 om 15:09 schreef Laurent Pinchart:
> Hi Maarten,
>
> Thank you for the patch.
>
> On Wednesday, 30 August 2017 15:17:50 EEST Maarten Lankhorst wrote:
>> Most code only cares about the current commit or previous commit.
>> Fortuantely we already have a place to track those. Move it to
>>
On Wed, Aug 30, 2017 at 02:53:43PM +0200, Maarten Lankhorst wrote:
> Op 30-08-17 om 14:46 schreef Daniel Vetter:
> > On Wed, Aug 30, 2017 at 02:17:52PM +0200, Maarten Lankhorst wrote:
> >> By always keeping track of the last commit in plane_state, we know
> >> whether there is an active update on t
On Monday, 2017-08-21 13:12:07 +, Eric Engestrom wrote:
> On Monday, 2017-08-21 14:42:51 +0200, Philipp Zabel wrote:
> > If drmPrimeFDToHandle fails in etna_bo_from_dmabuf, the function must
> > not return with the table_lock mutex held. There is no reason to call
> > drmPrimeFDToHandle under t
On Wed, Aug 30, 2017 at 02:54:28PM +0200, Maarten Lankhorst wrote:
> Op 30-08-17 om 14:43 schreef Daniel Vetter:
> > On Wed, Aug 30, 2017 at 02:17:48PM +0200, Maarten Lankhorst wrote:
> >> The next commit removes the wait for flip_done in in
> >> drm_atomic_helper_commit_cleanup_done, but we need i
On Fri, Aug 18, 2017 at 2:10 PM, Alex Deucher wrote:
> This patch set updates the AMD GPU and Audio CoProcessor (ACP)
> audio drivers and the designware i2s driver for Stoney (ST).
> ST is an APU similar to Carrizo (CZ) which already has ACP audio
> support. The i2s controller and ACP audio DMA e
Hi Maarten,
Thank you for the patch.
On Wednesday, 30 August 2017 15:17:50 EEST Maarten Lankhorst wrote:
> Most code only cares about the current commit or previous commit.
> Fortuantely we already have a place to track those. Move it to
> drm_crtc_state where it belongs. :)
>
> The per-crtc com
Op 30-08-17 om 14:43 schreef Daniel Vetter:
> On Wed, Aug 30, 2017 at 02:17:48PM +0200, Maarten Lankhorst wrote:
>> The next commit removes the wait for flip_done in in
>> drm_atomic_helper_commit_cleanup_done, but we need it for the tests
>> to pass. Instead of using complicated vblank tracking wh
Op 30-08-17 om 14:46 schreef Daniel Vetter:
> On Wed, Aug 30, 2017 at 02:17:52PM +0200, Maarten Lankhorst wrote:
>> By always keeping track of the last commit in plane_state, we know
>> whether there is an active update on the plane or not. With that
>> information we can reject the fast update, an
On Wed, Aug 30, 2017 at 02:17:52PM +0200, Maarten Lankhorst wrote:
> By always keeping track of the last commit in plane_state, we know
> whether there is an active update on the plane or not. With that
> information we can reject the fast update, and force the slowpath
> to be used as was original
Op 30-08-17 om 14:40 schreef Daniel Vetter:
> On Wed, Aug 30, 2017 at 02:17:51PM +0200, Maarten Lankhorst wrote:
>> Currently we neatly track the crtc state, but forget to look at
>> plane/connector state.
>>
>> When doing a nonblocking modeset, immediately followed by a setprop
>> before the modes
On Wed, Aug 30, 2017 at 02:17:48PM +0200, Maarten Lankhorst wrote:
> The next commit removes the wait for flip_done in in
> drm_atomic_helper_commit_cleanup_done, but we need it for the tests
> to pass. Instead of using complicated vblank tracking which ends
> up being ignored anyway, call the corr
https://bugs.freedesktop.org/show_bug.cgi?id=102013
--- Comment #17 from Amr Ibrahim ---
OK, I have made a mistake and tested some combinations.
radeon 7.9.0 + mesa 12.0.6 is buggy
radeon 7.9.0 + mesa 17.0.7 is buggy
radeon 7.7.0 + mesa 12.0.6 is not buggy
radeon 7.7.0 + mesa 17.0.7 is not buggy
On Wed, Aug 30, 2017 at 02:17:51PM +0200, Maarten Lankhorst wrote:
> Currently we neatly track the crtc state, but forget to look at
> plane/connector state.
>
> When doing a nonblocking modeset, immediately followed by a setprop
> before the modeset completes, the setprop will see the modesets ne
On Wed, Aug 30, 2017 at 02:17:49PM +0200, Maarten Lankhorst wrote:
> When commit synchronization through drm_crtc_commit was first
> introduced, we tried to solve the problem of the flip_done
> needing a reference count by blocking in cleanup_done.
>
> This has been changed by commit 24835e442f28
This started out as a small set of 2 patches, but feedback made it 5. :(
Maarten Lankhorst (5):
drm/i915: Always wait for flip_done
drm/atomic: Remove waits in drm_atomic_helper_commit_cleanup_done
drm/atomic: Move drm_crtc_commit to drm_crtc_state, v2.
drm/atomic: Fix freeing connector/pl
Most code only cares about the current commit or previous commit.
Fortuantely we already have a place to track those. Move it to
drm_crtc_state where it belongs. :)
The per-crtc commit_list is kept for places where we have to look
deeper than the current or previous commit for checking whether to
By always keeping track of the last commit in plane_state, we know
whether there is an active update on the plane or not. With that
information we can reject the fast update, and force the slowpath
to be used as was originally intended.
Cc: Gustavo Padovan
Signed-off-by: Maarten Lankhorst
---
d
The next commit removes the wait for flip_done in in
drm_atomic_helper_commit_cleanup_done, but we need it for the tests
to pass. Instead of using complicated vblank tracking which ends
up being ignored anyway, call the correct atomic helper. :)
RFC because I'm not completely sure what we want to
Currently we neatly track the crtc state, but forget to look at
plane/connector state.
When doing a nonblocking modeset, immediately followed by a setprop
before the modeset completes, the setprop will see the modesets new
state as the old state and free it.
This has to be solved by waiting for h
When commit synchronization through drm_crtc_commit was first
introduced, we tried to solve the problem of the flip_done
needing a reference count by blocking in cleanup_done.
This has been changed by commit 24835e442f28 ("drm: reference count
event->completion") which made the waits here no longe
On Fri, Dec 09, 2016 at 01:35:06PM +0100, Ulrich Hecht wrote:
> Hi!
>
> This is a slightly updated version of Laurent's series that adds the fix
> suggested by Magnus Damm and connects the FCP devices on M3-W to their
> IPMMU. It also drops the patches that have already been picked up in the
> med
panel-common.txt references display-timing.txt with an invalid path
('/panel' missing).
Signed-off-by: Lothar Waßmann
---
Documentation/devicetree/bindings/display/panel/panel-common.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display
On Tue, 2017-08-29 at 20:56 -0400, Jerome Glisse wrote:
> On Tue, Aug 29, 2017 at 05:11:24PM -0700, Linus Torvalds wrote:
>
> > People - *especially* the people who saw issues under KVM - can you
> > try out Jérôme's patch-series? I aded some people to the cc, the full
> > series is on lkml. Jérôm
vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Node names should not use numerical suffixes if the nodes can be
distinguished by unit-address.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree
On Wed, Aug 30, 2017 at 11:54:14AM +0100, Liviu Dudau wrote:
> On Tue, Aug 29, 2017 at 05:48:24PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Aug 29, 2017 at 02:33:52PM +0100, Liviu Dudau wrote:
> > > I've worked with Vladimir Murzin inside ARM to try to sort out problems
> > > on the board
Adjust the compatible string that was obviously copied from the
mitsubishi,aa121td01.txt file.
Signed-off-by: Lothar Waßmann
---
.../devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/b
On Tue, Aug 29, 2017 at 05:48:24PM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 29, 2017 at 02:33:52PM +0100, Liviu Dudau wrote:
> > I've worked with Vladimir Murzin inside ARM to try to sort out problems
> > on the board like the one that you have. He's got to a point where the HDLCD
> > s
On Wed, Aug 30, 2017 at 11:53:58AM +0200, Hans Verkuil wrote:
On 30/08/17 11:36, Brian Starkey wrote:
On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
On 30/08/17 09:50, Daniel Vetter wrote:
On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
The fact is, adding specia
Hi Geert,
Thank you for the patch.
On Wednesday, 30 August 2017 12:53:01 EEST Geert Uytterhoeven wrote:
> Node names should not use numerical suffixes if the nodes can be
> distinguished by unit-address.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
> ---
> Documentation/
On Tuesday, 29 August 2017 17:02:02 EEST Maarten Lankhorst wrote:
> Most code only cares about the current commit or previous commit.
> Fortunately we already have a place to track those. Move it to
> drm_crtc_state where it belongs. :)
>
> The per-crtc commit_list is kept for places where we have
On 30/08/17 11:36, Brian Starkey wrote:
> On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
>> On 30/08/17 09:50, Daniel Vetter wrote:
>>> On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
The fact is, adding special formats for each combination is
unmanageable -
On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
On 30/08/17 09:50, Daniel Vetter wrote:
On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
The fact is, adding special formats for each combination is
unmanageable - we're talking dozens in the case of our hardware.
Hm
On 08/30/2017 10:30 AM, Daniel Vetter wrote:
On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote:
On 08/30/2017 07:47 AM, Arvind Yadav wrote:
vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . So mark the n
Onnkhorst> that would be the right thing to do
chickens didn't want to audit 20+ drivers :-)
neither, could we just break them? :pTue, Aug 29, 2017 at
04:02:03PM +0200, Maarten Lankhorst wrote:
> Currently we neatly track the crtc state, but forget to look at
> plane/connector state.
>
> When d
On Wed, Aug 30, 2017 at 09:44:53AM +0200, Daniel Vetter wrote:
On Tue, Aug 29, 2017 at 05:03:19PM +0100, Brian Starkey wrote:
On Fri, Aug 25, 2017 at 03:34:33PM +0200, Daniel Vetter wrote:
> On Thu, Aug 24, 2017 at 11:04:01AM +0100, Brian Starkey wrote:
> > Hi,
> >
> > Thanks for the CC.
> >
> >
On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote:
> On 08/30/2017 07:47 AM, Arvind Yadav wrote:
> > vmw_fence_ops are not supposed to change at runtime. Functions
> > "dma_fence_init" working with const vmw_fence_ops provided
> > by . So mark the non-const structs as const.
> >
> >
On Fri, Aug 18, 2017 at 09:47:25AM +0200, Daniel Vetter wrote:
> On Thu, Aug 17, 2017 at 06:21:31PM +0200, Noralf Trønnes wrote:
> > This driver can use the drm_driver.dumb_destroy and
> > drm_driver.dumb_map_offset defaults, so no need to set them.
> >
> > Cc: Russell King
> > Signed-off-by: Nor
On 30/08/17 09:50, Daniel Vetter wrote:
> On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
>> On Mon, Aug 28, 2017 at 10:49:07PM +0200, Daniel Vetter wrote:
>>> On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne
>>> wrote:
Le jeudi 24 ao??t 2017 ?? 13:26 +0100, Brian Starkey a ?
On Tue, Aug 29, 2017 at 04:02:02PM +0200, Maarten Lankhorst wrote:
> Most code only cares about the current commit or previous commit.
> Fortunately we already have a place to track those. Move it to
> drm_crtc_state where it belongs. :)
>
> The per-crtc commit_list is kept for places where we hav
https://bugs.freedesktop.org/show_bug.cgi?id=102300
--- Comment #11 from Michel Dänzer ---
(In reply to fayn from comment #9)
> I updated bunch of packages today (linux-amd-staging,mesa etc) and now
> DVI-I-1 is not recognized but it is shown as DVI-D-1. This also brought new
> problem: monitors
On Tue, Aug 29, 2017 at 08:20:41PM -0500, Forest Crossman wrote:
> Hi, all,
>
> I recently bough a bunch of udl-compatible DisplayLink adapters and
> have been trying to use them in Linux, but have been running into some
> issues:
>
> - Output is limited to 16-bit color, but the device is capable
On 08/30/2017 07:47 AM, Arvind Yadav wrote:
vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 f
On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
> On Mon, Aug 28, 2017 at 10:49:07PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne
> > wrote:
> > > Le jeudi 24 ao??t 2017 ?? 13:26 +0100, Brian Starkey a ??crit :
> > > > > What I mean was: an appl
On Tue, Aug 29, 2017 at 05:03:19PM +0100, Brian Starkey wrote:
> On Fri, Aug 25, 2017 at 03:34:33PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 24, 2017 at 11:04:01AM +0100, Brian Starkey wrote:
> > > Hi,
> > >
> > > Thanks for the CC.
> > >
> > > On Fri, Aug 18, 2017 at 06:13:14PM +0200, Noralf
On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes wrote:
> >> Hi,
> >>
> >> Currently I'm using the cma library with tinydrm because it was so
> >> simple to use even though I have to work around the fact th
On Wed, Aug 30, 2017 at 01:57:35PM +0800, Xinliang Liu wrote:
> On 29 August 2017 at 21:57, Daniel Vetter wrote:
> > On Tue, Aug 29, 2017 at 11:54 AM, Xinliang Liu
> > wrote:
> >> Hi Dave,
> >>
> >> On 29 August 2017 at 16:32, Daniel Vetter wrote:
> >>> On Tue, Aug 29, 2017 at 10:46:33AM +0800,
On Tue, Aug 29, 2017 at 07:23:14PM +0200, Noralf Trønnes wrote:
>
> Den 28.08.2017 23.46, skrev Daniel Vetter:
> > On Mon, Aug 28, 2017 at 07:17:45PM +0200, Noralf Trønnes wrote:
> > > Add drm_fbdev_cma_dev_unplug() and use the drm_fb_helper device unplug
> > > support. Pin driver module on fb_ope
https://bugs.freedesktop.org/show_bug.cgi?id=101691
Michel Dänzer changed:
What|Removed |Added
i915 features||GEM/Other
QA Contact|
On Tue, Aug 29, 2017 at 06:17:25PM +0200, Noralf Trønnes wrote:
>
> Den 28.08.2017 23.41, skrev Daniel Vetter:
> > On Mon, Aug 28, 2017 at 07:17:44PM +0200, Noralf Trønnes wrote:
> > > Support device unplug by introducing a new initialization function:
> > > drm_fb_helper_simple_init() which toget
On Mon, Aug 28, 2017 at 10:40:34AM +0200, Daniel Vetter wrote:
> On Fri, Aug 25, 2017 at 01:16:12PM -0700, Rodrigo Vivi wrote:
> > This Fixes build on branches where we already have format-modifier.
> >
> > Reference:
> > https://lists.freedesktop.org/archives/dri-devel/2017-August/151044.html
>
https://bugs.freedesktop.org/show_bug.cgi?id=101691
--- Comment #40 from Ethan Hsieh ---
Cannot reproduce corruption issue with SNA_POWERSAVE enabled.
(Have to re-plug AC adapter to make the workaround work)
xserver-xorg-video-intel-2.99.917+git20160325/src/sna/sna_acpi.c
@@ -123,10 +123,14 @@ v
97 matches
Mail list logo
