Hi Mark Brown, There are two problems we have found for use regmap up to now. 1, Regmap will read device value depends on endian in .dtsi(DSPI in .dtsi file is big-endian) and readl()(readl() in arm64 is le32_to_cpu read) in system. That is the value read out is fixed regardless the kernel were compiled with CONFIG_CPU_BIG_ENDIAN yes or no. That makes the value(read from DSPI)can't be recognized in one endian mode(CONFIG_CPU_BIG_ENDIAN be set or not). The result is: DSPI can't working with CONFIG_CPU_BIG_ENDIAN set. 2, Sometimes regmap will generate some issues. Some regmap issues will cause the DSPI do not working. At 2016.4 we find the DSPI was not work, then we found that the regmap R/W the controller register sometimes not right. The result is: DSPI can't working with REGMAP API. Although the regmap issues was fast fixed by some giving person. But I'm still tend to use the reliable way. Regmap is nice and Maybe I should try to fix regmap instead of replacing regmap in my driver. But regmap is really very large and complex for DSPI driver. I think maybe the suitable way is the best way even the regmap is so good as everyone says. So I strongly suggest to use the dspi_writel / dspi_readl to instead of the regmap in DSPI driver. Best Regards, Yuan Yao > -----Original Message----- > From: Mark Brown [mailto:broonie@xxxxxxxxxx] > Sent: Wednesday, April 27, 2016 11:26 PM > To: Yuan Yao <yao.yuan@xxxxxxxxxxxxx> > Cc: robh+dt@xxxxxxxxxx; pawel.moll@xxxxxxx; shawnguo@xxxxxxxxxx; linux- > devel@xxxxxxxxxxxxxxxxxxxx; linux-spi@xxxxxxxxxxxxxxx; > devicetree@xxxxxxxxxxxxxxx; Yao Yuan <yao.yuan@xxxxxxx>; Yang-Leo Li > <leoyang.li@xxxxxxx>; Scott Wood <scott.wood@xxxxxxx> > Subject: Re: [PATCH 1/2] spi: spi-fsl-dspi: replace regmap R/W with internal > implementation > > On Wed, Apr 27, 2016 at 04:12:35PM +0800, Yuan Yao wrote: > > > At first we use regmap to cover this issue. > > But the regmap is designed too large and complex. > > The issue for regmap often effect the DSPI's stability. > > I'm not convinced that open coding things is going to make life much easier > here. If there's problems in the underlying code then fixing those seems like a > more generally useful approach to things. What are the actual problems this is > intended to fix? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
