Hi, On 01/22/2015 03:40 AM, Olof Johansson wrote: > Hi, > > On Thu, Nov 27, 2014 at 2:41 AM, Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote: >> include/linux/platform_data/ is not a correct place to keep the API >> definitions for edma, it is meant to be only for the pdata for the device. >> Clean up this by moving the API to include/linux/edma.h > > It's a nice net improvement, but it moves some things that should be > in _neither_ location to a new place where it doesn't belong either -- > and the new location is even more global. See below. > > ... > >> diff --git a/include/linux/edma.h b/include/linux/edma.h >> new file mode 100644 >> index 000000000000..9df92198c117 >> --- /dev/null >> +++ b/include/linux/edma.h >> @@ -0,0 +1,153 @@ >> +/* >> + * TI EDMA definitions >> + * >> + * Copyright (C) 2006-2013 Texas Instruments. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License as >> + * published by the Free Software Foundation version 2. >> + * >> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any >> + * kind, whether express or implied; without even the implied warranty >> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +/* >> + * This EDMA3 programming framework exposes two basic kinds of resource: >> + * >> + * Channel Triggers transfers, usually from a hardware event but >> + * also manually or by "chaining" from DMA completions. >> + * Each channel is coupled to a Parameter RAM (PaRAM) slot. >> + * >> + * Slot Each PaRAM slot holds a DMA transfer descriptor (PaRAM >> + * "set"), source and destination addresses, a link to a >> + * next PaRAM slot (if any), options for the transfer, and >> + * instructions for updating those addresses. There are >> + * more than twice as many slots as event channels. >> + * >> + * Each PaRAM set describes a sequence of transfers, either for one large >> + * buffer or for several discontiguous smaller buffers. An EDMA transfer >> + * is driven only from a channel, which performs the transfers specified >> + * in its PaRAM slot until there are no more transfers. When that last >> + * transfer completes, the "link" field may be used to reload the channel's >> + * PaRAM slot with a new transfer descriptor. >> + * >> + * The EDMA Channel Controller (CC) maps requests from channels into physical >> + * Transfer Controller (TC) requests when the channel triggers (by hardware >> + * or software events, or by chaining). The two physical DMA channels provided >> + * by the TCs are thus shared by many logical channels. >> + * >> + * DaVinci hardware also has a "QDMA" mechanism which is not currently >> + * supported through this interface. (DSP firmware uses it though.) >> + */ >> + >> +#ifndef __LINUX_EDMA_H_ >> +#define __LINUX_EDMA_H_ >> + >> +#include <linux/platform_data/edma.h> >> + >> +/* PaRAM slots are laid out like this */ >> +struct edmacc_param { >> + u32 opt; >> + u32 src; >> + u32 a_b_cnt; >> + u32 dst; >> + u32 src_dst_bidx; >> + u32 link_bcntrld; >> + u32 src_dst_cidx; >> + u32 ccnt; >> +} __packed; >> + >> +/* fields in edmacc_param.opt */ >> +#define SAM BIT(0) >> +#define DAM BIT(1) >> +#define SYNCDIM BIT(2) >> +#define STATIC BIT(3) >> +#define EDMA_FWID (0x07 << 8) >> +#define TCCMODE BIT(11) >> +#define EDMA_TCC(t) ((t) << 12) >> +#define TCINTEN BIT(20) >> +#define ITCINTEN BIT(21) >> +#define TCCHEN BIT(22) >> +#define ITCCHEN BIT(23) > > This seems like the kind of thing that should go with the edma driver > instead of being globally exported to the kernel through a > include/linux header file. Currently the edmacc_param struct is used by arch/arm/common/edma.c, drivers/dma/edma.c and the sound/soc/davinci/davinci-pcm.c For now this has to be in a global header file. Even with my local VIP branch where I had removed the davinci-pcm already the two drivers for edma needs this in global header file. I can assure you, it will be gone (along with the arch/arm/common/edma.c) but not right away. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html