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 <e...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
