From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Olof Johansson <olof@lixom.net>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
linux-omap <linux-omap@vger.kernel.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
"Koul, Vinod" <vinod.koul@intel.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Sekhar Nori <nsekhar@ti.com>, Liam Girdwood <lgirdwood@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Kevin Hilman <khilman@deeprootsystems.com>,
Tony Lindgren <tony@atomide.com>, Mark Brown <broonie@kernel.org>,
Chris Ball <chris@printf.net>,
"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
linux-spi@vger.kernel.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/3] ARM: edma: Split up header file to platform_data and API file
Date: Mon, 26 Jan 2015 09:29:56 +0200 [thread overview]
Message-ID: <54C5ECF4.10709@ti.com> (raw)
In-Reply-To: <CAOesGMgdLB9WkOwCt__iRMnTYZ-tMNS==FL+b6s3CzHK4b0MYQ@mail.gmail.com>
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@ti.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
WARNING: multiple messages have this Message-ID (diff)
From: peter.ujfalusi@ti.com (Peter Ujfalusi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: edma: Split up header file to platform_data and API file
Date: Mon, 26 Jan 2015 09:29:56 +0200 [thread overview]
Message-ID: <54C5ECF4.10709@ti.com> (raw)
In-Reply-To: <CAOesGMgdLB9WkOwCt__iRMnTYZ-tMNS==FL+b6s3CzHK4b0MYQ@mail.gmail.com>
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@ti.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
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Olof Johansson <olof@lixom.net>
Cc: Mark Brown <broonie@kernel.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Sekhar Nori <nsekhar@ti.com>, Arnd Bergmann <arnd@arndb.de>,
"Koul, Vinod" <vinod.koul@intel.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
Liam Girdwood <lgirdwood@gmail.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Chris Ball <chris@printf.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
<linux-spi@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
Tony Lindgren <tony@atomide.com>,
"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>
Subject: Re: [PATCH 3/3] ARM: edma: Split up header file to platform_data and API file
Date: Mon, 26 Jan 2015 09:29:56 +0200 [thread overview]
Message-ID: <54C5ECF4.10709@ti.com> (raw)
In-Reply-To: <CAOesGMgdLB9WkOwCt__iRMnTYZ-tMNS==FL+b6s3CzHK4b0MYQ@mail.gmail.com>
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@ti.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
next prev parent reply other threads:[~2015-01-26 7:30 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 10:41 [PATCH 0/3] ARM: edma: Correct header file usage Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
[not found] ` <1417084891-17990-1-git-send-email-peter.ujfalusi-l0cyMroinI0@public.gmane.org>
2014-11-27 10:41 ` [PATCH 1/3] ASoC: davinci-evm: Do not include edma headers Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-11-27 10:58 ` Mark Brown
2014-11-27 10:58 ` Mark Brown
2014-11-27 10:58 ` Mark Brown
2014-11-27 10:41 ` [PATCH 2/3] ARM: edma: Rename header file for dmaengine filter function definition Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-11-27 11:14 ` Arnd Bergmann
2014-11-27 11:14 ` Arnd Bergmann
2014-11-27 14:23 ` Peter Ujfalusi
2014-11-27 14:23 ` Peter Ujfalusi
2014-11-27 14:23 ` Peter Ujfalusi
2014-11-27 14:50 ` Arnd Bergmann
2014-11-27 14:50 ` Arnd Bergmann
2014-11-27 14:50 ` Arnd Bergmann
2014-11-27 18:46 ` Peter Ujfalusi
2014-11-27 18:46 ` Peter Ujfalusi
2014-11-27 18:46 ` Peter Ujfalusi
2014-11-27 18:46 ` Peter Ujfalusi
[not found] ` <54777174.4070203-l0cyMroinI0@public.gmane.org>
2014-11-27 21:52 ` Arnd Bergmann
2014-11-27 21:52 ` Arnd Bergmann
2014-11-27 21:52 ` Arnd Bergmann
2014-11-28 7:16 ` Peter Ujfalusi
2014-11-28 7:16 ` Peter Ujfalusi
2014-11-28 7:16 ` Peter Ujfalusi
2014-11-28 10:51 ` Arnd Bergmann
2014-11-28 10:51 ` Arnd Bergmann
2014-11-28 11:48 ` Peter Ujfalusi
2014-11-28 11:48 ` Peter Ujfalusi
2014-11-28 11:48 ` Peter Ujfalusi
2014-11-28 10:57 ` Ulf Hansson
2014-11-28 10:57 ` Ulf Hansson
2014-11-27 10:41 ` [PATCH 3/3] ARM: edma: Split up header file to platform_data and API file Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-11-27 10:41 ` Peter Ujfalusi
2014-12-08 12:49 ` Vinod Koul
2014-12-08 12:49 ` Vinod Koul
[not found] ` <20141208124917.GI16827-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-12-08 13:16 ` Arnd Bergmann
2014-12-08 13:16 ` Arnd Bergmann
2014-12-08 13:16 ` Arnd Bergmann
2014-12-30 13:17 ` Peter Ujfalusi
2014-12-30 13:17 ` Peter Ujfalusi
2014-12-30 13:17 ` Peter Ujfalusi
2015-01-22 1:40 ` Olof Johansson
2015-01-22 1:40 ` Olof Johansson
2015-01-26 7:29 ` Peter Ujfalusi [this message]
2015-01-26 7:29 ` Peter Ujfalusi
2015-01-26 7:29 ` Peter Ujfalusi
2015-01-14 9:51 ` [PATCH 0/3] ARM: edma: Correct header file usage Sekhar Nori
2015-01-14 9:51 ` Sekhar Nori
2015-01-14 9:51 ` Sekhar Nori
2015-01-14 9:51 ` Sekhar Nori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54C5ECF4.10709@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=chris@printf.net \
--cc=dmaengine@vger.kernel.org \
--cc=khilman@deeprootsystems.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nsekhar@ti.com \
--cc=olof@lixom.net \
--cc=tony@atomide.com \
--cc=ulf.hansson@linaro.org \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.