Message ID | 20230704090453.83980-3-william.qiu@starfivetech.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp1082405vqx; Tue, 4 Jul 2023 02:19:29 -0700 (PDT) X-Google-Smtp-Source: APBJJlGyxXm38HCj35/jRjcnnxmrriGCQ25SLleWkC7QzH2nuQd7fo4bjzmwc8o+0917+hHS1wmT X-Received: by 2002:a17:90a:1a0c:b0:262:fba5:2a8e with SMTP id 12-20020a17090a1a0c00b00262fba52a8emr11080174pjk.47.1688462369600; Tue, 04 Jul 2023 02:19:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688462369; cv=none; d=google.com; s=arc-20160816; b=pTOJMK14PjGPfXeczWAJbGi7k7272RrYVIMxM+XYOP4rWMVrNrP6XDQpvqULKAj19w OqLW8jNmrVS5DZinoJyFuXbg76vQYgOnTVL6gGwdEZD01X/B53er39RblMdCwN8cK+zv j8iybcmW3p95y6FmOtayfEU+lCfpGBEGF/C4ldKYx+qMeNlLcXfanIYrNPfLPDoVfRXx byKirl5gdnixOsAzpn9djvoYBOVkxMUBPgT/VrqJ/gi9KsES3+Z4//wpHzfs0th8Q4ax 7vhtT31PWeSXFTxoo8ZVtat8xFp/292d6mTQKICJ7T/3vvFX7skgJFtjwKHLeNY5c8co Cd5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=xluEhI4EKcS6Ela8oCzsYF8MRp2x8idCGb6vy/ZteSc=; fh=9L4c8Y3Ztj8IJEHul2Oxap4WQbV4N6M3aZnulda9XVo=; b=rpkHnImeTqrBmCaBnvwxW3H6RhA/4UQdyhXdeIVTtcGLcGgF5fGBhklhdZEqjZSAA7 StgGnPau1GvazOUNzJHbjUtsB3j330NXeSw1tDri8XDUZQPBidMnOi8iOeJqZ481suLj eTk5T91XyXoDW+jlmXEsCNE467Fcw0yRt8HUOeny8l7iet6ubglMzk34GaO8Bi86vm80 sNeWo8dVW3V4KGInZVOW70o/KWTK0fcwoNtqe2oqwSw5E0iY/qbhID34PZ9v1hmCqE8G OXzcDDHu1q27pnP+elRw0YNgYnJNxTS524ItUBBEm9Qlx1j5M/K0hXJCjLxXtXFVhOuO yB1A== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i9-20020a17090a650900b002509d96227esi22373158pjj.173.2023.07.04.02.19.16; Tue, 04 Jul 2023 02:19:29 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231904AbjGDJFQ convert rfc822-to-8bit (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Tue, 4 Jul 2023 05:05:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231843AbjGDJFG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 4 Jul 2023 05:05:06 -0400 Received: from ex01.ufhost.com (ex01.ufhost.com [61.152.239.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37BB3E6B; Tue, 4 Jul 2023 02:05:00 -0700 (PDT) Received: from EXMBX165.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX165", Issuer "EXMBX165" (not verified)) by ex01.ufhost.com (Postfix) with ESMTP id 9D19D24E2B5; Tue, 4 Jul 2023 17:04:57 +0800 (CST) Received: from EXMBX068.cuchost.com (172.16.6.68) by EXMBX165.cuchost.com (172.16.6.75) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 4 Jul 2023 17:04:56 +0800 Received: from williamqiu-virtual-machine.starfivetech.com (171.223.208.138) by EXMBX068.cuchost.com (172.16.6.68) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 4 Jul 2023 17:04:55 +0800 From: William Qiu <william.qiu@starfivetech.com> To: <devicetree@vger.kernel.org>, <linux-spi@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-riscv@lists.infradead.org> CC: Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Emil Renner Berthing <kernel@esmil.dk>, Ziv Xu <ziv.xu@starfivetech.com>, William Qiu <william.qiu@starfivetech.com> Subject: [PATCH v4 2/3] spi: cadence-quadspi: Add clock configuration for StarFive JH7110 QSPI Date: Tue, 4 Jul 2023 17:04:52 +0800 Message-ID: <20230704090453.83980-3-william.qiu@starfivetech.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230704090453.83980-1-william.qiu@starfivetech.com> References: <20230704090453.83980-1-william.qiu@starfivetech.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [171.223.208.138] X-ClientProxiedBy: EXCAS062.cuchost.com (172.16.6.22) To EXMBX068.cuchost.com (172.16.6.68) X-YovoleRuleAgent: yovoleflag Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770481117649287718?= X-GMAIL-MSGID: =?utf-8?q?1770481117649287718?= |
Series |
Add initialization of clock for StarFive JH7110 SoC
|
|
Commit Message
William Qiu
July 4, 2023, 9:04 a.m. UTC
Add QSPI clock operation in device probe. Signed-off-by: William Qiu <william.qiu@starfivetech.com> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306022017.UbwjjWRN-lkp@intel.com/ Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202306040644.6ZHs55x4-lkp@intel.com/ --- drivers/spi/spi-cadence-quadspi.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
Comments
Hey William, On Tue, Jul 04, 2023 at 05:04:52PM +0800, William Qiu wrote: > Add QSPI clock operation in device probe. > > Signed-off-by: William Qiu <william.qiu@starfivetech.com> > Reviewed-by: Hal Feng <hal.feng@starfivetech.com> > Reported-by: kernel test robot <lkp@intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202306022017.UbwjjWRN-lkp@intel.com/ These Reported-by tags don't seem correct, given they were reports about this patch, not the reason for it - but did you actually check that you fixed the errors that the patch produces? This particular one seems to complain about a hunk that is still in the patch & the CI running on the RISC-V patchwork is complaining about it. Cheers, Conor. > @@ -1840,6 +1858,8 @@ static int cqspi_resume(struct device *dev) > struct spi_master *master = dev_get_drvdata(dev); > > clk_prepare_enable(cqspi->clk); > + if (of_device_is_compatible(dev->of_node, "starfive,jh7110-qspi")) > + clk_bulk_prepare_enable(cqspi->num_clks, cqspi->clks); > cqspi_wait_idle(cqspi); > cqspi_controller_init(cqspi); > > -- > 2.34.1 >
On Tue, Jul 04, 2023 at 05:36:03PM +0100, Conor Dooley wrote: > On Tue, Jul 04, 2023 at 05:04:52PM +0800, William Qiu wrote: > > Add QSPI clock operation in device probe. > > > > Signed-off-by: William Qiu <william.qiu@starfivetech.com> > > Reviewed-by: Hal Feng <hal.feng@starfivetech.com> > > Reported-by: kernel test robot <lkp@intel.com> > > Closes: https://lore.kernel.org/oe-kbuild-all/202306022017.UbwjjWRN-lkp@intel.com/ > These Reported-by tags don't seem correct, given they were reports about > this patch, not the reason for it - but did you actually check that you > fixed the errors that the patch produces? Yeah, the Reported-bys that LKP sends in response to on list patches are a menace, they just generate noise. > This particular one seems to complain about a hunk that is still in the > patch & the CI running on the RISC-V patchwork is complaining about it. I'm surprised that builds cleanly anywhere...
On 04/07/2023 11:04, William Qiu wrote: > Add QSPI clock operation in device probe. > > Signed-off-by: William Qiu <william.qiu@starfivetech.com> > Reviewed-by: Hal Feng <hal.feng@starfivetech.com> > Reported-by: kernel test robot <lkp@intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202306022017.UbwjjWRN-lkp@intel.com/ > Reported-by: Julia Lawall <julia.lawall@inria.fr> > Closes: https://lore.kernel.org/r/202306040644.6ZHs55x4-lkp@intel.com/ > > @@ -1840,6 +1858,8 @@ static int cqspi_resume(struct device *dev) > struct spi_master *master = dev_get_drvdata(dev); > > clk_prepare_enable(cqspi->clk); > + if (of_device_is_compatible(dev->of_node, "starfive,jh7110-qspi")) Don't add compatible checks inside the code. It does not scale. We expect compatibles to be listed only in one place - of_device_id - and customize driver with match data / quirks / flags. Comment applies to all your diff hunks. > + clk_bulk_prepare_enable(cqspi->num_clks, cqspi->clks); > cqspi_wait_idle(cqspi); > cqspi_controller_init(cqspi); > Best regards, Krzysztof
On 2023/7/5 0:36, Conor Dooley wrote: > Hey William, > > On Tue, Jul 04, 2023 at 05:04:52PM +0800, William Qiu wrote: >> Add QSPI clock operation in device probe. >> >> Signed-off-by: William Qiu <william.qiu@starfivetech.com> >> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> >> Reported-by: kernel test robot <lkp@intel.com> >> Closes: https://lore.kernel.org/oe-kbuild-all/202306022017.UbwjjWRN-lkp@intel.com/ > > These Reported-by tags don't seem correct, given they were reports about > this patch, not the reason for it - but did you actually check that you > fixed the errors that the patch produces? > > This particular one seems to complain about a hunk that is still in the > patch & the CI running on the RISC-V patchwork is complaining about it. > > Cheers, > Conor. > I checked and found that I had only partially fixed it. I'll fix it in next version. Thanks for your comments. Best regards, William >> @@ -1840,6 +1858,8 @@ static int cqspi_resume(struct device *dev) >> struct spi_master *master = dev_get_drvdata(dev); >> >> clk_prepare_enable(cqspi->clk); >> + if (of_device_is_compatible(dev->of_node, "starfive,jh7110-qspi")) >> + clk_bulk_prepare_enable(cqspi->num_clks, cqspi->clks); >> cqspi_wait_idle(cqspi); >> cqspi_controller_init(cqspi); >> >> -- >> 2.34.1 >>
On 2023/7/5 14:21, Krzysztof Kozlowski wrote: > On 04/07/2023 11:04, William Qiu wrote: >> Add QSPI clock operation in device probe. >> >> Signed-off-by: William Qiu <william.qiu@starfivetech.com> >> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> >> Reported-by: kernel test robot <lkp@intel.com> >> Closes: https://lore.kernel.org/oe-kbuild-all/202306022017.UbwjjWRN-lkp@intel.com/ >> Reported-by: Julia Lawall <julia.lawall@inria.fr> >> Closes: https://lore.kernel.org/r/202306040644.6ZHs55x4-lkp@intel.com/ > > >> >> @@ -1840,6 +1858,8 @@ static int cqspi_resume(struct device *dev) >> struct spi_master *master = dev_get_drvdata(dev); >> >> clk_prepare_enable(cqspi->clk); >> + if (of_device_is_compatible(dev->of_node, "starfive,jh7110-qspi")) > > Don't add compatible checks inside the code. It does not scale. We > expect compatibles to be listed only in one place - of_device_id - and > customize driver with match data / quirks / flags. > > Comment applies to all your diff hunks. > I'll use "of_device_get_match_data" to replace it. But the way I added reset before is also by compatible checks. Should I change this place to "of_device_get_match_data" as well? >> + clk_bulk_prepare_enable(cqspi->num_clks, cqspi->clks); >> cqspi_wait_idle(cqspi); >> cqspi_controller_init(cqspi); >> > > Best regards, > Krzysztof >
On 05/07/2023 09:04, William Qiu wrote: > > > On 2023/7/5 14:21, Krzysztof Kozlowski wrote: >> On 04/07/2023 11:04, William Qiu wrote: >>> Add QSPI clock operation in device probe. >>> >>> Signed-off-by: William Qiu <william.qiu@starfivetech.com> >>> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> >>> Reported-by: kernel test robot <lkp@intel.com> >>> Closes: https://lore.kernel.org/oe-kbuild-all/202306022017.UbwjjWRN-lkp@intel.com/ >>> Reported-by: Julia Lawall <julia.lawall@inria.fr> >>> Closes: https://lore.kernel.org/r/202306040644.6ZHs55x4-lkp@intel.com/ >> >> >>> >>> @@ -1840,6 +1858,8 @@ static int cqspi_resume(struct device *dev) >>> struct spi_master *master = dev_get_drvdata(dev); >>> >>> clk_prepare_enable(cqspi->clk); >>> + if (of_device_is_compatible(dev->of_node, "starfive,jh7110-qspi")) >> >> Don't add compatible checks inside the code. It does not scale. We >> expect compatibles to be listed only in one place - of_device_id - and >> customize driver with match data / quirks / flags. >> >> Comment applies to all your diff hunks. >> > I'll use "of_device_get_match_data" to replace it. But the way I added > reset before is also by compatible checks. Should I change this place to > "of_device_get_match_data" as well? I don't know what's there, but in general driver should be written in a consistent style. Best regards, Krzysztof
On 2023/7/5 15:23, Krzysztof Kozlowski wrote: > On 05/07/2023 09:04, William Qiu wrote: >> >> >> On 2023/7/5 14:21, Krzysztof Kozlowski wrote: >>> On 04/07/2023 11:04, William Qiu wrote: >>>> Add QSPI clock operation in device probe. >>>> >>>> Signed-off-by: William Qiu <william.qiu@starfivetech.com> >>>> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> >>>> Reported-by: kernel test robot <lkp@intel.com> >>>> Closes: https://lore.kernel.org/oe-kbuild-all/202306022017.UbwjjWRN-lkp@intel.com/ >>>> Reported-by: Julia Lawall <julia.lawall@inria.fr> >>>> Closes: https://lore.kernel.org/r/202306040644.6ZHs55x4-lkp@intel.com/ >>> >>> >>>> >>>> @@ -1840,6 +1858,8 @@ static int cqspi_resume(struct device *dev) >>>> struct spi_master *master = dev_get_drvdata(dev); >>>> >>>> clk_prepare_enable(cqspi->clk); >>>> + if (of_device_is_compatible(dev->of_node, "starfive,jh7110-qspi")) >>> >>> Don't add compatible checks inside the code. It does not scale. We >>> expect compatibles to be listed only in one place - of_device_id - and >>> customize driver with match data / quirks / flags. >>> >>> Comment applies to all your diff hunks. >>> >> I'll use "of_device_get_match_data" to replace it. But the way I added >> reset before is also by compatible checks. Should I change this place to >> "of_device_get_match_data" as well? > > I don't know what's there, but in general driver should be written in a > consistent style. >It's in line 1719, inside the "cqspi_probe", but this part of the code is already merged in the main line. Should I keep it in a consistent style? Best regards, William > Best regards, > Krzysztof >
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c index 6ddb2dfc0f00..8774f9aaff61 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -63,6 +63,8 @@ struct cqspi_st { struct platform_device *pdev; struct spi_master *master; struct clk *clk; + struct clk_bulk_data *clks; + int num_clks; unsigned int sclk; void __iomem *iobase; @@ -1715,6 +1717,16 @@ static int cqspi_probe(struct platform_device *pdev) } if (of_device_is_compatible(pdev->dev.of_node, "starfive,jh7110-qspi")) { + cqspi->num_clks = devm_clk_bulk_get_all(dev, &cqspi->clks); + if (cqspi->num_clks < 0) { + dev_err(dev, "Cannot claim clock: %u\n", cqspi->num_clks); + return -EINVAL; + } + + ret = clk_bulk_prepare_enable(cqspi->num_clks, cqspi->clks); + if (ret) + dev_err(dev, "Cannot enable clock clks\n"); + rstc_ref = devm_reset_control_get_optional_exclusive(dev, "rstc_ref"); if (IS_ERR(rstc_ref)) { ret = PTR_ERR(rstc_ref); @@ -1816,6 +1828,9 @@ static void cqspi_remove(struct platform_device *pdev) clk_disable_unprepare(cqspi->clk); + if (of_device_is_compatible(pdev->dev.of_node, "starfive,jh7110-qspi")) + clk_bulk_disable_unprepare(cqspi->num_clks, cqspi->clks); + pm_runtime_put_sync(&pdev->dev); pm_runtime_disable(&pdev->dev); } @@ -1831,6 +1846,9 @@ static int cqspi_suspend(struct device *dev) clk_disable_unprepare(cqspi->clk); + if (of_device_is_compatible(dev->of_node, "starfive,jh7110-qspi")) + clk_bulk_disable_unprepare(cqspi->num_clks, cqspi->clks); + return ret; } @@ -1840,6 +1858,8 @@ static int cqspi_resume(struct device *dev) struct spi_master *master = dev_get_drvdata(dev); clk_prepare_enable(cqspi->clk); + if (of_device_is_compatible(dev->of_node, "starfive,jh7110-qspi")) + clk_bulk_prepare_enable(cqspi->num_clks, cqspi->clks); cqspi_wait_idle(cqspi); cqspi_controller_init(cqspi);