[PATCH v6 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem

Hi, On 3 March 2016 at 02:29, Rob Herring wrote: > On Fri, Feb 26, 2016 at 04:40:18PM +0800, Xinliang Liu wrote: >> Add ADE display controller binding doc. >> Add DesignWare DSI Host Controller v1.20a binding doc. >> >> v6: >> - Cleanup values part of reg and clocks properties. >> - Change

[pull] radeon and amdgpu drm-next-4.6

Hi Dave, Some more radeon and amdgpu stuff for drm-next. Mostly just bug fixes for new features and cleanups. The following changes since commit d2eaa59000c7717e68a75cf2c106f056d2bc30b4: Merge branch 'drm-rockchip-next-2016-02-18' of https://github.com/markyzq/kernel-drm-rockchip into

[PATCH v6 05/11] drm/hisilicon: Add vblank driver for ADE

On 1 March 2016 at 20:40, Archit Taneja wrote: > > > On 3/1/2016 3:44 PM, Xinliang Liu wrote: >> >> Hi, >> >> On 1 March 2016 at 02:48, Archit Taneja wrote: >>> >>> >>> >>> On 2/26/2016 2:10 PM, Xinliang Liu wrote: Add vblank irq handle. v6: None. v5: None. v4:

[PATCH v3 0/7] drm/atomic: Fix encoder stealing, v3.

This is a resend of "drm/atomic: Fix encoder stealing" with updated patches. Maarten Lankhorst (7): drm/atomic: Clean up update_output_state. drm/atomic: Pass connector and state to update_connector_routing. drm/atomic: Always call steal_encoder, v2. drm/atomic: Handle encoder stealing

[PATCH v3 2/7] drm/atomic: Pass connector and state to update_connector_routing.

Minor cleanup, connector and connector_state are always non-NULL here. Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic_helper.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c

[PATCH v3 3/7] drm/atomic: Always call steal_encoder, v2.

There's no need to have a separate function to get the crtc which is stolen, this can already be found when actually stealing the encoder. drm_for_each_connector already checks for connection_mutex, so use that macro now. Changes since v1: - Do not check for NULL crtc in connector_state, this

[PATCH v3 1/7] drm/atomic: Clean up update_output_state.

With the addition of crtc_state->connector_mask other connectors from different crtc's aren't needed any more, so only call add_affected_connectors on the target crtc. This allows a cleanup to first remove all current connectors, then add all set->connectors to the target crtc. Signed-off-by:

[PATCH v3 7/7] drm/atomic: Clean up update_connector_routing.

connector_state->crtc can no longer be unset by accident, so that check can be removed. The other code open-codes drm_atomic_get_existing_crtc_state, so use that. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 17 - 1 file changed, 4 insertions(+), 13

[PATCH v3 4/7] drm/atomic: Handle encoder stealing from set_config better.

Instead of failing with -EINVAL when conflicting encoders are found, the legacy set_config will disable other connectors when encoders conflict. With the previous commit this becomes a lot easier to implement. set_config only adds connectors to the state that are modified, and because of the

[PATCH v3 6/7] drm/atomic: Clean up steal_encoder, v2.

Now that only encoders can be stolen that are part of the state steal_encoder no longer needs to inspect all connectors, just those that are part of the atomic state. Changes since v1: - Change return value to void, can no longer fail. Signed-off-by: Maarten Lankhorst ---

[PATCH v3 5/7] drm/atomic: Handle encoder assignment conflicts in a separate check, v3.

The current check doesn't handle the case where we don't steal an encoder, but keep it on the current connector. If we repurpose disable_conflicting_encoders to do the checking, we just have to reject the ones that conflict. Changes since v1: - Return early with empty encoder_mask,

[PATCH 0/8] drm/bochs: convert bochs to atomic mode-setting

Hi, > > Did testing a while back & reported back to John (not sure this was in > > public on the list as we had some ping-ping emails beforehand due to > > some problems of applying the patches). No new version of the series > > since. > > > The only comment that I can see is this one [1]

[Intel-gfx] [PATCH v3 6/7] drm/atomic: Clean up steal_encoder, v2.

Hi Maarten, [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20160303] [cannot apply to v4.5-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Maarten-Lankhorst

[git pull] drm/sti: drm-next 2016-02-26

Hello Dave, Here are sti patches for drm-next. It brings: - The support of the atomic_check for the planes and minor fixes for planes - The support of the vendor specific infoframe for HDMI and the support of 2 HDMI properties related to the connector - The support of the DVO solving

[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field

Hi Ville, Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes that the userland controls the field presentation on the display output. This assumes that the userland is aware of the field actually on display and I think that this information is not provided by the DRM

[PATCH] drm/vmwgfx: use *_32_bits() macros

Use the upper_32_bits() macro instead of the four line equivalent that triggers a GCC warning on 32 bits x86: drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_header_submit': drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:297:25: warning: right shift count >= width of type

[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field

On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: > Hi Ville, > > Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes > that the userland controls the field presentation on the display output. > This assumes that the userland is aware of the field actually on

[PULL] drm-intel-fixes

Hi Dave, a couple of Intel fixes for v4.5. BR, Jani. The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af: Linux 4.5-rc6 (2016-02-28 08:41:20 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-03-03 for

[PATCH] dma-buf/fence: fix fence_is_later v2

Hi Alex, On 29 February 2016 at 21:23, Alex Deucher wrote: > From: Christian König > > A fence is never later than itself. This caused a bunch of overhead for > AMDGPU. > Thanks; added to for-next. > v2: simplify check as suggested by Michel. > Best regards, ~Sumit.

[PATCH] drm: Taint mm->mmap_sem with dev->struct_mutex for lockdep

The DRM core depends on mm->mmap_sem being the outer lock in order to setup/teardown and utilize fault handlers. If we taint the mm->mmap_sem as soon as we open the device for a process, we can define this proper ordering for lockdep and so it will report any violations early. Signed-off-by:

[Bug 94388] r600_blit.c:281: r600_decompress_depth_textures: Assertion `tex->is_depth && !tex->is_flushing_texture' failed.

was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/6f374dcd/attachment.html>

[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field

On 03/03/2016 12:28 PM, Ville Syrjälä wrote: > On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: >> Hi Ville, >> >> Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes >> that the userland controls the field presentation on the display output. >> This assumes

[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field

On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote: > > > On 03/03/2016 12:28 PM, Ville Syrjälä wrote: > > On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: > >> Hi Ville, > >> > >> Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes > >> that the

[PATCH 0/3] drm/omap: patches for v4.6 part 3

Hi, A few more patches for omapdrm for 4.6. These are based on the "drm/omap: patches for v4.6 part 2" series sent earlier. Tomi Laurent Pinchart (1): drm/omap: gem: Fix omap_gem_new() error path Tomi Valkeinen (2): drm/omap: remove -Werror from Makefile drm/omap: no need to select

[PATCH 1/3] drm/omap: remove -Werror from Makefile

Having -Werror in the omapdrm Makefile makes development and debugging a PITA. Let's remove it. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Makefile

[PATCH 2/3] drm/omap: gem: Fix omap_gem_new() error path

From: Laurent Pinchart When an error occurs in omap_gem_new() the function calls omap_gem_free_object() to clean up. However, that function expects to be called on a fully initialized GEM object and thus crashes. Replace it by manual cleanup. Signed-off-by:

[PATCH 3/3] drm/omap: no need to select OMAP2_DSS

omapdss driver now depends on omapdrm, so we no longer should select OMAP2_DSS from omapdrm's Kconfig. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig index

[Bug 94387] Approx 35W more power usage in multi-screen

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/20160303/a17cb4ad/attachment.html>

[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

From: Gustavo Padovan Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and optimize buffer Now num_fences can be filled by the caller to inform how many fences it wants to retrieve from the kernel. If the num_fences passed is greater than zero

[PATCH] staging/android: add flags member to sync ioctl structs

From: Gustavo Padovan Play safe and add flags member to all structs. So we don't need to break API or create new IOCTL in the future if new features that requires flags arises. v2: check if flags are valid (zero, in this case) v3: return -EINVAL if flags are

[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field

On 03/03/2016 02:33 PM, Ville Syrjälä wrote: > On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote: >> >> On 03/03/2016 12:28 PM, Ville Syrjälä wrote: >>> On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: Hi Ville, Using

[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

Op 03-03-16 om 15:34 schreef Gustavo Padovan: > From: Gustavo Padovan > > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and > optimize buffer > > Now num_fences can be filled by the caller to inform how many fences it > wants to retrieve from the kernel. If the num_fences passed

[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

On Mon, 29 Feb 2016 15:39:53 +0100, Jani Nikula wrote: > > On Mon, 29 Feb 2016, Martin Kepplinger wrote: > > Am 2016-02-26 um 20:59 schrieb Takashi Iwai: > >> Sorry, Cc to Jani was missing mistakenly. > >> > >> Please check this. It's a regression in 4.5-rc. > >> > >> > >> thanks, > >> > >>

[Bug 107381] radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics

https://bugzilla.kernel.org/show_bug.cgi?id=107381 Robin KERDILES changed: What|Removed |Added CC||xxdrshadowxx at gmail.com --- Comment

[Bug 107381] radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics

https://bugzilla.kernel.org/show_bug.cgi?id=107381 --- Comment #5 from Robin KERDILES --- Created attachment 206701 --> https://bugzilla.kernel.org/attachment.cgi?id=206701=edit dmesg under kernel 4.4 - archlinux x64 -- You are receiving this mail because: You are watching the assignee of

[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field

On Thu, Mar 03, 2016 at 03:40:56PM +0100, Fabien DESSENNE wrote: > > On 03/03/2016 02:33 PM, Ville Syrjälä wrote: > > On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote: > >> > >> On 03/03/2016 12:28 PM, Ville Syrjälä wrote: > >>> On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien

[PATCH] staging/android: add flags member to sync ioctl structs

On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Play safe and add flags member to all structs. So we don't need to > break API or create new IOCTL in the future if new features that requires > flags arises. > > v2: check if flags are valid (zero, in

[PATCH] MAINTAINERS: update radeon entry to include amdgpu as well

Both are maintained by same team. Signed-off-by: Alex Deucher --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index c647c40..20166fb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3712,7 +3712,7 @@ F:drivers/gpu/vga/ F:

[PATCH] MAINTAINERS: update radeon entry to include amdgpu as well

e much more useful with this. Acked-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/adb76513/attachment.sig>

[PATCH v1 00/12] PCI: Rework shadow ROM handling

The purpose of this series is to: - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment" messages reported by Linus [1], Andy [2], and others. - Move arch-specific shadow ROM location knowledge, e.g., 0xC-0xD, from PCI core to arch code. - Fix the ia64 and MIPS

[PATCH v1 01/12] PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED

A shadow copy of an option ROM is placed by the BIOS as a fixed address. Set IORESOURCE_PCI_FIXED to indicate that we can't move the shadow copy. This prevents warnings like the following when we assign resources: BAR 6: [??? 0x flags 0x2] has bogus alignment This warning is emitted by

[PATCH v1 02/12] PCI: Don't assign or reassign immutable resources

IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set, don't bother trying to assign or reassign the resource. Signed-off-by: Bjorn Helgaas --- drivers/pci/setup-res.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c

[PATCH v1 03/12] PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy

If we're using a RAM shadow copy instead of the ROM BAR, we don't need to touch the ROM BAR enable bit. Signed-off-by: Bjorn Helgaas --- drivers/pci/rom.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index

[PATCH v1 04/12] PCI: Set ROM shadow location in arch code, not in PCI core

IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in RAM. The existence of such a copy and its location are arch-specific. Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the 0xC-0xD location was hard-coded into the PCI core. If we're using a shadow

[PATCH v1 05/12] PCI: Clean up pci_map_rom() whitespace

Remove unnecessary indentation in pci_map_rom(). This is logically part of the previous patch; I split it out to make the critical changes in that patch more obvious. No functional change intended. Signed-off-by: Bjorn Helgaas --- drivers/pci/rom.c | 37 ++---

[PATCH v1 06/12] ia64/PCI: Use temporary struct resource * to avoid repetition

Use a temporary struct resource pointer to avoid needless repetition of "dev->resource[idx]". No functional change intended. Signed-off-by: Bjorn Helgaas --- arch/ia64/sn/kernel/io_acpi_init.c | 10 + arch/ia64/sn/kernel/io_init.c | 39 2

[PATCH v1 07/12] ia64/PCI: Use ioremap() instead of open-coded equivalent

Depositing __IA64_UNCACHED_OFFSET in the upper address bits is essentially equivalent to ioremap(): it converts a CPU physical address to a virtual address using the ia64 uncacheable identity map. Call ioremap() instead of doing the phys-to-virt conversion manually with __IA64_UNCACHED_OFFSET.

[PATCH v1 08/12] ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM resource

A struct resource contains CPU physical addresses, not virtual addresses. But sn_acpi_slot_fixup() and sn_io_slot_fixup() stored the virtual address of a shadow ROM copy in the resource. To compensate, pci_map_rom() had a special case that returned the resource address directly rather than

[PATCH v1 09/12] MIPS: Loongson 3: Use temporary struct resource * to avoid repetition

Use a temporary struct resource pointer to avoid needless repetition of "pdev->resource[PCI_ROM_RESOURCE]". No functional change intended. Signed-off-by: Bjorn Helgaas --- arch/mips/pci/fixup-loongson3.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH v1 10/12] MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow ROM resource

Loongson 3 used the IORESOURCE_ROM_COPY flag for its ROM resource. There are two problems with this: - When IORESOURCE_ROM_COPY is set, pci_map_rom() assumes the resource contains virtual addresses, so it doesn't ioremap the resource. This implies loongson_sysconf.vgabios_addr is a

[PATCH v1 11/12] PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY

The IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY bits are unused. Remove them and code that depends on them. Signed-off-by: Bjorn Helgaas --- drivers/pci/remove.c |1 - drivers/pci/rom.c | 31 +-- include/linux/ioport.h |2 -- 3 files changed, 1

[PATCH v1 12/12] PCI: Simplify sysfs ROM cleanup

The value of pdev->rom_attr is the definitive indicator of the fact that we're created a sysfs attribute. Check that rather than rom_size, which is only used incidentally when deciding whether to create a sysfs attribute. Signed-off-by: Bjorn Helgaas --- drivers/pci/pci-sysfs.c | 13

[PATCH v1 00/12] PCI: Rework shadow ROM handling

On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote: > The purpose of this series is to: > [ .. ] The patches look ok to me and seem to make sense. Of course, let's see what they break. Hopefully nothing, but any time the PCI resource code changes I get a bit worried. PTSD, I guess.

Two kangaroo

First Kangaroo: What does a frog say when it washes car windows? Second Kangaroo: Rub it, rub it, rub it. https://lists.freedesktop.org/archives/dri-devel/2016-January/097945.html https://patchwork.freedesktop.org/patch/65722 https://bugzilla.redhat.com/show_bug.cgi?id=1295646 It's been more

[PATCH] MAINTAINERS: update radeon entry to include amdgpu as well

> dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/3b333417/attachment.html>

[PATCH 1/3] drm/omap: remove -Werror from Makefile

Hi Tomi, Thank you for the patch. On Thursday 03 March 2016 16:01:16 Tomi Valkeinen wrote: > Having -Werror in the omapdrm Makefile makes development and debugging a > PITA. Let's remove it. Well, shouldn't we target having no warning ? :-) > Signed-off-by: Tomi Valkeinen > --- >

[PATCH 1/3] drm/omap: remove -Werror from Makefile

nt was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/56c7e3c6/attachment.sig>

[PATCH v7 1/5] staging/android: add num_fences field to struct sync_file_info

From: Gustavo Padovan Inform userspace how many fences are in the sync_fence_info field. Signed-off-by: Gustavo Padovan Reviewed-by: Maarten Lankhorst --- drivers/staging/android/sync.c | 2 ++ drivers/staging/android/uapi/sync.h | 2 ++ 2 files changed,

[PATCH v7 2/5] staging/android: rename SYNC_IOC_FENCE_INFO

From: Gustavo Padovan We don't use the 'fence' name to refer to sync_file anymore. So rename it to SYNC_IOC_FILE_INFO. Signed-off-by: Gustavo Padovan Reviewed-by: Maarten Lankhorst --- drivers/staging/android/sync.c | 2 +-

[PATCH v7 3/5] staging/android: remove redundant comments on sync_merge_data

From: Gustavo Padovan struct sync_merge_data already have documentation on top of the struct definition. No need to duplicate it. Signed-off-by: Gustavo Padovan Reviewed-by: Maarten Lankhorst --- drivers/staging/android/uapi/sync.h | 6 +++--- 1 file changed,

[PATCH v7 4/5] staging/android: refactor SYNC_IOC_FILE_INFO

From: Gustavo Padovan Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and optimize buffer Now num_fences can be filled by the caller to inform how many fences it wants to retrieve from the kernel. If the num_fences passed is greater than zero

[PATCH v7 5/5] staging/android: add flags member to sync ioctl structs

From: Gustavo Padovan Play safe and add flags member to all structs. So we don't need to break API or create new IOCTL in the future if new features that requires flags arises. Signed-off-by: Gustavo Padovan Reviewed-by: Maarten Lankhorst --- v2: check if

[PATCH] staging/android: add flags member to sync ioctl structs

2016-03-03 Gustavo Padovan : > Hi Greg, > > 2016-03-03 Greg Kroah-Hartman : > > > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > Play safe and add flags member to all structs. So we don't need to > > > break API or create new IOCTL in

[PATCH] staging/android: add flags member to sync ioctl structs

On Thu, Mar 03, 2016 at 08:17:14AM -0800, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Play safe and add flags member to all structs. So we don't need to > > break API or create new IOCTL in the future if new

[PATCH] drm/amdgpu: cleanup or bug?

Hi! First time sending a patch to the list. This patch deletes a set-but-not-read member from the amdgpu_device struct but I'm not sure the correct thing is to delete it. Maybe it should be checked some where? BR Nils Nils Wallménius (1): drm/amdgpu: delete set-but-not-read member has_uvd

[PATCH] drm/amdgpu: delete set-but-not-read member has_uvd from amdgpu_device

--- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/cik.c| 2 -- drivers/gpu/drm/amd/amdgpu/vi.c | 4 3 files changed, 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 0c42a85..cfd35b0 100644 ---

[PATCH] staging/android: add flags member to sync ioctl structs

On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >> From: Gustavo Padovan >> >> Play safe and add flags member to all structs. So we don't need to >> break API or create new IOCTL in the future if new features that

[Bug 94387] Approx 35W more power usage in multi-screen

els on the card to try and see what causes the extra power / heat usage? -- 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/20160303/7a

[Bug 94387] Approx 35W more power usage in multi-screen

art -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/9072d3d0/attachment.html>

[pull] drm/msm: msm-next for 4.6

Hi Dave, Big ticket items are hdmi support for 8996 (aka snapdragon 820), and adreno 430 support. Also one more small uapi addition to support timestamp queries. The following changes since commit d2eaa59000c7717e68a75cf2c106f056d2bc30b4: Merge branch 'drm-rockchip-next-2016-02-18' of

[PATCH] staging/android: add flags member to sync ioctl structs

On Thu, Mar 3, 2016 at 3:54 PM, Rob Clark wrote: > On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman > wrote: >> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> Play safe and add flags member to all structs. So we don't need to >>> break API

[PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)

On Thu, Mar 03, 2016 at 03:50:23PM +, Lionel Landwerlin wrote: > Hi Matt, > > On 11/02/16 02:32, Matt Roper wrote: > >Gen9 platforms allow CRTC's to be programmed with a background/canvas > >color below the programmable planes. Let's expose this as a property to > >allow userspace to program

[PATCH] staging/android: change IOCTLs opcode after ABI change

From: Gustavo Padovan Burn the old opcode to avoid any potential old userspace running the old API to get weird errors. Changing the opcodes will make them fail right away. This is just a precaution, there no upstream users of these interfaces yet and the only

[GIT PULL] drm-vc4-fixes-2016-03-03

This is pretty late, and since it's not regressions, I won't be at all surprised if you want to pull this into -next instead. I could rebase it back to -rc3 if you want it for -next. The following changes since commit 81f70ba233d5f660e1ea5fe23260ee323af5d53a: Linux 4.5-rc5 (2016-02-20

[PATCH 0/4 v2] drm: Add support of ARC PGU display controller

This series add support of ARC PGU display controller. ARC PGU is a quite simple byte streamer that gets data from the framebuffer and pushes it to hte connected encoder (DP or HDMI). It was tested on ARC SDP boards (axs101 in particular). Changes v1 -> v2: * Clean-up of DT bindings

[PATCH] staging/android: add flags member to sync ioctl structs

Hi Greg, 2016-03-03 Greg Kroah-Hartman : > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Play safe and add flags member to all structs. So we don't need to > > break API or create new IOCTL in the future if new features that requires > >

[drm:radeon_dp_link_train] *ERROR* clock recovery failed -bisected

On Thu, Mar 03, 2016 at 02:38:11AM +, Ken Moffat wrote: > One of my machines is an A10 Kaveri desktop, with a good old VGA > connection to the monitor. I've only just started trying to boot > any 4.5 kernel on it, but with 4.5.0-rc6 and now linus's tree from a > few hours ago

[PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)

Hi Matt, On 11/02/16 02:32, Matt Roper wrote: > Gen9 platforms allow CRTC's to be programmed with a background/canvas > color below the programmable planes. Let's expose this as a property to > allow userspace to program a desired value. > > This patch is based on earlier work by Chandra

[PATCH 1/4 v2] drm: Add support of ARC PGU display controller

ARC PGU could be found on some development boards from Synopsys. This is a simple byte streamer that reads data from a framebuffer and sends data to the single encoder. Signed-off-by: Alexey Brodkin Cc: David Airlie Cc: dri-devel at lists.freedesktop.org Cc: linux-snps-arc at