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=-6.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 9768EC43457 for ; Wed, 14 Oct 2020 09:04:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EF5BB20B1F for ; Wed, 14 Oct 2020 09:04:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=jms.id.au header.i=@jms.id.au header.b="Gl6vpxUK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728797AbgJNJEv (ORCPT ); Wed, 14 Oct 2020 05:04:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727382AbgJNJEg (ORCPT ); Wed, 14 Oct 2020 05:04:36 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A07B5C04585B; Tue, 13 Oct 2020 22:28:13 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id o21so1544478qtp.2; Tue, 13 Oct 2020 22:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kB//nqoMYrgFKVVbmCReUvvlCp/OH9pTFa1D0WvNeK8=; b=Gl6vpxUKtK+nwjlLO+SvrSUeR2dC+PEV5wmiGiSO4POlCr4RCSIgQ3LSh9oI8d/GvE 3SCz5zqjFohPG3bpCgc3pDGJbq7kbxfM78TQRlzSzCwMCDAMEbi7r8gN5Lx7EeR9WFzp ASIh0sC7J1hK0xf8PHJlMZ3xfkynkx3r+Txrk= 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=kB//nqoMYrgFKVVbmCReUvvlCp/OH9pTFa1D0WvNeK8=; b=U5oVH4eVCkdJEGqiktlNj6whxDVekGeblMKmTDVtzwKqiP6PnPYJVOGrncCcPuc0m0 W7FU8Cf/cE6L6mVIWhJaM90U7TOroh05mPCgABeR6iKoQ0foPQoSA4W+XRtDKkOkGt8v wEPxx+9c8B8aEywKFgqEDFH0iMD4ckYBntGEQXYzQ3003OQT1sPp6VkdlRPNF97Z2fMI gE1EQCI23EIiXxicJgt+xKDxPXoDY8AXnhXqGhAYLVyOVGuOlZb14i7sYycxYXDWhxUH kJeBvt/vAPpWTcbnSl1n7hm0qmYv6kNzbZ4zLkXKzS4X8si7phpgQE5f8xpWj7vOaCv6 4M7Q== X-Gm-Message-State: AOAM5326xXarde5RpqrbPuLKPZaLWCoNcjZSTV1T/57HTtJazosN3KuF hVE/YuDWIpMW3BpcPRf+d3BAchzN0n5cXoR1Fug= X-Google-Smtp-Source: ABdhPJw24gb5jxVKjUGFnb8ILFTaJiae+ZhEB+sYFIQ/Gi83c+wIbHiQ4g4hFhDiM1oYPQWMGp2dm2s2NPDIVlvVANQ= X-Received: by 2002:ac8:3674:: with SMTP id n49mr3177077qtb.385.1602653292820; Tue, 13 Oct 2020 22:28:12 -0700 (PDT) MIME-Version: 1.0 References: <20200928070108.14040-1-ryan_chen@aspeedtech.com> <20200928070108.14040-2-ryan_chen@aspeedtech.com> <160264382296.310579.9835482254268204873@swboyd.mtv.corp.google.com> In-Reply-To: <160264382296.310579.9835482254268204873@swboyd.mtv.corp.google.com> From: Joel Stanley Date: Wed, 14 Oct 2020 05:28:00 +0000 Message-ID: Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical To: Stephen Boyd Cc: Andrew Jeffery , Michael Turquette , Ryan Chen , BMC-SW , Linux ARM , linux-aspeed , linux-clk@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Oct 2020 at 02:50, Stephen Boyd wrote: > > Quoting Ryan Chen (2020-09-28 00:01:08) > > In ASPEED SoC LCLK is LPC clock for all SuperIO device, UART1/UART2 are > > default for Host SuperIO UART device, eSPI clk for Host eSPI bus access > > eSPI slave channel, those clks can't be disable should keep default, > > otherwise will affect Host side access SuperIO and SPI slave device. > > > > Signed-off-by: Ryan Chen > > --- > > Is there resolution on this thread? Not yet. We have a system where the BMC (management controller) controls some clocks, but the peripherals that it's clocking are outside the BMC's control. In this case, the host processor us using some UARTs and what not independent of any code running on the BMC. Ryan wants to have them marked as critical so the BMC never powers them down. However, there are systems that don't use this part of the soc, so for those implementations they are not critical and Linux on the BMC can turn them off. Do you have any thoughts? Has anyone solved a similar problem already? Cheers, Joel 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=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5EC9EC433DF for ; Wed, 14 Oct 2020 05:29:45 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 E397521582 for ; Wed, 14 Oct 2020 05:29:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oDsfH6Be"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=jms.id.au header.i=@jms.id.au header.b="Gl6vpxUK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E397521582 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jms.id.au 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id: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=cvIrPE/iyNXm9lnQA4/7OUbfNT2k6MOMS4yx7xQGOak=; b=oDsfH6BemV/KIEIMdO5be+yRl P7Y2LTCv5Cl6FhssRPVzwdBoPYoPv83Ho1YCRbnW5H2ThvPqnfsm2IMMHO1jtKFGqlMQmkb64bNkB KHbBMMGzOIjhAJrpqsQ9APMdX5V9TS4nkNj4EfsrB57Z44EAi4DakHhBuoF2w3eCOSiFM589dLwrR bDP4xIS43GdUiCUKfwSbKcZBYMWvADLjxS+Uh2g5ChwPxsIlQLps15jZWnQC9QJ3mUdudDpxPEzQa +UJeVfo0OMMdciCuqPKyOl4RD9EXg/pXHx8wRaRaCoLoNQabZ5FcQpBQNW12nYkTkUBNR38V3kL/I ERyZ1yaOQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSZKl-0008G4-VR; Wed, 14 Oct 2020 05:28:19 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSZKi-0008FW-35 for linux-arm-kernel@lists.infradead.org; Wed, 14 Oct 2020 05:28:17 +0000 Received: by mail-qt1-x844.google.com with SMTP id m9so1509578qth.7 for ; Tue, 13 Oct 2020 22:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kB//nqoMYrgFKVVbmCReUvvlCp/OH9pTFa1D0WvNeK8=; b=Gl6vpxUKtK+nwjlLO+SvrSUeR2dC+PEV5wmiGiSO4POlCr4RCSIgQ3LSh9oI8d/GvE 3SCz5zqjFohPG3bpCgc3pDGJbq7kbxfM78TQRlzSzCwMCDAMEbi7r8gN5Lx7EeR9WFzp ASIh0sC7J1hK0xf8PHJlMZ3xfkynkx3r+Txrk= 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=kB//nqoMYrgFKVVbmCReUvvlCp/OH9pTFa1D0WvNeK8=; b=cJFBC0ZfEfrtzKw/pd3lHkM6lUaFCh7u5/mZWOQiCWDVSPbyeF2HYr1sHNiTYmZnCn OjUcPBYtKcmZyigTpDkvwRqJhtzZxYrNH77gkVm8tD8lPFXLxW5+YzWEvT1puhjsw8jc jBW/Pc+xbdvTUK5BLJMLiFwnfsTGBmnHn+cDfVW+Dt3C8+iq3GGHGDgLRkyrK2IF9i8+ 2CRg89pWa9dqZxF0ITOO0uRVmO4pOtuYS+xA2mTPY3V13vcwUMZrz8Bxn/L0BCCQblox 1ALNuGQgMeSqc0HJLSPQ9nnnhHBdW+JKzR7lsviHgDpf8z4gUT755YP9YlYNTEe4PFev N2zg== X-Gm-Message-State: AOAM532TUEPwdgC8X+AXZV1le9DiyxPVqRBsGAyutLryFcXAzhjyHsxE Jf/RW1MbJTAhHgQNnT1cbrFrdwuLoyCt6QGiIWul783/ X-Google-Smtp-Source: ABdhPJw24gb5jxVKjUGFnb8ILFTaJiae+ZhEB+sYFIQ/Gi83c+wIbHiQ4g4hFhDiM1oYPQWMGp2dm2s2NPDIVlvVANQ= X-Received: by 2002:ac8:3674:: with SMTP id n49mr3177077qtb.385.1602653292820; Tue, 13 Oct 2020 22:28:12 -0700 (PDT) MIME-Version: 1.0 References: <20200928070108.14040-1-ryan_chen@aspeedtech.com> <20200928070108.14040-2-ryan_chen@aspeedtech.com> <160264382296.310579.9835482254268204873@swboyd.mtv.corp.google.com> In-Reply-To: <160264382296.310579.9835482254268204873@swboyd.mtv.corp.google.com> From: Joel Stanley Date: Wed, 14 Oct 2020 05:28:00 +0000 Message-ID: Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical To: Stephen Boyd X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201014_012816_344513_7A16B229 X-CRM114-Status: GOOD ( 13.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: BMC-SW , Ryan Chen , linux-aspeed , Andrew Jeffery , Michael Turquette , Linux Kernel Mailing List , linux-clk@vger.kernel.org, Linux ARM 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 Wed, 14 Oct 2020 at 02:50, Stephen Boyd wrote: > > Quoting Ryan Chen (2020-09-28 00:01:08) > > In ASPEED SoC LCLK is LPC clock for all SuperIO device, UART1/UART2 are > > default for Host SuperIO UART device, eSPI clk for Host eSPI bus access > > eSPI slave channel, those clks can't be disable should keep default, > > otherwise will affect Host side access SuperIO and SPI slave device. > > > > Signed-off-by: Ryan Chen > > --- > > Is there resolution on this thread? Not yet. We have a system where the BMC (management controller) controls some clocks, but the peripherals that it's clocking are outside the BMC's control. In this case, the host processor us using some UARTs and what not independent of any code running on the BMC. Ryan wants to have them marked as critical so the BMC never powers them down. However, there are systems that don't use this part of the soc, so for those implementations they are not critical and Linux on the BMC can turn them off. Do you have any thoughts? Has anyone solved a similar problem already? Cheers, Joel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel