From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AEEEC433B4 for ; Sat, 8 May 2021 23:04:23 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A31C1613FA for ; Sat, 8 May 2021 23:04:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A31C1613FA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:MIME-Version:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:Subject:In-Reply-To:Cc:To:From :Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MIjsGmtO0Rj89osal/uTX1yCHEN477cRuXgcElVDWRs=; b=B0JPswGVhM50oxbFJtd9vFF79v xTcMA+BdhqYoLxmU3R4d4TKx7cfIFXQ0muXxA9J/zhig43h+9JyrvGyXL1Wlbec8Si+eXibKOHmXK IMcrh27Ft5ME9uI3b4OjnYaEwZoK/Z3nr6nIdwti0O+8yKH/hk8WnFPWXjJUeWCleOXtTKlIGpF0V thdzArNvCle+zSbDQNgrPVVjx5lTg5p28+ikELUbaZy7ENE4jzNweFi3IZtdtrHuZrUTBKGMcRIE7 2A/M6ZTK89OBxggi4sQnXFfR7aWNz2P3LGHDaU9K8HRq8w2tNFtLlsqvgFnxXwh4T8ItKr23tRBWh +zKexTMA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lfVyE-00AVgl-Uc; Sat, 08 May 2021 23:02:51 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lfVyB-00AVge-Os for linux-arm-kernel@desiato.infradead.org; Sat, 08 May 2021 23:02:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Message-ID:References:Subject: In-Reply-To:Cc:To:From:Date:Sender:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description; bh=AxUdDaOfplD+F+5f3hDIBR1V54c9pLFEyO5ztoSS5DE=; b=AkkEnbiD0VNlc2p7zueDoweMUW PNP2LBDLg7uVz/9EiUN/j6gRKX5tTwANakkCwKTdDOCNfYgSm0x1O3HaMyjri++GjaulHuv8kSxYy 75AiJmLGhRAljynAHAo1AOXlUm6zsttzU+AmCDamW++/GzDJviN9EmCAplcGw6rVLfO+ReLoeDnMm gs3tzQ23En51lZC7eMI9GxPub9KEoc+6sJjRtWVsS8FSp5wUSquYvYcD6m9sxwIsfddYd22MUr6tF 01zZmW5D7/Im9d9/esE9HFuIWn6YhPCyJ2sIqzPHC/mNjrOnMmgNbV4Dvizh73BxaT7eZUN91y0TC czfiQCRg==; Received: from sibelius.xs4all.nl ([83.163.83.176]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lfVy7-007lMQ-Uc for linux-arm-kernel@lists.infradead.org; Sat, 08 May 2021 23:02:46 +0000 Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id c9fdf47c; Sun, 9 May 2021 01:02:34 +0200 (CEST) Date: Sun, 9 May 2021 01:02:33 +0200 (CEST) From: Mark Kettenis To: Linus Walleij Cc: kettenis@openbsd.org, krzk@kernel.org, tomasz.figa@gmail.com, maz@kernel.org, devicetree@vger.kernel.org, marcan@marcan.st, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, bgolaszewski@baylibre.com, sven@svenpeter.dev In-Reply-To: (message from Linus Walleij on Sat, 8 May 2021 23:09:55 +0200) Subject: Re: [PATCH 1/2] dt-bindings: pinctrl: Add DT bindings for apple, pinctrl References: <20210508142000.85116-1-kettenis@openbsd.org> <20210508142000.85116-2-kettenis@openbsd.org> Message-ID: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210508_160244_342856_046EB501 X-CRM114-Status: GOOD ( 46.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > From: Linus Walleij > Date: Sat, 8 May 2021 23:09:55 +0200 > > On Sat, May 8, 2021 at 4:20 PM Mark Kettenis wrote: > > > The Apple GPIO controller is a simple combined pin and GPIO conroller > > present on Apple ARM SoC platforms, including various iPhone and iPad > > devices and the "Apple Silicon" Macs. > > > > Signed-off-by: Mark Kettenis Hi Linus, Thanks for taking a look. > I knew this was coming! I saw an earlier version of the Linux > pin control driver in some tree somewhere. That may have been the initial Corellium port. I'm working with the Asahi Linux folks to get something that is a bit more upstreamable and something that works for U-Boot and other OSes too. So these proposed DT bindings deviate a little bit from what Corellium did. > I see we're only discussing bindings right now, but it would be > great to also take a look at the U-Boot driver and scratch Linux > driver (which I bet both exist) for a deeper understanding. > Git tree web links are fine. My U-Boot driver is here: https://github.com/kettenis/u-boot/blob/apple-m1-m1n1-gpio/drivers/pinctrl/pinctrl-apple.c Not yet submitted upstream since that is a bit pointless without an agreed upon binding; typically U-Boot requires a binding that is accepted by the Linux devlopers before accepting patches. Sven Peter may have a draft Linux driver somewhere as he has been working on support for the type-C USB ports, but I haven't seen that part of his code yet. > > +description: | > > + The Apple GPIO controller is a simple combined pin and GPIO controller > > spelling Not sure I'm seeing a spelling mistake here. Do you want a comma inserted somewhere? > > > + present on Apple ARM SoC platforms, including various iPhone and iPad > > + devices and the "Apple Silicon" Macs. > > > +properties: > > + compatible: > > + items: > > + - const: apple,t8103-pinctrl > > + - const: apple,pinctrl > > So is this an entirely Apple thing now, and not based on some Samsung > block from S3C like what we have seen before? As far as I can tell, yes. This Apple controller has a single register per pin that controls the muxing and gpio functions, whereas the S3C controller seems to have 4 registers per pin. In the Apple device tree this controller has a "gpio,t8101" compatible property which suggests that this particular incarnation was introduced with the the T8101 SoC (marketed as A14 and found in the iPhone 12). Of course that's just an educated guess. > It'd be great if Krzysztof or Tomasz who have experience with the > Samsung hardware could have a look at the registers etc in the > drivers and confirm or clear any relationship to Samsung hardware. > > This would partly involve trying to keep the pin control bindings > similar to Samsungs if there is a relationship. > > If there is no relationship, then we invent something new. > > All looks pretty good, but I am suspicious about this: > > > + interrupts: > > + minItems: 1 > > + maxItems: 7 > > Which is used like that. > > > + interrupt-controller; > > + interrupt-parent = <&aic>; > > + interrupts = , > > + , > > + , > > + , > > + , > > + , > > + ; > > First it is really odd with 7 of something as in all computer > science but I guess there is some explanation for that. No kidding. But all 4 controllers present on the SoC have 7 interrupts assigned to them in the Apple device tree. > What I am really wondering is if these interrupts are hierarchical, > i.e. that they match 1-to-1 to a GPIO line. They don't match 1-1. The GPIOs can be assigned to one of (apparently) 7 interrupt groups. I haven't looked to closely at this yet since U-Boot doesn't need/use the interrupt capability. But I suspect that pins don't have to be assigned to a interrupt group and that explains why there are only 7 interrupt groups as the 8th state is reserved for "unasigned". The number of pins per controller varies, but one of them has 212 pins. > We only (ideally) define the interrupts when it is used by the > GPIO block itself, such as when it spawns a cascaded interrupt > controller (i.e. you need to read status bits inside the GPIO > controller to figure out which line was fired). Multiple pins can be assigned to the same interrupt group as far as I can tell. So in that case the driver will have to look at status bits. > If the interrupt has a 1-to-1 mapping between GPIO lines and > the parent interrupt controller we usually do not define these > interrupts in the device tree at all. > > In those cases the interrupt is considered hierarchical and we > rely on the compatible for the block to define how the > interrupt lines are routed to the parent interrupt controller > (in this case AIC). > > In the Linux case, the GPIO driver has a hardcoded table > of mappings from the GPIO irq line offset and the corresponding > index on the parent interrupt controller (AIC). > > This is reflected in this IRQ routing information missing > from the bindings. > > Marc Zyngier can probably tell the story of why it is handled > like this, Ok, hopefully Marc can say something sensible here, but I'd say the interrupts on this hardware are cascaded. > There is some info on hierarchical IRQ handling in the > Linux GPIO driver docs: > https://www.kernel.org/doc/html/latest/driver-api/gpio/driver.html > Section "GPIO drivers providing IRQs" > > Yours, > Linus Walleij > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel