* 'next' of git://git.infradead.org/users/vkoul/slave-dma: (53 commits)
  ARM: mach-shmobile: specify CHCLR registers on SH7372
  dma: shdma: fix runtime PM: clear channel buffers on reset
  dma/imx-sdma: save irq flags when use spin_lock in sdma_tx_submit
  dmaengine/ste_dma40: clear LNK on channel startup
  dmaengine: intel_mid_dma: remove legacy pm interface
  ASoC: mxs: correct 'direction' of device_prep_dma_cyclic
  dmaengine: intel_mid_dma: error path fix
  dmaengine: intel_mid_dma: locking and freeing fixes
  mtd: gpmi-nand: move to dma_transfer_direction
  mtd: fix compile error for gpmi-nand
  mmc: mxs-mmc: fix the dma_transfer_direction migration
  dmaengine: add DMA_TRANS_NONE to dma_transfer_direction
  dma: mxs-dma: Don't use CLKGATE bits in CTRL0 to disable DMA channels
  dma: mxs-dma: make mxs_dma_prep_slave_sg() multi user safe
  dma: mxs-dma: Always leave mxs_dma_init() with the clock disabled.
  dma: mxs-dma: fix a typo in comment
  DMA: PL330: Remove pm_runtime_xxx calls from pl330 probe/remove
  video i.MX IPU: Fix display connections
  i.MX IPU DMA: Fix wrong burstsize settings
  dmaengine/ste_dma40: allow fixed physical channel
  ...

Fix up conflicts in drivers/dma/{Kconfig,mxs-dma.c,pl330.c}

The conflicts looked pretty trivial, but I'll ask people to verify them.

This adds initial support for requesting the various GPIO functions
necessary for certain ports. This just plugs in dumb request/free logic,
but serves as a building block for migrating off of the ->init_pins mess
to a wholly gpiolib backed solution (primarily parts with external
RTS/CTS pins, but will also allow us to clean up RXD pin testing).

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

When toggling the MCE support we don't want to concern ourselves with the
FIFO state, so ensure that the clearing bits are masked out when updating
the MCE state.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

The bulk of the ports do not support any sort of modem control, so
blindly twiddling the MCE bit doesn't accomplish much. We now require
ports to manually specify which line supports modem control signals.

While at it, tidy up the RTS/CTSIO handling in SCSPTR parts so it's a bit
more obvious what's going on (and without clobbering other configurations
in the process).

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

This plugs in loopback control for SCFCR-enabled ports and plugs it in
via the TIOCM_LOOP control, as others do.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

At the moment things like CTS/RTS are reported for all ports, while the
vast majority of them do not implement support at all (and others
implement support entirely in hardware). Fix up the ->get_mctrl()
reporting to simply assert DSR/CAR as other drivers without control
lines do.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

Technically there's nothing we can do for either of these, so update the
comments to reflect this, rather than infering that there's additional
work to be done.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

Presently the icount stats are only adjusted for the rx/tx case, this
makes sure that they're updated appropriately for the non-tx/rx cases,
too (specifically overruns, breaks, as well as frame and parity errors).

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

Presently there are a few places that make assumptions about the
existence of SCFCR, which doesn't hold true for several port types. While
generally harmless, this does lead to bogus reads/writes in both the
termios/runtime PM cases that are better off simply never being made in
the first place.

While we're at it, also get rid of a straggling PORT_SCI check that
infers all non-SCI ports contain SCFCR. This doesn't presently have any
impact, but as we're now able to test for the existence of registers
without defering to the port type we future proof for additional port
types.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

resolved conflicts:
	drivers/media/video/mx3_camera.c