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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 872BFC433ED for ; Sat, 8 May 2021 21:10:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 50DFC61352 for ; Sat, 8 May 2021 21:10:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229641AbhEHVLL (ORCPT ); Sat, 8 May 2021 17:11:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229559AbhEHVLK (ORCPT ); Sat, 8 May 2021 17:11:10 -0400 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9417CC061574 for ; Sat, 8 May 2021 14:10:08 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id w15so15979196ljo.10 for ; Sat, 08 May 2021 14:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m9+3noXngizjhhrRMZhk48zpVxasYuaz+6Rq3HmU5os=; b=t7yafSULJecEnKd2MYd23rEXI4UL7T3aYFjfUq+3PyWNhrGe3FQHVQlJmql5r9M26J ZB9uJ8Y14duaNd6UgXwfGpOEs1ZusTgSZFNTF3M/2l0a24T7wTs2kZofzSszfecq2+ba yPD9RVXrM9lZIr4rvmAc54o4pvDtUMxWC22vZbPE6Om5EPgbYy95KmyfGW2M87VWGG6h uIRx+ZM1OuehsFMec/kaHnNRnBqhzNK7zY4fEhopiRGuvTTywTGBZvgnt+df2me3+HTL +YB1tO1T6EgmyluAq7qiTDVMK46/xMpBjfrxC06SRnRL/rPx6xI32N7DQe50E+XB6XqU 7M7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m9+3noXngizjhhrRMZhk48zpVxasYuaz+6Rq3HmU5os=; b=qJwcDwdpqZU4LgX+NWjwS8hM7FA26L+aw4yloFLno817lX/Wnu+6eP46f/VG3aavDy N+Iz3pt4XIThht6JeXLXZu7oUNK71Jx5jMf4nhDOiBNIEMr+XOzz7+MAhGhOuH5DEDgs U/D1hBRzpycpZOqVOHUrg8wDv/7U6ePggr3MkgL8bxrw1mKD4jdF4JQT/JkGVNfr13pz VyQKOJZPzhpPZL9hMM3Y2K503mP4nJMzIohdA17UYV2FNunpX4GdsyA8EM9GRtQJgXO4 F3C7jGae8BywwNds4r+tQNP7qlqgOGSe/ZOnV19Bj1j+FuCmiSCgqQQ5WYGYPEPVazRC O7qA== X-Gm-Message-State: AOAM532GStXQ+WTUSzmOiwvusw/aiduoX7RMu4hIgaf+QE1fkHO0LE9p kmwT4UDTbAqM42qT8L0SQjeQ7u9SqylUp3iTA905ssj4yH6aqw== X-Google-Smtp-Source: ABdhPJx9fIpLuRXp6oykG1yO2k3sQMgNWt3rSDIbUp+Ot6stAgiAWOrwYZwqXeakE3J8GDLZmLs4ZF3jjOzuA8DAp7k= X-Received: by 2002:a2e:2e12:: with SMTP id u18mr13206972lju.200.1620508206995; Sat, 08 May 2021 14:10:06 -0700 (PDT) MIME-Version: 1.0 References: <20210508142000.85116-1-kettenis@openbsd.org> <20210508142000.85116-2-kettenis@openbsd.org> In-Reply-To: <20210508142000.85116-2-kettenis@openbsd.org> From: Linus Walleij Date: Sat, 8 May 2021 23:09:55 +0200 Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: pinctrl: Add DT bindings for apple,pinctrl To: kettenis@openbsd.org, Krzysztof Kozlowski , Tomasz Figa , Marc Zyngier Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Hector Martin , Rob Herring , Linux ARM , "open list:GPIO SUBSYSTEM" , linux-kernel , Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org 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 I knew this was coming! I saw an earlier version of the Linux pin control driver in some tree somewhere. 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. > +description: | > + The Apple GPIO controller is a simple combined pin and GPIO controller spelling > + 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? 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. What I am really wondering is if these interrupts are hierarchical, i.e. that they match 1-to-1 to a GPIO line. 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). 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, 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 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=-9.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 5DFC5C433ED for ; Sat, 8 May 2021 21:11:54 +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 D6E6C61041 for ; Sat, 8 May 2021 21:11:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6E6C61041 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jv/ben7VU2LWDdo5LT4OXa1s2oLVmLxJeJVRjz7gXxQ=; b=OYPBbHnTm+MvC1DDFzHKfrCit K7mG7iveiqubc67dV0UpdM0KYjWtZT+6kiR5bYpPw+0q8LhrVq3J73nOGKhXRaQvd/vmLwfxz6UJj o7aHB7UT/qnfip9GNYJmqvkpMHoiVTXWfe/eS8r6citdrjfM3ea7tjxDfXV0WMmPFhzgniMZBgAh+ t6P51Tg2Swx/ma3rnSYwb02O/TamJ8rGo77XwSHZkD0BDmNx/Q4Aq+0NI/V/NhXzmehL2vyQFaVCT VxwKRaExchPDawgBJsqPVBbzPqWjcm/VIbO9hPDStffEtXD17NWsp7Oi7mIvEkfsGqdaybbOztOpV xvEQwGGJA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lfUDJ-00AL9v-4l; Sat, 08 May 2021 21:10:17 +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 1lfUDF-00AL9O-M0 for linux-arm-kernel@desiato.infradead.org; Sat, 08 May 2021 21:10:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=m9+3noXngizjhhrRMZhk48zpVxasYuaz+6Rq3HmU5os=; b=unHRZW64k2WcCE8RUiw9TPFwpr Iv7Ph2ApZGDLgzdaYR6P/dQ7n9bdf88Ee1mjS8dnI8kj91shTeQQVO9WvD5EmWnC1Dtl179s9pSiU ahcgc8JKCD/mK8rXd8XYyhskVce0ooqP3lp60FNOxgmDzlGq4jdAIY869Z7lxYnncda1CrR0tMEhP BppLez3NO9OR6+t6yC7tm+4UUo6W2F+m0W7AxS0p1aY6sjQ5Ne1obqXtkO8Q82zGYqp2PnIu3GzW5 vUZMr3pkri9YkVNzquHEXNrLSsPzAnJYMF02/ppYPg3xRKxxEwOsJkD1m+dzw7L5N1qFkFRsW8i6P lkNt/FOw==; Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lfUDC-007ikQ-A0 for linux-arm-kernel@lists.infradead.org; Sat, 08 May 2021 21:10:12 +0000 Received: by mail-lj1-x22b.google.com with SMTP id b7so16000983ljr.4 for ; Sat, 08 May 2021 14:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m9+3noXngizjhhrRMZhk48zpVxasYuaz+6Rq3HmU5os=; b=t7yafSULJecEnKd2MYd23rEXI4UL7T3aYFjfUq+3PyWNhrGe3FQHVQlJmql5r9M26J ZB9uJ8Y14duaNd6UgXwfGpOEs1ZusTgSZFNTF3M/2l0a24T7wTs2kZofzSszfecq2+ba yPD9RVXrM9lZIr4rvmAc54o4pvDtUMxWC22vZbPE6Om5EPgbYy95KmyfGW2M87VWGG6h uIRx+ZM1OuehsFMec/kaHnNRnBqhzNK7zY4fEhopiRGuvTTywTGBZvgnt+df2me3+HTL +YB1tO1T6EgmyluAq7qiTDVMK46/xMpBjfrxC06SRnRL/rPx6xI32N7DQe50E+XB6XqU 7M7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m9+3noXngizjhhrRMZhk48zpVxasYuaz+6Rq3HmU5os=; b=pHcx6Wr/fNCZaqkRwOgiSxI9QB7TvSPAhKxLkkXbDzynQqqgkI32/Y5XUh42x/N6oj 4IxEOdZSCviRCnBGbP1+O5s/GhPn+sPa8NIv0QoMDUG+QPLgHkxOPdi5kTgtL4nNhxEc 5AER569yecDtBzdNVvoN2XwGAkYnl2WaRjXzZDGVl6Zz6CB4fmyFt3ZMAFurogYOOkWB BBzyS2ythXjy3o5m5peyAKY1+yYkexFM+zA59ONgPjuhbdYlCS0IZWj6xAPfamE0W6du f1Dn/fyV/cKOnpb2zfLbed8lUZCvZejGrdLrLWjSdwm6bslCkzC0AxycXGUKk8dcAGhm xiMA== X-Gm-Message-State: AOAM530tWTJ8lTRCUJ0f/hhTIFX2kRqpkGqLs1G1r/imzwN8FfIvbyZ6 IITiE8b27W7zPNkxoLq/zdCpZof1I+8kIXjRpzs9Hw== X-Google-Smtp-Source: ABdhPJx9fIpLuRXp6oykG1yO2k3sQMgNWt3rSDIbUp+Ot6stAgiAWOrwYZwqXeakE3J8GDLZmLs4ZF3jjOzuA8DAp7k= X-Received: by 2002:a2e:2e12:: with SMTP id u18mr13206972lju.200.1620508206995; Sat, 08 May 2021 14:10:06 -0700 (PDT) MIME-Version: 1.0 References: <20210508142000.85116-1-kettenis@openbsd.org> <20210508142000.85116-2-kettenis@openbsd.org> In-Reply-To: <20210508142000.85116-2-kettenis@openbsd.org> From: Linus Walleij Date: Sat, 8 May 2021 23:09:55 +0200 Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: pinctrl: Add DT bindings for apple, pinctrl To: kettenis@openbsd.org, Krzysztof Kozlowski , Tomasz Figa , Marc Zyngier Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Hector Martin , Rob Herring , Linux ARM , "open list:GPIO SUBSYSTEM" , linux-kernel , Bartosz Golaszewski X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210508_141010_478870_0B7B0AA8 X-CRM114-Status: GOOD ( 29.51 ) 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: , 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 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 I knew this was coming! I saw an earlier version of the Linux pin control driver in some tree somewhere. 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. > +description: | > + The Apple GPIO controller is a simple combined pin and GPIO controller spelling > + 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? 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. What I am really wondering is if these interrupts are hierarchical, i.e. that they match 1-to-1 to a GPIO line. 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). 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, 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