From patchwork Mon Feb 1 21:17:22 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Heiko_St=C3=BCbner?= X-Patchwork-Id: 8183671 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D9BD59F3CD for ; Mon, 1 Feb 2016 21:17:37 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0637920256 for ; Mon, 1 Feb 2016 21:17:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 06AC320221 for ; Mon, 1 Feb 2016 21:17:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753545AbcBAVRe (ORCPT ); Mon, 1 Feb 2016 16:17:34 -0500 Received: from gloria.sntech.de ([95.129.55.99]:34527 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751525AbcBAVRe (ORCPT ); Mon, 1 Feb 2016 16:17:34 -0500 Received: from ip9234aabf.dynamic.kabel-deutschland.de ([146.52.170.191] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aQLqd-0002pQ-35; Mon, 01 Feb 2016 22:17:23 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: "David.Wu" Cc: David Wu , khilman@kernel.org, nm@ti.com, huangtao@rock-chips.com, cf@rock-chips.com, zyw@rock-chips.com, xjq@rock-chips.com, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] PM / AVS: rockchip-io: add GRF and PMUGRF types to distinguish Date: Mon, 01 Feb 2016 22:17:22 +0100 Message-ID: <5354361.hQXgJ7cEGx@diego> User-Agent: KMail/4.14.10 (Linux/4.2.0-1-amd64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <56AF1D4E.40307@rock-chips.com> References: <1454155305-55516-1-git-send-email-david.wu@rock-chips.com> <5387650.lAgTxexlF2@phil> <56AF1D4E.40307@rock-chips.com> MIME-Version: 1.0 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi David, Am Montag, 1. Februar 2016, 16:54:38 schrieb David.Wu: > ? 2016/1/30 20:39, Heiko Stuebner ??: > > Am Samstag, 30. Januar 2016, 20:01:45 schrieb David Wu: > >> As rk3368 contained two separated iodomain areas, this was > >> determined to use which regmap base address. > >> > >> Signed-off-by: David Wu > > > > I don't think we need to specify this on a driver level. Both GRF areas > > are > > "General register files" only located in two separate power-domains. > > So the rockchip,grf property should work for both. Especially as nothing > > keeps designers from introducing yet another GRF-area somewhere else ;-) > > > > >From when I started working on the rk3368, I still have a preliminary > > > > patches for that sitting here, so I've attached on how I envisoned that to > > work. > > Okay, i agree to you, but it make someone a little confused just from > the drive code, > not DT file, about pmugrf regmap base address.:-) > > How do you feel about intergating GRF and PMU drivers in one driver? > Thanks! I will very strongly disagree here ;-) . Similar to the power-domains being part of the pmu, the io-domains are part of their individual GRFs. So if you want it really clean and tidy the way to go foward will be the attached patches. Compile-tested only. Other things like the usbphy control should move there as well in the long run. But that's not immediate necessary. Heiko From 116217957ec3910b9dc05420441848f3343e450e Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Mon, 1 Feb 2016 22:09:03 +0100 Subject: [PATCH 2/3] arm64: dts: rockchip: make grf syscons simple-mfds The general register files do contain a lot of separate functions and while some really are only registers with a lot of different 1-bit settings, there are also a lot of them containing some bigger function blocks. To be able to define these as sub-devices, make them simple-mfds. Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi index 122777b..4fc28e9 100644 --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi @@ -554,7 +554,7 @@ }; pmugrf: syscon@ff738000 { - compatible = "rockchip,rk3368-pmugrf", "syscon"; + compatible = "rockchip,rk3368-pmugrf", "syscon", "simple-mfd"; reg = <0x0 0xff738000 0x0 0x1000>; }; @@ -567,7 +567,7 @@ }; grf: syscon@ff770000 { - compatible = "rockchip,rk3368-grf", "syscon"; + compatible = "rockchip,rk3368-grf", "syscon", "simple-mfd"; reg = <0x0 0xff770000 0x0 0x1000>; }; -- 2.6.4