On Wed, 2019-06-26 at 06:46 +0000, Fancy Fang wrote: [...] > > The same goes for the clock soft enable bits on i.MX8MM. If those > > bits actually control clock gates, they should not be described as > > reset controls in the device tree. > > [FF] Make sense. The functions provided by the "dispmix reset" is more > likely to be a combination of a clock gating module and a reset > control than a standard reset controller. The reason why I choose > reset framework to implement this device is that: First, this module > is named as "dispmix reset" in the dispmix's design spec, so it gives > me the first impression that it should be acted as a reset controller. > And I'll check this with the IC designer.
Thank you. > Second, the "dispmix reset" is separated from the CCM LPCG module > which is used as the only clock controller device for the whole > platform. So the CCM clock driver seems cannot cover this device. > Last, the "dispmix reset" is shared by all the submodules in the > dispmix, so I abstract this device to be a reset controller driver to > simplify the 'reset' logic for all the submodules drivers. Agreed on both points. > If using clock framework to cover this device, another driver needs to > be implemented. I'll take a close look at it to see if this can > happen. Yes, if my assumptions are correct, it would be good if this could be rewritten as a combined clock and reset driver. There are quite a few examples for this in drivers/clk already. [...] > > Is there any reason not to just use straight readl/writel besides > > the automatic clock handling? > > [FF] Use regmap is for simplifying the register modifications since > the register has no SET or CLR shadow, so when set or clear one bit, > the register needs to be read-and-modify. And besides, the register > access requires disp-apb clock open, and regmap can handle this > properly. Ok, this makes sense to me. regards Philipp