From patchwork Thu Nov 17 06:06:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Jeffery X-Patchwork-Id: 9433555 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 138E860238 for ; Thu, 17 Nov 2016 06:09:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 038A528938 for ; Thu, 17 Nov 2016 06:09:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EC0062924C; Thu, 17 Nov 2016 06:09:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=2.0 tests=BAYES_00,DKIM_ADSP_ALL, DKIM_SIGNED,RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7E61128938 for ; Thu, 17 Nov 2016 06:09:13 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7FrA-000886-7r; Thu, 17 Nov 2016 06:07:32 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7Fr5-00086w-KU for linux-arm-kernel@lists.infradead.org; Thu, 17 Nov 2016 06:07:29 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7D76520618; Thu, 17 Nov 2016 01:07:03 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 17 Nov 2016 01:07:03 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aj.id.au; h=cc :date:from:message-id:subject:to:x-me-sender:x-me-sender :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Gez84v1hMqJnMXrkCfSGswT/jd4 =; b=g5nNx++XXn++3u6KhJOtqMzvuvmkGBli0a1PlFw9tH0wfv8+c/PU2t6wD+v 2OOnuk0qsWAGCD3fYrouhVcafoXrUmdNrpKgbAQYyy6M3mwAyLbPHWiOsXqwLIND bI+tUnb8oFJJ/B3WFFwK7rLCChy3VBPw4eiSba4I0G6vkFpw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Ge z84v1hMqJnMXrkCfSGswT/jd4=; b=LUjFsINg6Wyx+n+i2Fpj2aviEVU6YInCOB DnoE7JzR6isYrZGl4y4qEUcYkKltH6UKOE+/YstVXKZtZuQw/RT8VjWo1XVL0hCx BDHkdcwh8eJYqOK2h2LnHrpvNpLDg69Bzi63ERSB0XBHKA7Slc4B6vomEuGJOo09 HXd5AlOO8= X-ME-Sender: X-Sasl-enc: mEsiUpAxCj6J0u2Iz8dl8KB5CHu9jBl9k2e5zH3wz9H8 1479362822 Received: from keelia.au.ibm.com (unknown [203.0.153.9]) by mail.messagingengine.com (Postfix) with ESMTPA id D307A24426; Thu, 17 Nov 2016 01:06:59 -0500 (EST) From: Andrew Jeffery To: Arnd Bergmann , Lee Jones , Linus Walleij Subject: [RFC PATCH] mfd: dt: Add Aspeed LPC binding Date: Thu, 17 Nov 2016 16:36:33 +1030 Message-Id: <20161117060633.3837-1-andrew@aj.id.au> X-Mailer: git-send-email 2.9.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161116_220727_868278_F433E272 X-CRM114-Status: GOOD ( 21.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Andrew Jeffery , Benjamin Herrenschmidt , linux-kernel@vger.kernel.org, Rob Herring , Joel Stanley , linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Signed-off-by: Andrew Jeffery --- I'd like to start a discussion about how to handle the LPC register space in the Aspeed SoC. There are a number of issues, largely concerned with the layout of the registers but also with the fact that LPC register state is used by the pinmux to determine some pin functionality. So the register layout is problematic. Registers for what I think are coherent pieces of functionality functionality are littered through the layout: Post Code Control registers (PCCR) are interleaved with LPC Host Controller registers (LHCR) which are interleaved with Host Interface Controller registers (HICR) which are segmented by LPC Snoop registers. It seems appropriate that the whole thing is represented as an MFD syscon, with the alternative being writing several distinct drivers that map some number of resources to access all of their registers. The disadvantage of not representing the LPC space as a syscon is the LPC Host Controller driver will need to provide accessor functions for the pinmux driver. Pinmux also depends on bits in the Display Controller, and would need similar accessors provided there. The idea of using syscon regmaps removes the need to write these accessors. If the changes between the AST2400 and AST2500 are anything to go by, the pinmux complexity of the SoCs will only increase which will likely lead to the spread of these accessor functions. Yet another option would be to only expose the LPC Host Controller as a syscon instead of the whole LPC register space. I feel this is a little distasteful as the LHCRs are not in contiguous memory space; as mentioned above they are separated (seemingly randomly) by a PCCR. We could specify the LPC Host Controller as a syscon and provide multiple resources: The syscon implementation consumes the first resource which is what we desire here for use with pinmux, but the driver would be left to map any subsequent resources. That feels odd to me, but I'm interested in arguments for it. We could also map the LPC Host Controller syscon across the offending PCCR, but then any driver developed for the Post Code Controller would have to take a reference to the LPC Host Controller regmap. I feel like we might wind up with a syscon phandle spaghetti across the LPC controller if we use that approach. Finally, the LPC registers can be divided in two: one set for H8S/2168 compatible LPC functionality, and the rest for Aspeed-specific registers. Division in two is required if we are going to throw a regmap over the LPC space as the H8S/2168 registers are 1-byte wide, whilst the Aspeed LPC registers are 4-bytes. As far as I can tell we can treat them as separate functionality without any loss; if there is a cross-over in configuration we can have each phandle the other in the devicetree. The final complication is the iBT device sits in the Aspeed-specific part of the LPC controller and has an upstream driver that isn't regmap-capable. Describing the LPC controller as a syscon will require some changes there, but I think we can make it work without too much trouble. What is the recommended approach to managing such hardware? Cheers, Andrew PS: I sent a devicetree binding document out for the LPC Host Controller as part of a recent pinmux series[1]. As it stands the example in the document doesn't cover the all the registers relevant to the LPC Host Controller, which was a motivation for trying to sort the problem out properly. [1] https://www.spinics.net/lists/arm-kernel/msg540084.html .../devicetree/bindings/mfd/aspeed-lpc.txt | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt new file mode 100644 index 000000000000..36c8a9e08dc6 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt @@ -0,0 +1,28 @@ +* Device tree bindings for the Aspeed LPC Controller + +The Aspeed LPC controller contains registers for a variety of functions. Not +all registers for a function are contiguous, and some registers are referenced +by functions outside the LPC controller. + +Note that this is separate from the H8S/2168 compatible register set occupying +the start of the LPC controller address space. + +Some significant functions in the LPC controller: + +* LPC Host Controller +* Host Interface Controller +* iBT Controller +* SuperIO Scratch registers + +Required properties: +- compatible: "aspeed,ast2500-lpc", "syscon" +- reg: contains offset/length value of the Aspeed-specific LPC + memory region. + +Example: + +lpc: lpc@1e7890a0 { + compatible = "aspeed,ast2500-lpc", "syscon"; + reg = <0x1e789080 0x1e0>; +}; +