Hey,
Daniel pointed out I'd missed some i915 fixes, and I also found a single
etnaviv fix I missed.
So here they are,
Thanks,
Dave.
The following changes since commit 91d62d9f30206be6f7749a0e6f7fa58c6d70c702:
Merge branch 'drm-fixes-4.8' of git://people.freedesktop.org/~agd5f/linux
into d
Hi Jonathan,
Today's linux-next merge of the jc_docs tree got a conflict in:
Documentation/gpu/index.rst
between commit:
b754b35b089d ("vgaarbiter: rst-ifiy and polish kerneldoc")
from the drm-misc tree and commit:
505f711174b0 ("doc-rst: add index to sub-folders")
from the jc_docs tre
.
|.org|org
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160819/2ac6e6b4/attachment.html>
Since dev_printk likes to print "(NULL device *):" when passed in a NULL
pointer, we have to manually call printk() ourselves.
Fixes: c4e68a583202 ("drm: Introduce DRM_DEV_* log messages")
Signed-off-by: Chris Wilson
Cc: Eric Engestrom
Cc: Sean Paul
---
drivers/gpu/drm/drm_drv.c | 7 +--
1
On Thu, Aug 18, 2016 at 09:42:33PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 18 Aug 2016 21:38:37 +0200
>
> A few update suggestions were taken into account
> from static source code analysis.
savage is one of the dri1 legacy drivers, imo not really worth it to spend
ti
On Thu, Aug 18, 2016 at 09:48:04PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 18 Aug 2016 21:28:58 +0200
>
> The kfree() function was called in a few cases by the
> savage_bci_cmdbuf() function during error handling
> even if a passed variable contained a null pointer.
>
On Thu, Aug 18, 2016 at 10:42:06PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 18 Aug 2016 22:35:14 +0200
>
> Reuse existing functionality from memdup_user() instead of keeping
> duplicate source code.
>
> This issue was detected by using the Coccinelle software.
>
> Sig
The plane .prepare_fb() and .cleanup_fb() helpers are optional, there's
no need to implement empty stubs, and no need to explicitly set the
function pointers to NULL either.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 2 --
drivers/gpu/drm/fsl-dcu/fsl_d
Hello,
This patch series fixes the rcar-du-drm driver to support VSP plane sources
with an IOMMU. It is available for convenience at
git://linuxtv.org/pinchartl/media.git iommu/devel/du
On R-Car Gen3 the DU has no direct memory access but sources planes through
VSP instances. When an IOM
Direct callers of the FCP API hold a reference to the FCP module due to
module linkage, there's no need to take another one manually. Take a
reference to the device instead to ensure that it won't disappear being
the caller's back.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/rcar-
The functions might need to modify the state to store memory-related
data.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 ++--
drivers/gpu/drm/i915/intel_display.c| 4 ++--
drivers/gpu/drm/i915/intel_drv.h| 4 ++--
drivers/gpu
The new rcar_fcp_get_device() function retrieves the struct device
related to the FCP device. This is useful to handle DMA mapping through
the right device.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/rcar-fcp.c | 6 ++
include/media/rcar-fcp.h | 5 +
2 files chan
The display buffers must be mapped for DMA through the device that
performs memory access. Expose an API to map and unmap memory through
the VSP device to be used by the DU.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 24
include/media/vs
For planes handled by a VSP instance, map the framebuffer memory through
the VSP to ensure proper IOMMU handling.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 74 ---
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +
2 files changed, 70
On Fri, Aug 19, 2016 at 10:39 AM, Laurent Pinchart
wrote:
> Direct callers of the FCP API hold a reference to the FCP module due to
> module linkage, there's no need to take another one manually. Take a
> reference to the device instead to ensure that it won't disappear being
... behind
> the ca
On Fri, Aug 19, 2016 at 11:39:29AM +0300, Laurent Pinchart wrote:
> The plane .prepare_fb() and .cleanup_fb() helpers are optional, there's
> no need to implement empty stubs, and no need to explicitly set the
> function pointers to NULL either.
>
> Signed-off-by: Laurent Pinchart
Rebased onto C
Hi Laurent,
Daniel talked about a planned reorg from you around DRM formats (or
something like this) and I have proposed to fix some missing parts with
the XRGB444 formats.
Can you let us know if you can consider this fix as part of your reorg?
If you can't what would be the best option to get
ves/dri-devel/attachments/20160819/2a45e431/attachment.html>
This patch adds active plane reconfiguration support for imx-drm.
This may fixes some mode setting failure issues which were introduced
by imx-drm atomic conversion patch set. The main idea is to disable the
plane in question in CRTC's disable operation and then the drm atomic
core will enable it
Some display controllers need plane(s) to be disabled together with
the relevant CRTC, e.g., the IPUv3 display controller for imx-drm.
This patch adds atomic_disable CRTC helper callback so that
old_crtc_state(as a parameter of the callback) could be used
to get all appropriate active plane(s) of t
Now that the drm atomic core supports the callback ->atomic_disable,
we may replace the legacy one ->disable with it.
Cc: Philipp Zabel
Cc: David Airlie
Cc: Russell King
Cc: Daniel Vetter
Cc: Peter Senna Tschudin
Cc: Lucas Stach
Signed-off-by: Liu Ying
---
v3:
* Newly introduced in v3.
dr
We don't support configuring active plane on-the-fly for imx-drm.
The relevant CRTC should be disabled before the plane configuration.
Of course, the plane itself should be disabled as well.
This patch adds active plane reconfiguration support by forcing CRTC
mode change in plane's ->atomic_check
On Thu, Aug 18, 2016 at 11:42:37PM +0100, Robert Bragg wrote:
> Each metric set is given a sysfs entry like:
>
> /sys/class/drm/card0/metrics//id
>
> This allows userspace to enumerate the specific sets that are available
> for the current system. The 'id' file contains an unsigned integer that
>
"%s" DRM_PRINTK_FMT, level, function_name, prefix,
&vaf);
>
> va_end(args);
> }
> --
> 2.9.3
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160819/0619e284/attachment.html>
Hi Lin,
Am Mittwoch, 17. August 2016, 06:36:22 CEST schrieb Lin Huang:
> On new rockchip platform(rk3399 etc), there have dcf controller to
> do ddr frequency scaling, and this controller will implement in
> arm-trust-firmware. We add a special clock-type to handle that.
>
> Signed-off-by: Lin Hu
On 08/18/16 22:17, Rob Herring wrote:
> On Tue, Aug 16, 2016 at 12:24:28PM +0300, Jyri Sarha wrote:
>> Add "blue-and-red-wiring"-device tree property and update devicetree
>> binding document. The red and blue components are reversed between 24
>> and 16 bit modes on am335x LCDC output pins. To get
Am Mittwoch, 17. August 2016, 06:36:24 CEST schrieb Lin Huang:
> add ddrc clock setting, so we can do ddr frequency
> scaling on rk3399 platform in future.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v6:
> - None
>
> Changes in v5:
> - fit for the ddr type
>
> Changes in v4:
> - None
>
> C
Hi Dave, Daniel,
We had this i915 series with a single DRM core patch (reviewed) ready
for a while - just waiting for an ack to merge it via i915 trees.
Can we proceed with merging it?
Regards,
Tvrtko
On 18/08/16 18:17, Dave Gordon wrote:
> We had only DRM_INFO() and DRM_ERROR(), whereas the
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160819/983228ed/attachment.html>
On Thu, Aug 18, 2016 at 02:12:43PM -0700, Sean Paul wrote:
> From: Mark Yao
>
> This patch documents the compatible strings for the big and little vop
> in rockchip's drm driver.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
>
> Reviewed-by: To
From: Marek Olšák
This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
See the comment in the code. Basically, don't do cleanups in this header.
Signed-off-by: Marek Olšák
---
include/uapi/drm/amdgpu_drm.h | 295 +-
1 file changed, 150 inse
From: Marek Olšák
This reverts commit 31b4dfe24e903e995a32f17e9a9cafbbecabc77a.
See the comment in the code. Basically, don't do cleanups in this header.
Signed-off-by: Marek Olšák
---
include/uapi/drm/radeon_drm.h | 133 ++
1 file changed, 69 inser
On Thu, Aug 18, 2016 at 02:15:18PM -0700, Sean Paul wrote:
> From: Mark Yao
>
> Reorder the compatible vop devices to be sorted by chip number
> in ascending order.
>
> Reviewed-by: Tomasz Figa
> Signed-off-by: Mark Yao
> [seanpaul added commit description per tfiga's review]
> Signed-off-by:
Each metric set is given a sysfs entry like:
/sys/class/drm/card0/metrics//id
This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN.
https://bugzilla.kernel.org/show_bug.cgi?id=117581
--- Comment #3 from Elmar Stellnberger ---
With 4.7.0-ARCH-13902-gd491e80 and no_console_suspend the LVDS just did not
come up again under init=/bin/bash (i.e. it stayed black while it was still
possible to enter commands blindly) - basically a
Am 19.08.2016 um 15:50 schrieb Marek Olšák:
> From: Marek Olšák
>
> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>
> See the comment in the code. Basically, don't do cleanups in this header.
>
> Signed-off-by: Marek Olšák
I completely agree with you that this was a bad mov
https://bugzilla.kernel.org/show_bug.cgi?id=117581
--- Comment #4 from Elmar Stellnberger ---
Created attachment 229421
--> https://bugzilla.kernel.org/attachment.cgi?id=229421&action=edit
nvapeek 0x61 0x2 - 4.7.0-ARCH-13902-gd491e80 without no_console_suspend
and without nouveau module
https://bugzilla.kernel.org/show_bug.cgi?id=117581
--- Comment #5 from Elmar Stellnberger ---
Created attachment 229431
--> https://bugzilla.kernel.org/attachment.cgi?id=229431&action=edit
nvapeek 0x61 0x2 - 4.7.0-ARCH-13902-gd491e80 without no_console_suspend
and without nouveau module
On Fri, Aug 19, 2016 at 4:52 PM, Mikko Rapeli wrote:
> On Fri, Aug 19, 2016 at 04:26:40PM +0200, Christian König wrote:
>> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>> >From: Marek Olšák
>> >
>> >This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>> >
>> >See the comment in the
On Fri, Aug 19, 2016 at 04:26:40PM +0200, Christian König wrote:
> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
> >From: Marek Olšák
> >
> >This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
> >
> >See the comment in the code. Basically, don't do cleanups in this header.
> >
> >Sign
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160819/be5f0782/attachment-0001.html>
On Fri, Aug 19, 2016 at 5:22 PM, Marek Olšák wrote:
> On Fri, Aug 19, 2016 at 4:52 PM, Mikko Rapeli wrote:
>> On Fri, Aug 19, 2016 at 04:26:40PM +0200, Christian König wrote:
>>> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>> >From: Marek Olšák
>>> >
>>> >This reverts commit 2ce9dde0d47f
On Fri, Aug 19, 2016 at 7:11 PM, Daniel Vetter wrote:
> On Fri, Aug 19, 2016 at 5:22 PM, Marek Olšák wrote:
>> On Fri, Aug 19, 2016 at 4:52 PM, Mikko Rapeli wrote:
>>> On Fri, Aug 19, 2016 at 04:26:40PM +0200, Christian König wrote:
Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>Fro
On Fri, Aug 19, 2016 at 7:12 PM, Daniel Vetter wrote:
> On Fri, Aug 19, 2016 at 7:11 PM, Daniel Vetter wrote:
>> On Fri, Aug 19, 2016 at 5:22 PM, Marek Olšák wrote:
>>> On Fri, Aug 19, 2016 at 4:52 PM, Mikko Rapeli
>>> wrote:
On Fri, Aug 19, 2016 at 04:26:40PM +0200, Christian König wr
On Fri, 19 Aug 2016 11:52:15 +1000
Stephen Rothwell wrote:
> Today's linux-next merge of the jc_docs tree got a conflict in:
>
> Documentation/gpu/index.rst
>
> between commit:
>
> b754b35b089d ("vgaarbiter: rst-ifiy and polish kerneldoc")
>
> from the drm-misc tree and commit:
>
> 505
On Thu, May 12, 2016 at 6:56 PM, Martin Peres wrote:
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2016
> will be held in Helsinki from September 21 to September 23. The venue is
> located at Haaga-Helia university[0], next to the Pasila station.
>
> The official
On Thu, May 12, 2016 at 6:56 PM, Martin Peres wrote:
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2016
> will be held in Helsinki from September 21 to September 23. The venue is
> located at Haaga-Helia university[0], next to the Pasila station.
>
> The official
Signed-off-by: Rob Clark
---
drivers/dma-buf/reservation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index b528edb..1461b51 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -20
Ok, quick update on state of explicit fence fd's /
EGL_ANDROID_native_fence_sync:
For folks working on other drivers wishing to add support, we don't
have a "real" userspace yet. But Gustavo has added atomic support to
kmscube (as well as all of his work for in/out fences in atomic ioctl,
plus de
https://bugzilla.kernel.org/show_bug.cgi?id=153451
Bug ID: 153451
Summary: [bisected] display corruption issue on Mobility Radeon
HD 3650 (RV635/M86) since kernel 4.7
Product: Drivers
Version: 2.5
Kernel Version: 4.7 and above
https://bugzilla.kernel.org/show_bug.cgi?id=153451
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
https://bugzilla.kernel.org/show_bug.cgi?id=61941
Denis Ollier changed:
What|Removed |Added
CC||larchunix+kernel at gmail.com
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=153451
Denis Ollier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Fri, Aug 19, 2016 at 5:57 PM, Rob Clark wrote:
> Ok, quick update on state of explicit fence fd's /
> EGL_ANDROID_native_fence_sync:
>
> For folks working on other drivers wishing to add support, we don't
> have a "real" userspace yet. But Gustavo has added atomic support to
> kmscube (as well
On 19 August 2016 at 15:26, Christian König wrote:
> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>
>> From: Marek Olšák
>>
>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>>
>> See the comment in the code. Basically, don't do cleanups in this header.
>>
>> Signed-off-by: Ma
On Fri, Aug 19, 2016 at 6:54 PM, Emil Velikov
wrote:
> On 19 August 2016 at 15:26, Christian König
> wrote:
>> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>>
>>> From: Marek Olšák
>>>
>>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>>>
>>> See the comment in the code. B
can compile these include files without any major hassles.
-- next part ------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160819/c9b9e7b2/attachment.html>
On Fri, Aug 19, 2016 at 9:23 PM, Ken Phillis Jr wrote:
> On Fri, Aug 19, 2016 at 6:32 PM, Rob Clark wrote:
>>
>> tbh, I'm all in favor of making it easier to sync kernel headers to
>> libdrm, etc.
>>
>> But kernel *does* have stdint types. Just (for some reason that
>> completely baffles me) not
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160819/171b4ae8/attachment.sig>
ists.freedesktop.org/archives/dri-devel/attachments/20160819/e10719b2/attachment.html>
This came from the initial bringup code, which always idled the GPU
and always reset the overflow. That massively increases the size of
the working set when you're doing lots of small draws, though, as is
common on X desktops or piglit.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_gem
Everyone knows them, except all the new folks joining from the ARM
side haven't lived through all the pain of the past years and are
entirely surprised when I raise this. Definitely time to document
this.
Last time this was a big discussion was about 6 years ago, when qcom
tried to land a kernel d
quot;
> +mix every year it would be entirely unmanagable.
With the little nitpicks (probably) fixed,
Reviewed-by: Eric Anholt
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160819/3d2d2a1a/attachment-0001.sig>
On Fri, Aug 19, 2016 at 4:50 PM, Daniel Vetter
wrote:
> Everyone knows them, except all the new folks joining from the ARM
> side haven't lived through all the pain of the past years and are
> entirely surprised when I raise this. Definitely time to document
> this.
>
> Last time this was a big d
KMS has a lot of code sequences where the driver has to select a certain HW
configuration among the available ones. For e.g., link rate, clock,
voltage swing, training pattern etc. Printing such low-level messages is
valuable for debugging display problems. But, will bloat dmesg if printed
with DRM
65 matches
Mail list logo
