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 | 8 + drivers/gpu/drm/s

[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 f

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 Noralf! On Wed, Jun 7, 201

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 ac

[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 following

[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: L

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 v

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 inter

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 is

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 > Signed-

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 > on these ops.

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 ___ dri-devel mail

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, but they haven'

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 > and sun4v ca

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 mailing list dri-devel@lists.freedesktop.org https:

[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 4

[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 is

[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 +- include/drm/tinydrm/tinydrm-helpers.h

[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 --- Documentation/devicetree/bindings/vendor-prefixes.

[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 |6 + dri

[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(+) create mode 100644 Documentation/dev

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| 30 >

[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

[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. ___ dri-deve

[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

Re: [PATCH v3 4/6] dt-bindings: display: stm32: remove st-display-subsystem parent node requirement

On Fri, Jun 02, 2017 at 04:37:13PM +0200, Philippe CORNU wrote: > There is no need anymore to have a "st-display-subsystem" parent node > in the device tree for the ltdc. > > Signed-off-by: Philippe CORNU > --- > Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 1 - > 1 file changed

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 fi

[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 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 ++ drivers/gpu/drm/pane

[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 ++ drivers/gpu/drm/panel/panel-sim

[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: mention power-supply property

[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 --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +

Re: [PATCH v5 1/2] drm: Add const to name field declaration in struct drm_prop_enum_list

On Tue, May 30, 2017 at 07:29:55PM +0300, Jyri Sarha wrote: > There is no reason why the name field should not be const, but > several why it should. The struct should only be used by > drm_property_create_enum() and there the name-field from the struct > is passed to drm_property_add_enum(), which

Re: [PATCH v5 2/2] drm: Add optinal COLOR_ENCODING and COLOR_RANGE properties to drm_plane

On Tue, May 30, 2017 at 07:29:56PM +0300, Jyri Sarha wrote: > Add a standard optional properties to support different non RGB color > encodings in DRM planes. COLOR_ENCODING select the supported non RGB > color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects > the value ranges within

[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)

https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #7 from Julien Isorce --- Hi Luke, any chance you can try the apitrace https://bugs.freedesktop.org/show_bug.cgi?id=100712#c7 ? What worked for me on that bug was to disable write-combining by setting the env var R600_DEBUG=nowc for

Re: [PATCH 19/37] drm/fsl: Drop drm_vblank_cleanup

On 2017-05-31 01:52, Daniel Vetter wrote: > On Tue, May 30, 2017 at 02:17:04PM -0700, Stefan Agner wrote: >> On 2017-05-26 00:00, Daniel Vetter wrote: >> > On Thu, May 25, 2017 at 10:18 AM, Stefan Agner wrote: >> >> On 2017-05-24 07:51, Daniel Vetter wrote: >> >>> Again cleanup before irq disablin

Re: [PATCH 1/2] drm/fsl-dcu: implement irq_preinstall/uninstall callbacks

On 2017-06-01 20:00, Stefan Agner wrote: > Make use of the irq_preinstall/uninstall callback to clear and > mask all interrupts. Use write 1 to clear as documented by the > data sheet (writing a 0 seems to have cleared interrupt status > too). Remove fsl_dcu_drm_irq_init and call drm_irq_install >

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

Hi Dave, Just some cleanup/fixes this time around. -- Stefan The following changes since commit c9f0726ff360cf75aaafd326e439e9234630aee9: Merge tag 'exynos-drm-next-for-v4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2017-06-06 16:54:27 +1000) are

[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #29 from MirceaKitsune --- An update: The latest reimplementation of the freeze appears to be worse than all others. My system can now be taken down after only 4 hours of uptime! This is a huge difference from all previous versions o

[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 --- arch/x86/include/asm/iommu.h

[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 +++ b/arch/c6x/

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 +++- > 1 file chang

[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 --- a/drivers/xen/swiotlb

[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 feat

[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 73ec3c6f4cfe..3ce

[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 @@ -549,7 +54

[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 | 1 - arch/arm

[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 a/drivers/dma/ioat/init.c b/drivers/dm

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 yet,

[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 a88952ef371c..085fe6ce4049 10064

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 0c0075f17145..a4ea139c2ef9

[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 -- arch/s390/pci/pci

[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| 14 ++--

[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 +++ b/lib/dma-noop

[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 a/drivers/net/e

[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 3fad5e722a66..e15cd

[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 --- arch/powerpc/include/asm/dma-map

[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 a/arch/hexagon/include/asm/dma-mapping.h b/ar

[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 Hell

[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 a/arch/powerpc/platforms/cel

[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 +++ b/lib/dma-virt

[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 29ecfd815320..a01461d63f68 100644 ---

[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 b/arch/powerpc/include/asm/dma-mapping.h index 73a

[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 63cacf5d6cf2..d41280e869de 1

[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 --- a/arch/sh/inc

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 + 2 files

[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 He

[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 --- a/arch/hexagon/include/asm/dma-mapping.h +++

[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 --- a/arch/arm/commo

[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 return

[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 b/arch/mips/loongson64/common/dma-swiotlb.c ind

[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 b/arch/x86/kernel/pci-calgary_64.c index f

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: Christoph Hell

[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 a0f006daab48..c3a04b2d7532 100644

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 the sun4u > an

[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 08a0838b83fb..c35

[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 xen_swiotlb_dma

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 c

[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 me

[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 --- a/arch/powerpc/kernel/dma.c +++ b/arc

[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 a/arch/openrisc/include/a

[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 569bb6dd154a..f2abe

[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 b/arch/m32r/include/asm/dma-mapping.h index c01d9f

[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 + arch/arm/include/asm/dm

[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 files changed, 11

[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 ++--- drivers/gpu/drm/armada/armada_gem.h | 1 + 3 fi

[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(+), 31 deletions(-)

[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 b/arch/xtensa/include/asm/dma-mapping.h ind

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 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,

[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 deletion(-) diff --git a/driver

[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 changed, 52 insertions(+)

[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 Changes in v2: reuse hdmi_

[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 Y

[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 Changes in v2: describe grf on

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

  1   2   >