On 25 July 2015 at 04:27, Scott Wood <scottw...@freescale.com> wrote: > On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote: >> On 21 July 2015 at 11:45, Yangbo Lu <yangbo...@freescale.com> wrote: >> > For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender >> > version value and sdhc spec version value. This will break down >> > the ADMA data transfer. So add workaround to get right value >> > VVN=0x13, SVN = 0x1. >> >> So T4240-R1.0-R2.0 is the version of the controller, right? >> >> If I understand correct you are checking what CPU/SoC you are running >> on, to figure out which controller version you are using, as that >> can't be fetched (trusted) from the registers of the esdhc controller >> itself!? >> >> Instead, you could deal with this directly in the DTS files. I assume >> you have some DTS file for each SoC/board variant, right? > > No, we do not have a separate DTS file for each revision of an SoC -- and if > we did, we'd constantly have people using the wrong one. > >> In principle, in your DTS file specific for the board/SoC that holds >> the T4240-R1.0-R2.0 version of the controller, should add a specific >> esdhc DT property to indicate this errata. > > No, because (in addition to the above issue about chip revisions) the device > tree is stable ABI and errata are often discovered after device trees are > deployed.
Fair enough. Then what is your suggestion for the solution here? As I understand it, you can't update the already deployed DTB. Shall we make Linux patch the DTB during boot instead, depending on the chip revision? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
