Re: Minimal support for dm814x

Hi, * Delio Brignoli [151105 05:10]: > Hello Tony, > > We use dm814x in some of our products with a kernel based on version 2.6.37 > modified by TI and are considering moving to a current kernel version. I > recently saw this >

Re: [PATCH] Revert "ARM: dts: twl4030: Add iio properties for bci subnode"

* Sebastian Reichel [151106 08:14]: > This reverts commit af19161aaed7ff8d1a52b2e517460f2fa0774e32, > which breaks the omap3 device tree build due to a wrong reference. > > I accidently queued this change via the power supply subsystem while > telling Marek at the same time,

[PATCH v3 2/5] spi: spi-ti-qspi: add mmap mode read support

ti-qspi controller provides mmap port to read data from SPI flashes. mmap port is enabled in QSPI_SPI_SWITCH_REG. ctrl module register may also need to be accessed for some SoCs. The QSPI_SPI_SETUP_REGx needs to be populated with flash specific information like read opcode, read mode(quad, dual,

[PATCH v3 1/5] spi: introduce mmap read support for spi flash devices

In addition to providing direct access to SPI bus, some spi controller hardwares (like ti-qspi) provide special memory mapped port to accesses SPI flash devices in order to increase read performance. This means the controller can automatically send the SPI signals required to read data from the

[PATCH v3 3/5] mtd: devices: m25p80: add support for mmap read request

Certain spi controllers may support memory mapped interface to read from m25p80 type flash devices. This interface provides better read performance than regular SPI interface. Call spi_mtd_mmap_read() interface, if supported, to make use of memory-mapped interface. Signed-off-by: Vignesh R

[PATCH v3 0/5] Add memory mapped read support for ti-qspi

Changes since v2: Remove mmap_lock_mutex. Optimize enable/disable of mmap mode. Changes since v1: Introduce API in SPI core that MTD flash driver can call for mmap read instead of directly calling spi-master driver callback. This API makes sure that SPI core msg queue is locked during mmap

Re: [PATCH 1/7] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

On Fri, Nov 06, 2015 at 04:14:43PM +0100, H. Nikolaus Schaller wrote: > commit b98abe52fa8e ("Input: add common DT binding for touchscreens") > introduced common DT bindings for touchscreens [1] and a helper function to > parse the DT. > > This has been integrated and interpretation of the

Re: [PATCH 5/7] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

On Fri, Nov 06, 2015 at 04:14:47PM +0100, H. Nikolaus Schaller wrote: > commit b98abe52fa8e ("Input: add common DT binding for touchscreens") > introduced common DT bindings for touchscreens [1] and a helper function to > parse the DT. > > This has been integrated and interpretation of the

Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

Hi Tony, On Monday 12 October 2015 10:05:59 Tony Lindgren wrote: > * Tony Lindgren [150914 09:37]: > > * Suman Anna [150914 09:33]: > >> On 09/03/2015 05:34 PM, Suman Anna wrote: > >>> On 07/16/2015 07:58 AM, Tony Lindgren wrote: > * Laurent Pinchart

[PATCH] ASoC: davinci-mcasp: Fix TDM slot rx/tx mask associations

Fixes the associations between the tx_mask and rx_mask and the associated playback / capture streams during setting of the TDM slot. With this patch in place it is now possible for example to only populate tx_mask (leaving rx_mask as 0) for output-only codecs to control the TDM slot(s) the McASP

Re: [PATCH 5/7] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

Am 09.11.2015 um 18:31 schrieb Rob Herring : > On Fri, Nov 06, 2015 at 04:14:47PM +0100, H. Nikolaus Schaller wrote: >> commit b98abe52fa8e ("Input: add common DT binding for touchscreens") >> introduced common DT bindings for touchscreens [1] and a helper function to >> parse

Re: [PATCH 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel

Hi Peter, Thank you for the patch. What happened to this patch series ? It looks like dma_request_slave_channel_compat_reason() isn't in mainline, so I can't apply this patch. I'll mark this patch as deferred in patchwork, please resubmit it if you resubmit the series (and by the look of it

Re: [PATCH 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel

Hi Laurent, On 11/09/2015 09:50 PM, Laurent Pinchart wrote: > Hi Peter, > > Thank you for the patch. > > What happened to this patch series ? It looks like > dma_request_slave_channel_compat_reason() isn't in mainline, so I can't apply > this patch. > > I'll mark this patch as deferred in

Re: [PATCH] ASoC: davinci-mcasp: Fix TDM slot rx/tx mask associations

On 11/09/2015 08:19 PM, Andreas Dannenberg wrote: > Fixes the associations between the tx_mask and rx_mask and the associated > playback / capture streams during setting of the TDM slot. With this > patch in place it is now possible for example to only populate tx_mask > (leaving rx_mask as 0) for

[PATCH v3 5/5] ARM: dts: AM4372: add entry for qspi mmap region

Add qspi memory mapped region entries for AM43xx based SoCs. Also, update the binding documents for the controller to document this change. Signed-off-by: Vignesh R Acked-by: Rob Herring --- Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--

[PATCH v3 4/5] ARM: dts: DRA7: add entry for qspi mmap region

Add qspi memory mapped region entries for DRA7xx based SoCs. Also, update the binding documents for the controller to document this change. Signed-off-by: Vignesh R Acked-by: Rob Herring --- Documentation/devicetree/bindings/spi/ti_qspi.txt | 14 ++

Re: [PATCH] ASoC: davinci-mcasp: Fix TDM slot rx/tx mask associations

Reviewed-by: Jyri Sarha For what little there is to review. I only had HW that worked with symmetric masks, so I did not hit this myself. Should have hacked something to codec end to be able to test asymetric masks at McASP end. Thanks, Jyri On 11/09/15 20:19, Andreas

Re: [PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges

On 11/06/2015 11:53 PM, Rob Herring wrote: > On Fri, Oct 30, 2015 at 10:00:37AM +0200, Peter Ujfalusi wrote: >> In eDMA the events are directly mapped to a DMA channel (for example DMA >> event 14 can only be handled by DMA channel 14). If the memcpy is enabled >> on the eDMA, there is a