- 03 2月, 2012 1 次提交
-
-
由 Heiko Schocher 提交于
Default queue is expected to be a low-priority queue. This way, long transfers on the default queue started by the codec engine will not cause audio defects. Signed-off-by: NHeiko Schocher <hs@denx.de> Signed-off-by: NJuha Kuikka <juha.kuikka@gmail.com> Reported-by: NJuha Kuikka <juha.kuikka@gmail.com> Acked-by: NRajashekhara, Sudhakar <sudhakar.raj@ti.com> Cc: linux-mmc@vger.kernel.org Cc: davinci-linux-open-source@linux.davincidsp.com Cc: linux-arm-kernel@lists.infradead.org Cc: Rajashekhara, Sudhakar <sudhakar.raj@ti.com> Cc: Ido Yariv <ido@wizery.com> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Sergei Shtylyov <sshtylyov@mvista.com> Signed-off-by: NSekhar Nori <nsekhar@ti.com>
-
- 12 3月, 2011 1 次提交
-
-
由 Michael Williamson 提交于
The DA830_edma_ch enum set is not used. Remove it. Signed-off-by: NMichael Williamson <michael.williamson@criticallink.com> Acked-by: NSekhar Nori <nsekhar@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 06 8月, 2010 2 次提交
-
-
由 Rajashekhara, Sudhakar 提交于
Current EDMA driver is not taking care of EDMA channels/slots which are allocated from other processor, say DSP. If a channel/slot is allocated from DSP, the existing EDMA driver can still allocate the same resource on ARM. This patch enables the user to pass the channel/slots reserved for DSP as platform data. EDMA driver scans this list during probe and prepares a bitmap of channel/slots which can be used on ARM side. Trying to reserve channels by doing a 'pre-allocate' using edma_alloc_{slot|channel}() API does not work because 1) The reservation should be done in probe() to avoid race with other ARM side driver trying to use EDMA 2) The alloc channel API sets up the access through shadow region 0 which will be incorrect for DSP usage. It also sets up the channel <-> queue number mapping which is not required as DSP will likely do its own mapping anyway. 3) (minor) There is no API to allocate channels in bulk. Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: NSekhar Nori <nsekhar@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Sekhar Nori 提交于
This patch modifies the EDMA driver to expect the channel controller (CC) infomation passed on by the platform as a fixed size (EDMA_MAX_CC) array of pointers to structures. Doing so helps catch errors of the sort where the resource structure has information for more channel controllers than the number channel controller info structures defined. Such insufficient platform data would lead to illegal memory accesses. Signed-off-by: NSekhar Nori <nsekhar@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
- 05 2月, 2010 1 次提交
-
-
由 Sudhakar Rajashekhara 提交于
Currently, the edma_noevent list is passed from platform data. But on some architectures, there will be many EDMA channels which will not be used at all. This patch scans all the platform devices and then builds a list of events which are not being used. The unused event list will be used to allocate EDMA channels in case of EDMA_CHANNEL_ANY usage instead of the edma_noevent being used earlier for this purpose. This patch is based on David Brownells's suggestion at http://article.gmane.org/gmane.linux.davinci/15176. Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
- 26 8月, 2009 5 次提交
-
-
由 Sandeep Paulraj 提交于
For best performance, codecs often setup linked triggered transfers with a contiguous block of params, and that is when this API is used. Setup/configuration of these parameter RAMs is most efficient if they are contiguous. There is an API to allocate a set of contiguous parameter RAMs and a corresponding API to free a set of contiguous parameter RAMs Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Sandeep Paulraj 提交于
EDMA queues in DM365 are a little different than those on other DaVinci's. On DM365 Q0 and Q1 have the larger FIFO size. We want Q0 and Q1 to be used by codecs and DVSDK demos. MMC driver is the only driver which uses the flag 'EVENTQ_DEFAULT'. So MMC driver should be using Q2 instead of Q1 on DM365. This patch allows us to declare a "default queue" from SOC specific code. If it is not declared then the EDMA driver assumes a default of queue 1. Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Sandeep Paulraj 提交于
DM365 and DM6467 have 4 queues. The patch updates the 'dma_event_q' enum to reflect this. Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Mark A. Greer 提交于
The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: NSteve Chen <schen@mvista.com> Signed-off-by: NMikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: NMark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Sudhakar Rajashekhara 提交于
- restructure to support multiple channel controllers by using additional struct resources for each CC - interface changes visible to EDMA clients Introduce macros to build IDs from controller and channel number, and to extract them. Modify the edma_alloc_slot function to take an extra argument for the controller. Also update ASoC drivers to use API. ASoC changes Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> - Move queue related mappings to dm<soc>.c EDMA in DM355 and DM644x has two transfer controllers while DM646x has four transfer controllers. Moving the queue to tc mapping and queue priority mapping to dm<soc>.c will be helpful to probe these mappings from platform device so that the machine_is_* testing will be avoided. - add channel mapping logic Channel mapping logic is introduced in dm646x EDMA. This implies that there is no fixed association for a channel number to a parameter entry number. In other words, using the DMA channel mapping registers (DCHMAPn), a PaRAM entry can be mapped to any channel. While in the case of dm644x and dm355 there is a fixed mapping between the EDMA channel and Param entry number. Signed-off-by: NNaresh Medisetty <naresh@ti.com> Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com> Reviewed-by: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
- 29 5月, 2009 1 次提交
-
-
由 David Brownell 提交于
Remove remnants of dm6446-specific SRAM allocator, as preparation for a more generic replacement. Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
- 28 4月, 2009 1 次提交
-
-
由 Kevin Hilman 提交于
Original code for 2.6.10 and 2.6.28 series done by Texas Instruments and MontaVista, but major updates and rework done by Troy Kisky and David Brownell. Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Troy Kisky <troy.kisky@boundarydevices.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-