Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
On Wed, Mar 7, 2012 at 4:03 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
[v2 - more or less same description. Including lakml in cc for the full
set]
This patch series cleans up the handling of cookies in DMA engine drivers.
This is done by providing a set of inline library functions for common
tasks:
- moving the 'last completed cookie' into struct dma_chan - everyone
has this in their driver private channel data structure
- consolidate allocation of cookies to DMA descriptors
- common way to update 'last completed cookie' value
- standard way to implement tx_status callback and update the residue
- consolidate initialization of cookies
- update implementations differing from the majority of DMA engine drivers
to behave the same as the majority implementation in respect of cookies
What this means is that we get to the point where all DMA engine drivers
will hand out cookie value '2' as the first, and incrementing cookie
values up to INT_MAX, returning to cookie '1' as the next cookie.
Think of this patch series as round 1... I am hoping over time that more
code can be consolidated between the DMA engine drivers and end up with a
consistent way to handle various common themes in DMA engine hardware
(like physical channel-peripheral request signal selection.)
Compilation is broken without the following minor fix.
After that you may add
Acked-by: Jassi Brar jassisinghb...@gmail.com
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 49c123f..abf35a3 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -339,7 +339,6 @@ static int pl330_control(struct dma_chan *chan,
enum dma_ctrl_cmd cmd, unsigned
/* Mark all desc done */
list_for_each_entry_safe(desc, _dt, pch-work_list , node) {
desc-status = DONE;
- pch-completed = desc-txd.cookie;
list_move_tail(desc-node, list);
}
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
On Wed, Mar 7, 2012 at 11:51 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, Mar 07, 2012 at 11:39:25PM +0530, Jassi Brar wrote:
Compilation is broken without the following minor fix.
After that you may add
Acked-by: Jassi Brar jassisinghb...@gmail.com
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 49c123f..abf35a3 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -339,7 +339,6 @@ static int pl330_control(struct dma_chan *chan,
enum dma_ctrl_cmd cmd, unsigned
/* Mark all desc done */
list_for_each_entry_safe(desc, _dt, pch-work_list , node) {
desc-status = DONE;
- pch-completed = desc-txd.cookie;
I'm not sure just removing this is sufficient. Presumably it's
there for some reason - maybe it needs replacing with a call to
dma_cookie_complete() to preserve existing behaviour?
That was anyway a redundant save in DMA_TERMINATE_ALL, so it should be ok.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers
On 15 October 2011 23:05, Vinod Koul vinod.k...@intel.com wrote: Another alternate approach could be to add one more argument to prep_slave_sg API which allows us to pass additional runtime specific parameters. This can be NULL and unused for existing drivers and used in RIO and any future subsystems which want to use dmaengine. Thoughts...? That doesn't sound much different than passing the data via dma_chan.private during prep_slave_sg. Only now we add to the number of arguments. And then either this argument would be RapidIO specific (unfair to other users) or generic. In latter case what would it look like ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]460EX on-chip SATA driverkernel 2.6.33resubmission
On Fri, Jun 4, 2010 at 9:26 PM, Rupjyoti Sarmah rsar...@amcc.com wrote: This patch enables the on-chip DWC SATA controller of the AppliedMicro processor 460EX. Doesn't this DWC sata IP provide AHCI ? Just curious. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]460EX on-chip SATA driver Kernel 2.6.33 resubmission
On Wed, May 19, 2010 at 6:53 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 19 May 2010 10:49:59 +0900 Jassi Brar jassisinghb...@gmail.com wrote: On Thu, May 6, 2010 at 2:57 AM, Rupjyoti Sarmah rsar...@amcc.com wrote: This patch enables the on-chip DWC SATA controller of the AppliedMicro processor 460EX. The controller seems to be a thrid party IP (from Synopsys) in your SoC and there are many chances the IP will appear in some other SOCs too. This implementation doesn't seem to take care of that scenario. I'd question if that is worth it seriously. At the point there are multiple users of the device you know what it will look like. Until then you neither know if the work is needed nor what will require abstracting. Well, am to start writing driver for some dwc sata core in near future, not sure of the exact version because I've not yet had my hands on the specs. Even if my version happens to be different, we don't wanna count on such odds. So I believe it's worthwhile. Btw, I presented two options and the author can always choose the first one - rename the driver as SoC specific. And in a way, I'd prefer that :) Lazy evaluation is good for code too ;) Apart from increasing re-usability, that POV brings out neat code too. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]460EX on-chip SATA driver Kernel 2.6.33 resubmission
On Thu, May 6, 2010 at 2:57 AM, Rupjyoti Sarmah rsar...@amcc.com wrote: This patch enables the on-chip DWC SATA controller of the AppliedMicro processor 460EX. The controller seems to be a thrid party IP (from Synopsys) in your SoC and there are many chances the IP will appear in some other SOCs too. This implementation doesn't seem to take care of that scenario. So, please either call the driver something like sata_460ex.c or, better still, segregate the driver in two parts - SoC specific stuff and DWC IP core driver that can be reused by other SoCs having the same IP in future. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
