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

From: Philipp Zabel <p.zabel@pengutronix•de>
To: Fancy Fang <chen.fang@nxp•com>,
	"shawnguo@kernel•org" <shawnguo@kernel•org>,
	 "s.hauer@pengutronix•de" <s.hauer@pengutronix•de>
Cc: dl-linux-imx <linux-imx@nxp•com>,
	"festevam@gmail•com" <festevam@gmail•com>,
	"linux-arm-kernel@lists•infradead.org"
	<linux-arm-kernel@lists•infradead.org>,
	"kernel@pengutronix•de" <kernel@pengutronix•de>,
	"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>
Subject: Re: [PATCH] reset: Add driver for dispmix reset
Date: Thu, 27 Jun 2019 09:05:28 +0200	[thread overview]
Message-ID: <1561619128.4216.3.camel@pengutronix.de> (raw)
In-Reply-To: <AM6PR04MB49369AD1DE69A51B38471608F3E20@AM6PR04MB4936.eurprd04.prod.outlook.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel