[PATCH] 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. v2: Spelling and clarifications (Eric). v3: Implement

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

On Wed, Mar 01, 2017 at 02:42:02PM -0300, Gabriel Krisman Bertazi wrote: > Daniel Vetter writes: > > > I've spent quite some time trying to beat DOT into submission, this is the > > best I can do. The FIXME really is just a hint for someone with more clue > > to maybe make it

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

On Wed, Mar 01, 2017 at 12:56:36PM -0300, Gabriel Krisman Bertazi wrote: > Daniel Vetter writes: > > Hi Daniel, > > > +if dst_fname: > > +name = dst_fname[len(out_dir) + 1:] > > +# the builder needs not to copy one more time, so pop it if exists. > >

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

On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote: > 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

Re: [PATCH] drm: qxl: Don't clean up uninitialized fbdev framebuffer

On Wed, Mar 01, 2017 at 06:50:08PM -0300, Gabriel Krisman Bertazi wrote: > Daniel Vetter writes: > > Hi Daniel, thanks again for your review. > > > Hm, I bit silly that we need #ifdef here, all this stuff is meant to Just > > Work. Can't we just fix the oops with suitable

Re: [PATCH v3 06/13] drm: bridge: Add LVDS encoder driver

On Thu, Mar 02, 2017 at 02:30:09AM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday 04 Jan 2017 17:13:23 Laurent Pinchart wrote: > > On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote: > > > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote: > > >> On Wednesday 04

Re: [PULL] topic/designware-baytrail for 4.12

On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote: > Hi all, > > topic/designware-baytrail-2017-03-01: > Baytrail PMIC vs. PMU race fixes from Hans de Goede > > I opted to put all the patches for all subsystems into the topic branches, > so that if needed, each subsystem can apply

[drm-intel:topic/designware-baytrail 2/12] arch/x86/include/asm/iosf_mbi.h:137:55: warning: 'struct notifier_block' declared inside parameter list

tree: git://anongit.freedesktop.org/drm-intel topic/designware-baytrail head: ca9b131b63aaf21419725bcf90497877d6bf6271 commit: 26363e10f680194a71c8d4287c8e2886ed539c4e [2/12] x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier config: i386-randconfig-c0-03021134 (attached as .config)

Re: [PATCH v5 5/6] drm/i915: enable scrambling

Regards Shashank On 3/1/2017 8:41 PM, Ville Syrjälä wrote: On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote: Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher clocks,

Re: [PATCH v5 4/6] drm/edid: detect SCDC support in HF-VSDB

Regards Shashank On 3/1/2017 8:28 PM, Ville Syrjälä wrote: On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote: This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced

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

On 02/28/2017 06:58 PM, Krzysztof Kozlowski wrote: 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

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 Michel Dänzer changed: What|Removed |Added Product|DRI |Mesa

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 Michel Dänzer changed: What|Removed |Added Attachment #130009|text/x-log |text/plain

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 Michel Dänzer changed: What|Removed |Added Attachment #130008|text/x-log |text/plain

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 Michel Dänzer changed: What|Removed |Added Attachment #130018|text/x-log |text/plain

Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

Hi Laurent, On 01-03-2017 11:09, Laurent Pinchart wrote: > Hi Jose, > > On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote: >> On 05-01-2017 12:29, Laurent Pinchart wrote: >>> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote: On 20-12-2016 11:45, Russell King - ARM Linux wrote: > On Tue,

Re: [PATCH] drm/atmel-hlcdc: Fix suspend/resume implementation

Hi, On Wed, Mar 01, 2017 at 01:31:01PM +0100, Boris Brezillon wrote: > The current suspend resume implementation is assuming register values are > kept when entering suspend, which is no longer the case with the > suspend-to-RAM on the sama5d2. > > While at it, switch to the generic

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

On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote: [...] > > +static const struct i2c_device_id stdp2690_ge_b850v3_fw_i2c_table[] = { > > + {"stdp2690_ge_fw", 0}, > > + {}, > > +}; > > +MODULE_DEVICE_TABLE(i2c, stdp2690_ge_b850v3_fw_i2c_table); > > + > > +static const struct

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

On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote: 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

[RFC PATCH 3/3] drm: rcar-du: Register a completion callback with VSP1

Updating the state in a running VSP1 requires two interrupts from the VSP. Initially, the updated state will be committed - but only after the VSP1 has completed processing it's current frame will the new state be taken into account. As such, the committed state will only be 'completed' after an

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

Hi Archit, Thank you for the review! On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote: > > > On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote: > > The video processing pipeline on the second output on the GE B850v3: > > > > Host -> LVDS|--(STDP4028)--|DP ->

[RFC PATCH 1/3] v4l: vsp1: Register pipe with output WPF

The DRM object does not register the pipe with the WPF object. This is used internally throughout the driver as a means of accessing the pipe. As such this breaks operations which require access to the pipe from WPF interrupts. Register the pipe inside the WPF object after it has been declared as

[RFC PATCH 2/3] v4l: vsp1: extend VSP1 module API to allow DRM callback registration

To be able to perform page flips in DRM without flicker we need to be able to notify the rcar-du module when the VSP has completed its processing. To synchronise the page flip events for userspace, we move the required event through the VSP to track the data flow. When the frame is completed, the

[RFC PATCH 0/3] RCAR-DU, VSP1: Prevent pre-emptive frame flips on VSP1-DRM pipelines

The RCAR-DU utilises a running VSPD pipeline to perform processing for the display pipeline. Changes to this pipeline are performed with an atomic flush operation which updates the state in the VSPD. Due to the way the running pipeline is operated, any flush operation has an implicit latency of

Re: [PATCH v3 06/13] drm: bridge: Add LVDS encoder driver

Hi Daniel, On Wednesday 04 Jan 2017 17:13:23 Laurent Pinchart wrote: > On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote: > > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote: > >> On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote: > >>> Hm, something like

Re: [PATCH 5/5] drm/amd/display: Allow HDMI capabilities over DVI connector (DC)

On 2017-02-24 07:14 PM, Jeff Smith wrote: Signed-off-by: Jeff Smith --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c

Re: [PATCH 1/3] gpu: drm: amd/radeon: 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 Applied. Thanks! Alex > --- >

Re: [PATCH 4/5] drm/amd/display: Add HDMI Stereo 3D (DC) support

On 2017-02-24 07:14 PM, Jeff Smith wrote: Signed-off-by: Jeff Smith --- .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 32 -- .../display/dc/dce110/dce110_timing_generator.c| 4 --- 2 files changed, 23 insertions(+), 13 deletions(-) diff

Re: [PATCH 1/2] drm: Use pr_cont where appropriate

On Mon, Feb 27, 2017 at 8:31 PM, Joe Perches wrote: > Using 'printk("\n")' is not preferred anymore and > using printk to continue logging messages now produces > multiple line logging output unless the continuations > use KERN_CONT. > > Convert these uses to appropriately use

Re: [PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup

Den 01.03.2017 15.31, skrev Daniel Vetter: On Fri, Jan 27, 2017 at 03:29:29PM +0100, Daniel Vetter wrote: On Fri, Jan 27, 2017 at 03:23:43PM +0100, Noralf Trønnes wrote: Den 27.01.2017 08.49, skrev Daniel Vetter: On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote: This patchset

Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

Hi Jose, On Wednesday 01 Mar 2017 16:25:46 Jose Abreu wrote: > On 01-03-2017 11:09, Laurent Pinchart wrote: > > On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote: > >> On 05-01-2017 12:29, Laurent Pinchart wrote: > >>> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote: > On 20-12-2016 11:45,

[PATCH v4 9/9] drm: bridge: dw-hdmi: Switch to regmap for register access

From: Neil Armstrong The Synopsys Designware HDMI TX Controller does not enforce register access on platforms instanciating it. The current driver supports two different types of memory-mapped flat register access, but in order to support the Amlogic Meson SoCs

[PATCH v4 8/9] drm: bridge: dw-hdmi: Remove device type from platform data

From: Kieran Bingham The device type isn't used anymore now that workarounds and PHY-specific operations are performed based on version information read at runtime. Remove it. Signed-off-by: Kieran Bingham

[PATCH v4 0/9] drm: bridge: dw-hdmi: Refactor PHY support

Hello, This patch series refactors all the PHY handling code in order to allow support of vendor PHYs and Synopsys DWC HDMI 2.0 TX PHYs. The series starts with a few cleanups and small fixes. Patch 1/9 just removes unused code, patch 2/9 moves the color converter code out of the PHY configure

[PATCH v4 7/9] drm: bridge: dw-hdmi: Add support for custom PHY configuration

From: Kieran Bingham The DWC HDMI TX controller interfaces with a companion PHY. While Synopsys provides multiple standard PHYs, SoC vendors can also integrate a custom PHY. Modularize PHY configuration to support vendor PHYs through platform data. The

[PATCH v4 5/9] drm: bridge: dw-hdmi: Fix the PHY power up sequence

When powering the PHY up we need to wait for the PLL to lock. This is done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register (interrupt-based wait could be implemented as well but is likely overkill). The bit is asserted when the PLL locks, but the current code incorrectly waits for

[PATCH v4 6/9] drm: bridge: dw-hdmi: Create PHY operations

The HDMI TX controller support different PHYs whose programming interface can vary significantly, especially with vendor PHYs that are not provided by Synopsys. To support them, create a PHY operation structure that can be provided by the platform glue layer. The existing PHY handling code

[PATCH v4 2/9] drm: bridge: dw-hdmi: Move CSC configuration out of PHY code

The color space converter isn't part of the PHY, move its configuration out of PHY code. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++--- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git

[PATCH v4 4/9] drm: bridge: dw-hdmi: Fix the PHY power down sequence

The PHY requires us to wait for the PHY to switch to low power mode after deasserting TXPWRON and before asserting PDDQ in the power down sequence, otherwise power down will fail. The PHY power down can be monitored though the TX_READY bit, available through I2C in the PHY registers, or the

[PATCH v4 3/9] drm: bridge: dw-hdmi: Enable CSC even for DVI

From: Neil Armstrong If the input pixel format is not RGB, the CSC must be enabled in order to provide valid pixel to DVI sinks. This patch removes the hdmi only dependency on the CSC enabling. Reviewed-by: Jose Abreu Reviewed-by: Laurent Pinchart

[PATCH v4 1/9] drm: bridge: dw-hdmi: Remove unused functions

Most of the hdmi_phy_test_*() functions are unused. Remove them. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/dw-hdmi.c | 26 -- 1 file changed, 26 deletions(-) diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c

[PATCH] drm: qxl: Don't clean up uninitialized fbdev framebuffer

Daniel Vetter writes: Hi Daniel, thanks again for your review. > Hm, I bit silly that we need #ifdef here, all this stuff is meant to Just > Work. Can't we just fix the oops with suitable checks in the fini paths > instead? Heh. I expected someone would bring up this

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

Hi Maxime, On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote: > 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

Re: [PATCH v2] drm: Rely on mode_config data for fb_helper initialization

On Wed, Mar 01, 2017 at 04:01:05PM -0300, Gabriel Krisman Bertazi wrote: > Daniel Vetter writes: > > > You forgot to update the kernel-doc, building them now generates new > > warnings. Please fix in a follow-up patch. > > Hm, that´s a bummer. Please take the fix below.

Re: [PATCH v4 00/23] drm/rockchip: MIPI fixes & improvements

On Fri, Feb 24, 2017 at 12:54:43PM +, John Keeping wrote: > This version is mostly small changes in response to review comments from > Sean and Chris, the details are in the individual patches. > > I decided to drop the final patch which adds support for MIPI read > commands because I'm not

Re: [RESEND PATCH v7 0/7] Rockchip dw-mipi-dsi driver

On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote: > Hi all > > [Resend this v7 version series, since there are 5 mails have gone missing, > last > week] > > This version does not change the existing v6 patches, just to add the > "bandwidth fix" patch back, since we really need it. >

Re: [PATCH v2] drm: Rely on mode_config data for fb_helper initialization

Daniel Vetter writes: > You forgot to update the kernel-doc, building them now generates new > warnings. Please fix in a follow-up patch. Hm, that´s a bummer. Please take the fix below. Thanks for spotting. -- >8 -- Subject: [PATCH] drm: Update drm_fbdev_cma_init

[PATCH 2/2 RESEND] drm/vc4: Fix OOPSes from trying to cache a partially constructed BO.

If a CMA allocation failed, the partially constructed BO would be unreferenced through the normal path, and we might choose to put it in the BO cache. If we then reused it before it expired from the cache, the kernel would OOPS. Signed-off-by: Eric Anholt Fixes: c826a6e10644

[PATCH 1/2 RESEND] drm/vc4: Fulfill user BO creation requests from the kernel BO cache.

The from_cache flag was actually "the BO is invisible to userspace", so we can repurpose it to just zero out a cached BO and return it to userspace. Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by -1.44989% +/- 0.862891% (n=28, 1 outlier removed from each that appeared to be other

Re: [PATCH 0/4] some qxl fixes and cleanups.

Gerd Hoffmann writes: > Hi, > > This little series has some fixes and cleanups for the qxl driver. > Based on drm-misc-next branch. > Hi Gerd, Please add a reviewed-by for series. Reviewed-by: Gabriel Krisman Bertazi > cheers, > Gerd > > Gerd

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

On Wed, Mar 01, 2017 at 09:50:56AM -0800, Ben Widawsky wrote: > On 17-03-01 12:51:17, Ville Syrjälä wrote: > >On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote: > >> On 17-02-28 12:18:39, Jason Ekstrand wrote: > > > >> >I've said it before but reading through Ben's patches again make me

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #10 from Julien Isorce --- Created attachment 130018 --> https://bugs.freedesktop.org/attachment.cgi?id=130018=edit output of max-texture-size2 test with attached patch for mesa -- You are receiving this

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #9 from Julien Isorce --- Created attachment 130016 --> https://bugs.freedesktop.org/attachment.cgi?id=130016=edit patch for mesa to translate the radeonsi printf ENOMEM to a proper GL_OUT_OF_MEMORY --

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

On 17-03-01 12:51:17, Ville Syrjälä wrote: On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote: On 17-02-28 12:18:39, Jason Ekstrand wrote: >I've said it before but reading through Ben's patches again make me want to >be peskier about it. I would really like the UABI to treat the

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #8 from Julien Isorce --- Created attachment 130015 --> https://bugs.freedesktop.org/attachment.cgi?id=130015=edit output of max-texture-size2 test with USE_FENCE workaround -- You are receiving this

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #7 from Julien Isorce --- Created attachment 130014 --> https://bugs.freedesktop.org/attachment.cgi?id=130014=edit output of max-texture-size2 test with MESA_VERBOSE and R600_DEBUG -- You are receiving

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #6 from Julien Isorce --- Created attachment 130013 --> https://bugs.freedesktop.org/attachment.cgi?id=130013=edit output of max-texture-size2 test with MESA_VERBOSE -- You are receiving this mail

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #5 from Julien Isorce --- Created attachment 130012 --> https://bugs.freedesktop.org/attachment.cgi?id=130012=edit default output of max-texture-size2 test -- You are receiving this mail because: You are

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #4 from Julien Isorce --- Created attachment 130011 --> https://bugs.freedesktop.org/attachment.cgi?id=130011=edit max-texture-size2 backtrace untill ENOMEM -- You are receiving this mail because: You

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #3 from Julien Isorce --- Created attachment 130009 --> https://bugs.freedesktop.org/attachment.cgi?id=130009=edit Xorg.log -- You are receiving this mail because: You are the assignee for the

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #2 from Julien Isorce --- Created attachment 130008 --> https://bugs.freedesktop.org/attachment.cgi?id=130008=edit dmesg -- You are receiving this mail because: You are the assignee for the

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 --- Comment #1 from Julien Isorce --- Created attachment 130006 --> https://bugs.freedesktop.org/attachment.cgi?id=130006=edit lspic -s -v -- You are receiving this mail because: You are the assignee for the

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

https://bugs.freedesktop.org/show_bug.cgi?id=100024 Bug ID: 100024 Summary: [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2 Product: DRI Version: XOrg git Hardware:

Re: [PATCH] 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 6/6] drm/doc: atomic overview, with graph

Daniel Vetter writes: > I've spent quite some time trying to beat DOT into submission, this is the > best I can do. The FIXME really is just a hint for someone with more clue > to maybe make it better, or if not possible at all, what would look better > when doing a proper

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

Daniel Vetter writes: > Resulted in confusion a few times in the past. > Reviewed-by: Gabriel Krisman Bertazi -- Gabriel Krisman Bertazi ___ dri-devel mailing list dri-devel@lists.freedesktop.org

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

Daniel Vetter writes: > Oh, the shiny and pretties! > Very nice! Reviewed-by: Gabriel Krisman Bertazi -- Gabriel Krisman Bertazi ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

On Wed, Mar 01, 2017 at 04:07:02PM +0200, Ville Syrjälä wrote: > On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote: > > Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all > > 1.1. > > > > When a sink that supports deep color is connected to the output, the > >

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

Daniel Vetter writes: Hi Daniel, > +if dst_fname: > +name = dst_fname[len(out_dir) + 1:] > +# the builder needs not to copy one more time, so pop it if exists. > +translator.builder.images.pop(img_node['uri'], None) > +img_node['uri']

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement Link Rate fallback on Link training failure

On Fri, Dec 16, 2016 at 12:29:07PM +0200, Jani Nikula wrote: > From: Manasi Navare > > If link training at a link rate optimal for a particular > mode fails during modeset's atomic commit phase, then we > let the modeset complete and then retry. We save the link rate >

Re: [PATCH v5 5/6] drm/i915: enable scrambling

On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the

Re: [Intel-gfx] [PATCH] drm: Fix the kernel doc warning for drm_link_status

On Wed, Mar 01, 2017 at 06:45:10AM -0800, Manasi Navare wrote: > This fixes the kernel doc warning that was introduced in > the 'commit 40ee6fbef75fe6 ("drm: Add a new connector > atomic property for link status")'. Description has > been added for the enum values. > > Signed-off-by: Manasi

Re: [PATCH] drm: virtio: use kmem_cache

On Wed, Mar 01, 2017 at 03:09:08PM +0100, Gerd Hoffmann wrote: > Just use kmem_cache instead of rolling > our own, limited implementation. > > Signed-off-by: Gerd Hoffmann Looks very reasonable. Reviewed-by: Daniel Vetter > --- >

Re: [PATCH v5 4/6] drm/edid: detect SCDC support in HF-VSDB

On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote: > This patch does following: > - Adds a new structure (drm_hdmi_info) in drm_display_info. > This structure will be used to save and indicate if sink > supports advanced HDMI 2.0 features > - Adds another structure drm_scdc

[PATCH] drm: Fix the kernel doc warning for drm_link_status

This fixes the kernel doc warning that was introduced in the 'commit 40ee6fbef75fe6 ("drm: Add a new connector atomic property for link status")'. Description has been added for the enum values. Signed-off-by: Manasi Navare Cc: Jani Nikula

Re: [PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup

On Fri, Jan 27, 2017 at 03:29:29PM +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 03:23:43PM +0100, Noralf Trønnes wrote: > > > > Den 27.01.2017 08.49, skrev Daniel Vetter: > > > On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote: > > > > This patchset removes the need for

Re: [PATCH] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote: > Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all > 1.1. > > When a sink that supports deep color is connected to the output, the > receiver will send EDIDs that advertise this capability, even if it > isn't

[PATCH] drm: virtio: use kmem_cache

Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +-- drivers/gpu/drm/virtio/virtgpu_vq.c | 57 +++- 2 files changed, 11 insertions(+), 50

Re: [PATCH] drm/atmel-hlcdc: Fix suspend/resume implementation

On Wed, Mar 01, 2017 at 01:31:01PM +0100, Boris Brezillon wrote: > The current suspend resume implementation is assuming register values are > kept when entering suspend, which is no longer the case with the > suspend-to-RAM on the sama5d2. > > While at it, switch to the generic infrastructure to

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: Shawn Guo > Signed-off-by: Daniel Vetter

[Bug 99784] AMD 7470m When VGA plugged into laptop, only one monitor working at a time

https://bugs.freedesktop.org/show_bug.cgi?id=99784 --- Comment #6 from lazane...@gmail.com --- Problem persists with DRM 2.49.0 / 4.10.1-041001-lowlatency, LLVM 3.9.1 -- You are receiving this mail because: You are the assignee for the bug.___

[PATCH] drm/atmel-hlcdc: Fix suspend/resume implementation

The current suspend resume implementation is assuming register values are kept when entering suspend, which is no longer the case with the suspend-to-RAM on the sama5d2. While at it, switch to the generic infrastructure to enter suspend mode (drm_atomic_helper_suspend/resume()). Signed-off-by:

[Bug 99450] [amdgpu] Payday 2 visual glitches on some models

https://bugs.freedesktop.org/show_bug.cgi?id=99450 Hugo Posnic changed: What|Removed |Added Resolution|--- |FIXED

Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

Hi Jose, On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote: > On 05-01-2017 12:29, Laurent Pinchart wrote: > > On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote: > >> On 20-12-2016 11:45, Russell King - ARM Linux wrote: > >>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote: >

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

On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote: > On 17-02-28 12:18:39, Jason Ekstrand wrote: > >I've said it before but reading through Ben's patches again make me want to > >be peskier about it. I would really like the UABI to treat the CCS as if > >it's Y-tiled with a tile size

[PULL] topic/designware-baytrail for 4.12

Hi all, topic/designware-baytrail-2017-03-01: Baytrail PMIC vs. PMU race fixes from Hans de Goede I opted to put all the patches for all subsystems into the topic branches, so that if needed, each subsystem can apply refactorings to the entire thing. Which might be needed since we're very early

Re: [PATCH v2] drm: Rely on mode_config data for fb_helper initialization

On Thu, Feb 02, 2017 at 02:26:40PM -0200, Gabriel Krisman Bertazi wrote: > Instead of receiving the num_crts as a parameter, we can read it > directly from the mode_config structure. I audited the drivers that > invoke this helper and I believe all of them initialize the mode_config > struct

Re: [PATCH 1/2] drm: Add a new connector atomic property for link status

On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote: > /** > + * enum drm_link_status - connector's link_status property value > + * > + * This enum is used as the connector's link status property value. > + * It is set to the values defined in uapi. > + */ > +enum drm_link_status { > +

[PATCH] drm/exynos: kill mode_set_nofb callback

All Exynos CRTCs are fully configured by .enable callback. The only users of mode_set_nofb actually did nothing in their callbacks - they immediately returned because devices were in suspend state - mode_set_nofb is always called on disabled device. Signed-off-by: Andrzej Hajda

[PATCH 2/4] qxl: limit monitor config read retries

When reading the monitor config fails, don't retry forever. If it fails ten times in a row just give up to avoid the driver hangs. Also add a small delay after each attempt, so the host has a chance to complete a partial update. Signed-off-by: Gerd Hoffmann ---

[PATCH 3/4] qxl: read monitors config at boot

Try to read the client monitors config at driver load time, even without explicit notification. So in case that info was filled before the driver loaded and we've missed the notifications because of that the settings will still be used. With that place we now have to take care to properly handle

[PATCH 4/4] qxl: fix qxl_conn_get_modes

Call qxl_add_monitors_config_modes() unconditionally. Do all sanity checks in that function. Fix sanity checks. monitors_config is the current monitor configuration, whereas client_monitors_config is the configuration requested by the spice client. So when filling the mode list, based on the

[PATCH 0/4] some qxl fixes and cleanups.

Hi, This little series has some fixes and cleanups for the qxl driver. Based on drm-misc-next branch. cheers, Gerd Gerd Hoffmann (4): qxl: drop mode_info.modes & related code. qxl: limit monitor config read retries qxl: read monitors config at boot qxl: fix qxl_conn_get_modes

[PATCH 1/4] qxl: drop mode_info.modes & related code.

very old qxl hardware revisions (predating qxl ksm support by a few years) supported a fixed list of video modes only. The list is still provided by the virtual hardware, for backward compatibility reasons. The qxl kms driver never ever looks at it, except for dumping it to the kernel log at

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

Hi Maarten, Thank you for the resend. For the whole series, Tested-by: Laurent Pinchart On Wednesday 01 Mar 2017 10:21:26 Maarten Lankhorst wrote: > There are new iterator macros that annotate whether the new or old > state should be used. This is better

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

On Tue, Feb 28, 2017 at 03:48:47PM -0800, Eric Anholt wrote: > 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,

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

https://bugzilla.kernel.org/show_bug.cgi?id=193341 stefan.ko...@um.si changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

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

On Wed, 01 Mar 2017, Daniel Vetter wrote: > On Tue, Feb 28, 2017 at 06:59:52PM +, Joan Jani wrote: >> 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

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

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 drm_atomic_helper_update_legacy_modeset_state. Changes since v2: - Use the correct state in

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

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, also rename the variables from $obj_state to (old,new)_$obj_state as well. Changes since v1: - Use

  1   2   >