[PATCH 23/38] mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function

[Olof Johansson]

On Thu, Jun 19, 2014 at 5:28 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:
>> Anyway, we did get some folks to test the patches and was thus fairly
>> confident that we could merge them. Chris asked me to try to collect
>> them in a PR for him, so I did. Sorry if I managed to screw some
>> things up, there were several conflicts and actual regressions, which
>> I tried to take care of.
>>
>> The mmc people were also very helping in sending patches to fixup
>> related regressions, immediately after we merged your patchset. Thus
>> together I think we managed to pull it off.
>
> I tend to look through slightly less rose-tinted glasses.
>
> The fact is... there's loads of ARM platforms which now fail in Olof's
> build/boot testing, and they all seem to have a very similar pattern:
>
> hummingboard:
> [    1.149688] sdhci: Secure Digital Host Controller Interface driver
> [    1.155901] sdhci: Copyright(c) Pierre Ossman
> ...
> [    1.253630] Waiting for root device /dev/mmcblk0p2...
> [   60.325469] imx-sdma 20ec000.sdma: firmware not found
> ~$off
> # PYBOOT: Exception: timeout
>
> jetson:
> [    2.261355] Waiting for root device /dev/mmcblk0p1...
>
> wandboard:
> [    1.186870] sdhci: Secure Digital Host Controller Interface driver
> [    1.193075] sdhci: Copyright(c) Pierre Ossman
> ...
> [    1.291064] Waiting for root device /dev/mmcblk0p2...
>
> Whether these are caused by the patch set or not is anyone's guess,
> because we (a) don't know what's causing these failures, and (b)
> my patch series was never tested on anything but iMX6.
>
> I'm pretty certain that the hummingboard failure is not related to
> my series as that's one of the platforms I did test my series on.
>
> There's more failures which look like possibly something in core MMC is
> rather screwed, as OMAP5 (which doesn't use SDHCI) is also failing at
> a similar point.
>
> What these failures /do/ mean is that when I'm pushing my ARM for-next
> branch out, Olof's builder picks it up and runs a build across it, and
> the report returns a whole load of failures.  A whole load of failures
> means that those platforms haven't tested my changes, which means the
> quality of testing is much lower than it should be.
>
> With 26 passing and 15 failing, that's over 1/3 of platforms failing,
> which means 1/3 aren't getting tested.
>
> This level of failure has been going on for quite a while now, and (afaik)
> it remains uninvestigated and undiagnosed.  (This is one of the complaints
> I have about Olof's build/boot test system, much of the information about
> the build and boot is hidden away and unpublished, which makes it almost
> impossible for third parties to diagnose any problem there.  I've given up
> looking at most of Olof's build/boot mails because of this - it's just
> not interesting to see the same abbreviated boot failure logs which give
> no useful information time and time again.)

Most of this is because I want to avoid sending huuuge emails out with
the failures. I'll add a push of the full log to arm-soc.lixom.net and
include a link to it in the emails, similar to how I do the build
logs. I'll let you know when I've made that change.


-Olof