Re: [PATCH] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Rameshwar Sahu]

On Wed, Jan 6, 2016 at 3:01 PM, Vinod Koul  wrote:
> On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Wed, Jan 6, 2016 at 2:43 PM, Vinod Koul  wrote:
>> > On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote:
>> >> From: Rameshwar Prasad Sahu 
>> >>
>> >> For interrupt controller that doesn't support irq_disable and hardware
>> >> with level interrupt, an extra interrupt can be pending. This patch fixes
>> >> the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line.
>> >>
>> >> Reference: 
>> >> http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c
>> >
>> > I seem to have got this patch thrice :(
>> Due to mail failure (some issue was in my email client) to some
>> email-id it was multiple times,
>
> git send-email ?
Yes, was not able to send Arnd Bergmann.
>
>> >
>> >>
>> >> Signed-off-by: Rameshwar Prasad Sahu 
>> >> ---
>> >>  drivers/dma/xgene-dma.c |4 
>> >>  1 files changed, 4 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> >> index 9dfa2b0..6363e84 100644
>> >> --- a/drivers/dma/xgene-dma.c
>> >> +++ b/drivers/dma/xgene-dma.c
>> >> @@ -29,6 +29,7 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >>  #include 
>> >>  #include 
>> >>
>> >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> >> *pdma)
>> >>   /* Register DMA channel rx irq */
>> >>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>> >>   chan = >chan[i];
>> >> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>> >
>> > Why not use irq_settings_disable_unlazy(), at least read the reference you
>> > pointed out!
>>
>> irq_settings_disable_unlazy() is helper function to test
>> IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
>> FYI...
>> +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
>> +{
>> + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
>> +}
>
> Ah yes, I saw clear API and assumed there would be set. Then I think we
> should add a set helper as well as the usage is intended for drivers to
> set this flag
>
> Thomas,
>
> Any reason why you didn't add a set helper, only test and clear?
>
> --
> ~Vinod
--
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Rameshwar Sahu]

Hi Vinod,

On Wed, Jan 6, 2016 at 2:43 PM, Vinod Koul  wrote:
> On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote:
>> From: Rameshwar Prasad Sahu 
>>
>> For interrupt controller that doesn't support irq_disable and hardware
>> with level interrupt, an extra interrupt can be pending. This patch fixes
>> the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line.
>>
>> Reference: http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c
>
> I seem to have got this patch thrice :(
Due to mail failure (some issue was in my email client) to some
email-id it was multiple times,
>
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c |4 
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index 9dfa2b0..6363e84 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> *pdma)
>>   /* Register DMA channel rx irq */
>>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>>   chan = >chan[i];
>> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>
> Why not use irq_settings_disable_unlazy(), at least read the reference you
> pointed out!

irq_settings_disable_unlazy() is helper function to test
IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
FYI...
+static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
+{
+ return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
+}
>
>>   ret = devm_request_irq(chan->dev, chan->rx_irq,
>>  xgene_dma_chan_ring_isr,
>>  0, chan->name, chan);
>> @@ -1620,6 +1622,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> *pdma)
>>
>>   for (j = 0; j < i; j++) {
>>   chan = >chan[i];
>> + irq_clear_status_flags(chan->rx_irq, 
>> IRQ_DISABLE_UNLAZY);
>>   devm_free_irq(chan->dev, chan->rx_irq, chan);
>>   }
>>
>> @@ -1640,6 +1643,7 @@ static void xgene_dma_free_irqs(struct xgene_dma *pdma)
>>
>>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>>   chan = >chan[i];
>> + irq_clear_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>>   devm_free_irq(chan->dev, chan->rx_irq, chan);
>>   }
>>  }
>> --
>> 1.7.1
>
> --
> ~Vinod
--
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Rameshwar Sahu]

On Wed, Jan 6, 2016 at 3:01 PM, Vinod Koul <vinod.k...@intel.com> wrote:
> On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Wed, Jan 6, 2016 at 2:43 PM, Vinod Koul <vinod.k...@intel.com> wrote:
>> > On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote:
>> >> From: Rameshwar Prasad Sahu <rs...@apm.com>
>> >>
>> >> For interrupt controller that doesn't support irq_disable and hardware
>> >> with level interrupt, an extra interrupt can be pending. This patch fixes
>> >> the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line.
>> >>
>> >> Reference: 
>> >> http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c
>> >
>> > I seem to have got this patch thrice :(
>> Due to mail failure (some issue was in my email client) to some
>> email-id it was multiple times,
>
> git send-email ?
Yes, was not able to send Arnd Bergmann.
>
>> >
>> >>
>> >> Signed-off-by: Rameshwar Prasad Sahu <rs...@apm.com>
>> >> ---
>> >>  drivers/dma/xgene-dma.c |4 
>> >>  1 files changed, 4 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> >> index 9dfa2b0..6363e84 100644
>> >> --- a/drivers/dma/xgene-dma.c
>> >> +++ b/drivers/dma/xgene-dma.c
>> >> @@ -29,6 +29,7 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >>  #include 
>> >>  #include 
>> >>
>> >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> >> *pdma)
>> >>   /* Register DMA channel rx irq */
>> >>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>> >>   chan = >chan[i];
>> >> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>> >
>> > Why not use irq_settings_disable_unlazy(), at least read the reference you
>> > pointed out!
>>
>> irq_settings_disable_unlazy() is helper function to test
>> IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
>> FYI...
>> +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
>> +{
>> + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
>> +}
>
> Ah yes, I saw clear API and assumed there would be set. Then I think we
> should add a set helper as well as the usage is intended for drivers to
> set this flag
>
> Thomas,
>
> Any reason why you didn't add a set helper, only test and clear?
>
> --
> ~Vinod
--
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Rameshwar Sahu]

Hi Vinod,

On Wed, Jan 6, 2016 at 2:43 PM, Vinod Koul  wrote:
> On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote:
>> From: Rameshwar Prasad Sahu 
>>
>> For interrupt controller that doesn't support irq_disable and hardware
>> with level interrupt, an extra interrupt can be pending. This patch fixes
>> the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line.
>>
>> Reference: http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c
>
> I seem to have got this patch thrice :(
Due to mail failure (some issue was in my email client) to some
email-id it was multiple times,
>
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c |4 
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index 9dfa2b0..6363e84 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> *pdma)
>>   /* Register DMA channel rx irq */
>>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>>   chan = >chan[i];
>> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>
> Why not use irq_settings_disable_unlazy(), at least read the reference you
> pointed out!

irq_settings_disable_unlazy() is helper function to test
IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
FYI...
+static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
+{
+ return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
+}
>
>>   ret = devm_request_irq(chan->dev, chan->rx_irq,
>>  xgene_dma_chan_ring_isr,
>>  0, chan->name, chan);
>> @@ -1620,6 +1622,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> *pdma)
>>
>>   for (j = 0; j < i; j++) {
>>   chan = >chan[i];
>> + irq_clear_status_flags(chan->rx_irq, 
>> IRQ_DISABLE_UNLAZY);
>>   devm_free_irq(chan->dev, chan->rx_irq, chan);
>>   }
>>
>> @@ -1640,6 +1643,7 @@ static void xgene_dma_free_irqs(struct xgene_dma *pdma)
>>
>>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>>   chan = >chan[i];
>> + irq_clear_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>>   devm_free_irq(chan->dev, chan->rx_irq, chan);
>>   }
>>  }
>> --
>> 1.7.1
>
> --
> ~Vinod
--
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] mmc: host: arasan: sdhci-of-arasan: Remove no-hispd and no-cmd23 quirks for sdhci-arasan4.9a

[Rameshwar Sahu]

Hi Ulf,

On Wed, Dec 23, 2015 at 6:59 PM, Rameshswar Prasad Sahu  wrote:
> From: Rameshwar Prasad Sahu 
>
> The Arason SD host controller supports set block count command (cmd23)
> and high speed mode. This patch re-enable both of these features that
> was disabled. For device that doesn't support high speed, it should
> configure its capability register accordingly instead disables it
> explicitly.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/mmc/host/sdhci-of-arasan.c |5 -
>  1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
> b/drivers/mmc/host/sdhci-of-arasan.c
> index 75379cb..5d9fdb3 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -172,11 +172,6 @@ static int sdhci_arasan_probe(struct platform_device 
> *pdev)
> goto clk_disable_all;
> }
>
> -   if (of_device_is_compatible(pdev->dev.of_node, "arasan,sdhci-4.9a")) {
> -   host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
> -   host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> -   }
> -
> sdhci_get_of_property(pdev);
> pltfm_host = sdhci_priv(host);
> pltfm_host->priv = sdhci_arasan;
> --
> 1.7.1
>

Any comment on this patch ??
--
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] mmc: host: arasan: sdhci-of-arasan: Remove no-hispd and no-cmd23 quirks for sdhci-arasan4.9a

[Rameshwar Sahu]

Hi Ulf,

On Wed, Dec 23, 2015 at 6:59 PM, Rameshswar Prasad Sahu  wrote:
> From: Rameshwar Prasad Sahu 
>
> The Arason SD host controller supports set block count command (cmd23)
> and high speed mode. This patch re-enable both of these features that
> was disabled. For device that doesn't support high speed, it should
> configure its capability register accordingly instead disables it
> explicitly.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/mmc/host/sdhci-of-arasan.c |5 -
>  1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
> b/drivers/mmc/host/sdhci-of-arasan.c
> index 75379cb..5d9fdb3 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -172,11 +172,6 @@ static int sdhci_arasan_probe(struct platform_device 
> *pdev)
> goto clk_disable_all;
> }
>
> -   if (of_device_is_compatible(pdev->dev.of_node, "arasan,sdhci-4.9a")) {
> -   host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
> -   host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> -   }
> -
> sdhci_get_of_property(pdev);
> pltfm_host = sdhci_priv(host);
> pltfm_host->priv = sdhci_arasan;
> --
> 1.7.1
>

Any comment on this patch ??
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

On Wed, Dec 9, 2015 at 1:57 PM, Herbert Xu  wrote:
> On Wed, Dec 09, 2015 at 01:55:55PM +0530, Rameshwar Sahu wrote:
>>
>> Any comments on above patch ??
>
> My concern that there aren't going to be any in-kernel users remains.
Yes, we are not upstream in-kernel users right now, but later client
ma upstream there patches.

>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

Hi,

On Mon, Nov 16, 2015 at 2:42 PM,   wrote:
> From: Rameshwar Prasad Sahu 
>
> This patch implements support for APM X-Gene SoC CRC32C h/w accelerator driver
> and adds CRC32C computations support in dmaengine framework. APM X-Gene SoC 
> has
> DMA engine capable of performing CRC32C computations.
>
> v2 changes:
> 1. Added helper function in dmaengine framework
> 2. Documented CRC32C support in Documentations/dmaengine/provider.txt
> 3. Fixed algo name
> 4. Fixed coding style issues
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>
> Rameshwar Prasad Sahu (3):
>   dmaengine: Add support for new feature CRC32C computations
>   dmaengine: xgene-dma: Add support for CRC32C computations via DMA
> engine
>   Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
>
>  Documentation/dmaengine/provider.txt |3 +
>  drivers/crypto/Kconfig   |8 +
>  drivers/crypto/Makefile  |1 +
>  drivers/crypto/xgene-crc32c.c|  234 +
>  drivers/dma/dmaengine.c  |2 +
>  drivers/dma/xgene-dma.c  |  314 
> --
>  include/linux/dmaengine.h|   13 ++
>  7 files changed, 560 insertions(+), 15 deletions(-)
>  create mode 100755 drivers/crypto/xgene-crc32c.c

Any comments on above patch ??
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

On Wed, Dec 9, 2015 at 1:57 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Wed, Dec 09, 2015 at 01:55:55PM +0530, Rameshwar Sahu wrote:
>>
>> Any comments on above patch ??
>
> My concern that there aren't going to be any in-kernel users remains.
Yes, we are not upstream in-kernel users right now, but later client
ma upstream there patches.

>
> Cheers,
> --
> Email: Herbert Xu <herb...@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

Hi,

On Mon, Nov 16, 2015 at 2:42 PM,   wrote:
> From: Rameshwar Prasad Sahu 
>
> This patch implements support for APM X-Gene SoC CRC32C h/w accelerator driver
> and adds CRC32C computations support in dmaengine framework. APM X-Gene SoC 
> has
> DMA engine capable of performing CRC32C computations.
>
> v2 changes:
> 1. Added helper function in dmaengine framework
> 2. Documented CRC32C support in Documentations/dmaengine/provider.txt
> 3. Fixed algo name
> 4. Fixed coding style issues
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>
> Rameshwar Prasad Sahu (3):
>   dmaengine: Add support for new feature CRC32C computations
>   dmaengine: xgene-dma: Add support for CRC32C computations via DMA
> engine
>   Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
>
>  Documentation/dmaengine/provider.txt |3 +
>  drivers/crypto/Kconfig   |8 +
>  drivers/crypto/Makefile  |1 +
>  drivers/crypto/xgene-crc32c.c|  234 +
>  drivers/dma/dmaengine.c  |2 +
>  drivers/dma/xgene-dma.c  |  314 
> --
>  include/linux/dmaengine.h|   13 ++
>  7 files changed, 560 insertions(+), 15 deletions(-)
>  create mode 100755 drivers/crypto/xgene-crc32c.c

Any comments on above patch ??
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

Hi Herbert,

On Mon, Nov 30, 2015 at 2:20 PM, Herbert Xu  wrote:
> On Mon, Nov 30, 2015 at 02:19:33PM +0530, Rameshwar Sahu wrote:
>>
>> One of our client is using this layer for offloading the crc32c to our
>> dmaengine hw.
>
> Is this going to be merged into the kernel?
I am not sure about it, but as what I thought is Linux kernel supports
many algos in async mode and sync mode, later client has to take care
which one they are going to use.
Any way this offload implementation is specific to Applied Micro
X-Gene SoC, where we have such a dmaengine can do CRC32c.
>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

Hi Herbert,

On Mon, Nov 30, 2015 at 2:09 PM, Herbert Xu  wrote:
> On Mon, Nov 30, 2015 at 02:06:03PM +0530, Rameshwar Sahu wrote:
>> On Mon, Nov 16, 2015 at 2:42 PM,   wrote:
>> > From: Rameshwar Prasad Sahu 
>> >
>> > This patch implements support for APM X-Gene SoC CRC32C h/w accelerator 
>> > driver
>> > and adds CRC32C computations support in dmaengine framework. APM X-Gene 
>> > SoC has
>> > DMA engine capable of performing CRC32C computations.
>> >
>> > v2 changes:
>> > 1. Added helper function in dmaengine framework
>> > 2. Documented CRC32C support in 
>> > Documentations/dmaengine/provider.txt
>> > 3. Fixed algo name
>> > 4. Fixed coding style issues
>> >
>> > Signed-off-by: Rameshwar Prasad Sahu 
>> > ---
>> >
>> > Rameshwar Prasad Sahu (3):
>> >   dmaengine: Add support for new feature CRC32C computations
>> >   dmaengine: xgene-dma: Add support for CRC32C computations via DMA
>> > engine
>> >   Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
>> >
>> >  Documentation/dmaengine/provider.txt |3 +
>> >  drivers/crypto/Kconfig   |8 +
>> >  drivers/crypto/Makefile  |1 +
>> >  drivers/crypto/xgene-crc32c.c|  234 +
>> >  drivers/dma/dmaengine.c  |2 +
>> >  drivers/dma/xgene-dma.c  |  314 
>> > --
>> >  include/linux/dmaengine.h|   13 ++
>> >  7 files changed, 560 insertions(+), 15 deletions(-)
>> >  create mode 100755 drivers/crypto/xgene-crc32c.c
>>
>> Any Comments on above patchset ??
>
> The main user of crc32c is lib/libcrc32c.c.  Unfortunately it is
> entire synchronous so it won't be able to use your crc32c driver
> at all.

This is asynchronous implementation of the crc32c, mainly for
offloading the computations, So client (who want to use it) can call
it as like other async crypto algos available in linux/crypto, so they
have frame the layer on top of this.
>
> So who is going to be using this?
One of our client is using this layer for offloading the crc32c to our
dmaengine hw.

>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

On Mon, Nov 16, 2015 at 2:42 PM,   wrote:
> From: Rameshwar Prasad Sahu 
>
> This patch implements support for APM X-Gene SoC CRC32C h/w accelerator driver
> and adds CRC32C computations support in dmaengine framework. APM X-Gene SoC 
> has
> DMA engine capable of performing CRC32C computations.
>
> v2 changes:
> 1. Added helper function in dmaengine framework
> 2. Documented CRC32C support in Documentations/dmaengine/provider.txt
> 3. Fixed algo name
> 4. Fixed coding style issues
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>
> Rameshwar Prasad Sahu (3):
>   dmaengine: Add support for new feature CRC32C computations
>   dmaengine: xgene-dma: Add support for CRC32C computations via DMA
> engine
>   Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
>
>  Documentation/dmaengine/provider.txt |3 +
>  drivers/crypto/Kconfig   |8 +
>  drivers/crypto/Makefile  |1 +
>  drivers/crypto/xgene-crc32c.c|  234 +
>  drivers/dma/dmaengine.c  |2 +
>  drivers/dma/xgene-dma.c  |  314 
> --
>  include/linux/dmaengine.h|   13 ++
>  7 files changed, 560 insertions(+), 15 deletions(-)
>  create mode 100755 drivers/crypto/xgene-crc32c.c

Any Comments on above patchset ??
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

Hi Herbert,

On Mon, Nov 30, 2015 at 2:20 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Mon, Nov 30, 2015 at 02:19:33PM +0530, Rameshwar Sahu wrote:
>>
>> One of our client is using this layer for offloading the crc32c to our
>> dmaengine hw.
>
> Is this going to be merged into the kernel?
I am not sure about it, but as what I thought is Linux kernel supports
many algos in async mode and sync mode, later client has to take care
which one they are going to use.
Any way this offload implementation is specific to Applied Micro
X-Gene SoC, where we have such a dmaengine can do CRC32c.
>
> Cheers,
> --
> Email: Herbert Xu <herb...@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

On Mon, Nov 16, 2015 at 2:42 PM,   wrote:
> From: Rameshwar Prasad Sahu 
>
> This patch implements support for APM X-Gene SoC CRC32C h/w accelerator driver
> and adds CRC32C computations support in dmaengine framework. APM X-Gene SoC 
> has
> DMA engine capable of performing CRC32C computations.
>
> v2 changes:
> 1. Added helper function in dmaengine framework
> 2. Documented CRC32C support in Documentations/dmaengine/provider.txt
> 3. Fixed algo name
> 4. Fixed coding style issues
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>
> Rameshwar Prasad Sahu (3):
>   dmaengine: Add support for new feature CRC32C computations
>   dmaengine: xgene-dma: Add support for CRC32C computations via DMA
> engine
>   Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
>
>  Documentation/dmaengine/provider.txt |3 +
>  drivers/crypto/Kconfig   |8 +
>  drivers/crypto/Makefile  |1 +
>  drivers/crypto/xgene-crc32c.c|  234 +
>  drivers/dma/dmaengine.c  |2 +
>  drivers/dma/xgene-dma.c  |  314 
> --
>  include/linux/dmaengine.h|   13 ++
>  7 files changed, 560 insertions(+), 15 deletions(-)
>  create mode 100755 drivers/crypto/xgene-crc32c.c

Any Comments on above patchset ??
--
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 v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[Rameshwar Sahu]

Hi Herbert,

On Mon, Nov 30, 2015 at 2:09 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Mon, Nov 30, 2015 at 02:06:03PM +0530, Rameshwar Sahu wrote:
>> On Mon, Nov 16, 2015 at 2:42 PM,  <rs...@apm.com> wrote:
>> > From: Rameshwar Prasad Sahu <rs...@apm.com>
>> >
>> > This patch implements support for APM X-Gene SoC CRC32C h/w accelerator 
>> > driver
>> > and adds CRC32C computations support in dmaengine framework. APM X-Gene 
>> > SoC has
>> > DMA engine capable of performing CRC32C computations.
>> >
>> > v2 changes:
>> > 1. Added helper function in dmaengine framework
>> > 2. Documented CRC32C support in 
>> > Documentations/dmaengine/provider.txt
>> > 3. Fixed algo name
>> > 4. Fixed coding style issues
>> >
>> > Signed-off-by: Rameshwar Prasad Sahu <rs...@apm.com>
>> > ---
>> >
>> > Rameshwar Prasad Sahu (3):
>> >   dmaengine: Add support for new feature CRC32C computations
>> >   dmaengine: xgene-dma: Add support for CRC32C computations via DMA
>> > engine
>> >   Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
>> >
>> >  Documentation/dmaengine/provider.txt |3 +
>> >  drivers/crypto/Kconfig   |8 +
>> >  drivers/crypto/Makefile  |1 +
>> >  drivers/crypto/xgene-crc32c.c|  234 +
>> >  drivers/dma/dmaengine.c  |2 +
>> >  drivers/dma/xgene-dma.c  |  314 
>> > --
>> >  include/linux/dmaengine.h|   13 ++
>> >  7 files changed, 560 insertions(+), 15 deletions(-)
>> >  create mode 100755 drivers/crypto/xgene-crc32c.c
>>
>> Any Comments on above patchset ??
>
> The main user of crc32c is lib/libcrc32c.c.  Unfortunately it is
> entire synchronous so it won't be able to use your crc32c driver
> at all.

This is asynchronous implementation of the crc32c, mainly for
offloading the computations, So client (who want to use it) can call
it as like other async crypto algos available in linux/crypto, so they
have frame the layer on top of this.
>
> So who is going to be using this?
One of our client is using this layer for offloading the crc32c to our
dmaengine hw.

>
> Cheers,
> --
> Email: Herbert Xu <herb...@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

[Rameshwar Sahu]

Hi Vinod,

On Mon, Oct 12, 2015 at 7:53 PM, Vinod Koul  wrote:
> On Fri, Oct 09, 2015 at 10:08:32PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Fri, Oct 9, 2015 at 9:42 PM, Vinod Koul  wrote:
>> > On Thu, Oct 08, 2015 at 02:36:57PM +0530, Rameshwar Prasad Sahu wrote:
>> >> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
>> >> computations. But the bandwidth of the entire DMA engine is shared
>> >> among all channels. This patch re-configures operations availability
>> >> such that one can achieve maximum performance for XOR and PQ
>> >> computation by removing the memory offload operations.
>> >>
>> >> Signed-off-by: Rameshwar Prasad Sahu 
>> >> ---
>> >>  drivers/dma/xgene-dma.c | 1 -
>> >>  1 file changed, 1 deletion(-)
>> >>
>> >> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> >> index 8d57b1b..cd38022 100644
>> >> --- a/drivers/dma/xgene-dma.c
>> >> +++ b/drivers/dma/xgene-dma.c
>> >> @@ -1707,7 +1707,6 @@ static void xgene_dma_set_caps(struct 
>> >> xgene_dma_chan *chan,
>> >>   dma_cap_zero(dma_dev->cap_mask);
>> >>
>> >>   /* Set DMA device capability */
>> >> - dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>> >>   dma_cap_set(DMA_SG, dma_dev->cap_mask);
>> >
>> > This will not work. Still clients can invoke memcpy operation. You need to
>> > remove the callback
>>
>> Got it, instead of removing the callback registration can we keep it
>> inside the condition like..
>>
>> if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
>> dma_dev->device_prep_dma_memcpy = xgene_dma_prep_memcpy;
>
> But the code is dead and will not be tested and hence not maintained. I do
> not see a reason to keep dead code in kernel

Got it, I will remove the memcpy offload support and will send another
patch for review.
>
> --
> ~Vinod
--
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 v2] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

[Rameshwar Sahu]

Hi Vinod,

On Mon, Oct 12, 2015 at 7:53 PM, Vinod Koul <vinod.k...@intel.com> wrote:
> On Fri, Oct 09, 2015 at 10:08:32PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Fri, Oct 9, 2015 at 9:42 PM, Vinod Koul <vinod.k...@intel.com> wrote:
>> > On Thu, Oct 08, 2015 at 02:36:57PM +0530, Rameshwar Prasad Sahu wrote:
>> >> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
>> >> computations. But the bandwidth of the entire DMA engine is shared
>> >> among all channels. This patch re-configures operations availability
>> >> such that one can achieve maximum performance for XOR and PQ
>> >> computation by removing the memory offload operations.
>> >>
>> >> Signed-off-by: Rameshwar Prasad Sahu <rs...@apm.com>
>> >> ---
>> >>  drivers/dma/xgene-dma.c | 1 -
>> >>  1 file changed, 1 deletion(-)
>> >>
>> >> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> >> index 8d57b1b..cd38022 100644
>> >> --- a/drivers/dma/xgene-dma.c
>> >> +++ b/drivers/dma/xgene-dma.c
>> >> @@ -1707,7 +1707,6 @@ static void xgene_dma_set_caps(struct 
>> >> xgene_dma_chan *chan,
>> >>   dma_cap_zero(dma_dev->cap_mask);
>> >>
>> >>   /* Set DMA device capability */
>> >> - dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>> >>   dma_cap_set(DMA_SG, dma_dev->cap_mask);
>> >
>> > This will not work. Still clients can invoke memcpy operation. You need to
>> > remove the callback
>>
>> Got it, instead of removing the callback registration can we keep it
>> inside the condition like..
>>
>> if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
>> dma_dev->device_prep_dma_memcpy = xgene_dma_prep_memcpy;
>
> But the code is dead and will not be tested and hence not maintained. I do
> not see a reason to keep dead code in kernel

Got it, I will remove the memcpy offload support and will send another
patch for review.
>
> --
> ~Vinod
--
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 v2] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

[Rameshwar Sahu]

Hi Vinod,

On Fri, Oct 9, 2015 at 9:42 PM, Vinod Koul  wrote:
> On Thu, Oct 08, 2015 at 02:36:57PM +0530, Rameshwar Prasad Sahu wrote:
>> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
>> computations. But the bandwidth of the entire DMA engine is shared
>> among all channels. This patch re-configures operations availability
>> such that one can achieve maximum performance for XOR and PQ
>> computation by removing the memory offload operations.
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index 8d57b1b..cd38022 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -1707,7 +1707,6 @@ static void xgene_dma_set_caps(struct xgene_dma_chan 
>> *chan,
>>   dma_cap_zero(dma_dev->cap_mask);
>>
>>   /* Set DMA device capability */
>> - dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>>   dma_cap_set(DMA_SG, dma_dev->cap_mask);
>
> This will not work. Still clients can invoke memcpy operation. You need to
> remove the callback

Got it, instead of removing the callback registration can we keep it
inside the condition like..

if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
dma_dev->device_prep_dma_memcpy = xgene_dma_prep_memcpy;


>
> --
> ~Vinod
--
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 v2] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

[Rameshwar Sahu]

Hi Vinod,

On Fri, Oct 9, 2015 at 9:42 PM, Vinod Koul  wrote:
> On Thu, Oct 08, 2015 at 02:36:57PM +0530, Rameshwar Prasad Sahu wrote:
>> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
>> computations. But the bandwidth of the entire DMA engine is shared
>> among all channels. This patch re-configures operations availability
>> such that one can achieve maximum performance for XOR and PQ
>> computation by removing the memory offload operations.
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index 8d57b1b..cd38022 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -1707,7 +1707,6 @@ static void xgene_dma_set_caps(struct xgene_dma_chan 
>> *chan,
>>   dma_cap_zero(dma_dev->cap_mask);
>>
>>   /* Set DMA device capability */
>> - dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>>   dma_cap_set(DMA_SG, dma_dev->cap_mask);
>
> This will not work. Still clients can invoke memcpy operation. You need to
> remove the callback

Got it, instead of removing the callback registration can we keep it
inside the condition like..

if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
dma_dev->device_prep_dma_memcpy = xgene_dma_prep_memcpy;


>
> --
> ~Vinod
--
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] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

[Rameshwar Sahu]

On Thu, Oct 8, 2015 at 2:23 PM, Arnd Bergmann  wrote:
> On Thursday 08 October 2015 13:55:16 Rameshwar Prasad Sahu wrote:
>> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
>> computations. But the bandwidth of the entire DMA engine is shared
>> among all channels. This patch re-configures operations availability
>> such that one can achieve maximum performance for XOR and PQ
>> computation by removing the memory offload operations.
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index 8d57b1b..2998fcb 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -154,6 +154,7 @@
>>  #define XGENE_DMA_MAX_XOR_SRC  5
>>  #define XGENE_DMA_16K_BUFFER_LEN_CODE  0x0
>>  #define XGENE_DMA_INVALID_LEN_CODE 0x7800ULL
>> +#undef XGENE_DMA_MEMCPY_ENABLE
>>
>>  /* X-Gene DMA descriptor error codes */
>>  #define ERR_DESC_AXI   0x01
>> @@ -1707,7 +1708,9 @@ static void xgene_dma_set_caps(struct xgene_dma_chan 
>> *chan,
>> dma_cap_zero(dma_dev->cap_mask);
>>
>> /* Set DMA device capability */
>> +#ifdef XGENE_DMA_MEMCPY_ENABLE
>> dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>> +#endif
>> dma_cap_set(DMA_SG, dma_dev->cap_mask);
>>
>> /* Basically here, the X-Gene SoC DMA engine channel 0 supports XOR
>
> I don't see what the #ifdef gains you here when the setting is
> hardcoded. Why not just remove that DMA_MEMCPY capability completely
> if you don't want to use it?

Okay Arnd,
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

[Rameshwar Sahu]

On Thu, Oct 8, 2015 at 2:23 PM, Arnd Bergmann  wrote:
> On Thursday 08 October 2015 13:55:16 Rameshwar Prasad Sahu wrote:
>> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
>> computations. But the bandwidth of the entire DMA engine is shared
>> among all channels. This patch re-configures operations availability
>> such that one can achieve maximum performance for XOR and PQ
>> computation by removing the memory offload operations.
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index 8d57b1b..2998fcb 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -154,6 +154,7 @@
>>  #define XGENE_DMA_MAX_XOR_SRC  5
>>  #define XGENE_DMA_16K_BUFFER_LEN_CODE  0x0
>>  #define XGENE_DMA_INVALID_LEN_CODE 0x7800ULL
>> +#undef XGENE_DMA_MEMCPY_ENABLE
>>
>>  /* X-Gene DMA descriptor error codes */
>>  #define ERR_DESC_AXI   0x01
>> @@ -1707,7 +1708,9 @@ static void xgene_dma_set_caps(struct xgene_dma_chan 
>> *chan,
>> dma_cap_zero(dma_dev->cap_mask);
>>
>> /* Set DMA device capability */
>> +#ifdef XGENE_DMA_MEMCPY_ENABLE
>> dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>> +#endif
>> dma_cap_set(DMA_SG, dma_dev->cap_mask);
>>
>> /* Basically here, the X-Gene SoC DMA engine channel 0 supports XOR
>
> I don't see what the #ifdef gains you here when the setting is
> hardcoded. Why not just remove that DMA_MEMCPY capability completely
> if you don't want to use it?

Okay Arnd,
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] dmaengine: xgene-dma: Fix overwritting DMA tx ring

[Rameshwar Sahu]

Hi Vinod,

On Wed, Sep 16, 2015 at 1:33 PM, Rameshwar Prasad Sahu  wrote:
> This patch fixes an over flow issue with the TX ring descriptor. Each
> descriptor is 32B in size and an operation requires 2 of these
> descriptors.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/dma/xgene-dma.c | 37 +++--
>  1 file changed, 11 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index b23e8d5..21ba2cc 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -59,7 +59,6 @@
>  #define XGENE_DMA_RING_MEM_RAM_SHUTDOWN0xD070
>  #define XGENE_DMA_RING_BLK_MEM_RDY 0xD074
>  #define XGENE_DMA_RING_BLK_MEM_RDY_VAL 0x
> -#define XGENE_DMA_RING_DESC_CNT(v) (((v) & 0x0001FFFE) >> 1)
>  #define XGENE_DMA_RING_ID_GET(owner, num)  (((owner) << 6) | (num))
>  #define XGENE_DMA_RING_DST_ID(v)   ((1 << 10) | (v))
>  #define XGENE_DMA_RING_CMD_OFFSET  0x2C
> @@ -379,14 +378,6 @@ static u8 xgene_dma_encode_xor_flyby(u32 src_cnt)
> return flyby_type[src_cnt];
>  }
>
> -static u32 xgene_dma_ring_desc_cnt(struct xgene_dma_ring *ring)
> -{
> -   u32 __iomem *cmd_base = ring->cmd_base;
> -   u32 ring_state = ioread32(_base[1]);
> -
> -   return XGENE_DMA_RING_DESC_CNT(ring_state);
> -}
> -
>  static void xgene_dma_set_src_buffer(__le64 *ext8, size_t *len,
>  dma_addr_t *paddr)
>  {
> @@ -659,15 +650,12 @@ static void xgene_dma_clean_running_descriptor(struct 
> xgene_dma_chan *chan,
> dma_pool_free(chan->desc_pool, desc, desc->tx.phys);
>  }
>
> -static int xgene_chan_xfer_request(struct xgene_dma_ring *ring,
> -  struct xgene_dma_desc_sw *desc_sw)
> +static void xgene_chan_xfer_request(struct xgene_dma_chan *chan,
> +   struct xgene_dma_desc_sw *desc_sw)
>  {
> +   struct xgene_dma_ring *ring = >tx_ring;
> struct xgene_dma_desc_hw *desc_hw;
>
> -   /* Check if can push more descriptor to hw for execution */
> -   if (xgene_dma_ring_desc_cnt(ring) > (ring->slots - 2))
> -   return -EBUSY;
> -
> /* Get hw descriptor from DMA tx ring */
> desc_hw = >desc_hw[ring->head];
>
> @@ -694,11 +682,13 @@ static int xgene_chan_xfer_request(struct 
> xgene_dma_ring *ring,
> memcpy(desc_hw, _sw->desc2, sizeof(*desc_hw));
> }
>
> +   /* Increment the pending transaction count */
> +   chan->pending += ((desc_sw->flags &
> + XGENE_DMA_FLAG_64B_DESC) ? 2 : 1);
> +
> /* Notify the hw that we have descriptor ready for execution */
> iowrite32((desc_sw->flags & XGENE_DMA_FLAG_64B_DESC) ?
>   2 : 1, ring->cmd);
> -
> -   return 0;
>  }
>
>  /**
> @@ -710,7 +700,6 @@ static int xgene_chan_xfer_request(struct xgene_dma_ring 
> *ring,
>  static void xgene_chan_xfer_ld_pending(struct xgene_dma_chan *chan)
>  {
> struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
> -   int ret;
>
> /*
>  * If the list of pending descriptors is empty, then we
> @@ -735,18 +724,13 @@ static void xgene_chan_xfer_ld_pending(struct 
> xgene_dma_chan *chan)
> if (chan->pending >= chan->max_outstanding)
> return;
>
> -   ret = xgene_chan_xfer_request(>tx_ring, desc_sw);
> -   if (ret)
> -   return;
> +   xgene_chan_xfer_request(chan, desc_sw);
>
> /*
>  * Delete this element from ld pending queue and append it to
>  * ld running queue
>  */
> list_move_tail(_sw->node, >ld_running);
> -
> -   /* Increment the pending transaction count */
> -   chan->pending++;
> }
>  }
>
> @@ -821,7 +805,8 @@ static void xgene_dma_cleanup_descriptors(struct 
> xgene_dma_chan *chan)
>  * Decrement the pending transaction count
>  * as we have processed one
>  */
> -   chan->pending--;
> +   chan->pending -= ((desc_sw->flags &
> + XGENE_DMA_FLAG_64B_DESC) ? 2 : 1);
>
> /*
>  * Delete this node from ld running queue and append it to
> @@ -1482,7 +1467,7 @@ static int xgene_dma_create_chan_rings(struct 
> xgene_dma_chan *chan)
>  tx_ring->id, tx_ring->num, tx_ring->desc_vaddr);
>
> /* Set the max outstanding request possible to this channel */
> -   chan->max_outstanding = rx_ring->slots;
> +   chan->max_outstanding = tx_ring->slots;
>
> return ret;
>  }
> --
> 1.8.2.1
>

Any comments on above patch ??
--
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  

Re: [PATCH] dmaengine: xgene-dma: Fix overwritting DMA tx ring

[Rameshwar Sahu]

Hi Vinod,

On Wed, Sep 16, 2015 at 1:33 PM, Rameshwar Prasad Sahu  wrote:
> This patch fixes an over flow issue with the TX ring descriptor. Each
> descriptor is 32B in size and an operation requires 2 of these
> descriptors.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/dma/xgene-dma.c | 37 +++--
>  1 file changed, 11 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index b23e8d5..21ba2cc 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -59,7 +59,6 @@
>  #define XGENE_DMA_RING_MEM_RAM_SHUTDOWN0xD070
>  #define XGENE_DMA_RING_BLK_MEM_RDY 0xD074
>  #define XGENE_DMA_RING_BLK_MEM_RDY_VAL 0x
> -#define XGENE_DMA_RING_DESC_CNT(v) (((v) & 0x0001FFFE) >> 1)
>  #define XGENE_DMA_RING_ID_GET(owner, num)  (((owner) << 6) | (num))
>  #define XGENE_DMA_RING_DST_ID(v)   ((1 << 10) | (v))
>  #define XGENE_DMA_RING_CMD_OFFSET  0x2C
> @@ -379,14 +378,6 @@ static u8 xgene_dma_encode_xor_flyby(u32 src_cnt)
> return flyby_type[src_cnt];
>  }
>
> -static u32 xgene_dma_ring_desc_cnt(struct xgene_dma_ring *ring)
> -{
> -   u32 __iomem *cmd_base = ring->cmd_base;
> -   u32 ring_state = ioread32(_base[1]);
> -
> -   return XGENE_DMA_RING_DESC_CNT(ring_state);
> -}
> -
>  static void xgene_dma_set_src_buffer(__le64 *ext8, size_t *len,
>  dma_addr_t *paddr)
>  {
> @@ -659,15 +650,12 @@ static void xgene_dma_clean_running_descriptor(struct 
> xgene_dma_chan *chan,
> dma_pool_free(chan->desc_pool, desc, desc->tx.phys);
>  }
>
> -static int xgene_chan_xfer_request(struct xgene_dma_ring *ring,
> -  struct xgene_dma_desc_sw *desc_sw)
> +static void xgene_chan_xfer_request(struct xgene_dma_chan *chan,
> +   struct xgene_dma_desc_sw *desc_sw)
>  {
> +   struct xgene_dma_ring *ring = >tx_ring;
> struct xgene_dma_desc_hw *desc_hw;
>
> -   /* Check if can push more descriptor to hw for execution */
> -   if (xgene_dma_ring_desc_cnt(ring) > (ring->slots - 2))
> -   return -EBUSY;
> -
> /* Get hw descriptor from DMA tx ring */
> desc_hw = >desc_hw[ring->head];
>
> @@ -694,11 +682,13 @@ static int xgene_chan_xfer_request(struct 
> xgene_dma_ring *ring,
> memcpy(desc_hw, _sw->desc2, sizeof(*desc_hw));
> }
>
> +   /* Increment the pending transaction count */
> +   chan->pending += ((desc_sw->flags &
> + XGENE_DMA_FLAG_64B_DESC) ? 2 : 1);
> +
> /* Notify the hw that we have descriptor ready for execution */
> iowrite32((desc_sw->flags & XGENE_DMA_FLAG_64B_DESC) ?
>   2 : 1, ring->cmd);
> -
> -   return 0;
>  }
>
>  /**
> @@ -710,7 +700,6 @@ static int xgene_chan_xfer_request(struct xgene_dma_ring 
> *ring,
>  static void xgene_chan_xfer_ld_pending(struct xgene_dma_chan *chan)
>  {
> struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
> -   int ret;
>
> /*
>  * If the list of pending descriptors is empty, then we
> @@ -735,18 +724,13 @@ static void xgene_chan_xfer_ld_pending(struct 
> xgene_dma_chan *chan)
> if (chan->pending >= chan->max_outstanding)
> return;
>
> -   ret = xgene_chan_xfer_request(>tx_ring, desc_sw);
> -   if (ret)
> -   return;
> +   xgene_chan_xfer_request(chan, desc_sw);
>
> /*
>  * Delete this element from ld pending queue and append it to
>  * ld running queue
>  */
> list_move_tail(_sw->node, >ld_running);
> -
> -   /* Increment the pending transaction count */
> -   chan->pending++;
> }
>  }
>
> @@ -821,7 +805,8 @@ static void xgene_dma_cleanup_descriptors(struct 
> xgene_dma_chan *chan)
>  * Decrement the pending transaction count
>  * as we have processed one
>  */
> -   chan->pending--;
> +   chan->pending -= ((desc_sw->flags &
> + XGENE_DMA_FLAG_64B_DESC) ? 2 : 1);
>
> /*
>  * Delete this node from ld running queue and append it to
> @@ -1482,7 +1467,7 @@ static int xgene_dma_create_chan_rings(struct 
> xgene_dma_chan *chan)
>  tx_ring->id, tx_ring->num, tx_ring->desc_vaddr);
>
> /* Set the max outstanding request possible to this channel */
> -   chan->max_outstanding = rx_ring->slots;
> +   chan->max_outstanding = tx_ring->slots;
>
> return ret;
>  }
> --
> 1.8.2.1
>

Any comments on above patch ??
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path

[Rameshwar Sahu]

On Fri, Aug 21, 2015 at 2:21 PM, Vinod Koul  wrote:
> On Fri, Aug 21, 2015 at 02:15:08PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Fri, Aug 21, 2015 at 2:09 PM, Vinod Koul  wrote:
>> > On Thu, Aug 20, 2015 at 04:00:56PM +0530, Rameshwar Prasad Sahu wrote:
>> >> This patch fixes the an locking issue where client callback performs
>> > 
>> > ??
>> >
>> >> further submission.
>> > Do you men you are preventing that or fixing for this to be allowed?
>>
>> Fixing lock to allow client to submit further request in there
>> callback routine if they would like.
>
> Okay please fix the changelog to make it clear :)

Okay Vinod

>
> --
> ~Vinod
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path

[Rameshwar Sahu]

Hi Vinod,

On Fri, Aug 21, 2015 at 2:09 PM, Vinod Koul  wrote:
> On Thu, Aug 20, 2015 at 04:00:56PM +0530, Rameshwar Prasad Sahu wrote:
>> This patch fixes the an locking issue where client callback performs
> 
> ??
>
>> further submission.
> Do you men you are preventing that or fixing for this to be allowed?

Fixing lock to allow client to submit further request in there
callback routine if they would like.
>
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c | 33 ++---
>>  1 file changed, 22 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index d1c8809..0b82bc0 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -763,12 +763,17 @@ static void xgene_dma_cleanup_descriptors(struct 
>> xgene_dma_chan *chan)
>>   struct xgene_dma_ring *ring = >rx_ring;
>>   struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
>>   struct xgene_dma_desc_hw *desc_hw;
>> + struct list_head ld_completed;
>>   u8 status;
>>
>> + INIT_LIST_HEAD(_completed);
>> +
>> + spin_lock_bh(>lock);
>> +
>>   /* Clean already completed and acked descriptors */
>>   xgene_dma_clean_completed_descriptor(chan);
>>
>> - /* Run the callback for each descriptor, in order */
>> + /* Move all completed descriptors to ld completed queue, in order */
>>   list_for_each_entry_safe(desc_sw, _desc_sw, >ld_running, node) {
>>   /* Get subsequent hw descriptor from DMA rx ring */
>>   desc_hw = >desc_hw[ring->head];
>> @@ -811,15 +816,17 @@ static void xgene_dma_cleanup_descriptors(struct 
>> xgene_dma_chan *chan)
>>   /* Mark this hw descriptor as processed */
>>   desc_hw->m0 = cpu_to_le64(XGENE_DMA_DESC_EMPTY_SIGNATURE);
>>
>> - xgene_dma_run_tx_complete_actions(chan, desc_sw);
>> -
>> - xgene_dma_clean_running_descriptor(chan, desc_sw);
>> -
>>   /*
>>* Decrement the pending transaction count
>>* as we have processed one
>>*/
>>   chan->pending--;
>> +
>> + /*
>> +  * Delete this node from ld running queue and append it to
>> +  * ld completed queue for further processing
>> +  */
>> + list_move_tail(_sw->node, _completed);
>>   }
>>
>>   /*
>> @@ -828,6 +835,14 @@ static void xgene_dma_cleanup_descriptors(struct 
>> xgene_dma_chan *chan)
>>* ahead and free the descriptors below.
>>*/
>>   xgene_chan_xfer_ld_pending(chan);
>> +
>> + spin_unlock_bh(>lock);
>> +
>> + /* Run the callback for each descriptor, in order */
>> + list_for_each_entry_safe(desc_sw, _desc_sw, _completed, node) {
>> + xgene_dma_run_tx_complete_actions(chan, desc_sw);
>> + xgene_dma_clean_running_descriptor(chan, desc_sw);
>> + }
>>  }
>>
>>  static int xgene_dma_alloc_chan_resources(struct dma_chan *dchan)
>> @@ -876,11 +891,11 @@ static void xgene_dma_free_chan_resources(struct 
>> dma_chan *dchan)
>>   if (!chan->desc_pool)
>>   return;
>>
>> - spin_lock_bh(>lock);
>> -
>>   /* Process all running descriptor */
>>   xgene_dma_cleanup_descriptors(chan);
>>
>> + spin_lock_bh(>lock);
>> +
>>   /* Clean all link descriptor queues */
>>   xgene_dma_free_desc_list(chan, >ld_pending);
>>   xgene_dma_free_desc_list(chan, >ld_running);
>> @@ -1200,15 +1215,11 @@ static void xgene_dma_tasklet_cb(unsigned long data)
>>  {
>>   struct xgene_dma_chan *chan = (struct xgene_dma_chan *)data;
>>
>> - spin_lock_bh(>lock);
>> -
>>   /* Run all cleanup for descriptors which have been completed */
>>   xgene_dma_cleanup_descriptors(chan);
>>
>>   /* Re-enable DMA channel IRQ */
>>   enable_irq(chan->rx_irq);
>> -
>> - spin_unlock_bh(>lock);
>>  }
>>
>>  static irqreturn_t xgene_dma_chan_ring_isr(int irq, void *id)
>> --
>> 1.8.2.1
>>
>
> --
> ~Vinod
--
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] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path

[Rameshwar Sahu]

Hi Vinod,

On Fri, Aug 21, 2015 at 2:09 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Aug 20, 2015 at 04:00:56PM +0530, Rameshwar Prasad Sahu wrote:
 This patch fixes the an locking issue where client callback performs
 
 ??

 further submission.
 Do you men you are preventing that or fixing for this to be allowed?

Fixing lock to allow client to submit further request in there
callback routine if they would like.


 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 ---
  drivers/dma/xgene-dma.c | 33 ++---
  1 file changed, 22 insertions(+), 11 deletions(-)

 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 index d1c8809..0b82bc0 100644
 --- a/drivers/dma/xgene-dma.c
 +++ b/drivers/dma/xgene-dma.c
 @@ -763,12 +763,17 @@ static void xgene_dma_cleanup_descriptors(struct 
 xgene_dma_chan *chan)
   struct xgene_dma_ring *ring = chan-rx_ring;
   struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
   struct xgene_dma_desc_hw *desc_hw;
 + struct list_head ld_completed;
   u8 status;

 + INIT_LIST_HEAD(ld_completed);
 +
 + spin_lock_bh(chan-lock);
 +
   /* Clean already completed and acked descriptors */
   xgene_dma_clean_completed_descriptor(chan);

 - /* Run the callback for each descriptor, in order */
 + /* Move all completed descriptors to ld completed queue, in order */
   list_for_each_entry_safe(desc_sw, _desc_sw, chan-ld_running, node) {
   /* Get subsequent hw descriptor from DMA rx ring */
   desc_hw = ring-desc_hw[ring-head];
 @@ -811,15 +816,17 @@ static void xgene_dma_cleanup_descriptors(struct 
 xgene_dma_chan *chan)
   /* Mark this hw descriptor as processed */
   desc_hw-m0 = cpu_to_le64(XGENE_DMA_DESC_EMPTY_SIGNATURE);

 - xgene_dma_run_tx_complete_actions(chan, desc_sw);
 -
 - xgene_dma_clean_running_descriptor(chan, desc_sw);
 -
   /*
* Decrement the pending transaction count
* as we have processed one
*/
   chan-pending--;
 +
 + /*
 +  * Delete this node from ld running queue and append it to
 +  * ld completed queue for further processing
 +  */
 + list_move_tail(desc_sw-node, ld_completed);
   }

   /*
 @@ -828,6 +835,14 @@ static void xgene_dma_cleanup_descriptors(struct 
 xgene_dma_chan *chan)
* ahead and free the descriptors below.
*/
   xgene_chan_xfer_ld_pending(chan);
 +
 + spin_unlock_bh(chan-lock);
 +
 + /* Run the callback for each descriptor, in order */
 + list_for_each_entry_safe(desc_sw, _desc_sw, ld_completed, node) {
 + xgene_dma_run_tx_complete_actions(chan, desc_sw);
 + xgene_dma_clean_running_descriptor(chan, desc_sw);
 + }
  }

  static int xgene_dma_alloc_chan_resources(struct dma_chan *dchan)
 @@ -876,11 +891,11 @@ static void xgene_dma_free_chan_resources(struct 
 dma_chan *dchan)
   if (!chan-desc_pool)
   return;

 - spin_lock_bh(chan-lock);
 -
   /* Process all running descriptor */
   xgene_dma_cleanup_descriptors(chan);

 + spin_lock_bh(chan-lock);
 +
   /* Clean all link descriptor queues */
   xgene_dma_free_desc_list(chan, chan-ld_pending);
   xgene_dma_free_desc_list(chan, chan-ld_running);
 @@ -1200,15 +1215,11 @@ static void xgene_dma_tasklet_cb(unsigned long data)
  {
   struct xgene_dma_chan *chan = (struct xgene_dma_chan *)data;

 - spin_lock_bh(chan-lock);
 -
   /* Run all cleanup for descriptors which have been completed */
   xgene_dma_cleanup_descriptors(chan);

   /* Re-enable DMA channel IRQ */
   enable_irq(chan-rx_irq);
 -
 - spin_unlock_bh(chan-lock);
  }

  static irqreturn_t xgene_dma_chan_ring_isr(int irq, void *id)
 --
 1.8.2.1


 --
 ~Vinod
--
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] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path

[Rameshwar Sahu]

On Fri, Aug 21, 2015 at 2:21 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Fri, Aug 21, 2015 at 02:15:08PM +0530, Rameshwar Sahu wrote:
 Hi Vinod,

 On Fri, Aug 21, 2015 at 2:09 PM, Vinod Koul vinod.k...@intel.com wrote:
  On Thu, Aug 20, 2015 at 04:00:56PM +0530, Rameshwar Prasad Sahu wrote:
  This patch fixes the an locking issue where client callback performs
  
  ??
 
  further submission.
  Do you men you are preventing that or fixing for this to be allowed?

 Fixing lock to allow client to submit further request in there
 callback routine if they would like.

 Okay please fix the changelog to make it clear :)

Okay Vinod


 --
 ~Vinod

 --
 To unsubscribe from this list: send the line unsubscribe dmaengine in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v1 1/4] dmaengine: Add support for new feature CRC32C

[Rameshwar Sahu]

On Thu, Aug 20, 2015 at 12:38 PM, Vinod Koul  wrote:
> On Thu, Aug 20, 2015 at 11:59:07AM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul  wrote:
>> > On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
>> >> This patch adds support for new feature CRC32C calculation in
>> >> dmaengine framework.
>> >
>> > Looks okay can you please update Documentation also
>>
>> Thanks, I will update Documentation.
>
> Also add a wrapper for new API
Okay
>
> --
> ~Vinod
>
--
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 v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver

[Rameshwar Sahu]

Hi Vinod,

On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul  wrote:
> On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
>> + nents = sg_nents(req->src);
>> + sg_count = dma_map_sg(dev, req->src, nents, DMA_TO_DEVICE);
>> + if (!sg_count) {
>> + dev_err(dev, "Failed to map src sg");
>> + return -ENOMEM;
> mapping error shouldn't be no mem error
Okay, I guess then -EIO will be fine here??
>
>> + }
>> +
>> + if (sg_count > XGENE_DMA_MAX_FLYBY_SRC_CNT) {
>> + dev_err(dev, "Unsupported src sg len\n");
> would be worth printing length
Okay,
>
>> + goto err;
>> + }
>> +
>> + flags = DMA_CTRL_ACK;
> why ACK?
My understanding about DMA_CTRL_ACK is dma engine driver can
re-use/free this descriptor once operation completed in cleanup path.
Am I correct ??
But yes, I need to look on this because recently you have added one
more descriptor flag.

>
>> +
>> + tx = dchan->device->device_prep_dma_crc32c(dchan, req->src,
>> +req->nbytes,
>> +reqctx->seed,
>> +req->result,
>> +flags);
> We should add helper for this
Okay
>
> --
> ~Vinod
>
--
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 v1 2/4] dmaengine: xgene-dma: Add support for CRC32C calculation via DMA engine

[Rameshwar Sahu]

Hi Vinod,

On Thu, Aug 20, 2015 at 11:10 AM, Vinod Koul  wrote:
> On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
>> + /* Invalidate unused source address field */
>> + for (; i < 4; i++)
>> + xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
>> +
>> + /* Check whether requested buffer processed */
>> + if (nbytes) {
>> + chan_err(chan, "Src count crossed maximum limit\n");
>> + return -EINVAL;
> no cleanup ?
Here not required, cleanup I am doing in parent function from where
this function is getting called in case of failure.
>
>> +struct dma_async_tx_descriptor *xgene_dma_prep_flyby(
>> + struct xgene_dma_chan *chan, struct scatterlist *src_sg,
>> + size_t len, u32 seed, u8 *result, unsigned long flags, u8 opcode)
> please fix style here

Could you explain me What kind of coding style you would like here ??
>
>> +struct dma_async_tx_descriptor *xgene_dma_prep_crc32c(
>> + struct dma_chan *dchan, struct scatterlist *src_sg,
>> + size_t len, u32 seed, u8 *result, unsigned long flags)
> here too
>
>> @@ -1309,8 +1512,13 @@ static void xgene_dma_setup_ring(struct 
>> xgene_dma_ring *ring)
>> ring->pdma->csr_ring + XGENE_DMA_RING_ID);
>>
>>   /* Set DMA ring buffer */
>> - iowrite32(XGENE_DMA_RING_ID_BUF_SETUP(ring->num),
>> -   ring->pdma->csr_ring + XGENE_DMA_RING_ID_BUF);
>> + ring_id_buf = XGENE_DMA_RING_ID_BUF_SETUP(ring->num);
>> +
>> + if (ring->is_bufpool)
>> + ring_id_buf |= XGENE_DMA_RING_IS_BUFPOOL;
>> +
>> + iowrite32(ring_id_buf, ring->pdma->csr_ring +
>> +   XGENE_DMA_RING_ID_BUF);
> pls fix style here
I didn't see any alignment issue here, just follow checkpatch that
argument should start just after "function(" in next line also.
>
> --
> ~Vinod
--
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 v1 1/4] dmaengine: Add support for new feature CRC32C

[Rameshwar Sahu]

Hi Vinod,

On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul  wrote:
> On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
>> This patch adds support for new feature CRC32C calculation in
>> dmaengine framework.
>
> Looks okay can you please update Documentation also

Thanks, I will update Documentation.
>
> --
> ~Vinod
>
--
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 v1 1/4] dmaengine: Add support for new feature CRC32C

[Rameshwar Sahu]

On Thu, Aug 20, 2015 at 12:38 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Aug 20, 2015 at 11:59:07AM +0530, Rameshwar Sahu wrote:
 Hi Vinod,

 On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
  This patch adds support for new feature CRC32C calculation in
  dmaengine framework.
 
  Looks okay can you please update Documentation also

 Thanks, I will update Documentation.

 Also add a wrapper for new API
Okay

 --
 ~Vinod

--
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 v1 1/4] dmaengine: Add support for new feature CRC32C

[Rameshwar Sahu]

Hi Vinod,

On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
 This patch adds support for new feature CRC32C calculation in
 dmaengine framework.

 Looks okay can you please update Documentation also

Thanks, I will update Documentation.

 --
 ~Vinod

--
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 v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver

[Rameshwar Sahu]

Hi Vinod,

On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
 + nents = sg_nents(req-src);
 + sg_count = dma_map_sg(dev, req-src, nents, DMA_TO_DEVICE);
 + if (!sg_count) {
 + dev_err(dev, Failed to map src sg);
 + return -ENOMEM;
 mapping error shouldn't be no mem error
Okay, I guess then -EIO will be fine here??

 + }
 +
 + if (sg_count  XGENE_DMA_MAX_FLYBY_SRC_CNT) {
 + dev_err(dev, Unsupported src sg len\n);
 would be worth printing length
Okay,

 + goto err;
 + }
 +
 + flags = DMA_CTRL_ACK;
 why ACK?
My understanding about DMA_CTRL_ACK is dma engine driver can
re-use/free this descriptor once operation completed in cleanup path.
Am I correct ??
But yes, I need to look on this because recently you have added one
more descriptor flag.


 +
 + tx = dchan-device-device_prep_dma_crc32c(dchan, req-src,
 +req-nbytes,
 +reqctx-seed,
 +req-result,
 +flags);
 We should add helper for this
Okay

 --
 ~Vinod

--
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 v1 2/4] dmaengine: xgene-dma: Add support for CRC32C calculation via DMA engine

[Rameshwar Sahu]

Hi Vinod,

On Thu, Aug 20, 2015 at 11:10 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
 + /* Invalidate unused source address field */
 + for (; i  4; i++)
 + xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
 +
 + /* Check whether requested buffer processed */
 + if (nbytes) {
 + chan_err(chan, Src count crossed maximum limit\n);
 + return -EINVAL;
 no cleanup ?
Here not required, cleanup I am doing in parent function from where
this function is getting called in case of failure.

 +struct dma_async_tx_descriptor *xgene_dma_prep_flyby(
 + struct xgene_dma_chan *chan, struct scatterlist *src_sg,
 + size_t len, u32 seed, u8 *result, unsigned long flags, u8 opcode)
 please fix style here

Could you explain me What kind of coding style you would like here ??

 +struct dma_async_tx_descriptor *xgene_dma_prep_crc32c(
 + struct dma_chan *dchan, struct scatterlist *src_sg,
 + size_t len, u32 seed, u8 *result, unsigned long flags)
 here too

 @@ -1309,8 +1512,13 @@ static void xgene_dma_setup_ring(struct 
 xgene_dma_ring *ring)
 ring-pdma-csr_ring + XGENE_DMA_RING_ID);

   /* Set DMA ring buffer */
 - iowrite32(XGENE_DMA_RING_ID_BUF_SETUP(ring-num),
 -   ring-pdma-csr_ring + XGENE_DMA_RING_ID_BUF);
 + ring_id_buf = XGENE_DMA_RING_ID_BUF_SETUP(ring-num);
 +
 + if (ring-is_bufpool)
 + ring_id_buf |= XGENE_DMA_RING_IS_BUFPOOL;
 +
 + iowrite32(ring_id_buf, ring-pdma-csr_ring +
 +   XGENE_DMA_RING_ID_BUF);
 pls fix style here
I didn't see any alignment issue here, just follow checkpatch that
argument should start just after function( in next line also.

 --
 ~Vinod
--
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] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Tue, Jul 21, 2015 at 6:44 PM, Rameshwar Prasad Sahu  wrote:
> This patch adds ACPI support for the APM X-Gene DMA engine driver.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/dma/xgene-dma.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index dff22ab..d0a148d 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -21,6 +21,7 @@
>   * NOTE: PM support is currently not available.
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1944,16 +1945,18 @@ static int xgene_dma_probe(struct platform_device 
> *pdev)
> return ret;
>
> pdma->clk = devm_clk_get(>dev, NULL);
> -   if (IS_ERR(pdma->clk)) {
> +   if (IS_ERR(pdma->clk) && !ACPI_COMPANION(>dev)) {
> dev_err(>dev, "Failed to get clk\n");
> return PTR_ERR(pdma->clk);
> }
>
> /* Enable clk before accessing registers */
> -   ret = clk_prepare_enable(pdma->clk);
> -   if (ret) {
> -   dev_err(>dev, "Failed to enable clk %d\n", ret);
> -   return ret;
> +   if (!IS_ERR(pdma->clk)) {
> +   ret = clk_prepare_enable(pdma->clk);
> +   if (ret) {
> +   dev_err(>dev, "Failed to enable clk %d\n", ret);
> +   return ret;
> +   }
> }
>
> /* Remove DMA RAM out of shutdown */
> @@ -1998,7 +2001,8 @@ err_request_irq:
>
>  err_dma_mask:
>  err_clk_enable:
> -   clk_disable_unprepare(pdma->clk);
> +   if (!IS_ERR(pdma->clk))
> +   clk_disable_unprepare(pdma->clk);
>
> return ret;
>  }
> @@ -2022,11 +2026,20 @@ static int xgene_dma_remove(struct platform_device 
> *pdev)
> xgene_dma_delete_chan_rings(chan);
> }
>
> -   clk_disable_unprepare(pdma->clk);
> +   if (!IS_ERR(pdma->clk))
> +   clk_disable_unprepare(pdma->clk);
>
> return 0;
>  }
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id xgene_dma_acpi_match_ptr[] = {
> +   {"APMC0D43", 0},
> +   {},
> +};
> +MODULE_DEVICE_TABLE(acpi, xgene_dma_acpi_match_ptr);
> +#endif
> +
>  static const struct of_device_id xgene_dma_of_match_ptr[] = {
> {.compatible = "apm,xgene-storm-dma",},
> {},
> @@ -2039,6 +2052,7 @@ static struct platform_driver xgene_dma_driver = {
> .driver = {
> .name = "X-Gene-DMA",
> .of_match_table = xgene_dma_of_match_ptr,
> +   .acpi_match_table = ACPI_PTR(xgene_dma_acpi_match_ptr),
> },
>  };
>
> --
> 1.8.2.1


Any Comments on the above patch ??
--
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] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Tue, Jul 21, 2015 at 6:44 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch adds ACPI support for the APM X-Gene DMA engine driver.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 ---
  drivers/dma/xgene-dma.c | 28 +---
  1 file changed, 21 insertions(+), 7 deletions(-)

 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 index dff22ab..d0a148d 100644
 --- a/drivers/dma/xgene-dma.c
 +++ b/drivers/dma/xgene-dma.c
 @@ -21,6 +21,7 @@
   * NOTE: PM support is currently not available.
   */

 +#include linux/acpi.h
  #include linux/clk.h
  #include linux/delay.h
  #include linux/dma-mapping.h
 @@ -1944,16 +1945,18 @@ static int xgene_dma_probe(struct platform_device 
 *pdev)
 return ret;

 pdma-clk = devm_clk_get(pdev-dev, NULL);
 -   if (IS_ERR(pdma-clk)) {
 +   if (IS_ERR(pdma-clk)  !ACPI_COMPANION(pdev-dev)) {
 dev_err(pdev-dev, Failed to get clk\n);
 return PTR_ERR(pdma-clk);
 }

 /* Enable clk before accessing registers */
 -   ret = clk_prepare_enable(pdma-clk);
 -   if (ret) {
 -   dev_err(pdev-dev, Failed to enable clk %d\n, ret);
 -   return ret;
 +   if (!IS_ERR(pdma-clk)) {
 +   ret = clk_prepare_enable(pdma-clk);
 +   if (ret) {
 +   dev_err(pdev-dev, Failed to enable clk %d\n, ret);
 +   return ret;
 +   }
 }

 /* Remove DMA RAM out of shutdown */
 @@ -1998,7 +2001,8 @@ err_request_irq:

  err_dma_mask:
  err_clk_enable:
 -   clk_disable_unprepare(pdma-clk);
 +   if (!IS_ERR(pdma-clk))
 +   clk_disable_unprepare(pdma-clk);

 return ret;
  }
 @@ -2022,11 +2026,20 @@ static int xgene_dma_remove(struct platform_device 
 *pdev)
 xgene_dma_delete_chan_rings(chan);
 }

 -   clk_disable_unprepare(pdma-clk);
 +   if (!IS_ERR(pdma-clk))
 +   clk_disable_unprepare(pdma-clk);

 return 0;
  }

 +#ifdef CONFIG_ACPI
 +static const struct acpi_device_id xgene_dma_acpi_match_ptr[] = {
 +   {APMC0D43, 0},
 +   {},
 +};
 +MODULE_DEVICE_TABLE(acpi, xgene_dma_acpi_match_ptr);
 +#endif
 +
  static const struct of_device_id xgene_dma_of_match_ptr[] = {
 {.compatible = apm,xgene-storm-dma,},
 {},
 @@ -2039,6 +2052,7 @@ static struct platform_driver xgene_dma_driver = {
 .driver = {
 .name = X-Gene-DMA,
 .of_match_table = xgene_dma_of_match_ptr,
 +   .acpi_match_table = ACPI_PTR(xgene_dma_acpi_match_ptr),
 },
  };

 --
 1.8.2.1


Any Comments on the above patch ??
--
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 v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver

[Rameshwar Sahu]

On Fri, Jul 31, 2015 at 12:43 PM, Herbert Xu
 wrote:
> On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
>>
>> + .cra_name   = "xgene(crc32c)",
>> + .cra_driver_name= "crc32c-xgene",
>
> This looks wrong.  If you're implementing crc32c then cra_name
> should be just crc32c, i.e., the name of the algorithm that you
> are providing.

Okay, I will change it to crc32c only.
>
>> +MODULE_DESCRIPTION("APM X-Gene SoC CRC32C HW accelerator driver");
>> +MODULE_AUTHOR("Rameshwar Prasad Sahu ");
>> +MODULE_LICENSE("GPL");
>> +MODULE_VERSION("1.0");
>
> You should add a MODULE_ALIAS_CRYPTO too.
Okay
>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver

[Rameshwar Sahu]

On Fri, Jul 31, 2015 at 12:43 PM, Herbert Xu
herb...@gondor.apana.org.au wrote:
 On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:

 + .cra_name   = xgene(crc32c),
 + .cra_driver_name= crc32c-xgene,

 This looks wrong.  If you're implementing crc32c then cra_name
 should be just crc32c, i.e., the name of the algorithm that you
 are providing.

Okay, I will change it to crc32c only.

 +MODULE_DESCRIPTION(APM X-Gene SoC CRC32C HW accelerator driver);
 +MODULE_AUTHOR(Rameshwar Prasad Sahu rs...@apm.com);
 +MODULE_LICENSE(GPL);
 +MODULE_VERSION(1.0);

 You should add a MODULE_ALIAS_CRYPTO too.
Okay

 Cheers,
 --
 Email: Herbert Xu herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
 --
 To unsubscribe from this list: send the line unsubscribe dmaengine in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v1 0/4] Crypto: tcrypt: Add test case for APM X-Gene SoC CRC32C algo

[Rameshwar Sahu]

Hi All,

On Thu, Jul 30, 2015 at 5:41 PM, Rameshwar Prasad Sahu  wrote:
> This patch adds test case for APM X-Gene SoC CRC32C algorithm.

Please discard this patch description and subject line in this cover
letter, I have resent it again.

Thanks,
Ram

>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>
> Rameshwar Prasad Sahu (4):
>   dmaengine: Add support for new feature CRC32C
>   dmaengine: xgene-dma: Add support for CRC32C calculation via DMA
> engine
>   Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
>   Crypto: tcrypt: Add test case for APM X-Gene SoC CRC32C algo
>
>  crypto/tcrypt.c   |   4 +
>  crypto/testmgr.c  |   9 ++
>  drivers/crypto/Kconfig|   8 ++
>  drivers/crypto/Makefile   |   1 +
>  drivers/crypto/xgene-crc32c.c | 244 
>  drivers/dma/dmaengine.c   |   2 +
>  drivers/dma/xgene-dma.c   | 317 
> --
>  include/linux/dmaengine.h |   5 +
>  8 files changed, 575 insertions(+), 15 deletions(-)
>  create mode 100755 drivers/crypto/xgene-crc32c.c
>
> --
> 1.8.2.1
--
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] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver

[Rameshwar Sahu]

Hi Arnd,

On Wed, Jul 29, 2015 at 8:04 PM, Arnd Bergmann  wrote:
> On Tuesday 21 July 2015 18:44:39 Rameshwar Prasad Sahu wrote:
>> This patch adds ACPI support for the APM X-Gene DMA engine driver.
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>>
>
> How does a slave driver refer to a channel in case of ACPI?

We don't support slave dma here. This driver supports only memcp, xor,
pq, scatter-gather offloading, so,
client driver can use linux dmaengine APIs like dma_request_channel()
etc to request channel.


>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v1 0/4] Crypto: tcrypt: Add test case for APM X-Gene SoC CRC32C algo

[Rameshwar Sahu]

Hi All,

On Thu, Jul 30, 2015 at 5:41 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch adds test case for APM X-Gene SoC CRC32C algorithm.

Please discard this patch description and subject line in this cover
letter, I have resent it again.

Thanks,
Ram


 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 ---

 Rameshwar Prasad Sahu (4):
   dmaengine: Add support for new feature CRC32C
   dmaengine: xgene-dma: Add support for CRC32C calculation via DMA
 engine
   Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
   Crypto: tcrypt: Add test case for APM X-Gene SoC CRC32C algo

  crypto/tcrypt.c   |   4 +
  crypto/testmgr.c  |   9 ++
  drivers/crypto/Kconfig|   8 ++
  drivers/crypto/Makefile   |   1 +
  drivers/crypto/xgene-crc32c.c | 244 
  drivers/dma/dmaengine.c   |   2 +
  drivers/dma/xgene-dma.c   | 317 
 --
  include/linux/dmaengine.h |   5 +
  8 files changed, 575 insertions(+), 15 deletions(-)
  create mode 100755 drivers/crypto/xgene-crc32c.c

 --
 1.8.2.1
--
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] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver

[Rameshwar Sahu]

Hi Arnd,

On Wed, Jul 29, 2015 at 8:04 PM, Arnd Bergmann a...@arndb.de wrote:
 On Tuesday 21 July 2015 18:44:39 Rameshwar Prasad Sahu wrote:
 This patch adds ACPI support for the APM X-Gene DMA engine driver.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com


 How does a slave driver refer to a channel in case of ACPI?

We don't support slave dma here. This driver supports only memcp, xor,
pq, scatter-gather offloading, so,
client driver can use linux dmaengine APIs like dma_request_channel()
etc to request channel.



 Arnd
 --
 To unsubscribe from this list: send the line unsubscribe dmaengine in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Tue, Jul 21, 2015 at 6:44 PM, Rameshwar Prasad Sahu  wrote:
> This patch adds ACPI support for the APM X-Gene DMA engine driver.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/dma/xgene-dma.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index dff22ab..d0a148d 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -21,6 +21,7 @@
>   * NOTE: PM support is currently not available.
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1944,16 +1945,18 @@ static int xgene_dma_probe(struct platform_device 
> *pdev)
> return ret;
>
> pdma->clk = devm_clk_get(>dev, NULL);
> -   if (IS_ERR(pdma->clk)) {
> +   if (IS_ERR(pdma->clk) && !ACPI_COMPANION(>dev)) {
> dev_err(>dev, "Failed to get clk\n");
> return PTR_ERR(pdma->clk);
> }
>
> /* Enable clk before accessing registers */
> -   ret = clk_prepare_enable(pdma->clk);
> -   if (ret) {
> -   dev_err(>dev, "Failed to enable clk %d\n", ret);
> -   return ret;
> +   if (!IS_ERR(pdma->clk)) {
> +   ret = clk_prepare_enable(pdma->clk);
> +   if (ret) {
> +   dev_err(>dev, "Failed to enable clk %d\n", ret);
> +   return ret;
> +   }
> }
>
> /* Remove DMA RAM out of shutdown */
> @@ -1998,7 +2001,8 @@ err_request_irq:
>
>  err_dma_mask:
>  err_clk_enable:
> -   clk_disable_unprepare(pdma->clk);
> +   if (!IS_ERR(pdma->clk))
> +   clk_disable_unprepare(pdma->clk);
>
> return ret;
>  }
> @@ -2022,11 +2026,20 @@ static int xgene_dma_remove(struct platform_device 
> *pdev)
> xgene_dma_delete_chan_rings(chan);
> }
>
> -   clk_disable_unprepare(pdma->clk);
> +   if (!IS_ERR(pdma->clk))
> +   clk_disable_unprepare(pdma->clk);
>
> return 0;
>  }
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id xgene_dma_acpi_match_ptr[] = {
> +   {"APMC0D43", 0},
> +   {},
> +};
> +MODULE_DEVICE_TABLE(acpi, xgene_dma_acpi_match_ptr);
> +#endif
> +
>  static const struct of_device_id xgene_dma_of_match_ptr[] = {
> {.compatible = "apm,xgene-storm-dma",},
> {},
> @@ -2039,6 +2052,7 @@ static struct platform_driver xgene_dma_driver = {
> .driver = {
> .name = "X-Gene-DMA",
> .of_match_table = xgene_dma_of_match_ptr,
> +   .acpi_match_table = ACPI_PTR(xgene_dma_acpi_match_ptr),
> },
>  };
>
> --
> 1.8.2.1

Any comment here ??
--
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] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Tue, Jul 21, 2015 at 6:44 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch adds ACPI support for the APM X-Gene DMA engine driver.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 ---
  drivers/dma/xgene-dma.c | 28 +---
  1 file changed, 21 insertions(+), 7 deletions(-)

 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 index dff22ab..d0a148d 100644
 --- a/drivers/dma/xgene-dma.c
 +++ b/drivers/dma/xgene-dma.c
 @@ -21,6 +21,7 @@
   * NOTE: PM support is currently not available.
   */

 +#include linux/acpi.h
  #include linux/clk.h
  #include linux/delay.h
  #include linux/dma-mapping.h
 @@ -1944,16 +1945,18 @@ static int xgene_dma_probe(struct platform_device 
 *pdev)
 return ret;

 pdma-clk = devm_clk_get(pdev-dev, NULL);
 -   if (IS_ERR(pdma-clk)) {
 +   if (IS_ERR(pdma-clk)  !ACPI_COMPANION(pdev-dev)) {
 dev_err(pdev-dev, Failed to get clk\n);
 return PTR_ERR(pdma-clk);
 }

 /* Enable clk before accessing registers */
 -   ret = clk_prepare_enable(pdma-clk);
 -   if (ret) {
 -   dev_err(pdev-dev, Failed to enable clk %d\n, ret);
 -   return ret;
 +   if (!IS_ERR(pdma-clk)) {
 +   ret = clk_prepare_enable(pdma-clk);
 +   if (ret) {
 +   dev_err(pdev-dev, Failed to enable clk %d\n, ret);
 +   return ret;
 +   }
 }

 /* Remove DMA RAM out of shutdown */
 @@ -1998,7 +2001,8 @@ err_request_irq:

  err_dma_mask:
  err_clk_enable:
 -   clk_disable_unprepare(pdma-clk);
 +   if (!IS_ERR(pdma-clk))
 +   clk_disable_unprepare(pdma-clk);

 return ret;
  }
 @@ -2022,11 +2026,20 @@ static int xgene_dma_remove(struct platform_device 
 *pdev)
 xgene_dma_delete_chan_rings(chan);
 }

 -   clk_disable_unprepare(pdma-clk);
 +   if (!IS_ERR(pdma-clk))
 +   clk_disable_unprepare(pdma-clk);

 return 0;
  }

 +#ifdef CONFIG_ACPI
 +static const struct acpi_device_id xgene_dma_acpi_match_ptr[] = {
 +   {APMC0D43, 0},
 +   {},
 +};
 +MODULE_DEVICE_TABLE(acpi, xgene_dma_acpi_match_ptr);
 +#endif
 +
  static const struct of_device_id xgene_dma_of_match_ptr[] = {
 {.compatible = apm,xgene-storm-dma,},
 {},
 @@ -2039,6 +2052,7 @@ static struct platform_driver xgene_dma_driver = {
 .driver = {
 .name = X-Gene-DMA,
 .of_match_table = xgene_dma_of_match_ptr,
 +   .acpi_match_table = ACPI_PTR(xgene_dma_acpi_match_ptr),
 },
  };

 --
 1.8.2.1

Any comment here ??
--
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] dmaengine: xgene-dma: Fix the resource map to handle overlapping

[Rameshwar Sahu]

Hi Vinod,

On Tue, Jul 7, 2015 at 3:34 PM, Rameshwar Prasad Sahu  wrote:
> There is an overlap in dma ring cmd csr region due to sharing of ethernet
> ring cmd csr region. This patch fix the resource overlapping by mapping
> the entire dma ring cmd csr region.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  Documentation/devicetree/bindings/dma/apm-xgene-dma.txt | 2 +-
>  arch/arm64/boot/dts/apm/apm-storm.dtsi  | 2 +-
>  drivers/dma/xgene-dma.c | 3 +++
>  3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt 
> b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
> index d305876..c53e0b0 100644
> --- a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
> @@ -35,7 +35,7 @@ Example:
> device_type = "dma";
> reg = <0x0 0x1f27 0x0 0x1>,
>   <0x0 0x1f20 0x0 0x1>,
> - <0x0 0x1b008000 0x0 0x2000>,
> + <0x0 0x1b00 0x0 0x40>,
>   <0x0 0x1054a000 0x0 0x100>;
> interrupts = <0x0 0x82 0x4>,
>  <0x0 0xb8 0x4>,
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
> b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index 0689c3f..58093ed 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -823,7 +823,7 @@
> device_type = "dma";
> reg = <0x0 0x1f27 0x0 0x1>,
>   <0x0 0x1f20 0x0 0x1>,
> - <0x0 0x1b008000 0x0 0x2000>,
> + <0x0 0x1b00 0x0 0x40>,
>   <0x0 0x1054a000 0x0 0x100>;
> interrupts = <0x0 0x82 0x4>,
>  <0x0 0xb8 0x4>,
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index 620fd55ec..dff22ab 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -111,6 +111,7 @@
>  #define XGENE_DMA_MEM_RAM_SHUTDOWN 0xD070
>  #define XGENE_DMA_BLK_MEM_RDY  0xD074
>  #define XGENE_DMA_BLK_MEM_RDY_VAL  0x
> +#define XGENE_DMA_RING_CMD_SM_OFFSET   0x8000
>
>  /* X-Gene SoC EFUSE csr register and bit defination */
>  #define XGENE_SOC_JTAG1_SHADOW 0x18
> @@ -1887,6 +1888,8 @@ static int xgene_dma_get_resources(struct 
> platform_device *pdev,
> return -ENOMEM;
> }
>
> +   pdma->csr_ring_cmd += XGENE_DMA_RING_CMD_SM_OFFSET;
> +
> /* Get efuse csr region */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
> if (!res) {
> --
> 1.8.2.1
>

Any comments on above patch ?
--
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] dmaengine: xgene-dma: Fix the resource map to handle overlapping

[Rameshwar Sahu]

Hi Vinod,

On Tue, Jul 7, 2015 at 3:34 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 There is an overlap in dma ring cmd csr region due to sharing of ethernet
 ring cmd csr region. This patch fix the resource overlapping by mapping
 the entire dma ring cmd csr region.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 ---
  Documentation/devicetree/bindings/dma/apm-xgene-dma.txt | 2 +-
  arch/arm64/boot/dts/apm/apm-storm.dtsi  | 2 +-
  drivers/dma/xgene-dma.c | 3 +++
  3 files changed, 5 insertions(+), 2 deletions(-)

 diff --git a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt 
 b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
 index d305876..c53e0b0 100644
 --- a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
 +++ b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
 @@ -35,7 +35,7 @@ Example:
 device_type = dma;
 reg = 0x0 0x1f27 0x0 0x1,
   0x0 0x1f20 0x0 0x1,
 - 0x0 0x1b008000 0x0 0x2000,
 + 0x0 0x1b00 0x0 0x40,
   0x0 0x1054a000 0x0 0x100;
 interrupts = 0x0 0x82 0x4,
  0x0 0xb8 0x4,
 diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
 b/arch/arm64/boot/dts/apm/apm-storm.dtsi
 index 0689c3f..58093ed 100644
 --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
 +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
 @@ -823,7 +823,7 @@
 device_type = dma;
 reg = 0x0 0x1f27 0x0 0x1,
   0x0 0x1f20 0x0 0x1,
 - 0x0 0x1b008000 0x0 0x2000,
 + 0x0 0x1b00 0x0 0x40,
   0x0 0x1054a000 0x0 0x100;
 interrupts = 0x0 0x82 0x4,
  0x0 0xb8 0x4,
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 index 620fd55ec..dff22ab 100644
 --- a/drivers/dma/xgene-dma.c
 +++ b/drivers/dma/xgene-dma.c
 @@ -111,6 +111,7 @@
  #define XGENE_DMA_MEM_RAM_SHUTDOWN 0xD070
  #define XGENE_DMA_BLK_MEM_RDY  0xD074
  #define XGENE_DMA_BLK_MEM_RDY_VAL  0x
 +#define XGENE_DMA_RING_CMD_SM_OFFSET   0x8000

  /* X-Gene SoC EFUSE csr register and bit defination */
  #define XGENE_SOC_JTAG1_SHADOW 0x18
 @@ -1887,6 +1888,8 @@ static int xgene_dma_get_resources(struct 
 platform_device *pdev,
 return -ENOMEM;
 }

 +   pdma-csr_ring_cmd += XGENE_DMA_RING_CMD_SM_OFFSET;
 +
 /* Get efuse csr region */
 res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
 if (!res) {
 --
 1.8.2.1


Any comments on above patch ?
--
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] dmaengine: xgene-dma: Fix "incorrect type in assignement" warnings

[Rameshwar Sahu]

On Tue, Jun 2, 2015 at 7:05 PM, Vinod Koul  wrote:
>
> On Tue, Jun 02, 2015 at 02:33:33PM +0530, Rameshwar Prasad Sahu wrote:
> > This patch fixes sparse warnings like incorrect type in assignment
> > (different base types), cast to restricted __le64.
> >
> I am appliying this but ideally you should have split thsi into seprate
> patches for each fix



Thanks, I will take care this for next time.
Ram
>
>
> --
> ~Vinod
>
--
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] dmaengine: xgene-dma: Fix incorrect type in assignement warnings

[Rameshwar Sahu]

On Tue, Jun 2, 2015 at 7:05 PM, Vinod Koul vinod.k...@intel.com wrote:

 On Tue, Jun 02, 2015 at 02:33:33PM +0530, Rameshwar Prasad Sahu wrote:
  This patch fixes sparse warnings like incorrect type in assignment
  (different base types), cast to restricted __le64.
 
 I am appliying this but ideally you should have split thsi into seprate
 patches for each fix



Thanks, I will take care this for next time.
Ram


 --
 ~Vinod

--
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 v4] dmaengine: xgene-dma: Fix sparse wannings and coccinelle warnings

[Rameshwar Sahu]

On Mon, Apr 20, 2015 at 4:23 PM, Rameshwar Prasad Sahu  wrote:
> v4 changes:
> * Re-generate patch on top of latest for-linux git
>
> v3 changes:
> * Minor changes in length setting in DMA descriptor
>
> v2 changes:
> * Code cleanup
> * Changed way of setting DMA descriptors for big-endian
>
> This patch fixes compilation sparse warnings like incorrect type in assignment
> (different base types), cast to restricted __le64, symbol
> '__UNIQUE_ID_author__COUNTER__' has multiple initializers etc and
> coccinelle warnings (No need to set .owner here. The core will do it.)
>
> This patch is based on slave-dma / for-linus branch.
> (commit: 9f2fd0dfa594d857fbdaeda523ff7a46f16567f5 [26/28]
> dmaengine: Add support for APM X-Gene SoC DMA engine driver)
>
> Reported-by: kbuild test robot 
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/dma/xgene-dma.c | 161 
> ++--
>  1 file changed, 61 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index f52e3750..063c835 100755
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -127,29 +127,6 @@
>  #define XGENE_DMA_DESC_FLYBY_POS   4
>  #define XGENE_DMA_DESC_BUFLEN_POS  48
>  #define XGENE_DMA_DESC_HOENQ_NUM_POS   48
> -
> -#define XGENE_DMA_DESC_NV_SET(m)   \
> -   (((u64 *)(m))[0] |= XGENE_DMA_DESC_NV_BIT)
> -#define XGENE_DMA_DESC_IN_SET(m)   \
> -   (((u64 *)(m))[0] |= XGENE_DMA_DESC_IN_BIT)
> -#define XGENE_DMA_DESC_RTYPE_SET(m, v) \
> -   (((u64 *)(m))[0] |= ((u64)(v) << XGENE_DMA_DESC_RTYPE_POS))
> -#define XGENE_DMA_DESC_BUFADDR_SET(m, v)   \
> -   (((u64 *)(m))[0] |= (v))
> -#define XGENE_DMA_DESC_BUFLEN_SET(m, v)\
> -   (((u64 *)(m))[0] |= ((u64)(v) << XGENE_DMA_DESC_BUFLEN_POS))
> -#define XGENE_DMA_DESC_C_SET(m)\
> -   (((u64 *)(m))[1] |= XGENE_DMA_DESC_C_BIT)
> -#define XGENE_DMA_DESC_FLYBY_SET(m, v) \
> -   (((u64 *)(m))[2] |= ((v) << XGENE_DMA_DESC_FLYBY_POS))
> -#define XGENE_DMA_DESC_MULTI_SET(m, v, i)  \
> -   (((u64 *)(m))[2] |= ((u64)(v) << (((i) + 1) * 8)))
> -#define XGENE_DMA_DESC_DR_SET(m)   \
> -   (((u64 *)(m))[2] |= XGENE_DMA_DESC_DR_BIT)
> -#define XGENE_DMA_DESC_DST_ADDR_SET(m, v)  \
> -   (((u64 *)(m))[3] |= (v))
> -#define XGENE_DMA_DESC_H0ENQ_NUM_SET(m, v) \
> -   (((u64 *)(m))[3] |= ((u64)(v) << XGENE_DMA_DESC_HOENQ_NUM_POS))
>  #define XGENE_DMA_DESC_ELERR_RD(m) \
> (((m) >> XGENE_DMA_DESC_ELERR_POS) & 0x3)
>  #define XGENE_DMA_DESC_LERR_RD(m)  \
> @@ -158,14 +135,7 @@
> (((elerr) << 4) | (lerr))
>
>  /* X-Gene DMA descriptor empty s/w signature */
> -#define XGENE_DMA_DESC_EMPTY_INDEX 0
>  #define XGENE_DMA_DESC_EMPTY_SIGNATURE ~0ULL
> -#define XGENE_DMA_DESC_SET_EMPTY(m)\
> -   (((u64 *)(m))[XGENE_DMA_DESC_EMPTY_INDEX] = \
> -XGENE_DMA_DESC_EMPTY_SIGNATURE)
> -#define XGENE_DMA_DESC_IS_EMPTY(m) \
> -   (((u64 *)(m))[XGENE_DMA_DESC_EMPTY_INDEX] ==\
> -XGENE_DMA_DESC_EMPTY_SIGNATURE)
>
>  /* X-Gene DMA configurable parameters defines */
>  #define XGENE_DMA_RING_NUM 512
> @@ -238,10 +208,10 @@
> dev_err(chan->dev, "%s: " fmt, chan->name, ##arg)
>
>  struct xgene_dma_desc_hw {
> -   u64 m0;
> -   u64 m1;
> -   u64 m2;
> -   u64 m3;
> +   __le64 m0;
> +   __le64 m1;
> +   __le64 m2;
> +   __le64 m3;
>  };
>
>  enum xgene_dma_ring_cfgsize {
> @@ -388,14 +358,6 @@ static bool is_pq_enabled(struct xgene_dma *pdma)
> return !(val & XGENE_DMA_PQ_DISABLE_MASK);
>  }
>
> -static void xgene_dma_cpu_to_le64(u64 *desc, int count)
> -{
> -   int i;
> -
> -   for (i = 0; i < count; i++)
> -   desc[i] = cpu_to_le64(desc[i]);
> -}
> -
>  static u16 xgene_dma_encode_len(u32 len)
>  {
> return (len < XGENE_DMA_MAX_BYTE_CNT) ?
> @@ -424,34 +386,52 @@ static u32 xgene_dma_ring_desc_cnt(struct 
> xgene_dma_ring *ring)
> return XGENE_DMA_RING_DESC_CNT(ring_state);
>  }
>
> -static void xgene_dma_set_src_buffer(void *ext8, size_t *len,
> +static void xgene_dma_set_src_buffer(__le64 *ext8, size_t *len,
>  dma_addr_t *paddr)
>  {
> size_t nbytes = (*len < XGENE_DMA_MAX_BYTE_CNT) ?
> *len : XGENE_DMA_MAX_BYTE_CNT;
>
> -   XGENE_DMA_DESC_BUFADDR_SET(ext8, *paddr);
> -   XGENE_DMA_DESC_BUFLEN_SET(ext8, xgene_dma_encode_len(nbytes));
> +   *ext8 |= cpu_to_le64(*paddr);
> +   *ext8 |= cpu_to_le64((u64)xgene_dma_encode_len(nbytes) <<
> +XGENE_DMA_DESC_BUFLEN_POS);
> *len -= nbytes;
> *paddr += nbytes;
>  }
>
> -static void xgene_dma_invalidate_buffer(void *ext8)
> +static void 

Re: [PATCH v4] dmaengine: xgene-dma: Fix sparse wannings and coccinelle warnings

[Rameshwar Sahu]

On Mon, Apr 20, 2015 at 4:23 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 v4 changes:
 * Re-generate patch on top of latest for-linux git

 v3 changes:
 * Minor changes in length setting in DMA descriptor

 v2 changes:
 * Code cleanup
 * Changed way of setting DMA descriptors for big-endian

 This patch fixes compilation sparse warnings like incorrect type in assignment
 (different base types), cast to restricted __le64, symbol
 '__UNIQUE_ID_author__COUNTER__' has multiple initializers etc and
 coccinelle warnings (No need to set .owner here. The core will do it.)

 This patch is based on slave-dma / for-linus branch.
 (commit: 9f2fd0dfa594d857fbdaeda523ff7a46f16567f5 [26/28]
 dmaengine: Add support for APM X-Gene SoC DMA engine driver)

 Reported-by: kbuild test robot fengguang...@intel.com
 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 ---
  drivers/dma/xgene-dma.c | 161 
 ++--
  1 file changed, 61 insertions(+), 100 deletions(-)

 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 index f52e3750..063c835 100755
 --- a/drivers/dma/xgene-dma.c
 +++ b/drivers/dma/xgene-dma.c
 @@ -127,29 +127,6 @@
  #define XGENE_DMA_DESC_FLYBY_POS   4
  #define XGENE_DMA_DESC_BUFLEN_POS  48
  #define XGENE_DMA_DESC_HOENQ_NUM_POS   48
 -
 -#define XGENE_DMA_DESC_NV_SET(m)   \
 -   (((u64 *)(m))[0] |= XGENE_DMA_DESC_NV_BIT)
 -#define XGENE_DMA_DESC_IN_SET(m)   \
 -   (((u64 *)(m))[0] |= XGENE_DMA_DESC_IN_BIT)
 -#define XGENE_DMA_DESC_RTYPE_SET(m, v) \
 -   (((u64 *)(m))[0] |= ((u64)(v)  XGENE_DMA_DESC_RTYPE_POS))
 -#define XGENE_DMA_DESC_BUFADDR_SET(m, v)   \
 -   (((u64 *)(m))[0] |= (v))
 -#define XGENE_DMA_DESC_BUFLEN_SET(m, v)\
 -   (((u64 *)(m))[0] |= ((u64)(v)  XGENE_DMA_DESC_BUFLEN_POS))
 -#define XGENE_DMA_DESC_C_SET(m)\
 -   (((u64 *)(m))[1] |= XGENE_DMA_DESC_C_BIT)
 -#define XGENE_DMA_DESC_FLYBY_SET(m, v) \
 -   (((u64 *)(m))[2] |= ((v)  XGENE_DMA_DESC_FLYBY_POS))
 -#define XGENE_DMA_DESC_MULTI_SET(m, v, i)  \
 -   (((u64 *)(m))[2] |= ((u64)(v)  (((i) + 1) * 8)))
 -#define XGENE_DMA_DESC_DR_SET(m)   \
 -   (((u64 *)(m))[2] |= XGENE_DMA_DESC_DR_BIT)
 -#define XGENE_DMA_DESC_DST_ADDR_SET(m, v)  \
 -   (((u64 *)(m))[3] |= (v))
 -#define XGENE_DMA_DESC_H0ENQ_NUM_SET(m, v) \
 -   (((u64 *)(m))[3] |= ((u64)(v)  XGENE_DMA_DESC_HOENQ_NUM_POS))
  #define XGENE_DMA_DESC_ELERR_RD(m) \
 (((m)  XGENE_DMA_DESC_ELERR_POS)  0x3)
  #define XGENE_DMA_DESC_LERR_RD(m)  \
 @@ -158,14 +135,7 @@
 (((elerr)  4) | (lerr))

  /* X-Gene DMA descriptor empty s/w signature */
 -#define XGENE_DMA_DESC_EMPTY_INDEX 0
  #define XGENE_DMA_DESC_EMPTY_SIGNATURE ~0ULL
 -#define XGENE_DMA_DESC_SET_EMPTY(m)\
 -   (((u64 *)(m))[XGENE_DMA_DESC_EMPTY_INDEX] = \
 -XGENE_DMA_DESC_EMPTY_SIGNATURE)
 -#define XGENE_DMA_DESC_IS_EMPTY(m) \
 -   (((u64 *)(m))[XGENE_DMA_DESC_EMPTY_INDEX] ==\
 -XGENE_DMA_DESC_EMPTY_SIGNATURE)

  /* X-Gene DMA configurable parameters defines */
  #define XGENE_DMA_RING_NUM 512
 @@ -238,10 +208,10 @@
 dev_err(chan-dev, %s:  fmt, chan-name, ##arg)

  struct xgene_dma_desc_hw {
 -   u64 m0;
 -   u64 m1;
 -   u64 m2;
 -   u64 m3;
 +   __le64 m0;
 +   __le64 m1;
 +   __le64 m2;
 +   __le64 m3;
  };

  enum xgene_dma_ring_cfgsize {
 @@ -388,14 +358,6 @@ static bool is_pq_enabled(struct xgene_dma *pdma)
 return !(val  XGENE_DMA_PQ_DISABLE_MASK);
  }

 -static void xgene_dma_cpu_to_le64(u64 *desc, int count)
 -{
 -   int i;
 -
 -   for (i = 0; i  count; i++)
 -   desc[i] = cpu_to_le64(desc[i]);
 -}
 -
  static u16 xgene_dma_encode_len(u32 len)
  {
 return (len  XGENE_DMA_MAX_BYTE_CNT) ?
 @@ -424,34 +386,52 @@ static u32 xgene_dma_ring_desc_cnt(struct 
 xgene_dma_ring *ring)
 return XGENE_DMA_RING_DESC_CNT(ring_state);
  }

 -static void xgene_dma_set_src_buffer(void *ext8, size_t *len,
 +static void xgene_dma_set_src_buffer(__le64 *ext8, size_t *len,
  dma_addr_t *paddr)
  {
 size_t nbytes = (*len  XGENE_DMA_MAX_BYTE_CNT) ?
 *len : XGENE_DMA_MAX_BYTE_CNT;

 -   XGENE_DMA_DESC_BUFADDR_SET(ext8, *paddr);
 -   XGENE_DMA_DESC_BUFLEN_SET(ext8, xgene_dma_encode_len(nbytes));
 +   *ext8 |= cpu_to_le64(*paddr);
 +   *ext8 |= cpu_to_le64((u64)xgene_dma_encode_len(nbytes) 
 +XGENE_DMA_DESC_BUFLEN_POS);
 *len -= nbytes;
 *paddr += nbytes;
  }

 -static void xgene_dma_invalidate_buffer(void *ext8)
 +static void xgene_dma_invalidate_buffer(__le64 *ext8)
  {
 -   XGENE_DMA_DESC_BUFLEN_SET(ext8, XGENE_DMA_INVALID_LEN_CODE);
 +   

Re: [PATCH v3] dmaengine: xgene-dma: Fix sparse wannings and coccinelle warnings

[Rameshwar Sahu]

Hi Vinod,

On Fri, Apr 17, 2015 at 11:59 PM, Vinod Koul  wrote:
>
>>   /* Get DMA error interrupt */
>> @@ -2076,7 +2035,6 @@ static struct platform_driver xgene_dma_driver = {
>>   .remove = xgene_dma_remove,
>>   .driver = {
>>   .name = "X-Gene-DMA",
>> - .owner = THIS_MODULE,
> I have already applied a patch for this

Okay, I didn't pull latest git

>
>>   .of_match_table = xgene_dma_of_match_ptr,
>>   },
>>  };
>> @@ -2085,6 +2043,5 @@ module_platform_driver(xgene_dma_driver);
>>
>>  MODULE_DESCRIPTION("APM X-Gene SoC DMA driver");
>>  MODULE_AUTHOR("Rameshwar Prasad Sahu ");
>> -MODULE_AUTHOR("Loc Ho ");
> And why this?

I saw below warning reported by the kbuild robot test

drivers/dma/xgene-dma.c:2088:1: sparse: symbol
'__UNIQUE_ID_author__COUNTER__' has multiple initializers (originally
initialized at drivers/dma/xgene-dma.c:2087)
So, I kept only one author here.


>
> Fixes looks good though
>
> --
> ~Vinod
>>  MODULE_LICENSE("GPL");
>>  MODULE_VERSION("1.0");
>> --
>> 1.8.2.1
>>
>
> --
--
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] dmaengine: xgene-dma: Fix sparse wannings and coccinelle warnings

[Rameshwar Sahu]

Hi Vinod,

On Fri, Apr 17, 2015 at 11:59 PM, Vinod Koul vinod.k...@intel.com wrote:

   /* Get DMA error interrupt */
 @@ -2076,7 +2035,6 @@ static struct platform_driver xgene_dma_driver = {
   .remove = xgene_dma_remove,
   .driver = {
   .name = X-Gene-DMA,
 - .owner = THIS_MODULE,
 I have already applied a patch for this

Okay, I didn't pull latest git


   .of_match_table = xgene_dma_of_match_ptr,
   },
  };
 @@ -2085,6 +2043,5 @@ module_platform_driver(xgene_dma_driver);

  MODULE_DESCRIPTION(APM X-Gene SoC DMA driver);
  MODULE_AUTHOR(Rameshwar Prasad Sahu rs...@apm.com);
 -MODULE_AUTHOR(Loc Ho l...@apm.com);
 And why this?

I saw below warning reported by the kbuild robot test

drivers/dma/xgene-dma.c:2088:1: sparse: symbol
'__UNIQUE_ID_author__COUNTER__' has multiple initializers (originally
initialized at drivers/dma/xgene-dma.c:2087)
So, I kept only one author here.



 Fixes looks good though

 --
 ~Vinod
  MODULE_LICENSE(GPL);
  MODULE_VERSION(1.0);
 --
 1.8.2.1


 --
--
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] dmaengine: xgene-dma: Fix sparse wannings and coccinelle warnings

[Rameshwar Sahu]

Hi Arnd,

On Fri, Apr 17, 2015 at 2:19 PM, Arnd Bergmann  wrote:
> On Friday 17 April 2015 01:01:13 Rameshwar Prasad Sahu wrote:
>> v3 changes:
>>   * Minor changes in length setting in DMA descriptor
>>
>> v2 changes:
>>   * Code cleanup
>>   * Changed way of setting DMA descriptors for big-endian
>>
>> This patch fixes compilation sparse warnings like incorrect type in 
>> assignment
>> (different base types), cast to restricted __le64, symbol
>> '__UNIQUE_ID_author__COUNTER__' has multiple initializers etc and
>> coccinelle warnings (No need to set .owner here. The core will do it.)
>>
>> This patch is based on slave-dma / for-linus branch.
>> (commit: 9f2fd0dfa594d857fbdaeda523ff7a46f16567f5 [26/28]
>>   dmaengine: Add support for APM X-Gene SoC DMA engine driver)
>>
>> Reported-by: kbuild test robot 
>> Signed-off-by: Rameshwar Prasad Sahu 
>
> Looks good now,
>
> Reviewed-by: Arnd Bergmann 
>
> There is one small enhancement that you could still do and I'll shut up after
> that ;-)
>
>>
>> -static void *xgene_dma_lookup_ext8(u64 *desc, int idx)
>> +static __le64 *xgene_dma_lookup_ext8(struct xgene_dma_desc_hw *desc, int 
>> idx)
>>  {
>> - return (idx % 2) ? (desc + idx - 1) : (desc + idx + 1);
>> + switch (idx) {
>> + case 0:
>> + return >m1;
>> + case 1:
>> + return >m0;
>> + case 2:
>> + return >m3;
>> + case 3:
>> + return >m2;
>> + default:
>> + pr_err("Invalid dma descriptor index\n");
>> + }
>> +
>> + return NULL;
>>  }
>>
> ...
>
>>   /* Set 1st to 5th source addresses */
>>   for (i = 0; i < src_cnt; i++) {
>>   len = *nbytes;
>> - xgene_dma_set_src_buffer((i == 0) ? (desc1 + 8) :
>> + xgene_dma_set_src_buffer((i == 0) ? >m1 :
>>xgene_dma_lookup_ext8(desc2, i - 1),
>>, [i]);
>> - XGENE_DMA_DESC_MULTI_SET(desc1, scf[i], i);
>> + desc1->m2 |= cpu_to_le64((scf[i] << ((i + 1) * 8)));
>>   }
>
> If you just unroll this loop, you get code that is smaller and easier to
> understand:
>
> /* Set 1st to 5th source addresses */
> xgene_dma_set_src_buffer(>m1, , [0]);
> xgene_dma_set_src_buffer(>m0, , [1]);
> xgene_dma_set_src_buffer(>m3, , [2]);
> xgene_dma_set_src_buffer(>m2, , [3]);
> desc1->m2 |= cpu_to_le64(scf[0] | scf[1] << 8 | scf[2] << 16 | scf[3] 
> << 24);

Actually here, in run time src_cnt value can be 2 or 3 upto 5, so we
can't unroll it.


>
> 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] dmaengine: xgene-dma: Fix sparse wannings and coccinelle warnings

[Rameshwar Sahu]

Hi Arnd,

On Fri, Apr 17, 2015 at 2:19 PM, Arnd Bergmann a...@arndb.de wrote:
 On Friday 17 April 2015 01:01:13 Rameshwar Prasad Sahu wrote:
 v3 changes:
   * Minor changes in length setting in DMA descriptor

 v2 changes:
   * Code cleanup
   * Changed way of setting DMA descriptors for big-endian

 This patch fixes compilation sparse warnings like incorrect type in 
 assignment
 (different base types), cast to restricted __le64, symbol
 '__UNIQUE_ID_author__COUNTER__' has multiple initializers etc and
 coccinelle warnings (No need to set .owner here. The core will do it.)

 This patch is based on slave-dma / for-linus branch.
 (commit: 9f2fd0dfa594d857fbdaeda523ff7a46f16567f5 [26/28]
   dmaengine: Add support for APM X-Gene SoC DMA engine driver)

 Reported-by: kbuild test robot fengguang...@intel.com
 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com

 Looks good now,

 Reviewed-by: Arnd Bergmann a...@arndb.de

 There is one small enhancement that you could still do and I'll shut up after
 that ;-)


 -static void *xgene_dma_lookup_ext8(u64 *desc, int idx)
 +static __le64 *xgene_dma_lookup_ext8(struct xgene_dma_desc_hw *desc, int 
 idx)
  {
 - return (idx % 2) ? (desc + idx - 1) : (desc + idx + 1);
 + switch (idx) {
 + case 0:
 + return desc-m1;
 + case 1:
 + return desc-m0;
 + case 2:
 + return desc-m3;
 + case 3:
 + return desc-m2;
 + default:
 + pr_err(Invalid dma descriptor index\n);
 + }
 +
 + return NULL;
  }

 ...

   /* Set 1st to 5th source addresses */
   for (i = 0; i  src_cnt; i++) {
   len = *nbytes;
 - xgene_dma_set_src_buffer((i == 0) ? (desc1 + 8) :
 + xgene_dma_set_src_buffer((i == 0) ? desc1-m1 :
xgene_dma_lookup_ext8(desc2, i - 1),
len, src[i]);
 - XGENE_DMA_DESC_MULTI_SET(desc1, scf[i], i);
 + desc1-m2 |= cpu_to_le64((scf[i]  ((i + 1) * 8)));
   }

 If you just unroll this loop, you get code that is smaller and easier to
 understand:

 /* Set 1st to 5th source addresses */
 xgene_dma_set_src_buffer(desc1-m1, len, src[0]);
 xgene_dma_set_src_buffer(desc2-m0, len, src[1]);
 xgene_dma_set_src_buffer(desc2-m3, len, src[2]);
 xgene_dma_set_src_buffer(desc2-m2, len, src[3]);
 desc1-m2 |= cpu_to_le64(scf[0] | scf[1]  8 | scf[2]  16 | scf[3] 
  24);

Actually here, in run time src_cnt value can be 2 or 3 upto 5, so we
can't unroll it.



 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 v8 0/3] dmaengine: APM X-Gene SoC DMA engine driver support

[Rameshwar Sahu]

On Thu, Apr 2, 2015 at 2:05 PM, Vinod Koul  wrote:
> On Wed, Mar 18, 2015 at 07:17:33PM +0530, Rameshwar Prasad Sahu wrote:
>> This patch set implements the APM X-Gene SoC DMA driver support to offload
>> the DMA operations such as memory copy(memcpy), scatter gather memory copy,
>> raid5 xor and raid6 p+q.
> Applied, now

Thank you very much Vinod.

---
~Ram

>
> Thanks
> --
> ~Vinod
--
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 v8 0/3] dmaengine: APM X-Gene SoC DMA engine driver support

[Rameshwar Sahu]

On Thu, Apr 2, 2015 at 2:05 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Wed, Mar 18, 2015 at 07:17:33PM +0530, Rameshwar Prasad Sahu wrote:
 This patch set implements the APM X-Gene SoC DMA driver support to offload
 the DMA operations such as memory copy(memcpy), scatter gather memory copy,
 raid5 xor and raid6 p+q.
 Applied, now

Thank you very much Vinod.

---
~Ram


 Thanks
 --
 ~Vinod
--
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 v8 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 23, 2015 at 4:37 PM, Rameshwar Sahu  wrote:
> Hi Vinod,
>
> On Thu, Mar 19, 2015 at 1:47 PM, Rameshwar Sahu  wrote:
>> Hi Vinod,
>>
>> On Wed, Mar 18, 2015 at 7:17 PM, Rameshwar Prasad Sahu  wrote:
>>> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
>>> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
>>> These DMA operations include memory copy, scatter-gather memory copy,
>>> raid5 xor, and raid6 p+q offloading.
>>>
>>> Signed-off-by: Rameshwar Prasad Sahu 
>>> Signed-off-by: Loc Ho 
>>> ---
>>>  drivers/dma/Kconfig |8 +
>>>  drivers/dma/Makefile|1 +
>>>  drivers/dma/xgene-dma.c | 2090 
>>> +++
>>>  3 files changed, 2099 insertions(+)
>>>  create mode 100755 drivers/dma/xgene-dma.c
>>>
>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>> index a874b6e..a271346 100644
>>> --- a/drivers/dma/Kconfig
>>> +++ b/drivers/dma/Kconfig
>>> @@ -425,6 +425,14 @@ config IMG_MDC_DMA
>>> help
>>>   Enable support for the IMG multi-threaded DMA controller (MDC).
>>>
>>> +config XGENE_DMA
>>> +   tristate "APM X-Gene DMA support"
>>> +   select DMA_ENGINE
>>> +   select DMA_ENGINE_RAID
>>> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>> +   help
>>> + Enable support for the APM X-Gene SoC DMA engine.
>>> +
>>>  config DMA_ENGINE
>>> bool
>>>
>>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>>> index f915f61..06c1576 100644
>>> --- a/drivers/dma/Makefile
>>> +++ b/drivers/dma/Makefile
>>> @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>>>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>>>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>>>  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
>>> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
>>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>>> new file mode 100755
>>> index 000..2383528
>>> --- /dev/null
>>> +++ b/drivers/dma/xgene-dma.c
>>> @@ -0,0 +1,2090 @@
>>> +/*
>>> + * Applied Micro X-Gene SoC DMA engine Driver
>>> + *
>>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>>> + * Authors: Rameshwar Prasad Sahu 
>>> + * Loc Ho 
>>> + *
>>> + * 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;  either version 2 of the  License, or (at your
>>> + * option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>> + *
>>> + * NOTE: PM support is currently not available.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include "dmaengine.h"
>>> +
>>> +/* X-Gene DMA ring csr registers and bit definations */
>>> +#define XGENE_DMA_RING_CONFIG  0x04
>>> +#define XGENE_DMA_RING_ENABLE  BIT(31)
>>> +#define XGENE_DMA_RING_ID  0x08
>>> +#define XGENE_DMA_RING_ID_SETUP(v) ((v) | BIT(31))
>>> +#define XGENE_DMA_RING_ID_BUF  0x0C
>>> +#define XGENE_DMA_RING_ID_BUF_SETUP(v) (((v) << 9) | BIT(21))
>>> +#define XGENE_DMA_RING_THRESLD0_SET1   0x30
>>> +#define XGENE_DMA_RING_THRESLD0_SET1_VAL   0X64
>>> +#define XGENE_DMA_RING_THRESLD1_SET1   0x34
>>> +#define XGENE_DMA_RING_THRESLD1_SET1_VAL   0xC8
>>> +#define XGENE_DMA_RING_HYSTERESIS  0x68
>>> +#define XGENE_DMA_RING_HYSTERESIS_VAL  0x
>>> +#define XGENE_DMA_RING_STATE 

Re: [PATCH v8 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 23, 2015 at 4:37 PM, Rameshwar Sahu rs...@apm.com wrote:
 Hi Vinod,

 On Thu, Mar 19, 2015 at 1:47 PM, Rameshwar Sahu rs...@apm.com wrote:
 Hi Vinod,

 On Wed, Mar 18, 2015 at 7:17 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy, scatter-gather memory copy,
 raid5 xor, and raid6 p+q offloading.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---
  drivers/dma/Kconfig |8 +
  drivers/dma/Makefile|1 +
  drivers/dma/xgene-dma.c | 2090 
 +++
  3 files changed, 2099 insertions(+)
  create mode 100755 drivers/dma/xgene-dma.c

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index a874b6e..a271346 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -425,6 +425,14 @@ config IMG_MDC_DMA
 help
   Enable support for the IMG multi-threaded DMA controller (MDC).

 +config XGENE_DMA
 +   tristate APM X-Gene DMA support
 +   select DMA_ENGINE
 +   select DMA_ENGINE_RAID
 +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
 +   help
 + Enable support for the APM X-Gene SoC DMA engine.
 +
  config DMA_ENGINE
 bool

 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index f915f61..06c1576 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
 +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 new file mode 100755
 index 000..2383528
 --- /dev/null
 +++ b/drivers/dma/xgene-dma.c
 @@ -0,0 +1,2090 @@
 +/*
 + * Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2015, Applied Micro Circuits Corporation
 + * Authors: Rameshwar Prasad Sahu rs...@apm.com
 + * Loc Ho l...@apm.com
 + *
 + * 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;  either version 2 of the  License, or (at your
 + * option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + *
 + * NOTE: PM support is currently not available.
 + */
 +
 +#include linux/clk.h
 +#include linux/delay.h
 +#include linux/dma-mapping.h
 +#include linux/dmaengine.h
 +#include linux/dmapool.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_device.h
 +
 +#include dmaengine.h
 +
 +/* X-Gene DMA ring csr registers and bit definations */
 +#define XGENE_DMA_RING_CONFIG  0x04
 +#define XGENE_DMA_RING_ENABLE  BIT(31)
 +#define XGENE_DMA_RING_ID  0x08
 +#define XGENE_DMA_RING_ID_SETUP(v) ((v) | BIT(31))
 +#define XGENE_DMA_RING_ID_BUF  0x0C
 +#define XGENE_DMA_RING_ID_BUF_SETUP(v) (((v)  9) | BIT(21))
 +#define XGENE_DMA_RING_THRESLD0_SET1   0x30
 +#define XGENE_DMA_RING_THRESLD0_SET1_VAL   0X64
 +#define XGENE_DMA_RING_THRESLD1_SET1   0x34
 +#define XGENE_DMA_RING_THRESLD1_SET1_VAL   0xC8
 +#define XGENE_DMA_RING_HYSTERESIS  0x68
 +#define XGENE_DMA_RING_HYSTERESIS_VAL  0x
 +#define XGENE_DMA_RING_STATE   0x6C
 +#define XGENE_DMA_RING_STATE_WR_BASE   0x70
 +#define XGENE_DMA_RING_NE_INT_MODE 0x017C
 +#define XGENE_DMA_RING_NE_INT_MODE_SET(m, v)   \
 +   ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define XGENE_DMA_RING_NE_INT_MODE_RESET(m, v) \
 +   ((m) = (~BIT(31 - (v
 +#define XGENE_DMA_RING_CLKEN   0xC208
 +#define XGENE_DMA_RING_SRST0xC200
 +#define XGENE_DMA_RING_MEM_RAM_SHUTDOWN0xD070
 +#define XGENE_DMA_RING_BLK_MEM_RDY 0xD074
 +#define XGENE_DMA_RING_BLK_MEM_RDY_VAL 0x
 +#define XGENE_DMA_RING_DESC_CNT(v) (((v)  0x0001FFFE)  1)
 +#define XGENE_DMA_RING_ID_GET(owner, num)  (((owner)  6) | (num))
 +#define XGENE_DMA_RING_DST_ID(v)   ((1  10) | (v))
 +#define XGENE_DMA_RING_CMD_OFFSET  0x2C
 +#define XGENE_DMA_RING_CMD_BASE_OFFSET(v)  ((v)  6)
 +#define XGENE_DMA_RING_COHERENT_SET(m) \
 +   (((u32 *)(m))[2] |= BIT(4))
 +#define XGENE_DMA_RING_ADDRL_SET(m

Re: [PATCH v8 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Thu, Mar 19, 2015 at 1:47 PM, Rameshwar Sahu  wrote:
> Hi Vinod,
>
> On Wed, Mar 18, 2015 at 7:17 PM, Rameshwar Prasad Sahu  wrote:
>> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
>> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
>> These DMA operations include memory copy, scatter-gather memory copy,
>> raid5 xor, and raid6 p+q offloading.
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> Signed-off-by: Loc Ho 
>> ---
>>  drivers/dma/Kconfig |8 +
>>  drivers/dma/Makefile|1 +
>>  drivers/dma/xgene-dma.c | 2090 
>> +++
>>  3 files changed, 2099 insertions(+)
>>  create mode 100755 drivers/dma/xgene-dma.c
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index a874b6e..a271346 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -425,6 +425,14 @@ config IMG_MDC_DMA
>> help
>>   Enable support for the IMG multi-threaded DMA controller (MDC).
>>
>> +config XGENE_DMA
>> +   tristate "APM X-Gene DMA support"
>> +   select DMA_ENGINE
>> +   select DMA_ENGINE_RAID
>> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>> +   help
>> + Enable support for the APM X-Gene SoC DMA engine.
>> +
>>  config DMA_ENGINE
>> bool
>>
>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>> index f915f61..06c1576 100644
>> --- a/drivers/dma/Makefile
>> +++ b/drivers/dma/Makefile
>> @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>>  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
>> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> new file mode 100755
>> index 000..2383528
>> --- /dev/null
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -0,0 +1,2090 @@
>> +/*
>> + * Applied Micro X-Gene SoC DMA engine Driver
>> + *
>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>> + * Authors: Rameshwar Prasad Sahu 
>> + * Loc Ho 
>> + *
>> + * 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;  either version 2 of the  License, or (at your
>> + * option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + *
>> + * NOTE: PM support is currently not available.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "dmaengine.h"
>> +
>> +/* X-Gene DMA ring csr registers and bit definations */
>> +#define XGENE_DMA_RING_CONFIG  0x04
>> +#define XGENE_DMA_RING_ENABLE  BIT(31)
>> +#define XGENE_DMA_RING_ID  0x08
>> +#define XGENE_DMA_RING_ID_SETUP(v) ((v) | BIT(31))
>> +#define XGENE_DMA_RING_ID_BUF  0x0C
>> +#define XGENE_DMA_RING_ID_BUF_SETUP(v) (((v) << 9) | BIT(21))
>> +#define XGENE_DMA_RING_THRESLD0_SET1   0x30
>> +#define XGENE_DMA_RING_THRESLD0_SET1_VAL   0X64
>> +#define XGENE_DMA_RING_THRESLD1_SET1   0x34
>> +#define XGENE_DMA_RING_THRESLD1_SET1_VAL   0xC8
>> +#define XGENE_DMA_RING_HYSTERESIS  0x68
>> +#define XGENE_DMA_RING_HYSTERESIS_VAL  0x
>> +#define XGENE_DMA_RING_STATE   0x6C
>> +#define XGENE_DMA_RING_STATE_WR_BASE   0x70
>> +#define XGENE_DMA_RING_NE_INT_MODE 0x017C
>> +#define XGENE_DMA_RING_NE_INT_MODE_SET(m, v)   \
>> +   ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
>> +#define XGENE_DMA_RING_NE_INT_MODE_RESET(m, v) \
>> +   ((m) &= (~BIT(31 - (v
>> +#define XGENE_DMA_RING_CLKEN   0xC208
>> +#define XGENE_DMA_RING_SRST0xC200
>

Re: [PATCH v8 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Thu, Mar 19, 2015 at 1:47 PM, Rameshwar Sahu rs...@apm.com wrote:
 Hi Vinod,

 On Wed, Mar 18, 2015 at 7:17 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy, scatter-gather memory copy,
 raid5 xor, and raid6 p+q offloading.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---
  drivers/dma/Kconfig |8 +
  drivers/dma/Makefile|1 +
  drivers/dma/xgene-dma.c | 2090 
 +++
  3 files changed, 2099 insertions(+)
  create mode 100755 drivers/dma/xgene-dma.c

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index a874b6e..a271346 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -425,6 +425,14 @@ config IMG_MDC_DMA
 help
   Enable support for the IMG multi-threaded DMA controller (MDC).

 +config XGENE_DMA
 +   tristate APM X-Gene DMA support
 +   select DMA_ENGINE
 +   select DMA_ENGINE_RAID
 +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
 +   help
 + Enable support for the APM X-Gene SoC DMA engine.
 +
  config DMA_ENGINE
 bool

 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index f915f61..06c1576 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
 +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 new file mode 100755
 index 000..2383528
 --- /dev/null
 +++ b/drivers/dma/xgene-dma.c
 @@ -0,0 +1,2090 @@
 +/*
 + * Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2015, Applied Micro Circuits Corporation
 + * Authors: Rameshwar Prasad Sahu rs...@apm.com
 + * Loc Ho l...@apm.com
 + *
 + * 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;  either version 2 of the  License, or (at your
 + * option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + *
 + * NOTE: PM support is currently not available.
 + */
 +
 +#include linux/clk.h
 +#include linux/delay.h
 +#include linux/dma-mapping.h
 +#include linux/dmaengine.h
 +#include linux/dmapool.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_device.h
 +
 +#include dmaengine.h
 +
 +/* X-Gene DMA ring csr registers and bit definations */
 +#define XGENE_DMA_RING_CONFIG  0x04
 +#define XGENE_DMA_RING_ENABLE  BIT(31)
 +#define XGENE_DMA_RING_ID  0x08
 +#define XGENE_DMA_RING_ID_SETUP(v) ((v) | BIT(31))
 +#define XGENE_DMA_RING_ID_BUF  0x0C
 +#define XGENE_DMA_RING_ID_BUF_SETUP(v) (((v)  9) | BIT(21))
 +#define XGENE_DMA_RING_THRESLD0_SET1   0x30
 +#define XGENE_DMA_RING_THRESLD0_SET1_VAL   0X64
 +#define XGENE_DMA_RING_THRESLD1_SET1   0x34
 +#define XGENE_DMA_RING_THRESLD1_SET1_VAL   0xC8
 +#define XGENE_DMA_RING_HYSTERESIS  0x68
 +#define XGENE_DMA_RING_HYSTERESIS_VAL  0x
 +#define XGENE_DMA_RING_STATE   0x6C
 +#define XGENE_DMA_RING_STATE_WR_BASE   0x70
 +#define XGENE_DMA_RING_NE_INT_MODE 0x017C
 +#define XGENE_DMA_RING_NE_INT_MODE_SET(m, v)   \
 +   ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define XGENE_DMA_RING_NE_INT_MODE_RESET(m, v) \
 +   ((m) = (~BIT(31 - (v
 +#define XGENE_DMA_RING_CLKEN   0xC208
 +#define XGENE_DMA_RING_SRST0xC200
 +#define XGENE_DMA_RING_MEM_RAM_SHUTDOWN0xD070
 +#define XGENE_DMA_RING_BLK_MEM_RDY 0xD074
 +#define XGENE_DMA_RING_BLK_MEM_RDY_VAL 0x
 +#define XGENE_DMA_RING_DESC_CNT(v) (((v)  0x0001FFFE)  1)
 +#define XGENE_DMA_RING_ID_GET(owner, num)  (((owner)  6) | (num))
 +#define XGENE_DMA_RING_DST_ID(v)   ((1  10) | (v))
 +#define XGENE_DMA_RING_CMD_OFFSET  0x2C
 +#define XGENE_DMA_RING_CMD_BASE_OFFSET(v)  ((v)  6)
 +#define XGENE_DMA_RING_COHERENT_SET(m) \
 +   (((u32 *)(m))[2] |= BIT(4))
 +#define XGENE_DMA_RING_ADDRL_SET(m, v) \
 +   (((u32 *)(m))[2] |= (((v)  8)  5))
 +#define

Re: [PATCH v8 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Wed, Mar 18, 2015 at 7:17 PM, Rameshwar Prasad Sahu  wrote:
> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
> These DMA operations include memory copy, scatter-gather memory copy,
> raid5 xor, and raid6 p+q offloading.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> Signed-off-by: Loc Ho 
> ---
>  drivers/dma/Kconfig |8 +
>  drivers/dma/Makefile|1 +
>  drivers/dma/xgene-dma.c | 2090 
> +++
>  3 files changed, 2099 insertions(+)
>  create mode 100755 drivers/dma/xgene-dma.c
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index a874b6e..a271346 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -425,6 +425,14 @@ config IMG_MDC_DMA
> help
>   Enable support for the IMG multi-threaded DMA controller (MDC).
>
> +config XGENE_DMA
> +   tristate "APM X-Gene DMA support"
> +   select DMA_ENGINE
> +   select DMA_ENGINE_RAID
> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
> +   help
> + Enable support for the APM X-Gene SoC DMA engine.
> +
>  config DMA_ENGINE
> bool
>
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index f915f61..06c1576 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> new file mode 100755
> index 000..2383528
> --- /dev/null
> +++ b/drivers/dma/xgene-dma.c
> @@ -0,0 +1,2090 @@
> +/*
> + * Applied Micro X-Gene SoC DMA engine Driver
> + *
> + * Copyright (c) 2015, Applied Micro Circuits Corporation
> + * Authors: Rameshwar Prasad Sahu 
> + * Loc Ho 
> + *
> + * 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;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + * NOTE: PM support is currently not available.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "dmaengine.h"
> +
> +/* X-Gene DMA ring csr registers and bit definations */
> +#define XGENE_DMA_RING_CONFIG  0x04
> +#define XGENE_DMA_RING_ENABLE  BIT(31)
> +#define XGENE_DMA_RING_ID  0x08
> +#define XGENE_DMA_RING_ID_SETUP(v) ((v) | BIT(31))
> +#define XGENE_DMA_RING_ID_BUF  0x0C
> +#define XGENE_DMA_RING_ID_BUF_SETUP(v) (((v) << 9) | BIT(21))
> +#define XGENE_DMA_RING_THRESLD0_SET1   0x30
> +#define XGENE_DMA_RING_THRESLD0_SET1_VAL   0X64
> +#define XGENE_DMA_RING_THRESLD1_SET1   0x34
> +#define XGENE_DMA_RING_THRESLD1_SET1_VAL   0xC8
> +#define XGENE_DMA_RING_HYSTERESIS  0x68
> +#define XGENE_DMA_RING_HYSTERESIS_VAL  0x
> +#define XGENE_DMA_RING_STATE   0x6C
> +#define XGENE_DMA_RING_STATE_WR_BASE   0x70
> +#define XGENE_DMA_RING_NE_INT_MODE 0x017C
> +#define XGENE_DMA_RING_NE_INT_MODE_SET(m, v)   \
> +   ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
> +#define XGENE_DMA_RING_NE_INT_MODE_RESET(m, v) \
> +   ((m) &= (~BIT(31 - (v
> +#define XGENE_DMA_RING_CLKEN   0xC208
> +#define XGENE_DMA_RING_SRST0xC200
> +#define XGENE_DMA_RING_MEM_RAM_SHUTDOWN0xD070
> +#define XGENE_DMA_RING_BLK_MEM_RDY 0xD074
> +#define XGENE_DMA_RING_BLK_MEM_RDY_VAL 0x
> +#define XGENE_DMA_RING_DESC_CNT(v) (((v) & 0x0001FFFE) >> 1)
> +#define XGENE_DMA_RING_ID_GET(owner, num)  (((owner) << 6) | (num))
> +#define XGENE_DMA_RING_DST_ID(v)   ((1 << 10) | (v))
> +#define XGENE_DMA_RING_CMD_OFFSET  0x2C
> +#define XGENE_DMA_RING_CMD_BASE_OFFSET(v)  ((v) << 6)
> +#define XGENE_DMA_RING_COHERENT_SET(m) \
> +   (((u32 *)(m))[2] |= BIT(4))
> +#define XGENE_DMA_RING_ADDRL_SET(m, v) \
> +   (((u32 *)(m))[2] |= (((v) >> 8) << 5))
> +#define XGENE_DMA_RING_ADDRH_SET(m, v) \
> +   (((u32 *)(m))[3] |= ((v) >> 35))
> +#define XGENE_DMA_RING_ACCEPTLERR_SET(m)   \
> +   

Re: [PATCH v8 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Wed, Mar 18, 2015 at 7:17 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy, scatter-gather memory copy,
 raid5 xor, and raid6 p+q offloading.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---
  drivers/dma/Kconfig |8 +
  drivers/dma/Makefile|1 +
  drivers/dma/xgene-dma.c | 2090 
 +++
  3 files changed, 2099 insertions(+)
  create mode 100755 drivers/dma/xgene-dma.c

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index a874b6e..a271346 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -425,6 +425,14 @@ config IMG_MDC_DMA
 help
   Enable support for the IMG multi-threaded DMA controller (MDC).

 +config XGENE_DMA
 +   tristate APM X-Gene DMA support
 +   select DMA_ENGINE
 +   select DMA_ENGINE_RAID
 +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
 +   help
 + Enable support for the APM X-Gene SoC DMA engine.
 +
  config DMA_ENGINE
 bool

 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index f915f61..06c1576 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
 +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 new file mode 100755
 index 000..2383528
 --- /dev/null
 +++ b/drivers/dma/xgene-dma.c
 @@ -0,0 +1,2090 @@
 +/*
 + * Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2015, Applied Micro Circuits Corporation
 + * Authors: Rameshwar Prasad Sahu rs...@apm.com
 + * Loc Ho l...@apm.com
 + *
 + * 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;  either version 2 of the  License, or (at your
 + * option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + *
 + * NOTE: PM support is currently not available.
 + */
 +
 +#include linux/clk.h
 +#include linux/delay.h
 +#include linux/dma-mapping.h
 +#include linux/dmaengine.h
 +#include linux/dmapool.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_device.h
 +
 +#include dmaengine.h
 +
 +/* X-Gene DMA ring csr registers and bit definations */
 +#define XGENE_DMA_RING_CONFIG  0x04
 +#define XGENE_DMA_RING_ENABLE  BIT(31)
 +#define XGENE_DMA_RING_ID  0x08
 +#define XGENE_DMA_RING_ID_SETUP(v) ((v) | BIT(31))
 +#define XGENE_DMA_RING_ID_BUF  0x0C
 +#define XGENE_DMA_RING_ID_BUF_SETUP(v) (((v)  9) | BIT(21))
 +#define XGENE_DMA_RING_THRESLD0_SET1   0x30
 +#define XGENE_DMA_RING_THRESLD0_SET1_VAL   0X64
 +#define XGENE_DMA_RING_THRESLD1_SET1   0x34
 +#define XGENE_DMA_RING_THRESLD1_SET1_VAL   0xC8
 +#define XGENE_DMA_RING_HYSTERESIS  0x68
 +#define XGENE_DMA_RING_HYSTERESIS_VAL  0x
 +#define XGENE_DMA_RING_STATE   0x6C
 +#define XGENE_DMA_RING_STATE_WR_BASE   0x70
 +#define XGENE_DMA_RING_NE_INT_MODE 0x017C
 +#define XGENE_DMA_RING_NE_INT_MODE_SET(m, v)   \
 +   ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define XGENE_DMA_RING_NE_INT_MODE_RESET(m, v) \
 +   ((m) = (~BIT(31 - (v
 +#define XGENE_DMA_RING_CLKEN   0xC208
 +#define XGENE_DMA_RING_SRST0xC200
 +#define XGENE_DMA_RING_MEM_RAM_SHUTDOWN0xD070
 +#define XGENE_DMA_RING_BLK_MEM_RDY 0xD074
 +#define XGENE_DMA_RING_BLK_MEM_RDY_VAL 0x
 +#define XGENE_DMA_RING_DESC_CNT(v) (((v)  0x0001FFFE)  1)
 +#define XGENE_DMA_RING_ID_GET(owner, num)  (((owner)  6) | (num))
 +#define XGENE_DMA_RING_DST_ID(v)   ((1  10) | (v))
 +#define XGENE_DMA_RING_CMD_OFFSET  0x2C
 +#define XGENE_DMA_RING_CMD_BASE_OFFSET(v)  ((v)  6)
 +#define XGENE_DMA_RING_COHERENT_SET(m) \
 +   (((u32 *)(m))[2] |= BIT(4))
 +#define XGENE_DMA_RING_ADDRL_SET(m, v) \
 +   (((u32 *)(m))[2] |= (((v)  8)  5))
 +#define XGENE_DMA_RING_ADDRH_SET(m, v) \
 +   (((u32 *)(m))[3] |= ((v)  35))
 +#define 

Re: [PATCH v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Tue, Mar 17, 2015 at 3:49 PM, Vinod Koul  wrote:
> On Tue, Mar 17, 2015 at 03:03:14PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Mon, Mar 16, 2015 at 11:01 PM, Rameshwar Sahu  wrote:
>> > Hi Vinod,
>> >
>> > On Mon, Mar 16, 2015 at 9:56 PM, Vinod Koul  wrote:
>> >> On Mon, Mar 16, 2015 at 05:24:34PM +0530, Rameshwar Sahu wrote:
>> >>> >> >> +static void xgene_dma_free_desc_list_reverse(struct 
>> >>> >> >> xgene_dma_chan *chan,
>> >>> >> >> +  struct list_head *list)
>> >>> >> > do we really care about free order?
>> >>> >>
>> >>> >> Yes it start dellocation of descriptor by tail.
>> >>> > and why by tail is not clear.
>> >>> We can free allocated descriptor in forward order from head or in
>> >>> reverse order, I just followed here fsldma.c driver.
>> >>> Does this make sense ??
>> >> No, you have two APIs to free list. Why do you need two?
>> >
>> > Yes, basically we have tow API to free list.
>> > xgene_dma_free_desc_list_reverse will call if any failure in
>> > allocation of memory from DMA pool in prep routines.
>> > Like e.g. in prep routing we have some descriptors allocated and still
>> > need to get descriptor to complete the DMA request and failure happen,
>> > so we need to free all allocated descriptor.
>> >
>> >>
>> >>>
>> >>>
>> >>> >
>> >>> >> > where are you mapping dma buffers?
>> >>> >>
>> >>> >>  I didn't get you here. Can you please explain me here what you mean.
>> >>> >> As per my understanding client should map the dma buffer and give the
>> >>> >> physical address and size to this callback prep routines.
>> >>> > not for memcpy, that is true for slave transfers
>> >>> >
>> >>> > For mempcy the idea is that drivers will do buffer mapping
>> >>>
>> >>> Still I am clear here, why memcpy will do buffer mapping, I see other
>> >>> drivers and also async_memcpy.c , they only map it and pass mapped
>> >>> physical dma address to driver.
>> >>>
>> >>> Buffer mapping mean you here is dma_map_xxx ?? Am I correct.
>> >> Yes
>> >
>> > I have confusion here, I don't see any driver dma buffer mapping in
>> > prep_dma_memcpy.
>> > Can you please clear me here if driver does this on behalf of client,
>> > like any example so that I can proceed further.
>>
>> Any comment here ??
> The advise typically is that for memcpy the dma mapping should be done by
> client. For now this is okay as we have precedence, let me check with Dan.
>>
>> >>
>> >>>
>> >>> >
>> >>> >> > why are you calling this here, status check shouldnt do this...
>> >>> >>
>> >>> >> Okay, I will remove it.
>> >>> >>
>> >>> >>
>> >>> >> >> + spin_unlock_bh(>lock);
>> >>> >> >> + return DMA_IN_PROGRESS;
>> >>> >> > residue here is size of transacation.
>> >>> >>
>> >>> >> We can't calculate here residue size. We don't have any controller
>> >>> >> register which will tell about remaining transaction size.
>> >>> > Okay if you cant calculate residue why do we have this fn?
>> >>>
>> >>> So basically case here for me is completion of dma descriptor
>> >>> submitted to hw is not same as order of submission to hw.
>> >>> So scenario coming in multithread running :e.g. let's assume we have
>> >>> submitted two descriptors first has cookie 1001 and second has 1002,
>> >>> now 1002 is completed first, so updated last_completed_cookie as 1002
>> >>> but not yer checked for dma_tx_status, and then first cookie completes
>> >>> and update last_completed_cookie as 1001, now second transaction check
>> >>> for tx_status and it get DMA_IN_PROGRESS, because
>> >>> last_completed_cookie(1001) is less than second transaction's
>> >>> cookie(1002).
>> >>>
>> >>> Due to this issue I am traversing that transaction in pend

Re: [PATCH v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 16, 2015 at 11:01 PM, Rameshwar Sahu  wrote:
> Hi Vinod,
>
> On Mon, Mar 16, 2015 at 9:56 PM, Vinod Koul  wrote:
>> On Mon, Mar 16, 2015 at 05:24:34PM +0530, Rameshwar Sahu wrote:
>>> >> >> +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan 
>>> >> >> *chan,
>>> >> >> +  struct list_head *list)
>>> >> > do we really care about free order?
>>> >>
>>> >> Yes it start dellocation of descriptor by tail.
>>> > and why by tail is not clear.
>>> We can free allocated descriptor in forward order from head or in
>>> reverse order, I just followed here fsldma.c driver.
>>> Does this make sense ??
>> No, you have two APIs to free list. Why do you need two?
>
> Yes, basically we have tow API to free list.
> xgene_dma_free_desc_list_reverse will call if any failure in
> allocation of memory from DMA pool in prep routines.
> Like e.g. in prep routing we have some descriptors allocated and still
> need to get descriptor to complete the DMA request and failure happen,
> so we need to free all allocated descriptor.
>
>>
>>>
>>>
>>> >
>>> >> > where are you mapping dma buffers?
>>> >>
>>> >>  I didn't get you here. Can you please explain me here what you mean.
>>> >> As per my understanding client should map the dma buffer and give the
>>> >> physical address and size to this callback prep routines.
>>> > not for memcpy, that is true for slave transfers
>>> >
>>> > For mempcy the idea is that drivers will do buffer mapping
>>>
>>> Still I am clear here, why memcpy will do buffer mapping, I see other
>>> drivers and also async_memcpy.c , they only map it and pass mapped
>>> physical dma address to driver.
>>>
>>> Buffer mapping mean you here is dma_map_xxx ?? Am I correct.
>> Yes
>
> I have confusion here, I don't see any driver dma buffer mapping in
> prep_dma_memcpy.
> Can you please clear me here if driver does this on behalf of client,
> like any example so that I can proceed further.

Any comment here ??

>>
>>>
>>> >
>>> >> > why are you calling this here, status check shouldnt do this...
>>> >>
>>> >> Okay, I will remove it.
>>> >>
>>> >>
>>> >> >> + spin_unlock_bh(>lock);
>>> >> >> + return DMA_IN_PROGRESS;
>>> >> > residue here is size of transacation.
>>> >>
>>> >> We can't calculate here residue size. We don't have any controller
>>> >> register which will tell about remaining transaction size.
>>> > Okay if you cant calculate residue why do we have this fn?
>>>
>>> So basically case here for me is completion of dma descriptor
>>> submitted to hw is not same as order of submission to hw.
>>> So scenario coming in multithread running :e.g. let's assume we have
>>> submitted two descriptors first has cookie 1001 and second has 1002,
>>> now 1002 is completed first, so updated last_completed_cookie as 1002
>>> but not yer checked for dma_tx_status, and then first cookie completes
>>> and update last_completed_cookie as 1001, now second transaction check
>>> for tx_status and it get DMA_IN_PROGRESS, because
>>> last_completed_cookie(1001) is less than second transaction's
>>> cookie(1002).
>>>
>>> Due to this issue I am traversing that transaction in pending list and
>>> running list, if not there means we are done.
>>>
>>> Does this make sense??
>> That only convinces me that there is something not so correct.
>>
>> To help me understand pls let me know if below is fine:
>> - for a physical channel, do you submit multiple transactions?
>
> Yes
>
>> - if yes, how does DMA deal with multiple transactions, how does it schedule
>>   them?
>
> So , basically we submit multiple descriptor to dma physical channel,
> and dma engine execute it one by one and give us completion callback.
> So in this way we expect callback on same order as submission order
> and it does also, no issue.
>
> But problem is with supporting p+q offload, here we have P
> functionality supports in dma physical channel 0 and Q functionality
> supports in dma physical channel 1. So for pq we need to submit two
> descriptor, one to channel 0 and second to channel1, in this cas

Re: [PATCH v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Tue, Mar 17, 2015 at 3:49 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Tue, Mar 17, 2015 at 03:03:14PM +0530, Rameshwar Sahu wrote:
 Hi Vinod,

 On Mon, Mar 16, 2015 at 11:01 PM, Rameshwar Sahu rs...@apm.com wrote:
  Hi Vinod,
 
  On Mon, Mar 16, 2015 at 9:56 PM, Vinod Koul vinod.k...@intel.com wrote:
  On Mon, Mar 16, 2015 at 05:24:34PM +0530, Rameshwar Sahu wrote:
+static void xgene_dma_free_desc_list_reverse(struct 
xgene_dma_chan *chan,
+  struct list_head *list)
do we really care about free order?
  
   Yes it start dellocation of descriptor by tail.
   and why by tail is not clear.
  We can free allocated descriptor in forward order from head or in
  reverse order, I just followed here fsldma.c driver.
  Does this make sense ??
  No, you have two APIs to free list. Why do you need two?
 
  Yes, basically we have tow API to free list.
  xgene_dma_free_desc_list_reverse will call if any failure in
  allocation of memory from DMA pool in prep routines.
  Like e.g. in prep routing we have some descriptors allocated and still
  need to get descriptor to complete the DMA request and failure happen,
  so we need to free all allocated descriptor.
 
 
 
 
  
where are you mapping dma buffers?
  
I didn't get you here. Can you please explain me here what you mean.
   As per my understanding client should map the dma buffer and give the
   physical address and size to this callback prep routines.
   not for memcpy, that is true for slave transfers
  
   For mempcy the idea is that drivers will do buffer mapping
 
  Still I am clear here, why memcpy will do buffer mapping, I see other
  drivers and also async_memcpy.c , they only map it and pass mapped
  physical dma address to driver.
 
  Buffer mapping mean you here is dma_map_xxx ?? Am I correct.
  Yes
 
  I have confusion here, I don't see any driver dma buffer mapping in
  prep_dma_memcpy.
  Can you please clear me here if driver does this on behalf of client,
  like any example so that I can proceed further.

 Any comment here ??
 The advise typically is that for memcpy the dma mapping should be done by
 client. For now this is okay as we have precedence, let me check with Dan.

 
 
  
why are you calling this here, status check shouldnt do this...
  
   Okay, I will remove it.
  
  
+ spin_unlock_bh(chan-lock);
+ return DMA_IN_PROGRESS;
residue here is size of transacation.
  
   We can't calculate here residue size. We don't have any controller
   register which will tell about remaining transaction size.
   Okay if you cant calculate residue why do we have this fn?
 
  So basically case here for me is completion of dma descriptor
  submitted to hw is not same as order of submission to hw.
  So scenario coming in multithread running :e.g. let's assume we have
  submitted two descriptors first has cookie 1001 and second has 1002,
  now 1002 is completed first, so updated last_completed_cookie as 1002
  but not yer checked for dma_tx_status, and then first cookie completes
  and update last_completed_cookie as 1001, now second transaction check
  for tx_status and it get DMA_IN_PROGRESS, because
  last_completed_cookie(1001) is less than second transaction's
  cookie(1002).
 
  Due to this issue I am traversing that transaction in pending list and
  running list, if not there means we are done.
 
  Does this make sense??
  That only convinces me that there is something not so correct.
 
  To help me understand pls let me know if below is fine:
  - for a physical channel, do you submit multiple transactions?
 
  Yes
 
  - if yes, how does DMA deal with multiple transactions, how does it 
  schedule
them?
 
  So , basically we submit multiple descriptor to dma physical channel,
  and dma engine execute it one by one and give us completion callback.
  So in this way we expect callback on same order as submission order
  and it does also, no issue.
 
  But problem is with supporting p+q offload, here we have P
  functionality supports in dma physical channel 0 and Q functionality
  supports in dma physical channel 1. So for pq we need to submit two
  descriptor, one to channel 0 and second to channel1, in this case we
  can't expect the completion order, because channnel 0 can finish P
  before Q or vice versa, and we need to wait to complete both before
  calling client callback() and completing cookie.
  Second thing we submit memcpy and sg on same channel, and can complete
  before even though if it submitted after PQ.

 So our SoC dma engine hw design idea was to get more throughput while
 running two channel concurrent and calculating the P and Q together,
 but somehow now today we came to scenario where running P and Q on
 different channel causing hang to dmaengine, some hw bug, So now I am
 going to support P and Q generation in same channel, so above
 mentioned cookie status scenario will never come.
 I will send

Re: [PATCH v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 16, 2015 at 11:01 PM, Rameshwar Sahu rs...@apm.com wrote:
 Hi Vinod,

 On Mon, Mar 16, 2015 at 9:56 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Mon, Mar 16, 2015 at 05:24:34PM +0530, Rameshwar Sahu wrote:
   +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan 
   *chan,
   +  struct list_head *list)
   do we really care about free order?
 
  Yes it start dellocation of descriptor by tail.
  and why by tail is not clear.
 We can free allocated descriptor in forward order from head or in
 reverse order, I just followed here fsldma.c driver.
 Does this make sense ??
 No, you have two APIs to free list. Why do you need two?

 Yes, basically we have tow API to free list.
 xgene_dma_free_desc_list_reverse will call if any failure in
 allocation of memory from DMA pool in prep routines.
 Like e.g. in prep routing we have some descriptors allocated and still
 need to get descriptor to complete the DMA request and failure happen,
 so we need to free all allocated descriptor.




 
   where are you mapping dma buffers?
 
   I didn't get you here. Can you please explain me here what you mean.
  As per my understanding client should map the dma buffer and give the
  physical address and size to this callback prep routines.
  not for memcpy, that is true for slave transfers
 
  For mempcy the idea is that drivers will do buffer mapping

 Still I am clear here, why memcpy will do buffer mapping, I see other
 drivers and also async_memcpy.c , they only map it and pass mapped
 physical dma address to driver.

 Buffer mapping mean you here is dma_map_xxx ?? Am I correct.
 Yes

 I have confusion here, I don't see any driver dma buffer mapping in
 prep_dma_memcpy.
 Can you please clear me here if driver does this on behalf of client,
 like any example so that I can proceed further.

Any comment here ??



 
   why are you calling this here, status check shouldnt do this...
 
  Okay, I will remove it.
 
 
   + spin_unlock_bh(chan-lock);
   + return DMA_IN_PROGRESS;
   residue here is size of transacation.
 
  We can't calculate here residue size. We don't have any controller
  register which will tell about remaining transaction size.
  Okay if you cant calculate residue why do we have this fn?

 So basically case here for me is completion of dma descriptor
 submitted to hw is not same as order of submission to hw.
 So scenario coming in multithread running :e.g. let's assume we have
 submitted two descriptors first has cookie 1001 and second has 1002,
 now 1002 is completed first, so updated last_completed_cookie as 1002
 but not yer checked for dma_tx_status, and then first cookie completes
 and update last_completed_cookie as 1001, now second transaction check
 for tx_status and it get DMA_IN_PROGRESS, because
 last_completed_cookie(1001) is less than second transaction's
 cookie(1002).

 Due to this issue I am traversing that transaction in pending list and
 running list, if not there means we are done.

 Does this make sense??
 That only convinces me that there is something not so correct.

 To help me understand pls let me know if below is fine:
 - for a physical channel, do you submit multiple transactions?

 Yes

 - if yes, how does DMA deal with multiple transactions, how does it schedule
   them?

 So , basically we submit multiple descriptor to dma physical channel,
 and dma engine execute it one by one and give us completion callback.
 So in this way we expect callback on same order as submission order
 and it does also, no issue.

 But problem is with supporting p+q offload, here we have P
 functionality supports in dma physical channel 0 and Q functionality
 supports in dma physical channel 1. So for pq we need to submit two
 descriptor, one to channel 0 and second to channel1, in this case we
 can't expect the completion order, because channnel 0 can finish P
 before Q or vice versa, and we need to wait to complete both before
 calling client callback() and completing cookie.
 Second thing we submit memcpy and sg on same channel, and can complete
 before even though if it submitted after PQ.

So our SoC dma engine hw design idea was to get more throughput while
running two channel concurrent and calculating the P and Q together,
but somehow now today we came to scenario where running P and Q on
different channel causing hang to dmaengine, some hw bug, So now I am
going to support P and Q generation in same channel, so above
mentioned cookie status scenario will never come.
I will send you the patch for review.

Thanks,


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

Re: [PATCH v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 16, 2015 at 9:56 PM, Vinod Koul  wrote:
> On Mon, Mar 16, 2015 at 05:24:34PM +0530, Rameshwar Sahu wrote:
>> >> >> +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan 
>> >> >> *chan,
>> >> >> +  struct list_head *list)
>> >> > do we really care about free order?
>> >>
>> >> Yes it start dellocation of descriptor by tail.
>> > and why by tail is not clear.
>> We can free allocated descriptor in forward order from head or in
>> reverse order, I just followed here fsldma.c driver.
>> Does this make sense ??
> No, you have two APIs to free list. Why do you need two?

Yes, basically we have tow API to free list.
xgene_dma_free_desc_list_reverse will call if any failure in
allocation of memory from DMA pool in prep routines.
Like e.g. in prep routing we have some descriptors allocated and still
need to get descriptor to complete the DMA request and failure happen,
so we need to free all allocated descriptor.

>
>>
>>
>> >
>> >> > where are you mapping dma buffers?
>> >>
>> >>  I didn't get you here. Can you please explain me here what you mean.
>> >> As per my understanding client should map the dma buffer and give the
>> >> physical address and size to this callback prep routines.
>> > not for memcpy, that is true for slave transfers
>> >
>> > For mempcy the idea is that drivers will do buffer mapping
>>
>> Still I am clear here, why memcpy will do buffer mapping, I see other
>> drivers and also async_memcpy.c , they only map it and pass mapped
>> physical dma address to driver.
>>
>> Buffer mapping mean you here is dma_map_xxx ?? Am I correct.
> Yes

I have confusion here, I don't see any driver dma buffer mapping in
prep_dma_memcpy.
Can you please clear me here if driver does this on behalf of client,
like any example so that I can proceed further.
>
>>
>> >
>> >> > why are you calling this here, status check shouldnt do this...
>> >>
>> >> Okay, I will remove it.
>> >>
>> >>
>> >> >> + spin_unlock_bh(>lock);
>> >> >> + return DMA_IN_PROGRESS;
>> >> > residue here is size of transacation.
>> >>
>> >> We can't calculate here residue size. We don't have any controller
>> >> register which will tell about remaining transaction size.
>> > Okay if you cant calculate residue why do we have this fn?
>>
>> So basically case here for me is completion of dma descriptor
>> submitted to hw is not same as order of submission to hw.
>> So scenario coming in multithread running :e.g. let's assume we have
>> submitted two descriptors first has cookie 1001 and second has 1002,
>> now 1002 is completed first, so updated last_completed_cookie as 1002
>> but not yer checked for dma_tx_status, and then first cookie completes
>> and update last_completed_cookie as 1001, now second transaction check
>> for tx_status and it get DMA_IN_PROGRESS, because
>> last_completed_cookie(1001) is less than second transaction's
>> cookie(1002).
>>
>> Due to this issue I am traversing that transaction in pending list and
>> running list, if not there means we are done.
>>
>> Does this make sense??
> That only convinces me that there is something not so correct.
>
> To help me understand pls let me know if below is fine:
> - for a physical channel, do you submit multiple transactions?

Yes

> - if yes, how does DMA deal with multiple transactions, how does it schedule
>   them?

So , basically we submit multiple descriptor to dma physical channel,
and dma engine execute it one by one and give us completion callback.
So in this way we expect callback on same order as submission order
and it does also, no issue.

But problem is with supporting p+q offload, here we have P
functionality supports in dma physical channel 0 and Q functionality
supports in dma physical channel 1. So for pq we need to submit two
descriptor, one to channel 0 and second to channel1, in this case we
can't expect the completion order, because channnel 0 can finish P
before Q or vice versa, and we need to wait to complete both before
calling client callback() and completing cookie.
Second thing we submit memcpy and sg on same channel, and can complete
before even though if it submitted after PQ.

>
> --
> ~Vinod
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,


On Mon, Mar 16, 2015 at 4:57 PM, Vinod Koul  wrote:
> On Mon, Mar 16, 2015 at 04:00:22PM +0530, Rameshwar Sahu wrote:
>
>> >> +static struct xgene_dma_desc_sw *xgene_dma_alloc_descriptor(
>> >> +  struct xgene_dma_chan *chan)
>> >> +{
>> >> + struct xgene_dma_desc_sw *desc;
>> >> + dma_addr_t phys;
>> >> +
>> >> + desc = dma_pool_alloc(chan->desc_pool, GFP_NOWAIT, );
>> >> + if (!desc) {
>> >> + chan_dbg(chan, "Failed to allocate LDs\n");
>> > not error?
>>
>> Yes it's error only by lacking of dma memory, do I need to use dev_err
>> to show the error msg ??
> yes

Okay fine.
>
>>
>> >
>> >> +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan *chan,
>> >> +  struct list_head *list)
>> > do we really care about free order?
>>
>> Yes it start dellocation of descriptor by tail.
> and why by tail is not clear.

We can free allocated descriptor in forward order from head or in
reverse order, I just followed here fsldma.c driver.
Does this make sense ??


>
>> > where are you mapping dma buffers?
>>
>>  I didn't get you here. Can you please explain me here what you mean.
>> As per my understanding client should map the dma buffer and give the
>> physical address and size to this callback prep routines.
> not for memcpy, that is true for slave transfers
>
> For mempcy the idea is that drivers will do buffer mapping

Still I am clear here, why memcpy will do buffer mapping, I see other
drivers and also async_memcpy.c , they only map it and pass mapped
physical dma address to driver.

Buffer mapping mean you here is dma_map_xxx ?? Am I correct.

>
>> > why are you calling this here, status check shouldnt do this...
>>
>> Okay, I will remove it.
>>
>>
>> >> + spin_unlock_bh(>lock);
>> >> + return DMA_IN_PROGRESS;
>> > residue here is size of transacation.
>>
>> We can't calculate here residue size. We don't have any controller
>> register which will tell about remaining transaction size.
> Okay if you cant calculate residue why do we have this fn?

So basically case here for me is completion of dma descriptor
submitted to hw is not same as order of submission to hw.
So scenario coming in multithread running :e.g. let's assume we have
submitted two descriptors first has cookie 1001 and second has 1002,
now 1002 is completed first, so updated last_completed_cookie as 1002
but not yer checked for dma_tx_status, and then first cookie completes
and update last_completed_cookie as 1001, now second transaction check
for tx_status and it get DMA_IN_PROGRESS, because
last_completed_cookie(1001) is less than second transaction's
cookie(1002).

Due to this issue I am traversing that transaction in pending list and
running list, if not there means we are done.

Does this make sense??

>
>>
>> >> + }
>> >> + }
>> >> +
>> >> + /* Check if this descriptor is in running queue */
>> >> + list_for_each_entry(desc, >ld_running, node) {
>> >> + if (desc->tx.cookie == cookie) {
>> >> + /* Cleanup any running and executed descriptors */
>> >> + xgene_dma_cleanup_descriptors(chan);
>> > ditto?
>>
>> Okay
>>
>>
>> >> + spin_unlock_bh(>lock);
>> >> + return dma_cookie_status(>dma_chan,
>> >> +  cookie, txstate);
>> > and you havent touched txstate so what is the intent here...?
>>
>> txstate can filled by caller, so it may be NULL or not NULL, we are
>> passing same.
> something seems very wrong here. Status should return the current satue of
> queried descriptor and if residue value in txstate, you seem to be doing
> something else, quotesion is what and why :)
>

Please see my above comment.
Thanks
> --
> ~Vinod
>
--
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 v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 16, 2015 at 2:57 PM, Vinod Koul  wrote:
> On Thu, Mar 12, 2015 at 04:45:19PM +0530, Rameshwar Prasad Sahu wrote:
>> +/* DMA ring csr registers and bit definations */
>> +#define DMA_RING_CONFIG  0x04
>> +#define DMA_RING_ENABLE  BIT(31)
>> +#define DMA_RING_ID  0x08
>> +#define DMA_RING_ID_SETUP(v) ((v) | BIT(31))
>> +#define DMA_RING_ID_BUF  0x0C
>> +#define DMA_RING_ID_BUF_SETUP(v) (((v) << 9) | BIT(21))
>> +#define DMA_RING_THRESLD0_SET1   0x30
>> +#define DMA_RING_THRESLD0_SET1_VAL   0X64
>> +#define DMA_RING_THRESLD1_SET1   0x34
>> +#define DMA_RING_THRESLD1_SET1_VAL   0xC8
>> +#define DMA_RING_HYSTERESIS  0x68
>> +#define DMA_RING_HYSTERESIS_VAL  0x
>> +#define DMA_RING_STATE   0x6C
>> +#define DMA_RING_STATE_WR_BASE   0x70
>> +#define DMA_RING_NE_INT_MODE 0x017C
>> +#define DMA_RING_NE_INT_MODE_SET(m, v)   \
>> + ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
>> +#define DMA_RING_NE_INT_MODE_RESET(m, v) \
>> + ((m) &= (~BIT(31 - (v
>> +#define DMA_RING_CLKEN   0xC208
>> +#define DMA_RING_SRST0xC200
>> +#define DMA_RING_MEM_RAM_SHUTDOWN0xD070
>> +#define DMA_RING_BLK_MEM_RDY 0xD074
>> +#define DMA_RING_BLK_MEM_RDY_VAL 0x
>> +#define DMA_RING_DESC_CNT(v) (((v) & 0x0001FFFE) >> 1)
>> +#define DMA_RING_ID_GET(owner, num)  (((owner) << 6) | (num))
>> +#define DMA_RING_DST_ID(v)   ((1 << 10) | (v))
>> +#define DMA_RING_CMD_OFFSET  0x2C
>> +#define DMA_RING_CMD_BASE_OFFSET(v)  ((v) << 6)
>> +#define DMA_RING_COHERENT_SET(m) (((u32 *)(m))[2] |= BIT(4))
>> +#define DMA_RING_ADDRL_SET(m, v) (((u32 *)(m))[2] |= (((v) >> 8) << 5))
>> +#define DMA_RING_ADDRH_SET(m, v) (((u32 *)(m))[3] |= ((v) >> 35))
>> +#define DMA_RING_ACCEPTLERR_SET(m)   (((u32 *)(m))[3] |= BIT(19))
>> +#define DMA_RING_SIZE_SET(m, v)  (((u32 *)(m))[3] |= ((v) << 
>> 23))
>> +#define DMA_RING_RECOMBBUF_SET(m)(((u32 *)(m))[3] |= BIT(27))
>> +#define DMA_RING_RECOMTIMEOUTL_SET(m)(((u32 *)(m))[3] |= (0x7 << 
>> 28))
>> +#define DMA_RING_RECOMTIMEOUTH_SET(m)(((u32 *)(m))[4] |= 0x3)
>> +#define DMA_RING_SELTHRSH_SET(m) (((u32 *)(m))[4] |= BIT(3))
>> +#define DMA_RING_TYPE_SET(m, v)  (((u32 *)(m))[4] |= ((v) << 
>> 19))
> These are very generic name as can conflicts, can you please namespace
> these...
>
>> +/* DMA device csr registers and bit definitions */
>> +#define DMA_IPBRR0x0
>> +#define DMA_DEV_ID_RD(v) ((v) & 0x0FFF)
>> +#define DMA_BUS_ID_RD(v) (((v) >> 12) & 3)
>> +#define DMA_REV_NO_RD(v) (((v) >> 14) & 3)
>> +#define DMA_GCR  0x10
>> +#define DMA_CH_SETUP(v)  ((v) = ((v) & ~0x000F) | 
>> 0x000AAFFF)
>> +#define DMA_ENABLE(v)((v) |= BIT(31))
>> +#define DMA_DISABLE(v)   ((v) &= ~BIT(31))
>> +#define DMA_RAID6_CONT   0x14
>> +#define DMA_RAID6_MULTI_CTRL(v)  ((v) << 24)
>> +#define DMA_INT  0x70
>> +#define DMA_INT_MASK 0x74
>> +#define DMA_INT_ALL_MASK 0x
>> +#define DMA_INT_ALL_UNMASK   0x0
>> +#define DMA_INT_MASK_SHIFT   0x14
>> +#define DMA_RING_INT0_MASK   0x90A0
>> +#define DMA_RING_INT1_MASK   0x90A8
>> +#define DMA_RING_INT2_MASK   0x90B0
>> +#define DMA_RING_INT3_MASK   0x90B8
>> +#define DMA_RING_INT4_MASK   0x90C0
>> +#define DMA_CFG_RING_WQ_ASSOC0x90E0
>> +#define DMA_ASSOC_RING_MNGR1 0x
>> +#define DMA_MEM_RAM_SHUTDOWN 0xD070
>> +#define DMA_BLK_MEM_RDY  0xD074
>> +#define DMA_BLK_MEM_RDY_VAL  0x
> same here and throughout the driver..
>
>> +static void xgene_dma_free_descriptor(struct xgene_dma_chan *chan,
>> +   struct xgene_dma_desc_sw *desc)
>> +{
>> + list_del(>node);
>> + chan_dbg(chan, "LD %p free\n", desc);
>> + dma_pool_free(chan->desc_pool, desc, desc->tx.phys);
> where is the descriptor freed? Perhpas we can say clean rather than free
> here to not confuse...
>
>> +}
>> +
>> +static struct xgene_dma_desc_sw *xgene_dma_alloc_descriptor(
>> +  struct xgene_dma_chan *chan)
>> +{
>> + struct xgene_dma_desc_sw *desc;
>> + dma_addr_t phys;
>> +
>> + desc = dma_pool_alloc(chan->desc_pool, GFP_NOWAIT, );
>> + if (!desc) {
>> + chan_dbg(chan, "Failed to allocate LDs\n");
> not error?
>
>> +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan *chan,
>> +  struct list_head *list)
> do we really care about free order?
>

Re: [PATCH v7 3/3] Documentation: dma: Add APM X-Gene SoC DMA engine driver documentation

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 16, 2015 at 2:59 PM, Vinod Koul  wrote:
> On Thu, Mar 12, 2015 at 04:45:21PM +0530, Rameshwar Prasad Sahu wrote:
>> This patch adds device tree binding for APM X-Gene SoC DMA engine driver.
> The patch title should be to add the bindings and not Documentation

Got it, thanks
>
> --
> ~Vinod
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> Signed-off-by: Loc Ho 
>> ---
>>  .../devicetree/bindings/dma/apm-xgene-dma.txt  | 47 
>> ++
>>  1 file changed, 47 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt 
>> b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
>> new file mode 100644
>> index 000..d305876
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
>> @@ -0,0 +1,47 @@
>> +Applied Micro X-Gene SoC DMA nodes
>> +
>> +DMA nodes are defined to describe on-chip DMA interfaces in
>> +APM X-Gene SoC.
>> +
>> +Required properties for DMA interfaces:
>> +- compatible: Should be "apm,xgene-dma".
>> +- device_type: set to "dma".
>> +- reg: Address and length of the register set for the device.
>> +  It contains the information of registers in the following order:
>> +  1st - DMA control and status register address space.
>> +  2nd - Descriptor ring control and status register address space.
>> +  3rd - Descriptor ring command register address space.
>> +  4th - Soc efuse register address space.
>> +- interrupts: DMA has 5 interrupts sources. 1st interrupt is
>> +  DMA error reporting interrupt. 2nd, 3rd, 4th and 5th interrupts
>> +  are completion interrupts for each DMA channels.
>> +- clocks: Reference to the clock entry.
>> +
>> +Optional properties:
>> +- dma-coherent : Present if dma operations are coherent
>> +
>> +Example:
>> + dmaclk: dmaclk@1f27c000 {
>> + compatible = "apm,xgene-device-clock";
>> + #clock-cells = <1>;
>> + clocks = < 0>;
>> + reg = <0x0 0x1f27c000 0x0 0x1000>;
>> + reg-names = "csr-reg";
>> + clock-output-names = "dmaclk";
>> + };
>> +
>> + dma: dma@1f27 {
>> + compatible = "apm,xgene-storm-dma";
>> + device_type = "dma";
>> + reg = <0x0 0x1f27 0x0 0x1>,
>> +   <0x0 0x1f20 0x0 0x1>,
>> +   <0x0 0x1b008000 0x0 0x2000>,
>> +   <0x0 0x1054a000 0x0 0x100>;
>> + interrupts = <0x0 0x82 0x4>,
>> +  <0x0 0xb8 0x4>,
>> +  <0x0 0xb9 0x4>,
>> +  <0x0 0xba 0x4>,
>> +  <0x0 0xbb 0x4>;
>> + dma-coherent;
>> + clocks = < 0>;
>> + };
>> --
>> 1.8.2.1
>>
>
> --
--
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 v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,


On Mon, Mar 16, 2015 at 2:57 PM, Vinod Koul  wrote:
> On Thu, Mar 12, 2015 at 04:45:19PM +0530, Rameshwar Prasad Sahu wrote:
>> +/* DMA ring csr registers and bit definations */
>> +#define DMA_RING_CONFIG  0x04
>> +#define DMA_RING_ENABLE  BIT(31)
>> +#define DMA_RING_ID  0x08
>> +#define DMA_RING_ID_SETUP(v) ((v) | BIT(31))
>> +#define DMA_RING_ID_BUF  0x0C
>> +#define DMA_RING_ID_BUF_SETUP(v) (((v) << 9) | BIT(21))
>> +#define DMA_RING_THRESLD0_SET1   0x30
>> +#define DMA_RING_THRESLD0_SET1_VAL   0X64
>> +#define DMA_RING_THRESLD1_SET1   0x34
>> +#define DMA_RING_THRESLD1_SET1_VAL   0xC8
>> +#define DMA_RING_HYSTERESIS  0x68
>> +#define DMA_RING_HYSTERESIS_VAL  0x
>> +#define DMA_RING_STATE   0x6C
>> +#define DMA_RING_STATE_WR_BASE   0x70
>> +#define DMA_RING_NE_INT_MODE 0x017C
>> +#define DMA_RING_NE_INT_MODE_SET(m, v)   \
>> + ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
>> +#define DMA_RING_NE_INT_MODE_RESET(m, v) \
>> + ((m) &= (~BIT(31 - (v
>> +#define DMA_RING_CLKEN   0xC208
>> +#define DMA_RING_SRST0xC200
>> +#define DMA_RING_MEM_RAM_SHUTDOWN0xD070
>> +#define DMA_RING_BLK_MEM_RDY 0xD074
>> +#define DMA_RING_BLK_MEM_RDY_VAL 0x
>> +#define DMA_RING_DESC_CNT(v) (((v) & 0x0001FFFE) >> 1)
>> +#define DMA_RING_ID_GET(owner, num)  (((owner) << 6) | (num))
>> +#define DMA_RING_DST_ID(v)   ((1 << 10) | (v))
>> +#define DMA_RING_CMD_OFFSET  0x2C
>> +#define DMA_RING_CMD_BASE_OFFSET(v)  ((v) << 6)
>> +#define DMA_RING_COHERENT_SET(m) (((u32 *)(m))[2] |= BIT(4))
>> +#define DMA_RING_ADDRL_SET(m, v) (((u32 *)(m))[2] |= (((v) >> 8) << 5))
>> +#define DMA_RING_ADDRH_SET(m, v) (((u32 *)(m))[3] |= ((v) >> 35))
>> +#define DMA_RING_ACCEPTLERR_SET(m)   (((u32 *)(m))[3] |= BIT(19))
>> +#define DMA_RING_SIZE_SET(m, v)  (((u32 *)(m))[3] |= ((v) << 
>> 23))
>> +#define DMA_RING_RECOMBBUF_SET(m)(((u32 *)(m))[3] |= BIT(27))
>> +#define DMA_RING_RECOMTIMEOUTL_SET(m)(((u32 *)(m))[3] |= (0x7 << 
>> 28))
>> +#define DMA_RING_RECOMTIMEOUTH_SET(m)(((u32 *)(m))[4] |= 0x3)
>> +#define DMA_RING_SELTHRSH_SET(m) (((u32 *)(m))[4] |= BIT(3))
>> +#define DMA_RING_TYPE_SET(m, v)  (((u32 *)(m))[4] |= ((v) << 
>> 19))
> These are very generic name as can conflicts, can you please namespace
> these...

Okay
>
>> +/* DMA device csr registers and bit definitions */
>> +#define DMA_IPBRR0x0
>> +#define DMA_DEV_ID_RD(v) ((v) & 0x0FFF)
>> +#define DMA_BUS_ID_RD(v) (((v) >> 12) & 3)
>> +#define DMA_REV_NO_RD(v) (((v) >> 14) & 3)
>> +#define DMA_GCR  0x10
>> +#define DMA_CH_SETUP(v)  ((v) = ((v) & ~0x000F) | 
>> 0x000AAFFF)
>> +#define DMA_ENABLE(v)((v) |= BIT(31))
>> +#define DMA_DISABLE(v)   ((v) &= ~BIT(31))
>> +#define DMA_RAID6_CONT   0x14
>> +#define DMA_RAID6_MULTI_CTRL(v)  ((v) << 24)
>> +#define DMA_INT  0x70
>> +#define DMA_INT_MASK 0x74
>> +#define DMA_INT_ALL_MASK 0x
>> +#define DMA_INT_ALL_UNMASK   0x0
>> +#define DMA_INT_MASK_SHIFT   0x14
>> +#define DMA_RING_INT0_MASK   0x90A0
>> +#define DMA_RING_INT1_MASK   0x90A8
>> +#define DMA_RING_INT2_MASK   0x90B0
>> +#define DMA_RING_INT3_MASK   0x90B8
>> +#define DMA_RING_INT4_MASK   0x90C0
>> +#define DMA_CFG_RING_WQ_ASSOC0x90E0
>> +#define DMA_ASSOC_RING_MNGR1 0x
>> +#define DMA_MEM_RAM_SHUTDOWN 0xD070
>> +#define DMA_BLK_MEM_RDY  0xD074
>> +#define DMA_BLK_MEM_RDY_VAL  0x
> same here and throughout the driver..
>

Okay...


>> +static void xgene_dma_free_descriptor(struct xgene_dma_chan *chan,
>> +   struct xgene_dma_desc_sw *desc)
>> +{
>> + list_del(>node);
>> + chan_dbg(chan, "LD %p free\n", desc);
>> + dma_pool_free(chan->desc_pool, desc, desc->tx.phys);
> where is the descriptor freed? Perhpas we can say clean rather than free
> here to not confuse...

xgene_dma_clean_completed_descriptor() is freeing the descriptor once
descriptor acked by client.
This is in the completion path.

>
>> +}
>> +
>> +static struct xgene_dma_desc_sw *xgene_dma_alloc_descriptor(
>> +  struct xgene_dma_chan *chan)
>> +{
>> + struct xgene_dma_desc_sw *desc;
>> + dma_addr_t phys;
>> +
>> + desc = dma_pool_alloc(chan->desc_pool, GFP_NOWAIT, );
>> + if (!desc) {
>> + chan_dbg(chan, "Failed to allocate LDs\n");
> not error?

Yes it's error only by lacking of dma 

Re: [PATCH v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,


On Mon, Mar 16, 2015 at 4:57 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Mon, Mar 16, 2015 at 04:00:22PM +0530, Rameshwar Sahu wrote:

  +static struct xgene_dma_desc_sw *xgene_dma_alloc_descriptor(
  +  struct xgene_dma_chan *chan)
  +{
  + struct xgene_dma_desc_sw *desc;
  + dma_addr_t phys;
  +
  + desc = dma_pool_alloc(chan-desc_pool, GFP_NOWAIT, phys);
  + if (!desc) {
  + chan_dbg(chan, Failed to allocate LDs\n);
  not error?

 Yes it's error only by lacking of dma memory, do I need to use dev_err
 to show the error msg ??
 yes

Okay fine.


 
  +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan *chan,
  +  struct list_head *list)
  do we really care about free order?

 Yes it start dellocation of descriptor by tail.
 and why by tail is not clear.

We can free allocated descriptor in forward order from head or in
reverse order, I just followed here fsldma.c driver.
Does this make sense ??



  where are you mapping dma buffers?

  I didn't get you here. Can you please explain me here what you mean.
 As per my understanding client should map the dma buffer and give the
 physical address and size to this callback prep routines.
 not for memcpy, that is true for slave transfers

 For mempcy the idea is that drivers will do buffer mapping

Still I am clear here, why memcpy will do buffer mapping, I see other
drivers and also async_memcpy.c , they only map it and pass mapped
physical dma address to driver.

Buffer mapping mean you here is dma_map_xxx ?? Am I correct.


  why are you calling this here, status check shouldnt do this...

 Okay, I will remove it.


  + spin_unlock_bh(chan-lock);
  + return DMA_IN_PROGRESS;
  residue here is size of transacation.

 We can't calculate here residue size. We don't have any controller
 register which will tell about remaining transaction size.
 Okay if you cant calculate residue why do we have this fn?

So basically case here for me is completion of dma descriptor
submitted to hw is not same as order of submission to hw.
So scenario coming in multithread running :e.g. let's assume we have
submitted two descriptors first has cookie 1001 and second has 1002,
now 1002 is completed first, so updated last_completed_cookie as 1002
but not yer checked for dma_tx_status, and then first cookie completes
and update last_completed_cookie as 1001, now second transaction check
for tx_status and it get DMA_IN_PROGRESS, because
last_completed_cookie(1001) is less than second transaction's
cookie(1002).

Due to this issue I am traversing that transaction in pending list and
running list, if not there means we are done.

Does this make sense??



  + }
  + }
  +
  + /* Check if this descriptor is in running queue */
  + list_for_each_entry(desc, chan-ld_running, node) {
  + if (desc-tx.cookie == cookie) {
  + /* Cleanup any running and executed descriptors */
  + xgene_dma_cleanup_descriptors(chan);
  ditto?

 Okay


  + spin_unlock_bh(chan-lock);
  + return dma_cookie_status(chan-dma_chan,
  +  cookie, txstate);
  and you havent touched txstate so what is the intent here...?

 txstate can filled by caller, so it may be NULL or not NULL, we are
 passing same.
 something seems very wrong here. Status should return the current satue of
 queried descriptor and if residue value in txstate, you seem to be doing
 something else, quotesion is what and why :)


Please see my above comment.
Thanks
 --
 ~Vinod

--
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 v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 16, 2015 at 2:57 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Mar 12, 2015 at 04:45:19PM +0530, Rameshwar Prasad Sahu wrote:
 +/* DMA ring csr registers and bit definations */
 +#define DMA_RING_CONFIG  0x04
 +#define DMA_RING_ENABLE  BIT(31)
 +#define DMA_RING_ID  0x08
 +#define DMA_RING_ID_SETUP(v) ((v) | BIT(31))
 +#define DMA_RING_ID_BUF  0x0C
 +#define DMA_RING_ID_BUF_SETUP(v) (((v)  9) | BIT(21))
 +#define DMA_RING_THRESLD0_SET1   0x30
 +#define DMA_RING_THRESLD0_SET1_VAL   0X64
 +#define DMA_RING_THRESLD1_SET1   0x34
 +#define DMA_RING_THRESLD1_SET1_VAL   0xC8
 +#define DMA_RING_HYSTERESIS  0x68
 +#define DMA_RING_HYSTERESIS_VAL  0x
 +#define DMA_RING_STATE   0x6C
 +#define DMA_RING_STATE_WR_BASE   0x70
 +#define DMA_RING_NE_INT_MODE 0x017C
 +#define DMA_RING_NE_INT_MODE_SET(m, v)   \
 + ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define DMA_RING_NE_INT_MODE_RESET(m, v) \
 + ((m) = (~BIT(31 - (v
 +#define DMA_RING_CLKEN   0xC208
 +#define DMA_RING_SRST0xC200
 +#define DMA_RING_MEM_RAM_SHUTDOWN0xD070
 +#define DMA_RING_BLK_MEM_RDY 0xD074
 +#define DMA_RING_BLK_MEM_RDY_VAL 0x
 +#define DMA_RING_DESC_CNT(v) (((v)  0x0001FFFE)  1)
 +#define DMA_RING_ID_GET(owner, num)  (((owner)  6) | (num))
 +#define DMA_RING_DST_ID(v)   ((1  10) | (v))
 +#define DMA_RING_CMD_OFFSET  0x2C
 +#define DMA_RING_CMD_BASE_OFFSET(v)  ((v)  6)
 +#define DMA_RING_COHERENT_SET(m) (((u32 *)(m))[2] |= BIT(4))
 +#define DMA_RING_ADDRL_SET(m, v) (((u32 *)(m))[2] |= (((v)  8)  5))
 +#define DMA_RING_ADDRH_SET(m, v) (((u32 *)(m))[3] |= ((v)  35))
 +#define DMA_RING_ACCEPTLERR_SET(m)   (((u32 *)(m))[3] |= BIT(19))
 +#define DMA_RING_SIZE_SET(m, v)  (((u32 *)(m))[3] |= ((v)  
 23))
 +#define DMA_RING_RECOMBBUF_SET(m)(((u32 *)(m))[3] |= BIT(27))
 +#define DMA_RING_RECOMTIMEOUTL_SET(m)(((u32 *)(m))[3] |= (0x7  
 28))
 +#define DMA_RING_RECOMTIMEOUTH_SET(m)(((u32 *)(m))[4] |= 0x3)
 +#define DMA_RING_SELTHRSH_SET(m) (((u32 *)(m))[4] |= BIT(3))
 +#define DMA_RING_TYPE_SET(m, v)  (((u32 *)(m))[4] |= ((v)  
 19))
 These are very generic name as can conflicts, can you please namespace
 these...

 +/* DMA device csr registers and bit definitions */
 +#define DMA_IPBRR0x0
 +#define DMA_DEV_ID_RD(v) ((v)  0x0FFF)
 +#define DMA_BUS_ID_RD(v) (((v)  12)  3)
 +#define DMA_REV_NO_RD(v) (((v)  14)  3)
 +#define DMA_GCR  0x10
 +#define DMA_CH_SETUP(v)  ((v) = ((v)  ~0x000F) | 
 0x000AAFFF)
 +#define DMA_ENABLE(v)((v) |= BIT(31))
 +#define DMA_DISABLE(v)   ((v) = ~BIT(31))
 +#define DMA_RAID6_CONT   0x14
 +#define DMA_RAID6_MULTI_CTRL(v)  ((v)  24)
 +#define DMA_INT  0x70
 +#define DMA_INT_MASK 0x74
 +#define DMA_INT_ALL_MASK 0x
 +#define DMA_INT_ALL_UNMASK   0x0
 +#define DMA_INT_MASK_SHIFT   0x14
 +#define DMA_RING_INT0_MASK   0x90A0
 +#define DMA_RING_INT1_MASK   0x90A8
 +#define DMA_RING_INT2_MASK   0x90B0
 +#define DMA_RING_INT3_MASK   0x90B8
 +#define DMA_RING_INT4_MASK   0x90C0
 +#define DMA_CFG_RING_WQ_ASSOC0x90E0
 +#define DMA_ASSOC_RING_MNGR1 0x
 +#define DMA_MEM_RAM_SHUTDOWN 0xD070
 +#define DMA_BLK_MEM_RDY  0xD074
 +#define DMA_BLK_MEM_RDY_VAL  0x
 same here and throughout the driver..

 +static void xgene_dma_free_descriptor(struct xgene_dma_chan *chan,
 +   struct xgene_dma_desc_sw *desc)
 +{
 + list_del(desc-node);
 + chan_dbg(chan, LD %p free\n, desc);
 + dma_pool_free(chan-desc_pool, desc, desc-tx.phys);
 where is the descriptor freed? Perhpas we can say clean rather than free
 here to not confuse...

 +}
 +
 +static struct xgene_dma_desc_sw *xgene_dma_alloc_descriptor(
 +  struct xgene_dma_chan *chan)
 +{
 + struct xgene_dma_desc_sw *desc;
 + dma_addr_t phys;
 +
 + desc = dma_pool_alloc(chan-desc_pool, GFP_NOWAIT, phys);
 + if (!desc) {
 + chan_dbg(chan, Failed to allocate LDs\n);
 not error?

 +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan *chan,
 +  struct list_head *list)
 do we really care about free order?

 +{
 + struct xgene_dma_desc_sw *desc, *_desc;
 +
 + list_for_each_entry_safe_reverse(desc, _desc, list, node)
 + xgene_dma_free_descriptor(chan, desc);
 +}
 +
 +static void 

Re: [PATCH v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,


On Mon, Mar 16, 2015 at 2:57 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Mar 12, 2015 at 04:45:19PM +0530, Rameshwar Prasad Sahu wrote:
 +/* DMA ring csr registers and bit definations */
 +#define DMA_RING_CONFIG  0x04
 +#define DMA_RING_ENABLE  BIT(31)
 +#define DMA_RING_ID  0x08
 +#define DMA_RING_ID_SETUP(v) ((v) | BIT(31))
 +#define DMA_RING_ID_BUF  0x0C
 +#define DMA_RING_ID_BUF_SETUP(v) (((v)  9) | BIT(21))
 +#define DMA_RING_THRESLD0_SET1   0x30
 +#define DMA_RING_THRESLD0_SET1_VAL   0X64
 +#define DMA_RING_THRESLD1_SET1   0x34
 +#define DMA_RING_THRESLD1_SET1_VAL   0xC8
 +#define DMA_RING_HYSTERESIS  0x68
 +#define DMA_RING_HYSTERESIS_VAL  0x
 +#define DMA_RING_STATE   0x6C
 +#define DMA_RING_STATE_WR_BASE   0x70
 +#define DMA_RING_NE_INT_MODE 0x017C
 +#define DMA_RING_NE_INT_MODE_SET(m, v)   \
 + ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define DMA_RING_NE_INT_MODE_RESET(m, v) \
 + ((m) = (~BIT(31 - (v
 +#define DMA_RING_CLKEN   0xC208
 +#define DMA_RING_SRST0xC200
 +#define DMA_RING_MEM_RAM_SHUTDOWN0xD070
 +#define DMA_RING_BLK_MEM_RDY 0xD074
 +#define DMA_RING_BLK_MEM_RDY_VAL 0x
 +#define DMA_RING_DESC_CNT(v) (((v)  0x0001FFFE)  1)
 +#define DMA_RING_ID_GET(owner, num)  (((owner)  6) | (num))
 +#define DMA_RING_DST_ID(v)   ((1  10) | (v))
 +#define DMA_RING_CMD_OFFSET  0x2C
 +#define DMA_RING_CMD_BASE_OFFSET(v)  ((v)  6)
 +#define DMA_RING_COHERENT_SET(m) (((u32 *)(m))[2] |= BIT(4))
 +#define DMA_RING_ADDRL_SET(m, v) (((u32 *)(m))[2] |= (((v)  8)  5))
 +#define DMA_RING_ADDRH_SET(m, v) (((u32 *)(m))[3] |= ((v)  35))
 +#define DMA_RING_ACCEPTLERR_SET(m)   (((u32 *)(m))[3] |= BIT(19))
 +#define DMA_RING_SIZE_SET(m, v)  (((u32 *)(m))[3] |= ((v)  
 23))
 +#define DMA_RING_RECOMBBUF_SET(m)(((u32 *)(m))[3] |= BIT(27))
 +#define DMA_RING_RECOMTIMEOUTL_SET(m)(((u32 *)(m))[3] |= (0x7  
 28))
 +#define DMA_RING_RECOMTIMEOUTH_SET(m)(((u32 *)(m))[4] |= 0x3)
 +#define DMA_RING_SELTHRSH_SET(m) (((u32 *)(m))[4] |= BIT(3))
 +#define DMA_RING_TYPE_SET(m, v)  (((u32 *)(m))[4] |= ((v)  
 19))
 These are very generic name as can conflicts, can you please namespace
 these...

Okay

 +/* DMA device csr registers and bit definitions */
 +#define DMA_IPBRR0x0
 +#define DMA_DEV_ID_RD(v) ((v)  0x0FFF)
 +#define DMA_BUS_ID_RD(v) (((v)  12)  3)
 +#define DMA_REV_NO_RD(v) (((v)  14)  3)
 +#define DMA_GCR  0x10
 +#define DMA_CH_SETUP(v)  ((v) = ((v)  ~0x000F) | 
 0x000AAFFF)
 +#define DMA_ENABLE(v)((v) |= BIT(31))
 +#define DMA_DISABLE(v)   ((v) = ~BIT(31))
 +#define DMA_RAID6_CONT   0x14
 +#define DMA_RAID6_MULTI_CTRL(v)  ((v)  24)
 +#define DMA_INT  0x70
 +#define DMA_INT_MASK 0x74
 +#define DMA_INT_ALL_MASK 0x
 +#define DMA_INT_ALL_UNMASK   0x0
 +#define DMA_INT_MASK_SHIFT   0x14
 +#define DMA_RING_INT0_MASK   0x90A0
 +#define DMA_RING_INT1_MASK   0x90A8
 +#define DMA_RING_INT2_MASK   0x90B0
 +#define DMA_RING_INT3_MASK   0x90B8
 +#define DMA_RING_INT4_MASK   0x90C0
 +#define DMA_CFG_RING_WQ_ASSOC0x90E0
 +#define DMA_ASSOC_RING_MNGR1 0x
 +#define DMA_MEM_RAM_SHUTDOWN 0xD070
 +#define DMA_BLK_MEM_RDY  0xD074
 +#define DMA_BLK_MEM_RDY_VAL  0x
 same here and throughout the driver..


Okay...


 +static void xgene_dma_free_descriptor(struct xgene_dma_chan *chan,
 +   struct xgene_dma_desc_sw *desc)
 +{
 + list_del(desc-node);
 + chan_dbg(chan, LD %p free\n, desc);
 + dma_pool_free(chan-desc_pool, desc, desc-tx.phys);
 where is the descriptor freed? Perhpas we can say clean rather than free
 here to not confuse...

xgene_dma_clean_completed_descriptor() is freeing the descriptor once
descriptor acked by client.
This is in the completion path.


 +}
 +
 +static struct xgene_dma_desc_sw *xgene_dma_alloc_descriptor(
 +  struct xgene_dma_chan *chan)
 +{
 + struct xgene_dma_desc_sw *desc;
 + dma_addr_t phys;
 +
 + desc = dma_pool_alloc(chan-desc_pool, GFP_NOWAIT, phys);
 + if (!desc) {
 + chan_dbg(chan, Failed to allocate LDs\n);
 not error?

Yes it's error only by lacking of dma memory, do I need to use dev_err
to show the error msg ??


 +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan *chan,
 +  struct list_head 

Re: [PATCH v7 3/3] Documentation: dma: Add APM X-Gene SoC DMA engine driver documentation

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 16, 2015 at 2:59 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Mar 12, 2015 at 04:45:21PM +0530, Rameshwar Prasad Sahu wrote:
 This patch adds device tree binding for APM X-Gene SoC DMA engine driver.
 The patch title should be to add the bindings and not Documentation

Got it, thanks

 --
 ~Vinod

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---
  .../devicetree/bindings/dma/apm-xgene-dma.txt  | 47 
 ++
  1 file changed, 47 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/dma/apm-xgene-dma.txt

 diff --git a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt 
 b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
 new file mode 100644
 index 000..d305876
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
 @@ -0,0 +1,47 @@
 +Applied Micro X-Gene SoC DMA nodes
 +
 +DMA nodes are defined to describe on-chip DMA interfaces in
 +APM X-Gene SoC.
 +
 +Required properties for DMA interfaces:
 +- compatible: Should be apm,xgene-dma.
 +- device_type: set to dma.
 +- reg: Address and length of the register set for the device.
 +  It contains the information of registers in the following order:
 +  1st - DMA control and status register address space.
 +  2nd - Descriptor ring control and status register address space.
 +  3rd - Descriptor ring command register address space.
 +  4th - Soc efuse register address space.
 +- interrupts: DMA has 5 interrupts sources. 1st interrupt is
 +  DMA error reporting interrupt. 2nd, 3rd, 4th and 5th interrupts
 +  are completion interrupts for each DMA channels.
 +- clocks: Reference to the clock entry.
 +
 +Optional properties:
 +- dma-coherent : Present if dma operations are coherent
 +
 +Example:
 + dmaclk: dmaclk@1f27c000 {
 + compatible = apm,xgene-device-clock;
 + #clock-cells = 1;
 + clocks = socplldiv2 0;
 + reg = 0x0 0x1f27c000 0x0 0x1000;
 + reg-names = csr-reg;
 + clock-output-names = dmaclk;
 + };
 +
 + dma: dma@1f27 {
 + compatible = apm,xgene-storm-dma;
 + device_type = dma;
 + reg = 0x0 0x1f27 0x0 0x1,
 +   0x0 0x1f20 0x0 0x1,
 +   0x0 0x1b008000 0x0 0x2000,
 +   0x0 0x1054a000 0x0 0x100;
 + interrupts = 0x0 0x82 0x4,
 +  0x0 0xb8 0x4,
 +  0x0 0xb9 0x4,
 +  0x0 0xba 0x4,
 +  0x0 0xbb 0x4;
 + dma-coherent;
 + clocks = dmaclk 0;
 + };
 --
 1.8.2.1


 --
--
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 v7 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

On Mon, Mar 16, 2015 at 9:56 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Mon, Mar 16, 2015 at 05:24:34PM +0530, Rameshwar Sahu wrote:
   +static void xgene_dma_free_desc_list_reverse(struct xgene_dma_chan 
   *chan,
   +  struct list_head *list)
   do we really care about free order?
 
  Yes it start dellocation of descriptor by tail.
  and why by tail is not clear.
 We can free allocated descriptor in forward order from head or in
 reverse order, I just followed here fsldma.c driver.
 Does this make sense ??
 No, you have two APIs to free list. Why do you need two?

Yes, basically we have tow API to free list.
xgene_dma_free_desc_list_reverse will call if any failure in
allocation of memory from DMA pool in prep routines.
Like e.g. in prep routing we have some descriptors allocated and still
need to get descriptor to complete the DMA request and failure happen,
so we need to free all allocated descriptor.




 
   where are you mapping dma buffers?
 
   I didn't get you here. Can you please explain me here what you mean.
  As per my understanding client should map the dma buffer and give the
  physical address and size to this callback prep routines.
  not for memcpy, that is true for slave transfers
 
  For mempcy the idea is that drivers will do buffer mapping

 Still I am clear here, why memcpy will do buffer mapping, I see other
 drivers and also async_memcpy.c , they only map it and pass mapped
 physical dma address to driver.

 Buffer mapping mean you here is dma_map_xxx ?? Am I correct.
 Yes

I have confusion here, I don't see any driver dma buffer mapping in
prep_dma_memcpy.
Can you please clear me here if driver does this on behalf of client,
like any example so that I can proceed further.


 
   why are you calling this here, status check shouldnt do this...
 
  Okay, I will remove it.
 
 
   + spin_unlock_bh(chan-lock);
   + return DMA_IN_PROGRESS;
   residue here is size of transacation.
 
  We can't calculate here residue size. We don't have any controller
  register which will tell about remaining transaction size.
  Okay if you cant calculate residue why do we have this fn?

 So basically case here for me is completion of dma descriptor
 submitted to hw is not same as order of submission to hw.
 So scenario coming in multithread running :e.g. let's assume we have
 submitted two descriptors first has cookie 1001 and second has 1002,
 now 1002 is completed first, so updated last_completed_cookie as 1002
 but not yer checked for dma_tx_status, and then first cookie completes
 and update last_completed_cookie as 1001, now second transaction check
 for tx_status and it get DMA_IN_PROGRESS, because
 last_completed_cookie(1001) is less than second transaction's
 cookie(1002).

 Due to this issue I am traversing that transaction in pending list and
 running list, if not there means we are done.

 Does this make sense??
 That only convinces me that there is something not so correct.

 To help me understand pls let me know if below is fine:
 - for a physical channel, do you submit multiple transactions?

Yes

 - if yes, how does DMA deal with multiple transactions, how does it schedule
   them?

So , basically we submit multiple descriptor to dma physical channel,
and dma engine execute it one by one and give us completion callback.
So in this way we expect callback on same order as submission order
and it does also, no issue.

But problem is with supporting p+q offload, here we have P
functionality supports in dma physical channel 0 and Q functionality
supports in dma physical channel 1. So for pq we need to submit two
descriptor, one to channel 0 and second to channel1, in this case we
can't expect the completion order, because channnel 0 can finish P
before Q or vice versa, and we need to wait to complete both before
calling client callback() and completing cookie.
Second thing we submit memcpy and sg on same channel, and can complete
before even though if it submitted after PQ.


 --
 ~Vinod
 --
 To unsubscribe from this list: send the line unsubscribe dmaengine in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi


On Fri, Feb 27, 2015 at 9:39 AM, Rameshwar Sahu  wrote:
> Hi,
>
>
> On Thu, Feb 26, 2015 at 7:55 PM, Ben Dooks  wrote:
>> On 26/02/15 12:31, Rameshwar Sahu wrote:
>>> Hi Vinod,
>>>
>>>
>>> On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu  
>>> wrote:
>>>> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
>>>> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
>>>> These DMA operations include memory copy and scatter-gather memory copy
>>>> offloading.
>>>>
>>>> Signed-off-by: Rameshwar Prasad Sahu 
>>>> Signed-off-by: Loc Ho 
>>>> ---
>>>>  drivers/dma/Kconfig |8 +
>>>>  drivers/dma/Makefile|1 +
>>>>  drivers/dma/xgene-dma.c | 1738 
>>>> +++
>>>>  3 files changed, 1747 insertions(+)
>>>>  create mode 100755 drivers/dma/xgene-dma.c
>>>>
>>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>>> index a874b6e..0e05831 100644
>>>> --- a/drivers/dma/Kconfig
>>>> +++ b/drivers/dma/Kconfig
>>>> @@ -425,6 +425,14 @@ config IMG_MDC_DMA
>>>> help
>>>>   Enable support for the IMG multi-threaded DMA controller (MDC).
>>>>
>>>> +config XGENE_DMA
>>>> +   tristate "APM X-Gene DMA support"
>>>> +   depends on ARCH_XGENE
>>>> +   select DMA_ENGINE
>>>> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>>> +   help
>>>> + Enable support for the APM X-Gene SoC DMA engine.
>>>> +
>>>>  config DMA_ENGINE
>>>> bool
>>>>
>>>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>>>> index f915f61..06c1576 100644
>>>> --- a/drivers/dma/Makefile
>>>> +++ b/drivers/dma/Makefile
>>>> @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>>>>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>>>>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>>>>  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
>>>> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
>>>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>>>> new file mode 100755
>>>> index 000..e736c2e
>>>> --- /dev/null
>>>> +++ b/drivers/dma/xgene-dma.c
>>>> @@ -0,0 +1,1738 @@
>>>> +/*
>>>> + * Applied Micro X-Gene SoC DMA engine Driver
>>>> + *
>>>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>>>> + * Authors: Rameshwar Prasad Sahu 
>>>> + * Loc Ho 
>>>> + *
>>>> + * 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;  either version 2 of the  License, or (at 
>>>> your
>>>> + * option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>> + *
>>>> + * NOTE: PM support is currently not available.
>>>> + */
>>>> +
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#include "dmaengine.h"
>>>> +
>>>> +/* DMA ring csr registers and bit definations */
>>>> +#define DMA_RING_CONFIG0x04
>>>> +#define DMA_RING_ENABLEBIT(31)
>>>> +#define DMA_RING_ID0x08
>>>> +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
>>>> +#define DMA_RING_ID_BUF0x0C
>>>> +#define DMA_RING_ID_BUF_SETUP(v)   (((v) << 9) | BIT(21))
>>>> +#define DMA_R

Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi,


On Thu, Feb 26, 2015 at 7:55 PM, Ben Dooks  wrote:
> On 26/02/15 12:31, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>>
>> On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu  wrote:
>>> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
>>> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
>>> These DMA operations include memory copy and scatter-gather memory copy
>>> offloading.
>>>
>>> Signed-off-by: Rameshwar Prasad Sahu 
>>> Signed-off-by: Loc Ho 
>>> ---
>>>  drivers/dma/Kconfig |8 +
>>>  drivers/dma/Makefile|1 +
>>>  drivers/dma/xgene-dma.c | 1738 
>>> +++
>>>  3 files changed, 1747 insertions(+)
>>>  create mode 100755 drivers/dma/xgene-dma.c
>>>
>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>> index a874b6e..0e05831 100644
>>> --- a/drivers/dma/Kconfig
>>> +++ b/drivers/dma/Kconfig
>>> @@ -425,6 +425,14 @@ config IMG_MDC_DMA
>>> help
>>>   Enable support for the IMG multi-threaded DMA controller (MDC).
>>>
>>> +config XGENE_DMA
>>> +   tristate "APM X-Gene DMA support"
>>> +   depends on ARCH_XGENE
>>> +   select DMA_ENGINE
>>> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>> +   help
>>> + Enable support for the APM X-Gene SoC DMA engine.
>>> +
>>>  config DMA_ENGINE
>>> bool
>>>
>>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>>> index f915f61..06c1576 100644
>>> --- a/drivers/dma/Makefile
>>> +++ b/drivers/dma/Makefile
>>> @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>>>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>>>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>>>  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
>>> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
>>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>>> new file mode 100755
>>> index 000..e736c2e
>>> --- /dev/null
>>> +++ b/drivers/dma/xgene-dma.c
>>> @@ -0,0 +1,1738 @@
>>> +/*
>>> + * Applied Micro X-Gene SoC DMA engine Driver
>>> + *
>>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>>> + * Authors: Rameshwar Prasad Sahu 
>>> + * Loc Ho 
>>> + *
>>> + * 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;  either version 2 of the  License, or (at your
>>> + * option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>> + *
>>> + * NOTE: PM support is currently not available.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include "dmaengine.h"
>>> +
>>> +/* DMA ring csr registers and bit definations */
>>> +#define DMA_RING_CONFIG0x04
>>> +#define DMA_RING_ENABLEBIT(31)
>>> +#define DMA_RING_ID0x08
>>> +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
>>> +#define DMA_RING_ID_BUF0x0C
>>> +#define DMA_RING_ID_BUF_SETUP(v)   (((v) << 9) | BIT(21))
>>> +#define DMA_RING_THRESLD0_SET1 0x30
>>> +#define DMA_RING_THRESLD0_SET1_VAL 0X64
>>> +#define DMA_RING_THRESLD1_SET1 0x34
>>> +#define DMA_RING_THRESLD1_SET1_VAL 0xC8
>>> +#define DMA_RING_HYSTERESIS0x68
>>> +#define DMA_RING_HYSTERESIS_VAL0x
>>> +#define DMA_RING_STATE 0x6C
>>> +#define DMA_RING_STATE_WR_BASE 0x70
>>> +#define DMA_RING_NE_INT_MODE   0x017C
>>> +#define DMA_RIN

Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,


On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu  wrote:
> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
> These DMA operations include memory copy and scatter-gather memory copy
> offloading.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> Signed-off-by: Loc Ho 
> ---
>  drivers/dma/Kconfig |8 +
>  drivers/dma/Makefile|1 +
>  drivers/dma/xgene-dma.c | 1738 
> +++
>  3 files changed, 1747 insertions(+)
>  create mode 100755 drivers/dma/xgene-dma.c
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index a874b6e..0e05831 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -425,6 +425,14 @@ config IMG_MDC_DMA
> help
>   Enable support for the IMG multi-threaded DMA controller (MDC).
>
> +config XGENE_DMA
> +   tristate "APM X-Gene DMA support"
> +   depends on ARCH_XGENE
> +   select DMA_ENGINE
> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
> +   help
> + Enable support for the APM X-Gene SoC DMA engine.
> +
>  config DMA_ENGINE
> bool
>
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index f915f61..06c1576 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> new file mode 100755
> index 000..e736c2e
> --- /dev/null
> +++ b/drivers/dma/xgene-dma.c
> @@ -0,0 +1,1738 @@
> +/*
> + * Applied Micro X-Gene SoC DMA engine Driver
> + *
> + * Copyright (c) 2015, Applied Micro Circuits Corporation
> + * Authors: Rameshwar Prasad Sahu 
> + * Loc Ho 
> + *
> + * 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;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + * NOTE: PM support is currently not available.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "dmaengine.h"
> +
> +/* DMA ring csr registers and bit definations */
> +#define DMA_RING_CONFIG0x04
> +#define DMA_RING_ENABLEBIT(31)
> +#define DMA_RING_ID0x08
> +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
> +#define DMA_RING_ID_BUF0x0C
> +#define DMA_RING_ID_BUF_SETUP(v)   (((v) << 9) | BIT(21))
> +#define DMA_RING_THRESLD0_SET1 0x30
> +#define DMA_RING_THRESLD0_SET1_VAL 0X64
> +#define DMA_RING_THRESLD1_SET1 0x34
> +#define DMA_RING_THRESLD1_SET1_VAL 0xC8
> +#define DMA_RING_HYSTERESIS0x68
> +#define DMA_RING_HYSTERESIS_VAL0x
> +#define DMA_RING_STATE 0x6C
> +#define DMA_RING_STATE_WR_BASE 0x70
> +#define DMA_RING_NE_INT_MODE   0x017C
> +#define DMA_RING_NE_INT_MODE_SET(m, v) \
> +   ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
> +#define DMA_RING_NE_INT_MODE_RESET(m, v)   \
> +   ((m) &= (~BIT(31 - (v
> +#define DMA_RING_CLKEN 0xC208
> +#define DMA_RING_SRST  0xC200
> +#define DMA_RING_MEM_RAM_SHUTDOWN  0xD070
> +#define DMA_RING_BLK_MEM_RDY   0xD074
> +#define DMA_RING_BLK_MEM_RDY_VAL   0x
> +#define DMA_RING_DESC_CNT(v)   (((v) & 0x0001FFFE) >> 1)
> +#define DMA_RING_ID_GET(owner, num)(((owner) << 6) | (num))
> +#define DMA_RING_DST_ID(v) ((1 << 10) | (v))
> +#define DMA_RING_CMD_OFFSET0x2C
> +#define DMA_RING_CMD_BASE_OFFSET(v)((v) << 6)
> +#define DMA_RING_COHERENT_SET(m)   (((u32 *)(m))[2] |= BIT(4))
> +#define DMA_RING_ADDRL_SET(m, v)   (((u32 *)(m))[2] |= (((v) >> 8) << 5))
> +#define DMA_RING_ADDRH_SET(m, v)   (((u32 *)(m))[3] |= ((v) >> 35))
> +#define DMA_RING_ACCEPTLERR_SET(m) (((u32 *)(m))[3] |= BIT(19))
> +#define DMA_RING_SIZE_SET(m, v)(((u32 *)(m))[3] |= ((v) << 
> 23))
> +#define DMA_RING_RECOMBBUF_SET(m)  (((u32 *)(m))[3] |= BIT(27))
> +#define DMA_RING_RECOMTIMEOUTL_SET(m)  (((u32 *)(m))[3] |= (0x7 << 28))
> +#define 

Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi


On Fri, Feb 27, 2015 at 9:39 AM, Rameshwar Sahu rs...@apm.com wrote:
 Hi,


 On Thu, Feb 26, 2015 at 7:55 PM, Ben Dooks ben.do...@codethink.co.uk wrote:
 On 26/02/15 12:31, Rameshwar Sahu wrote:
 Hi Vinod,


 On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu rs...@apm.com 
 wrote:
 This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy and scatter-gather memory copy
 offloading.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---
  drivers/dma/Kconfig |8 +
  drivers/dma/Makefile|1 +
  drivers/dma/xgene-dma.c | 1738 
 +++
  3 files changed, 1747 insertions(+)
  create mode 100755 drivers/dma/xgene-dma.c

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index a874b6e..0e05831 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -425,6 +425,14 @@ config IMG_MDC_DMA
 help
   Enable support for the IMG multi-threaded DMA controller (MDC).

 +config XGENE_DMA
 +   tristate APM X-Gene DMA support
 +   depends on ARCH_XGENE
 +   select DMA_ENGINE
 +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
 +   help
 + Enable support for the APM X-Gene SoC DMA engine.
 +
  config DMA_ENGINE
 bool

 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index f915f61..06c1576 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
 +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 new file mode 100755
 index 000..e736c2e
 --- /dev/null
 +++ b/drivers/dma/xgene-dma.c
 @@ -0,0 +1,1738 @@
 +/*
 + * Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2015, Applied Micro Circuits Corporation
 + * Authors: Rameshwar Prasad Sahu rs...@apm.com
 + * Loc Ho l...@apm.com
 + *
 + * 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;  either version 2 of the  License, or (at 
 your
 + * option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + *
 + * NOTE: PM support is currently not available.
 + */
 +
 +#include linux/clk.h
 +#include linux/delay.h
 +#include linux/dma-mapping.h
 +#include linux/dmaengine.h
 +#include linux/dmapool.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_device.h
 +
 +#include dmaengine.h
 +
 +/* DMA ring csr registers and bit definations */
 +#define DMA_RING_CONFIG0x04
 +#define DMA_RING_ENABLEBIT(31)
 +#define DMA_RING_ID0x08
 +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
 +#define DMA_RING_ID_BUF0x0C
 +#define DMA_RING_ID_BUF_SETUP(v)   (((v)  9) | BIT(21))
 +#define DMA_RING_THRESLD0_SET1 0x30
 +#define DMA_RING_THRESLD0_SET1_VAL 0X64
 +#define DMA_RING_THRESLD1_SET1 0x34
 +#define DMA_RING_THRESLD1_SET1_VAL 0xC8
 +#define DMA_RING_HYSTERESIS0x68
 +#define DMA_RING_HYSTERESIS_VAL0x
 +#define DMA_RING_STATE 0x6C
 +#define DMA_RING_STATE_WR_BASE 0x70
 +#define DMA_RING_NE_INT_MODE   0x017C
 +#define DMA_RING_NE_INT_MODE_SET(m, v) \
 +   ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define DMA_RING_NE_INT_MODE_RESET(m, v)   \
 +   ((m) = (~BIT(31 - (v
 +#define DMA_RING_CLKEN 0xC208
 +#define DMA_RING_SRST  0xC200
 +#define DMA_RING_MEM_RAM_SHUTDOWN  0xD070
 +#define DMA_RING_BLK_MEM_RDY   0xD074
 +#define DMA_RING_BLK_MEM_RDY_VAL   0x
 +#define DMA_RING_DESC_CNT(v)   (((v)  0x0001FFFE)  1)
 +#define DMA_RING_ID_GET(owner, num)(((owner)  6) | (num))
 +#define DMA_RING_DST_ID(v) ((1  10) | (v))
 +#define DMA_RING_CMD_OFFSET0x2C
 +#define DMA_RING_CMD_BASE_OFFSET(v)((v)  6)
 +#define DMA_RING_COHERENT_SET(m)   (((u32 *)(m))[2] |= BIT(4))
 +#define DMA_RING_ADDRL_SET(m, v)   (((u32 *)(m))[2] |= (((v)  8)  
 5))
 +#define DMA_RING_ADDRH_SET(m, v)   (((u32 *)(m))[3] |= ((v)  35))
 +#define DMA_RING_ACCEPTLERR_SET(m) (((u32 *)(m))[3] |= BIT(19

Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,


On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy and scatter-gather memory copy
 offloading.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---
  drivers/dma/Kconfig |8 +
  drivers/dma/Makefile|1 +
  drivers/dma/xgene-dma.c | 1738 
 +++
  3 files changed, 1747 insertions(+)
  create mode 100755 drivers/dma/xgene-dma.c

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index a874b6e..0e05831 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -425,6 +425,14 @@ config IMG_MDC_DMA
 help
   Enable support for the IMG multi-threaded DMA controller (MDC).

 +config XGENE_DMA
 +   tristate APM X-Gene DMA support
 +   depends on ARCH_XGENE
 +   select DMA_ENGINE
 +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
 +   help
 + Enable support for the APM X-Gene SoC DMA engine.
 +
  config DMA_ENGINE
 bool

 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index f915f61..06c1576 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
 +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 new file mode 100755
 index 000..e736c2e
 --- /dev/null
 +++ b/drivers/dma/xgene-dma.c
 @@ -0,0 +1,1738 @@
 +/*
 + * Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2015, Applied Micro Circuits Corporation
 + * Authors: Rameshwar Prasad Sahu rs...@apm.com
 + * Loc Ho l...@apm.com
 + *
 + * 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;  either version 2 of the  License, or (at your
 + * option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + *
 + * NOTE: PM support is currently not available.
 + */
 +
 +#include linux/clk.h
 +#include linux/delay.h
 +#include linux/dma-mapping.h
 +#include linux/dmaengine.h
 +#include linux/dmapool.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_device.h
 +
 +#include dmaengine.h
 +
 +/* DMA ring csr registers and bit definations */
 +#define DMA_RING_CONFIG0x04
 +#define DMA_RING_ENABLEBIT(31)
 +#define DMA_RING_ID0x08
 +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
 +#define DMA_RING_ID_BUF0x0C
 +#define DMA_RING_ID_BUF_SETUP(v)   (((v)  9) | BIT(21))
 +#define DMA_RING_THRESLD0_SET1 0x30
 +#define DMA_RING_THRESLD0_SET1_VAL 0X64
 +#define DMA_RING_THRESLD1_SET1 0x34
 +#define DMA_RING_THRESLD1_SET1_VAL 0xC8
 +#define DMA_RING_HYSTERESIS0x68
 +#define DMA_RING_HYSTERESIS_VAL0x
 +#define DMA_RING_STATE 0x6C
 +#define DMA_RING_STATE_WR_BASE 0x70
 +#define DMA_RING_NE_INT_MODE   0x017C
 +#define DMA_RING_NE_INT_MODE_SET(m, v) \
 +   ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define DMA_RING_NE_INT_MODE_RESET(m, v)   \
 +   ((m) = (~BIT(31 - (v
 +#define DMA_RING_CLKEN 0xC208
 +#define DMA_RING_SRST  0xC200
 +#define DMA_RING_MEM_RAM_SHUTDOWN  0xD070
 +#define DMA_RING_BLK_MEM_RDY   0xD074
 +#define DMA_RING_BLK_MEM_RDY_VAL   0x
 +#define DMA_RING_DESC_CNT(v)   (((v)  0x0001FFFE)  1)
 +#define DMA_RING_ID_GET(owner, num)(((owner)  6) | (num))
 +#define DMA_RING_DST_ID(v) ((1  10) | (v))
 +#define DMA_RING_CMD_OFFSET0x2C
 +#define DMA_RING_CMD_BASE_OFFSET(v)((v)  6)
 +#define DMA_RING_COHERENT_SET(m)   (((u32 *)(m))[2] |= BIT(4))
 +#define DMA_RING_ADDRL_SET(m, v)   (((u32 *)(m))[2] |= (((v)  8)  5))
 +#define DMA_RING_ADDRH_SET(m, v)   (((u32 *)(m))[3] |= ((v)  35))
 +#define DMA_RING_ACCEPTLERR_SET(m) (((u32 *)(m))[3] |= BIT(19))
 +#define DMA_RING_SIZE_SET(m, v)(((u32 *)(m))[3] |= ((v)  
 23))
 +#define DMA_RING_RECOMBBUF_SET(m)  (((u32 *)(m))[3] |= BIT(27))
 +#define DMA_RING_RECOMTIMEOUTL_SET(m)  (((u32 *)(m))[3] |= 

Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi,


On Thu, Feb 26, 2015 at 7:55 PM, Ben Dooks ben.do...@codethink.co.uk wrote:
 On 26/02/15 12:31, Rameshwar Sahu wrote:
 Hi Vinod,


 On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy and scatter-gather memory copy
 offloading.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---
  drivers/dma/Kconfig |8 +
  drivers/dma/Makefile|1 +
  drivers/dma/xgene-dma.c | 1738 
 +++
  3 files changed, 1747 insertions(+)
  create mode 100755 drivers/dma/xgene-dma.c

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index a874b6e..0e05831 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -425,6 +425,14 @@ config IMG_MDC_DMA
 help
   Enable support for the IMG multi-threaded DMA controller (MDC).

 +config XGENE_DMA
 +   tristate APM X-Gene DMA support
 +   depends on ARCH_XGENE
 +   select DMA_ENGINE
 +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
 +   help
 + Enable support for the APM X-Gene SoC DMA engine.
 +
  config DMA_ENGINE
 bool

 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index f915f61..06c1576 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
 +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 new file mode 100755
 index 000..e736c2e
 --- /dev/null
 +++ b/drivers/dma/xgene-dma.c
 @@ -0,0 +1,1738 @@
 +/*
 + * Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2015, Applied Micro Circuits Corporation
 + * Authors: Rameshwar Prasad Sahu rs...@apm.com
 + * Loc Ho l...@apm.com
 + *
 + * 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;  either version 2 of the  License, or (at your
 + * option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + *
 + * NOTE: PM support is currently not available.
 + */
 +
 +#include linux/clk.h
 +#include linux/delay.h
 +#include linux/dma-mapping.h
 +#include linux/dmaengine.h
 +#include linux/dmapool.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_device.h
 +
 +#include dmaengine.h
 +
 +/* DMA ring csr registers and bit definations */
 +#define DMA_RING_CONFIG0x04
 +#define DMA_RING_ENABLEBIT(31)
 +#define DMA_RING_ID0x08
 +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
 +#define DMA_RING_ID_BUF0x0C
 +#define DMA_RING_ID_BUF_SETUP(v)   (((v)  9) | BIT(21))
 +#define DMA_RING_THRESLD0_SET1 0x30
 +#define DMA_RING_THRESLD0_SET1_VAL 0X64
 +#define DMA_RING_THRESLD1_SET1 0x34
 +#define DMA_RING_THRESLD1_SET1_VAL 0xC8
 +#define DMA_RING_HYSTERESIS0x68
 +#define DMA_RING_HYSTERESIS_VAL0x
 +#define DMA_RING_STATE 0x6C
 +#define DMA_RING_STATE_WR_BASE 0x70
 +#define DMA_RING_NE_INT_MODE   0x017C
 +#define DMA_RING_NE_INT_MODE_SET(m, v) \
 +   ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define DMA_RING_NE_INT_MODE_RESET(m, v)   \
 +   ((m) = (~BIT(31 - (v
 +#define DMA_RING_CLKEN 0xC208
 +#define DMA_RING_SRST  0xC200
 +#define DMA_RING_MEM_RAM_SHUTDOWN  0xD070
 +#define DMA_RING_BLK_MEM_RDY   0xD074
 +#define DMA_RING_BLK_MEM_RDY_VAL   0x
 +#define DMA_RING_DESC_CNT(v)   (((v)  0x0001FFFE)  1)
 +#define DMA_RING_ID_GET(owner, num)(((owner)  6) | (num))
 +#define DMA_RING_DST_ID(v) ((1  10) | (v))
 +#define DMA_RING_CMD_OFFSET0x2C
 +#define DMA_RING_CMD_BASE_OFFSET(v)((v)  6)
 +#define DMA_RING_COHERENT_SET(m)   (((u32 *)(m))[2] |= BIT(4))
 +#define DMA_RING_ADDRL_SET(m, v)   (((u32 *)(m))[2] |= (((v)  8)  
 5))
 +#define DMA_RING_ADDRH_SET(m, v)   (((u32 *)(m))[3] |= ((v)  35))
 +#define DMA_RING_ACCEPTLERR_SET(m) (((u32 *)(m))[3] |= BIT(19))
 +#define DMA_RING_SIZE_SET(m, v)(((u32 *)(m))[3] |= ((v)  
 23

Re: [PATCH v5 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,


On Fri, Feb 6, 2015 at 1:41 AM, Vinod Koul  wrote:
> On Thu, Feb 05, 2015 at 05:29:06PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> Thanks for reviewing this patch.
>>
>> Please see inline..
> Please STOP top posting
>
>> >
>> >> +}
>> >> +
>> >> +static void xgene_dma_issue_pending(struct dma_chan *channel)
>> >> +{
>> >> + /* Nothing to do */
>> >> +}
>> > What do you mean by nothing to do here
>> > See Documentation/dmaengine/client.txt Section 4 & 5
>> This docs is only applicable on slave DMA operations, we don't support
>> slave DMA, it's only master.
>> Our hw engine is designed in the way that there is no scope of
>> flushing pending transaction explicitly by sw.
>> We have circular ring descriptor dedicated to engine. In submit
>> callback  we are queuing descriptor and informing to engine, so after
>> this it's internal to hw to execute descriptor one by one.
> But the API expectations on this are _same_
>
> No the API expects you to maintain a SW queue, then push to your ring buffer
> when you get issue_pending. Issue pending is the start of data transfer, you
> client will expect accordingly.

Okay, I will maintain a sw queue, and will push sw descriptor to hw in
this callback.
>
>> >> + /* Run until we are out of length */
>> >> + do {
>> >> + /* Create the largest transaction possible */
>> >> + copy = min_t(size_t, len, DMA_MAX_64BDSC_BYTE_CNT);
>> >> +
>> >> + /* Prepare DMA descriptor */
>> >> + xgene_dma_prep_cpy_desc(chan, slot, dst, src, copy);
>> >> +
>> > This is wrong. The descriptor is supposed to be already prepared and now it
>> > has to be submitted to queue
>>
>> Due to the race in tx_submit call from the client, need to serialize
>> the submission of H/W DMA descriptors.
>>  So we are making  shadow copy in prepare DMA  routine and  preparing
>> actual descriptor during tx_submit call.
> Thats an abuse of API and I dont see a reason why this race should happen in
> the first place.
>
> So you get a prep call, you prepare a desc in SW. Then submit pushes it to a
> queue. Finally in issue pending you push them to HW. Simple..?

I agree, I will do it and post another version soon.
>
> --
> ~Vinod
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v5 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,


On Fri, Feb 6, 2015 at 1:41 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Feb 05, 2015 at 05:29:06PM +0530, Rameshwar Sahu wrote:
 Hi Vinod,

 Thanks for reviewing this patch.

 Please see inline..
 Please STOP top posting

 
  +}
  +
  +static void xgene_dma_issue_pending(struct dma_chan *channel)
  +{
  + /* Nothing to do */
  +}
  What do you mean by nothing to do here
  See Documentation/dmaengine/client.txt Section 4  5
 This docs is only applicable on slave DMA operations, we don't support
 slave DMA, it's only master.
 Our hw engine is designed in the way that there is no scope of
 flushing pending transaction explicitly by sw.
 We have circular ring descriptor dedicated to engine. In submit
 callback  we are queuing descriptor and informing to engine, so after
 this it's internal to hw to execute descriptor one by one.
 But the API expectations on this are _same_

 No the API expects you to maintain a SW queue, then push to your ring buffer
 when you get issue_pending. Issue pending is the start of data transfer, you
 client will expect accordingly.

Okay, I will maintain a sw queue, and will push sw descriptor to hw in
this callback.

  + /* Run until we are out of length */
  + do {
  + /* Create the largest transaction possible */
  + copy = min_t(size_t, len, DMA_MAX_64BDSC_BYTE_CNT);
  +
  + /* Prepare DMA descriptor */
  + xgene_dma_prep_cpy_desc(chan, slot, dst, src, copy);
  +
  This is wrong. The descriptor is supposed to be already prepared and now it
  has to be submitted to queue

 Due to the race in tx_submit call from the client, need to serialize
 the submission of H/W DMA descriptors.
  So we are making  shadow copy in prepare DMA  routine and  preparing
 actual descriptor during tx_submit call.
 Thats an abuse of API and I dont see a reason why this race should happen in
 the first place.

 So you get a prep call, you prepare a desc in SW. Then submit pushes it to a
 queue. Finally in issue pending you push them to HW. Simple..?

I agree, I will do it and post another version soon.

 --
 ~Vinod
 --
 To unsubscribe from this list: send the line unsubscribe dmaengine in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v5 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

Thanks for reviewing this patch.

Please see inline..


Thanks,
with regards,
Ram


On Thu, Feb 5, 2015 at 7:20 AM, Vinod Koul  wrote:
> On Tue, Feb 03, 2015 at 06:25:05PM +0530, Rameshwar Prasad Sahu wrote:
>> +/* Applied Micro X-Gene SoC DMA engine Driver
>> + *
>> + * Copyright (c) 2014, Applied Micro Circuits Corporation
> not 2015?
>> + * Authors: Rameshwar Prasad Sahu 
>> + *   Loc Ho 
>> + *
>
>> +/* DMA ring csr registers and bit definations */
>> +#define RING_CONFIG  0x04
>> +#define RING_ENABLE  BIT(31)
>> +#define RING_ID  0x08
>> +#define RING_ID_SETUP(v) ((v) | BIT(31))
>> +#define RING_ID_BUF  0x0C
>> +#define RING_ID_BUF_SETUP(v) (((v) << 9) | BIT(21))
>> +#define RING_THRESLD0_SET1   0x30
>> +#define RING_THRESLD0_SET1_VAL   0X64
>> +#define RING_THRESLD1_SET1   0x34
>> +#define RING_THRESLD1_SET1_VAL   0xC8
>> +#define RING_HYSTERESIS  0x68
>> +#define RING_HYSTERESIS_VAL  0x
>> +#define RING_STATE   0x6C
>> +#define RING_STATE_WR_BASE   0x70
>> +#define RING_NE_INT_MODE 0x017C
>> +#define RING_NE_INT_MODE_SET(m, v)   \
>> + ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
>> +#define RING_NE_INT_MODE_RESET(m, v) \
>> + ((m) &= (~BIT(31 - (v
>> +#define RING_CLKEN   0xC208
>> +#define RING_SRST0xC200
>> +#define RING_MEM_RAM_SHUTDOWN0xD070
>> +#define RING_BLK_MEM_RDY 0xD074
>> +#define RING_BLK_MEM_RDY_VAL 0x
>> +#define RING_ID_GET(owner, num)  (((owner) << 6) | (num))
>> +#define RING_DST_RING_ID(v)  ((1 << 10) | (v))
>> +#define RING_CMD_OFFSET(v)   (((v) << 6) + 0x2C)
>> +#define RING_COHERENT_SET(m) (((u32 *)(m))[2] |= BIT(4))
>> +#define RING_ADDRL_SET(m, v) (((u32 *)(m))[2] |= (((v) >> 8) << 5))
>> +#define RING_ADDRH_SET(m, v) (((u32 *)(m))[3] |= ((v) >> 35))
>> +#define RING_ACCEPTLERR_SET(m)   (((u32 *)(m))[3] |= BIT(19))
>> +#define RING_SIZE_SET(m, v)  (((u32 *)(m))[3] |= ((v) << 23))
>> +#define RING_RECOMBBUF_SET(m)(((u32 *)(m))[3] |= BIT(27))
>> +#define RING_RECOMTIMEOUTL_SET(m)\
>> + (((u32 *)(m))[3] |= (0x7 << 28))
>> +#define RING_RECOMTIMEOUTH_SET(m)\
>> + (((u32 *)(m))[4] |= 0x3)
>> +#define RING_SELTHRSH_SET(m) (((u32 *)(m))[4] |= BIT(3))
>> +#define RING_TYPE_SET(m, v)  (((u32 *)(m))[4] |= ((v) << 19))a
> these defines and the ones which follow need to be namespace aptly
>

Okay..

>> +static void xgene_dma_cpu_to_le64(u64 *desc, int count)
> why is this endian specific?

Our cpu supports both little endian and big endian,
Our DMA hw engine is little endian, so DMA engine descriptor needs to
be in little endian format .
>
>> +
>> +static irqreturn_t xgene_dma_ring_isr(int irq, void *id)
>> +{
>> + struct xgene_dma_chan *chan = (struct xgene_dma_chan *)id;
>> +
>> + BUG_ON(!chan);
>> +
>> + /* Disable DMA channel IRQ */
>> + disable_irq_nosync(chan->rx_irq);
>> +
>> + /* Schedule tasklet */
>> + tasklet_schedule(>rx_tasklet);
>> +
> Ideally you should submit next txn here, but...

Already we have pushed prepared descriptor to engine, so here this is
just rx path to get completion interrupt.

>
>> +
>> +static int xgene_dma_alloc_chan_resources(struct dma_chan *channel)
>> +{
>> + struct xgene_dma_chan *chan = to_xgene_dma_chan(channel);
>> + int i;
>> +
>> + /* Check if we have already allcated resources */
>> + if (chan->slots)
>> + return DMA_SLOT_PER_CHANNEL;
>> +
>> + spin_lock_bh(>lock);
>> +
>> + chan->slots = devm_kzalloc(chan->pdma->dev,
>> +sizeof(struct xgene_dma_slot) *
>> +DMA_SLOT_PER_CHANNEL, GFP_ATOMIC);
> GFP_NOWAIT pls
Okay GFP_KERNEL should also be ok ?
>
>> +
>> +static enum dma_status xgene_dma_tx_status(struct dma_chan *channel,
>> +dma_cookie_t cookie,
>> +struct dma_tx_state *txstate)
>> +{
>> + return dma_cookie_status(channel, cookie, txstate);
> why no residue calculation

We don't have way to pause, resume or stop DMA operation in DMA engine
hw once we have submitted descriptor to engine. While prep routine we
have prepared descriptor for whole requested length, so no need to
calculate residue.
>
>> +}
>> +
>> +static void xgene_dma_issue_pending(struct dma_chan *channel)
>> +{
>> + /* Nothing to do */
>> +}
> What do you mean by nothing to do here
> See Documentation/dmaengine/client.txt Section 4 & 5
This docs is only applicable on slave DMA operations, we don't support
slave DMA, it's only master.
Our hw engine is designed in the way that there is no scope of
flushing pending transaction explicitly by sw.
We have circular ring descriptor dedicated to engine. In submit
callback  we are queuing descriptor and informing to engine, so after
this it's internal to hw to execute descriptor one by one.

>
>
>> +static dma_cookie_t 

Re: [PATCH v5 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Vinod,

Thanks for reviewing this patch.

Please see inline..


Thanks,
with regards,
Ram


On Thu, Feb 5, 2015 at 7:20 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Tue, Feb 03, 2015 at 06:25:05PM +0530, Rameshwar Prasad Sahu wrote:
 +/* Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2014, Applied Micro Circuits Corporation
 not 2015?
 + * Authors: Rameshwar Prasad Sahu rs...@apm.com
 + *   Loc Ho l...@apm.com
 + *

 +/* DMA ring csr registers and bit definations */
 +#define RING_CONFIG  0x04
 +#define RING_ENABLE  BIT(31)
 +#define RING_ID  0x08
 +#define RING_ID_SETUP(v) ((v) | BIT(31))
 +#define RING_ID_BUF  0x0C
 +#define RING_ID_BUF_SETUP(v) (((v)  9) | BIT(21))
 +#define RING_THRESLD0_SET1   0x30
 +#define RING_THRESLD0_SET1_VAL   0X64
 +#define RING_THRESLD1_SET1   0x34
 +#define RING_THRESLD1_SET1_VAL   0xC8
 +#define RING_HYSTERESIS  0x68
 +#define RING_HYSTERESIS_VAL  0x
 +#define RING_STATE   0x6C
 +#define RING_STATE_WR_BASE   0x70
 +#define RING_NE_INT_MODE 0x017C
 +#define RING_NE_INT_MODE_SET(m, v)   \
 + ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define RING_NE_INT_MODE_RESET(m, v) \
 + ((m) = (~BIT(31 - (v
 +#define RING_CLKEN   0xC208
 +#define RING_SRST0xC200
 +#define RING_MEM_RAM_SHUTDOWN0xD070
 +#define RING_BLK_MEM_RDY 0xD074
 +#define RING_BLK_MEM_RDY_VAL 0x
 +#define RING_ID_GET(owner, num)  (((owner)  6) | (num))
 +#define RING_DST_RING_ID(v)  ((1  10) | (v))
 +#define RING_CMD_OFFSET(v)   (((v)  6) + 0x2C)
 +#define RING_COHERENT_SET(m) (((u32 *)(m))[2] |= BIT(4))
 +#define RING_ADDRL_SET(m, v) (((u32 *)(m))[2] |= (((v)  8)  5))
 +#define RING_ADDRH_SET(m, v) (((u32 *)(m))[3] |= ((v)  35))
 +#define RING_ACCEPTLERR_SET(m)   (((u32 *)(m))[3] |= BIT(19))
 +#define RING_SIZE_SET(m, v)  (((u32 *)(m))[3] |= ((v)  23))
 +#define RING_RECOMBBUF_SET(m)(((u32 *)(m))[3] |= BIT(27))
 +#define RING_RECOMTIMEOUTL_SET(m)\
 + (((u32 *)(m))[3] |= (0x7  28))
 +#define RING_RECOMTIMEOUTH_SET(m)\
 + (((u32 *)(m))[4] |= 0x3)
 +#define RING_SELTHRSH_SET(m) (((u32 *)(m))[4] |= BIT(3))
 +#define RING_TYPE_SET(m, v)  (((u32 *)(m))[4] |= ((v)  19))a
 these defines and the ones which follow need to be namespace aptly


Okay..

 +static void xgene_dma_cpu_to_le64(u64 *desc, int count)
 why is this endian specific?

Our cpu supports both little endian and big endian,
Our DMA hw engine is little endian, so DMA engine descriptor needs to
be in little endian format .

 +
 +static irqreturn_t xgene_dma_ring_isr(int irq, void *id)
 +{
 + struct xgene_dma_chan *chan = (struct xgene_dma_chan *)id;
 +
 + BUG_ON(!chan);
 +
 + /* Disable DMA channel IRQ */
 + disable_irq_nosync(chan-rx_irq);
 +
 + /* Schedule tasklet */
 + tasklet_schedule(chan-rx_tasklet);
 +
 Ideally you should submit next txn here, but...

Already we have pushed prepared descriptor to engine, so here this is
just rx path to get completion interrupt.


 +
 +static int xgene_dma_alloc_chan_resources(struct dma_chan *channel)
 +{
 + struct xgene_dma_chan *chan = to_xgene_dma_chan(channel);
 + int i;
 +
 + /* Check if we have already allcated resources */
 + if (chan-slots)
 + return DMA_SLOT_PER_CHANNEL;
 +
 + spin_lock_bh(chan-lock);
 +
 + chan-slots = devm_kzalloc(chan-pdma-dev,
 +sizeof(struct xgene_dma_slot) *
 +DMA_SLOT_PER_CHANNEL, GFP_ATOMIC);
 GFP_NOWAIT pls
Okay GFP_KERNEL should also be ok ?

 +
 +static enum dma_status xgene_dma_tx_status(struct dma_chan *channel,
 +dma_cookie_t cookie,
 +struct dma_tx_state *txstate)
 +{
 + return dma_cookie_status(channel, cookie, txstate);
 why no residue calculation

We don't have way to pause, resume or stop DMA operation in DMA engine
hw once we have submitted descriptor to engine. While prep routine we
have prepared descriptor for whole requested length, so no need to
calculate residue.

 +}
 +
 +static void xgene_dma_issue_pending(struct dma_chan *channel)
 +{
 + /* Nothing to do */
 +}
 What do you mean by nothing to do here
 See Documentation/dmaengine/client.txt Section 4  5
This docs is only applicable on slave DMA operations, we don't support
slave DMA, it's only master.
Our hw engine is designed in the way that there is no scope of
flushing pending transaction explicitly by sw.
We have circular ring descriptor dedicated to engine. In submit
callback  we are queuing descriptor and informing to engine, so after
this it's internal to hw to execute descriptor one by one.



 +static dma_cookie_t xgene_dma_tx_memcpy_submit(
 + struct dma_async_tx_descriptor *tx)
 +{
 + struct xgene_dma_chan *chan = to_xgene_dma_chan(tx-chan);
 + struct xgene_dma_slot *slot = 

Re: [PATCH v5 0/3] dmaengine: APM X-Gene SoC DMA engine driver support

[Rameshwar Sahu]

Hi Vinod,

Can you please review this patch set.


Thanks,
with regards,
Ram


On Tue, Feb 3, 2015 at 6:25 PM, Rameshwar Prasad Sahu  wrote:
> This patch set implements the APM X-Gene SoC DMA driver
> support to offload the DMA operations such as memory copy(memcpy),
> scatter gathering.
>
> v5 changes:
> 1. Minor changes in coding style.
> 2. Added DMA_CTRL_ACK flag initialization
> v4 changes:
> 1. Fixed dma-ranges property on DTS.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> Signed-off-by: Loc Ho 
> ---
>
> Rameshwar Prasad Sahu (3):
>   dmaengine: Add support for APM X-Gene SoC DMA engine driver
>   arm64: dts: Add APM X-Gene DMA device and DMA clock DTS nodes
>   Documentation: dma: Add APM X-Gene SoC DMA engine driver documentation
>
>  .../devicetree/bindings/dma/apm-xgene-dma.txt  |   49 +
>  arch/arm64/boot/dts/apm/apm-storm.dtsi |   26 +
>  drivers/dma/Kconfig|8 +
>  drivers/dma/Makefile   |1 +
>  drivers/dma/xgene-dma.c| 1597 
> 
>  5 files changed, 1681 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
>  create mode 100755 drivers/dma/xgene-dma.c
>
> --
> 1.8.2.1
>
--
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 v5 0/3] dmaengine: APM X-Gene SoC DMA engine driver support

[Rameshwar Sahu]

Hi Vinod,

Can you please review this patch set.


Thanks,
with regards,
Ram


On Tue, Feb 3, 2015 at 6:25 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch set implements the APM X-Gene SoC DMA driver
 support to offload the DMA operations such as memory copy(memcpy),
 scatter gathering.

 v5 changes:
 1. Minor changes in coding style.
 2. Added DMA_CTRL_ACK flag initialization
 v4 changes:
 1. Fixed dma-ranges property on DTS.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---

 Rameshwar Prasad Sahu (3):
   dmaengine: Add support for APM X-Gene SoC DMA engine driver
   arm64: dts: Add APM X-Gene DMA device and DMA clock DTS nodes
   Documentation: dma: Add APM X-Gene SoC DMA engine driver documentation

  .../devicetree/bindings/dma/apm-xgene-dma.txt  |   49 +
  arch/arm64/boot/dts/apm/apm-storm.dtsi |   26 +
  drivers/dma/Kconfig|8 +
  drivers/dma/Makefile   |1 +
  drivers/dma/xgene-dma.c| 1597 
 
  5 files changed, 1681 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
  create mode 100755 drivers/dma/xgene-dma.c

 --
 1.8.2.1

--
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 v4 0/3] dmaengine: APM X-Gene SoC DMA engine driver support

[Rameshwar Sahu]

Hi All,

Any comments on this patch set.


Thanks,
with regards,
Ram


On Wed, Jan 21, 2015 at 4:31 PM, Rameshwar Prasad Sahu  wrote:
> This patch set implements the APM X-Gene SoC DMA driver
> support to offload the DMA operations such as memory copy(memcpy),
> scatter gathering.
>
> v4 changes:
> 1. Fixed dma-ranges property on DTS.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> Signed-off-by: Loc Ho 
> ---
>
> Rameshwar Prasad Sahu (3):
>   dmaengine: Add support for APM X-Gene SoC DMA engine driver
>   arm64: dts: Add APM X-Gene DMA device and DMA clock DTS nodes
>   Documentation: dma: Add APM X-Gene SoC DMA engine driver documentation
>
>  .../devicetree/bindings/dma/apm-xgene-dma.txt  |   49 +
>  arch/arm64/boot/dts/apm/apm-storm.dtsi |   26 +
>  drivers/dma/Kconfig|8 +
>  drivers/dma/Makefile   |1 +
>  drivers/dma/xgene-dma.c| 1566 
> 
>  5 files changed, 1650 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
>  create mode 100644 drivers/dma/xgene-dma.c
>
> --
> 1.8.2.1
>
--
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 v4 0/3] dmaengine: APM X-Gene SoC DMA engine driver support

[Rameshwar Sahu]

Hi All,

Any comments on this patch set.


Thanks,
with regards,
Ram


On Wed, Jan 21, 2015 at 4:31 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch set implements the APM X-Gene SoC DMA driver
 support to offload the DMA operations such as memory copy(memcpy),
 scatter gathering.

 v4 changes:
 1. Fixed dma-ranges property on DTS.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---

 Rameshwar Prasad Sahu (3):
   dmaengine: Add support for APM X-Gene SoC DMA engine driver
   arm64: dts: Add APM X-Gene DMA device and DMA clock DTS nodes
   Documentation: dma: Add APM X-Gene SoC DMA engine driver documentation

  .../devicetree/bindings/dma/apm-xgene-dma.txt  |   49 +
  arch/arm64/boot/dts/apm/apm-storm.dtsi |   26 +
  drivers/dma/Kconfig|8 +
  drivers/dma/Makefile   |1 +
  drivers/dma/xgene-dma.c| 1566 
 
  5 files changed, 1650 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
  create mode 100644 drivers/dma/xgene-dma.c

 --
 1.8.2.1

--
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] arm64: dts: Add APM X-Gene DMA device and DMA clock DTS nodes

[Rameshwar Sahu]

Thanks,
with regards,
Ram


On Mon, Jan 19, 2015 at 8:11 PM, Rameshwar Sahu  wrote:
> Hi Arnd,
>
>
>
>
>
>
> Thanks,
> with regards,
> Ram
>
> On Mon, Jan 19, 2015 at 7:10 PM, Arnd Bergmann  wrote:
>>
>> On Monday 19 January 2015 18:11:08 Rameshwar Prasad Sahu wrote:
>> > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
>> > b/arch/arm64/boot/dts/apm/apm-storm.dtsi
>> > index f1ad9c2..e20da23 100644
>> > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
>> > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
>> > @@ -103,6 +103,9 @@
>> > #size-cells = <2>;
>> > ranges;
>> >
>> > +   /* DDR range is 42-bit addressing */
>> > +   dma-ranges = <0x40 0x0 0x40 0x0 0x1ff 0x>;
>> > +
>> >
>>
>> The comment above is misleading, and the value is wrong. I assume you
>>
>> copied these from the AMD patch that introduced the respective property.
>
>
> I referred this patch from AMD only.
>>
>>
>> The value should be
>>
>> dma-ranges = <0x40 0x0 0x40 0x0 0x200 0>;
>
>
> then it should be :
>
> dma-ranges = <0x40 0x0 0x40 0x0 0x400 0>;
>
>
>> to say that any DMA to physical addresses from 0 to 0x3f.
>> is disallowed and dma to physical addresses from 0x40.
>> to 0x23f. is allowed and gets translated using an
>> identity mapping.
>>
>> I also see that on Mustang, all memory is outside of this range,
>
>
> Do you mean all other device controller node in DT here??
> Basically these are all device controller memory, as what I understood is
> dma-ranges tells about DDR ranges like start address of DDR
> and length.
>
>
>>
>> which is a bit suspicious, while your PCI memory space is
>> included.
>
>
>>
>> It would be best to match the numbers up with your data sheet.
>>
>> Arnd
>> --
>> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
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] arm64: dts: Add APM X-Gene DMA device and DMA clock DTS nodes

[Rameshwar Sahu]

Thanks,
with regards,
Ram


On Mon, Jan 19, 2015 at 8:11 PM, Rameshwar Sahu rs...@apm.com wrote:
 Hi Arnd,






 Thanks,
 with regards,
 Ram

 On Mon, Jan 19, 2015 at 7:10 PM, Arnd Bergmann a...@arndb.de wrote:

 On Monday 19 January 2015 18:11:08 Rameshwar Prasad Sahu wrote:
  diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
  b/arch/arm64/boot/dts/apm/apm-storm.dtsi
  index f1ad9c2..e20da23 100644
  --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
  +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
  @@ -103,6 +103,9 @@
  #size-cells = 2;
  ranges;
 
  +   /* DDR range is 42-bit addressing */
  +   dma-ranges = 0x40 0x0 0x40 0x0 0x1ff 0x;
  +
 

 The comment above is misleading, and the value is wrong. I assume you

 copied these from the AMD patch that introduced the respective property.


 I referred this patch from AMD only.


 The value should be

 dma-ranges = 0x40 0x0 0x40 0x0 0x200 0;


 then it should be :

 dma-ranges = 0x40 0x0 0x40 0x0 0x400 0;


 to say that any DMA to physical addresses from 0 to 0x3f.
 is disallowed and dma to physical addresses from 0x40.
 to 0x23f. is allowed and gets translated using an
 identity mapping.

 I also see that on Mustang, all memory is outside of this range,


 Do you mean all other device controller node in DT here??
 Basically these are all device controller memory, as what I understood is
 dma-ranges tells about DDR ranges like start address of DDR
 and length.



 which is a bit suspicious, while your PCI memory space is
 included.



 It would be best to match the numbers up with your data sheet.

 Arnd
 --
 To unsubscribe from this list: send the line unsubscribe dmaengine in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
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 v2 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Arnd,





Thanks,
with regards,
Ram


On Tue, Jan 13, 2015 at 12:25 AM, Arnd Bergmann  wrote:
> On Monday 12 January 2015 14:40:09 Rameshwar Sahu wrote:
>> > +
>> > +   dma_set_mask_and_coherent(>dev,
>> > + (sizeof(dma_addr_t) == sizeof(u64)) ?
>> > + DMA_BIT_MASK(64) : DMA_BIT_MASK(32));
>> > +
>>
>
> I commented on this on v1 already: always set the device specific mask here,
> it's independent of the CPU architecture, but do check the return value.
>
Got it, I will set first 64 bit dma mask here  due to device support
64 bit address dma operations, and fall down to 32 - bit in case
failure with 64 bit.


> Also add the correct dma-ranges property in the parent, or else this will
> fail in the future once we add proper checks to dma_set_mask.

I see arch/arm64 kernel doesn't use dma range value parsed from
dma-range property currently, I will check it more.
It doesn't use dma_pfn_offset value calculated by the dma-ranges in
dma mapping API.
dma-ranges value should test properly before adding.
Is there any use to add this dma-ranges properly if arch code doesn't support ??

>
> 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 v2 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi Arnd,





Thanks,
with regards,
Ram


On Tue, Jan 13, 2015 at 12:25 AM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 12 January 2015 14:40:09 Rameshwar Sahu wrote:
  +
  +   dma_set_mask_and_coherent(pdev-dev,
  + (sizeof(dma_addr_t) == sizeof(u64)) ?
  + DMA_BIT_MASK(64) : DMA_BIT_MASK(32));
  +


 I commented on this on v1 already: always set the device specific mask here,
 it's independent of the CPU architecture, but do check the return value.

Got it, I will set first 64 bit dma mask here  due to device support
64 bit address dma operations, and fall down to 32 - bit in case
failure with 64 bit.


 Also add the correct dma-ranges property in the parent, or else this will
 fail in the future once we add proper checks to dma_set_mask.

I see arch/arm64 kernel doesn't use dma range value parsed from
dma-range property currently, I will check it more.
It doesn't use dma_pfn_offset value calculated by the dma-ranges in
dma mapping API.
dma-ranges value should test properly before adding.
Is there any use to add this dma-ranges properly if arch code doesn't support ??


 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 v2 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi All,

Any comments on this patch ??
Thanks,
with regards,
Ram


On Wed, Jan 7, 2015 at 4:39 PM, Rameshwar Prasad Sahu  wrote:
> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
> These DMA operations include memory copy and scatter gathering offload.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> Signed-off-by: Loc Ho 
> ---
>  drivers/dma/Kconfig |8 +
>  drivers/dma/Makefile|1 +
>  drivers/dma/xgene-dma.c | 1500 
> +++
>  3 files changed, 1509 insertions(+)
>  create mode 100644 drivers/dma/xgene-dma.c
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index f2b2c4e..251ce60 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -416,6 +416,14 @@ config NBPFAXI_DMA
> help
>   Support for "Type-AXI" NBPF DMA IPs from Renesas
>
> +config XGENE_DMA
> +   tristate "APM X-Gene DMA support"
> +   depends on ARCH_XGENE
> +   select DMA_ENGINE
> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
> +   help
> + Enable support for the APM X-Gene SoC DMA engine.
> +
>  config DMA_ENGINE
> bool
>
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 2022b54..0567e69 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -50,3 +50,4 @@ obj-y += xilinx/
>  obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> new file mode 100644
> index 000..ba8001a
> --- /dev/null
> +++ b/drivers/dma/xgene-dma.c
> @@ -0,0 +1,1500 @@
> +/* Applied Micro X-Gene SoC DMA engine Driver
> + *
> + * Copyright (c) 2014, Applied Micro Circuits Corporation
> + * Authors: Rameshwar Prasad Sahu 
> + * Loc Ho 
> + *
> + * 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;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "dmaengine.h"
> +
> +/* DMA ring csr registers and bit definations */
> +#define RING_ID0x0008
> +#define RING_ID_BUF0x000c
> +#define RING_CONFIG0x006c
> +#define RING_WR_BASE   0x0070
> +#define RING_NE_INT_MODE   0x017c
> +#define RING_NUM_CONFIG5
> +#define RING_DST_RING_ID(v)((1 << 10) | (v))
> +#define RING_CMD_OFFSET(v) (((v) << 6) + 0x2C)
> +#define RING_SELTHRSH_SET(m)   (((u32 *)(m))[4] |= BIT(3))
> +#define RING_ACCEPTLERR_SET(m) (((u32 *)(m))[3] |= BIT(19))
> +#define RING_QCOHERENT_SET(m)  (((u32 *)(m))[2] |= BIT(4))
> +#define RING_RECOMBBUF_SET(m)  (((u32 *)(m))[3] |= BIT(27))
> +#define RING_ID_SETUP(v)   ((v) | BIT(31))
> +#define RING_ID_BUF_SETUP(v)   (((v) << 9) | BIT(21))
> +#define RING_ID_GET(owner, num)(((owner) << 6) | (num))
> +#define RING_ADDRL_SET(m, v)   (((u32 *)(m))[2] |= (((v) >> 8) << 5))
> +#define RING_ADDRH_SET(m, v)   (((u32 *)(m))[3] |= ((v) >> 35))
> +#define RING_SIZE_SET(m, v)(((u32 *)(m))[3] |= ((v) << 23))
> +#define RING_TYPE_SET(m, v)(((u32 *)(m))[4] |= ((v) << 19))
> +#define RING_RECOMTIMEOUTL_SET(m)  \
> +   (((u32 *)(m))[3] |= (0x7 << 28))
> +#define RINNG_RECOMTIMEOUTH_SET(m) \
> +   (((u32 *)(m))[4] |= 0x3)
> +#define RING_NE_INT_MODE_SET(m, v) \
> +   ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
> +#define RING_NE_INT_MODE_RESET(m, v)   \
> +   ((m) &= (~BIT(31 - (v
> +
> +/* DMA device csr registers and bit definitions */
> +#define DMA_MEM_RAM_SHUTDOWN   0xD070
> +#define DMA_BLK_MEM_RDY0xD074
> +#define DMA_BLK_MEM_RDY_DEFAULT0x
> +#define DMA_RING_INT0_MASK 0x90A0
> +#define DMA_RING_INT1_MASK 0x90A8
> +#define DMA_RING_INT2_MASK 0x90B0
> +#define DMA_RING_INT3_MASK 0x90B8
> +#define DMA_RING_INT4_MASK 0x90C0
> +#define DMA_CFG_RING_WQ_ASSOC  0x90E0
> +#define DMA_WQ_ASSOC_RING_MNGR10x
> +#define DMA_CFG_RING_HOLD  0x90F8
> +#define DMA_RING_MNGR1_HOLD_EN BIT(1)
> +#define DMA_IPBRR  0x0
> +#define DMA_BUS_ID_RD(v)   (((v) >> 12) & 3)
> +#define DMA_REV_NO_RD(v)   (((v) >> 14) 

Re: [PATCH v2 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi All,

Any comments on this patch ??
Thanks,
with regards,
Ram


On Wed, Jan 7, 2015 at 4:39 PM, Rameshwar Prasad Sahu rs...@apm.com wrote:
 This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy and scatter gathering offload.

 Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com
 Signed-off-by: Loc Ho l...@apm.com
 ---
  drivers/dma/Kconfig |8 +
  drivers/dma/Makefile|1 +
  drivers/dma/xgene-dma.c | 1500 
 +++
  3 files changed, 1509 insertions(+)
  create mode 100644 drivers/dma/xgene-dma.c

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index f2b2c4e..251ce60 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -416,6 +416,14 @@ config NBPFAXI_DMA
 help
   Support for Type-AXI NBPF DMA IPs from Renesas

 +config XGENE_DMA
 +   tristate APM X-Gene DMA support
 +   depends on ARCH_XGENE
 +   select DMA_ENGINE
 +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
 +   help
 + Enable support for the APM X-Gene SoC DMA engine.
 +
  config DMA_ENGINE
 bool

 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index 2022b54..0567e69 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -50,3 +50,4 @@ obj-y += xilinx/
  obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
 +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 new file mode 100644
 index 000..ba8001a
 --- /dev/null
 +++ b/drivers/dma/xgene-dma.c
 @@ -0,0 +1,1500 @@
 +/* Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2014, Applied Micro Circuits Corporation
 + * Authors: Rameshwar Prasad Sahu rs...@apm.com
 + * Loc Ho l...@apm.com
 + *
 + * 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;  either version 2 of the  License, or (at your
 + * option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +
 +#include linux/clk.h
 +#include linux/delay.h
 +#include linux/dmaengine.h
 +#include linux/dma-mapping.h
 +#include linux/highmem.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_device.h
 +#include linux/pm_runtime.h
 +
 +#include dmaengine.h
 +
 +/* DMA ring csr registers and bit definations */
 +#define RING_ID0x0008
 +#define RING_ID_BUF0x000c
 +#define RING_CONFIG0x006c
 +#define RING_WR_BASE   0x0070
 +#define RING_NE_INT_MODE   0x017c
 +#define RING_NUM_CONFIG5
 +#define RING_DST_RING_ID(v)((1  10) | (v))
 +#define RING_CMD_OFFSET(v) (((v)  6) + 0x2C)
 +#define RING_SELTHRSH_SET(m)   (((u32 *)(m))[4] |= BIT(3))
 +#define RING_ACCEPTLERR_SET(m) (((u32 *)(m))[3] |= BIT(19))
 +#define RING_QCOHERENT_SET(m)  (((u32 *)(m))[2] |= BIT(4))
 +#define RING_RECOMBBUF_SET(m)  (((u32 *)(m))[3] |= BIT(27))
 +#define RING_ID_SETUP(v)   ((v) | BIT(31))
 +#define RING_ID_BUF_SETUP(v)   (((v)  9) | BIT(21))
 +#define RING_ID_GET(owner, num)(((owner)  6) | (num))
 +#define RING_ADDRL_SET(m, v)   (((u32 *)(m))[2] |= (((v)  8)  5))
 +#define RING_ADDRH_SET(m, v)   (((u32 *)(m))[3] |= ((v)  35))
 +#define RING_SIZE_SET(m, v)(((u32 *)(m))[3] |= ((v)  23))
 +#define RING_TYPE_SET(m, v)(((u32 *)(m))[4] |= ((v)  19))
 +#define RING_RECOMTIMEOUTL_SET(m)  \
 +   (((u32 *)(m))[3] |= (0x7  28))
 +#define RINNG_RECOMTIMEOUTH_SET(m) \
 +   (((u32 *)(m))[4] |= 0x3)
 +#define RING_NE_INT_MODE_SET(m, v) \
 +   ((m) = ((m)  ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define RING_NE_INT_MODE_RESET(m, v)   \
 +   ((m) = (~BIT(31 - (v
 +
 +/* DMA device csr registers and bit definitions */
 +#define DMA_MEM_RAM_SHUTDOWN   0xD070
 +#define DMA_BLK_MEM_RDY0xD074
 +#define DMA_BLK_MEM_RDY_DEFAULT0x
 +#define DMA_RING_INT0_MASK 0x90A0
 +#define DMA_RING_INT1_MASK 0x90A8
 +#define DMA_RING_INT2_MASK 0x90B0
 +#define DMA_RING_INT3_MASK 0x90B8
 +#define DMA_RING_INT4_MASK 0x90C0
 +#define DMA_CFG_RING_WQ_ASSOC  0x90E0
 +#define DMA_WQ_ASSOC_RING_MNGR10x
 +#define DMA_CFG_RING_HOLD  0x90F8
 +#define DMA_RING_MNGR1_HOLD_EN BIT(1)
 +#define DMA_IPBRR  0x0
 +#define DMA_BUS_ID_RD(v)   (((v) 

Re: [PATCH v1 1/3] dmaengine: Add support for APM X-Gene SoC DMA driver

[Rameshwar Sahu]

Hi Arnd,

See inline...

Thanks,
with regards,
Ram


On Wed, Dec 31, 2014 at 8:21 PM, Arnd Bergmann  wrote:
> On Wednesday 31 December 2014 17:12:14 Rameshwar Prasad Sahu wrote:
>> This patch implements the APM X-Gene SoC DMA driver. The APM X-Gene
>> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
>> These DMA operations include memory copy and scatter gathering offload.
>
> Is the dma engine capable of slave DMA in theory and you just don't use
> that, or does it not do that at all?

This DMA engine is not capable of slave DMA.


>
>> +static int xgene_dma_init_mem(struct xgene_dma *pdma)
>> +{
>> + int timeout = 1000;
>> +
>> + writel(0x0, pdma->csr_dma + DMA_MEM_RAM_SHUTDOWN);
>> +
>> + /* Force a barrier */
>> + readl(pdma->csr_dma + DMA_MEM_RAM_SHUTDOWN);
>> +
>> + do {
>> + if (readl(pdma->csr_dma + DMA_BLK_MEM_RDY)
>> + == DMA_BLK_MEM_RDY_DEFAULT)
>> + break;
>> + udelay(1);
>> + } while (--timeout);
>> +
>> + if (timeout <= 0) {
>> + dev_err(pdma->dev,
>> + "Failed to release memory from shutdown\n");
>> + return -ENODEV;
>> + }
>> + return 0;
>> +}
>
> That's a long busy-loop. Can you use a sleeping function instead?

Okay I will do this.

>
>> + /* Set DMA mask and coherent mask */
>> + ret = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(64));
>> + if (ret) {
>> + dev_err(>dev, "Failed to set DMA mask\n");
>> + goto err_pm_enable;
>> + }
>
> Never use dma_coerce_mask_and_coherent in new drivers. Instead, make
> sure that the information in the device tree is correct in the first
> place so the driver doesn't need to override it.
>
> Arnd
>

Okay I will use function for DMA masking that other driver uses.
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, 
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to Applied Micro Circuits Corporation or 
its subsidiaries. 
It is to be used solely for the purpose of furthering the parties' business 
relationship. 
All unauthorized review, use, disclosure or distribution is prohibited. 
If you are not the intended recipient, please contact the sender by reply 
e-mail 
and destroy all copies of the original message.

--
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 v1 1/3] dmaengine: Add support for APM X-Gene SoC DMA driver

[Rameshwar Sahu]

Hi Arnd,

See inline...

Thanks,
with regards,
Ram


On Wed, Dec 31, 2014 at 8:21 PM, Arnd Bergmann a...@arndb.de wrote:
 On Wednesday 31 December 2014 17:12:14 Rameshwar Prasad Sahu wrote:
 This patch implements the APM X-Gene SoC DMA driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy and scatter gathering offload.

 Is the dma engine capable of slave DMA in theory and you just don't use
 that, or does it not do that at all?

This DMA engine is not capable of slave DMA.



 +static int xgene_dma_init_mem(struct xgene_dma *pdma)
 +{
 + int timeout = 1000;
 +
 + writel(0x0, pdma-csr_dma + DMA_MEM_RAM_SHUTDOWN);
 +
 + /* Force a barrier */
 + readl(pdma-csr_dma + DMA_MEM_RAM_SHUTDOWN);
 +
 + do {
 + if (readl(pdma-csr_dma + DMA_BLK_MEM_RDY)
 + == DMA_BLK_MEM_RDY_DEFAULT)
 + break;
 + udelay(1);
 + } while (--timeout);
 +
 + if (timeout = 0) {
 + dev_err(pdma-dev,
 + Failed to release memory from shutdown\n);
 + return -ENODEV;
 + }
 + return 0;
 +}

 That's a long busy-loop. Can you use a sleeping function instead?

Okay I will do this.


 + /* Set DMA mask and coherent mask */
 + ret = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
 + if (ret) {
 + dev_err(pdev-dev, Failed to set DMA mask\n);
 + goto err_pm_enable;
 + }

 Never use dma_coerce_mask_and_coherent in new drivers. Instead, make
 sure that the information in the device tree is correct in the first
 place so the driver doesn't need to override it.

 Arnd


Okay I will use function for DMA masking that other driver uses.
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, 
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to Applied Micro Circuits Corporation or 
its subsidiaries. 
It is to be used solely for the purpose of furthering the parties' business 
relationship. 
All unauthorized review, use, disclosure or distribution is prohibited. 
If you are not the intended recipient, please contact the sender by reply 
e-mail 
and destroy all copies of the original message.

--
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/