Re: [PATCH] drm-misc: Document review best practices

On Tue, Feb 28, 2017 at 12:09:29PM -0800, Eric Anholt wrote: > Daniel Vetter writes: > > > Let's make sure that review doesn't go through needless cycles. Diff > > doesn't show this, but this is only for the "small drivers" part of > > drm. > > > > Acked-by: Boris

Re: [PATCH] MAINTAINERS: Update git entries for drivers in drm-misc

On Tue, Feb 28, 2017 at 08:36:57PM +0100, Daniel Vetter wrote: > It's still just an experiment, but one lesson learned from drm-misc is > that not updating MAINTAINERS just leads to confusion. And this is > easy to revert. > > Cc: Boris Brezillon > Cc: Mark

Re: [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

On 28/02/17 14:55, Joe Perches wrote: > Use a more common logging style. > > Miscellanea: > > o Coalesce formats and realign arguments > o Neaten a few macros now using pr_ > > Signed-off-by: Joe Perches For omap: Acked-by: Tomi Valkeinen Tomi

[Bug 194731] drm general protection fault in drm_atomic_init

https://bugzilla.kernel.org/show_bug.cgi?id=194731 --- Comment #6 from Janpieter Sollie (janpieter.sol...@dommel.be) --- I know, but isn't it possible that the error is with DRM and not with the driver? if not, sorry for reporting a wrong bug -- You are receiving this mail because: You are

Re: [PATCH] drm: vc4: Don't wait for vblank when updating the cursor

On 01/03/17 11:00 AM, Michael Zoran wrote: > On Wed, 2017-03-01 at 10:48 +0900, Michel Dänzer wrote: >> On 01/03/17 12:45 AM, Michael Zoran wrote: >>> On Tue, 2017-02-28 at 16:42 +0900, Michel Dänzer wrote: On 24/02/17 10:54 AM, Michael Zoran wrote: > Commonly used desktop environments

Re: [PATCH] drm: vc4: Don't wait for vblank when updating the cursor

On Wed, 2017-03-01 at 10:48 +0900, Michel Dänzer wrote: > On 01/03/17 12:45 AM, Michael Zoran wrote: > > On Tue, 2017-02-28 at 16:42 +0900, Michel Dänzer wrote: > > > On 24/02/17 10:54 AM, Michael Zoran wrote: > > > > Commonly used desktop environments such as xfce4 and gnome > > > > on debian sid

Re: [PATCH] drm: vc4: Don't wait for vblank when updating the cursor

On 01/03/17 12:45 AM, Michael Zoran wrote: > On Tue, 2017-02-28 at 16:42 +0900, Michel Dänzer wrote: >> On 24/02/17 10:54 AM, Michael Zoran wrote: >>> Commonly used desktop environments such as xfce4 and gnome >>> on debian sid can flood the graphics drivers with cursor >>> updates. >> >> FWIW,

[Bug 194731] drm general protection fault in drm_atomic_init

https://bugzilla.kernel.org/show_bug.cgi?id=194731 --- Comment #5 from Michel Dänzer (mic...@daenzer.net) --- This bugzilla is only for in-tree code. Also, amdgpu-pro doesn't officially support 4.10 yet, so this is basically an unsupported configuration. -- You are receiving this mail because:

Re: [PATCH v4 4/5] drm/atomic: Convert get_existing_state callers to get_old/new_state, v3.

Hi Maarten, Thank you for the patch. On Thursday 16 Feb 2017 15:47:09 Maarten Lankhorst wrote: > This is a straightforward conversion that converts all the users of > get_existing_state in atomic core to use get_old_state or get_new_state > > Changes since v1: > - Fix using the wrong state in >

Re: [PATCH v4 5/5] drm/blend: Use new atomic iterator macros.

Hi Maarten, Thank you for the patch. On Thursday 16 Feb 2017 15:47:10 Maarten Lankhorst wrote: > There are new iterator macros that annotate whether the new or old > state should be used. This is better than using a state that depends on > whether it's called before or after swap. For clarity,

Re: [PATCH v4 3/5] drm/atomic: Add macros to access existing old/new state, v2.

Hi Maarten, Thank you for the patch. On Thursday 16 Feb 2017 15:47:08 Maarten Lankhorst wrote: > After atomic commit, these macros should be used in place of > get_existing_state. Also after commit get_xx_state should no longer > be used because it may not have the required locks. > > The calls

Re: [PATCH v4 2/5] drm/atomic: Make drm_atomic_plane_disabling easier to understand.

Hi Maarten, Thank you for the patch. On Thursday 16 Feb 2017 15:47:07 Maarten Lankhorst wrote: > This function becomes a lot simpler when having passed both the old and > new state to it. Looking at all callers, it seems that old_plane_state > is never NULL so the check can be dropped. > >

Re: [PATCH v4 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v2.

Hi Maarten, Thank you for the patch. On Thursday 16 Feb 2017 15:47:06 Maarten Lankhorst wrote: > There are new iterator macros that annotate whether the new or old > state should be used. This is better than using a state that depends on > whether it's called before or after swap. For clarity,

[PATCH 3/3] drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style issues

Fixed the following style issues drivers/gpu/vga/vga_switcheroo.c:98: WARNING: please, no space before tabs drivers/gpu/vga/vga_switcheroo.c:99: WARNING: please, no space before tabs drivers/gpu/vga/vga_switcheroo.c:102: WARNING: please, no space before tabs drivers/gpu/vga/vga_switcheroo.c:103:

Re: [PATCH] drm/atmel-hlcdc: Simplify the HLCDC layer logic

Le 06/02/2017 à 19:27, Boris Brezillon a écrit : > An HLCDC layers in Atmel's nomenclature is either a DRM plane or a 'Post > Processing Layer' which can be used to output the results of the HLCDC > composition in a memory buffer. > > atmel_hlcdc_layer.c was designed to be generic enough to be

[git pull] drm fixes for v4.11-rc1

This is a selection of fixes for recent bugs, the vmwgfx one is important to avoid a regression, and compat ioctl one is pretty urgent for stable. Otherwise nothing too much. I've got a separate pull req for some AST hw IBM need to enable. Dave. The following changes since commit

[PATCH V2 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

The video processing pipeline on the second output on the GE B850v3: Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output Each bridge has a dedicated flash containing firmware for supporting the custom design. The result is that in this design neither the STDP4028 nor the

[PATCH V2 4/4] dts/imx6q-b850v3: Use megachips-stdpxxxx-ge-b850v3-fw bridges (LVDS-DP++)

Configures the megachips-stdp-ge-b850v3-fw bridges on the GE B850v3 dts file. Cc: Laurent Pinchart Cc: Martyn Welch Cc: Martin Donnelly Cc: Javier Martinez Canillas Cc: Enric

Re: [PATCH v2 9/9] drm/i915: Add render decompression support

On Thu, Jan 5, 2017 at 7:14 AM, wrote: > From: Ville Syrjälä > > SKL+ display engine can scan out certain kinds of compressed surfaces > produced by the render engine. This involved telling the display engine > the location of the

Re: [RESEND PATCH v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph

On Tue, Feb 28, 2017 at 10:17 AM, Hoegeun Kwon wrote: > Hi All, > > [Resend this v2 patches, because i have missing TO and CC.] > > The dsi + panel is a parental relationship, so OF grpah is not needed. > Therefore, the current dsi_parse_dt function will throw an error,

Re: [PATCH 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

On 02/27/2017 07:10 PM, Peter Senna Tschudin wrote: On Wed, Feb 01, 2017 at 04:17:21PM +0530, Archit Taneja wrote: Hi Archit, Hi, Some minor comments: Thank you for the review! On 01/28/2017 07:51 PM, Peter Senna Tschudin wrote: The video processing pipeline on the second output on

Re: [PATCH RESEND] drm/via: use get_user_pages_unlocked()

On 28 February 2017 at 19:35, Al Viro wrote: > On Tue, Feb 28, 2017 at 10:01:10AM +0100, Daniel Vetter wrote: > >> > + ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr, >> > + vsg->num_pages, vsg->pages, >> > +

Re: [PATCH] drm: vc4: Don't wait for vblank when updating the cursor

On Tue, 2017-02-28 at 16:42 +0900, Michel Dänzer wrote: > On 24/02/17 10:54 AM, Michael Zoran wrote: > > Commonly used desktop environments such as xfce4 and gnome > > on debian sid can flood the graphics drivers with cursor > > updates. > > FWIW, this has nothing to do with the desktop

[PATCH V2 0/4] megachips-stdpxxxx-ge-b850v3-fw

The video processing pipeline on the second output on the GE B850v3: Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output Each bridge has a dedicated flash containing firmware for supporting the custom design. The result is that in this design neither the STDP4028 nor the

Re: [PATCH RESEND] drm/via: use get_user_pages_unlocked()

On Tue, Feb 28, 2017 at 10:01:10AM +0100, Daniel Vetter wrote: > > + ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr, > > + vsg->num_pages, vsg->pages, > > + (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 0); Umm... Why not ret =

Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format

On 02/28/2017 06:57 AM, clinton.a.tay...@intel.com wrote: From: Clint Taylor P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. Rockchip's vop support this video format(little endian only) as the input video format. P016 is a

[PATCH V2 1/4] dt-bindings: display: megachips-stdpxxxx-ge-b850v3-fw

Devicetree binding documentation for the second video output of the GE B850v3: STDP4028-ge-b850v3-fw bridges (LVDS-DP) STDP2690-ge-b850v3-fw bridges (DP-DP++) Added entry for MegaChips at: Documentation/devicetree/bindings/vendor-prefixes.txt Cc: Laurent Pinchart

[git pull] drm ast support for ast 2500 hardware

This is a set of changes to enable the AST2500 BMC hardware, and also fix some bugs interacting with the older AST hardware. Some of the bug fixes are cc'ed to stable. Dave. The following changes since commit 45554b2357d5782497e59f09146cc3636d6ad551: Merge tag 'trace-v4.11-2' of

[PATCH V2 2/4] MAINTAINERS: Add entry for megachips-stdpxxxx-ge-b850v3-fw

Add MAINTAINERS entry for the second video output of the GE B850v3: STDP4028-ge-b850v3-fw bridges (LVDS-DP) STDP2690-ge-b850v3-fw bridges (DP-DP++) Cc: Laurent Pinchart Cc: Martyn Welch Cc: Martin Donnelly

Re: [PATCH 6/6] drm/doc: atomic overview, with graph

Daniel Vetter writes: > I want to split up a few more things and document some details better > (like how exactly to subclass drm_atomic_state). And maybe also split > up the helpers a bit per-topic, but this should be a ok-ish start for > better atomic overview. > > One

Re: [PATCH 5/6] drm/doc: diagram for mode objects and properties

Daniel Vetter writes: > Resulted in confusion a few times in the past. > > Cc: Laurent Pinchart > Cc: Manasi Navare > Signed-off-by: Daniel Vetter > --- >

Re: [PATCH 4/6] drm/doc: Consistent kerneldoc include order

Daniel Vetter writes: > First overview text (if there is any), then headers (since generally > you want to start out with the data structures), then all the other > stuff with functions. > > Most of this is pre-shpinx, since with the old docbook only the "sphinx"

[PATCH v6 1/2] drm_fourcc: Add new P010, P016 video format

From: Clint Taylor P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. Rockchip's vop support this video format(little endian only) as the input video format. P016 is a planar 4:2:0 YUV 12 bits per channel P016 is a planar 4:2:0

Re: [PATCH v2 9/9] drm/i915: Add render decompression support

On 17-02-28 12:18:39, Jason Ekstrand wrote: On Thu, Jan 5, 2017 at 7:14 AM, wrote: From: Ville Syrjälä SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the

Re: [PATCH v2 9/9] drm/i915: Add render decompression support

On 17-02-28 12:18:39, Jason Ekstrand wrote: On Thu, Jan 5, 2017 at 7:14 AM, wrote: From: Ville Syrjälä SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the

Re: [PATCH] drm: vc4: Don't wait for vblank when updating the cursor

Michael Zoran writes: > Commonly used desktop environments such as xfce4 and gnome > on debian sid can flood the graphics drivers with cursor > updates. Because the current implementation is waiting > for a vblank between cursor updates, this will cause the > display to

Re: [PATCH 0/4] vc4 RST documentation

Daniel Vetter writes: > On Mon, Feb 27, 2017 at 12:11:40PM -0800, Eric Anholt wrote: >> danvet asked me a while ago to try generating documentation with the >> new RST-based infrastructure. I had a couple of hours to do some >> editing, so here it is. >> >> So far I'm not

Re: [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

On Tue, Feb 28, 2017 at 1:55 PM, Joe Perches wrote: > Use a more common logging style. > > Miscellanea: > > o Coalesce formats and realign arguments > o Neaten a few macros now using pr_ > > Signed-off-by: Joe Perches For the gma500 changes: Acked-by: Patrik

Re: [PATCH] MAINTAINERS: Update git entries for drivers in drm-misc

On Tue, 28 Feb 2017 20:36:57 +0100 Daniel Vetter wrote: > It's still just an experiment, but one lesson learned from drm-misc is > that not updating MAINTAINERS just leads to confusion. And this is > easy to revert. > > Cc: Boris Brezillon

Re: [PATCH] MAINTAINERS: Update git entries for drivers in drm-misc

Daniel Vetter writes: > It's still just an experiment, but one lesson learned from drm-misc is > that not updating MAINTAINERS just leads to confusion. And this is > easy to revert. > > Cc: Boris Brezillon > Cc: Mark Yao

Re: [PATCH] drm-misc: Document review best practices

Daniel Vetter writes: > Let's make sure that review doesn't go through needless cycles. Diff > doesn't show this, but this is only for the "small drivers" part of > drm. > > Acked-by: Boris Brezillon > Acked-by: Jani Nikula

Re: [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

For drm/vmwgfx: Acked-by: Sinclair Yeh On Tue, Feb 28, 2017 at 04:55:54AM -0800, Joe Perches wrote: > Use a more common logging style. > > Miscellanea: > > o Coalesce formats and realign arguments > o Neaten a few macros now using pr_ > > Signed-off-by: Joe Perches

Re: [PATCH] MAINTAINERS: Update git entries for drivers in drm-misc

> diff --git a/MAINTAINERS b/MAINTAINERS > index 6cd8945b9094..e55a648e77ec 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4174,7 +4174,7 @@ F: drivers/gpu/drm/bridge/ > DRM DRIVER FOR BOCHS VIRTUAL GPU > M: Gerd Hoffmann > L:

[PATCH] MAINTAINERS: Update git entries for drivers in drm-misc

It's still just an experiment, but one lesson learned from drm-misc is that not updating MAINTAINERS just leads to confusion. And this is easy to revert. Cc: Boris Brezillon Cc: Mark Yao Cc: Eric Anholt Cc: Gerd

Re: [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

On Tue, Feb 28, 2017 at 7:55 AM, Joe Perches wrote: > Use a more common logging style. > > Miscellanea: > > o Coalesce formats and realign arguments > o Neaten a few macros now using pr_ > > Signed-off-by: Joe Perches for drm/msm part: Acked-by: Rob Clark

Re: [Intel-gfx] [PATCH v2 01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec

On Tue, 28 Feb 2017 13:59:16 +0100 Hans de Goede wrote: > Document the DSI panel enable / disable sequences from the spec, > for easy comparison between the code and the spec. > > Signed-off-by: Hans de Goede > Acked-by: Jani Nikula

[PATCH 5/6] drm/doc: diagram for mode objects and properties

Resulted in confusion a few times in the past. Cc: Laurent Pinchart Cc: Manasi Navare Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 22 ++ 1 file changed, 22

[PATCH 6/6] drm/doc: atomic overview, with graph

I want to split up a few more things and document some details better (like how exactly to subclass drm_atomic_state). And maybe also split up the helpers a bit per-topic, but this should be a ok-ish start for better atomic overview. One thing I failed at is getting DOT to layout the overview

[PATCH 1/6] doc: Explain light-handed markup preference a bit better

We already had a super-short blurb, but worth extending it I think: We're still pretty far away from anything like a consensus, but there's clearly a lot of people who prefer an as-light as possible approach to converting existing .txt files to .rst. Make sure this is properly taken into account

[PATCH 4/6] drm/doc: Consistent kerneldoc include order

First overview text (if there is any), then headers (since generally you want to start out with the data structures), then all the other stuff with functions. Most of this is pre-shpinx, since with the old docbook only the overview stuff was pulled in directly. Everything else was put in a

[PATCH 3/6] drm/doc: Add KMS overview graphs

Oh, the shiny and pretties! Cc: Laurent Pinchart Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms-helpers.rst | 4 ++ Documentation/gpu/drm-kms.rst | 132 ++ 2 files changed, 136

[PATCH 0/6] more kernel-doc patches

Hi all, Finally gotten around to polish and flush these out. I think Markus' kfigure/kimage/krender support is now simplified a lot (at least as much as I managed with my python/sphinx noob-ness), and also rebase the doc patch about the light markup approach we've discussed a while ago.

[PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

From: Markus Heiser This patch brings scalable figure, image handling and a concept to embed *render* markups: * DOT (http://www.graphviz.org) * SVG For image handling use the 'image' replacement:: .. kernel-image:: svg_image.svg :alt:simple SVG

[Bug 193341] AMDGPU: kernel NULL pointer dereferenced with hybrid graphics

https://bugzilla.kernel.org/show_bug.cgi?id=193341 --- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) --- Make sure your kernel has this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c10c8f7c27103bd7ac02d041d9d6e97296d48fc1 -- You are receiving this mail

Re: [PATCH v2 1/4] drm: add RGB formats with separate alpha plane

On Tue, Feb 28, 2017 at 03:12:35PM +0100, Philipp Zabel wrote: > Some hardware can read the alpha components separately and then > conditionally fetch color components only for non-zero alpha values. > This patch adds fourcc definitions for two-plane RGB formats with an > 8-bit alpha channel on a

[Bug 193341] AMDGPU: kernel NULL pointer dereferenced with hybrid graphics

https://bugzilla.kernel.org/show_bug.cgi?id=193341 --- Comment #7 from stefan.ko...@um.si --- Created attachment 254989 --> https://bugzilla.kernel.org/attachment.cgi?id=254989=edit Dmesg of 4.10.1-1-ARCH #1 SMP PREEMPT Sun Feb 26 21:08:53 UTC 2017 x86_64 GNU/Linux I'm not sure if all

Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format

On 02/28/2017 02:58 AM, ayaka wrote: On 02/28/2017 06:57 AM, clinton.a.tay...@intel.com wrote: From: Clint Taylor P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. Rockchip's vop support this video format(little endian only)

Re: [RESEND PATCH 00/14] QXL atomic modesetting

Hi, > Patches look good, great job. I'll go run some more tests and if all > goes fine I'll push to drm-misc-next. Ok, cool, text console, xorg and wayland all work fine without glitches. Series pushed. thanks, Gerd ___ dri-devel mailing list

Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format

On Tue, Feb 28, 2017 at 08:08:55AM -0800, Clint Taylor wrote: > On 02/28/2017 03:56 AM, Ville Syrjälä wrote: > > On Mon, Feb 27, 2017 at 02:57:58PM -0800, clinton.a.tay...@intel.com wrote: > >> From: Clint Taylor > >> > >> P010 is a planar 4:2:0 YUV with interleaved UV

Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format

On 02/28/2017 03:56 AM, Ville Syrjälä wrote: On Mon, Feb 27, 2017 at 02:57:58PM -0800, clinton.a.tay...@intel.com wrote: From: Clint Taylor P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. Rockchip's vop support this video

[Bug 99850] Tessellation bug on Carrizo

https://bugs.freedesktop.org/show_bug.cgi?id=99850 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED

Re: ABI navigator for libdrm

On Tue, Feb 28, 2017 at 8:11 AM, Andrey Ponomarenko wrote: > 27.02.2017, 15:30, "Rob Clark": >> On Mon, Feb 27, 2017 at 1:41 AM, Andrey Ponomarenko: >>> 26.02.2017, 22:15, "Daniel Vetter": On Sun, Feb 26, 2017 at 10:51 AM, Andrey Ponomarenko: > Hello,

[PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic framebuffer emulation driver. Legacy framebuffer users like non kms/drm based OpenGL(ES)/EGL implementations may require the ioctl to synchronize drawing or buffer flip for double buffering. It is tested on the i.MX6.

[PATCH v4 0/1] drm: Support framebuffer panning

Hi, This is a respin of the previous serie called "Support fast framebuffer panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been removed, and the comments that were made at that time fixed (hopefully). Let me know what you think, Maxime Changes from v3: - Dropped the

[Bug 97590] Fury X (Fiji) LEDs do not reflect GPU load

https://bugs.freedesktop.org/show_bug.cgi?id=97590 --- Comment #15 from Alex Deucher --- (In reply to Vedran Miletić from comment #14) > (In reply to Adam Bolte from comment #9) > > The only difference between this patch and the Windows behaviour is with the > > second

Re: 4.11-rc0, thinkpad x220: GPU hang

On Tue, Feb 28, 2017 at 03:34:53PM +0100, Pavel Machek wrote: > Hi! > > mplayer stopped working after a while. Dmesg says: > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at > usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5 > [ 3190.767227] [drm] GPU HANG: ecode

Re: [RESEND PATCH 00/14] QXL atomic modesetting

On Di, 2017-02-28 at 14:29 +0100, Gerd Hoffmann wrote: > On Mo, 2017-02-27 at 17:43 -0300, Gabriel Krisman Bertazi wrote: > > Hi, > > > > This is a resend of the qxl atomic modesetting patchset to include the > > reviewed-by tags from Gustavo and rebase on top of the tip of drm-misc-next. > > >

[PATCH v3 5/7] drm: Introduce drm_gem_object_{get,put}()

From: Thierry Reding For consistency with other reference counting APIs in the kernel, add drm_gem_object_get() and drm_gem_object_put(), as well as an unlocked variant of the latter, to reference count GEM buffer objects. Compatibility aliases are added to keep existing

[PATCH v3 0/7] drm: Introduce consistent reference counting APIs

From: Thierry Reding This series introduces DRM reference counting APIs that are consistent with other reference counting APIs in the kernel. They are also much shorter. Compatibility aliases are added to keep existing code working and will stay in place until all users of

[PATCH v3 6/7] drm: Introduce drm_property_blob_{get,put}()

From: Thierry Reding For consistency with other reference counting APIs in the kernel, add drm_property_blob_get() and drm_property_blob_put() to reference count DRM blob properties. Compatibility aliases are added to keep existing code working. To help speed up the

[PATCH v3 1/7] drm: Rename drm_mode_object_get()

From: Thierry Reding Subsequent patches will introduce reference counting APIs that are more consistent with similar APIs throughout the Linux kernel. These APIs use the _get() and _put() suffixes and will collide with this existing function. Rename the function to

[PATCH v3 3/7] drm: Introduce drm_connector_{get,put}()

From: Thierry Reding For consistency with other reference counting APIs in the kernel, add drm_connector_get() and drm_connector_put() functions to reference count connectors. Compatibility aliases are added to keep existing code working. To help speed up the transition, all

[PATCH v3 4/7] drm: Introduce drm_framebuffer_{get,put}()

From: Thierry Reding For consistency with other reference counting APIs in the kernel, add drm_framebuffer_get() and drm_framebuffer_put() to reference count DRM framebuffers. Compatibility aliases are added to keep existing code working. To help speed up the transition, all

[PATCH v3 7/7] drm: Rename connector list iterator API

From: Thierry Reding Currently the functions that initialize and tear down a connector iterator use the _get() and _put() suffixes. However, these suffixes are typically used by reference counting functions. Make these function names a little more consistent by changing the

[PATCH v3 2/7] drm: Introduce drm_mode_object_{get,put}()

From: Thierry Reding For consistency with other reference counting APIs in the kernel, add drm_mode_object_get() and drm_mode_object_put() to reference count DRM mode objects. Compatibility aliases are added to keep existing code working. To help speed up the transition, all

4.11-rc0, thinkpad x220: GPU hang

Hi! mplayer stopped working after a while. Dmesg says: [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5 [ 3190.767227] [drm] GPU HANG: ecode 6:0:0xbb409fff, in chromium [4597], reason: Hang on render ring, action: reset

Re: [PATCH v2 4/9] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

On Tue, Feb 28, 2017 at 4:07 AM, Yannick FERTRE wrote: > On 02/24/2017 03:06 PM, Rob Herring wrote: >> On Fri, Feb 24, 2017 at 2:18 AM, Yannick FERTRE >> wrote: >>> On 02/21/2017 03:07 PM, Rob Herring wrote: On Mon, Feb 20, 2017 at 5:01 AM,

[PATCH v3 1/4] gpu: ipu-v3: remove IRQ dance on DC channel disable

From: Lucas Stach This has never worked properly, as the IRQ got retriggered immediately on unmask. Remove the IRQ wait dance, as it is apparently safe to disable the DC channel at any point in time. Signed-off-by: Lucas Stach Signed-off-by:

[PATCH v3 2/4] gpu: ipu-v3: add unsynchronised DP channel disabling

When disabling the foreground DP channel during a modeset, the DC is already disabled without waiting for end of frame. There is no reason to wait for a frame boundary before updating the DP registers in that case. Add support to apply updates immediately. No functional changes, yet.

[PATCH v3 0/4] Fix DP busy wait and defer disabling overlay plane

Hi, third try. This time I've removed the drm_atomic_helper_wait_for_vblanks call from imx_drm_commit_tail unless there are planes to be disabled. Also the drm_atomic_helper_cleanup_planes call is removed, as that is a no-op for CMA framebuffer based drivers. This series fixes an issue with the

[PATCH v3 3/4] drm/imx: don't wait for vblank and stop calling cleanup_planes in commit_tail

drm_atomic_helper_cleanup_planes only calls the cleanup_fb plane helpers, which we don't implement as a CMA framebuffer based driver. There is no reason to wait for vblanks in commit_tail only to do nothing afterwards. Signed-off-by: Philipp Zabel --- Changes since v2: -

[PATCH v3 4/4] drm/imx: add deferred plane disabling

The DP (display processor) channel disable code tried to busy wait for the DP sync flow end interrupt status bit when disabling the partial plane without a full modeset. That never worked reliably, and it was disabled completely by the recent "gpu: ipu-v3: remove IRQ dance on DC channel disable"

[PATCH v2 4/4] drm/imx: ipuv3-plane: add support for separate alpha planes

The IPUv3 can read 8-bit alpha values from a separate plane buffer using a companion IDMAC channel driven by the Alpha Transparency Controller (ATC) for the graphics channels. The conditional read mechanism allows to reduce memory bandwidth by skipping reads of color data for completely

[PATCH v2 1/4] drm: add RGB formats with separate alpha plane

Some hardware can read the alpha components separately and then conditionally fetch color components only for non-zero alpha values. This patch adds fourcc definitions for two-plane RGB formats with an 8-bit alpha channel on a second plane. Signed-off-by: Philipp Zabel

[PATCH v2 3/4] drm/imx: extend drm_plane_state_to_eba for separate channel support

Allow to calculate EBA for planes other than plane 0. This is in preparation for the following patch, which adds support for separate alpha planes. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/imx/ipuv3-plane.c | 16 1 file changed, 8 insertions(+),

[PATCH v2 2/4] gpu: ipu-v3: add support for separate alpha channels

The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels. This allows to reduce memory bandwidth via a conditional read mechanism or to support planar YUV formats with alpha transparency. Signed-off-by:

Re: [Nouveau] [PATCH 0/3] gpu: drm: Convert printk(KERN_ to pr_

On Tue, Feb 28, 2017 at 04:55:51AM -0800, Joe Perches wrote: > Broken up for Daniel Vetter Thanks, I applied the core patch (needed a minor resolution in drm_edid.c). I'll wait with the driver patch for a few more acks maybe, and leave the 2 other patches to Alex for picking up directly. Thanks,

Re: [RESEND PATCH 00/14] QXL atomic modesetting

On Mo, 2017-02-27 at 17:43 -0300, Gabriel Krisman Bertazi wrote: > Hi, > > This is a resend of the qxl atomic modesetting patchset to include the > reviewed-by tags from Gustavo and rebase on top of the tip of drm-misc-next. > > This series implements support for Atomic Modesetting in the QXL

Re: [maintainers-tools] dim: Clarify how to proceed when adding drm-xxx remotes

On Tue, Feb 28, 2017 at 12:50:57PM +, Daniel Stone wrote: > Hi, > > On 28 February 2017 at 12:36, Boris Brezillon > wrote: > > @@ -54,6 +54,13 @@ This will also check out the latest maintainer-tools > > branches, so please replace > > the dim you just

Re: [PATCH v2 3/4] drm/imx: call drm_atomic_helper_commit_hw_done after drm_atomic_helper_wait_for_vblanks

On Tue, 2017-02-28 at 12:45 +0100, Daniel Vetter wrote: > On Tue, Feb 28, 2017 at 10:59:54AM +0100, Philipp Zabel wrote: > > On Mon, 2017-02-27 at 17:25 +0100, Daniel Vetter wrote: > > > On Mon, Feb 27, 2017 at 02:14:57PM +0100, Philipp Zabel wrote: > > > > Disabling planes will consist of two

Re: ABI navigator for libdrm

27.02.2017, 15:30, "Rob Clark":> On Mon, Feb 27, 2017 at 1:41 AM, Andrey Ponomarenko:>>  26.02.2017, 22:15, "Daniel Vetter":>>>  On Sun, Feb 26, 2017 at 10:51 AM, Andrey Ponomarenko:   Hello,   I'd like to present the ABI Navigator project to search for binary symbols (functions,

[PATCH v2 09/10] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)

According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON on enable for cmd-mode, just like we already call their counterparts on disable. Note: untested, my panel is a vid-mode panel. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe

[PATCH v2 10/10] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode

For v3 VBTs in vid-mode the delays are part of the VBT sequences, so we should not also delay ourselves otherwise we get double delays. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe --- drivers/gpu/drm/i915/intel_dsi.c | 19

[PATCH v2 08/10] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable

For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF, v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop. Signed-off-by: Hans de Goede --- Changes in v2: -Only call MIPI_SEQ_TEAR_OFF in cmd mode --- drivers/gpu/drm/i915/intel_dsi.c | 2 ++ 1

[PATCH v2 05/10] drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()

Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready state (LP-11), this is the sequence in which things should be done according to the spec. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe --- drivers/gpu/drm/i915/intel_dsi.c |

[PATCH v2 06/10] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as we call intel_panel_enable_backlight() / intel_panel_disable_backlight(). Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe --- Changes in v2: -Drop meaningless code-comments

[PATCH v2 07/10] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order

According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN first. Since the v2 order has known issues, we use the v3 order everywhere, add a comment documenting this. Signed-off-by: Hans de Goede

[PATCH v2 02/10] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON

intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET, will always be called at some point before intel_dsi_pre_enable() making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant. In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes against the VBT spec.

[PATCH v2 03/10] drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls

Now that we are no longer bound to the drm_panel_ callbacks, call MIPI_SEQ_POWER_ON/OFF at the proper place. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe --- drivers/gpu/drm/i915/intel_dsi.c | 10 -- 1 file changed, 4 insertions(+),

[PATCH v2 04/10] drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable

Move the DPOunit clock gate workaround to directly after the PLL enable. The exact location of the workaround does not matter and there are 2 reasons to group it with the PLL enable: 1) This moves it out of the middle of the init sequence from the spec, making it easier to follow the init

  1   2   >