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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 2CEB9C433EF for ; Mon, 11 Apr 2022 18:13:32 +0000 (UTC) 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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tf7kIQAukaHATARF74Y9iWt67QMZWC13W6pA4iwh/Rs=; b=aC+h181bCc4C52 Bns2/+3sAPkYwW3rwt7Rq3PfYf47LAyIQgBSxrGEh9m1lDv6jwFxU2krM02dmhyWsnKg0U3rJElB6 cAfslcc4kHqd7Af4v+A0zmsMmK1c3dZP0yJ5q1RN3oqbAfYeJFuR5iuqEF/lQy16ythuxV/or4sDs hcKFXsd+jksM/k+O8j1IX0y43MiojCjQ2RLQKDUGdZE9Way+tTsnL1xrln+5+Jxcwakw7kD9pKPp/ AKncZxeAED+3J6VVV3wEsYCM/rdMHNLp0vWjwSWsjIZNyDueHhRU8+d1CEHvpEND2kS1iOQKHRPg+ tYCkQ6+NiR2YeLPbTEGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ndyXX-00A07I-7d; Mon, 11 Apr 2022 18:13:27 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ndyXM-00A03b-73 for linux-mediatek@lists.infradead.org; Mon, 11 Apr 2022 18:13:17 +0000 Received: by mail-pf1-x42f.google.com with SMTP id s8so15257330pfk.12 for ; Mon, 11 Apr 2022 11:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Jw2w5fc9s7LYCxNyjF4Anw/31mGnF1Xnlp2YCJojif4=; b=zYUmChAbevCzMKAOteYpCt8iCZnXii2/ZAqbsWsSzdO+W6XUiXCDFOfEFJO4LuI29J GRfLdTG71rNc/4fdqQ6qUxbUXZRjAg/2nBe3XM+bYVDggr68EsmbxVGph1uscr1XvI7I H9thhM8YlDLthSuyIVx3oKcri5EMQCZNH7Nx7iBufxmFnXpJjfMSVZ1CC/4i58B1ZoSZ pt68xA/6LSO9ec+sEYg8O1wBSGS4tPWSCfCz0lyB+uncZ0kG0QoNZkTTEmpHD+r/98yR ppY5AdTcH52vSTE6T7ECEiu34gSQpmbib1ZrOqRGx9VPczLU12Rjrt+V9ksp8ODe2T0+ LRjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Jw2w5fc9s7LYCxNyjF4Anw/31mGnF1Xnlp2YCJojif4=; b=eY47TaVkcQI/RX4MFahqJFK60hTNNxVtIxP+GtkNEV285qOj7JAY0oDOQRhFt690l0 y5MsqfPNFhFh+bFgYIWeWWGTZvSkjobkFLKOuCJ9BKSb4Lr3nME1BRueT0045YBnfQqJ OGXgJ25kJTcekXm8g9cD+NfRIX5by70UTJtiEmID/YoDow9WaML/ojtU7Iijmnmg0gdm HxQYx5DA+/SaiCRVMvR5PHaIQuOTWP8Dwuj13iJL0adgoSoF9qxuFTOnbLu9sNLgFnW6 ROpE9hohgEo5AzF5ZG+nIJZ0wWwrYVwNUmC8hxPg8Z8xu/0roHqmjszbv4K89jzUJ9ve PxyA== X-Gm-Message-State: AOAM533I5hkp9enfaB4vLDKgrxwGXtuzoI8veT0E+IjrRQRXqbgo8GRW k0Arl4Ho281roMsOyIP1YXqtQw== X-Google-Smtp-Source: ABdhPJwFnQOXCSv95jf3Mtp1Xp4D95v+w5pquv+GUaB8VSDncNnmKQidKvtg+7Fpe/4FvzhLFVMuQw== X-Received: by 2002:a63:6e07:0:b0:398:1337:d99e with SMTP id j7-20020a636e07000000b003981337d99emr27022351pgc.23.1649700793750; Mon, 11 Apr 2022 11:13:13 -0700 (PDT) Received: from localhost (c-71-197-186-152.hsd1.wa.comcast.net. [71.197.186.152]) by smtp.gmail.com with ESMTPSA id x5-20020aa79a45000000b00504a1c8b75asm17752885pfj.165.2022.04.11.11.13.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Apr 2022 11:13:13 -0700 (PDT) From: Kevin Hilman To: Rex-BC Chen , rafael@kernel.org, viresh.kumar@linaro.org, robh+dt@kernel.org, krzk+dt@kernel.org Cc: matthias.bgg@gmail.com, jia-wei.chang@mediatek.com, roger.lu@mediatek.com, hsinyi@google.com, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com Subject: Re: [PATCH V2 13/15] cpufreq: mediatek: Link CCI device to CPU In-Reply-To: References: <20220408045908.21671-1-rex-bc.chen@mediatek.com> <20220408045908.21671-14-rex-bc.chen@mediatek.com> <7hfsmn5m9f.fsf@baylibre.com> Date: Mon, 11 Apr 2022 11:13:12 -0700 Message-ID: <7hwnfv4hfr.fsf@baylibre.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220411_111316_306392_FCEC7805 X-CRM114-Status: GOOD ( 24.00 ) X-BeenThere: linux-mediatek@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-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Rex-BC Chen writes: > On Fri, 2022-04-08 at 13:54 -0700, Kevin Hilman wrote: >> Rex-BC Chen writes: >> >> > From: Jia-Wei Chang >> > >> > In some MediaTek SoCs, like MT8183, CPU and CCI share the same >> > power >> > supplies. Cpufreq needs to check if CCI devfreq exists and wait >> > until >> > CCI devfreq ready before scaling frequency. >> > >> > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will >> > start >> > DVFS when CCI is ready. >> > - Add platform data for MT8183. >> > >> > Signed-off-by: Jia-Wei Chang >> >> The checks here are not enough, and will lead to unexpected behavior. >> IIUC, before doing DVFS, you're checking: >> >> 1) if the "cci" DT node is present and >> 2) if the driver for that device is bound >> >> If both those conditions are not met, you don't actually fail, you >> just >> silently do nothing in ->set_target(). As Angelo pointed out also, >> this >> is not a good idea, and will be rather confusing to users. >> >> The same thing would happen if the cci DT node was present, but the >> CCI >> devfreq driver was disabled. Silent failure would also be quite >> unexpected behavior. Similarily, if the cci DT node is not present >> at >> all (like it is in current upstream DT), this CPUfreq driver will >> silently do nothing. Not good. >> >> So, this patch needs to handle several scenarios: >> >> 1) CCI DT node not present >> >> In this case, the driver should still operate normally. With no CCI >> node, or driver there's no conflict. >> >> 2) CCI DT present/enabled but not yet bound >> >> In this case, you could return -EAGAIN as suggested by Angelo, or >> maybe >> better, it should do a deferred probe. >> >> 3) CCI DT present, but driver disabled >> >> This case is similar to (1), this driver should continue to work. >> >> Kevin > > Hello Kevin and Angelo, > > In my review, if we do not get the link or the link status is not > correct between cci and cpufreq in target_index, I think it will never > established again for this link. > Because it's not checked in probe stage. > > So I think we just need to deal with the issue without cci device, and > don't expect the link between cci and cpufreq will be connected again. > > If I am wrong, please correct me. I don't fully understand your questions, but I think what your getting at suggest that you might need to use deferred probe to handle the case where the ordering of CCI and cpufreq probing is not predictable. Kevin _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0004C433F5 for ; Mon, 11 Apr 2022 18:13:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245626AbiDKSP3 (ORCPT ); Mon, 11 Apr 2022 14:15:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235843AbiDKSP3 (ORCPT ); Mon, 11 Apr 2022 14:15:29 -0400 Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F0A1B85C for ; Mon, 11 Apr 2022 11:13:14 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id s137so12175315pgs.5 for ; Mon, 11 Apr 2022 11:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Jw2w5fc9s7LYCxNyjF4Anw/31mGnF1Xnlp2YCJojif4=; b=zYUmChAbevCzMKAOteYpCt8iCZnXii2/ZAqbsWsSzdO+W6XUiXCDFOfEFJO4LuI29J GRfLdTG71rNc/4fdqQ6qUxbUXZRjAg/2nBe3XM+bYVDggr68EsmbxVGph1uscr1XvI7I H9thhM8YlDLthSuyIVx3oKcri5EMQCZNH7Nx7iBufxmFnXpJjfMSVZ1CC/4i58B1ZoSZ pt68xA/6LSO9ec+sEYg8O1wBSGS4tPWSCfCz0lyB+uncZ0kG0QoNZkTTEmpHD+r/98yR ppY5AdTcH52vSTE6T7ECEiu34gSQpmbib1ZrOqRGx9VPczLU12Rjrt+V9ksp8ODe2T0+ LRjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Jw2w5fc9s7LYCxNyjF4Anw/31mGnF1Xnlp2YCJojif4=; b=7oOsP42XMCYK85c22rlpetc9CKbzlWpmPjYIJpKoi72FKyTvFa3GV8CCLBp8DRQdCD 0jgZ/MFuuQxRu5Oj2Infafv1IZznXfJat9PALhwOMo/2suLMTwAbFnvcuBwmssrSA6s7 2tW9mW4YNEiRq00fQrjj87ywl0ZUQmKDRlyC6EQPWpjTAylqoo1CqPXZbbF0smh1TRpo bY6qKveWXW+e5W7ATA1zpKst7WaJxyrmdcfR4+hmez8gX8z+AbAeyr/qvTgKgWhlfm3o mbryGNJxCCXrFSb3gH3JN0INlIRm12+SkR5MXH7QDBLRQimADPaLE4FFlwEujDI4UjXT HtAw== X-Gm-Message-State: AOAM5338LCI+1VOs2vKDKOqyJza7YcoazqwXxtxwiBEMJLHNMFs5wqwn JogSOy3hI0lfMwGA98sn9ZJiJg== X-Google-Smtp-Source: ABdhPJwFnQOXCSv95jf3Mtp1Xp4D95v+w5pquv+GUaB8VSDncNnmKQidKvtg+7Fpe/4FvzhLFVMuQw== X-Received: by 2002:a63:6e07:0:b0:398:1337:d99e with SMTP id j7-20020a636e07000000b003981337d99emr27022351pgc.23.1649700793750; Mon, 11 Apr 2022 11:13:13 -0700 (PDT) Received: from localhost (c-71-197-186-152.hsd1.wa.comcast.net. [71.197.186.152]) by smtp.gmail.com with ESMTPSA id x5-20020aa79a45000000b00504a1c8b75asm17752885pfj.165.2022.04.11.11.13.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Apr 2022 11:13:13 -0700 (PDT) From: Kevin Hilman To: Rex-BC Chen , rafael@kernel.org, viresh.kumar@linaro.org, robh+dt@kernel.org, krzk+dt@kernel.org Cc: matthias.bgg@gmail.com, jia-wei.chang@mediatek.com, roger.lu@mediatek.com, hsinyi@google.com, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com Subject: Re: [PATCH V2 13/15] cpufreq: mediatek: Link CCI device to CPU In-Reply-To: References: <20220408045908.21671-1-rex-bc.chen@mediatek.com> <20220408045908.21671-14-rex-bc.chen@mediatek.com> <7hfsmn5m9f.fsf@baylibre.com> Date: Mon, 11 Apr 2022 11:13:12 -0700 Message-ID: <7hwnfv4hfr.fsf@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Rex-BC Chen writes: > On Fri, 2022-04-08 at 13:54 -0700, Kevin Hilman wrote: >> Rex-BC Chen writes: >> >> > From: Jia-Wei Chang >> > >> > In some MediaTek SoCs, like MT8183, CPU and CCI share the same >> > power >> > supplies. Cpufreq needs to check if CCI devfreq exists and wait >> > until >> > CCI devfreq ready before scaling frequency. >> > >> > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will >> > start >> > DVFS when CCI is ready. >> > - Add platform data for MT8183. >> > >> > Signed-off-by: Jia-Wei Chang >> >> The checks here are not enough, and will lead to unexpected behavior. >> IIUC, before doing DVFS, you're checking: >> >> 1) if the "cci" DT node is present and >> 2) if the driver for that device is bound >> >> If both those conditions are not met, you don't actually fail, you >> just >> silently do nothing in ->set_target(). As Angelo pointed out also, >> this >> is not a good idea, and will be rather confusing to users. >> >> The same thing would happen if the cci DT node was present, but the >> CCI >> devfreq driver was disabled. Silent failure would also be quite >> unexpected behavior. Similarily, if the cci DT node is not present >> at >> all (like it is in current upstream DT), this CPUfreq driver will >> silently do nothing. Not good. >> >> So, this patch needs to handle several scenarios: >> >> 1) CCI DT node not present >> >> In this case, the driver should still operate normally. With no CCI >> node, or driver there's no conflict. >> >> 2) CCI DT present/enabled but not yet bound >> >> In this case, you could return -EAGAIN as suggested by Angelo, or >> maybe >> better, it should do a deferred probe. >> >> 3) CCI DT present, but driver disabled >> >> This case is similar to (1), this driver should continue to work. >> >> Kevin > > Hello Kevin and Angelo, > > In my review, if we do not get the link or the link status is not > correct between cci and cpufreq in target_index, I think it will never > established again for this link. > Because it's not checked in probe stage. > > So I think we just need to deal with the issue without cci device, and > don't expect the link between cci and cpufreq will be connected again. > > If I am wrong, please correct me. I don't fully understand your questions, but I think what your getting at suggest that you might need to use deferred probe to handle the case where the ordering of CCI and cpufreq probing is not predictable. Kevin 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 18973C433F5 for ; Mon, 11 Apr 2022 18:14:29 +0000 (UTC) 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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ehnMrxIaeIuZklPnmAVlmOIpobedBYca8+ayZo00bpQ=; b=Apx9vR33NjF6aU BJO4psUXoDM0PhJF53fwOP5NvunpYcSOttNWJhk+7VyWcYHrW/O2gv4rXMEfI6s1EmJBehawQV7Hz WPHaXe86S1HYLlxqX12uymsGAshp8OZ+m6m949/5bBSMiZG8YOis+NMB6FwhY996nBSFwBDiGjay/ o5T2VTiL4Iud0FviI/bTzupjAGU2Z+D3uSfDbcmKhTazAycJSOAVWoTE9eH0BKoFpcEQwr05BDOog 7hFpInuhnHQgCSL8TqhW4PterijuIzOHWYsl0I2Vru3SnfkPA0WL4vGS1mVF+w6c7EJXyqcFOWHiC xuYQe8uluAeJeJprwkTQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ndyXP-00A04s-68; Mon, 11 Apr 2022 18:13:19 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ndyXL-00A03a-WD for linux-arm-kernel@lists.infradead.org; Mon, 11 Apr 2022 18:13:17 +0000 Received: by mail-pg1-x534.google.com with SMTP id t13so14889865pgn.8 for ; Mon, 11 Apr 2022 11:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Jw2w5fc9s7LYCxNyjF4Anw/31mGnF1Xnlp2YCJojif4=; b=zYUmChAbevCzMKAOteYpCt8iCZnXii2/ZAqbsWsSzdO+W6XUiXCDFOfEFJO4LuI29J GRfLdTG71rNc/4fdqQ6qUxbUXZRjAg/2nBe3XM+bYVDggr68EsmbxVGph1uscr1XvI7I H9thhM8YlDLthSuyIVx3oKcri5EMQCZNH7Nx7iBufxmFnXpJjfMSVZ1CC/4i58B1ZoSZ pt68xA/6LSO9ec+sEYg8O1wBSGS4tPWSCfCz0lyB+uncZ0kG0QoNZkTTEmpHD+r/98yR ppY5AdTcH52vSTE6T7ECEiu34gSQpmbib1ZrOqRGx9VPczLU12Rjrt+V9ksp8ODe2T0+ LRjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Jw2w5fc9s7LYCxNyjF4Anw/31mGnF1Xnlp2YCJojif4=; b=mBwcn6DBYpiDYoSwns5/73uoQD8yogWSdjp7eRGEZjiBSn2PNcOQbqi8Kbi43cogBu Jy2ej0LVltaJU97Drf8YxXv7odwVuHasK9w5FvafYeZC2rrqlPyuevdLrE5r4FnurI55 J86nXxNbrANzadds7Vq/bb/Riabx8YeV5950PidllKJHsMTOGE3hbgdRcFAOD8UmlmA9 FeUw8mV+qx4pNIrmtFimC/5vIuin4G8xvy6zR2IXqryvIVcowFkuwRPiEZNpiwYaM6mD n74nMGg/mlqAGgIomjB9hzFjSeokHv1K/d7RIMBRhBlCgVbCs8w0YbT77ZEl6RBrmTus jNMA== X-Gm-Message-State: AOAM530YtlEFaoTWO0ayyp3qjjsVZ3uALF57IoG8WFb6PLqMhDLgDFrf F0eHBcYeYQs0XdNAI+t+5yiblg== X-Google-Smtp-Source: ABdhPJwFnQOXCSv95jf3Mtp1Xp4D95v+w5pquv+GUaB8VSDncNnmKQidKvtg+7Fpe/4FvzhLFVMuQw== X-Received: by 2002:a63:6e07:0:b0:398:1337:d99e with SMTP id j7-20020a636e07000000b003981337d99emr27022351pgc.23.1649700793750; Mon, 11 Apr 2022 11:13:13 -0700 (PDT) Received: from localhost (c-71-197-186-152.hsd1.wa.comcast.net. [71.197.186.152]) by smtp.gmail.com with ESMTPSA id x5-20020aa79a45000000b00504a1c8b75asm17752885pfj.165.2022.04.11.11.13.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Apr 2022 11:13:13 -0700 (PDT) From: Kevin Hilman To: Rex-BC Chen , rafael@kernel.org, viresh.kumar@linaro.org, robh+dt@kernel.org, krzk+dt@kernel.org Cc: matthias.bgg@gmail.com, jia-wei.chang@mediatek.com, roger.lu@mediatek.com, hsinyi@google.com, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com Subject: Re: [PATCH V2 13/15] cpufreq: mediatek: Link CCI device to CPU In-Reply-To: References: <20220408045908.21671-1-rex-bc.chen@mediatek.com> <20220408045908.21671-14-rex-bc.chen@mediatek.com> <7hfsmn5m9f.fsf@baylibre.com> Date: Mon, 11 Apr 2022 11:13:12 -0700 Message-ID: <7hwnfv4hfr.fsf@baylibre.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220411_111316_075493_C4B76A0D X-CRM114-Status: GOOD ( 25.36 ) 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 Rex-BC Chen writes: > On Fri, 2022-04-08 at 13:54 -0700, Kevin Hilman wrote: >> Rex-BC Chen writes: >> >> > From: Jia-Wei Chang >> > >> > In some MediaTek SoCs, like MT8183, CPU and CCI share the same >> > power >> > supplies. Cpufreq needs to check if CCI devfreq exists and wait >> > until >> > CCI devfreq ready before scaling frequency. >> > >> > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will >> > start >> > DVFS when CCI is ready. >> > - Add platform data for MT8183. >> > >> > Signed-off-by: Jia-Wei Chang >> >> The checks here are not enough, and will lead to unexpected behavior. >> IIUC, before doing DVFS, you're checking: >> >> 1) if the "cci" DT node is present and >> 2) if the driver for that device is bound >> >> If both those conditions are not met, you don't actually fail, you >> just >> silently do nothing in ->set_target(). As Angelo pointed out also, >> this >> is not a good idea, and will be rather confusing to users. >> >> The same thing would happen if the cci DT node was present, but the >> CCI >> devfreq driver was disabled. Silent failure would also be quite >> unexpected behavior. Similarily, if the cci DT node is not present >> at >> all (like it is in current upstream DT), this CPUfreq driver will >> silently do nothing. Not good. >> >> So, this patch needs to handle several scenarios: >> >> 1) CCI DT node not present >> >> In this case, the driver should still operate normally. With no CCI >> node, or driver there's no conflict. >> >> 2) CCI DT present/enabled but not yet bound >> >> In this case, you could return -EAGAIN as suggested by Angelo, or >> maybe >> better, it should do a deferred probe. >> >> 3) CCI DT present, but driver disabled >> >> This case is similar to (1), this driver should continue to work. >> >> Kevin > > Hello Kevin and Angelo, > > In my review, if we do not get the link or the link status is not > correct between cci and cpufreq in target_index, I think it will never > established again for this link. > Because it's not checked in probe stage. > > So I think we just need to deal with the issue without cci device, and > don't expect the link between cci and cpufreq will be connected again. > > If I am wrong, please correct me. I don't fully understand your questions, but I think what your getting at suggest that you might need to use deferred probe to handle the case where the ordering of CCI and cpufreq probing is not predictable. Kevin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel