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

[Eric Nelson]

Hi all,

On 03/21/2016 11:31 AM, Eric Nelson wrote:
> 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 at nelint.com>
>>>>>
...

>> I'm seeing some build breakage on master surrounding the use
>> of DM though.
>>

Peng's patch made it clear that DM wasn't supported by fsl_esdhc.

>> If I select DM and BLK on top of nitrogen6q_defconfig, I get
>> lots of build errors.
>>

It's CONFIG_BLK that produces lots of issues, and from what
I can tell, it's only currently supported for sandbox.

Out of ignorance, I was conflating the two.

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

I think I have a better handle on this now.

I'm still a bit confused on what needs to be done in order
for CONFIG_BLK to work against real hardware.

>From what I can tell, the some modules in cmd/ need to be
updated to use blk_dread/blk_dwrite/blk_derase and some kind
of re-structuring needs to occur in drivers/mmc to support
the "blk" uclass.

Does that sound about right?

Is somebody currently working on this?

Please advise,


Eric