[RFC 5/5] dma-buf/sync_file: rework fence storage in struct file

On Thu, Jun 23, 2016 at 12:29:50PM -0300, Gustavo Padovan wrote: > -static void sync_file_add_pt(struct sync_file *sync_file, int *i, > +static int sync_file_set_fence(struct sync_file *sync_file, > +struct fence **fences) > +{ > + struct fence_array *array; > + > +

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

his, then you can use libGL + EGL (this has always >> worked), or there's also libglvnd's libOpenGL (this is new). Given >> that, it should be reworded. >> >> Cheers, >> Daniel >> > > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/c08e8fa8/attachment-0001.html>

[PATCH] drm/amdkfd: destroy mutex if process creation fails

Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 6482fee..771a18a 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++

[RFC 1/5] dma-buf/fence: add .teardown() ops

On Thu, Jun 23, 2016 at 12:29:46PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > fence_array requires a function to clean up its state before we > are able to call fence_put() and release it. An explanation along the lines of: As the array of fence callbacks held by an active

[RFC 3/5] dma-buf/fence: add .get_fences() ops

On Thu, Jun 23, 2016 at 12:29:48PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > get_fences() should return a copy of all fences in the fence as some > fence subclass (such as fence_array) can store more than one fence at > time. > > Signed-off-by: Gustavo Padovan > --- >

[RFC 4/5] dma-buf/fence-array: add fence_array_get_fences()

On Thu, Jun 23, 2016 at 12:29:49PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > This function returns a copy of the array of fences. > > Signed-off-by: Gustavo Padovan > --- > drivers/dma-buf/fence-array.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git

[v3 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to

[v3 PATCH 4/5] Documentation: bindings: add dt documentation for cdn DP controller

This patch adds a binding that describes the cdn DP controller for rk3399. Signed-off-by: Chris Zhong --- Changes in v3: - add SoC specific compatible string - remove reg = <1>; Changes in v2: None Changes in v1: - add extcon node description - add #sound-dai-cells description

[v3 PATCH 0/5] Rockchip Type-C and DispplayPort driver

Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and

[Bug 96492] Running Opera web-browser with forced hardware rendering cause GPU lockup

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/83ac784c/attachment.html>

[Bug 96492] Running Opera web-browser with forced hardware rendering cause GPU lockup

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/4d3aa170/attachment.html>

[Bug 94445] Tonga llvm assert since RegisterCoalescer: Need to check DstReg+SrcReg for missing undef flags

ves/dri-devel/attachments/20160623/f204f39f/attachment.html>

[PATCH v2 25/25] arm64: dts: apq8016-sbc: Add HDMI display support

The APQ8016-sbc provides a HDMI output. The APQ8016 display block only provides a MIPI DSI output. So, the board has a ADV7533 DSI to HDMI encoder chip that sits between the DSI PHY output and the HDMI connector. Add the ADV7533 DT node under its I2C control bus, and tie the DSI output port to

[PATCH v2 24/25] arm64: dts: msm8916: Add display support

The MSM8916 SoC contains a MDP5 based display block, and one DSI output. Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children sub-blocks. Establish the link between MDP5's INTF1 output port and DSI's input port. Cc: Andy Gross Cc: Rob Herring Cc: devicetree at vger.kernel.org

[PATCH v2 23/25] dt-bindings: display/msm: Remove power domain property from encoder nodes

Remove the power-domain property from the DSI, HDMI and eDP dt-binding docs. The power domain only needs to be specified in the parent MDSS device node (that too only for SoCs which contain MDSS). Signed-off-by: Archit Taneja --- Documentation/devicetree/bindings/display/msm/dsi.txt | 3 ---

[PATCH v2 22/25] dt-bindings: msm/dsi: Remove unused properties

Remove the DSI index properties from the DSI host and PHY binding documentation. The indices aren't a valid property and shouldn't be a part of the DT binding. Signed-off-by: Archit Taneja --- Documentation/devicetree/bindings/display/msm/dsi.txt | 6 -- 1 file changed, 6 deletions(-) diff

[PATCH v2 21/25] dt-bindings: msm/mdp: Provide details on MDP interface ports

The MDP4/5 DT node now contains a list of ports that describe how it connects to external encoder interfaces like DSI and HDMI. These follow the standard of_graph bindings, and allow us to get rid of the 'connectors' phandle that contained a list of all the external encoders connected to MDP.

[PATCH v2 20/25] dt-bindings: msm/mdp5: Add MDP5 display bindings

Add a new doc for DT bindings for platforms that contain MDP5 display controller hardware. The doc describes bindings for the top level MDSS wrapper hardware and MDP5 itself. Add an example for the bindings as found in MSM8916. Acked-by: Rob Herring Signed-off-by: Archit Taneja ---

[PATCH v2 19/25] dt-bindings: msm/mdp4: Create a separate binding doc for MDP4

MDP4 and MDP5 vary a bit in terms of device hierarchy and the properties they require. Rename the binding doc to mdp4.txt and remove MDP5 specific pieces. A separate document will be created for MDP5 Acked-by: Rob Herring Signed-off-by: Archit Taneja ---

[PATCH v2 18/25] drm/msm/dsi: Don't get DSI index from DT

The DSI host and PHY driver currently expects the DT bindings to provide custom properties "qcom,dsi-host-index" and "qcom,dsi-phy-index" so that the driver can identify which DSI instance it is. The binding isn't acceptable, but the driver still needs to figure out what its instance id. This is

[PATCH v2 17/25] drm/msm/mdp5: Update compatible strings for MDSS/MDP5

Introduce new compatible strings for the top level MDSS wrapper device, and the MDP5 device. Previously, the "qcom,mdp5" and "qcom,mdss_mdp" compatible strings were used to match the top level platform_device (which was also tied to the top level drm_device struct). Now, these strings are used to

[PATCH v2 16/25] drm/msm: Drop the gpu binding

The driver currently identifies the GPU components it needs by parsing a phandle list from the 'gpus' DT property. This isn't the right binding to go with. So, for now, just search all device nodes and find the gpu node we need by parsing a list of compatible strings. Once we know how to link

[PATCH v2 15/25] drm/msm: Add components for MDP5

For MDP5 based platforms, the master device isn't the MDP5 platform device, but the top level MDSS device, which is a parent to MDP5 and interface (DSI, HDMI, eDP etc) devices. In order to add components on MDP5 platforms, we first need to populate the MDSS children, locate the MDP5 child, and

[PATCH v2 14/25] drm/msm: Add display components by parsing MDP ports

The kms driver currently identifies all the mdss components it needs by parsing a phandle list from the 'connectors' DT property. Instead of this, describe a list of ports that the MDP hardware provides to the external world. These ports are linked to external encoder interfaces such as DSI,

[PATCH v2 13/25] drm/msm: Create separate funcs for adding display/gpu components

Simplifies some of the code that we'll add later. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/msm_drv.c | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index 1c18690..1b8b915

[PATCH v2 12/25] drm/msm/mdp5: Add missing mdp5_enable/disable calls

Since runtime PM isn't implemented yet, we need to call mdp5_enable/disable in a few more places. These would later be replaced by runtime PM get/put calls. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 2 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 2 ++ 2 files

[PATCH v2 11/25] drm/msm: Call pm_runtime_enable/disable for newly created devices

With the new device hierarchy for MDP5, we need to enable runtime PM for both the toplevel MDSS device and the MDP5 device itself. Enable runtime PM for the new devices. Since MDP4 and MDP5 now have different places where runtime PM is enabled, remove the previous pm_runtime_enable/disable calls,

[PATCH v2 10/25] drm/msm/mdp5: Update the register offsets of MDP5 sub-blocks

The MDP5 sub-block register offsets are relative to the top level MDSS register address. Now that we have the start of MDP5 register address space, provide the offsets relative to that. This involves subtracting the offsets with 0x1000 or 0x100 depending on the MDP5 version. Signed-off-by:

[PATCH v2 09/25] drm/msm/mdp5: Use updated MDP5 register names

Since MDSS registers were stuffed within the the MDP5 register space, we had an __offset_MDP() macro to identify the offset between the start of MDSS and MDP5 address spaces. This offset macro expected a MDP index argument, which didn't make much sense since we don't have multiple MDPs. The

[PATCH v2 08/25] drm/msm/mdp5: Remove old kms init/destroy funcs

With the new kms_init/destroy funcs in place for MDP5, we can get rid of the old kms funcs. Some members of the mdp5_kms struct also become redundant, so we remove those too. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 228 +---

[PATCH v2 07/25] drm/msm/mdp5: Use the new hierarchy and drop old irq management

Call msm_mdss_init in msm_drv to set up top level registers/irq line. Start using the new kms_init2/destroy2 funcs to inititalize MDP5 KMS. With the MDSS interrupt and irqdomain set up, the old MDP5 irq code can be dropped. The mdp5_hw_init kms func now uses the platform device tied to MDP5

[PATCH v2 06/25] drm/msm/mdp5: Prepare new kms_init funcs

With MDP5 as a new device, we need to do less for MDP when initializing modeset after all the components are bound. Create mdp5_kms_init2/destroy2 funcs that inits modeset. These will eventually replace the older kms_init/destroy funcs. In the new kms_init2, the platform_device used is the one

[PATCH v2 05/25] drm/msm/mdp5: Create a separate MDP5 device

In order to have a tree-like device hierarchy between MDSS and its sub-blocks (MDP5, DSI, HDMI, eDP etc), we need to create a separate device/driver for MDP5. Currently, MDP5 and MDSS are squashed together are are tied to the top level platform_device, which is also the one used to create

[PATCH v2 04/25] drm/msm/mdp5: Add MDSS top level driver

SoCs that contain MDP5 have a top level wrapper called MDSS that manages clocks, power and irq for the sub-blocks within it. Currently, the MDSS portions are stuffed into the MDP5 driver. This makes it hard to represent the DT bindings in the correct way. We create a top level MDSS helper that

[PATCH v2 03/25] drm/msm: Get irq number within kms driver itself

The driver gets the irq number using platform_get_irq on the main kms platform device. This works fine since both MDP4 and MDP5 currently have a flat device hierarchy. The platform device tied with the drm_device points to the MDP DT node in both cases. This won't work when MDP5 supports a

[PATCH v2 02/25] drm/msm: Remove unused fields

These aren't used. Probably left overs when driver was refactored to support both MDP4 and MDP5. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/msm_kms.h | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h index

[PATCH v2 01/25] drm/msm: Drop the id_table in platform_driver

This isn't needed as we only support OF. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/msm_drv.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index a02dc2b..476eafe 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++

[PATCH v2 00/25] drm/msm: Enable DT support

This patchset adds the last bits needed for getting the MSM display bindings in correct shape, and as an example, adds display support for MSM8916. One problem with the MDP5 driver was that device hierarchy didn't match with the hardware. All MDP5 based display blocks contain a top-level MDSS

[PATCH v3 02/10] drm/rockchip: analogix_dp: split the lcdc select setting into device data

Am Donnerstag, 23. Juni 2016, 10:32:53 schrieb Sean Paul: > On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > > eDP controller need to declare which vop provide the video source, > > and it's defined in GRF registers. > > > > But different chips have different GRF register address, so we need

[PATCH 12/12] arm64: tegra: Add DPAUX pinctrl bindings

Add the DPAUX pinctrl states for the DPAUX nodes defining all three possible states of "aux", "i2c" and "off". Also add the 'i2c-bus' node for the DPAUX nodes so that the I2C driver core does not attempt to parse the pinctrl state nodes. Populate the nodes for the pinctrl clients of the DPAUX pin

[PATCH 11/12] arm64: tegra: Add SOR power-domain node

Add node for SOR power-domain for Tegra210 and populate the SOR power-domain phandle for SOR and DPAUX nodes that are dependent on this power-domain. Please note that although neither the SOR or DPAUX drivers currently support runtime power-management, by populating the power-domain node the SOR

[PATCH 10/12] drm/tegra: Add pinctrl support for DPAUX

The DPAUX pins are shared with an internal I2C controller. To allow these pins to be muxed to the I2C controller, register a pinctrl device for the DPAUX device. Make Tegra DRM support dependent on PINCTRL to avoid any compilation issues. This is based upon work by Thierry Reding .

[PATCH 09/12] dt-bindings: Add bindings for Tegra DPAUX pinctrl driver

On Tegra124, Tegra132 and Tegra210 devices the pads used by the Display Port Auxiliary (DPAUX) channel are multiplexed such that they can also be used by one of the internal I2C controllers. Note that this is different from I2C-over-AUX supported by the DPAUX controller. The register that

[PATCH 08/12] i2c: core: Add support for 'i2c-bus' subnode

If the 'i2c-bus' device-tree node is present for an I2C adapter then parse this subnode for I2C slaves. Signed-off-by: Jon Hunter --- drivers/i2c/i2c-core.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index

[PATCH 07/12] dt-bindings: i2c: Add support for 'i2c-bus' subnode

The I2C driver core for boards using device-tree assumes any subnode of an I2C adapter in the device-tree blob as being a I2C slave device. Although this makes complete sense, some I2C adapters may have subnodes which are not I2C slaves but subnodes presenting other features. For example some

[PATCH 06/12] pinctrl: pinconf: Add generic helper function for freeing mappings

The pinconf-generic.h file exposes functions for creating generic mappings but it does not expose a function for freeing the mappings. Add a function for freeing generic mappings. Signed-off-by: Jon Hunter Acked-by: Linus Walleij --- drivers/pinctrl/pinconf-generic.c | 8

[PATCH 05/12] drm/tegra: Prepare DPAUX for supporting generic PM domains

To utilise the DPAUX on Tegra, the SOR power partition must be enabled. Now that Tegra supports the generic PM domain framework we manage the SOR power partition via this framework for DPAUX. However, the sequence for gating/ungating the SOR power partition requires that the DPAUX reset is

[PATCH 04/12] dt-bindings: display: Update Tegra DPAUX documentation

Update the DPAUX compatibility string information for Tegra124, Tegra132 and Tegra210. Signed-off-by: Jon Hunter --- .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 03/12] drm/tegra: Add helper functions for setting up DPAUX pads

In preparation for adding pinctrl support for the DPAUX pads, add helpers functions for configuring the pads and controlling the power for the pads. Please note that although a simple if-statement could be used instead of a case statement for configuring the pads as there are only two possible

[PATCH 02/12] drm/tegra: Clean-up if probing DPAUX fails

If the probing of the DPAUX fails, then clocks are left enabled and the DPAUX reset de-asserted. Add code to perform the necessary clean-up on probe failure by disabling clocks and asserting the reset. Signed-off-by: Jon Hunter --- drivers/gpu/drm/tegra/dpaux.c | 22 -- 1

[PATCH 01/12] soc/tegra: pmc: Initialise resets associated with a power partition

When registering the Tegra power partitions with the generic PM domain framework, the current state of the each partition is checked and used as the default state for the partition. However, the state of each reset associated with the partition is not initialised and so it is possible that the

[PATCH 00/12] Add support for Tegra DPAUX pinctrl

The Display Port Auxiliary (DPAUX) channel pads can be shared with an internal I2C controller. Add pinctrl support for these pads so that the I2C controller can request and use these pads. This series has been tested with Thierry's patches for correcting the parent clock for the DPAUX devices

Precise vblank timestamping for VC4 kms.

On Thu, Jun 23, 2016 at 08:17:49AM +0200, Mario Kleiner wrote: > The following patch implements precise vblank timestamping > for RaspberryPi's VC4, at least for standard progressive > scan display modes. > > It has been tested on the HDMI output with half a dozen different > video modes using

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

On Thu, 23 Jun 2016, Steven Newbury wrote: > [ Unknown signature status ] > On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote: >> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote: >> > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: >> > > On Fri, 17 Jun 2016, Daniel Vetter

[Intel-gfx] [PATCH] drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx

On Thu, Jun 23, 2016 at 01:45:06PM +0200, Maarten Lankhorst wrote: > Atomic updates may acquire more state than initially locked through > drm_modeset_lock_crtc, running with heavy stress can cause a > WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc: > > [ 601.491296] [ cut here

[PATCH 3/3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

vGEM buffers are useful for passing data between software clients and hardware renders. By allowing the user to create and attach fences to the exported vGEM buffers (on the dma-buf), the user can implement a deferred renderer and queue hardware operations like flipping and then signal the buffer

[PATCH 2/3] drm/vgem: Enable dmabuf interface for export

Enable the standard GEM dma-buf interface provided by the DRM core, but only for exporting the VGEM object. This allows passing around the VGEM objects created from the dumb interface and using them as sources elsewhere. Creating a VGEM object for a foriegn handle is not supported. v2: With

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

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. v2: drm_gem_free_mmap_offset() is performed from drm_gem_object_release() so we can remove the redundant

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

; friends)? If not, maybe it would be an interesting GSoC project, assuming > such patches were accepted? Yes, endian swap helpers exist in mesa. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed..

[PATCH v4 1/4] drm: add generic zpos property

2016-06-22 1:45 GMT+02:00 Laurent Pinchart : > Hi Benjamin, > > Thank you for the patch. > > Could you please reply to Ville's comment to v1 of this patch (posted on April > the 25th) ? > For each iteration of the patches we have swap between two solutions: - have normalization done between 0 to

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

Rui -- 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/20160623/96be1485/attachment.html>

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

> > > After being more careful about waiting to identify flicker, this > > > one > > > seems to be the one the bisect finds.  I'm now running v4.7-rc3 > > > with > > > this one reverted and am currently seeing no flicker > > > problems.  It > > > is, > > > however, early days because the flicker can hide for long > > > periods, so > > > I > > > 'll wait until Monday evening and a few reboots before declaring > > > victory. > > > > > >   > > I'm seeing this on my IvyBridge.  I'll try reverting the commit > > here > > too, to see if it's the same issue. > > IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a > different failure mode. > It must be something else then.  Actually, in my case linus/master is okay.  I saw the subject and though it must be the same issue.  I'm seeing it with drm-intel nightly/next branches.  Shall I try to bisect it?  Symptoms are similar, although I would describe it more like flashes of a different buffer across parts of the screen. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/1f99b976/attachment.sig>

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

Ard Biesheuvel writes: > On 23 June 2016 at 11:55, Punit Agrawal wrote: >> Ard Biesheuvel writes: >> >>> 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

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

; > commit a05628195a0d9f3173dd9aa76f482aef692e46ee > Author: Ville Syrjälä > Date:   Mon Apr 11 10:23:51 2016 +0300 > >     drm/i915: Get panel_type from OpRegion panel details > > After being more careful about waiting to identify flicker, this one > seems to be the one the bisect finds.  I'm now running v4.7-rc3 with > this one reverted and am currently seeing no flicker problems.  It > is, > however, early days because the flicker can hide for long periods, so > I > 'll wait until Monday evening and a few reboots before declaring > victory. > >  I'm seeing this on my IvyBridge.  I'll try reverting the commit here too, to see if it's the same issue. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/c628480a/attachment-0001.sig>

[PATCH] drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx

Atomic updates may acquire more state than initially locked through drm_modeset_lock_crtc, running with heavy stress can cause a WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc: [ 601.491296] [ cut here ] [ 601.491366] WARNING: CPU: 0 PID: 2411 at

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160623/9c612d16/attachment.html>

linux-next: manual merge of the sunxi tree with the drm-misc tree

Hi Maxime, Today's linux-next merge of the sunxi tree got a conflict in: drivers/gpu/drm/sun4i/sun4i_drv.c between commit: 366e292df678 ("drm/sun4i: Remove open-coded drm_connector_register_all()") from the drm-misc tree and commit: 7aa2e2b731b3 ("drm/sun4i: Convert to connector

[RFC 5/5] dma-buf/sync_file: rework fence storage in struct file

From: Gustavo Padovan Create sync_file->fence to abstract the type of fence we are using for each sync_file. If only one fence is present we use a normal struct fence but if there is more fences to be added to the sync_file a fence_array is created. This

[RFC 4/5] dma-buf/fence-array: add fence_array_get_fences()

From: Gustavo Padovan This function returns a copy of the array of fences. Signed-off-by: Gustavo Padovan --- drivers/dma-buf/fence-array.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/dma-buf/fence-array.c

[RFC 3/5] dma-buf/fence: add .get_fences() ops

From: Gustavo Padovan get_fences() should return a copy of all fences in the fence as some fence subclass (such as fence_array) can store more than one fence at time. Signed-off-by: Gustavo Padovan --- drivers/dma-buf/fence.c | 14 ++

[RFC 2/5] dma-buf/fence-array: add fence_array_teardown()

From: Gustavo Padovan When using fences in sync files we need to clean up everything when the sync file needs to be freed, thus we need to teardown fence_array, by removing the callback of its fences and putting extra references to the fence_array base fence.

[RFC 1/5] dma-buf/fence: add .teardown() ops

From: Gustavo Padovan fence_array requires a function to clean up its state before we are able to call fence_put() and release it. Signed-off-by: Gustavo Padovan --- drivers/dma-buf/fence.c | 7 +++ include/linux/fence.h | 7 +++ 2 files changed, 14

[RFC 0/5] rework fences on struct sync_file

From: Gustavo Padovan Hi all, This is an attempt to improve fence support on Sync File. The basic idea is to have only sync_file->fence and store all fences there, either as normal fences or fence_arrays. That way we can remove some potential duplication when

[PATCH 2/2] drm/tegra: sor: Use sor1_src clock to set parent for HDMI

From: Thierry Reding When running in HDMI mode, the sor1 IP block needs to use the sor1_src as parent clock, and in turn configure the sor1_src to use pll_d2_out0 as its parent. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/sor.c | 14 +- 1 file

[PATCH 1/2] dt-bindings: display: tegra: Add source clock for SOR

From: Thierry Reding The SOR clock can have various sources, with the most commonly used being the sor_safe, pll_d2_out0, pll_dp and sor_brick clocks. These are configured using a three level mux, of which the first 2 levels can be treated as one. The direct parents of the

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

Hi Philipp, On Wed, Jun 22, 2016 at 4:51 PM, Philipp Zabel wrote: > Hi Nicolas, > > Am Mittwoch, den 22.06.2016, 14:32 +0800 schrieb Nicolas Boichat: >> >> Actually, experimenting a bit more with the code, I realized that the >> >> connector is always attached to the encoder, not the bridge, so

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

On 23 June 2016 at 11:55, Punit Agrawal wrote: > Ard Biesheuvel writes: > >> 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 >>

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

On Thu, Jun 23, 2016 at 10:43 AM, Thierry Reding wrote: > On Thu, Jun 23, 2016 at 10:24:46AM +0200, Tomeu Vizoso wrote: >> On 23 June 2016 at 10:21, Jani Nikula wrote: >> > On Wed, 22 Jun 2016, Daniel Vetter wrote: >> >> On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding >> >> wrote: >> >>>

[Intel-gfx] DP link training and performance issues with HDMI USB-C dongle and Skylake

On Thu, 23 Jun 2016, Andy Lutomirski wrote: > I have a Dell XPS 13 9350 (Skylake) and a Dell DA200 adapter. The > latter is a Thunderbolt device that includes an HDMI port and connects > over USB Type C. I believe that it's internally using DP Alternate > Mode. > I don't know whether this is a

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

On Wed, 22 Jun 2016, Daniel Vetter wrote: > On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding > wrote: >> Perhaps another way to avoid that would be to put the two files into a >> separate directory, as in: >> >> /sys/kernel/debug/dri//crtc-/crc/ >> +-- control >> +-- data

[RFC PATCH 00/13] Add support for Tegra DPAUX pinctrl

On Thu, Jun 23, 2016 at 10:04 AM, Thierry Reding wrote: > On Thu, Jun 23, 2016 at 09:49:20AM +0200, Linus Walleij wrote: >> On Fri, Jun 17, 2016 at 6:58 PM, Thierry Reding >> wrote: >> >> > Oh wait... there's the pinctrl helper function that is a build- >> > dependency. Linus, would you be okay

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

Am Donnerstag, den 23.06.2016, 12:08 +0800 schrieb Nicolas Boichat: [...] > >> >> I think it'd be a bit weird to have the DDC bus phandle on the DP > >> >> connector, as we're not reading the EDID on the DP side of the bridge, > >> >> but on the HDMI side (and the bridge can do all sort of things

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

Ard Biesheuvel writes: > 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

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

--- 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/20160623/b2d24dac/attachment.sig>

[PATCH 7/7] staging/android: remove sync framework TODO

2016-06-23 Emil Velikov : > Hi Gustavo, > > On 20 June 2016 at 16:53, Gustavo Padovan wrote: > > - - port libsync tests to kselftest > > I believe the tests haven't landed yet right, so this should stay right ? Yes, you are right. That part is still missing in upstream. Gustavo

[PATCH v3 03/10] drm/bridge: analogix_dp: correct the register bit define error in ANALOGIX_DP_PLL_REG_1

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > There're an register define error in ANALOGIX_DP_PLL_REG_1 which introduced > by commit bcec20fd5ad6 ("drm: bridge: analogix/dp: add some rk3288 special > registers setting"). > > The PHY PLL input clock source is selected by

[PATCH v3 02/10] drm/rockchip: analogix_dp: split the lcdc select setting into device data

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > eDP controller need to declare which vop provide the video source, > and it's defined in GRF registers. > > But different chips have different GRF register address, so we need to > create a device data to declare the GRF messages for each

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

On 23 June 2016 at 10:21, Jani Nikula wrote: > On Wed, 22 Jun 2016, Daniel Vetter wrote: >> On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding >> wrote: >>> Perhaps another way to avoid that would be to put the two files into a >>> separate directory, as in: >>> >>>

[PATCH v3 10/10] drm/bridge: analogix_dp: fix no drm hpd event when panel plug in

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only > send drm hp event when the irq_type and the enum value is true. > > if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...) > drm_helper_hpd_irq_event(dp->drm_dev); > > So

[PATCH v3 09/10] drm/rockchip: analogix_dp: update the comments about why need to hardcode VOP output mode

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > The hardware IC designed that VOP must output the RGB10 video format to > eDP contoller, and if eDP panel only support RGB8, then eDP contoller > should cut down the video data, not via VOP contoller, that's why we need > to hardcode the VOP

[PATCH v3 08/10] drm/rockchip: analogix_dp: correct the connector display color format and bpc

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > Rockchip VOP couldn't output YUV video format for eDP controller, so > when driver detect connector support YUV video format, we need to hack > it down to RGB888. > > Signed-off-by: Yakir Yang > Acked-by: Mark Yao > --- > Changes in v3: > -

[RFC PATCH v2 6/6] drm/rockchip: Add dmc notifier in vop driver

Hi Lin, On 2016년 06월 22일 21:25, hl wrote: > Hi Chanwoo Choi, > > On 2016年06月22日 15:11, Chanwoo Choi wrote: >> Hi, >> >> On 2016년 06월 06일 19:13, Lin Huang wrote: >>> when in ddr frequency scaling process, vop can not do >>> enable or disable operate, since dcf will base on vop

[PATCH v3 07/10] drm/bridge: analogix_dp: passing the connector as an argument in .get_modes()

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > It's better to pass the connector to platform driver in .get_modes() > callback, just like what the .get_modes() helper function designed. > > Signed-off-by: Yakir Yang Reviewed-by: Sean Paul > --- > Changes in v3: > - Avoid to change any

[PATCH v3 06/10] drm/rockchip: analogix_dp: make panel detect to an optional action

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > Some boards don't need to declare a panel device node, like the > display interface is DP monitors, so it's necessary to make the > panel detect to an optional action. > > Signed-off-by: Yakir Yang > Acked-by: Mark Yao > --- > Changes in v3:

[RFC PATCH 00/13] Add support for Tegra DPAUX pinctrl

hen you can pull it too. > > Would that work? Yes, that would be just fine. 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.freedeskto

[PATCH v4.1 1/2] drm/rockchip: analogix_dp: introduce the pclk for grf

For RK3399's GRF module, if we want to operate the graphic related grf registers, we need to enable the pclk_vio_grf which supply power for VIO GRF IOs, so it's better to introduce an optional grf clock in driver. Signed-off-by: Yakir Yang --- Hi all, This is an external patch for analogix_dp

[RFC PATCH 00/13] Add support for Tegra DPAUX pinctrl

On Fri, Jun 17, 2016 at 6:58 PM, Thierry Reding wrote: > Oh wait... there's the pinctrl helper function that is a build- > dependency. Linus, would you be okay if I took that through the > drm-tegra tree along with the DPAUX driver change, and provide a > stable branch for you to resolve

[PATCH v3 05/10] drm/rockchip: analogix_dp: add rk3399 eDP support

On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote: > RK3399 and RK3288 shared the same eDP IP controller, only some light > difference with VOP configure and GRF configure. > > Signed-off-by: Yakir Yang > Acked-by: Mark Yao > --- > Changes in v3: > - Give the "rk3399-edp" a separate line for

[PATCH v4 2/2] dt-bindings: analogix_dp: rockchip: correct the wrong compatible name

The document about rockchip platform make a mistaken in available compatible name of "rk3288-edp", we should correct it to "rk3288-dp" which correspond to the compatible name in driver. This mistaken was introduced in commit be91c36247089 ("dt-bindings: add document for rockchip variant of

[PATCH v4 1/2] drm/rockchip: analogix_dp: introduce the pclk for grf

For RK3399's GRF module, if we want to operate the graphic related grf registers, we need to enable the pclk_vio_grf which supply power for VIO GRF IOs, so it's better to introduce an optional grf clock in driver. Signed-off-by: Yakir Yang --- Hi all, This is an external patch for analogix_dp

  1   2   >