From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2] mmc: seperate block number into small parts for multi-write cmd
Date: Mon, 11 Oct 2010 11:22:24 +0200 [thread overview]
Message-ID: <20101011092224.161A014F310@gemini.denx.de> (raw)
In-Reply-To: <4CB2D225.6020702@emk-elektronik.de>
Dear Reinhard Meyer,
In message <4CB2D225.6020702@emk-elektronik.de> you wrote:
>
> After thinking alot about this:
> Preface: (for understanding of the issue)
Thanks!!
> I see two possible solutions for that problem here:
> 1. generally limit the number of blocks requested to 65535. The performance
> penalty for that is insignificant. (65535 blocks are about 32 MiB)
> 2. limit it on a case by case basis by passing such limit like a host
> capability to the high level part.
>
> Here I would (after much deliberation) favour version 1.
I agree. Implementing 2) is not worth the effort or the code. 32 MiB
should be enough in most practical cases, and even for really big
transfers it is a more than appropriate chunk size.
> The second and more serious problem Lei Wen seems to have with his hardware
> is that DMA seems problematic (how so?) for more than 512 KiB.
Indeed. So far it is totally unclear to me what sort of restriction
this actually is. If my interpretation is correct, than such DMA
transfers should not cross 512 KiB memory boundaries, so the maximum
transfer size is 512 KiB, but only when you start on a 512 KiB
aligned address. Also my interpretation is that this is not actually
a hard restriction, but only a convenience to avoid handling some DMA
interrupt properly - in Linux. I wonder if this really applied to
U-Boot at all, where we use polling instead.
> I really don't see that we should pull such (unusual?) limitations into the
> high level part. I think the low level driver could issue several DMA
> transfers in that case.
Again I agree. thi is a low-level, controller specific detail, which
should not affect any upper-layer code. It should be completely hidden
in the controller specific driver code.
> We need concensus here first before we can issue and comment patches.
I think both of us agree. We just need to convince Lei Wen...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For every problem there is one solution which is simple, neat, and
wrong. - H. L. Mencken
next prev parent reply other threads:[~2010-10-11 9:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-06 7:19 [U-Boot] [PATCH] mmc: seperate block number into small parts for multi-write cmd Lei Wen
2010-09-06 8:28 ` Wolfgang Denk
2010-09-06 8:40 ` Lei Wen
2010-09-06 9:23 ` Reinhard Meyer
2010-09-06 9:31 ` Lei Wen
2010-09-06 10:16 ` Reinhard Meyer
2010-09-06 10:48 ` Lei Wen
2010-09-06 11:50 ` Reinhard Meyer
2010-10-10 4:20 ` Lei Wen
2010-10-10 6:48 ` Wolfgang Denk
2010-10-10 8:49 ` Lei Wen
2010-10-10 9:22 ` Wolfgang Denk
2010-10-10 9:27 ` Lei Wen
2010-10-10 9:39 ` Reinhard Meyer
2010-10-10 9:44 ` Lei Wen
2010-10-10 9:33 ` Reinhard Meyer
2010-10-10 9:42 ` Lei Wen
2010-10-11 3:42 ` [U-Boot] [PATCH V2] " Lei Wen
2010-10-11 9:00 ` Reinhard Meyer
2010-10-11 9:22 ` Wolfgang Denk [this message]
2010-10-11 9:27 ` Lei Wen
2010-10-11 10:44 ` [U-Boot] [PATCH] " Reinhard Meyer
2010-10-11 11:35 ` Wolfgang Denk
2010-10-11 15:39 ` [U-Boot] [PATCH V3] " Lei Wen
2010-10-13 19:57 ` Wolfgang Denk
2010-10-14 5:38 ` [U-Boot] [PATCH V4] " Lei Wen
2010-10-25 18:46 ` Steve Sakoman
2010-10-27 18:39 ` Wolfgang Denk
2010-10-27 19:59 ` Steve Sakoman
2010-10-27 6:04 ` [U-Boot] [PATCH V3] " Lei Wen
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=20101011092224.161A014F310@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/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.