All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH mmc-next v2 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
Date: Tue, 31 Jul 2018 13:52:57 +0800	[thread overview]
Message-ID: <20180731135257.268924f3@xhacker.debian> (raw)
In-Reply-To: <20180731112924.6a1e8388@xhacker.debian>

On Tue, 31 Jul 2018 11:29:24 +0800
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:

> Hi Robin,
> 
> On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote:
> 
> > Hi Jisheng,
> > 
> > On 26/07/18 08:14, Jisheng Zhang wrote:  
> > > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > > the DMA transfer into two so that each one doesn't exceed the boundary.    
> > 
> > Out of interest, is the driver already setting its segment boundary mask 
> > appropriately? This sounds like the exact kind of hardware restriction 
> > that dma_parms is intended to describe, which scatterlist-generating 
> > code is *supposed* to already respect.  
> 
> Thanks for the nice input. It may provide an elegant solution for this
> limitation. 
> 
> To simplify the situation, let's assume no iommu, only swiotlb. And
> the DDR is less than 4GB so swiotlb on arm64 doesn't init.
> 
> There's no dma range limitation with the HW, the only limitation
> is boundary, while dma_capable() doesn't check the boundary mask, so if
> we taking this solution, we need to teach dma_capable() about the boundary
> mask, I'm not sure whether this is acceptable.
> 
> Another problem is swiotlb initialization. When to init swiotlb, we dunno
> there's such boundary limitation HW. Is there any elegant solution for
> this problem?
> 

One more problem is: swiotlb isn't available on all platforms, e.g arm?
How to solve this SDHCI HW's limitation on arm soc w/o iommu?

Thanks

WARNING: multiple messages have this Message-ID (diff)
From: Jisheng.Zhang@synaptics.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH mmc-next v2 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
Date: Tue, 31 Jul 2018 13:52:57 +0800	[thread overview]
Message-ID: <20180731135257.268924f3@xhacker.debian> (raw)
In-Reply-To: <20180731112924.6a1e8388@xhacker.debian>

On Tue, 31 Jul 2018 11:29:24 +0800
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:

> Hi Robin,
> 
> On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote:
> 
> > Hi Jisheng,
> > 
> > On 26/07/18 08:14, Jisheng Zhang wrote:  
> > > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > > the DMA transfer into two so that each one doesn't exceed the boundary.    
> > 
> > Out of interest, is the driver already setting its segment boundary mask 
> > appropriately? This sounds like the exact kind of hardware restriction 
> > that dma_parms is intended to describe, which scatterlist-generating 
> > code is *supposed* to already respect.  
> 
> Thanks for the nice input. It may provide an elegant solution for this
> limitation. 
> 
> To simplify the situation, let's assume no iommu, only swiotlb. And
> the DDR is less than 4GB so swiotlb on arm64 doesn't init.
> 
> There's no dma range limitation with the HW, the only limitation
> is boundary, while dma_capable() doesn't check the boundary mask, so if
> we taking this solution, we need to teach dma_capable() about the boundary
> mask, I'm not sure whether this is acceptable.
> 
> Another problem is swiotlb initialization. When to init swiotlb, we dunno
> there's such boundary limitation HW. Is there any elegant solution for
> this problem?
> 

One more problem is: swiotlb isn't available on all platforms, e.g arm?
How to solve this SDHCI HW's limitation on arm soc w/o iommu?

Thanks

WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>, <linux-mmc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH mmc-next v2 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
Date: Tue, 31 Jul 2018 13:52:57 +0800	[thread overview]
Message-ID: <20180731135257.268924f3@xhacker.debian> (raw)
In-Reply-To: <20180731112924.6a1e8388@xhacker.debian>

On Tue, 31 Jul 2018 11:29:24 +0800
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:

> Hi Robin,
> 
> On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote:
> 
> > Hi Jisheng,
> > 
> > On 26/07/18 08:14, Jisheng Zhang wrote:  
> > > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > > the DMA transfer into two so that each one doesn't exceed the boundary.    
> > 
> > Out of interest, is the driver already setting its segment boundary mask 
> > appropriately? This sounds like the exact kind of hardware restriction 
> > that dma_parms is intended to describe, which scatterlist-generating 
> > code is *supposed* to already respect.  
> 
> Thanks for the nice input. It may provide an elegant solution for this
> limitation. 
> 
> To simplify the situation, let's assume no iommu, only swiotlb. And
> the DDR is less than 4GB so swiotlb on arm64 doesn't init.
> 
> There's no dma range limitation with the HW, the only limitation
> is boundary, while dma_capable() doesn't check the boundary mask, so if
> we taking this solution, we need to teach dma_capable() about the boundary
> mask, I'm not sure whether this is acceptable.
> 
> Another problem is swiotlb initialization. When to init swiotlb, we dunno
> there's such boundary limitation HW. Is there any elegant solution for
> this problem?
> 

One more problem is: swiotlb isn't available on all platforms, e.g arm?
How to solve this SDHCI HW's limitation on arm soc w/o iommu?

Thanks

  reply	other threads:[~2018-07-31  5:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26  7:10 [PATCH mmc-next v2 0/3] solve SDHCI DWC MSHC 128MB DMA boundary limitation Jisheng Zhang
2018-07-26  7:10 ` Jisheng Zhang
2018-07-26  7:12 ` [PATCH mmc-next v2 1/3] mmc: sdhci: add adma_table_num member to struct sdhci_host Jisheng Zhang
2018-07-26  7:12   ` Jisheng Zhang
2018-07-26  7:12 ` [PATCH mmc-next v2 2/3] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops Jisheng Zhang
2018-07-26  7:12   ` Jisheng Zhang
2018-07-26  7:14 ` [PATCH mmc-next v2 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation Jisheng Zhang
2018-07-26  7:14   ` Jisheng Zhang
2018-07-28 17:35   ` kbuild test robot
2018-07-28 17:35     ` kbuild test robot
2018-07-28 19:27   ` kbuild test robot
2018-07-28 19:27     ` kbuild test robot
2018-07-30 11:06   ` Robin Murphy
2018-07-30 11:06     ` Robin Murphy
2018-07-31  3:29     ` Jisheng Zhang
2018-07-31  3:29       ` Jisheng Zhang
2018-07-31  3:29       ` Jisheng Zhang
2018-07-31  5:52       ` Jisheng Zhang [this message]
2018-07-31  5:52         ` Jisheng Zhang
2018-07-31  5:52         ` Jisheng Zhang

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=20180731135257.268924f3@xhacker.debian \
    --to=jisheng.zhang@synaptics.com \
    --cc=adrian.hunter@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=ulf.hansson@linaro.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 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.