Hi Sylwester, > >>> > > The CLK_IGNORE_UNUSED flag has to be avoided whenever possible. > >>> > > Use the CLK_IS_CRITICAL flag instead for critical SPI1 clocks, > >>> > > which enables the clock line during boot time. > >> > > >> > I don't agree. Both flags should be avoided. Clk is critical does not > >> > solve the problem. It is just a better workaround for lack of proper > >> > clock consumers. > >> > > >> > The IOCLK is not a critical clock. It can be disabled (e.g. when SoC > >> > is used on a board without any SPI device connected). > > > > As we discussed offline there is no driver which is requesting > > this clock. We cannot ask to the spi driver to handle three > > clocks because the exynos5433 has its own peculiarities. > > > > If we want this on the spi driver's side, we need to add a new > > compatible and check it everytime. To me it looks uglier than > > just keep it alive. > > I took a closer look at what those IOCLK clocks exactly are and > unfortunately I must agree with Krzysztof. These clock gates are > closely related to the IP blocks and to me proper approach is to > have them listed in DT and controlled by the SPI bus driver. > > I checked and there is similar pattern for other IPs like I2S and > other SoCs, e.g. exynos7420. > Additionally parents of those IOCLK_SPI?_CLK clocks are currently > wrongly modelled as fixed rate clocks. These clocks really don't > have a parent until some clock is fed externally to the SoC's I/O > pin. But this issue could be addressed later. yes, it's a weird design :/ > I think it is not a big deal to add "samsung-exynos5433-spi" > compatible to the SPI driver along with a new variant data and > a flag like "has_cmu_ioclk" to indicate whether a third clock > should be handled or not. Presumably for now the ioclk clock can > just simply be enabled in probe(), this way it will be enabled > only for SPI controllers actually in use. OK, I will work on s3c64xx driver side, then. Thanks, Andi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |