Message ID | 20231003042215.142678-4-shravan.chippa@microchip.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp1846765vqb; Mon, 2 Oct 2023 21:22:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFkax6oPH035c3nCssLYtapRKsfUQqNuxa3oT4ZdrejVtNuK3RX/LT0irIj3fU1lEDDM3aU X-Received: by 2002:a17:90a:8548:b0:274:b4ce:7049 with SMTP id a8-20020a17090a854800b00274b4ce7049mr11070477pjw.34.1696306936086; Mon, 02 Oct 2023 21:22:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696306936; cv=none; d=google.com; s=arc-20160816; b=WmfRDbmVgO1oUSbueV3bqL34vFVQhHGmw7WsHAlLFEU6oUhK1e3ynZiPgjJks3+/Gc 9RDInCAHk4iN3S4XDMfDmx/rAzQmyDELw+ShZpEymMhKQMvs5/hO1a2JWc1CCtKNR2zN RUo8tZQXeLOHOE9SKHcQ+su5jZrz6XZgSN4pF3agZythyGYiNClnlyZhp6ZwzIo7o8qN zDbkXOeChtDStkGxG6eLte+OKLmvqT0FjqdnLbgyREyAnFUbBDvavKUBFiAVJOZl7PxJ H8GHZjfHsB416esooXaaz1MfZkLAmGKVn0iXi/YpR1ZGyK4kcwglr/4xNYDfJ/nM1CUt LoIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Yo+cz5eBfEboWdYW5sEp8HiPn0yeJpx0LOlS0pOIuv0=; fh=ShTRRczpu864z7u/uL8KOhQHPlzqNfTJPMMlbqeoRU0=; b=Mx70sB7MaoKrRrWNVVh7x47Blu66Zhva1xt+dmSsvxLWwommT0Uke7MgPpVq+VXqgj nFAY/adjKFwO2agSZKLH5H5smSMYxp9IfxpdAaDU8pkNuccq0fSwFiFzm7dCYYEQg/GM 859WaAQPhDwJv3lCOGPivFNUqm8zQpumHX+9403AgYyXtpQvPDgr0bdoLQa5uZY3XMNZ G1Hz6130Whn7YRbVHVx7T0AhafAKPC3qJ7aMJfZ4HRA+7Q9RU629lFoHF6J4k0wADVKP 1OpWy5OJCWI/lPpNSn+AzqBar9yxAL/2Ha/CP/oAKC6kbdDXPKxrg3wWT/SadYo6GYRc r1fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=BAmMgobZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id pj8-20020a17090b4f4800b00277e0d7163asi638658pjb.32.2023.10.02.21.22.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 21:22:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=BAmMgobZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 29883822B02C; Mon, 2 Oct 2023 21:22:15 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239080AbjJCEWI (ORCPT <rfc822;pusanteemu@gmail.com> + 18 others); Tue, 3 Oct 2023 00:22:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239045AbjJCEWG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 3 Oct 2023 00:22:06 -0400 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CABBA4; Mon, 2 Oct 2023 21:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1696306923; x=1727842923; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=UxIXasS2OTVy/F2KygXVSkU+5jJ464D8P3BNT5N73Ss=; b=BAmMgobZho0o5Stq1Q6KSwzl45QSDV4mxwJugROGmHRShDgPF5BOwMj8 MH2BGtkut6/ujAcjKkrIcZ17QdERfrVXswUq2rPqO2/5sUOrbGToBbzWU wfDhnEfw39lfWApyW1qE0v/txW1Sn/Istl0jrMqRqpK1ubJi+RmNmShCK 4Lx+Pro0tksrJIvpgxzCSwACHc9APNxXKp4U+OJYi1J+dqxSq/jVZNgw+ l3ffmzUz9uDeF+lpRTlvhrREVZG4hMAtUx3Ye0mOKSXr6U9Sp9lPwzya3 qlUIMwwVxiEUi3xy//Es5ghqHZivUHsmIWGSPX1iayxgctbD2fKfypwxy Q==; X-CSE-ConnectionGUID: CfTVgEzCTm6iPkFhghp5JA== X-CSE-MsgGUID: i4Wnc6pNSb+uhGmwA9d/zg== X-ThreatScanner-Verdict: Negative X-IronPort-AV: E=Sophos;i="6.03,196,1694761200"; d="scan'208";a="7623120" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa4.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 02 Oct 2023 21:22:02 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Mon, 2 Oct 2023 21:21:21 -0700 Received: from microchip1-OptiPlex-9020.microchip.com (10.10.85.11) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2507.21 via Frontend Transport; Mon, 2 Oct 2023 21:21:16 -0700 From: shravan chippa <shravan.chippa@microchip.com> To: <green.wan@sifive.com>, <vkoul@kernel.org>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <palmer@dabbelt.com>, <paul.walmsley@sifive.com>, <conor+dt@kernel.org> CC: <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>, <shravan.chippa@microchip.com> Subject: [PATCH v2 3/4] dmaengine: sf-pdma: add mpfs-pdma compatible name Date: Tue, 3 Oct 2023 09:52:14 +0530 Message-ID: <20231003042215.142678-4-shravan.chippa@microchip.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231003042215.142678-1-shravan.chippa@microchip.com> References: <20231003042215.142678-1-shravan.chippa@microchip.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 02 Oct 2023 21:22:15 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778706741828289114 X-GMAIL-MSGID: 1778706741828289114 |
Series |
dma: sf-pdma: various sf-pdma updates for the mpfs platform
|
|
Commit Message
shravan chippa
Oct. 3, 2023, 4:22 a.m. UTC
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 Signed-off-by: Shravan Chippa <shravan.chippa@microchip.com> --- drivers/dma/sf-pdma/sf-pdma.c | 27 ++++++++++++++++++++++++--- drivers/dma/sf-pdma/sf-pdma.h | 6 ++++++ 2 files changed, 30 insertions(+), 3 deletions(-)
Comments
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 > > Signed-off-by: Shravan Chippa <shravan.chippa@microchip.com> > --- > drivers/dma/sf-pdma/sf-pdma.c | 27 ++++++++++++++++++++++++--- > drivers/dma/sf-pdma/sf-pdma.h | 6 ++++++ > 2 files changed, 30 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c > index 06a0912a12a1..a9ff319d4ca3 100644 > --- a/drivers/dma/sf-pdma/sf-pdma.c > +++ b/drivers/dma/sf-pdma/sf-pdma.c > @@ -21,6 +21,7 @@ > #include <linux/dma-mapping.h> > #include <linux/of.h> > #include <linux/of_dma.h> > +#include <linux/of_device.h> > #include <linux/slab.h> > > #include "sf-pdma.h" > @@ -66,7 +67,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; Two spaces. > desc->xfer_size = size; > desc->dst_addr = dst; > desc->src_addr = src; > @@ -520,6 +521,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 +547,14 @@ static int sf_pdma_probe(struct platform_device *pdev) > > pdma->n_chans = n_chans; > > + pdma->transfer_type = PDMA_FULL_SPEED; > + > + ddata = of_device_get_match_data(&pdev->dev); > + if (ddata) { > + if (ddata->quirks & NO_STRICT_ORDERING) > + pdma->transfer_type &= ~(NO_STRICT_ORDERING); > + } > + The commit message says "Sifive platform dma does not allow out-of-order transfers" so you want strict ordering by default and then allow out-of-order transfers if the match data allows it, right? But here bit 3 is set by default and cleared if the quirk is set, so it looks like bit 3 actually means "strict ordering" and not "no strict ordering" as you've named it. The confusion here probably stems using the same define for the quirk and the xfer_type. Unless I'm mistaken above I'd find something like this a lot easier to read: sf_pdma.h: #define PDMA_FULL_SPEED 0xFF000000 #define PDMA_STRICT_ORDERING BIT(3) sf_pdma.c: #define PDMA_QUIRK_NO_STRICT_ORDERING BIT(0) dma->transfer_type = PDMA_FULL_SPEED | PDMA_STRICT_ORDERING; ... 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,11 +642,22 @@ static int sf_pdma_remove(struct platform_device *pdev) > return 0; > } > > +static const struct sf_pdma_driver_platdata mpfs_pdma = { > + .quirks = 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); > > static struct platform_driver sf_pdma_driver = { > diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h > index 5c398a83b491..3b16db4daa0b 100644 > --- a/drivers/dma/sf-pdma/sf-pdma.h > +++ b/drivers/dma/sf-pdma/sf-pdma.h > @@ -49,6 +49,7 @@ > > /* Transfer Type */ > #define PDMA_FULL_SPEED 0xFF000008 > +#define NO_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
Hi Emil Renner, > -----Original Message----- > From: Emil Renner Berthing <emil.renner.berthing@canonical.com> > Sent: Tuesday, October 3, 2023 1:05 PM > To: shravan Chippa - I35088 <Shravan.Chippa@microchip.com>; > green.wan@sifive.com; vkoul@kernel.org; robh+dt@kernel.org; > krzysztof.kozlowski+dt@linaro.org; palmer@dabbelt.com; > paul.walmsley@sifive.com; conor+dt@kernel.org > Cc: dmaengine@vger.kernel.org; devicetree@vger.kernel.org; linux- > riscv@lists.infradead.org; linux-kernel@vger.kernel.org; Nagasuresh Relli - I67208 > <Nagasuresh.Relli@microchip.com>; Praveen Kumar - I30718 > <Praveen.Kumar@microchip.com> > Subject: Re: [PATCH v2 3/4] dmaengine: sf-pdma: add mpfs-pdma compatible > name > > [You don't often get email from emil.renner.berthing@canonical.com. Learn why > this is important at https://aka.ms/LearnAboutSenderIdentification ] > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > 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 > > > > Signed-off-by: Shravan Chippa <shravan.chippa@microchip.com> > > --- > > drivers/dma/sf-pdma/sf-pdma.c | 27 ++++++++++++++++++++++++--- > > drivers/dma/sf-pdma/sf-pdma.h | 6 ++++++ > > 2 files changed, 30 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/dma/sf-pdma/sf-pdma.c > > b/drivers/dma/sf-pdma/sf-pdma.c index 06a0912a12a1..a9ff319d4ca3 > > 100644 > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > @@ -21,6 +21,7 @@ > > #include <linux/dma-mapping.h> > > #include <linux/of.h> > > #include <linux/of_dma.h> > > +#include <linux/of_device.h> > > #include <linux/slab.h> > > > > #include "sf-pdma.h" > > @@ -66,7 +67,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; > > Two spaces. > > > desc->xfer_size = size; > > desc->dst_addr = dst; > > desc->src_addr = src; > > @@ -520,6 +521,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 +547,14 @@ static int sf_pdma_probe(struct platform_device > *pdev) > > > > pdma->n_chans = n_chans; > > > > + pdma->transfer_type = PDMA_FULL_SPEED; > > + > > + ddata = of_device_get_match_data(&pdev->dev); > > + if (ddata) { > > + if (ddata->quirks & NO_STRICT_ORDERING) > > + pdma->transfer_type &= ~(NO_STRICT_ORDERING); > > + } > > + > > The commit message says "Sifive platform dma does not allow out-of-order > transfers" so you want strict ordering by default and then allow > out-of-order transfers if the match data allows it, right? > > But here bit 3 is set by default and cleared if the quirk is set, so it looks > like bit 3 actually means "strict ordering" and not "no strict ordering" as > you've named it. > > The confusion here probably stems using the same define for the quirk and the > xfer_type. Unless I'm mistaken above I'd find something like this a lot easier > to read: > > sf_pdma.h: > #define PDMA_FULL_SPEED 0xFF000000 > #define PDMA_STRICT_ORDERING BIT(3) > > sf_pdma.c: > #define PDMA_QUIRK_NO_STRICT_ORDERING BIT(0) > > dma->transfer_type = PDMA_FULL_SPEED | PDMA_STRICT_ORDERING; > ... > if (ddata->quirks & PDMA_QUIRK_NO_STRICT_ORDERING) > pdma->transfer_type &= ~PDMA_STRICT_ORDERING; > Thanks for the input. To avoid confusion on the naming of the macro and new macro for quirk I will try to modify it as you mentioned. Thanks, Shravan > > pdma->membase = devm_platform_ioremap_resource(pdev, 0); > > if (IS_ERR(pdma->membase)) > > return PTR_ERR(pdma->membase); > > @@ -632,11 +642,22 @@ static int sf_pdma_remove(struct platform_device > *pdev) > > return 0; > > } > > > > +static const struct sf_pdma_driver_platdata mpfs_pdma = { > > + .quirks = 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); > > > > static struct platform_driver sf_pdma_driver = { > > diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h > > index 5c398a83b491..3b16db4daa0b 100644 > > --- a/drivers/dma/sf-pdma/sf-pdma.h > > +++ b/drivers/dma/sf-pdma/sf-pdma.h > > @@ -49,6 +49,7 @@ > > > > /* Transfer Type */ > > #define PDMA_FULL_SPEED 0xFF000008 > > +#define NO_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
On Tue, Oct 03, 2023 at 09:52:14AM +0530, 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 > > Signed-off-by: Shravan Chippa <shravan.chippa@microchip.com> > --- > drivers/dma/sf-pdma/sf-pdma.c | 27 ++++++++++++++++++++++++--- > drivers/dma/sf-pdma/sf-pdma.h | 6 ++++++ > 2 files changed, 30 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c > index 06a0912a12a1..a9ff319d4ca3 100644 > --- a/drivers/dma/sf-pdma/sf-pdma.c > +++ b/drivers/dma/sf-pdma/sf-pdma.c > @@ -21,6 +21,7 @@ > #include <linux/dma-mapping.h> > #include <linux/of.h> > #include <linux/of_dma.h> > +#include <linux/of_device.h> Wrong header. > #include <linux/slab.h> > > #include "sf-pdma.h" > @@ -66,7 +67,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 +521,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 +547,14 @@ static int sf_pdma_probe(struct platform_device *pdev) > > pdma->n_chans = n_chans; > > + pdma->transfer_type = PDMA_FULL_SPEED; > + > + ddata = of_device_get_match_data(&pdev->dev); Use device_get_match_data() instead > + if (ddata) { > + if (ddata->quirks & NO_STRICT_ORDERING) > + pdma->transfer_type &= ~(NO_STRICT_ORDERING); > + } > + > pdma->membase = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(pdma->membase)) > return PTR_ERR(pdma->membase); > @@ -632,11 +642,22 @@ static int sf_pdma_remove(struct platform_device *pdev) > return 0; > } > > +static const struct sf_pdma_driver_platdata mpfs_pdma = { > + .quirks = 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); > > static struct platform_driver sf_pdma_driver = { > diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h > index 5c398a83b491..3b16db4daa0b 100644 > --- a/drivers/dma/sf-pdma/sf-pdma.h > +++ b/drivers/dma/sf-pdma/sf-pdma.h > @@ -49,6 +49,7 @@ > > /* Transfer Type */ > #define PDMA_FULL_SPEED 0xFF000008 > +#define NO_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 >
diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c index 06a0912a12a1..a9ff319d4ca3 100644 --- a/drivers/dma/sf-pdma/sf-pdma.c +++ b/drivers/dma/sf-pdma/sf-pdma.c @@ -21,6 +21,7 @@ #include <linux/dma-mapping.h> #include <linux/of.h> #include <linux/of_dma.h> +#include <linux/of_device.h> #include <linux/slab.h> #include "sf-pdma.h" @@ -66,7 +67,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 +521,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 +547,14 @@ static int sf_pdma_probe(struct platform_device *pdev) pdma->n_chans = n_chans; + pdma->transfer_type = PDMA_FULL_SPEED; + + ddata = of_device_get_match_data(&pdev->dev); + if (ddata) { + if (ddata->quirks & NO_STRICT_ORDERING) + pdma->transfer_type &= ~(NO_STRICT_ORDERING); + } + pdma->membase = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(pdma->membase)) return PTR_ERR(pdma->membase); @@ -632,11 +642,22 @@ static int sf_pdma_remove(struct platform_device *pdev) return 0; } +static const struct sf_pdma_driver_platdata mpfs_pdma = { + .quirks = 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); static struct platform_driver sf_pdma_driver = { diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h index 5c398a83b491..3b16db4daa0b 100644 --- a/drivers/dma/sf-pdma/sf-pdma.h +++ b/drivers/dma/sf-pdma/sf-pdma.h @@ -49,6 +49,7 @@ /* Transfer Type */ #define PDMA_FULL_SPEED 0xFF000008 +#define NO_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 */