Dear Reinhard Meyer, dear Lei Wen,
In message <4cb2ea80.2090...@emk-elektronik.de> you wrote:
>
> > Ok, I am also fine with not include the 512KiB restriction.
> > So we comes to a conclusion that we still use v1 patch, but cut the
> > 512KiB limitation?
>
> Considering the comments that were giv
Dear Lei Wen,
> Ok, I am also fine with not include the 512KiB restriction.
> So we comes to a conclusion that we still use v1 patch, but cut the
> 512KiB limitation?
Considering the comments that were given to that one, yes.
> As mmc host limitation, the max number of block in one go
> should b
On Sun, Oct 10, 2010 at 5:39 PM, Reinhard Meyer
wrote:
> Dear Lei Wen,
>>
>> I think it is a generic problem, and I am also curios why other people
>> don't complain for it...
>
> Because it is NOT a generic problem.
>
>> In Linux code, the multi-write write semantic also has such limitation
>> in
Hi Reinhard,
On Sun, Oct 10, 2010 at 5:33 PM, Reinhard Meyer
wrote:
> Dear all concerned,
>>
>> But my (limited!) understanding is that it's not a platform problem
>> you are solving, but one of this special kind of controller, which
>> nobody else would ever run into.
>
> I would vouch to extend
Dear Lei Wen,
> I think it is a generic problem, and I am also curios why other people
> don't complain for it...
Because it is NOT a generic problem.
> In Linux code, the multi-write write semantic also has such limitation
> in platform code.
> So if UBOOT also could have this, that would be so
Dear all concerned,
> But my (limited!) understanding is that it's not a platform problem
> you are solving, but one of this special kind of controller, which
> nobody else would ever run into.
I would vouch to extend
struct mmc {
struct list_head link;
char name[32];
void
Hi Wolfgang,
On Sun, Oct 10, 2010 at 5:22 PM, Wolfgang Denk wrote:
> Dear Lei Wen,
>
> In message you
> wrote:
>>
>> > Please explain why that shouldnot be possible. It's the driver that
>> > accesses your hardware, so it has full control over everything going
>> > on.
>> >
>> You are right, ce
Dear Lei Wen,
In message you
wrote:
>
> > Please explain why that shouldnot be possible. It's the driver that
> > accesses your hardware, so it has full control over everything going
> > on.
> >
> You are right, certainly driver cuold make this, but this would bring
> a lot of complexity for it
Hi Wolfgang,
On Sun, Oct 10, 2010 at 2:48 PM, Wolfgang Denk wrote:
> Dear Lei Wen,
>
> In message you
> wrote:
>>
>> Although the common code is named as mmc.c, I think a lot of people use it
>> to work for sd too, since they are compatible in most case.
>
> Right. And where SD drivers differ,
Dear Lei Wen,
In message you
wrote:
>
> Although the common code is named as mmc.c, I think a lot of people use it
> to work for sd too, since they are compatible in most case.
Right. And where SD drivers differ, such differeng code should be
provided by the SD drivers, and not pulled into the
Hi Reinhard,
On Mon, Sep 6, 2010 at 7:50 PM, Reinhard Meyer wrote:
> Lei Wen schrieb:
> Where does this limitation supposedly come from?
This limitation comes from the SD/MMC sepc. You could find one and
check the 0x6 offset register(BLOCK COUNT REGISTER).
>>> This might refer to ce
Lei Wen schrieb:
Where does this limitation supposedly come from?
>>> This limitation comes from the SD/MMC sepc. You could find one and
>>> check the 0x6 offset register(BLOCK COUNT REGISTER).
>> This might refer to certain HOST controllers, but not to Cards!
>
> You are right, this comes fr
On Mon, Sep 6, 2010 at 6:16 PM, Reinhard Meyer wrote:
> Lei Wen schrieb:
>> On Mon, Sep 6, 2010 at 5:23 PM, Reinhard Meyer
>> wrote:
>>> Dear Lei Wen,
As mmc host limitation, the max number of block in one go
>
> You already write it's a HOST limitation.
>
should be limited to 65535, a
Lei Wen schrieb:
> On Mon, Sep 6, 2010 at 5:23 PM, Reinhard Meyer
> wrote:
>> Dear Lei Wen,
>>> As mmc host limitation, the max number of block in one go
You already write it's a HOST limitation.
>>> should be limited to 65535, and the max buffer size should
>>> not excceed 512k bytes.
Which w
On Mon, Sep 6, 2010 at 5:23 PM, Reinhard Meyer wrote:
> Dear Lei Wen,
>> As mmc host limitation, the max number of block in one go
>> should be limited to 65535, and the max buffer size should
>> not excceed 512k bytes.
>
> Where does this limitation supposedly come from?
This limitation comes fr
Dear Lei Wen,
> As mmc host limitation, the max number of block in one go
> should be limited to 65535, and the max buffer size should
> not excceed 512k bytes.
Where does this limitation supposedly come from?
And, 65535 blocks (of 512) are already near 32 MB.
TOP9000> mmci
mci: setting clock 19
On Mon, Sep 6, 2010 at 4:28 PM, Wolfgang Denk wrote:
> Dear Lei Wen,
>
> In message <1283757567-15161-1-git-send-email-lei...@marvell.com> you wrote:
>> As mmc host limitation, the max number of block in one go
>> should be limited to 65535, and the max buffer size should
>> not excceed 512k bytes
Dear Lei Wen,
In message <1283757567-15161-1-git-send-email-lei...@marvell.com> you wrote:
> As mmc host limitation, the max number of block in one go
> should be limited to 65535, and the max buffer size should
> not excceed 512k bytes.
There is a typo in the Subject ("separate"), and actually I
As mmc host limitation, the max number of block in one go
should be limited to 65535, and the max buffer size should
not excceed 512k bytes.
Signed-off-by: Lei Wen
---
drivers/mmc/mmc.c | 56 +---
1 files changed, 35 insertions(+), 21 deletions(-
19 matches
Mail list logo
