[GIT PULL] imx-drm cleanups and YUV 4:2:0 memory read/write reduction support

Hi Dave, This tag contains a few cleanup patches, and adds support for setting a bit in the channel parameter memory to stop the IPU from writing the chroma lines twice for YUV420 and NV12 formats. regards Philipp The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

[GIT PULL] imx-drm fixes for PRE, LDB, VDIC

Hi Dave, this tag fixes a sporadic PRE startup issue on i.MX6QP, fixes LDB probing for device trees that don't specify a panel, such as SABREauto, and fixes the capture interface input selection to the deinterlacer, which is used by the upcoming video4linux support. regards Philipp The

Re: [RFC 0/1] drm: Add Grain Media GM12U320 kms driver

Hi, On 07-06-17 23:14, Noralf Trønnes wrote: Den 07.06.2017 22.19, skrev Noralf Trønnes: Den 07.06.2017 21.50, skrev Marco Diego Aurélio Mesquita: On Wed, Jun 7, 2017 at 4:38 PM, Noralf Trønnes wrote: Den 07.06.2017 20.46, skrev Marco Diego Aurélio Mesquita: Hi

Re: [PATCH v2 0/3] drm/omap: Support for hotplug detection

On 02/06/17 15:26, Peter Ujfalusi wrote: > Hi, > > Changes since v1: > - proper locking within omap_connector_hpd_cb() > - include the correct linux/mutex.h in omap_connector and tpd driver. > > this series will add support for HPD in omapdrm. Instead of polling for HPD > changes we can use

Re: [PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

Hi Tomi, On 08/05/17 12:26, Tomi Valkeinen wrote: > On 06/05/17 14:58, Hans Verkuil wrote: > >> My assumption was that hdmi_display_disable() was called when the hotplug >> would go >> away. But I discovered that that isn't the case, or at least not when X is >> running. >> It seems that the

Re: [PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

On 08/06/17 10:34, Hans Verkuil wrote: >> Peter is about to send hotplug-interrupt-handling series, I think the >> HPD function work should be done on top of that, as otherwise it'll just >> conflict horribly. > > Has that been merged yet? And if so, what git repo/branch should I base > my next

Re: [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

On 06/08/2017 06:25 AM, Christoph Hellwig wrote: > DMA_ERROR_CODE is not a public API and will go away. Instead properly > unwind based on the loop counter. > > Signed-off-by: Christoph Hellwig Acked-by: Dave Jiang > --- > drivers/dma/ioat/init.c | 24

[PATCH 39/44] xen-swiotlb: remove xen_swiotlb_set_dma_mask

This just duplicates the generic implementation. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index c3a04b2d7532..82fc54f8eb77 100644 ---

[PATCH 5/8] lib/interval_tree: Fast overlap detection

Allow interval trees to quickly check for overlaps to avoid unnecesary tree lookups in interval_tree_iter_first(). As of this patch, all interval tree flavors will require using a 'rb_root_cached' such that we can have the leftmost node easily available. While most users will make use of this

[PATCH 10/44] ia64: remove DMA_ERROR_CODE

All ia64 dma_mapping_ops instances already have a mapping_error member. Signed-off-by: Christoph Hellwig --- arch/ia64/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h index

[PATCH 16/44] arm64: remove DMA_ERROR_CODE

The dma alloc interface returns an error by return NULL, and the mapping interfaces rely on the mapping_error method, which the dummy ops already implement correctly. Thus remove the DMA_ERROR_CODE define. Signed-off-by: Christoph Hellwig --- arch/arm64/include/asm/dma-mapping.h |

[PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

DMA_ERROR_CODE is not a public API and will go away. Instead properly unwind based on the loop counter. Signed-off-by: Christoph Hellwig --- drivers/dma/ioat/init.c | 24 +++- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git

clean up and modularize arch dma_mapping interface

Hi all, for a while we have a generic implementation of the dma mapping routines that call into per-arch or per-device operations. But right now there still are various bits in the interfaces where don't clearly operate on these ops. This series tries to clean up a lot of those (but not all

[PATCH 35/44] x86: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that this also means the arch specific check will be fully instead of partially applied in the AMD iommu driver. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 3 ---

[PATCH 09/44] c6x: remove DMA_ERROR_CODE

Signed-off-by: Christoph Hellwig --- arch/c6x/include/asm/dma-mapping.h | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/c6x/include/asm/dma-mapping.h b/arch/c6x/include/asm/dma-mapping.h index aca9f755e4f8..05daf1038111 100644 --- a/arch/c6x/include/asm/dma-mapping.h

[PATCH 36/44] dma-mapping: remove HAVE_ARCH_DMA_SUPPORTED

Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index a57875309bfd..3e5908656226 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h

[git pull] drm fixes for 4.12-rc5

Hi Linus, Bit more spread out fixes this time, fixes for 7 drivers + a couple of core fixes. i915 and vmwgfx are the main ones. The vmwgfx ones fix a bunch of regressions in their atomic rework, and a few fixes destined for stable. i915 has some 4.12 regressions and older things that need to be

[PATCH 02/44] ibmveth: properly unwind on init errors

That way the driver doesn't have to rely on DMA_ERROR_CODE, which is not a public API and going away. Signed-off-by: Christoph Hellwig --- drivers/net/ethernet/ibm/ibmveth.c | 159 + 1 file changed, 74 insertions(+), 85 deletions(-) diff --git

[PATCH 12/44] microblaze: remove DMA_ERROR_CODE

microblaze does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/microblaze/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/microblaze/include/asm/dma-mapping.h b/arch/microblaze/include/asm/dma-mapping.h index

[PATCH 21/44] powerpc: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Instead define a ->mapping_error method for all IOMMU based dma operation instances. The direct ops don't ever return an error and don't need a ->mapping_error method. Signed-off-by: Christoph Hellwig ---

[PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 2 -- arch/hexagon/kernel/dma.c | 12 +--- arch/hexagon/kernel/hexagon_ksyms.c| 1 - 3 files changed, 9 insertions(+), 6 deletions(-) diff --git

[PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu driver already implements a proper ->mapping_error method, so it's only using the value internally. Add a new local define using the value that arm64 which is the only current user of dma-iommu. Signed-off-by: Christoph

[PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

Besides removing the last instance of the set_dma_mask method this also reduced the code duplication. Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/cell/iommu.c | 25 + 1 file changed, 9 insertions(+), 16 deletions(-) diff --git

[PATCH 41/44] powerpc/cell: clean up fixed mapping dma_ops initialization

By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can have the fixed map_ops set yet as it's only set by the set_dma_mask method. So move the setup for the fixed case to be only called in that place instead of indirecting through cell_dma_dev_setup. Signed-off-by: Christoph

[PATCH 32/44] hexagon: remove the unused dma_is_consistent prototype

Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/hexagon/include/asm/dma-mapping.h b/arch/hexagon/include/asm/dma-mapping.h index 9c15cb5271a6..463dbc18f853 100644 ---

[PATCH 38/44] arm: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c index 4aabf117e136..d89a0b56b245 100644 ---

[PATCH 01/44] firmware/ivc: use dma_mapping_error

DMA_ERROR_CODE is not supposed to be used by drivers. Signed-off-by: Christoph Hellwig --- drivers/firmware/tegra/ivc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/tegra/ivc.c b/drivers/firmware/tegra/ivc.c index

[PATCH 44/44] powerpc: merge __dma_set_mask into dma_set_mask

Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/dma-mapping.h | 1 - arch/powerpc/kernel/dma.c | 13 - 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/dma-mapping.h

[PATCH 18/44] iommu/amd: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- drivers/iommu/amd_iommu.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index

[PATCH 14/44] sh: remove DMA_ERROR_CODE

sh does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/sh/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/sh/include/asm/dma-mapping.h b/arch/sh/include/asm/dma-mapping.h index d99008af5f73..9b06be07db4d 100644 ---

Re: [Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

By Sent from my iPhone ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 27/44] sparc: remove leon_dma_ops

We can just use pci32_dma_ops. Btw, given that leon is 32-bit and appears to be PCI based, do even need the special case for it in get_arch_dma_ops at all? Signed-off-by: Christoph Hellwig --- arch/sparc/include/asm/dma-mapping.h | 3 +-- arch/sparc/kernel/ioport.c | 5

[PATCH 19/44] s390: implement ->mapping_error

s390 can also use noop_dma_ops, and while that currently does not return errors it will so in the future. Implementing the mapping_error method is the proper way to have per-ops error conditions. Signed-off-by: Christoph Hellwig --- arch/s390/include/asm/dma-mapping.h | 2 --

[PATCH 20/44] sparc: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/sparc/include/asm/dma-mapping.h | 2 -- arch/sparc/kernel/iommu.c| 12 +--- arch/sparc/kernel/iommu_common.h | 2 ++ arch/sparc/kernel/pci_sun4v.c|

[PATCH 29/44] dma-noop: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-noop.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-noop.c b/lib/dma-noop.c index de26c8b68f34..643a074f139d 100644 --- a/lib/dma-noop.c +++

[PATCH 22/44] x86/pci-nommu: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/pci-nommu.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c index

Re: [PATCH 25/44] arm: implement ->mapping_error

BOn Thu, Jun 08, 2017 at 03:25:50PM +0200, Christoph Hellwig wrote: > +static int dmabounce_mapping_error(struct device *dev, dma_addr_t dma_addr) > +{ > + if (dev->archdata.dmabounce) > + return 0; I'm not convinced that we need this check here: dev->archdata.dmabounce =

[PATCH 13/44] openrisc: remove DMA_ERROR_CODE

openrisc does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/openrisc/include/asm/dma-mapping.h b/arch/openrisc/include/asm/dma-mapping.h index

[PATCH 25/44] arm: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 16 --- arch/arm/include/asm/dma-iommu.h | 2 ++ arch/arm/include/asm/dma-mapping.h | 1 - arch/arm/mm/dma-mapping.c | 41

[PATCH 30/44] dma-virt: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-virt.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-virt.c b/lib/dma-virt.c index dcd4df1f7174..5c4f11329721 100644 --- a/lib/dma-virt.c +++

[PATCH v2 2/4] drm/rockchip: dw_hdmi: add RK3399 HDMI support

RK3399 and RK3288 shared the same HDMI IP controller, only some light difference with GRF configure. base on Yakir Yang's rk3399 patch, rebase to newest upstrem kernel: https://patchwork.kernel.org/patch/9223323 Signed-off-by: Mark Yao Signed-off-by: Yakir Yang

Re: [PATCH v3 0/3] Add support for the S6E3HF2 panel on TM2e board

Dear Thierry, Could you check these patches. Regards, Hoegeun On 05/19/2017 03:56 PM, Hoegeun Kwon wrote: Dear Thierry, Could you check these patches? I think this patches have accumulated enough dust. If you have a another opinion, please tell me. Best regards, Hoegeun On 04/18/2017 05:40

[lkp-robot] [drm] e1f8a89c4f: pft.faults_per_sec_per_cpu -77.9% regression

Greeting, FYI, we noticed a -77.9% regression of pft.faults_per_sec_per_cpu due to commit: commit: e1f8a89c4f33f5b32cfb047f07fdf6d38cda854a ("drm: introduce sync objects (v4)") git://people.freedesktop.org/~airlied/linux.git drm-syncobj-sem in testcase: pft on test machine:

[PATCH 1/4] drm: bridge: dw-hdmi: Export hdmi_phy_configure_dwc_hdmi_3d_tx

So dw-hdmi vendor driver can reuse hdmi_phy_configure_dwc_hdmi_3d_tx to configure their hardware. Signed-off-by: Mark Yao --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++- include/drm/bridge/dw_hdmi.h | 3 +++ 2 files changed, 5 insertions(+), 1

Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2

在 2017-06-07 22:38，Maxime Ripard 写道： On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: >I have no idea what this is supposed to be doing either. > >I might be wrong, but I really feel like there's a big mismatch >between your commit log, and what you actually implement. > >In your

[PATCH 23/44] x86/calgary: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/pci-calgary_64.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/pci-calgary_64.c

Re: [PATCH 19/44] s390: implement ->mapping_error

On Thu, 8 Jun 2017 15:25:44 +0200 Christoph Hellwig wrote: > s390 can also use noop_dma_ops, and while that currently does not return > errors it will so in the future. Implementing the mapping_error method > is the proper way to have per-ops error conditions. > > Signed-off-by:

[PATCH 08/44] xen-swiotlb: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index

[PATCH 07/44] xen-swiotlb: consolidate xen_swiotlb_dma_ops

ARM and x86 had duplicated versions of the dma_ops structure, the only difference is that x86 hasn't wired up the set_dma_mask, mmap, and get_sgtable ops yet. On x86 all of them are identical to the generic version, so they aren't needed but harmless. All the symbols used only for

Re: [PATCH 28/44] sparc: remove arch specific dma_supported implementations

Hi Christoph, On Thu, Jun 8, 2017 at 11:25 PM, Christoph Hellwig wrote: > Usually dma_supported decisions are done by the dma_map_ops instance. > Switch sparc to that model by providing a ->dma_supported instance for > sbus that always returns false, and implementations tailored to

[PATCH 24/44] x86: remove DMA_ERROR_CODE

All dma_map_ops instances now handle their errors through ->mapping_error. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h index

[PATCH 04/44] drm/exynos: don't use DMA_ERROR_CODE

DMA_ERROR_CODE already isn't a valid API to user for drivers and will go away soon. exynos_drm_fb_dma_addr uses it a an error return when the passed in index is invalid, but the callers never check for it but instead pass the address straight to the hardware. Add a WARN_ON instead and just

[PATCH 37/44] mips/loongson64: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/mips/loongson64/common/dma-swiotlb.c | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/arch/mips/loongson64/common/dma-swiotlb.c

[PATCH v2 3/4] drm/rockchip: dw_hdmi: introduce the VPLL clock setting

For RK3399 HDMI, there is an external clock need for HDMI PHY, and it should keep the same clock rate with VOP DCLK. VPLL have supported the clock for HDMI PHY, but there is no clock divider bewteen VPLL and HDMI PHY. So we need to set the VPLL rate manually in HDMI driver. Signed-off-by: Yakir

[PATCH v2 4/4] drm/rockchip: dw_hdmi: 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 Signed-off-by: Mark Yao

Re: [PATCH v3 2/6] dt-bindings: display: Add Synopsys DW MIPI DSI DRM bridge driver

Hi Philippe, Rob, On 06/08/2017 09:10 PM, Rob Herring wrote: On Fri, Jun 02, 2017 at 04:37:11PM +0200, Philippe CORNU wrote: This patch adds documentation of device tree bindings for the Synopsys DesignWare MIPI DSI host DRM bridge driver. Could you drop "DRM bridge driver" from the subject

[PATCH] ARM: dts: exynos: Add the OF graph between fimd and dsi

It should be connected to OF graph between fimd and dsi. Add the OF graph between fimd and dsi. Signed-off-by: Hoegeun Kwon --- arch/arm/boot/dts/exynos3250.dtsi | 26 ++ arch/arm/boot/dts/exynos4.dtsi| 26 ++ 2 files

[PATCH 2/3] drm/panel: Add support for s6e63j0x03 panel driver

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver which uses mipi_dsi bus to communicate with panel. The panel has 320×320 resolution in 1.63" physical panel. This panel is used in Samsung Galaxy Gear 2. Signed-off-by: Inki Dae Signed-off-by: Hyungwon Hwang

[PATCH 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using MIPI-DSI interfaces. Signed-off-by: Hoegeun Kwon --- .../bindings/display/panel/samsung,s6e63j0x03.txt | 24 ++ 1 file changed, 24 insertions(+) create mode 100644

[PATCH 0/3] Add support for the s6e63j0x03 panel on Rinato board

Hi all, The purpose of this patch is add support for s6e63j0x03 AMOLED panel on the rinato board(Samsung Galaxy Gear 2). The first and second patches are Add the binding document and panel driver. The third patch is remove the unnecessary properties in the rinato dts. Best regards, Hoegeun

[PATCH 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

The display-timing and delay are included in the panel driver. So it should be removed in dts. Signed-off-by: Hoegeun Kwon --- arch/arm/boot/dts/exynos3250-rinato.dts | 22 -- 1 file changed, 22 deletions(-) diff --git

Re: [PATCH v3 6/6] drm/stm: Add STM32 DSI host driver

On 06/06/2017 01:41 PM, Neil Armstrong wrote: Hi Philippe, On 06/02/2017 04:37 PM, Philippe CORNU wrote: Add the STM32 DSI host driver that uses the Synopsys DesignWare MIPI DSI DRM bridge. Signed-off-by: Philippe CORNU --- drivers/gpu/drm/stm/Kconfig |

Re: [PATCH 1/4] drm: bridge: dw-hdmi: Export hdmi_phy_configure_dwc_hdmi_3d_tx

Ignore this patch, Jose has a better patch to solve rk3399 hdmi phy configure. Hi Jose Sorry for missing your patch about hdmi 2.0 vendor phy fixup: https://patchwork.kernel.org/patch/9702229 It works fine on rk3399/rk3288, can you resend a standard patch to upstream? Thanks On 2017年06月09日

Re: [PATCH v3 3/6] drm/bridge/synopsys: Add MIPI DSI host controller bridge

Hi Phillipe, Thanks for the clean ups. Some comments inline. On 06/02/2017 08:07 PM, Philippe CORNU wrote: Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. Signed-off-by: Philippe CORNU

[PATCH 28/44] sparc: remove arch specific dma_supported implementations

Usually dma_supported decisions are done by the dma_map_ops instance. Switch sparc to that model by providing a ->dma_supported instance for sbus that always returns false, and implementations tailored to the sun4u and sun4v cases for sparc64, and leave it unimplemented for PCI on sparc32, which

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/intel_engine_cs.c between commit: ef6c4d75e353 ("drm/i915: fix warning for unused variable") from the drm-intel-fixes tree and commit: a8e9a419c337 ("drm/i915: Lie and treat all engines as idle if

[PATCH 26/44] dma-mapping: remove DMA_ERROR_CODE

And update the documentation - dma_mapping_error has been supported everywhere for a long time. Signed-off-by: Christoph Hellwig --- Documentation/DMA-API-HOWTO.txt | 31 +-- include/linux/dma-mapping.h | 5 - 2 files changed, 5 insertions(+),

[PATCH 15/44] xtensa: remove DMA_ERROR_CODE

xtensa already implements the mapping_error method for its only dma_map_ops instance. Signed-off-by: Christoph Hellwig --- arch/xtensa/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/xtensa/include/asm/dma-mapping.h

[PATCH 11/44] m32r: remove DMA_ERROR_CODE

dma-noop is the only dma_mapping_ops instance for m32r and does not return errors. Signed-off-by: Christoph Hellwig --- arch/m32r/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/m32r/include/asm/dma-mapping.h

[PATCH 34/44] arm: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that the code seems a little fishy for dmabounce and iommu, but for now I'd like to preserve the existing behavior 1:1. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 1 +

[PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 2 -- arch/hexagon/kernel/dma.c | 9 - 2

[PATCH 05/44] drm/armada: don't abuse DMA_ERROR_CODE

dev_addr isn't even a dma_addr_t, and DMA_ERROR_CODE has never been a valid driver API. Add a bool mapped flag instead. Signed-off-by: Christoph Hellwig --- drivers/gpu/drm/armada/armada_fb.c | 2 +- drivers/gpu/drm/armada/armada_gem.c | 5 ++---

[PATCH 33/44] openrisc: remove arch-specific dma_supported implementation

This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/dma-mapping.h | 7 --- 1 file changed, 7 deletions(-) diff --git

[PATCH 40/44] tile: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- arch/tile/kernel/pci-dma.c | 30 -- 1 file changed, 30 deletions(-) diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c index

[PATCH 43/44] dma-mapping: remove the set_dma_mask method

Signed-off-by: Christoph Hellwig --- arch/powerpc/kernel/dma.c | 4 include/linux/dma-mapping.h | 6 -- 2 files changed, 10 deletions(-) diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c index 41c749586bd2..466c9f07b288 100644 ---

[PATCH v2 0/4] Add RK3399 HDMI Support

RK3399 and RK3288 shared the same HDMI IP controller, only some light difference with GRF configure, and an external VPLL clock need to configure. base on Yakir's v1 thread: http://lkml.iu.edu/hypermail/linux/kernel/1607.1/01468.html Some Yakir's hdmi patches cause hdmi no display on my test,

Re: clean up and modularize arch dma_mapping interface

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:25 +0200 > for a while we have a generic implementation of the dma mapping routines > that call into per-arch or per-device operations. But right now there > still are various bits in the interfaces where don't clearly operate >

Re: [PATCH 27/44] sparc: remove leon_dma_ops

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:52 +0200 > We can just use pci32_dma_ops. > > Btw, given that leon is 32-bit and appears to be PCI based, do even need > the special case for it in get_arch_dma_ops at all? I would need to defer to the LEON developers on that,

Re: [PATCH 02/44] ibmveth: properly unwind on init errors

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:27 +0200 > That way the driver doesn't have to rely on DMA_ERROR_CODE, which > is not a public API and going away. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller

Re: [PATCH 28/44] sparc: remove arch specific dma_supported implementations

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:53 +0200 > Usually dma_supported decisions are done by the dma_map_ops instance. > Switch sparc to that model by providing a ->dma_supported instance for > sbus that always returns false, and implementations tailored to the sun4u

Re: [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

Hi Christoph, On 08/06/17 14:25, Christoph Hellwig wrote: > DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu > driver already implements a proper ->mapping_error method, so it's only > using the value internally. Add a new local define using the value > that arm64 which

Re: [PATCH 16/44] arm64: remove DMA_ERROR_CODE

On 08/06/17 14:25, Christoph Hellwig wrote: > The dma alloc interface returns an error by return NULL, and the > mapping interfaces rely on the mapping_error method, which the dummy > ops already implement correctly. > > Thus remove the DMA_ERROR_CODE define. Reviewed-by: Robin Murphy

Re: [PATCH 20/44] sparc: implement ->mapping_error

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:45 +0200 > DMA_ERROR_CODE is going to go away, so don't rely on it. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller ___ dri-devel

[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive

https://bugzilla.kernel.org/show_bug.cgi?id=150731 Luke A. Guest (lagu...@archeia.com) changed: What|Removed |Added CC||lagu...@archeia.com

[PULL] drm-intel-fixes

Hi Dave, fixes all around for drm/i915, half stable, half for this merge window. There's a last minute build warning fix on top that I failed to notice earlier, everything else was pushed earlier. BR, Jani. The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f: Linux

[Bug 195321] nouveau?/DRI3?: dual monitors unusable without running compton --paint-on-overlay

https://bugzilla.kernel.org/show_bug.cgi?id=195321 Ilia Mirkin (imir...@alum.mit.edu) changed: What|Removed |Added CC||imir...@alum.mit.edu

[PATCH] drm/imx: lock scanout transfers for consecutive bursts

Because of its shallow queues and limited reordering ability, the i.MX6Q memory controller likes AXI bursts of consecutive addresses a lot. To optimize memory access performance, lock the IPU scanout channels for a number of burst accesses each, before switching to the next channel. The burst size

[PATCH v2 1/4] drm/panel: simple: add support for NEC NL12880B20-05

This adds support for the NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel, which can be supported by the simple panel driver. Signed-off-by: Lucas Stach --- v2: new patch in V2 --- .../bindings/display/panel/nec,nl12880b20-05.txt | 8 ++

[PATCH v2 3/4] drm/panel: simple: add support for NLT NL192108AC18-02D

This adds support for the NLT Technologies NL192108AC18-02D 15.6" LVDS FullHD TFT LCD panel, which can be supported by the simple panel driver. Timings are taken from the preliminary datasheet, as a final one is not yet available. Signed-off-by: Lucas Stach --- v2:

[PATCH v2 2/4] dt-bindings: add vendor prefix for NLT Technologies, Ltd.

NLT technologies is the former NEC display business, but changed its name to NLT Technologies when forming a joint venture with Shenzhen AVIC OPTOELECTRONICS, Ltd. Signed-off-by: Lucas Stach Acked-by: Rob Herring --- v2: no change ---

[PATCH v2 4/4] drm/panel: simple: add support for AUO P320HVN03

This adds support for the AU Optronics Corporation 31.5" FHD (1920x1080) LVDS TFT LCD panel, which can be supported by the simple panel driver Signed-off-by: Lucas Stach --- v2: mention power-supply property --- .../bindings/display/panel/auo,p320hvn03.txt | 8

[PATCH v2 4/4] drm/tinydrm: Add RePaper e-ink driver

This adds support for the Pervasive Displays RePaper branded displays. The controller code is taken from the userspace driver available through repaper.org. Only the V231 film is supported since the others are EOL. Signed-off-by: Noralf Trønnes --- MAINTAINERS

Re: [PATCH v3 2/6] dt-bindings: display: Add Synopsys DW MIPI DSI DRM bridge driver

On Fri, Jun 02, 2017 at 04:37:11PM +0200, Philippe CORNU wrote: > This patch adds documentation of device tree bindings for the > Synopsys DesignWare MIPI DSI host DRM bridge driver. > > Signed-off-by: Philippe CORNU > --- > .../bindings/display/bridge/dw_mipi_dsi.txt

[PATCH v2 0/4] drm/tinydrm: Add support for Pervasive Displays RePaper monochrome e-ink panels

This adds support for the 1.44", 1.9", 2.0" and 2.7" Pervasive Diplays monochrome e-ink panels. The code was taken from the userspace driver available through repaper.org. Monochrome Since drm doesn't have support for monochrome, I have added a helper to convert XRGB to greyscale8. XRGB

[PATCH v2 3/4] drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helper

Drm has no monochrome or greyscale support so add a conversion from the common format XR24. Also reorder includes into the common order. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 74 +-

[PATCH v2 1/4] of: Add vendor prefix for Pervasive Displays

Pervasive Displays Inc. designs, develops, and manufactures low-power electrophoretic (e-ink) display modules and supporting electronics for commercial and industrial display applications. Signed-off-by: Noralf Trønnes Acked-by: Rob Herring ---

[PATCH v2 2/4] dt-bindings: Add Pervasive Displays RePaper bindings

Add device-tree binding documentation for the 1.44", 1.9", 2.0" and 2.7" display panels. Signed-off-by: Noralf Trønnes Acked-by: Rob Herring --- .../devicetree/bindings/display/repaper.txt| 52 ++ 1 file changed, 52 insertions(+)

[pull] radeon and amdgpu drm-next-4.13

Hi Dave, New radeon and amdgpu features for 4.13: - Lots of Vega10 bug fixes - Preliminary Raven support - KIQ support for compute rings - MEC queue management rework from Andres - Audio support for DCE6 - SR-IOV improvements - Improved module parameters for controlling radeon vs amdgpu support

Re: [PATCH v3 5/6] dt-bindings: display: stm32: Add DSI host driver

On Fri, Jun 02, 2017 at 04:37:14PM +0200, Philippe CORNU wrote: > This patch adds documentation of device tree bindings for the STM32 > DSI host driver based on the Synopsys DW MIPI DSI bridge driver. > --- > .../devicetree/bindings/display/st,stm32-ltdc.txt | 83 > +- > 1

[Bug 195321] nouveau?/DRI3?: dual monitors unusable without running compton --paint-on-overlay

https://bugzilla.kernel.org/show_bug.cgi?id=195321 --- Comment #4 from Jimi (jimijames.b...@gmail.com) --- I can't just never upgrade my kernel ever again... -- You are receiving this mail because: You are watching the assignee of the bug. ___

  1   2   >