[Bug 94671] [radeonsi] Blue-ish textures in Shadow of Mordor

https://bugs.freedesktop.org/show_bug.cgi?id=94671 --- Comment #8 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- (In reply to Nicolai H�hnle from comment #7) > Hi Jan! First, please try this patch which fixes a similar bug: > https://patchwork.freedesktop.org/patch/78118/ > > If that doesn't

[Bug 94671] [radeonsi] Blue-ish textures in Shadow of Mordor

https://bugs.freedesktop.org/show_bug.cgi?id=94671 --- Comment #9 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- Created attachment 122511 --> https://bugs.freedesktop.org/attachment.cgi?id=122511=edit Screenshot: Mesa radeonsi OpenGL - patched -- You are receiving this mail because: You are

Upstreaming DAL

On 24 March 2016 at 03:27, Alex Deucher wrote: > Our goal is to transition to our new DAL display stack. It is the > path we are validating internally for both the open and hybrid stacks > and will be the only display stack we support going forward with new > asics. When we initially released

[PATCH v2 13/18] mm/compaction: support non-lru movable pagemigration

An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/6b36af8a/attachment-0001.html>

[PATCH 0/7] drm/exynos: HDMI and DECON fixes and enhancements

Hi Andrzej, 2016년 03월 23일 22:15에 Andrzej Hajda 이(가) 쓴 글: > Hi Inki, > > This set of patches provides set of different fixes and enhancements > for DECON -> HDMI path. It is based on: > - my HDMI patches which are not yet merged[1], could you look at them > by the way, they were

[PATCH 0/7] drm/exynos: HDMI and DECON fixes and enhancements

2016년 03월 24일 10:07에 Inki Dae 이(가) 쓴 글: > Hi Andrzej, > > 2016년 03월 23일 22:15에 Andrzej Hajda 이(가) 쓴 글: >> Hi Inki, >> >> This set of patches provides set of different fixes and enhancements >> for DECON -> HDMI path. It is based on: >> - my HDMI patches which are

[PATCH 22/52] drm/amd/powerplay: enable dpm for baffin.

Alex Deucher gmail.com> writes: > + > + tmp_result = ellesmere_enable_thermal_auto_throttle(hwmgr); > + PP_ASSERT_WITH_CODE((0 == tmp_result), > + "Failed to enable thermal auto throttle!", result = > tmp_result); > + > + tmp_result =

[PATCH v2 13/18] mm/compaction: support non-lru movable page migration

On Wed, Mar 23, 2016 at 02:05:11PM +0900, Joonsoo Kim wrote: > On Tue, Mar 22, 2016 at 11:55:45PM +0900, Minchan Kim wrote: > > On Tue, Mar 22, 2016 at 02:50:37PM +0900, Joonsoo Kim wrote: > > > On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote: > > > > We have allowed migration for only

[PATCH v2 13/18] mm/compaction: support non-lru movable pagemigration

On Thu, Mar 24, 2016 at 05:26:50AM +0900, Gioh Kim wrote: >Hmmm... But, in failure case, is it safe to call putback_lru_page() for >them? >And, PageIsolated() would be left. Is it okay? It's not symmetric that >isolated page can be freed by decreasing ref count without calling >

Upstreaming DAL

Just my 2 cents^Wcomments. On Thu, Mar 24, 2016 at 12:15 AM, Dave Airlie wrote: > On 24 March 2016 at 03:27, Alex Deucher wrote: >> Our goal is to transition to our new DAL display stack. It is the >> path we are validating internally for both the open and hybrid stacks >> and will be the only

[PATCH] drm: bridge: Make (pre/post) enable/disable callbacks optional

On 02/26/2016 03:21 PM, Laurent Pinchart wrote: > Instead of forcing bridges to implement empty callbacks make them all > optional. Acked-by: Archit Taneja > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/drm_bridge.c | 12

Atomic mode-setting drivers

On Fri, Mar 04, 2016 at 05:20:00PM -0500, Alex Deucher wrote: > Code complexities and internal abstractions aside, we've implemented > the API and tested it and it appears to work. What sort of additional > semantics does atomic imply that you don't think DAL would handle? Michel asked me to

[RFC 0/6] drm/fences: add in-fences to DRM

Hey, Op 23-03-16 om 19:47 schreef Gustavo Padovan: > From: Gustavo Padovan > > Hi, > > This is a first proposal to discuss the addition of in-fences support > to DRM. It adds a new struct to fence.c to abstract the use of sync_file > in DRM drivers. The new struct fence_collection contains a

VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs

2016-02-15 10:34 GMT+08:00 Saket Sinha : > > It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained > virtualized support for 3D/OpenGL hardware acceleration in VMs, > allowing using the GPU of the host in VMs. > > As per my understanding the following components are needed - > > -

[RFC 1/6] drm/fence: add FENCE_FD property to planes

Hi, 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글: > From: Gustavo Padovan > > FENCE_FD can now be set by the user during an atomic IOCTL, it > will be used by atomic_commit to wait until the sync_file is signalled, > i.e., the framebuffer is ready for scanout. It seems that

How do I substitute drm_gem.h with another header file for Linux 3.2 kernel?

Hi, I am one of the two developers (the other is Ran Huang who posted a patch on this mailing list recently) working on reviving VIA Technologies DRM module that will support KMS and TTM. Using the installation notes James Simmons (the previous developer who did a lot of work trying to finish

[RFC 0/6] drm/fences: add in-fences to DRM

Hi, 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글: > From: Gustavo Padovan > > Hi, > > This is a first proposal to discuss the addition of in-fences support > to DRM. It adds a new struct to fence.c to abstract the use of sync_file > in DRM drivers. The new struct

[RFC 0/6] drm/fences: add in-fences to DRM

this patch series reminder me my another thoughts recently, But I don't know if my idea is appropriated: sometimes one person could only need wait any of these fence array, but it doesn't want to call fence_wait_any since which will block its thread. if there is a mechanism let the person

[Bug 115051] HD 5870, GPU lockup

https://bugzilla.kernel.org/show_bug.cgi?id=115051 Tiger changed: What|Removed |Added CC||TigerLiu.ee at gmail.com --- Comment #1 from

[linux-sunxi] [PATCH v3 08/19] ARM: sun5i: Add DRAM gates

On Thu, Mar 24, 2016 at 12:38 AM, Maxime Ripard wrote: > The DRAM gates control whether the image / display devices on the SoC have > access to the DRAM clock or not. > > Enable it. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai I assume you'll add another version for A10s, or move

[Bug 94667] Artifacts on applications on discrete

: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/2e4ea7bb/attachment.html>

[PATCH v3 1/2 RESEND] drm/dp_helper: add workarounds from intel_dp_dpcd_read_wake()

On Wed, 23 Mar 2016, Lyude wrote: > Some sinks need some time during the process of resuming the system from > sleep before they're ready to handle transactions. While it would be > nice if they responded with NACKs in these scenarios, this isn't always > the case as a few sinks will just timeout

[PATCH] drm: Add new DCS commands in the enum list

Adding new DCS commands which are specified in the DCS 1.3 spec related to CABC. Cc: Thierry Reding Cc: David Airlie Cc: Ville Syrjälä Cc: Daniel Vetter Suggested-by: Jani Nikula Signed-off-by: Deepak M --- include/video/mipi_display.h | 8 1 file changed, 8 insertions(+) diff

[Bug 94667] Artifacts on applications on discrete

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/e8052148/attachment-0001.html>

[PATCH 02/23] ARM: dts: n950: add display support

On Wed, 23 Mar 2016, Sebastian Reichel wrote: > On Wed, Mar 23, 2016 at 02:40:53PM +0200, Jani Nikula wrote: >> On Thu, 17 Mar 2016, Sebastian Reichel wrote: >> > On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote: >> >> [...] >> >> > + >> >> > + /* panel is 480x464

[Intel-gfx] [PATCH 1/3] drm: Add new DCS commands in the enum list

On Thu, 24 Mar 2016, Deepak M wrote: > Adding new DCS commands which are specified in the > DCS 1.3 spec related to CABC. > > Cc: Thierry Reding > Cc: David Airlie > Cc: Ville Syrjälä > Cc: Daniel Vetter > Suggested-by: Jani Nikula > Signed-off-by: Deepak M Deepak, for future reference,

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

59.91*+ […] -- 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/20160324/857c8ab2/attachment.html>

[PATCH 2/3] devicetree: Add ANX7814 bridge binding.

The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter designed for portable devices. Signed-off-by: Enric Balletbo i Serra --- .../devicetree/bindings/video/bridge/anx7814.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644

[PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.

Although there are other chips from the same family that can reuse this driver, at the moment we only tested ANX7814 chip. The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter designed for portable devices. This driver adds initial support for HDMI to DP pass-through mode.

[PATCH 0/3] Add ANX7814 I2C bridge driver

Hi all, This patch set to introduces the anx7814 slimport transmitter driver. These new series will replace the old series that can be found here [1]. The reason why I introduce these new series is because the driver changed significantly. The old approach used a polled state machine ans was not

[PATCH 1/3] of: Add vendor prefix for Analogix Semiconductor

Analogix Semiconductor Inc. develops analog and mixed-signal devices for digital media and communications interconnect applications. Signed-off-by: Enric Balletbo i Serra --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] drm/exynos: fix cancel page flip code

Driver code did not remove event from the list of pending events before destroy. As a result drm core tried later to inspect invalid memory location. The patch replaces removal code with call to core helper. The bug was detected using KASAN: [ 10.107249]

[PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.

On Thu, Mar 24, 2016 at 11:41:46AM +0100, Enric Balletbo i Serra wrote: > + /* Map slave addresses of ANX7814 */ > + for (i = 0; i < I2C_NUM_ADDRESSES; i++) { > + anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter, > +

[Bug 94667] Artifacts on applications on discrete

part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/81d3f941/attachment.html>

[Bug 94667] Artifacts on applications on discrete

bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/bdcbda6f/attachment.html>

[PATCH] drm: bridge: anx78xx: fix ptr_ret.cocci warnings

drivers/gpu/drm/bridge/anx78xx.c:632:1-3: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci CC: Enric Balletbo i Serra Signed-off-by: Fengguang Wu --- anx78xx.c |5 + 1 file changed, 1

[PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.

Hi Enric, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.5 next-20160324] [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/Enric-Balletbo-i-Serra/Add-ANX7814-I2C

[PATCH] drm: Add new DCS commands in the enum list

On 03/24/2016 10:18 AM, Deepak M wrote: > Adding new DCS commands which are specified in the > DCS 1.3 spec related to CABC. > > Cc: Thierry Reding > Cc: David Airlie > Cc: Ville Syrjälä > Cc: Daniel Vetter > Suggested-by: Jani Nikula > Signed-off-by: Deepak M > --- >

[Bug 94667] Artifacts on applications on discrete

tom part of the screen looks weird -- 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/20160324/30a0aff5/attachment.html>

[PATCH 1/1] drm: fsl-dcu: Use flat cache

Using REGCACHE_RBTREE for MMIO regmap is not valid as spinlock's will be used during cache allocation. This fixes the following bug: BUG: sleeping function called from invalid context at mm/slab.h:388 in_atomic(): 1, irqs_disabled(): 128, pid: 192, name: udevd [...] Signed-off-by: Alexander

[RFC 0/6] drm/fences: add in-fences to DRM

Hi Maarten, 2016-03-24 Maarten Lankhorst : > Hey, > > Op 23-03-16 om 19:47 schreef Gustavo Padovan: > > From: Gustavo Padovan > > > > Hi, > > > > This is a first proposal to discuss the addition of in-fences support > > to DRM. It adds a new struct to fence.c to abstract the use of sync_file >

[RFC 0/6] drm/fences: add in-fences to DRM

Hi Inki, 2016-03-24 Inki Dae : > Hi, > > 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글: > > From: Gustavo Padovan > > > > Hi, > > > > This is a first proposal to discuss the addition of in-fences support > > to DRM. It adds a new struct to fence.c to abstract the use of

Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

On 03/22/2016 08:41 PM, Dave Airlie wrote: >>> So although it's small framework or just subdirectory, we would need >>> someone who can manage the framework to avoid further confusion if >>> necessary. >> So maybe it just doesn't need a maintainer, and maybe those the owner >> of the bridge

[PATCH 2/4 v3] drm: Add DT bindings documentation for ARC PGU display controller

Hi Rob, On Mon, 2016-03-21 at 08:04 -0500, Rob Herring wrote: > On Fri, Mar 11, 2016 at 06:42:37PM +0300, Alexey Brodkin wrote: > > > > This add DT bindings documentation for ARC PGU display controller. > > > > Signed-off-by: Alexey Brodkin > > Cc: Rob Herring > > Cc:

[PATCH v14 0/17] Add Analogix Core Display Port Driver

Am Montag, 15. Februar 2016, 19:08:05 schrieb Yakir Yang: > Hi all, > > The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller > share the same IP, so a lot of parts can be re-used. I split the common > code into bridge directory, then rk3288 and exynos only need to keep > some

[PATCH 02/23] ARM: dts: n950: add display support

as missing. In my case the "[" prefix of kernel messages was rendered as two dots. At least the vertical line was not visible at all. I _think_, that your HW team decided to cover the first and the last few pixels of the 864 display with plastic. So technically it's a 864 display, but e

[PATCH 02/23] ARM: dts: n950: add display support

On Thu, 24 Mar 2016, Sebastian Reichel wrote: > As I said: I did use 864 initially. That results in missing pixels. Sorry, I didn't mean to question this. Go with what works, not with some old fart's ramblings! > I _think_, that your HW team decided to cover the first and the > last few pixels

[Bug 93178] Textures are filled with garbage

ime. -- 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/20160324/de15bfd1/attachment.html>

Upstreaming DAL

On Wed, Mar 23, 2016 at 01:27:21PM -0400, Alex Deucher wrote: > Our goal is to transition to our new DAL display stack. It is the > path we are validating internally for both the open and hybrid stacks > and will be the only display stack we support going forward with new > asics. When we

[RFC 0/6] drm/fences: add in-fences to DRM

On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae wrote: > Hi, > > 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글: >> From: Gustavo Padovan >> >> Hi, >> >> This is a first proposal to discuss the addition of in-fences support >> to DRM. It adds a new struct to fence.c to abstract the use

[Bug 94671] [radeonsi] Blue-ish textures in Shadow of Mordor

org/archives/dri-devel/attachments/20160324/ae6d1d98/attachment-0001.html>

[Bug 94484] Kernel BUG with latest radeon driver

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/87c48bd3/attachment-0001.html>

[PATCH v4 0/5] Move workarounds from intel_dp_dpcd_read_wake() into drm's DP helpers

This series of patches takes all of the workarounds we used in intel_dp_dpcd_read_wake() for working around misbehaving sinks into drm's DP aux transaction helpers, so that they can be applied to all aux transactions across each driver. While this patch series was intended to fix issues with the

[PATCH v4 1/5] drm/dp_helper: Increase retry interval to 1000us

This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. Signed-off-by: Lyude --- drivers/gpu/drm/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v4 2/5] drm/dp_helper: Always wait before retrying native aux transactions

This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. Some sinks need some time during the process of resuming the system from sleep before they're ready to handle transactions. While it would be

[PATCH v4 3/5] drm/dp_helper: Retry aux transactions on all errors

This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. We cannot rely on sinks NACKing or deferring when they can't receive transactions, nor can we rely on any other sort of consistent error to

[PATCH v4 4/5] drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()

This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. Some sinks will just return garbage for the first aux tranaction they receive when coming out of sleep mode, so we need to perform an

[PATCH v4 5/5] drm/i915: Get rid of intel_dp_dpcd_read_wake()

Since we've fixed up drm_dp_dpcd_read() to allow for retries when things timeout, there's no use for having this function anymore. Good riddens. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_dp.c | 79 - 1 file changed, 22 insertions(+), 57

[Bug 115251] New: amdgpu: Black screen + hang with Kaveri

https://bugzilla.kernel.org/show_bug.cgi?id=115251 Bug ID: 115251 Summary: amdgpu: Black screen + hang with Kaveri Product: Drivers Version: 2.5 Kernel Version: 4.4.5 Hardware: x86-64 OS: Linux Tree: Mainline

[Bug 115141] radeon kernel module hangs suspend

https://bugzilla.kernel.org/show_bug.cgi?id=115141 --- Comment #4 from Paulo Dias --- sorry i cant, i dont have the resources :( maybe eugene? -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 115251] amdgpu: Black screen + hang with Kaveri

https://bugzilla.kernel.org/show_bug.cgi?id=115251 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1

omap4: how to get the HDMI core IRQ?

Hi Tomi, I hope you (or someone else on this list) can help me find the problem in this code. I am working on a kernel framework for HDMI CEC (see https://lwn.net/Articles/680942/). In order to get as much experience with different devices as possible I am trying to implement it on my

[Bug 94689] Two monitor DisplayPort MST DaisyChain (Second/Last Monitor In Chain Black Screen)

vel/attachments/20160324/2a4ce72b/attachment.html>

[PATCH 4/5] drm/vc4: Add DPI driver

de is not useful, though (Note: I had documented it backwards: false is hsync|vsync, true is hactive). That just left me with output-format. I think .bus_format in the panel_desc can cover that, so I've now dropped all of these brcm properties. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/c0f99da7/attachment.sig>

[PATCH 0/5 v4] 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/103 in particular). Note following series that introduces

[PATCH 1/5 v4] drm: Add support of ARC PGU display controller

From: Carlos Palminha 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: Carlos Palminha Signed-off-by: Alexey Brodkin Cc: David Airlie

[PATCH 2/5 v4] drm: Add DT bindings documentation for ARC PGU display controller

This add DT bindings documentation for ARC PGU display controller. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: devicetree at vger.kernel.org Cc: linux-snps-arc at

[PATCH 3/5 v4] MAINTAINERS: Add maintainer for ARC PGU display controller

This updates MAINTEINERS file with information about maintainer of ARC PGU display controller driver. Signed-off-by: Alexey Brodkin Cc: linux-snps-arc at lists.infradead.org --- No changes v3 -> v4. No changes v2 -> v3. No changes v1 -> v2. MAINTAINERS | 6 ++ 1 file changed, 6

[PATCH 4/5 v4] arc: Add our own implementation of fb_pgprotect()

During mmaping of frame-buffer pages to user-space fb_protect() is called to set proper page settings. In case of ARC we need to mark pages that are mmaped to user as uncached because of 2 reasons: * Huge amount of data if passing through data cache will thrash cache a lot making cache almost

[PATCH 5/5 v4] arc: axs10x - add support of ARC PGU

Synopsys DesignWare ARC SDP boards sport ARC SDP display controller attached to ADV7511 HDMI encoder. That change adds desctiption of both ARC PGU and ADV7511 in ARC SDP'd base-board Device Tree. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Pawel Moll Cc: Mark

[PATCH 1/5 v4] drm: Add support of ARC PGU display controller

Hello, On Fri, 2016-03-25 at 01:37 +0800, kbuild test robot wrote: > Hi Carlos, > > [auto build test ERROR on drm/drm-next] > [also build test ERROR on v4.5 next-20160324] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system

[PATCH 0/5 v2] drm/vc4: DPI panel support

This is round 2 of the DPI panel support for vc4. This time the custom properties are dropped in favor of connector->display_info.bus_formats[]. Testable tree is at: https://github.com/anholt/linux/tree/drm-vc4-dpi-boot Eric Anholt (5): of: Add vendor prefix for On Tat Industrial Company.

[PATCH 2/5] panel-simple: Add the 7" DPI panel from Adafruit.

This is a basic TFT panel with a 40-pin FPC connector on it. The specification doesn't define timings, but the Adafruit instructions were setting up 800x480 CVT. v2: Add .bus_format and vsync/hsync flags. Signed-off-by: Eric Anholt Acked-by: Rob Herring ---

[PATCH 3/5] drm: Add an encoder and connector type enum for DPI.

Right now exynos is exposing DPI as a TMDS encoder and VGA connector, which seems rather misleading. This isn't just an internal detail, since xrandr actually exposes "VGA" as the output name. Define some new enums so that vc4's DPI can have a more informative name. I considered other names for

[PATCH 1/5] of: Add vendor prefix for On Tat Industrial Company.

This is the vendor for a 7" DPI panel sold by Adafruit which I'd like to describe in DT. Signed-off-by: Eric Anholt Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 4/5] drm/vc4: Add DPI driver

The DPI interface involves taking a ton of our GPIOs to be used as outputs, and routing display signals over them in parallel. v2: Use display_info.bus_formats[] to replace our custom DT properties. Signed-off-by: Eric Anholt --- .../devicetree/bindings/display/brcm,bcm-vc4.txt | 36 ++

[PATCH 5/5] ARM: bcm2835: Add the DPI hardware to the device tree.

It's currently marked disabled, as it's not useful without a panel associated with it and the GPIO pins routed to ALT2. Signed-off-by: Eric Anholt --- arch/arm/boot/dts/bcm283x.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/bcm283x.dtsi

[pull] radeon and amdgpu drm-next-4.6

Hi Dave, A few fixes for 4.6. The following changes since commit 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7: drm/amdgpu: release_pages requires linux/pagemap.h (2016-03-21 13:22:52 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.6 for you