linux-toradex.git/drivers/dma/hsu, branch v4.5

dmaengine: hsu: speed up residue calculation

2015-12-05T08:30:34+00:00

There is no need to calculate an overall length of the descriptor each time we
call for DMA transfer status. Instead we do this at descriptor allocation stage
and keep the stored length for further usage.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: hsu: remove platform data

2015-10-18T04:22:08+00:00

There are no platforms where it's not possible to calculate
the number of channels based on IO space length, and since
that is the only purpose for struct hsu_dma_platform_data,
removing it.

Suggested-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
Acked-by: Vinod Koul 
Acked-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

dmaengine: hsu: make the UART driver in control of selecting this driver

2015-10-18T04:22:08+00:00

HSU (High Speed UART) DMA engine, like the name suggests, is
an integrated DMA engine for UART and UART alone. Therefore,
making the UART drivers responsible of selecting it and
removing the user selectable option for it. The UARTs with
this DMA engine can always select HSU_DMA when
SERIAL_8250_DMA option is enabled.

Suggested-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
Acked-by: Vinod Koul 
Acked-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

dmaengine: hsu: remove excessive lock

2015-07-16T13:00:46+00:00

All hardware accesses are done under virtual channel lock. That's why specific
channel lock is excessive and can be removed safely. This has been tested on
Intel Medfield and Merrifield.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: hsu: Fix memory leak when stopping a running transfer

2015-06-02T13:03:08+00:00

The vd->node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.

Signed-off-by: Peter Ujfalusi 
[andy: fix the typo to prevent a compilation error]
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: hsu: don't prompt for hsu_core part

2015-04-22T16:28:32+00:00

HSU_DMA is selected by the HSU_DMA_PCI driver, this should be user selected
so remove the user prompt for this

Signed-off-by: Vinod Koul 
Signed-off-by: Linus Torvalds

dmaengine: hsu: move memory allocation to GFP_NOWAIT

2015-03-26T22:02:49+00:00

The GFP_ATOMIC is too strict, and DMAEngine documentation make an advice to use
GFP_NOWAIT. This patch does the conversion.

Signed-off-by: Andy Shevchenko 
Acked-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: hsu: remove redundant pieces of code

2015-03-26T22:02:48+00:00

There are few places where the implemented pieces of code are not needed, i.e.:
- direction can't be wrong in hsu_dma_chan_start()
- desc->active set to 0 by kzalloc
- DMAEngine is NULL-aware when call ->device_alloc_chan_resources()

Signed-off-by: Andy Shevchenko 
Acked-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: hsu: add Intel Tangier PCI ID

2015-03-26T22:01:37+00:00

Intel Tangier is known to have the HSU DMA IP as PCI device 00:05.0. The patch
adds the ID as found on Intel Edison board to the PCI device table.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

dmaengine: append hsu DMA driver

2015-03-07T02:23:02+00:00

The HSU DMA is developed to support High Speed UART controllers found in
particular on Intel MID platforms such as Intel Medfield.

The existing implementation is tighten to the drivers/tty/serial/mfd.c driver
and has a lot of disadvantages. Besides that we would like to get rid of the
old HS UART driver in regarding to extending the 8250 which supports generic
DMAEngine API. That's why the current driver has been developed.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman