[U-Boot] [ANN] U-Boot v2018.03-rc3 released

[Alex Kiernan]

On Wed, Feb 21, 2018 at 9:20 AM, Alex Kiernan <alex.kiernan at gmail.com> wrote:
> On Tue, Feb 20, 2018 at 10:03 PM, Tom Rini <trini at konsulko.com> wrote:
>> Hey all,
>>
>> So, we're a day late.  That's because I wanted the MMC PR to come in for
>> some important fixes, and it was too late in my day to then push a
>> release.  I think we probably have a few more fixes that need to come
>> in, but hopefully no more new regressions to be found.  That said, if
>> you have your environment, well, anywhere, a little bit of hardware
>> testing wouldn't hurt.  I think we're still on track for -rc4 on March
>> 5th and the release on March 12th.  But if we aren't, the release will
>> get delayed.
>>
>
> Something's broken my board (AM335x, not quite a BBB):
>
> MMC:   mmc at 481d8000 - probe failed: -1
>
> Looks to be this commit:
>
> 2d7482cf793fe4d8a98906002708d6e1fa2c5ba3
>
> Still looking, but I'd guess I'm now missing something from my DTB
> which I didn't need previously.
>

mmc_of_parse says:

        /* f_max is obtained from the optional "max-frequency" property */
        dev_read_u32(dev, "max-frequency", &cfg->f_max);

I don't have a max-frequency (pretty much all my config comes direct
from am33xx.dtsi), so if I add a max-frequency to my tree I get a
working board, but the comment above suggests I shouldn't need to, so
do we need something like this added (or a refactor of mmc_of_parse so
it takes a default?)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 02970f2..b87ff01 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1825,6 +1825,8 @@ static int omap_hsmmc_ofdata_to_platdata(struct
udevice *dev)
        if (ret < 0)
                return ret;

+       if (cfg->f_max == 0)
+               cfg->f_max = 52000000;
        cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
        cfg->f_min = 400000;
        cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;

I'm also seeing MMC_MODE_1BIT (which I didn't previously have set)
alongside MMC_MODE_4BIT and MMC_MODE_8BIT (which I previously did),
but I'm guessing that doesn't matter?

-- 
Alex Kiernan