Hi Leo, Am Dienstag, 27. Februar 2018, 04:15:46 CET schrieb 温暖: > Thank you for your advice! I will revise it according to your suggestion. please also keep an eye on my reply to Linus' mail pointing out some other issues where the driver should not tie into soc-specific areas like the clock controller etc. Thanks Heiko Am Dienstag, 27. Februar 2018, 04:15:46 CET schrieb 温暖: > On 2/26/2018 18:12，Linus Walleij<linus.walleij@xxxxxxxxxx> wrote： > On Mon, Feb 26, 2018 at 9:16 AM, Wen Nuan <leo.wen@xxxxxxxxxxxxxx> wrote: > + pdata->grf_gpio2b_iomux = ioremap((resource_size_t) > + (GRF_BASE_ADDR + > + GRF_GPIO2B_IOMUX), 4); > + grf_val = __raw_readl(pdata->grf_gpio2b_iomux); > + __raw_writel(((grf_val) | (1 << 6) | (1 << (6 + 16))), > + pdata->grf_gpio2b_iomux); > + > + pdata->grf_io_vsel = ioremap((resource_size_t) > + (GRF_BASE_ADDR + GRF_IO_VSEL), 4); > + grf_val = __raw_readl(pdata->grf_io_vsel); > + __raw_writel(((grf_val) | (1 << 1) | (1 << (1 + 16))), > + pdata->grf_io_vsel); > > You are doing pin control on the side of the pin control subsystem > it looks like? > > I think David Wu and Heiko Stubner needs to have a look at what you > are doing here to suggest other solutions. > > Apart from that, why use __raw_writel instead of just writel()? > > This pin is iomux, default GPIO, need to be changed to CLK. > This CLK is provided to external sensor for use. > I'll use writel(). As stated, please don't directly access soc blocks like the clock controller or iomuxes, there are standard APIs like the general clock API and also assigned-clock* devicetree properties. Similarly for pinctrl access. So there should not be any writel (or ioremap) at all in this spi driver I'd think. Thanks Heiko
