linux-kernel - Re: [PATCH 3/5] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150527072759.GS6325@pengutronix.de>
Date:	Wed, 27 May 2015 09:27:59 +0200
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Yong Wu <yong.wu@...iatek.com>
Cc:	James Liao <jamesjj.liao@...iatek.com>, devicetree@...r.kernel.org,
	Mike Turquette <mturquette@...aro.org>,
	srv_heupstream@...iatek.com, Stephen Boyd <sboyd@...eaurora.org>,
	linux-kernel@...r.kernel.org,
	Henry Chen <henryc.chen@...iatek.com>,
	Ricky Liang <jcliang@...omium.org>,
	Rob Herring <robh+dt@...nel.org>,
	linux-mediatek@...ts.infradead.org,
	Sascha Hauer <kernel@...gutronix.de>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Yingjoe Chen <yingjoe.chen@...iatek.com>,
	Eddie Huang <eddie.huang@...iatek.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 3/5] dt-bindings: ARM: Mediatek: Document devicetree
 bindings for clock controllers

On Wed, May 27, 2015 at 02:12:49PM +0800, Yong Wu wrote:
> On Tue, 2015-05-26 at 13:08 +0200, Sascha Hauer wrote:
> > On Tue, May 26, 2015 at 04:55:36PM +0800, James Liao wrote:
> > > Hi Sascha,
> > > 
> > > On Tue, 2015-05-26 at 09:56 +0200, Sascha Hauer wrote:
> > > > On Thu, May 21, 2015 at 03:12:54PM +0800, James Liao wrote:
> > > > > This adds the binding documentation for the mmsys, imgsys, vdecsys,
> > > > > vencsys and vencltsys controllers found on Mediatek SoCs.
> > > > > 
> > > > > index 0000000..a5b94a7
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
> > > > > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
> > > > > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
> > > > 
> > > > Do these really become multiple drivers so that it's worth abstracting
> > > > them in the clock framework?
> > > 
> > > These clocks need to be controlled among several drivers. For example,
> > > vdecsys clocks will be controlled by VDEC driver (not ready yet) and
> > > MT8173 SMI driver [1]. That means these clocks need a mechanism to share
> > > between these 2 drivers. CCF share clocks by using of reference count,
> > > so I think it's suitable to implement these subsystem clocks.
> > > 
> > > As I know SMI driver need to access clocks among mmsys, imgsys, vdecsys,
> > > vencsys and vencltsys. So in this patch I added clocks of these
> > > subsystems into CCF.
> > > 
> > > [1]
> > > http://lists.infradead.org/pipermail/linux-mediatek/2015-March/000058.html
> > 
> > Looking at the 3.18 tree we have this:
> > 
> > 	vdecsys: vdecsys@...00000 {
> > 		compatible = "mediatek,mt8173-vdecsys", "syscon";
> > 		reg = <0 0x16000000 0 0x1000>;
> > 		#clock-cells = <1>;
> > 	};
> > 
> > 	larb1:larb@...10000 {
> > 		compatible = "mediatek,mt8173-smi-larb";
> > 		reg = <0 0x16010000 0 0x1000>;
> > 		clocks = <&mmsys MM_SMI_COMMON>,
> > 			 <&vdecsys VDEC_CKEN>,
> > 			 <&vdecsys VDEC_LARB_CKEN>;
> > 		clock-names = "larb_sub0", "larb_sub1", "larb_sub2";
> > 	};
> > 
> > I believe that the larb needs the MM_SMI_COMMON clock to modify the larb
> > registers, but is it really necessary to enable VDEC_CKEN and
> > VDEC_LARB_CKEN just to set the F_SMI_MMU_EN bit in the larb?
> Yes. SMI need the two clock while smi work.
> the lastest smi binding is [1].
> smi need "apb" and "smi" clocks.
> 
> [1]http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013025.html
> 
> > 
> > With the above we have the situation that the vdec driver calls into the
> > iommu driver which then calls into the larb driver which calls back into
> > the vdec driver via the clk API. This seems very suspicious.
> iommu driver will call into the larb driver.
> but I don't think the larb driver will call into the vdec driver. is it
> right?

When the larb has clocks from the vdec like in the above example from
the 3.18 kernel then the larb indirectly via the clk API writes to the
vdec register space.
In the latest code you referenced the vdec clocks are no longer assigned
to the larbs. This means we no longer need the vdec clocks abstracted in
CCF.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/