From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Matthew Leon <matthewleon@linux.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 v3 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
Date: Mon, 30 Jul 2018 11:11:33 +0800 [thread overview]
Message-ID: <20180730111133.0b4e8b2d@xhacker.debian> (raw)
In-Reply-To: <01010164e92bcc1a-c3ac69eb-f6e5-4420-ac87-de1a0ffd0ac5-000000@us-west-2.amazonses.com>
On Mon, 30 Jul 2018 03:11:59 +0000
Matthew Leon <matthewleon@linux.com> wrote:
> >> Hey Jisheng,
>
> >Hi,
>
> >>
>
> >In LKML, we'd better not top post.
>
> Noted. My apologies.
>
> >> Shouldn't we be splitting until all DMA blocks are less than 128M
> boundary?
> >> I am a noob, but I think we should be prepared for boundaries that when
> >> split in two, will still be greater than 128M. Feel free to disagree but
> >> please explain why I may be wrong. Thank-you.
>
> >the limitation is "DMA addr can't span 128MB boundary" rather than "must be
> >less than 128MB", they are different.
>
> >And the max transfer size of one DMA desc is 64KB.
>
> >thanks
>
> I have misspoken. What if the DMA transfer size is 1024M? If we split in
> two, then we have 2 transfers, each of which span 512M. So wouldn't we need
> to split again to have 4 transfers, each of which span 128M?
>
the max transfer size of each desc is 64KB, how could it be 1024MB?
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 v3 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
Date: Mon, 30 Jul 2018 11:11:33 +0800 [thread overview]
Message-ID: <20180730111133.0b4e8b2d@xhacker.debian> (raw)
In-Reply-To: <01010164e92bcc1a-c3ac69eb-f6e5-4420-ac87-de1a0ffd0ac5-000000@us-west-2.amazonses.com>
On Mon, 30 Jul 2018 03:11:59 +0000
Matthew Leon <matthewleon@linux.com> wrote:
> >> Hey Jisheng,
>
> >Hi,
>
> >>
>
> >In LKML, we'd better not top post.
>
> Noted. My apologies.
>
> >> Shouldn't we be splitting until all DMA blocks are less than 128M
> boundary?
> >> I am a noob, but I think we should be prepared for boundaries that when
> >> split in two, will still be greater than 128M. Feel free to disagree but
> >> please explain why I may be wrong. Thank-you.
>
> >the limitation is "DMA addr can't span 128MB boundary" rather than "must be
> >less than 128MB", they are different.
>
> >And the max transfer size of one DMA desc is 64KB.
>
> >thanks
>
> I have misspoken. What if the DMA transfer size is 1024M? If we split in
> two, then we have 2 transfers, each of which span 512M. So wouldn't we need
> to split again to have 4 transfers, each of which span 128M?
>
the max transfer size of each desc is 64KB, how could it be 1024MB?
next prev parent reply other threads:[~2018-07-30 3:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-30 2:42 [PATCH mmc-next v3 0/3] solve SDHCI DWC MSHC 128MB DMA boundary limitation Jisheng Zhang
2018-07-30 2:42 ` Jisheng Zhang
2018-07-30 2:45 ` [PATCH mmc-next v3 2/3] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops Jisheng Zhang
2018-07-30 2:45 ` Jisheng Zhang
2018-08-15 14:07 ` Adrian Hunter
2018-08-15 14:07 ` Adrian Hunter
2018-07-30 2:46 ` [PATCH mmc-next v3 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation Jisheng Zhang
2018-07-30 2:46 ` Jisheng Zhang
2018-07-30 2:56 ` Matthew Leon
2018-07-30 2:59 ` Jisheng Zhang
2018-07-30 2:59 ` Jisheng Zhang
[not found] ` <01010164e92bcc1a-c3ac69eb-f6e5-4420-ac87-de1a0ffd0ac5-000000@us-west-2.amazonses.com>
2018-07-30 3:11 ` Jisheng Zhang [this message]
2018-07-30 3:11 ` Jisheng Zhang
2018-07-30 3:11 ` Matthew Leon
2018-08-09 2:27 ` [PATCH mmc-next v3 0/3] solve SDHCI DWC MSHC " Jisheng Zhang
2018-08-09 2:27 ` 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=20180730111133.0b4e8b2d@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=matthewleon@linux.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.