From: Vinod Koul <vkoul@kernel.org>
To: shravan chippa <shravan.chippa@microchip.com>
Cc: green.wan@sifive.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, palmer@dabbelt.com,
paul.walmsley@sifive.com, conor+dt@kernel.org,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
nagasuresh.relli@microchip.com, praveen.kumar@microchip.com,
Emil Renner Berthing <emil.renner.berthing@canonical.com>
Subject: Re: [PATCH v4 3/4] dmaengine: sf-pdma: add mpfs-pdma compatible name
Date: Fri, 24 Nov 2023 17:41:36 +0530 [thread overview]
Message-ID: <ZWCS+ECGTgwVPR1u@matsya> (raw)
In-Reply-To: <20231031052753.3430169-4-shravan.chippa@microchip.com>
On 31-10-23, 10:57, shravan chippa wrote:
> From: Shravan Chippa <shravan.chippa@microchip.com>
>
> Sifive platform dma does not allow out-of-order transfers,
> Add a PolarFire SoC specific compatible and code to support
> for out-of-order dma transfers
By default dma xtions are not supposed to be out of order, so why does
it make sense specifying that here?
>
> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> Signed-off-by: Shravan Chippa <shravan.chippa@microchip.com>
> ---
> drivers/dma/sf-pdma/sf-pdma.c | 27 ++++++++++++++++++++++++---
> drivers/dma/sf-pdma/sf-pdma.h | 8 +++++++-
> 2 files changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c
> index 4c456bdef882..82ab12c40743 100644
> --- a/drivers/dma/sf-pdma/sf-pdma.c
> +++ b/drivers/dma/sf-pdma/sf-pdma.c
> @@ -25,6 +25,8 @@
>
> #include "sf-pdma.h"
>
> +#define PDMA_QUIRK_NO_STRICT_ORDERING BIT(0)
> +
> #ifndef readq
> static inline unsigned long long readq(void __iomem *addr)
> {
> @@ -66,7 +68,7 @@ static struct sf_pdma_desc *sf_pdma_alloc_desc(struct sf_pdma_chan *chan)
> static void sf_pdma_fill_desc(struct sf_pdma_desc *desc,
> u64 dst, u64 src, u64 size)
> {
> - desc->xfer_type = PDMA_FULL_SPEED;
> + desc->xfer_type = desc->chan->pdma->transfer_type;
> desc->xfer_size = size;
> desc->dst_addr = dst;
> desc->src_addr = src;
> @@ -520,6 +522,7 @@ static struct dma_chan *sf_pdma_of_xlate(struct of_phandle_args *dma_spec,
>
> static int sf_pdma_probe(struct platform_device *pdev)
> {
> + const struct sf_pdma_driver_platdata *ddata;
> struct sf_pdma *pdma;
> int ret, n_chans;
> const enum dma_slave_buswidth widths =
> @@ -545,6 +548,14 @@ static int sf_pdma_probe(struct platform_device *pdev)
>
> pdma->n_chans = n_chans;
>
> + pdma->transfer_type = PDMA_FULL_SPEED | PDMA_STRICT_ORDERING;
> +
> + ddata = device_get_match_data(&pdev->dev);
> + if (ddata) {
> + if (ddata->quirks & PDMA_QUIRK_NO_STRICT_ORDERING)
> + pdma->transfer_type &= ~PDMA_STRICT_ORDERING;
> + }
> +
> pdma->membase = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(pdma->membase))
> return PTR_ERR(pdma->membase);
> @@ -632,9 +643,19 @@ static int sf_pdma_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct sf_pdma_driver_platdata mpfs_pdma = {
> + .quirks = PDMA_QUIRK_NO_STRICT_ORDERING,
> +};
> +
> static const struct of_device_id sf_pdma_dt_ids[] = {
> - { .compatible = "sifive,fu540-c000-pdma" },
> - { .compatible = "sifive,pdma0" },
> + {
> + .compatible = "sifive,fu540-c000-pdma",
> + }, {
> + .compatible = "sifive,pdma0",
> + }, {
> + .compatible = "microchip,mpfs-pdma",
> + .data = &mpfs_pdma,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, sf_pdma_dt_ids);
> diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h
> index 5c398a83b491..267e79a5e0a5 100644
> --- a/drivers/dma/sf-pdma/sf-pdma.h
> +++ b/drivers/dma/sf-pdma/sf-pdma.h
> @@ -48,7 +48,8 @@
> #define PDMA_ERR_STATUS_MASK GENMASK(31, 31)
>
> /* Transfer Type */
> -#define PDMA_FULL_SPEED 0xFF000008
> +#define PDMA_FULL_SPEED 0xFF000000
> +#define PDMA_STRICT_ORDERING BIT(3)
>
> /* Error Recovery */
> #define MAX_RETRY 1
> @@ -112,8 +113,13 @@ struct sf_pdma {
> struct dma_device dma_dev;
> void __iomem *membase;
> void __iomem *mappedbase;
> + u32 transfer_type;
> u32 n_chans;
> struct sf_pdma_chan chans[];
> };
>
> +struct sf_pdma_driver_platdata {
> + u32 quirks;
> +};
> +
> #endif /* _SF_PDMA_H */
> --
> 2.34.1
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: shravan chippa <shravan.chippa@microchip.com>
Cc: green.wan@sifive.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, palmer@dabbelt.com,
paul.walmsley@sifive.com, conor+dt@kernel.org,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
nagasuresh.relli@microchip.com, praveen.kumar@microchip.com,
Emil Renner Berthing <emil.renner.berthing@canonical.com>
Subject: Re: [PATCH v4 3/4] dmaengine: sf-pdma: add mpfs-pdma compatible name
Date: Fri, 24 Nov 2023 17:41:36 +0530 [thread overview]
Message-ID: <ZWCS+ECGTgwVPR1u@matsya> (raw)
In-Reply-To: <20231031052753.3430169-4-shravan.chippa@microchip.com>
On 31-10-23, 10:57, shravan chippa wrote:
> From: Shravan Chippa <shravan.chippa@microchip.com>
>
> Sifive platform dma does not allow out-of-order transfers,
> Add a PolarFire SoC specific compatible and code to support
> for out-of-order dma transfers
By default dma xtions are not supposed to be out of order, so why does
it make sense specifying that here?
>
> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> Signed-off-by: Shravan Chippa <shravan.chippa@microchip.com>
> ---
> drivers/dma/sf-pdma/sf-pdma.c | 27 ++++++++++++++++++++++++---
> drivers/dma/sf-pdma/sf-pdma.h | 8 +++++++-
> 2 files changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c
> index 4c456bdef882..82ab12c40743 100644
> --- a/drivers/dma/sf-pdma/sf-pdma.c
> +++ b/drivers/dma/sf-pdma/sf-pdma.c
> @@ -25,6 +25,8 @@
>
> #include "sf-pdma.h"
>
> +#define PDMA_QUIRK_NO_STRICT_ORDERING BIT(0)
> +
> #ifndef readq
> static inline unsigned long long readq(void __iomem *addr)
> {
> @@ -66,7 +68,7 @@ static struct sf_pdma_desc *sf_pdma_alloc_desc(struct sf_pdma_chan *chan)
> static void sf_pdma_fill_desc(struct sf_pdma_desc *desc,
> u64 dst, u64 src, u64 size)
> {
> - desc->xfer_type = PDMA_FULL_SPEED;
> + desc->xfer_type = desc->chan->pdma->transfer_type;
> desc->xfer_size = size;
> desc->dst_addr = dst;
> desc->src_addr = src;
> @@ -520,6 +522,7 @@ static struct dma_chan *sf_pdma_of_xlate(struct of_phandle_args *dma_spec,
>
> static int sf_pdma_probe(struct platform_device *pdev)
> {
> + const struct sf_pdma_driver_platdata *ddata;
> struct sf_pdma *pdma;
> int ret, n_chans;
> const enum dma_slave_buswidth widths =
> @@ -545,6 +548,14 @@ static int sf_pdma_probe(struct platform_device *pdev)
>
> pdma->n_chans = n_chans;
>
> + pdma->transfer_type = PDMA_FULL_SPEED | PDMA_STRICT_ORDERING;
> +
> + ddata = device_get_match_data(&pdev->dev);
> + if (ddata) {
> + if (ddata->quirks & PDMA_QUIRK_NO_STRICT_ORDERING)
> + pdma->transfer_type &= ~PDMA_STRICT_ORDERING;
> + }
> +
> pdma->membase = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(pdma->membase))
> return PTR_ERR(pdma->membase);
> @@ -632,9 +643,19 @@ static int sf_pdma_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct sf_pdma_driver_platdata mpfs_pdma = {
> + .quirks = PDMA_QUIRK_NO_STRICT_ORDERING,
> +};
> +
> static const struct of_device_id sf_pdma_dt_ids[] = {
> - { .compatible = "sifive,fu540-c000-pdma" },
> - { .compatible = "sifive,pdma0" },
> + {
> + .compatible = "sifive,fu540-c000-pdma",
> + }, {
> + .compatible = "sifive,pdma0",
> + }, {
> + .compatible = "microchip,mpfs-pdma",
> + .data = &mpfs_pdma,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, sf_pdma_dt_ids);
> diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h
> index 5c398a83b491..267e79a5e0a5 100644
> --- a/drivers/dma/sf-pdma/sf-pdma.h
> +++ b/drivers/dma/sf-pdma/sf-pdma.h
> @@ -48,7 +48,8 @@
> #define PDMA_ERR_STATUS_MASK GENMASK(31, 31)
>
> /* Transfer Type */
> -#define PDMA_FULL_SPEED 0xFF000008
> +#define PDMA_FULL_SPEED 0xFF000000
> +#define PDMA_STRICT_ORDERING BIT(3)
>
> /* Error Recovery */
> #define MAX_RETRY 1
> @@ -112,8 +113,13 @@ struct sf_pdma {
> struct dma_device dma_dev;
> void __iomem *membase;
> void __iomem *mappedbase;
> + u32 transfer_type;
> u32 n_chans;
> struct sf_pdma_chan chans[];
> };
>
> +struct sf_pdma_driver_platdata {
> + u32 quirks;
> +};
> +
> #endif /* _SF_PDMA_H */
> --
> 2.34.1
--
~Vinod
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-11-24 12:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 5:27 [PATCH v4 0/4] dma: sf-pdma: various sf-pdma updates for the mpfs platform shravan chippa
2023-10-31 5:27 ` shravan chippa
2023-10-31 5:27 ` [PATCH v4 1/4] dmaengine: sf-pdma: Support of_dma_controller_register() shravan chippa
2023-10-31 5:27 ` shravan chippa
2023-11-24 12:08 ` Vinod Koul
2023-11-24 12:08 ` Vinod Koul
2023-11-28 11:34 ` Shravan.Chippa
2023-11-28 11:34 ` Shravan.Chippa
2023-10-31 5:27 ` [PATCH v4 2/4] dt-bindings: dma: sf-pdma: add new compatible name shravan chippa
2023-10-31 5:27 ` shravan chippa
2023-10-31 5:27 ` [PATCH v4 3/4] dmaengine: sf-pdma: add mpfs-pdma " shravan chippa
2023-10-31 5:27 ` shravan chippa
2023-11-24 12:11 ` Vinod Koul [this message]
2023-11-24 12:11 ` Vinod Koul
2023-11-28 11:29 ` Shravan.Chippa
2023-11-28 11:29 ` Shravan.Chippa
2023-10-31 5:27 ` [PATCH v4 4/4] riscv: dts: microchip: add specific compatible for mpfs' pdma shravan chippa
2023-10-31 5:27 ` shravan chippa
2023-11-21 7:52 ` [PATCH v4 0/4] dma: sf-pdma: various sf-pdma updates for the mpfs platform Shravan.Chippa
2023-11-21 7:52 ` Shravan.Chippa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZWCS+ECGTgwVPR1u@matsya \
--to=vkoul@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=emil.renner.berthing@canonical.com \
--cc=green.wan@sifive.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=nagasuresh.relli@microchip.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=praveen.kumar@microchip.com \
--cc=robh+dt@kernel.org \
--cc=shravan.chippa@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.