Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Wednesday 12 December 2012, Viresh Kumar wrote: > I saw the binding document and it looks it can be applied to dw_dmac > too, as there is nothing special for it. > > The question is how? We are already late for merge window and this > one is queued. Supplying a new patch, getting it reviewed/tested and > being pulled by Linus is not so easy :) > > Two ways: > - Keep it as is, and i will fix it separately and quickly > - Drop it :( It seems we got both lucky and unlucky here, as all the dmaengine patches, including this set and the generic DT bindings missed out in the end. So there is time to fix it all for 3.9. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Wednesday 12 December 2012, Viresh Kumar wrote: I saw the binding document and it looks it can be applied to dw_dmac too, as there is nothing special for it. The question is how? We are already late for merge window and this one is queued. Supplying a new patch, getting it reviewed/tested and being pulled by Linus is not so easy :) Two ways: - Keep it as is, and i will fix it separately and quickly - Drop it :( It seems we got both lucky and unlucky here, as all the dmaengine patches, including this set and the generic DT bindings missed out in the end. So there is time to fix it all for 3.9. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On 12 December 2012 14:10, Andy Shevchenko wrote: > Will we survive if the patch is in mainline? I mean how big the impact > of it is? It doesn't fail to do fulfill its purpose and even ALL DT stuff would work well. Its just the matter of using the right API's, design and bindings :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Mon, 2012-12-10 at 22:08 +, Arnd Bergmann wrote: > The build bug is not the problem however, but the abuse of the > API is. Andy, are you sure you understood what this does when > you gave you Reviewed-by comment? Thank you for pointing this out to refresh my memories and go through documentation again. -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Wed, 2012-12-12 at 08:30 +0530, Viresh Kumar wrote: > > * It requires slave drivers to know that they are using the dw_dmac > > driver and pass a pointer to dw_generic_filter, which is not > > generic at all > > > > * It requires the dmac node to have information about all slaves > > > > There are also some minor issues, such as the naming of DT > > properties, but the above need to be resolved first. > > I saw the binding document and it looks it can be applied to dw_dmac > too, as there is nothing special for it. > > The question is how? We are already late for merge window and this > one is queued. Supplying a new patch, getting it reviewed/tested and > being pulled by Linus is not so easy :) > > Two ways: > - Keep it as is, and i will fix it separately and quickly > - Drop it :( Will we survive if the patch is in mainline? I mean how big the impact of it is? -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Wed, 2012-12-12 at 08:30 +0530, Viresh Kumar wrote: * It requires slave drivers to know that they are using the dw_dmac driver and pass a pointer to dw_generic_filter, which is not generic at all * It requires the dmac node to have information about all slaves There are also some minor issues, such as the naming of DT properties, but the above need to be resolved first. I saw the binding document and it looks it can be applied to dw_dmac too, as there is nothing special for it. The question is how? We are already late for merge window and this one is queued. Supplying a new patch, getting it reviewed/tested and being pulled by Linus is not so easy :) Two ways: - Keep it as is, and i will fix it separately and quickly - Drop it :( Will we survive if the patch is in mainline? I mean how big the impact of it is? -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Mon, 2012-12-10 at 22:08 +, Arnd Bergmann wrote: The build bug is not the problem however, but the abuse of the API is. Andy, are you sure you understood what this does when you gave you Reviewed-by comment? Thank you for pointing this out to refresh my memories and go through documentation again. -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On 12 December 2012 14:10, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: Will we survive if the patch is in mainline? I mean how big the impact of it is? It doesn't fail to do fulfill its purpose and even ALL DT stuff would work well. Its just the matter of using the right API's, design and bindings :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
Sorry for replying late, was too busy with other work yesterday.
On 11 December 2012 03:38, Arnd Bergmann wrote:
> I'm deeply sorry for the very late complaint on this, but I only now
Better late than never :)
> noticed this patch as I was seeing build breakage in linux-next
> because of it.
Oops!! Here is a fix for that
Author: Viresh Kumar
Date: Wed Dec 12 08:28:07 2012 +0530
ARM: SPEAr1310: Fix CF DMA data
We need to pass string with device-channel name to dma controller
instead of dma
controller specific dma struct. Fix CF dma data.
Signed-off-by: Viresh Kumar
---
arch/arm/mach-spear13xx/spear1310.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-spear13xx/spear1310.c
b/arch/arm/mach-spear13xx/spear1310.c
index f65ad5b..54f0e2e 100644
--- a/arch/arm/mach-spear13xx/spear1310.c
+++ b/arch/arm/mach-spear13xx/spear1310.c
@@ -36,7 +36,7 @@
static struct arasan_cf_pdata cf_pdata = {
.cf_if_clk = CF_IF_CLK_166M,
.quirk = CF_BROKEN_UDMA,
- .dma_priv = _dma_priv,
+ .dma_priv = "cf",
};
> Viresh, there are multiple problems with your approach unfortunately:
>
> * It does not follow the binding from
> Documentation/devicetree/bindings/dma/dma.txt
When i patched it, this patch wasn't there in linux-next/master.
Probably was getting reviewed somewhere :)
> * It requires slave drivers to know that they are using the dw_dmac
> driver and pass a pointer to dw_generic_filter, which is not
> generic at all
>
> * It requires the dmac node to have information about all slaves
>
> There are also some minor issues, such as the naming of DT
> properties, but the above need to be resolved first.
I saw the binding document and it looks it can be applied to dw_dmac
too, as there is nothing special for it.
The question is how? We are already late for merge window and this
one is queued. Supplying a new patch, getting it reviewed/tested and
being pulled by Linus is not so easy :)
Two ways:
- Keep it as is, and i will fix it separately and quickly
- Drop it :(
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
Sorry for replying late, was too busy with other work yesterday.
On 11 December 2012 03:38, Arnd Bergmann a...@arndb.de wrote:
I'm deeply sorry for the very late complaint on this, but I only now
Better late than never :)
noticed this patch as I was seeing build breakage in linux-next
because of it.
Oops!! Here is a fix for that
Author: Viresh Kumar viresh.ku...@linaro.org
Date: Wed Dec 12 08:28:07 2012 +0530
ARM: SPEAr1310: Fix CF DMA data
We need to pass string with device-channel name to dma controller
instead of dma
controller specific dma struct. Fix CF dma data.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
arch/arm/mach-spear13xx/spear1310.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-spear13xx/spear1310.c
b/arch/arm/mach-spear13xx/spear1310.c
index f65ad5b..54f0e2e 100644
--- a/arch/arm/mach-spear13xx/spear1310.c
+++ b/arch/arm/mach-spear13xx/spear1310.c
@@ -36,7 +36,7 @@
static struct arasan_cf_pdata cf_pdata = {
.cf_if_clk = CF_IF_CLK_166M,
.quirk = CF_BROKEN_UDMA,
- .dma_priv = cf_dma_priv,
+ .dma_priv = cf,
};
Viresh, there are multiple problems with your approach unfortunately:
* It does not follow the binding from
Documentation/devicetree/bindings/dma/dma.txt
When i patched it, this patch wasn't there in linux-next/master.
Probably was getting reviewed somewhere :)
* It requires slave drivers to know that they are using the dw_dmac
driver and pass a pointer to dw_generic_filter, which is not
generic at all
* It requires the dmac node to have information about all slaves
There are also some minor issues, such as the naming of DT
properties, but the above need to be resolved first.
I saw the binding document and it looks it can be applied to dw_dmac
too, as there is nothing special for it.
The question is how? We are already late for merge window and this
one is queued. Supplying a new patch, getting it reviewed/tested and
being pulled by Linus is not so easy :)
Two ways:
- Keep it as is, and i will fix it separately and quickly
- Drop it :(
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Monday 10 December 2012, Arnd Bergmann wrote: > The build bug is not the problem however, but the abuse of the > API is. Andy, are you sure you understood what this does when > you gave you Reviewed-by comment? > Ah, I just saw that Andy had the right intuition when commenting on it at first, but Viresh managed to convince him otherwise, and appearently neither had followed the discussion about the dmaengine bindings... Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Tuesday 16 October 2012, Viresh Kumar wrote: > dw_dmac driver already supports device tree but it used to have its platform > data passed the non-DT way. > > This patch does following changes: > - pass platform data via DT, non-DT way still takes precedence if both are > used. > - create generic filter routine > - Earlier slave information was made available by slave specific filter > routines > in chan->private field. Now, this information would be passed from within > dmac > DT node. Slave drivers would now be required to pass bus_id (a string) as > parameter to this generic filter(), which would be compared against the > slave > data passed from DT, by the generic filter routine. > - Update binding document > > Signed-off-by: Viresh Kumar > Reviewed-by: Andy Shevchenko I'm deeply sorry for the very late complaint on this, but I only now noticed this patch as I was seeing build breakage in linux-next because of it. The build bug is not the problem however, but the abuse of the API is. Andy, are you sure you understood what this does when you gave you Reviewed-by comment? Viresh, there are multiple problems with your approach unfortunately: * It does not follow the binding from Documentation/devicetree/bindings/dma/dma.txt * It requires slave drivers to know that they are using the dw_dmac driver and pass a pointer to dw_generic_filter, which is not generic at all * It requires the dmac node to have information about all slaves There are also some minor issues, such as the naming of DT properties, but the above need to be resolved first. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Tuesday 16 October 2012, Viresh Kumar wrote: dw_dmac driver already supports device tree but it used to have its platform data passed the non-DT way. This patch does following changes: - pass platform data via DT, non-DT way still takes precedence if both are used. - create generic filter routine - Earlier slave information was made available by slave specific filter routines in chan-private field. Now, this information would be passed from within dmac DT node. Slave drivers would now be required to pass bus_id (a string) as parameter to this generic filter(), which would be compared against the slave data passed from DT, by the generic filter routine. - Update binding document Signed-off-by: Viresh Kumar viresh.ku...@linaro.org Reviewed-by: Andy Shevchenko andriy.shevche...@linux.intel.com I'm deeply sorry for the very late complaint on this, but I only now noticed this patch as I was seeing build breakage in linux-next because of it. The build bug is not the problem however, but the abuse of the API is. Andy, are you sure you understood what this does when you gave you Reviewed-by comment? Viresh, there are multiple problems with your approach unfortunately: * It does not follow the binding from Documentation/devicetree/bindings/dma/dma.txt * It requires slave drivers to know that they are using the dw_dmac driver and pass a pointer to dw_generic_filter, which is not generic at all * It requires the dmac node to have information about all slaves There are also some minor issues, such as the naming of DT properties, but the above need to be resolved first. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Monday 10 December 2012, Arnd Bergmann wrote: The build bug is not the problem however, but the abuse of the API is. Andy, are you sure you understood what this does when you gave you Reviewed-by comment? Ah, I just saw that Andy had the right intuition when commenting on it at first, but Viresh managed to convince him otherwise, and appearently neither had followed the discussion about the dmaengine bindings... Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Fri, 2012-10-26 at 14:35 +0530, Viresh Kumar wrote: > >> I can see that you applied these patches and they are present in > >> linux-next. But i feel > >> the order of patches is bad. > > Yes looks like I forgot to sort the mbox series :( > > > > since all patches were applied nicely, and they seem fairly independent > > of each other it should cause issue. Let me know if you wnat me to redo > > my -next. > > yes. The ARCH specific patch 3/3 uses a routine created in 2/3. So they have > to be in right order for git bisect to work. Done, it should reflect now. Sorry for the mess. -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On 26 October 2012 14:18, Vinod Koul wrote: > On Fri, 2012-10-26 at 14:25 +0530, Viresh Kumar wrote: >> I can see that you applied these patches and they are present in >> linux-next. But i feel >> the order of patches is bad. > Yes looks like I forgot to sort the mbox series :( > > since all patches were applied nicely, and they seem fairly independent > of each other it should cause issue. Let me know if you wnat me to redo > my -next. yes. The ARCH specific patch 3/3 uses a routine created in 2/3. So they have to be in right order for git bisect to work. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Fri, 2012-10-26 at 14:25 +0530, Viresh Kumar wrote: > Hi Vinod, > > On 16 October 2012 09:49, Viresh Kumar wrote: > > dw_dmac driver already supports device tree but it used to have its platform > > data passed the non-DT way. > > > > This patch does following changes: > > - pass platform data via DT, non-DT way still takes precedence if both are > > used. > > - create generic filter routine > > - Earlier slave information was made available by slave specific filter > > routines > > in chan->private field. Now, this information would be passed from within > > dmac > > DT node. Slave drivers would now be required to pass bus_id (a string) as > > parameter to this generic filter(), which would be compared against the > > slave > > data passed from DT, by the generic filter routine. > > - Update binding document > > I can see that you applied these patches and they are present in > linux-next. But i feel > the order of patches is bad. Yes looks like I forgot to sort the mbox series :( since all patches were applied nicely, and they seem fairly independent of each other it should cause issue. Let me know if you wnat me to redo my -next. -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
Hi Vinod, On 16 October 2012 09:49, Viresh Kumar wrote: > dw_dmac driver already supports device tree but it used to have its platform > data passed the non-DT way. > > This patch does following changes: > - pass platform data via DT, non-DT way still takes precedence if both are > used. > - create generic filter routine > - Earlier slave information was made available by slave specific filter > routines > in chan->private field. Now, this information would be passed from within > dmac > DT node. Slave drivers would now be required to pass bus_id (a string) as > parameter to this generic filter(), which would be compared against the > slave > data passed from DT, by the generic filter routine. > - Update binding document I can see that you applied these patches and they are present in linux-next. But i feel the order of patches is bad. git log --oneline gives following: 879a0ec dmaengine: dw_dmac: Update documentation style comments for dw_dma_platform_data d0e35f3 dmaengine: dw_dmac: Enhance device tree support 4c4c30c ARM: SPEAr13xx: Pass DW DMAC platform data from DT The last patch "ARM: SPEAr13xx: Pass DW DMAC platform data from DT" has dependency on second patch. The correct order would be: 4c4c30c ARM: SPEAr13xx: Pass DW DMAC platform data from DT d0e35f3 dmaengine: dw_dmac: Enhance device tree support 879a0ec dmaengine: dw_dmac: Update documentation style comments for dw_dma_platform_data PS: We are looking at output of git log. Last patch (or first from bottom) was applied first. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
Hi Vinod, On 16 October 2012 09:49, Viresh Kumar viresh.ku...@linaro.org wrote: dw_dmac driver already supports device tree but it used to have its platform data passed the non-DT way. This patch does following changes: - pass platform data via DT, non-DT way still takes precedence if both are used. - create generic filter routine - Earlier slave information was made available by slave specific filter routines in chan-private field. Now, this information would be passed from within dmac DT node. Slave drivers would now be required to pass bus_id (a string) as parameter to this generic filter(), which would be compared against the slave data passed from DT, by the generic filter routine. - Update binding document I can see that you applied these patches and they are present in linux-next. But i feel the order of patches is bad. git log --oneline gives following: 879a0ec dmaengine: dw_dmac: Update documentation style comments for dw_dma_platform_data d0e35f3 dmaengine: dw_dmac: Enhance device tree support 4c4c30c ARM: SPEAr13xx: Pass DW DMAC platform data from DT The last patch ARM: SPEAr13xx: Pass DW DMAC platform data from DT has dependency on second patch. The correct order would be: 4c4c30c ARM: SPEAr13xx: Pass DW DMAC platform data from DT d0e35f3 dmaengine: dw_dmac: Enhance device tree support 879a0ec dmaengine: dw_dmac: Update documentation style comments for dw_dma_platform_data PS: We are looking at output of git log. Last patch (or first from bottom) was applied first. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Fri, 2012-10-26 at 14:25 +0530, Viresh Kumar wrote: Hi Vinod, On 16 October 2012 09:49, Viresh Kumar viresh.ku...@linaro.org wrote: dw_dmac driver already supports device tree but it used to have its platform data passed the non-DT way. This patch does following changes: - pass platform data via DT, non-DT way still takes precedence if both are used. - create generic filter routine - Earlier slave information was made available by slave specific filter routines in chan-private field. Now, this information would be passed from within dmac DT node. Slave drivers would now be required to pass bus_id (a string) as parameter to this generic filter(), which would be compared against the slave data passed from DT, by the generic filter routine. - Update binding document I can see that you applied these patches and they are present in linux-next. But i feel the order of patches is bad. Yes looks like I forgot to sort the mbox series :( since all patches were applied nicely, and they seem fairly independent of each other it should cause issue. Let me know if you wnat me to redo my -next. -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Fri, 2012-10-26 at 14:35 +0530, Viresh Kumar wrote: I can see that you applied these patches and they are present in linux-next. But i feel the order of patches is bad. Yes looks like I forgot to sort the mbox series :( since all patches were applied nicely, and they seem fairly independent of each other it should cause issue. Let me know if you wnat me to redo my -next. yes. The ARCH specific patch 3/3 uses a routine created in 2/3. So they have to be in right order for git bisect to work. Done, it should reflect now. Sorry for the mess. -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
dw_dmac driver already supports device tree but it used to have its platform
data passed the non-DT way.
This patch does following changes:
- pass platform data via DT, non-DT way still takes precedence if both are used.
- create generic filter routine
- Earlier slave information was made available by slave specific filter routines
in chan->private field. Now, this information would be passed from within dmac
DT node. Slave drivers would now be required to pass bus_id (a string) as
parameter to this generic filter(), which would be compared against the slave
data passed from DT, by the generic filter routine.
- Update binding document
Signed-off-by: Viresh Kumar
Reviewed-by: Andy Shevchenko
---
V2->V3:
--
- Simplified an equation in filter routine
- renamed variable 'val' as 'tmp' in DT parsing routine
V1->V2:
--
- Optimized filter & DT parsing routine
- Removed unnecessary casts from changes
- renamed filter function
- Fixed function prototype and return value of DT parsing routine for !CONFIG_OF
case
- use of_get_child_count()
Documentation/devicetree/bindings/dma/snps-dma.txt | 44 +++
drivers/dma/dw_dmac.c | 134 +
drivers/dma/dw_dmac_regs.h | 4 +
include/linux/dw_dmac.h| 43 ---
4 files changed, 208 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index c0d85db..5bb3dfb 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -6,6 +6,26 @@ Required properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
+- nr_channels: Number of channels supported by hardware
+- is_private: The device channels should be marked as private and not for by
the
+ general purpose DMA channel allocator. False if not passed.
+- chan_allocation_order: order of allocation of channel, 0 (default):
ascending,
+ 1: descending
+- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
+ increase from chan n->0
+- block_size: Maximum block size supported by the controller
+- nr_masters: Number of AHB masters supported by the controller
+- data_width: Maximum data width supported by hardware per AHB master
+ (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
+- slave_info:
+ - bus_id: name of this device channel, not just a device name since
+ devices may have more than one channel e.g. "foo_tx". For using the
+ dw_generic_filter(), slave drivers must pass exactly this string as
+ param to filter function.
+ - cfg_hi: Platform-specific initializer for the CFG_HI register
+ - cfg_lo: Platform-specific initializer for the CFG_LO register
+ - src_master: src master for transfers on allocated channel.
+ - dst_master: dest master for transfers on allocated channel.
Example:
@@ -14,4 +34,28 @@ Example:
reg = <0xfc00 0x1000>;
interrupt-parent = <>;
interrupts = <12>;
+
+ nr_channels = <8>;
+ chan_allocation_order = <1>;
+ chan_priority = <1>;
+ block_size = <0xfff>;
+ nr_masters = <2>;
+ data_width = <3 3 0 0>;
+
+ slave_info {
+ uart0-tx {
+ bus_id = "uart0-tx";
+ cfg_hi = <0x4000>; /* 0x8 << 11 */
+ cfg_lo = <0>;
+ src_master = <0>;
+ dst_master = <1>;
+ };
+ spi0-tx {
+ bus_id = "spi0-tx";
+ cfg_hi = <0x2000>; /* 0x4 << 11 */
+ cfg_lo = <0>;
+ src_master = <0>;
+ dst_master = <0>;
+ };
+ };
};
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index c4b0eb3..98f33a7 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -1179,6 +1179,50 @@ static void dwc_free_chan_resources(struct dma_chan
*chan)
dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
}
+bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
+{
+ struct dw_dma *dw = to_dw_dma(chan->device);
+ static struct dw_dma *last_dw;
+ static char *last_bus_id;
+ int i = -1;
+
+ /*
+* dmaengine framework calls this routine for all channels of all dma
+* controller, until true is returned. If 'param' bus_id is not
+* registered with a dma controller (dw), then there is no need of
+* running below function for all channels of
[PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
dw_dmac driver already supports device tree but it used to have its platform
data passed the non-DT way.
This patch does following changes:
- pass platform data via DT, non-DT way still takes precedence if both are used.
- create generic filter routine
- Earlier slave information was made available by slave specific filter routines
in chan-private field. Now, this information would be passed from within dmac
DT node. Slave drivers would now be required to pass bus_id (a string) as
parameter to this generic filter(), which would be compared against the slave
data passed from DT, by the generic filter routine.
- Update binding document
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
Reviewed-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
V2-V3:
--
- Simplified an equation in filter routine
- renamed variable 'val' as 'tmp' in DT parsing routine
V1-V2:
--
- Optimized filter DT parsing routine
- Removed unnecessary casts from changes
- renamed filter function
- Fixed function prototype and return value of DT parsing routine for !CONFIG_OF
case
- use of_get_child_count()
Documentation/devicetree/bindings/dma/snps-dma.txt | 44 +++
drivers/dma/dw_dmac.c | 134 +
drivers/dma/dw_dmac_regs.h | 4 +
include/linux/dw_dmac.h| 43 ---
4 files changed, 208 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index c0d85db..5bb3dfb 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -6,6 +6,26 @@ Required properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
+- nr_channels: Number of channels supported by hardware
+- is_private: The device channels should be marked as private and not for by
the
+ general purpose DMA channel allocator. False if not passed.
+- chan_allocation_order: order of allocation of channel, 0 (default):
ascending,
+ 1: descending
+- chan_priority: priority of channels. 0 (default): increase from chan 0-n, 1:
+ increase from chan n-0
+- block_size: Maximum block size supported by the controller
+- nr_masters: Number of AHB masters supported by the controller
+- data_width: Maximum data width supported by hardware per AHB master
+ (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
+- slave_info:
+ - bus_id: name of this device channel, not just a device name since
+ devices may have more than one channel e.g. foo_tx. For using the
+ dw_generic_filter(), slave drivers must pass exactly this string as
+ param to filter function.
+ - cfg_hi: Platform-specific initializer for the CFG_HI register
+ - cfg_lo: Platform-specific initializer for the CFG_LO register
+ - src_master: src master for transfers on allocated channel.
+ - dst_master: dest master for transfers on allocated channel.
Example:
@@ -14,4 +34,28 @@ Example:
reg = 0xfc00 0x1000;
interrupt-parent = vic1;
interrupts = 12;
+
+ nr_channels = 8;
+ chan_allocation_order = 1;
+ chan_priority = 1;
+ block_size = 0xfff;
+ nr_masters = 2;
+ data_width = 3 3 0 0;
+
+ slave_info {
+ uart0-tx {
+ bus_id = uart0-tx;
+ cfg_hi = 0x4000; /* 0x8 11 */
+ cfg_lo = 0;
+ src_master = 0;
+ dst_master = 1;
+ };
+ spi0-tx {
+ bus_id = spi0-tx;
+ cfg_hi = 0x2000; /* 0x4 11 */
+ cfg_lo = 0;
+ src_master = 0;
+ dst_master = 0;
+ };
+ };
};
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index c4b0eb3..98f33a7 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -1179,6 +1179,50 @@ static void dwc_free_chan_resources(struct dma_chan
*chan)
dev_vdbg(chan2dev(chan), %s: done\n, __func__);
}
+bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
+{
+ struct dw_dma *dw = to_dw_dma(chan-device);
+ static struct dw_dma *last_dw;
+ static char *last_bus_id;
+ int i = -1;
+
+ /*
+* dmaengine framework calls this routine for all channels of all dma
+* controller, until true is returned. If 'param' bus_id is not
+* registered with a dma controller (dw), then there is no need of
+* running below function for all
