Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp13281813rwb; Sun, 27 Nov 2022 03:08:09 -0800 (PST) X-Google-Smtp-Source: AA0mqf4P8uJZ+IARu5xdguMVwWWFO0pdz5mj4izqtREDbzw2GR6YE+JUDUsBGcEpWxdag1ePPBdH X-Received: by 2002:a17:906:6dc9:b0:7bc:5700:490 with SMTP id j9-20020a1709066dc900b007bc57000490mr9918054ejt.592.1669547289299; Sun, 27 Nov 2022 03:08:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669547289; cv=none; d=google.com; s=arc-20160816; b=XFGop/VFgwpnbcmsIm5Y8D37cjCw0K+NU/MmNPwHLcjySUj2raLr6zgJ5cyj2q6/0A gVlKp+UMgiC0/dmh9ZNw143b9cHZ8b6RIm+OcDUqOifqjW73wHwkf3SKnCzSpjRMna+F a2mdOnLpnHvS+pTqhO33V5WcgYiGfS46aBp/doFx1l2aiy6izUtpK3JkjXkfTsf5C3P/ +PAdG7Z96P7Hptzjn3xpJW0M/iYhVxaxrFVaTyEPCNtEQzdJjVz4WpEg9FrYos4uNJtY M2H73RyyDFC3BzsQBPOXhl5UZoMKkTV4PJIJQnKr3rOoYFZzfC2G5b61ZBPlX0/chxXc JzhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=a/lRJw3Gs/dFweLCVLuIgos8ablOI2qBTJVe/3vTcrU=; b=T6AcA59lxjOp2TLuLFYRsaSX8AhjQVLrpF3GJpb6rV7hQNU3qFdg15aZZDCh3chtD/ WW/9kCGpIcLWJ48ZdHBZ+5OXydKDdfXXsS+u/Zf+tipXx27Y+oRgnRjg2XfuBmFG1J+I W64nr6yubA2lthQC9huuX68RQ6Fa3JLEKxa9LcettQIDLsT6xuTGqD+2xogP1B1bwaP0 8hMp6w5aqBkR4Ta4A0nT8mC8+jLCAWevgGEhuQcnKdpwcZjpQnWy/bw+kbL4ZlZWdIyM EqSYGTu7nTjqvg0R47+OQNfDGnpfAZH/JFwovswsMO8qX0X73Y67Q2U9QpjWwQ74hXch 9ZHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f7-20020a50ee87000000b00461d8ee1316si7269741edr.21.2022.11.27.03.07.49; Sun, 27 Nov 2022 03:08:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229543AbiK0JzY (ORCPT + 84 others); Sun, 27 Nov 2022 04:55:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbiK0JzX (ORCPT ); Sun, 27 Nov 2022 04:55:23 -0500 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0BF412760; Sun, 27 Nov 2022 01:55:21 -0800 (PST) Received: by mail-qt1-f173.google.com with SMTP id l2so4964056qtq.11; Sun, 27 Nov 2022 01:55:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=a/lRJw3Gs/dFweLCVLuIgos8ablOI2qBTJVe/3vTcrU=; b=BTkSMIlD5lD3ZbnfiMATJDoG5jJXcSOvRxTeYzffskdwIygLy1uA+XE9NmLYjwMK49 9XKKfTBsEOjUCQSPhdYG9sIFia2NPP30n/GQ8qaNZgyoqIqwIkMTbXnQSiZ3sYtc+9fu KZ0B3xkZ7eLpL84S0R2ldLif75qiBTglVO7GuOpyrHQwlqKh6fArTh4PP0OEkUW6eCoR XTsOYo/RqF3/BHMTXm7VMPODRqKX/ceA7CcsBotlCl1l7iqW0bT3gJvZoxARq+bfBKOF Hg753X1iBU7/FfZJSZ6kzhFTBbSywLRPBhiqI1xHwMmNpik9yn+YdzRgOTdaWCLEFBXP Rp3g== X-Gm-Message-State: ANoB5pn9Fr73KUTVQAH8UYeB9QMlb9jZe0YZR3QI4/oEplbmDBMwSyo9 9xdo35oTZ0xEwKgjhB8nRzUT5vXLZyzB1A== X-Received: by 2002:a05:622a:514e:b0:3a5:2988:c67c with SMTP id ew14-20020a05622a514e00b003a52988c67cmr31107413qtb.487.1669542920790; Sun, 27 Nov 2022 01:55:20 -0800 (PST) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id z1-20020ac84541000000b003a530a32f67sm5044802qtn.65.2022.11.27.01.55.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Nov 2022 01:55:20 -0800 (PST) Received: by mail-yb1-f170.google.com with SMTP id y83so9941836yby.12; Sun, 27 Nov 2022 01:55:19 -0800 (PST) X-Received: by 2002:a5b:24b:0:b0:6ca:3b11:8d76 with SMTP id g11-20020a5b024b000000b006ca3b118d76mr25273660ybp.202.1669542919298; Sun, 27 Nov 2022 01:55:19 -0800 (PST) MIME-Version: 1.0 References: <20221124172207.153718-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20221124172207.153718-8-prabhakar.mahadev-lad.rj@bp.renesas.com> In-Reply-To: From: Geert Uytterhoeven Date: Sun, 27 Nov 2022 10:55:07 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 7/7] soc: renesas: Add L2 cache management for RZ/Five SoC To: "Lad, Prabhakar" Cc: Samuel Holland , Paul Walmsley , Palmer Dabbelt , Albert Ou , Geert Uytterhoeven , Magnus Damm , Heiko Stuebner , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Guo Ren , Jisheng Zhang , Atish Patra , Anup Patel , Andrew Jones , Nathan Chancellor , Philipp Tomsich , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-renesas-soc@vger.kernel.org, Biju Das , Lad Prabhakar Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Prabhakar, On Sat, Nov 26, 2022 at 10:10 PM Lad, Prabhakar wrote: > On Fri, Nov 25, 2022 at 7:43 PM Samuel Holland wrote: > > On 11/24/22 11:22, Prabhakar wrote: > > > From: Lad Prabhakar > > > > > > On the AX45MP core, cache coherency is a specification option so it may > > > not be supported. In this case DMA will fail. As a workaround, firstly we > > > allocate a global dma coherent pool from which DMA allocations are taken > > > and marked as non-cacheable + bufferable using the PMA region as specified > > > in the device tree. Synchronization callbacks are implemented to > > > synchronize when doing DMA transactions. > > > > > > The Andes AX45MP core has a Programmable Physical Memory Attributes (PMA) > > > block that allows dynamic adjustment of memory attributes in the runtime. > > > It contains a configurable amount of PMA entries implemented as CSR > > > registers to control the attributes of memory locations in interest. > > > > > > Below are the memory attributes supported: > > > * Device, Non-bufferable > > > * Device, bufferable > > > * Memory, Non-cacheable, Non-bufferable > > > * Memory, Non-cacheable, Bufferable > > > * Memory, Write-back, No-allocate > > > * Memory, Write-back, Read-allocate > > > * Memory, Write-back, Write-allocate > > > * Memory, Write-back, Read and Write-allocate > > > > > > This patch adds support to configure the memory attributes of the memory > > > regions as passed from the l2 cache node and exposes the cache management > > > ops. > > > > Forgive my ignorance, but why do you need both a DMA pool and explicit > > cache maintenance? Wouldn't the purpose of marking a memory region as > > permanently non-cacheable be to avoid cache maintenance? And likewise, > > if you are doing cache maintenance anyway, why does it matter if/how the > > memory is cacheable? > > > "Memory, Non-cacheable, Bufferable" raises an AXI signal for > transactions hence needing SW implementation for cache maintenance. > > > > More info about PMA (section 10.3): > > > Link: http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf > > > > > > Signed-off-by: Lad Prabhakar > > > +static int ax45mp_configure_pma_regions(struct device_node *np) > > > +{ > > > + const char *propname = "andestech,pma-regions"; > > > + u32 start, size, flags; > > > + unsigned int entry_id; > > > + unsigned int i; > > > + int count; > > > + int ret; > > > + > > > + count = of_property_count_elems_of_size(np, propname, sizeof(u32) * 3); > > > + if (count < 0) > > > + return count; > > > + > > > + if (count > AX45MP_MAX_PMA_REGIONS) > > > + return -EINVAL; > > > + > > > + for (i = 0, entry_id = 0 ; entry_id < count ; i += 3, entry_id++) { > > > + of_property_read_u32_index(np, propname, i, &start); > > > + of_property_read_u32_index(np, propname, i + 1, &size); > > > + of_property_read_u32_index(np, propname, i + 2, &flags); > > > + ret = ax45mp_sbi_set_pma(start, size, flags, entry_id); > > > + if (!ret) > > > + pr_err("Failed to setup PMA region 0x%x - 0x%x flags: 0x%x", > > > + start, start + size, flags); > > > + } > > > + > > > + return 0; > > > +} > > > > If firmware support is required to set up these PMA regions, why is > > Linux doing this at all? The firmware has access to the devicetree as > > well. It can set this up before entering S-mode, and then you don't need > > to expose this capability via an SBI extension. In fact, firmware could > > generate the reserved-memory node based on these regions at runtime (or > > vice versa). > > > That's a good point. I'll do some research on this and get back. > > Btw are there any existing examples where the firmware adds DT nodes? /memory, reserved-memory, optee on ARM, RPC status on R-Car Gen3/4, ... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds