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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B7BAC4332F for ; Fri, 1 Oct 2021 15:27:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A3BF61A6F for ; Fri, 1 Oct 2021 15:27:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232344AbhJAP27 (ORCPT ); Fri, 1 Oct 2021 11:28:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232086AbhJAP27 (ORCPT ); Fri, 1 Oct 2021 11:28:59 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A26D0C06177E for ; Fri, 1 Oct 2021 08:27:14 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id qe4-20020a17090b4f8400b0019f663cfcd1so3124195pjb.1 for ; Fri, 01 Oct 2021 08:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NDBF0d4bKXIj7mL5yYNHBXYAg7HQa1G1QOL0lrIIjuQ=; b=vyCE1SjTyUO59YshqoxCZREYCGmX1MLlD2wPH86txBGh9li4OkL1kVFk49gHlm1VaD ftZLw4tkzhpF5hlX2FiAddEp3MvH4L4Fg1Mu1TLOsaieKla+AmpvH5c4iQ3aOZdX7oJz J/pGhZFBosmhuydsPFT3/19gQUVWyqr0eY8Ghyjckm8+STHJ+H6Q3LINLYMkm4Tb/VWo NQFkzjZU7JhIkTJrzj0vuwTjz49j6dfiPPG5QsH1KGBsWpu6suruD2Zoqy6ujUV0mXRr zpx/0+szWfgVfjxzN57nEoskVnF5Aq/8+LXxY5e8sLc4+/IuGcxQc+oC0D/0qQqUcHIX l9ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NDBF0d4bKXIj7mL5yYNHBXYAg7HQa1G1QOL0lrIIjuQ=; b=7IOOOX+Ds/F1XF1TLG+YajE/giTEsrFW2zw1V2Hxqoxby2xD6LBfdY1YbTX2OJrjpX 8GEIM3B6+xVlRPi0ru4mfFItcaIlDK/n6DaAjt6LkEdkjDQWRyLrFKtw16KDv58hs3gr bVcOse0LQndJPHmZA9fOy9tapLLk9TmkS20PW/ZB+ST/rcbuTIGBEvZfx4w8osNTtgIR z9SMVipv9rcoaCffv1kjCkSG/plZ+9kp7RE3ArJSC3AgujgSDEhByRQeJl4XZfeSLks1 nYGcUzXGTM0IOyGoHe94MKWL1dk12maJVRhI/TGsBRBa04Xtp/bzlsehWTWVdvxJEm/x 4dFQ== X-Gm-Message-State: AOAM530q/BvWd8Poiobf3rnD7CTtf7jbsTta3GNo9hdBAdR0vOxevrS8 62MHgkqNWAaje2YrGSdnzTd3GPUvyW6Gw60Uy/f1hA== X-Google-Smtp-Source: ABdhPJw+H/uBI4TBsasR8eBHLbgky559HD5gbdguuPNsq60YvUyVD3gt7UgsIT81kS73NIa4qmiR13/eOF+1CUlO760= X-Received: by 2002:a17:902:c193:b0:13e:8e77:6c82 with SMTP id d19-20020a170902c19300b0013e8e776c82mr1802110pld.29.1633102033855; Fri, 01 Oct 2021 08:27:13 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Olof Johansson Date: Fri, 1 Oct 2021 08:27:02 -0700 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Arnd Bergmann Cc: Geert Uytterhoeven , Saravana Kannan , Will McVicker , Krzysztof Kozlowski , Russell King , Catalin Marinas , Will Deacon , Michael Turquette , Stephen Boyd , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Linus Walleij , Alessandro Zummo , Alexandre Belloni , John Stultz , Thomas Gleixner , Lee Jones , "Cc: Android Kernel" , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk , "open list:GPIO SUBSYSTEM" , linux-rtc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann wrote: > > On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven wrote: > > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan wrote: > > > GIC and arch timer. Basically the minimal kernel would need a timer > > > for the scheduler tick and IRQ controller to get the timer IRQ and the > > > fixed clock driver if the archtimer uses one to get its frequency and > > > the early UART console is pointless as a module (so build it in to > > > allow debugging/development). > > > > > > And then all new drivers, we should make sure are implemented as > > > tristate drivers. And we can go back and slowly work on converting > > > existing drivers to modules (community effort -- not one person or > > > entity) -- at least the ones where the author has hardware or ones > > > where the change is very likely to be correct and someone else is > > > willing to test it. We'll never be able to support some/all ARM32 (do > > > they even have a GIC/arch timer standard?), but at least for ARM64, > > > this seems like a viable goal. > > > > Cortex-A7/A15 and later have GIC and architectured timer, so it should > > work for contemporary systems. > > Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've > > seen SoCs where the interrupt for the latter was not wired :-(. > > There are a number of well-known examples even with 64-bit chips or > Cortex-A7/A15 based SoCs that can't use the architected timer, > irqchip or iommu. > > Apple M1, Broadcom BCM283x, Samsung Exynos5 and > some Hisilicon server parts come to mind, I'm sure there > are more. There's also more and more movement towards having coprocessors with standardized interfaces dealing with this functionality. We're currently at the point where they have coprocessors with non-standardized interfaces, and it's useful to keep encouraging convergence in this area to everybody's benefit. I don't find it particularly useful to make life easier for the custom solutions at the expense of others like this patchset does, when that's (just beyond? on?) the horizon. > > What are the plans for other architectures? > > I've seen similar patches being applied for e.g. MIPS. > > There is some work in the more actively maintained MIPS > platforms to make those behave more like Arm/powerpc/riscv/m68k > platforms, using a single image and moving drivers into modules. > Most MIPS platforms seem unlikely to get updated to this, > and will continue to require a SoC specific kernel binary forever, > similar to the renesas superh platforms. Most of the less > common architectures (arc, csky, hexagon, nios2, xtensa, > microblaze, nds32, openrisc, sparc/leon) are way behind that > though, and generally don't work at all without out-of-tree > code. One of the arguments for needing some of these core drivers in-kernel is that some platforms boot at very conservative DVFS operating points, to a degree that you really want to turn up the CPU clocks fairly early during boot. If you don't have the drivers built-in, you can't do that and/or you create possible fragile or awkward inter-module dependencies with deferred probing, etc. We do care about boot time enough to prefer to just build them in for this reason. If vmlinux binary size is a concern, maybe it's time to consider splitting the drivers into a bare-minimum piece that's not a module for early setup, and the rest that can be loaded post-boot. -Olof 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DB2BC433F5 for ; Fri, 1 Oct 2021 15:29:08 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 45C8661A6F for ; Fri, 1 Oct 2021 15:29:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 45C8661A6F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lixom.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=UI7mwoL/BZrO3KaEAy6zuDUFN1G4/WfoTi9khV0T0KI=; b=vu9hj39c/kBNVW ceBzjtxZ60N3UtwcVpCOGcrjjzpSdC+IT+jYsPDj0BhFjwSgnALGnD608tRuHrP9YInU22rBD/OHn pnOC0p2DNFmZe3bkNkqMIjpdfA2tYdKe1DgQMoQrlQ9fIWesPV5t1C/vzGusfoMfC7PtVkGxxH9ek A2YrP1bkjMU07I7vS5PNaKi+Prh0EPn3OintomT9aPNE3vUGDsfDmroGgcLy2v32/+FDXD7ZglNTl qPoTHrlXSMCDp8UlS8oftKFCTZf0b3WJRuPc88Xk1zKlFRzo5NNoqHXgSvR+9enETXRMy31T8YdFB k8QnA8Fhk7XO+jErWTSA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWKRS-000jYW-IC; Fri, 01 Oct 2021 15:27:18 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWKRO-000jXr-SU for linux-arm-kernel@lists.infradead.org; Fri, 01 Oct 2021 15:27:16 +0000 Received: by mail-pj1-x1029.google.com with SMTP id d4-20020a17090ad98400b0019ece228690so9536206pjv.5 for ; Fri, 01 Oct 2021 08:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NDBF0d4bKXIj7mL5yYNHBXYAg7HQa1G1QOL0lrIIjuQ=; b=vyCE1SjTyUO59YshqoxCZREYCGmX1MLlD2wPH86txBGh9li4OkL1kVFk49gHlm1VaD ftZLw4tkzhpF5hlX2FiAddEp3MvH4L4Fg1Mu1TLOsaieKla+AmpvH5c4iQ3aOZdX7oJz J/pGhZFBosmhuydsPFT3/19gQUVWyqr0eY8Ghyjckm8+STHJ+H6Q3LINLYMkm4Tb/VWo NQFkzjZU7JhIkTJrzj0vuwTjz49j6dfiPPG5QsH1KGBsWpu6suruD2Zoqy6ujUV0mXRr zpx/0+szWfgVfjxzN57nEoskVnF5Aq/8+LXxY5e8sLc4+/IuGcxQc+oC0D/0qQqUcHIX l9ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NDBF0d4bKXIj7mL5yYNHBXYAg7HQa1G1QOL0lrIIjuQ=; b=Bo1uQRw43B/UqIxofDnW/rToSzcr08s101DWi2duprXnht3EjdY5YfaOsyUaGU2yaG w5x9uL5Bw5f5YV2rcX/+BvW3cKOOTsIDL+PhfoCzOQq+qhKKuZR6pMKvrppc9BoczU2f 9W9cqQ3QqeCXvmeJ6d+oTp8jiSIK4ARjufQql8NngxY6+tgO3lmnZBnkAGptBiZ7cWNq xEMtqwPiK66lmZhDHqIB7oTdj7smNnaxZavsDoBG9h/BI4anwsxXf0RmMH4EKDkUY2u0 pfkEAFks8xkIBSen42eMoXbmC0P3U0KzDYMfZhAwfrvkhqYtXELXV+AYgP3UGRcRZycv JqDQ== X-Gm-Message-State: AOAM532SI3Hcf+W2TV/DalpFZ078yurG/teV4hQ+Yr0dW3gKX3m7fjMT RR14p0EugCtnNcC0AMsrfJvEyD5YjUQoF4uEkCunJQ== X-Google-Smtp-Source: ABdhPJw+H/uBI4TBsasR8eBHLbgky559HD5gbdguuPNsq60YvUyVD3gt7UgsIT81kS73NIa4qmiR13/eOF+1CUlO760= X-Received: by 2002:a17:902:c193:b0:13e:8e77:6c82 with SMTP id d19-20020a170902c19300b0013e8e776c82mr1802110pld.29.1633102033855; Fri, 01 Oct 2021 08:27:13 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Olof Johansson Date: Fri, 1 Oct 2021 08:27:02 -0700 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Arnd Bergmann Cc: Geert Uytterhoeven , Saravana Kannan , Will McVicker , Krzysztof Kozlowski , Russell King , Catalin Marinas , Will Deacon , Michael Turquette , Stephen Boyd , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Linus Walleij , Alessandro Zummo , Alexandre Belloni , John Stultz , Thomas Gleixner , Lee Jones , "Cc: Android Kernel" , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk , "open list:GPIO SUBSYSTEM" , linux-rtc@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211001_082715_000630_32A7237F X-CRM114-Status: GOOD ( 39.29 ) 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 Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann wrote: > > On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven wrote: > > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan wrote: > > > GIC and arch timer. Basically the minimal kernel would need a timer > > > for the scheduler tick and IRQ controller to get the timer IRQ and the > > > fixed clock driver if the archtimer uses one to get its frequency and > > > the early UART console is pointless as a module (so build it in to > > > allow debugging/development). > > > > > > And then all new drivers, we should make sure are implemented as > > > tristate drivers. And we can go back and slowly work on converting > > > existing drivers to modules (community effort -- not one person or > > > entity) -- at least the ones where the author has hardware or ones > > > where the change is very likely to be correct and someone else is > > > willing to test it. We'll never be able to support some/all ARM32 (do > > > they even have a GIC/arch timer standard?), but at least for ARM64, > > > this seems like a viable goal. > > > > Cortex-A7/A15 and later have GIC and architectured timer, so it should > > work for contemporary systems. > > Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've > > seen SoCs where the interrupt for the latter was not wired :-(. > > There are a number of well-known examples even with 64-bit chips or > Cortex-A7/A15 based SoCs that can't use the architected timer, > irqchip or iommu. > > Apple M1, Broadcom BCM283x, Samsung Exynos5 and > some Hisilicon server parts come to mind, I'm sure there > are more. There's also more and more movement towards having coprocessors with standardized interfaces dealing with this functionality. We're currently at the point where they have coprocessors with non-standardized interfaces, and it's useful to keep encouraging convergence in this area to everybody's benefit. I don't find it particularly useful to make life easier for the custom solutions at the expense of others like this patchset does, when that's (just beyond? on?) the horizon. > > What are the plans for other architectures? > > I've seen similar patches being applied for e.g. MIPS. > > There is some work in the more actively maintained MIPS > platforms to make those behave more like Arm/powerpc/riscv/m68k > platforms, using a single image and moving drivers into modules. > Most MIPS platforms seem unlikely to get updated to this, > and will continue to require a SoC specific kernel binary forever, > similar to the renesas superh platforms. Most of the less > common architectures (arc, csky, hexagon, nios2, xtensa, > microblaze, nds32, openrisc, sparc/leon) are way behind that > though, and generally don't work at all without out-of-tree > code. One of the arguments for needing some of these core drivers in-kernel is that some platforms boot at very conservative DVFS operating points, to a degree that you really want to turn up the CPU clocks fairly early during boot. If you don't have the drivers built-in, you can't do that and/or you create possible fragile or awkward inter-module dependencies with deferred probing, etc. We do care about boot time enough to prefer to just build them in for this reason. If vmlinux binary size is a concern, maybe it's time to consider splitting the drivers into a bare-minimum piece that's not a module for early setup, and the rest that can be loaded post-boot. -Olof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel