Re: [PATCH] reset: Add driver for dispmix reset

[Philipp Zabel]

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