[U-Boot] [RFC PATCH 2/2] mmc: add support for block device cache

[Eric Nelson <eric@nelint.com>]

Hi Tom,

On 03/20/2016 03:54 PM, Eric Nelson wrote:
> On 03/20/2016 03:13 PM, Tom Rini wrote:
>> On Sun, Mar 20, 2016 at 12:35:53PM -0700, Eric Nelson wrote:
>>> On 03/17/2016 02:23 PM, Stephen Warren wrote:
>>>> On 03/16/2016 03:40 PM, Eric Nelson wrote:
>>>>> Signed-off-by: Eric Nelson <eric@nelint.com>
>>>>
>>>> Patch description.
>>>>
>>>>> ---
>>>>>   drivers/mmc/mmc.c       | 10 +++++++++-
>>>>>   drivers/mmc/mmc_write.c |  7 +++++++
>>>>
>>>> Presumably it makes sense for the cache to work for IDE, SATA, USB,
>>>> SCSI, ... too. I wonder if it's possible to put this code somewhere more
>>>> central than mmc*.c so it automatically applies to
>>>> dev_desc->block_read() (see include/part.h). Perhaps not since each
>>>> implementation supplies its own block_read function directly, so the
>>>> cache calls do need to be duplicated everywhere.
>>>>
>>>
>>> Yeah. I haven't found a spot that would allow interception of
>>> the various block_read/write functions.
>>
>> Shouldn't DM also help here?
>>
> 
> I haven't yet looked, but this may be true.
> 
> I'm seeing some build breakage on master surrounding the use
> of DM though.
> 
> If I select DM and BLK on top of nitrogen6q_defconfig, I get
> lots of build errors.
> 
> I want to get a V2 RFC patch out before digging through the
> details of that.
> 

I'm obviously not up to speed on the state of DM and I hadn't
seen Simon's patch adding blk.h.

The new blk_dread/write/erase functions do provide a convenient
spot for checking cache, though they're not universally used yet.

In particular, hooking up the cache there will lose visibility
into things like the "mmc write" command.

I'm also not sure of the current state of DM with respect to
block drivers and wonder if a block cache should wait a cycle
or two.

Simon, I'd appreciate some feedback when you have a chance.

Regards,


Eric