From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Christian Lamparter <chunkeey@gmail.com>
Cc: dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
Dan Williams <dan.j.williams@intel.com>,
Vinod Koul <vkoul@kernel.org>, Viresh Kumar <vireshk@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Subject: [v2,2/2] dmaengine: dw-dmac: implement dma protection control setting
Date: Sat, 10 Nov 2018 20:45:53 +0200 [thread overview]
Message-ID: <20181110184553.GF10650@smile.fi.intel.com> (raw)
On Sat, Nov 10, 2018 at 05:28:31PM +0100, Christian Lamparter wrote:
> This patch adds a new device-tree property that allows to
> specify the dma protection control bits for the all of the
> DMA controller's channel uniformly.
>
> Setting the "correct" bits can have a huge impact on the
> PPC460EX and APM82181 that use this DMA engine in combination
> with a DesignWare' SATA-II core (sata_dwc_460ex driver).
>
> In the OpenWrt Forum, the user takimata reported that:
> |It seems your patch unleashed the full power of the SATA port.
> |Where I was previously hitting a really hard limit at around
> |82 MB/s for reading and 27 MB/s for writing, I am now getting this:
> |
> |root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024
> |1024+0 records in
> |1024+0 records out
> |real 0m 13.65s
> |user 0m 0.01s
> |sys 0m 11.89s
> |
> |root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024
> |1024+0 records in
> |1024+0 records out
> |real 0m 8.41s
> |user 0m 0.01s
> |sys 0m 4.70s
> |
> |This means: 121 MB/s reading and 75 MB/s writing!
> |
> |The drive is a WD Green WD10EARX taken from an older MBL Single.
> |I repeated the test a few times with even larger files to rule out
> |any caching, I'm still seeing the same great performance. OpenWrt is
> |now completely on par with the original MBL firmware's performance.
>
> Another user And.short reported:
> |I can report that your fix worked! Boots up fine with two
> |drives even with more partitions, and no more reboot on
> |concurrent disk access!
>
> A closer look into the sata_dwc_460ex code revealed that
> the driver did initally set the correct protection control
> bits. However, this feature was lost when the sata_dwc_460ex
> driver was converted to the generic DMA driver framework.
LGTM, though minor style comment below.
>
> BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/55
> BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/50
> Fixes: 8b3444852a2b ("sata_dwc_460ex: move to generic DMA driver")
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> drivers/dma/dw/core.c | 2 ++
> drivers/dma/dw/platform.c | 6 ++++++
> drivers/dma/dw/regs.h | 4 ++++
> include/linux/platform_data/dma-dw.h | 6 ++++++
> 4 files changed, 18 insertions(+)
>
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index f43e6dafe446..0772d2d6cc68 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -160,12 +160,14 @@ static void dwc_initialize_chan_idma32(struct dw_dma_chan *dwc)
>
> static void dwc_initialize_chan_dw(struct dw_dma_chan *dwc)
> {
> + struct dw_dma *dw = to_dw_dma(dwc->chan.device);
> u32 cfghi = DWC_CFGH_FIFO_MODE;
> u32 cfglo = DWC_CFGL_CH_PRIOR(dwc->priority);
> bool hs_polarity = dwc->dws.hs_polarity;
>
> cfghi |= DWC_CFGH_DST_PER(dwc->dws.dst_id);
> cfghi |= DWC_CFGH_SRC_PER(dwc->dws.src_id);
> + cfghi |= DWC_CFGH_PROTCTL(dw->pdata->protctl);
>
> /* Set polarity of handshake interface */
> cfglo |= hs_polarity ? DWC_CFGL_HS_DST_POL | DWC_CFGL_HS_SRC_POL : 0;
> diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> index f62dd0944908..c299ff181bb6 100644
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -162,6 +162,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
> pdata->multi_block[tmp] = 1;
> }
>
> + if (!of_property_read_u32(np, "snps,dma-protection-control", &tmp)) {
> + if (tmp > CHAN_PROTCTL_MASK)
> + return NULL;
> + pdata->protctl = tmp;
> + }
> +
> return pdata;
> }
> #else
> diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
> index 09e7dfdbb790..646c9c960c07 100644
> --- a/drivers/dma/dw/regs.h
> +++ b/drivers/dma/dw/regs.h
> @@ -200,6 +200,10 @@ enum dw_dma_msize {
> #define DWC_CFGH_FCMODE (1 << 0)
> #define DWC_CFGH_FIFO_MODE (1 << 1)
> #define DWC_CFGH_PROTCTL(x) ((x) << 2)
> +#define DWC_CFGH_PROTCTL_DATA (0 << 2) /* data access - always set */
> +#define DWC_CFGH_PROTCTL_PRIV (1 << 2) /* privileged -> AHB HPROT[1] */
> +#define DWC_CFGH_PROTCTL_BUFFER (2 << 2) /* bufferable -> AHB HPROT[2] */
> +#define DWC_CFGH_PROTCTL_CACHE (4 << 2) /* cacheable -> AHB HPROT[3] */
> #define DWC_CFGH_DS_UPD_EN (1 << 5)
> #define DWC_CFGH_SS_UPD_EN (1 << 6)
> #define DWC_CFGH_SRC_PER(x) ((x) << 7)
> diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
> index 896cb71a382c..b7b9d4a56bb0 100644
> --- a/include/linux/platform_data/dma-dw.h
> +++ b/include/linux/platform_data/dma-dw.h
> @@ -49,6 +49,7 @@ struct dw_dma_slave {
> * @data_width: Maximum data width supported by hardware per AHB master
> * (in bytes, power of 2)
> * @multi_block: Multi block transfers supported by hardware per channel.
> + * @protctl: Protection control signals setting per channel.
> */
> struct dw_dma_platform_data {
> unsigned int nr_channels;
> @@ -65,6 +66,11 @@ struct dw_dma_platform_data {
> unsigned char nr_masters;
> unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
> unsigned char multi_block[DW_DMA_MAX_NR_CHANNELS];
> +#define CHAN_PROTCTL_PRIVILEGED BIT(0)
> +#define CHAN_PROTCTL_BUFFERABLE BIT(1)
> +#define CHAN_PROTCTL_CACHEABLE BIT(2)
> +#define CHAN_PROTCTL_MASK GENMASK(2, 0)
TAB vs. SPACE.
> + unsigned char protctl;
> };
>
> #endif /* _PLATFORM_DATA_DMA_DW_H */
> --
> 2.19.1
>
next reply other threads:[~2018-11-10 18:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-10 18:45 Andy Shevchenko [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-11-10 16:28 [v2,2/2] dmaengine: dw-dmac: implement dma protection control setting Christian Lamparter
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=20181110184553.GF10650@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=chunkeey@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=vireshk@kernel.org \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox