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.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
