On Wed, 7 Dec 2022 at 09:13, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > > On 7/12/22 01:03, Michael Walle wrote: > > Hi Adrian, > > > >> SDHCI has separate controls for the internal clock and enabling the > >> clock signal to the card. > >> > >> The card clock signal was disabled via SDHCI_CLOCK_CARD_EN to avoid > >> glitches on the clock line. It is not necessary to reset the internal clock > >> to re-enable it. Instead re-enable by re-asserting SDHCI_CLOCK_CARD_EN. > > > > This commit breaks my board > > (arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts). The > > full bootlog is at the end of the mail. Reverting this commit will make my > > board boot again on mmc/next. What is strange though, is that this board is > > also in the kernelci and it doesn't happen there. At least on a quick > > glance at the next-master-next runs I couldn't spot the error. > > sdhci-esdhc ->set_clock() is esdhc_of_set_clock() which changes its behaviour > depending on the transfer mode, so presumably the clock must be recalculated > for e.g. HS400 so the ->set_clock() must always be used when changing > transfer mode even when the clock frequency does not change. As before, > there could be other drivers with similar issues with this patch, so Ulf, > please drop this patch also, sorry! Np! We have linux-next, to help us with testing of these kinds of issues. > > > > > Unfortunately, I don't think I can debug that on my own. But I'm happy to > > help and test suggested patches. But I really don't know whats going on > > here. > > > > -michael > > Michael, thanks for reporting! The offending patch has been dropped from my mmc tree. Kind regards Uffe
