Message-ID: <54C5ECF4.10709@ti.com>
Date:	Mon, 26 Jan 2015 09:29:56 +0200
From:	Peter Ujfalusi <peter.ujfalusi@...com>
To:	Olof Johansson <olof@...om.net>
CC:	Mark Brown <broonie@...nel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Sekhar Nori <nsekhar@...com>, Arnd Bergmann <arnd@...db.de>,
	"Koul, Vinod" <vinod.koul@...el.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Chris Ball <chris@...ntf.net>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	<linux-spi@...r.kernel.org>,
	linux-omap <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>
Subject: Re: [PATCH 3/3] ARM: edma: Split up header file to platform_data
 and API file

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@...com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists