From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Nelson <eric@nelint.com>
Date: Fri, 25 Mar 2016 17:11:38 -0700
Subject: [U-Boot] [RFC PATCH 2/2] mmc: add support for block device cache
In-Reply-To: <56F03E1B.20501@nelint.com>
References: <56E9A92F.5000205@nelint.com>
 <1458164424-15363-1-git-send-email-eric@nelint.com>
 <1458164424-15363-3-git-send-email-eric@nelint.com>
 <56EB2060.8040309@wwwdotorg.org> <56EEFB99.2080805@nelint.com>
 <20160320221332.GU23166@bill-the-cat> <56EF2A3C.603@nelint.com>
 <56F03E1B.20501@nelint.com>
Message-ID: <56F5D3BA.8060204@nelint.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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