Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2043710rwd; Mon, 15 May 2023 06:37:47 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7VpIut50ZU0qBe7rfq4Du1iVXEttYS9KoU7A55kdlyum8P+JCpwoZHY9aliBZhNoffZ0ej X-Received: by 2002:a05:6a00:134b:b0:643:b263:404 with SMTP id k11-20020a056a00134b00b00643b2630404mr43877697pfu.33.1684157867174; Mon, 15 May 2023 06:37:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684157867; cv=none; d=google.com; s=arc-20160816; b=bngo2ao5dED7LKvX38r+ZPNOSOo6RYvFur6buZ+hjifE2nXyDlpFAGSxRkam2vVwkZ nfz5fpXiZJsvcB15ruY6opZlqIBfPaeZ/5raMU3X/fcee46hB6Z8d+XEOTVmIjbNiYzb Rllj0LWreb0aC67ojQHwqQPQs12YFvBjj52+Eu2RHRf4WvycV49OXYSrB0Xw2Vwr4327 3tghTRTfJZuT4+bT/6IAbkFOQRqUoPSZnq4ri/RK0pl7V3fKOixdDjOHokPm3ujnrEXh o0TMCqs6b5CsSuieweCe7+fSOvcaZg40keo4lQQRbkuhq1F5DLZbk4fEhYWIH9yehx0l WyuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=pfNV16UMu5FO6CoOIsV4b7HDmZ43b1x2rpHl7CZGmtM=; b=ijJhnNugavJI8hVlRWk1V+Ogkb0NMrPkC+Ui5hs+5Msny2PPH4bHI1QRQ5MldEbB+e 7ohOVT3hKOTr60MqzFQCuT+NpPs8V7OP9dZSBJ5pQ3SlUO9PJG1bz+rtQ8QV/JhHXPGe eiTT3XnsJXOGzpJJK66HWeMju+thw9JCQ0KsiG3Jg80mfsMJsLkSCRCJErbdGRx+CNJE NDGhoELxGmKd0oZ6gWS9RfXq3zsQ8mqF05tl/5z1PIpivuw2GSF2BDtXtkWWQfGKhAbg iBs0QicG+2xmgcqbJFRv13TZZE44Pw/iVEtuVbhjbeYAceC3SEk+6Fv48IBBChvWX01J xaJQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g13-20020aa79dcd000000b0063b8350bdb6si17424443pfq.23.2023.05.15.06.37.32; Mon, 15 May 2023 06:37:47 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242210AbjEONJg (ORCPT + 99 others); Mon, 15 May 2023 09:09:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242311AbjEONJQ (ORCPT ); Mon, 15 May 2023 09:09:16 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 811532D57; Mon, 15 May 2023 06:08:53 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C941B2F4; Mon, 15 May 2023 06:08:56 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C55EF3F67D; Mon, 15 May 2023 06:08:09 -0700 (PDT) Date: Mon, 15 May 2023 14:08:07 +0100 From: Sudeep Holla To: "lihuisong (C)" Cc: Arnd Bergmann , Bjorn Andersson , Matthias Brugger , AngeloGioacchino Del Regno , Shawn Guo , linux-kernel@vger.kernel.org, soc@kernel.org, wanghuiqiang@huawei.com, tanxiaofei@huawei.com, liuyonglong@huawei.com, huangdaode@huawei.com, linux-acpi@vger.kernel.org, Len Brown , "Rafael J. Wysocki" , devicetree@vger.kernel.org, Rob Herring , Frank Rowand , Krzysztof Kozlowski Subject: Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC Message-ID: <20230515130807.pdvx7bxwjkfdsmsr@bogus> References: <20230424073020.4039-1-lihuisong@huawei.com> <20230425103040.znv66k364ant6klq@bogus> <20230425131918.5tf5vot4h7jf54xk@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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 On Thu, May 04, 2023 at 09:16:16PM +0800, lihuisong (C) wrote: > > I'm tring to use CRS with GAS to report PCC channel ID and get other > informations driver need by address. OK you had pcc-chan-id pcc-type and device-flags in the DSD style bindings to begin with. I haven't understood device-flags here so can't comment on that. > I found a way to obtain the generic register information according to > "Referencing the PCC address space" in ACPI spec. > And driver also get the PCC generic register information successfully. > Can you elaborate ? I assume by that you must be able to get pcc-chan-id right ? You must not need pcc-type as the pcc mailbox driver must handle the type for you. If not, we may need to fix or add any missing support. > But I don't know how to set and use the address in PCC register. It must be same as what you would have specified in you new bindings under "pcc-chan-id". I am confused as you say you were able to get the PCC generic register information successfully but you still claim you don't know how to set or use the address. > Where should this address come from? > It seems that ACPI spec is not very detailed about this. > Do you have any suggestions? > I am afraid, I don't have any as I am failing to understand the exact issue you are facing. Let me try to ask the question explicity here: If you are just referring to just the in Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize) then, RegisterAddress is usually the offset in the comms address associated with the PCC subspace ID specified in AccessSize. Yes the use of AccessSize for the PCC subspace ID is bit confusing though. You can either list all the registers with _CRS individually or the driver can just use the PCC subspace ID in AccessSize and keep RegisterAddress = 0 but access individual offset based on its own knowledge. I haven't seen the full driver yet but I assuming that's how you would have used if you went with your DSD pcc-chan-id proposal. > On the other hand, we think that System Memory space + method can also > achieve above goal. What do you think of that? Again I don't understand what you mean by that. -- Regards, Sudeep