[PATCH] drm/ast: Fix incorrect register check for DRAM width

During DRAM initialization on certain ASpeed devices, an incorrect bit (bit 10) was checked in the "SDRAM Bus Width Status" register to determine DRAM width. Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05. Signed-off-by: Timothy Pearson ---

[Bug 93911] Radeon rv635 with KMS and no dpm, intermittent/random GPU lockup

.org/archives/dri-devel/attachments/20160225/debf739d/attachment.html>

[PATCH, RESEND] drm/sti: use u32 to store DMA addresses

The STi drm driver correctly warns about invalid format strings when built with 64-bit dma_addr_t: sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb': sti_hqvdp.c:605:119: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}'

[PATCH, RESEND] drm: avoid uninitialized timestamp use in wait_vblank

gcc warns about the timestamp in drm_wait_vblank being possibly used without an initialization: drivers/gpu/drm/drm_irq.c: In function 'drm_wait_vblank': drivers/gpu/drm/drm_irq.c:1755:28: warning: 'now.tv_usec' may be used uninitialized in this function [-Wmaybe-uninitialized]

[Bug 93594] Flickering Shadows in The Talos Principle

scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/8dbc2e13/attachment.html>

[Bug 72877] Wrong colors with Mesa 9.2, 10.0, and 11.0.2 on PPC Linux systems

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/20160225/21e1397f/attachment-0001.html>

[git pull] drm fixes

On Thu, Feb 25, 2016 at 6:20 PM, Dave Airlie wrote: > > This is a bit larger than Id like, but I asked the Intel guys to pull in > some Skylake fixes in the possibly vain hope that Skylake might be more > functional now that I'm seeing production hardware shipping. > > For i915, it's mostly the

[PATCH v3 2/2] gpu: host1x: Set the DMA mask for host1x devices

The default DMA mask covers a 32 bits address range, but devices can address more than that. Set the DMA mask to the actual addressable range to avoid the use of unneeded bounce buffers. Signed-off-by: Alexandre Courbot --- Changes since v1: - set the mask at the bus level so of_dma_configure()

[PATCH v3 1/2] gpu: host1x: Set DMA ops on device creation

Currently host1x-instanciated devices have their dma_ops left to NULL, which makes any DMA operation (like buffer import) on ARM64 fallback to the dummy_dma_ops and fail with an error. This patch calls of_dma_configure() with the host1x node when creating such a device, so the proper DMA

[GIT PULL] drm/tilcdc: Accumulated fixes over the past couple of years

od target. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/dac69d32/attachment.sig>

[GIT PULL] drm/tilcdc: Accumulated fixes over the past couple of years

Hi Dave, Here is a long list of tilcdc fixes that were reviewed by Tomi Valkeinen here: https://lists.freedesktop.org/archives/dri-devel/2016-February/101649.html The fixes are on top of commit 0041ee4d3642f9ad80a479fbe51a4bc7f3cd8294: Merge branch 'drm/next/du' of

[PATCH v9] dma-buf: Add ioctls to allow userspace to flush

On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote: > +static long dma_buf_ioctl(struct file *file, > + unsigned int cmd, unsigned long arg) > +{ > + struct dma_buf *dmabuf; > + struct dma_buf_sync sync; > + enum dma_data_direction direction; > + > +

[PATCH 30/33] drm/omap: verify that fb plane pitches are the same

A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/7e27c7ff/attachment.sig>

[PATCH v2 1/3] drm/fsl-dcu: use mode flags for hsync/vsync polarity

.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/f5202e26/attachment.sig>

[PATCH 12/33] drm/omap: use dma_mapping_error in omap_gem_dma_sync

nyway, so the pages have to be unmapped somewhere in any case. So possibly we could unmap, but I don't see us leaking anything even if the dma_map_page fails. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/2d96c98a/attachment.sig>

[PATCH 11/33] drm/omap: use dma_mapping_error in omap_gem_attach_pages

9,8 @@ static int omap_gem_attach_pages(struct drm_gem_object >> *obj) omap_obj->pages = pages; >> >> return 0; >> +free_addrs: >> +kfree(addrs); >> > > I'd move this blank line before free_addrs. Yes, that makes it cleaner. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/b78f6fe1/attachment.sig>

[GIT PULL] drm/fsl-dcu: cleanup changes and fixes for v4.6

Hi Dave, As previously discussed, this is my first pull request for the DCU DRM driver along with the change in MAINTAINERS. https://lkml.org/lkml/2016/1/7/26 The pull contains some code cleanup changes (e.g. removing all error handling for the regmap calls) and several fixes. -- Stefan The

[Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

On Fri, Feb 26, 2016 at 12:36:12AM +, Emil Velikov wrote: ... > > --- a/drivers/gpu/drm/drm_crtc.c > > +++ b/drivers/gpu/drm/drm_crtc.c > > @@ -1554,6 +1554,41 @@ static int > > drm_mode_create_standard_properties(struct drm_device *dev) > > return -ENOMEM; > >

[PATCH] android: add virgl to be a valid driver

On 25 February 2016 at 16:41, Chih-Wei Huang wrote: > To avoid the warning: > > external/libdrm/libkms/Android.mk:17: invalid GPU drivers: virgl > > Signed-off-by: Chih-Wei Huang Pushed to master. Thanks Emil

[Bug 94242] [radeonsi] Crash while running Fedora mock tool for prompting root (gtksu)

-- 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/20160225/2c426939/attachment.html>

[PATCH 5/5] drm/i915: Implement color management on chv

On Thu, Feb 25, 2016 at 03:33:43PM +, Lionel Landwerlin wrote: > Patch based on a previous series by Shashank Sharma. > > v2: Update contributors > > v3: Refactor degamma/gamma LUTs load into a single function > > v4: Remove unused variable > > Signed-off-by: Shashank Sharma >

[Bug 94284] [radeonsi] outlast segfault on start

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

[PATCH 2/2] drm/dp: add DPCD/AUX logging

Add a new drm_debug bit for turning on DPCD logging, to aid debugging with troublesome monitors. v2: don't try to hexdump the universe if driver returns -errno, and change the "too many retries" traces to DRM_ERROR() v3: rename to more generic "AUX" instead of DP specific DPCD, add

[PATCH 1/2] drm/dp: move hw_mutex up the call stack

1) don't let other threads trying to bang on aux channel interrupt the defer timeout/logic 2) don't let other threads interrupt the i2c over aux logic Technically, according to people who actually have the DP spec, this should not be required. In practice, it makes some troublesome Dell monitor

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

On Tue, Feb 23, 2016 at 9:33 PM, Thulasimani, Sivakumar wrote: > > > On 2/24/2016 3:41 AM, Lyude wrote: >> >> As it turns out, resuming DP MST is racey since we don't make sure MST >> is ready before we start modesetting, it just usually happens to be >> ready in time. This isn't the case on all

[Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

On Thu, Feb 25, 2016 at 03:33:42PM +, Lionel Landwerlin wrote: > Patch based on a previous series by Shashank Sharma. > > v2: Do not read GAMMA_MODE register to figure what mode we're in > > v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 > > Add documentation on how the

[PATCH v2 1/2] drm/fsl-dcu: fix register initialization

On 2016-02-02 17:06, Stefan Agner wrote: > The layer enumeration start with 0 (0-15 for LS1021a and 0-63 for > Vybrid) whereas the register enumeration start from 1 (1-10 for > LS1021a and 1-9 for Vybrid). The loop started off from 0 for both > iterations and initialized the number of layers

[PATCH v2 1/3] drm/fsl-dcu: use mode flags for hsync/vsync polarity

On 2016-02-08 13:57, Stefan Agner wrote: > The current default configuration is as follows: > - Invert VSYNC signal (active LOW) > - Invert HSYNC signal (active LOW) > > The mode flags allow to specify the required polarity per > mode. Furthermore, none of the current driver settings is >

[RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture

On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote: > >> +} > >> + > >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page > >> **ret_page, > >> + gfp_t flags); > >> +extern bool arch_in_atomic_pool(void *start, size_t size); > >>

[PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

On 02/18/16 16:35, Rob Herring wrote: > On Wed, Feb 17, 2016 at 04:49:05PM +0200, Jyri Sarha wrote: >> From: Jean-Francois Moine >> >> Two kinds of ports may be declared in a DT graph of ports: video and audio. >> This patch accepts the port value from a video port as an alternative >> to the

[PATCH 0/7] drm/fsl-dcu: fixes and enhancements

On 2015-11-18 18:42, Stefan Agner wrote: > During testing the DCU DRM driver on the Freescale Vybrid platform > I came across some (platform independent) bugs and problems which > this patchset addresses. > > Note: To use the driver on Vybrid some platform/device-tree > enhancements are needed

[PATCH 5/5] drm/i915: Implement color management on chv

Patch based on a previous series by Shashank Sharma. v2: Update contributors v3: Refactor degamma/gamma LUTs load into a single function v4: Remove unused variable Signed-off-by: Shashank Sharma Signed-off-by: Lionel Landwerlin Signed-off-by: Kumar, Kiran S Signed-off-by: Kausal Malladi

[PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

Patch based on a previous series by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add documentation on how the Broadcast RGB property is affected by CTM v4: Update contributors v5: Refactor

[PATCH 3/5] drm: introduce pipe color correction properties

Patch based on a previous series by Shashank Sharma. This introduces optional properties to enable color correction at the pipe level. It relies on 3 transformations applied to every pixels displayed. First a lookup into a degamma table, then a multiplication of the rgb components by a 3x3 matrix

[PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

Implement Daniel Stone's recommendation to not read registers to infer the hardware's state. v2: Read GAMMA_MODE register value at init (Matt Roper's comment) v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along with other registers (Matt Roper's comment). Signed-off-by:

[PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

The moves a couple of functions programming the gamma LUT and CSC units into their own file. On generations prior to Haswell there is only a gamma LUT. From haswell on there is also a new enhanced color correction unit that isn't used yet. This is why we need to set the GAMMA_MODE register,

[PATCH 0/5] Pipe level color management V9

This series introduces pipe level color management through a set of properties attached to the CRTC. It also provides an implementation for some Intel platforms. This series is based of a previous set of patches by Shashank Sharma. Cheers, Lionel v9: Rebase on nightly Lionel Landwerlin (5):

[Bug 94284] [radeonsi] outlast segfault on start

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160225/e7746655/attachment.html>

[PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

On Thu, Feb 25, 2016 at 10:58:46AM +, Lionel Landwerlin wrote: > Implement Daniel Stone's recommendation to not read registers to infer > the hardware's state. > > v2: Read GAMMA_MODE register value at init (Matt Roper's comment) > > v3: Read GAMMA_MODE register in

[PATCH v11 11/14] clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output

On 02/17, Philipp Zabel wrote: > The configurable hdmi_ref output of the PLL block is derived from > the tvdpll_594m clock signal via a configurable PLL post-divider. > It is used as the PLL reference input to the HDMI PHY module. > > Signed-off-by: Philipp Zabel > Acked-by: James Liao > ---

[PATCH v11 13/14] clk: mediatek: remove hdmitx_dig_cts from TOP clocks

On 02/17, Philipp Zabel wrote: > The hdmitx_dig_cts clock signal is not a child of tvdpll_445p5m, > but is routed out of the HDMI PHY module. > > Signed-off-by: Philipp Zabel > --- For the latest one: Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora

[PATCH] drm/gma500: Make mdfld_dsi_connector_dpms() return a value

Hi Daniel, A patch to fix this is already merged into drm-misc: commit db9b60400f9253c25ae639797df2d0ff7a35d9d8 Author: Sudip Mukherjee Date: Tue Feb 2 11:35:55 2016 +0530 drm/gma500: remove helper function We were getting build warning about:

[PATCH v9 13/14] clk: mediatek: remove hdmitx_dig_cts from TOP clocks

On 01/12, Philipp Zabel wrote: > The hdmitx_dig_cts clock signal is not a child of tvdpll_445p5m, > but is routed out of the HDMI PHY module. > > Signed-off-by: Philipp Zabel > --- Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation

[PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

From: Ville Syrjälä To save a bit of power, let's try to turn off the TMDS output buffers in DP++ adaptors when we're not driving the port. v2: Let's not forget DDI, toss in a debug message while at it Signed-off-by: Ville Syrjälä ---

[PATCH v3 00/10] drm/msm/hdmi: HDMI support on MSM8996

On 02/25/2016 02:17 PM, Archit Taneja wrote: > > > On 02/25/2016 02:09 PM, Arnd Bergmann wrote: >> On Thursday 25 February 2016 11:22:35 Archit Taneja wrote: >>> HDMI on MSM8996 has a TX block that is compatible with the older >>> versions apart from some minor changes. The HDMI PHY and PLL on

[PATCH v3 00/10] drm/msm/hdmi: HDMI support on MSM8996

On 02/25/2016 02:09 PM, Arnd Bergmann wrote: > On Thursday 25 February 2016 11:22:35 Archit Taneja wrote: >> HDMI on MSM8996 has a TX block that is compatible with the older >> versions apart from some minor changes. The HDMI PHY and PLL on MSM8996 >> are new. >> >> The series refactors the code

[Bug 93761] A conditional discard in a fragment shader causes no depth writing at all

because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/1778bd8a/attachment.html>

[4.4-rc1][Regression] drm/i915: Check live status before reading edid

On 02/24/2016 10:53 PM, Jindal, Sonika wrote: > Hi Joe, > > Yes, first thing to try is to increase the tries. We testing with 300 retries, but the second monitor still did not show up. However, it did show up in lspci. > Can you please point me to the bug and provide more details like platform,

[RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture

Hello, On 2016-02-19 11:30, Arnd Bergmann wrote: > On Friday 19 February 2016 09:22:44 Marek Szyprowski wrote: >> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation >> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The >> side-effect of this change is a

[Bug 80419] XCOM: Enemy Unknown Causes lockup

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/8876f8a8/attachment.html>

[Bug 93933] Setting invalid uniform results in corrupted rendering

type|| -- 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/20160225/c2e3244d/attachment.html>

[Bug 93740] weston client egl corruption above certain window size since radeonsi: Enable DCC.

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160225/2e360216/attachment.html>

[RFC 26/29] dma-buf/fence: remove pointless fence_timeline_signal at destroy phase

2016-02-09 Tom Cherry : > On Fri, Jan 15, 2016 at 3:42 PM, Greg Hackmann > wrote: > > On 01/15/2016 10:02 AM, Gustavo Padovan wrote: > >> > >> Patches 27 and 28 are attempt to fix that. I assumed that if some code is > >> calling fence_timeline_destroy() it wants to stop everything so I > >>

[Bug 93144] [radeonsi] Alien: Isolation feature request

L: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/f33eb866/attachment.html>

[PATCH v4 00/22] drm/ticdc: Accumulated fixes over the past couple of years

tal signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/229ba90c/attachment.sig>

Enable CONFIG_VGA_SWITCHEROO cause lspci on MSI GS60-070XCN stuck

Hi, On Wed, Feb 24, 2016 at 11:32:15PM +0800, Drunkard Zhang wrote: > I may hit a bug, when enabled CONFIG_VGA_SWITCHEROO, run lspci command > on MSI GS60-070XCN will stuck, it eats 100% CPU of one core, and > CPU/memory allocation on this system fails sometimes. Sounds like a deadlock. Does

[PATCH] drm/i2c: tda998x: Choose between atomic or non atomic dpms helper

Hi, Based on discussion around this patch: https://lists.freedesktop.org/archives/dri-devel/2016-February/100685.html I think the patch below should be applied to tda988x development branch. Would you take it or do you prefer some other approach? Best regards, Jyri On 01/16/16 22:17, Jyri

[Bug 93829] [Wine] Lockup with MotoGP 2

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

[Bug 93478] [amdgpu] [tonga] VM Faults and card lock up

ment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/219cde9b/attachment.html>

[PATCH v3 10/10] dt-bindings: msm/hdmi: Add HDMI PHY bindings

Add HDMI PHY bindings. Update the example to use HDMI PHY. Added a missing power-domains property in the HDMI core bindings. Also, simplified HDMI TX's DT node name in the example. Cc: devicetree at vger.kernel.org Cc: Rob Herring Signed-off-by: Archit Taneja ---

[PATCH v3 09/10] drm/msm/hdmi: HDMI 8996 PHY/PLL support

Add support for the HDMI PHY/PLL found in MSM8996/APQ8096. Unlike the previous PHYs supported in the driver, this doesn't need the powerup/powerdown ops. The PLL prepare/unprepare clock ops enable/disable the phy itself. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/Makefile

[PATCH v3 08/10] drm/msm/hdmi: Update generated headers for HDMI 8996 PHY

Adds HDMI 8996 PHY offsets. The offsets are divided into 3 parts: - Core HDMI PHY registers - HDMI PLL registers (part of QSERDES block) - HDMI TX lane registers (part of QSERDES block) Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 500

[PATCH v3 07/10] drm/msm/hdmi: Update generated headers to split PHY/PLL offsets

- Create separate domains for 8960 PHY and PLL - Create separate domains for 8x60 PHY Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 157 +--- 1 file changed, 74 insertions(+), 83 deletions(-) diff --git

[PATCH v3 06/10] drm/msm/hdmi: Convert PHY files according to new design

Remove the old PHY ops managed by hdmi_platform_config and use them as ops provided by the HDMI PHY driver. Remove the old HDMI 8960 PLL code that used the top level HDMI TX mmio base. NOTE: With this commit, HDMI functionality will break until the HDMI PHY/PLL register offsets in hdmi.xml.h

[PATCH v3 05/10] drm/msm/hdmi: Make HDMI core get its PHY

Make HDMI core get its PHY by parsing the "phys" phandle. The core will use this PHY reference to enable/disable PHY. The driver defers probe until PHY isn't available. The DT bindings used here is the same as the one used for PHYs using the common PHY framework bindings. Signed-off-by: Archit

[PATCH v3 04/10] drm/msm/hdmi: Manage HDMI PLL through PHY driver

Add a helper to initialize PLL in the PHY driver. HDMI PLLs are going to have their own mmio base different from that of PHY. For the clock code in hdmi_phy_8960.c, some changes were needed for it to work with the updated register offsets. Create a copy of the updated clock code in

[PATCH v3 03/10] drm/msm/hdmi: Create a separate HDMI PHY driver

Create a PHY device that represents the TX PHY and PLL parts of the HDMI block. This makes management of PHY specific resources (regulators and clocks) much easier, and makes the PHY and PLL usable independently. It also simplifies the core HDMI driver, which currently assigns phy ops among many

[PATCH v3 02/10] drm/msm/hdmi: Fix connector detect when there is no HPD gpio

Some platforms may not have a HPD gpio line to detect Hot Plug signal from the connector. They need to rely only on reading REG_HDMI_HPD_INT_STATUS for HPD. Modify hdmi_connector_detect logic such that it checks for HPD only using the status register if there is no HPD gpio. Signed-off-by:

[PATCH v3 01/10] drm/msm/hdmi: Clean up connector gpio usage

Make gpio allocation and usage iterative by parsing the gpios on a given platform from a list. This gives us flexibility over what all gpios exist for a platform, whether they are input or output, and what value they should be set to. In particular, this will make HDMI on 8x96 platforms easier to

[PATCH v3 00/10] drm/msm/hdmi: HDMI support on MSM8996

HDMI on MSM8996 has a TX block that is compatible with the older versions apart from some minor changes. The HDMI PHY and PLL on MSM8996 are new. The series refactors the code such that there is a separate HDMI PHY driver, similar to what we already have for DSI. This makes it easier to integrate

[PATCH v2 7/7] drm/msm/dsi: Parse DSI lanes via DT

The DSI driver is currently unaware of how the DSI physical data lanes are mapped to the logical lanes provided by the DSI controller. Create a DT binding "qcom,data-lane-map" that provides this information on a given platform. The MSM DSI controller is restricted in terms of what all mappings

[PATCH v2 6/7] drm/msm/dsi: Drop VDD regulator for MSM8916

VDD regulator input was specified for MSM8916. It turns our that this regulator is used for the display panels used on MSM8916 platforms, but not the DSI controller itself. Drop this regulator from the list. Reported-by: Vinay Simha Signed-off-by: Archit Taneja ---

[PATCH v2 5/7] drm/msm/dsi: Remove incorrect warning on host attach

With the implementation of of_graph parsing, it isn't any longer necessary for msm_host->device node to be same as dsi->dev.of_node. This only holds true when the connected device is also a child of the dsi_host. In the case of external bridge chips belonging to a different control bus, these are

[PATCH v2 4/7] drm/msm: Free fb helper resources in msm_unload

We have a msm_fbev_free function to uninit fb_helper stuff, but we aren't using it. Call it in msm_unload. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/msm_drv.c | 5 + drivers/gpu/drm/msm/msm_drv.h | 1 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_drv.c

[PATCH v2 3/7] drm/msm/mdp: Detach iommu in mdp4_destroy

From: Sricharan R attach_dev gets called in mdp4_kms_init, but there is no corresponding detach_dev called in the error path or in the kms driver unload path. Detach and destroy mmu in mdp4_destroy. Signed-off-by: Sricharan R Signed-off-by: Archit Taneja ---

[PATCH v2 2/7] drm/msm: make iommu port names const'ier

From: Rob Clark Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_iommu.c | 6 -- drivers/gpu/drm/msm/msm_mmu.h | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c index

[PATCH v2 1/7] drm/msm/mdp: Use atomic helper to set crtc property

Assign drm_atomic_helper_crtc_set_property helper to MDP4 and MDP5 crtcs' set_property ops. This replaces the custom funcs that returned an error even for standard crtc properties. Signed-off-by: Archit Taneja Reviewed-by: Daniel Vetter --- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 9

[PATCH v2 0/7] drm/msm: Misc patches

These are mainly small fixes in drm/msm. The last patch adds a way to parse DSI lanes information via DT. Changes in v2: - Updated the patch VDD regulator patch for MSM8916. After studying schematics and looking at DSI specs again carefully, we realized that the vdd supply is meant for the

[PATCH v2 13/13] dt-bindings: msm/hdmi: Add HDMI PHY bindings

Hi Kishon, On 02/24/2016 05:30 PM, Kishon Vijay Abraham I wrote: > Hi Archit, > > On Tuesday 23 February 2016 03:06 PM, Archit Taneja wrote: >> >> >> On 02/23/2016 12:57 AM, Rob Herring wrote: >>> On Mon, Feb 22, 2016 at 5:07 AM, Archit Taneja >>> wrote: On 02/22/2016 08:24 AM,

[PATCH 5/5] drm/i915: Implement color management on chv

Patch based on a previous series by Shashank Sharma. v2: Update contributors v3: Refactor degamma/gamma LUTs load into a single function v4: Remove unused variable Signed-off-by: Shashank Sharma Signed-off-by: Lionel Landwerlin Signed-off-by: Kumar, Kiran S Signed-off-by: Kausal Malladi

[PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

Patch based on a previous series by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add documentation on how the Broadcast RGB property is affected by CTM v4: Update contributors v5: Refactor

[PATCH 3/5] drm: introduce pipe color correction properties

Patch based on a previous series by Shashank Sharma. This introduces optional properties to enable color correction at the pipe level. It relies on 3 transformations applied to every pixels displayed. First a lookup into a degamma table, then a multiplication of the rgb components by a 3x3 matrix

[PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

Implement Daniel Stone's recommendation to not read registers to infer the hardware's state. v2: Read GAMMA_MODE register value at init (Matt Roper's comment) v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along with other registers (Matt Roper's comment). Signed-off-by:

[PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

The moves a couple of functions programming the gamma LUT and CSC units into their own file. On generations prior to Haswell there is only a gamma LUT. From haswell on there is also a new enhanced color correction unit that isn't used yet. This is why we need to set the GAMMA_MODE register,

[PATCH 0/5] Pipe level color management V8

This series introduces pipe level color management through a set of properties attached to the CRTC. It also provides an implementation for some Intel platforms. This series is based of a previous set of patches by Shashank Sharma. Cheers, Lionel Lionel Landwerlin (5): drm/i915: Extract out

[Bug 94284] [radeonsi] outlast segfault on start

||on start -- 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/20160225/073dda26/attachment-0

[patch] drm/amd: cleanup get_mfd_cell_dev()

It's simpler to just use snprintf() to print this to one buffer instead of using strcpy() and strcat(). Also using snprintf() is slightly safer than using sprintf(). Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c

radeon RV730 lockup

ioctl+0x13d/0x560 > [] ? radeon_cs_parser_init+0x490/0x490 [radeon] > [] radeon_drm_ioctl+0x9/0x10 [radeon] > [] do_vfs_ioctl+0x2b5/0x490 > [] ? __fget+0x72/0xa0 > [] SyS_ioctl+0x3c/0x70 > [] entry_SYSCALL_64_fastpath+0x12/0x6a > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/a20c9858/attachment.html>

[PATCH v2.1 5/6] drm/atomic: Handle encoder assignment conflicts in a separate check, v2.

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

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

On 24 February 2016 at 02:37, Mark Rutland wrote: Hi Mark, thanks for review. > On Tue, Feb 23, 2016 at 11:00:21AM +0800, Xinliang Liu wrote: >> Add ADE display controller binding doc. >> Add DesignWare DSI Host Controller v1.20a binding doc. >> >> v5: >> - Remove endpoint unit address of dsi

[PATCH] drm/i2c: tda998x: Choose between atomic or non atomic dpms helper

On Thu, Feb 25, 2016 at 12:09:39PM +0200, Jyri Sarha wrote: > Hi, > Based on discussion around this patch: > > https://lists.freedesktop.org/archives/dri-devel/2016-February/100685.html > > I think the patch below should be applied to tda988x development branch. > Would you take it or do you

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

Unfortunately MST is a wild beast, and doesn't work at all like other connectors. This being said, putting it above intel_display_resume() was the first thing I tried but that didn't work. Originally I had thought putting it this high up was required because I had assumed drm_mode_config_reset()

[PATCH] drm/nouveau: platform: Fix deferred probe

erdown; > + > + *pdevice = >device; > > return 0; > + > +powerdown: > + nvkm_device_tegra_power_down(tdev); > +remove: > + nvkm_device_tegra_remove_iommu(tdev); > +free: > + kfree(tdev); > + return ret; > } > #else > int > -- > 2.7.1 > Tested-by: Nicolas Chauvet Test-HW jetson-tk1 Tested-by on top of Fedora 4.5-r5 kernel package Thx -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/98e60e7a/attachment.html>

[PATCH v3 00/10] drm/msm/hdmi: HDMI support on MSM8996

On Thursday 25 February 2016 11:22:35 Archit Taneja wrote: > HDMI on MSM8996 has a TX block that is compatible with the older > versions apart from some minor changes. The HDMI PHY and PLL on MSM8996 > are new. > > The series refactors the code such that there is a separate HDMI PHY > driver,

[Bug 80678] xrandr scaling / transform does not work with radeon

vel/attachments/20160225/8d76d68f/attachment.html>

[PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity

On 2016-02-24 11:28, Philipp Zabel wrote: > Am Dienstag, den 23.02.2016, 15:30 -0800 schrieb Stefan Agner: >> Any comments on this? > > None other that I'm all in favor. consider patch 2 > Acked-by: Philipp Zabel > Same here! Acked-by: Manfred Schlaegl regards Manfred

[PATCH v4 15/22] drm/tilcdc: Get rid of complex ping-pong mechanism

on the screen, so when you do a page flip, you could flip the wrong buffer. The next patch adds some safety margin for the "page-flip near vblank" issue. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/546e85ef/attachment.sig>

[PATCH v4 15/22] drm/tilcdc: Get rid of complex ping-pong mechanism

On Thu, Feb 25, 2016 at 1:55 AM, Tomi Valkeinen wrote: > > > On 24/02/16 22:31, Rob Clark wrote: >> On Wed, Feb 24, 2016 at 11:48 AM, Jyri Sarha wrote: >>> From: Tomi Valkeinen >>> >>> Get rid of complex ping-pong mechanism and replace it with simpler >>> single buffer flipping code. >>> >>>

[PATCH] drm/nouveau: platform: Fix deferred probe

On Thu, Feb 25, 2016 at 2:34 AM, Thierry Reding wrote: > From: Thierry Reding > > The error cleanup paths aren't quite correct and will crash upon > deferred probe. > > Cc: stable at vger.kernel.org # v4.3+ > Signed-off-by: Thierry Reding Reviewed-by: Alexandre Courbot

[PATCH] drm/nouveau: platform: Fix deferred probe

return 0; > + > +powerdown: > + nvkm_device_tegra_power_down(tdev); > +remove: > + nvkm_device_tegra_remove_iommu(tdev); > +free: > + kfree(tdev); > + return ret; > } > #else > int > -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160225/03a942e5/attachment-0001.sig>

  1   2   >