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