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

[Reinhard Meyer]

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.

> 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.

However if agreement exists that the commom MMC code shall limit its
requests to drivers to the most limiting hardware design... be it.

Reinhard