[U-Boot] [PATCH 1/3] mmc: limit block count for multi-block write commands

[Lei Wen]

Hi Reinhard,

On Thu, Sep 9, 2010 at 11:07 PM, Reinhard Meyer
<u-boot at emk-elektronik.de> wrote:
> Dear Lei Wen,
>> Hi Reinhard,
>>
>>
>>> Besides that my remarks to yesterdays patch of yours are still valid:
>>> Those "magic numbers" are due to a specific hardware controller/limitation
>>> and not any SD/MMC card limitation.
>>>
>>> And which hardware driver are you using this with?
>>> Maybe some context would help.
>>> Maybe the splitting could be done in the hardware driver and not in this
>>> generic part?
>>>
>> Certainly those limitation could not be put at the generic part. But
>> for the common limitation from the spec,
>> I believe put there is a better choice. I mention for the sd host
>> controller standard spec has such limitation for a maximum blocks at
>> one go.
>> You could refer to the pdf doc at:
>> http://www.sdcard.org/developers/tech/host_controller/simple_spec/Simplified_SD_Host_Controller_Spec.pdf
>> The register table at page 20 shows the block count register is only
>> 16 bit width.
>
> This is now going in circles...
> You keep repeating the same Tantra over and over. You should by now have
> realized that this spec gives an EXAMPLE of how a host controller might
> be realized. For obvious reasons most designers will NOT follow that
> SD-Card specification and might even call their controller a multi-media-card
> interface.
>
> So I repeat again: I am sure that many embedded systems
> do NOT have such a "Simplified_SD_Host_Controller" that has a
> funny 16 Bit Register in its hardware.

I also agree this discussion should not going into a endless circle...
You says that the sd spec is just example, and mention the mmc.
But you should not forget mmc&sd card are often designed together, so
designer would
choose the sd register layout to get the sd&mmc both works.

If designer don't follow the spec, it is obvious allowable, but this
one just should be a special case.
I believe most others would like to follow the spec directly.

Maybe we could let somebody else to show their choice...


>
>> For the 524288 magic number, 512k, I just follow the Linux way, that
>> is don't let the driver to bother to handle the dma boundary if it use
>> sdma instead PIO.
>
> And again: I am sure most hardware does not have a funny 512k boundary for
> DMA operations either. And if, would that boundary not be at a divisible
> by 512k memory address (page size maybe) and not at a length of 512k?
>
>>
>> So it is not which hardware's question.
>
> It IS hardware related.

Yes, it is hardware related, but I mean not a special hardware...
>
> However if agreement exists that the commom MMC code shall limit its
> requests to drivers to the most limiting hardware design... be it.
>
> Reinhard
>

Best regards,
Lei
>