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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 11F62C433F5 for ; Sat, 18 Sep 2021 07:23:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DE45A60238 for ; Sat, 18 Sep 2021 07:23:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242984AbhIRHYe (ORCPT ); Sat, 18 Sep 2021 03:24:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231351AbhIRHYc (ORCPT ); Sat, 18 Sep 2021 03:24:32 -0400 Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F831C061574; Sat, 18 Sep 2021 00:23:09 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id t200so4603517vkt.0; Sat, 18 Sep 2021 00:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TJsSrAwWhlsa4DGBFOs0h4d6FtyaUOuEZliDLkcdxh8=; b=Pgv1nGguzHCSVuwqumEkVRZVgJtK/RIv1yTLpNHD2vMciWt2O9RJ2D0z0TQrcwbNl4 KtwVre9j8gbz0Cadij2psVnViTcvjBaoMPt3RDkqgufeYgLGcG59qSIebbQUMwgZVRzC JTE+yQy6fQfLArLKWngoDZ2l98IwjJwGpRXtzlaJWSHFpJsd7FhOp4Il9rSeUIwQDGii bXP6Ia66qPzrX85PZt6xcM5I9W5vRgLod89o/5K4QNKqM7WV2IYrpmf2pl1SrUJwcXwN xIPlcqR0zpqhEgZaeF4p9RHL7xgNOhJv0e5+UXcFRDfW7gjgtOafQb4VlXL/e5/Wy85H D+LA== 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=TJsSrAwWhlsa4DGBFOs0h4d6FtyaUOuEZliDLkcdxh8=; b=cLTrwbZU59o2IPkhx5K6y8hMb2Ji4nEJ6j2BQTrPnK+kQqTqW5NJHr1OciOJPj3ziD EPUhDi7VpPRG0+7EV31sxZ6dRrJHg0C8c3s7m4Ayr2AJGBTVcxuRDP67P2oajDbq2vMz Xu19jU/sV1pqp/rUDJjYHeTXMkquIh3zsmno5YBjSp18nas/MyIK/t2ZuAtjkWTbtiLq eVz+S4ZFh2GO0IvCkzFE9tFzzjOWev9AEhlWV1Y4uF/q/awnIQMeYxl5FPVKLVFO8TwY alp2pd/EIEcgr/dATk6fGtQL7QKJKuc4vvSAkHOfkId9RATFynTkVdw5Dp3gjbA12ljN UUhw== X-Gm-Message-State: AOAM532YIn1VUhh3YW5yPjEP1OIq3CdG1DSwOfsQDRGEcqB03tuSoOp3 LOL5sT2k3/c44WJuc4w9PZHy4esnAhVDAE2KPGA= X-Google-Smtp-Source: ABdhPJz8kzfDXfUg5s+UGhyNC9f4aIPy1Tu+4KVbD72w8T6of9b1In0UX2NsGnCsGYa5CfsfhCWWRL8m/WrPJ5SSpYo= X-Received: by 2002:a1f:b2d6:: with SMTP id b205mr5053277vkf.11.1631949788458; Sat, 18 Sep 2021 00:23:08 -0700 (PDT) MIME-Version: 1.0 References: <20210917035736.3934017-1-chenhuacai@loongson.cn> <20210917035736.3934017-21-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Sat, 18 Sep 2021 15:22:57 +0800 Message-ID: Subject: Re: [PATCH V3 20/22] LoongArch: Add multi-processor (SMP) support To: Arnd Bergmann Cc: Huacai Chen , Andy Lutomirski , Thomas Gleixner , Peter Zijlstra , Andrew Morton , David Airlie , Jonathan Corbet , Linus Torvalds , linux-arch , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Xuefeng Li , Yanteng Si , Jiaxun Yang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Arnd, On Fri, Sep 17, 2021 at 5:57 PM Arnd Bergmann wrote: > > On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen wrote: > > > + > > +struct task_struct; > > + > > +struct plat_smp_ops { > > + void (*send_ipi_single)(int cpu, unsigned int action); > > + void (*send_ipi_mask)(const struct cpumask *mask, unsigned int action); > > + void (*smp_setup)(void); > > + void (*prepare_cpus)(unsigned int max_cpus); > > + int (*boot_secondary)(int cpu, struct task_struct *idle); > > + void (*init_secondary)(void); > > + void (*smp_finish)(void); > > +#ifdef CONFIG_HOTPLUG_CPU > > + int (*cpu_disable)(void); > > + void (*cpu_die)(unsigned int cpu); > > +#endif > > +}; > > > Do you foresee having more than one implementation of these in the > near future? If not, I would suggest leaving out the extra indirection > and just using direct function calls. OK, let me rethink this, if it is still needed, I will tell you why. > > > +#ifdef CONFIG_SMP > > + > > +static inline void plat_smp_setup(void) > > +{ > > + extern const struct plat_smp_ops *mp_ops; /* private */ > > + > > + mp_ops->smp_setup(); > > +} > > + > > +#else /* !CONFIG_SMP */ > > + > > +static inline void plat_smp_setup(void) { } > > + > > +#endif /* !CONFIG_SMP */ > > You could even go further and do what arch/arm64 has, making > SMP support unconditional. This obviously depends on hardware > roadmaps, but if all harfdware you support has multiple cores, > then non-SMP mode just adds complexity. As mentioned in another patch, we do have some MCU hardware (no FP, no SMP, and even no MMU). > > > + > > +#define MAX_CPUS 64 > > You CONFIG_NR_CPUS allows up to 256. I think you need to > adjust one of the numbers to match the other, or remove this > definition and just use CONFIG_NR_CPUS directly. Legacy IPI method only supports at most 64 CPUs (limited by the MMIO register space). Maybe we can remove the whole legacy method support, then we can remove MAX_CPUS, too. > > > + > > +static volatile void *ipi_set_regs[MAX_CPUS]; > > +static volatile void *ipi_clear_regs[MAX_CPUS]; > > +static volatile void *ipi_status_regs[MAX_CPUS]; > > +static volatile void *ipi_en_regs[MAX_CPUS]; > > +static volatile void *ipi_mailbox_buf[MAX_CPUS]; > > Why are these 'volatile'? If they are MMIO registers, they > should be __iomem, and accessed using readl()/writel() > etc Yes, they are MMIO registers and __iomem is needed. Huacai > > Arnd