[PATCH 01/10] drm/amd-kfd: Clean up inline handling

On Tue, Jun 21, 2016 at 12:10 PM, Daniel Vetter wrote: > - inline functions need to be static inline, otherwise gcc can opt to > not inline and the linker gets unhappy. > - no forward decls for inline functions, just include the right headers. > > Cc: Oded Gabbay > Cc: Ben Goz >

[PATCH 2/3] drm/vgem: Fix mmaping

On Sat, Jun 18, 2016 at 04:20:48PM +0100, Chris Wilson wrote: > The vGEM mmap code has bitrotted slightly and now immediately BUGs. > Since vGEM was last updated, there are new core GEM facilities to > provide more common functions, so let's use those here. Bugzilla:

[PATCH v4 0/8] iommu/rockchip: Fix bugs and enable on ARM64

Hi Joerg, On Tue, Jun 21, 2016 at 6:17 PM, Joerg Roedel wrote: > > On Tue, Jun 21, 2016 at 01:34:33PM +0900, Tomasz Figa wrote: > > This series intends mostly to enable support for ARM64 architecture > > in the rockchip-iommu driver. On the way to do so, some bugs are also > > fixed. > > > > The

[PATCH v3 3/3] drm: sti: rework init sequence

On Tue, Jun 21, 2016 at 03:09:40PM +0200, Benjamin Gaignard wrote: > Use drm_dev_alloc() and drm_dev_register() instead of .load() > To simplify init sequence only create fbdev when requested > in output_poll_changed(). > > version 2: > remove call to drm_connector_unregister_all() and >

[PATCH v4 4/4] drm/i915: Enable polling when we don't have hpd

On Tue, Jun 21, 2016 at 02:18:35PM -0400, Lyude wrote: > Unfortunately, there's two situations where we lose hpd right now: > - Runtime suspend > - When we've shut off all of the power wells on Valleyview/Cherryview > > While it would be nice if this didn't cause issues, this has the > ability to

[PATCH 01/10] drm/amd-kfd: Clean up inline handling

On Tue, Jun 21, 2016 at 10:11:13PM +0300, Oded Gabbay wrote: > On Tue, Jun 21, 2016 at 12:10 PM, Daniel Vetter > wrote: > > - inline functions need to be static inline, otherwise gcc can opt to > > not inline and the linker gets unhappy. > > - no forward decls for inline functions, just

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

Hi, On 6/20/2016 12:44 PM, Nicolas Boichat wrote: > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > that has an internal microcontroller. > > The only reason a Linux kernel driver is necessary is to reject > resolutions that require more bandwidth than what is available on

[PATCH v3 0/10]

On 6/14/2016 5:15 PM, Yakir Yang wrote: > RK3399 and RK3288 shared the same eDP IP controller, only some light > difference with VOP configure and GRF configure. > > Also same misc fix to analogix_dp driver: > - Hotplug invalid which report by Dan Carpenter > - Make panel detect to an optional

[Bug 96622] [radeonsi] "Dreamfall Chapters: The longest Journey" shows visual corruption

77449 [Bug 77449] Tracker bug for all bugs related to Steam titles -- 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/20160621/82a96ca0/attachment-0001.html>

[Bug 96602] [radeonsi] Dreamfall Chapters: one shader fails to compile, minor visual corruption

p.org/archives/dri-devel/attachments/20160621/c33187bf/attachment.html>

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote: > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote: > > Cc: Ville > > > > On Mon, 20 Jun 2016, James Bottomley < > > James.Bottomley at HansenPartnership.com> wrote: > > > OK, my candidate bad commit is this one: > > > > > >

[Bug 94231] Problems compiling libdrm since glibc 2.23

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

[Bug 94231] Problems compiling libdrm since glibc 2.23

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

[PATCH 1/2] drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"

Any news on this one? Thanks a bunch, -mario On 06/14/2016 04:12 PM, Mario Kleiner wrote: > On 06/14/2016 01:05 PM, Daniel Vetter wrote: >> On Thu, May 26, 2016 at 4:39 PM, Mario Kleiner >> wrote: >>> This reverts commit 013dd9e03872 >>> ("drm/i915/dp: fall back to 18 bpp when sink capability

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

rm_crtc_state { > struct drm_atomic_state *state; > }; > > +struct drm_crtc_crc_entry { > + uint32_t frame; > + uint32_t crc[5]; > +}; > + > +#define DRM_CRTC_CRC_ENTRIES_NR 128 > +struct drm_crtc_crc { > + spinlock_t lock; > + const char *source; > + bool opened;/* exclusive access to the result file */ You could probably have done this with an atomic and avoid the spin lock for exclusive access, but it's probably not worth it. > + struct drm_crtc_crc_entry *entries; > + int head, tail; unsigned int? > + wait_queue_head_t wq; > + struct dentry **debugfs_entries; > +}; > + > /** > * struct drm_crtc_funcs - control CRTCs for a given device > * > @@ -704,6 +720,29 @@ struct drm_crtc_funcs { > const struct drm_crtc_state *state, > struct drm_property *property, > uint64_t *val); > + > + /** > + * @set_crc_source: > + * > + * Changes the source of CRC checksums of frames at the request of > + * userspace, typically for testing purposes. The sources available are > + * specific of each driver and a %NULL value indicates that CRC > + * generation is to be switched off. Perhaps also mention that "none" is an alias for NULL? > + * > + * When CRC generation is enabled, the driver should call > + * drm_crtc_add_crc_entry() at each frame, providing any information > + * that characterizes the frame contents in the crcN arguments, as > + * provided from the configured source. Drivers should accept a "auto" > + * source name that will select a default source for this CRTC. Would it be useful to provide some more aliases? "enable" and "on" for "auto", "disable" and "off" for "none"? Thierry -- 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/20160621/b8bdf25e/attachment-0001.sig>

[PATCH v6 4/4] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

[PATCH v6 3/4] drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the

[PATCH v6 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

[PATCH v6 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: stable at vger.kernel.org Cc: Ville Syrjälä Acked-by: Daniel Vetter Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_crt.c | 10 +- 1

[PATCH v6 0/4] Fixes for HPD

Latest version of: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html The only patch that's changed here is 4/4, the rest are just being sent so that they can be in one thread to make things easier for reviewers Lyude (4): drm/i915/vlv: Make intel_crt_reset() per-encoder

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote: > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote: > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote: > > > Cc: Ville > > > > > > On Mon, 20 Jun 2016, James Bottomley < > > > James.Bottomley at HansenPartnership.com>

[PATCH 1/2] drm/omap: dsi: Remove unused variable

ature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/d60c4892/attachment-0001.sig>

[PATCH v4 1/3] drm: Add callbacks for late registering

Like what has been done for connectors add callbacks on encoder, crtc and plane to let driver do actions after drm device registration. Correspondingly, add callbacks called before unregister drm device. version 2: add drm_modeset_register_all() and drm_modeset_unregister_all() to centralize all

[PATCH v4 1/3] drm: Add callbacks for late registering

On Tue, Jun 21, 2016 at 04:37:09PM +0200, Benjamin Gaignard wrote: > Like what has been done for connectors add callbacks on encoder, > crtc and plane to let driver do actions after drm device registration. > > Correspondingly, add callbacks called before unregister drm device. > > version 2: >

[PATCH 1/2] drm/omap: dsi: Remove unused variable

> ("drm/omap: fix unused variable warning in dsi & hdmi") in the mainline > (-rc3). Bah... that's what I get for not generating patches against linux-next. Thanks for letting me know. Thierry -- 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/20160621/78fda562/attachment.sig>

[PATCH 2/2] drm/omap: hdmi: Remove unused variable

From: Thierry Reding Commit 973999aa0140 ("drm/omap: Remove regulator API abuse") removed the only user of the local 'r' variable, which thus became unused. Signed-off-by: Thierry Reding --- drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 - 1 file changed, 1 deletion(-) diff

[PATCH 1/2] drm/omap: dsi: Remove unused variable

From: Thierry Reding Commit 973999aa0140 ("drm/omap: Remove regulator API abuse") removed the only user of the local 'r' variable, which thus became unused. Signed-off-by: Thierry Reding --- drivers/gpu/drm/omapdrm/dss/dsi.c | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH] drm/fsl-dcu: use drm_mode_config_cleanup on initialization errors

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/20160621/fa2c4b1a/attachment.sig>

[PATCH v4 0/8] iommu/rockchip: Fix bugs and enable on ARM64

On Tue, Jun 21, 2016 at 03:18:49PM +0200, Heiko Stübner wrote: > Am Dienstag, 21. Juni 2016, 14:54:35 schrieb Joerg Roedel: > > Hi Tomasz, > > > > On Tue, Jun 21, 2016 at 09:42:16PM +0900, Tomasz Figa wrote: > > > In simple words, DRM patches depend on IOMMU patches. > > > > > > More precisely:

[PATCH v3 1/3] drm: Add callbacks for late registering

On Tue, Jun 21, 2016 at 03:09:38PM +0200, Benjamin Gaignard wrote: > Like what has been done for connectors add callbacks on encoder, > crtc and plane to let driver do actions after drm device registration. > > Correspondingly, add callbacks called before unregister drm device. > > version 2: >

[PATCH] drm/hisilicon: add select HISI_KIRIN_DW_DSI

chment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/4934490a/attachment-0001.sig>

[PATCH] drm: mediatek: remove IOMMU_DMA select

eason why patchwork didn't include the commit message in the downloaded mbox. I've pieced it together manually and applied this to topic/drm-misc. Thanks, Thierry -- 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/20160621/563249f9/attachment.sig>

[PATCH v4 0/8] iommu/rockchip: Fix bugs and enable on ARM64

Am Dienstag, 21. Juni 2016, 14:54:35 schrieb Joerg Roedel: > Hi Tomasz, > > On Tue, Jun 21, 2016 at 09:42:16PM +0900, Tomasz Figa wrote: > > In simple words, DRM patches depend on IOMMU patches. > > > > More precisely: The IOMMU patches alone are supposed to not break > > anything. Same goes for

[PATCH v3 3/3] drm: sti: rework init sequence

Use drm_dev_alloc() and drm_dev_register() instead of .load() To simplify init sequence only create fbdev when requested in output_poll_changed(). version 2: remove call to drm_connector_unregister_all() and drm_dev_set_unique() Signed-off-by: Benjamin Gaignard ---

[PATCH v3 2/3] drm: sti: use late_register and early_unregister callbacks

Make sti driver use register callback to move debugfs initialization out of sub-components creation. This will allow to convert driver .load() to drm_dev_alloc() and drm_dev_register(). sti_compositor bring up 2 crtc but only one debugfs init is needed so use drm_crtc_index to do it on the first

[PATCH v3 1/3] drm: Add callbacks for late registering

Like what has been done for connectors add callbacks on encoder, crtc and plane to let driver do actions after drm device registration. Correspondingly, add callbacks called before unregister drm device. version 2: add drm_modeset_register_all() and drm_modeset_unregister_all() to centralize all

[PATCH v3 0/3] Add callbacks for late registering

version 3: Dont export functions if not needed. Fix uninitialized return variable. In case of error while calling late_register unwind what was aldeay done. drm_modeset_unregister_all() call callbacks in reverse order compare to drm_modeset_register_all() version 2: create functions

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

Hi, On 21 June 2016 at 14:57, Rainer Hochecker wrote: > Are you saying that this is outdated: > https://wayland.freedesktop.org/faq.html#heading_toc_j_12 > > A more subtle point is that libGL.so includes the GLX symbols, so linking to > that library will pull in all the X dependencies. This

[PATCH v4 0/8] iommu/rockchip: Fix bugs and enable on ARM64

Hi Tomasz, On Tue, Jun 21, 2016 at 09:42:16PM +0900, Tomasz Figa wrote: > In simple words, DRM patches depend on IOMMU patches. > > More precisely: The IOMMU patches alone are supposed to not break > anything. Same goes for the first DRM patch (7/8). Only second DRM > patch (8/8) depends on

[RFC PATCH v2] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

The 100c08 scratch page is mapped using dma_map_page() before the TTM layer has had a chance to set the DMA mask. This means we are still running with the default of 32 when this code executes, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the

[PATCH v2 7/7] Documentation/DocBook: remove gpu.tmpl

The gpu documentation has now been converted to reStructuredText files under Documentation/gpu. Remove the obsolete DocBook template. Also remove it from MAINTAINERS. Good riddance. Signed-off-by: Jani Nikula --- Documentation/DocBook/Makefile |2 +- Documentation/DocBook/gpu.tmpl | 3528

[PATCH v2 6/7] Documentation/gpu: split up mm, kms and kms-helpers from internals

Make the documents more manageable. Signed-off-by: Jani Nikula --- Documentation/gpu/drm-internals.rst | 1379 + Documentation/gpu/drm-kms-helpers.rst | 260 +++ Documentation/gpu/drm-kms.rst | 656 Documentation/gpu/drm-mm.rst

[PATCH v2 5/7] Documentation/gpu: convert the KMS properties table to CSV

Pandoc really did a bad job of converting the big KMS properties table to RST. Instead, put the properties into a separate plain text CSV file, and include it in the RST file. The generated output isn't very pretty, but at least the information is there, and it's stored in a format that's easier

[PATCH v2 4/7] Documentation/gpu: use recommended order of heading markers

While splitting the document up, the headings "shifted" from what pandoc generated. Use the following order for headings for consistency: == Document title == First = Second -- Third ~ Leave the lower level headings as they are; I think those are less

[PATCH v2 3/7] MAINTAINERS: add Documentation/gpu and Documentation/gpu/i915.rst

We'll want to keep an eye on what's going on in these files. Signed-off-by: Jani Nikula --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index cb88f724e07c..ce9c23dd02c6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3857,6 +3857,7 @@ F:

[PATCH v2 2/7] Documentation/gpu: split up the gpu documentation

Make the gpu documentation easier to manage by splitting to separate files. Again, this is just the split, no real edits. Signed-off-by: Jani Nikula --- Documentation/gpu/drm-internals.rst | 1998 ++ Documentation/gpu/drm-uapi.rst | 91 ++

[PATCH v2 1/7] Documentation/gpu: add new gpu.rst converted from DocBook gpu.tmpl

This is the first step towards converting the DocBook gpu.tmpl to Sphinx and reStructuredText, the new kernel documentation tool and markup. Use Jon's "cheesy conversion script" in Documentation/sphinx/tmplcvt to do the rough conversion. Do the manual edits in follow-up patches. Add a new

[PATCH v2 0/7] Documentation: convert DocBook gpu.tmpl to reStructuredText

Take two of [1], see the cover letter there. I've renamed drm-userland-interfaces.rst to drm-uapi.rst and added a further split-up patch of drm internals, extracting mm, kms and kms helpers to separate documents. BR, Jani. [1] http://mid.gmane.org/cover.1466434348.git.jani.nikula at intel.com

[PATCH] drm: Drop mode_config.mutex from get_resources ioctl

The only thing this protected is the connector_list, which is now protected differently. v2: Also remove comment (Chris). Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c

[PATCH] drm: Don't compute obj counts expensively in get_resources

Looping when we keep track of this is silly. Only thing we have to be careful is with sampling the connector count. To avoid inconsisten results due to gcc re-computing this, use READ_ONCE. And to avoid surprising userspace, make sure we don't copy more connectors than planned, and report the

[PULL] drm: atmel-hlcdc: Fixes for 4.7-rc5

Hi Dave, Here is a PR containing two fixes for 4.7. Regards, Boris The following changes since commit 58a2ab3af722550b2e4e8155eb08660e16c20ee6: drm: atmel-hlcdc: fix a NULL check (2016-06-01 15:59:36 +0200) are available in the git repository at: git at

[PATCH 02/10] drm: Don't compute obj counts expensively in get_resources

On Tue, Jun 21, 2016 at 10:48:08AM +0100, Chris Wilson wrote: > On Tue, Jun 21, 2016 at 11:10:27AM +0200, Daniel Vetter wrote: > > And to avoid surprising userspace, make sure we don't copy more > > connectors than planned, and report the actual number of connectors > > copied. That way any racing

[PATCH] drm: Refactor drop/set master code a bit

File open/set_maseter ioctl and file close/drop_master ioctl share the same master handling code. Extract it. Note that vmwgfx's master_set callback needs to know whether the master is a new one or has been used already, so thread this through. On the close/drop side a similar parameter existed,

[PATCH v3 1/3] drm: Add callbacks for late registering

On Tue, Jun 21, 2016 at 03:09:38PM +0200, Benjamin Gaignard wrote: > Like what has been done for connectors add callbacks on encoder, > crtc and plane to let driver do actions after drm device registration. > > Correspondingly, add callbacks called before unregister drm device. > > version 2: >

[PATCH v4 4/4] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

[PATCH v2 0/7] Documentation: convert DocBook gpu.tmpl to reStructuredText

On Tue, Jun 21, 2016 at 02:48:56PM +0300, Jani Nikula wrote: > Take two of [1], see the cover letter there. > > I've renamed drm-userland-interfaces.rst to drm-uapi.rst and added a > further split-up patch of drm internals, extracting mm, kms and kms > helpers to separate documents. All applied

[PATCH] drm: Lobotomize set_busid nonsense for !pci drivers

We already have a fallback in place to fill out the unique from dev->unique, which is set to something reasonable in drm_dev_alloc. Which means we only need to have a special set_busid for pci devices, to be able to care the backwards compat code for drm 1.1 around, which libdrm still needs.

[PATCH] drm: atmel-hlcdc: Fix OF graph parsing

Le 03/06/2016 09:26, Boris Brezillon a écrit : > atmel_hlcdc_create_outputs() iterates over OF graph nodes and releases > the node (using of_node_put()) after each iteration, which is wrong > since for_each_endpoint_of_node() is already taking care of that. > > Move the of_node_put() call in the

[PATCH] drm: Don't compute obj counts expensively in get_resources

On Tue, Jun 21, 2016 at 02:29:48PM +0200, Daniel Vetter wrote: > Looping when we keep track of this is silly. Only thing we have to > be careful is with sampling the connector count. To avoid inconsisten > results due to gcc re-computing this, use READ_ONCE. > > And to avoid surprising userspace,

[Bug 96588] [regression] [amdgpu] Errors scheduling IBs

re 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/20160621/03aaf363/attachment.html>

[PATCH v4 8/8] iommu/rockchip: Enable Rockchip IOMMU on ARM64

From: Simon Xue This patch makes it possible to compile the rockchip-iommu driver on ARM64, so that it can be used with 64-bit SoCs equipped with this type of IOMMU. Signed-off-by: Simon Xue Signed-off-by: Shunqian Zheng Signed-off-by: Tomasz Figa ---

[PATCH v4 7/8] drm/rockchip: Use common IOMMU API to attach devices

From: Shunqian Zheng Rockchip DRM used the arm special API, arm_iommu_*(), to attach iommu for ARM32 SoCs. This patch convert to common iommu API so it would support ARM64 like RK3399. Since previous patch added support for direct IOMMU address space management, there is

[PATCH v4 6/8] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

The API is not suitable for subsystems consisting of multiple devices and requires severe hacks to use it. To mitigate this, this patch implements allocation and address space management locally by using helpers provided by DRM framework, like other DRM drivers do, e.g. Tegra. This patch should

[PATCH v4 5/8] iommu/rockchip: Prepare to support generic DMA mapping

From: Shunqian Zheng Set geometry for allocated domains and fix .domain_alloc() callback to work with IOMMU_DOMAIN_DMA domain type, which is used for implicit domains on ARM64. Signed-off-by: Shunqian Zheng Signed-off-by: Tomasz Figa --- drivers/iommu/rockchip-iommu.c

[PATCH v4 4/8] iommu/rockchip: Use DMA API to manage coherency

From: Shunqian Zheng Use DMA API instead of architecture internal functions like __cpuc_flush_dcache_area() etc. The biggest difficulty here is that dma_map and _sync calls require some struct device, while there is no real 1:1 relation between an IOMMU domain and some

[PATCH v4 3/8] iommu/rockchip: Fix allocation of bases array in driver probe

From: Shunqian Zheng In .probe(), devm_kzalloc() is called with size == 0 and works only by luck, due to internal behavior of the allocator and the fact that the proper allocation size is small. Let's use proper value for calculating the size. Fixes: cd6438c5f844

[PATCH v4 2/8] iommu/rockchip: Add map_sg callback for rk_iommu_ops

From: Simon Xue The iommu_dma_alloc() in iommu/dma-iommu.c calls iommu_map_sg() that requires the callback iommu_ops .map_sg(). Adding the default_iommu_map_sg() to Rockchip IOMMU accordingly. Signed-off-by: Simon Xue Signed-off-by: Shunqian Zheng Reviewed-on:

[PATCH v4 1/8] iommu/rockchip: Fix devm_{request,free}_irq parameter

From: Simon Xue Even though the IOMMU shares IRQ with its master, the struct device passed to {request,free}_irq is supposed to represent the device that is signalling the interrupt. This patch makes the driver use IOMMU device instead of master's device to make things

[PATCH v4 0/8] iommu/rockchip: Fix bugs and enable on ARM64

This series intends mostly to enable support for ARM64 architecture in the rockchip-iommu driver. On the way to do so, some bugs are also fixed. The most important changes here are: - making the Rockchip IOMMU driver use DMA API for managing cache coherency of page tables, - making the

[PATCH] drm/rockchip: Finish initialization before registering DRM device

Currently the driver calls drm_dev_register() directly after allocating the DRM device and then continues with further initialization. This is incorrect, because drm_dev_register() is supposed to be called after all initialization is done. This problem was masked by the fact that

[PATCH v2 1/3] drm: Add callbacks for late registering

2016-06-21 12:31 GMT+02:00 Chris Wilson : > On Tue, Jun 21, 2016 at 11:31:34AM +0200, Benjamin Gaignard wrote: >> Like what has been done for connectors add callbacks on encoder, >> crtc and plane to let driver do actions after drm device registration. >> >> Correspondingly, add callbacks called

[PATCH v1 3/3] drm/i915: Use new CRC debugfs API

The core provides now an ABI to userspace for generation of CRCs that is compatible with the one currently in i915. So remove the code that is now duplicated and implement instead the ->set_crc_source() callback to start and end CRC generation. We still register files in the old debugfs paths so

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

Adds a per-device debugfile "drm_crc_control" that allows selecting a source for frame checksums in each CRTC that supports them. The checksums for each subsequent frame can be read from the per-CRTC file "drm_crtc_N_crc". The code is taken from the i915 driver and other drivers can now provide

[PATCH v1 1/3] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. Signed-off-by: Tomeu Vizoso --- drivers/gpu/drm/i915/Makefile | 2

[PATCH v1 0/3] New debugfs API for capturing CRC of frames

Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are expected to be identical, also have identical CRC values. Other drivers

[PATCH v3 4/4] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

[PATCH v3 3/4] drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the

[PATCH v3 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

[PATCH v3 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: stable at vger.kernel.org Cc: Ville Syrjälä Acked-by: Daniel Vetter Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_crt.c | 10 +- 1

[PATCH v3 0/4] Fixes for HPD

This is a revised version of the patchset: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html This patchset is intended to fix the issue of not having HPD when we're in runtime suspend, or on Valleyview/Cherryview systems when we don't have any power wells enabled. While this

[PATCH 7/7] drm/rcar-du: Remove redundant calls to drm_connector_register_all()

Hi Chris, Thank you for the patch. On Friday 17 Jun 2016 09:25:23 Chris Wilson wrote: > Up to now, the recommendation was for drivers to call drm_dev_register() > followed by drm_connector_register_all(). Now that > drm_connector_register() is safe against multiple invocations, we can > move

[PATCH 26/27] drm/crtc-helper: disable_unused_functions really isn't for atomic

Hi Daniel, On Thursday 09 Jun 2016 10:26:44 Daniel Vetter wrote: > On Thu, Jun 09, 2016 at 01:36:30AM +0300, Laurent Pinchart wrote: > > On Wednesday 08 Jun 2016 14:19:18 Daniel Vetter wrote: > >> Rockchip just blew up here on testing, because I removed some "is this > >> crtc already

[PATCH 2/3] drm/vc4: Remove open-coded drm_connector_register_all()

On Tue, Jun 21, 2016 at 10:28:02AM +0100, Chris Wilson wrote: > drm_dev_register() will now register all known connectors, so we no > longer have to do so manually. > > Signed-off-by: Chris Wilson > Cc: Eric Anholt > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel at

[PATCH 26/27] drm/crtc-helper: disable_unused_functions really isn't for atomic

On Tue, Jun 21, 2016 at 12:12:54PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > On Thursday 09 Jun 2016 10:26:44 Daniel Vetter wrote: > > On Thu, Jun 09, 2016 at 01:36:30AM +0300, Laurent Pinchart wrote: > > > On Wednesday 08 Jun 2016 14:19:18 Daniel Vetter wrote: > > >> Rockchip just blew up

[PATCH] arm64: dts: Add display subsystem DT nodes for hi6220-hikey

Add ade and dsi DT nodes for hikey board. The binding docs were acked by Rob Herring in this thread: https://lists.freedesktop.org/archives/dri-devel/2016-March/102135.html Signed-off-by: Xinliang Liu --- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 8

i915 and Intel NUC DN2820FYK

On Mon, 20 Jun 2016, Aristeu Rozanski wrote: > while trying to use the NUC DN2820FYK [1], screen goes black as soon > i915 is loaded. The NUC is connected by HDMI to a 1920x1080 display. > Works normally while on the BIOS (upgraded to the latest one just in > case today) and while on grub. Here's

[PATCH v2 1/3] drm: Add callbacks for late registering

On Tue, Jun 21, 2016 at 11:31:34AM +0200, Benjamin Gaignard wrote: > Like what has been done for connectors add callbacks on encoder, > crtc and plane to let driver do actions after drm device registration. > > Correspondingly, add callbacks called before unregister drm device. > > version 2: >

[PATCH v2 3/3] drm: sti: rework init sequence

Use drm_dev_alloc() and drm_dev_register() instead of .load() To simplify init sequence only create fbdev when requested in output_poll_changed(). version 2: remove call to drm_connector_unregister_all() and drm_dev_set_unique() Signed-off-by: Benjamin Gaignard ---

[PATCH v2 2/3] drm: sti: use late_register and early_unregister callbacks

Make sti driver use register callback to move debugfs initialization out of sub-components creation. This will allow to convert driver .load() to drm_dev_alloc() and drm_dev_register(). sti_compositor bring up 2 crtc but only one debugfs init is needed so use drm_crtc_index to do it on the first

[PATCH v2 1/3] drm: Add callbacks for late registering

Like what has been done for connectors add callbacks on encoder, crtc and plane to let driver do actions after drm device registration. Correspondingly, add callbacks called before unregister drm device. version 2: add drm_modeset_register_all() and drm_modeset_unregister_all() to centralize all

[PATCH v2 0/3] Add callbacks for late registering

version 2: create functions drm_modeset_register_all and drm_modeset_unregister_all to regroup all callbacks calls to avoid loops into drm_dev_register and drm_dev_unregister. Call order is now planes, crtcs, encoders and connectors Fix sti driver to not call drm_connector_register_all and

[PATCH 02/20] clk: multiplier: Prevent the multiplier from under / over flowing

x, Kernel and Android engineering http://free-electrons.com -- 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/20160621/d2365af8/attachment.sig>

[PATCH v4 0/8] iommu/rockchip: Fix bugs and enable on ARM64

On Tue, Jun 21, 2016 at 01:34:33PM +0900, Tomasz Figa wrote: > This series intends mostly to enable support for ARM64 architecture > in the rockchip-iommu driver. On the way to do so, some bugs are also > fixed. > > The most important changes here are: > - making the Rockchip IOMMU driver use

[PATCH 10/10] drm: Drop mode_config.mutex from _reset()

Again, we now have a safe way to iterate over the connector list and can remove the locking. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 0a678cfd9920..1064a41ed38b

[PATCH 09/10] drm: Drop mode_config.mutex from get_resources ioctl

The only thing this protected is the connector_list, which is now protected differently. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index d104717cab6b..0a678cfd9920

[PATCH 08/10] drm: Drop mode_config.mutex from connector_register_all

With the reworked connector_list locking we don't need this any more. Also, we can remove the FIXME comment from the unregister function, too, by using drm_for_each_connector. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 9 ++--- 1 file changed, 2 insertions(+), 7

[PATCH 07/10] drm: Revamp connector_list protection

This is a pretty good horror show, but I think it's the best tradeoff: - Thanks to srcu and delayed freeing the locking doesn't leak out to callers, hence no added headaches with locking inversions. - For core and drivers which hot-remove connectors all the connector list walking details are

[PATCH 06/10] drm: Drop cargo-culted modeset_lock_all from encoder/plane init/cleanup

We can't hotplug encoders/planes, there's no point in that locking. It was also inconsistent because lacking from plane_init. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c

[PATCH 05/10] drm/i915: Roll out drm_for_each_connector in intel_hotplug.c

Just prep work to for the revamped connector_list locking. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_hotplug.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c

[PATCH 04/10] drm/i915: Use use the drm_for_each_connector in i915_debugfs.c

I noticed that we don't have any locking. drm_for_each_connector will soon encapsulate late, so just roll that macro out as prep work. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git

  1   2   >