On 27 July 2015 at 17:57, Scott Wood <scottwood@xxxxxxxxxxxxx> wrote: > On Mon, 2015-07-27 at 09:58 +0200, Ulf Hansson wrote: >> On 25 July 2015 at 04:27, Scott Wood <scottwood@xxxxxxxxxxxxx> wrote: >> > On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote: >> > > On 21 July 2015 at 11:45, Yangbo Lu <yangbo.lu@xxxxxxxxxxxxx> 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 said in my comment on patch 2/3, read SVR from the device-config/guts > MMIO block, which works on both PPC and ARM. > That's okay, as long as don't have include sections of non generic header files in the driver. To be more clear, this is not okay to have: #include <mach/*> Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
