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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1ED7C433EF for ; Wed, 6 Oct 2021 13:30:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C4D1F60E9C for ; Wed, 6 Oct 2021 13:30:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238739AbhJFNcA (ORCPT ); Wed, 6 Oct 2021 09:32:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238447AbhJFNb6 (ORCPT ); Wed, 6 Oct 2021 09:31:58 -0400 Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 423B9C061760 for ; Wed, 6 Oct 2021 06:30:06 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id l22so468956vsq.9 for ; Wed, 06 Oct 2021 06:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UrLV8lA9162y3Lq8ezBxO5g1WjobTNq21pHd09HREe4=; b=tN7kKFFg9UP/MYNLwIHE2JePwU333q5+xEdt6mbOfK0hbOqAnd+K8rFgOZNTJx7fkb z/9RmDktrO7pxyC6UuXssuZZWsCAswQDn7wn5deSg1gnvCOv8Ip5xkrdEq7CXH3sCnz5 ZNKR/+BqPuhTAn8hLDD4fnGzeGsIFvFU0wgg00r6O4GwozDTmTHidt/Ty78CLvTvEYnd qhcWASimkmlcmwjQHm7yB+SxGIcUbamU/ZwNq3/UNDcl0t4YGloyPIGRooCd010An6rF C9foeSGVxLNd4ID+7XL0smV1L+Wx1IKChUsOwMkjGXsB7qXj8w2omU4gDE8wMEzizz/O 7aYw== 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=UrLV8lA9162y3Lq8ezBxO5g1WjobTNq21pHd09HREe4=; b=gjkos/PHEUSVNeAybiLv3m4B6Og4QwnpWud6IncrIu4SpFkqHVhEcOheHzVo3msjeo ckKXxR7Of86nEte0gctdz9e+Hou0t8yHfZ1KzGZpreu8R0Hjv7FsEivFg2qlHcRwvjFJ 1ONLi1aza+BXWD5DpDFk3W77z/ypAgM1kJwNwzObcAko/V0BEZSbUlxOgHoC7uBS2onD 7rfdG7wqN+J2wI6HLVi7YmJUaLw6ihHWYDtEMVk+iOk1+BoUV/dKU2mTkHRa1YFIVkNw 4pi66E6KtmxclA4Yaaw/Q07alwAlfYEBMLWUUmrJMoEf9O32ee/7nYDm3LYYLSE20yTR omow== X-Gm-Message-State: AOAM530ztB9QsZhT4A3u6V5JBL+76A5C+KOcBqCesH466JZtypwl2/CO qqM4i2jT1yjnf67DvdOmJ1bgUNMcw/+XjL7gYcKoHg== X-Google-Smtp-Source: ABdhPJw7Y31PK48QAwhNJ55JoS18j5NxCyEWG2Cj9aMQv6RP/Q4Nir7aL+rkCVZGbUp9DmNbSv1KECk7Zun40Hhp4GI= X-Received: by 2002:a67:1781:: with SMTP id 123mr23972078vsx.1.1633527005116; Wed, 06 Oct 2021 06:30:05 -0700 (PDT) MIME-Version: 1.0 References: <20210914155607.14122-1-semen.protsenko@linaro.org> <20210914155607.14122-2-semen.protsenko@linaro.org> <6ef3e9a3-77e7-48b7-cbcd-c13db50d0cd9@canonical.com> <16ee07a1-afa9-b258-8836-e96de84551db@canonical.com> In-Reply-To: <16ee07a1-afa9-b258-8836-e96de84551db@canonical.com> From: Sam Protsenko Date: Wed, 6 Oct 2021 16:29:53 +0300 Message-ID: Subject: Re: [PATCH 1/6] clk: samsung: Enable bus clock on init To: Krzysztof Kozlowski Cc: Sylwester Nawrocki , =?UTF-8?Q?Pawe=C5=82_Chmiel?= , Chanwoo Choi , Tomasz Figa , Rob Herring , Stephen Boyd , Michael Turquette , Ryu Euiyoul , Tom Gall , Sumit Semwal , John Stultz , Amit Pundir , devicetree , linux-arm Mailing List , linux-clk , Linux Kernel Mailing List , Linux Samsung SOC Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 6 Oct 2021 at 15:38, Krzysztof Kozlowski wrote: > > On 06/10/2021 12:46, Sam Protsenko wrote: > > On Wed, 15 Sept 2021 at 11:21, Krzysztof Kozlowski > > wrote: > >> > >> On 14/09/2021 17:56, Sam Protsenko wrote: > >>> By default if bus clock has no users its "enable count" value is 0. It > >>> might be actually running if it's already enabled in bootloader, but > >>> then in some cases it can be disabled by mistake. For example, such case > >>> was observed when dw_mci_probe() enabled bus clock, then failed to do > >>> something and disabled that bus clock on error path. After that even > >>> attempt to read the 'clk_summary' file in DebugFS freezed forever, as > >>> CMU bus clock ended up being disabled and it wasn't possible to access > >>> CMU registers anymore. > >>> > >>> To avoid such cases, CMU driver must increment the ref count for that > >>> bus clock by running clk_prepare_enable(). There is already existing > >>> '.clk_name' field in struct samsung_cmu_info, exactly for that reason. > >>> It was added in commit 523d3de41f02 ("clk: samsung: exynos5433: Add > >>> support for runtime PM"). But the clock is actually enabled only in > >>> Exynos5433 clock driver. Let's mimic what is done there in generic > >>> samsung_cmu_register_one() function, so other drivers can benefit from > >>> that `.clk_name' field. As was described above, it might be helpful not > >>> only for PM reasons, but also to prevent possible erroneous clock gating > >>> on error paths. > >>> > >>> Another way to workaround that issue would be to use CLOCK_IS_CRITICAL > >>> flag for corresponding gate clocks. But that might be not very good > >>> design decision, as we might still want to disable that bus clock, e.g. > >>> on PM suspend. > >>> > >>> Signed-off-by: Sam Protsenko > >>> --- > >>> drivers/clk/samsung/clk.c | 13 +++++++++++++ > >>> 1 file changed, 13 insertions(+) > >>> > >>> diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c > >>> index 1949ae7851b2..da65149fa502 100644 > >>> --- a/drivers/clk/samsung/clk.c > >>> +++ b/drivers/clk/samsung/clk.c > >>> @@ -357,6 +357,19 @@ struct samsung_clk_provider * __init samsung_cmu_register_one( > >>> > >>> ctx = samsung_clk_init(np, reg_base, cmu->nr_clk_ids); > >>> > >>> + /* Keep bus clock running, so it's possible to access CMU registers */ > >>> + if (cmu->clk_name) { > >>> + struct clk *bus_clk; > >>> + > >>> + bus_clk = __clk_lookup(cmu->clk_name); > >>> + if (bus_clk) { > >>> + clk_prepare_enable(bus_clk); > >>> + } else { > >>> + pr_err("%s: could not find bus clock %s\n", __func__, > >>> + cmu->clk_name); > >>> + } > >>> + } > >>> + > >> > >> Solving this problem in generic way makes sense but your solution is > >> insufficient. You skipped suspend/resume paths and in such case you > >> should remove the Exynos5433-specific code. > >> > > > > Keeping core bus clocks always running seems like a separate > > independent feature to me (not related to suspend/resume). It's > > mentioned in commit 523d3de41f02 ("clk: samsung: exynos5433: Add > > support for runtime PM") this way: > > > > "Also for each CMU there is one special parent clock, which has to > > be enabled all the time when any access to CMU registers is being > > done." > > > > Why do you think suspend/resume paths have to be implemented along > > with it? Btw, I didn't add PM ops in clk-exynos850, as PM is not > > implemented on my board yet and I can't test it. > > You can skip the runtime PM, so keep your patch almost like it is now > (in respect to Sylwester's comment about __clk_lookup). However now the > Exynos5433 will enable the clk_name twice: here and in > exynos5433_cmu_probe(). > > If you keep this approach, you need to remove duplicated part in > exynos5433_cmu_probe()... > My patch is only touching samsung_cmu_register_one(), and exynos5433_cmu_probe() doesn't call samsung_cmu_register_one(). So I don't think there can be a problem there. Or I'm missing something? samsung_cmu_register_one() is actually called from 5433 clk driver, but only from CMUs registered with CLK_OF_DECLARE(), and those are not setting .clk_name field, so my code is not affecting those either. Real problem I can see is that I can't avoid using __clk_lookup() if I implement that code in samsung_cmu_register_one(). Tried to do use clk_get(NULL, ...) instead, but it doesn't work with 1st param (dev) being NULL, because samsung_clk_register_*() functions don't register clkdev (only samsung_clk_register_fixed_rate() does), hence LIST_HEAD(clocks) is empty in clkdev.c, and clk_get() fails, when not provided with actual 'dev' param, which in turn is not present in samsung_cmu_register_one()... About using platform_driver: as I can see from clk-exynos5433.c, only CMUs which belong to Power Domains are registered as platform_driver. Rest of CMUs are registered using CLK_OF_DECLARE(), thus they don't get platform_device param. That makes it harder to avoid using __clk_lookup() inside samsung_cmu_register_one(). All that said, I feel like correct way to implement this patch would be: 1. Register all PD-capable CMUs as platform_driver in clk-exynos850 (all CMUs except CMU_TOP) 2. Move bus clock enablement code from samsung_cmu_register_one() to corresponding clk-exynos850 probe function This way I would be able to use clk_get(dev, ...) instead of __clk_lookup(), and that won't affect any existing code for sure. Code will be more unified w.r.t. how it's done in clk-exynos5433, and platform_device will be a foundation for implementing PM ops later. Taking into account how much design decisions should be done for using that in common code -- I'd say let's do that later, as a separate refactoring activity. Do you think that makes sense? Thanks! > > > > If you are suggesting moving all stuff from exynos5433_cmu_probe() > > into samsung_cmu_register_one(), it would take passing platform_device > > there, and implementing all PM related operations. I guess it's not a > > super easy task, as it would require converting clk-exynos7 to > > platform_driver for instance, and re-testing everything on exynos5433 > > and exynos7 boards (which I don't have). > > > > What do you say if I pull that code to clk-exynos850.c instead for v2? > > Refactoring (merging stuff from exynos5433_cmu_probe() into > > samsung_cmu_register_one() ) can be done later, when I add PM ops into > > clk-exynos850. > > > >> Best regards, > >> Krzysztof > > > Best regards, > Krzysztof 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5B43C433F5 for ; Wed, 6 Oct 2021 13:41:52 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 7EADC610CC for ; Wed, 6 Oct 2021 13:41:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7EADC610CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Cc: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=qghZF42Q523xMJ6sl92KqiZ0RtoAbtL31VyDAn2nW1g=; b=qqFvzniQ4xS8Lh Z2S5uMZzTgmw/Sr7mS+FryL9nbF7c+oSkMMLYM6KAh2Ww65r5ELxygf283eKfvYSS67JJ/DMRIXoc ICtsKF5/8FIsAGYV+X+POob6LlpAMuYRjzkUi1IarMlYkbS00gc5Q3WMXT4XdYhvp42aqtqCv/xQn TNdwdZ9mezNMybhzXq47gtoPQ4bFdyqnSW7YtC4t9GSR95NkBEPu4LGu9RHFWThQ3R3iMPlmKnuGX MWVAvBkckNHtnpihH/vRh1Ac/k2jZ20Huof7o/TScbkalFtX9PgHJ9EJ4PsyZ9AlbCNzJuorEHB8u WAny5Mb8PQVWM/P5CQFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mY78o-00EU9Z-KN; Wed, 06 Oct 2021 13:39:26 +0000 Received: from mail-vs1-xe31.google.com ([2607:f8b0:4864:20::e31]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mY6zm-00EQKO-Qi for linux-arm-kernel@lists.infradead.org; Wed, 06 Oct 2021 13:30:08 +0000 Received: by mail-vs1-xe31.google.com with SMTP id g10so2900765vsb.8 for ; Wed, 06 Oct 2021 06:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UrLV8lA9162y3Lq8ezBxO5g1WjobTNq21pHd09HREe4=; b=tN7kKFFg9UP/MYNLwIHE2JePwU333q5+xEdt6mbOfK0hbOqAnd+K8rFgOZNTJx7fkb z/9RmDktrO7pxyC6UuXssuZZWsCAswQDn7wn5deSg1gnvCOv8Ip5xkrdEq7CXH3sCnz5 ZNKR/+BqPuhTAn8hLDD4fnGzeGsIFvFU0wgg00r6O4GwozDTmTHidt/Ty78CLvTvEYnd qhcWASimkmlcmwjQHm7yB+SxGIcUbamU/ZwNq3/UNDcl0t4YGloyPIGRooCd010An6rF C9foeSGVxLNd4ID+7XL0smV1L+Wx1IKChUsOwMkjGXsB7qXj8w2omU4gDE8wMEzizz/O 7aYw== 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=UrLV8lA9162y3Lq8ezBxO5g1WjobTNq21pHd09HREe4=; b=Brbfxcc0pnMohFKvZHTpqDp+YvryJwD7XPfqn/eLykrc8uohCcwCC853z7Tw7gH/ww mdewnheQvypGZRJ5hRiii3Zhs1wKzXTjoouPqjp1uhM3mVeMZJOJqzA7c0sWfdPZW6Na +q+wFUMoohb2g4Dv4oYHx7yqgj+n3s0g/guTqjtINcxyKCkJ+PTw57W1g/R2zjjTdeU+ 8NuiN6GrHKedg8sLtocYzzD4CyA3LBgE7SzqORJJdbaO2BUZJezHHQXfqoNHlxLPSL+/ rPVoH+8pi7+t1oa+lUSn270U23HjGsN31ONKBUGqgHbfHeykq0kJFhqoVmIVNVL/zHj3 MCiA== X-Gm-Message-State: AOAM5319K8JJEotVkdBILoFiaiMzz4+oX9vupD1ZQnYBtPpr0T+JI4Y1 owB8ZEnXGcOgueGbEhOceNBArTapybpQK7/tqdt/9g== X-Google-Smtp-Source: ABdhPJw7Y31PK48QAwhNJ55JoS18j5NxCyEWG2Cj9aMQv6RP/Q4Nir7aL+rkCVZGbUp9DmNbSv1KECk7Zun40Hhp4GI= X-Received: by 2002:a67:1781:: with SMTP id 123mr23972078vsx.1.1633527005116; Wed, 06 Oct 2021 06:30:05 -0700 (PDT) MIME-Version: 1.0 References: <20210914155607.14122-1-semen.protsenko@linaro.org> <20210914155607.14122-2-semen.protsenko@linaro.org> <6ef3e9a3-77e7-48b7-cbcd-c13db50d0cd9@canonical.com> <16ee07a1-afa9-b258-8836-e96de84551db@canonical.com> In-Reply-To: <16ee07a1-afa9-b258-8836-e96de84551db@canonical.com> From: Sam Protsenko Date: Wed, 6 Oct 2021 16:29:53 +0300 Message-ID: Subject: Re: [PATCH 1/6] clk: samsung: Enable bus clock on init To: Krzysztof Kozlowski Cc: Sylwester Nawrocki , =?UTF-8?Q?Pawe=C5=82_Chmiel?= , Chanwoo Choi , Tomasz Figa , Rob Herring , Stephen Boyd , Michael Turquette , Ryu Euiyoul , Tom Gall , Sumit Semwal , John Stultz , Amit Pundir , devicetree , linux-arm Mailing List , linux-clk , Linux Kernel Mailing List , Linux Samsung SOC X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211006_063006_926410_B20DC2EB X-CRM114-Status: GOOD ( 53.48 ) 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 On Wed, 6 Oct 2021 at 15:38, Krzysztof Kozlowski wrote: > > On 06/10/2021 12:46, Sam Protsenko wrote: > > On Wed, 15 Sept 2021 at 11:21, Krzysztof Kozlowski > > wrote: > >> > >> On 14/09/2021 17:56, Sam Protsenko wrote: > >>> By default if bus clock has no users its "enable count" value is 0. It > >>> might be actually running if it's already enabled in bootloader, but > >>> then in some cases it can be disabled by mistake. For example, such case > >>> was observed when dw_mci_probe() enabled bus clock, then failed to do > >>> something and disabled that bus clock on error path. After that even > >>> attempt to read the 'clk_summary' file in DebugFS freezed forever, as > >>> CMU bus clock ended up being disabled and it wasn't possible to access > >>> CMU registers anymore. > >>> > >>> To avoid such cases, CMU driver must increment the ref count for that > >>> bus clock by running clk_prepare_enable(). There is already existing > >>> '.clk_name' field in struct samsung_cmu_info, exactly for that reason. > >>> It was added in commit 523d3de41f02 ("clk: samsung: exynos5433: Add > >>> support for runtime PM"). But the clock is actually enabled only in > >>> Exynos5433 clock driver. Let's mimic what is done there in generic > >>> samsung_cmu_register_one() function, so other drivers can benefit from > >>> that `.clk_name' field. As was described above, it might be helpful not > >>> only for PM reasons, but also to prevent possible erroneous clock gating > >>> on error paths. > >>> > >>> Another way to workaround that issue would be to use CLOCK_IS_CRITICAL > >>> flag for corresponding gate clocks. But that might be not very good > >>> design decision, as we might still want to disable that bus clock, e.g. > >>> on PM suspend. > >>> > >>> Signed-off-by: Sam Protsenko > >>> --- > >>> drivers/clk/samsung/clk.c | 13 +++++++++++++ > >>> 1 file changed, 13 insertions(+) > >>> > >>> diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c > >>> index 1949ae7851b2..da65149fa502 100644 > >>> --- a/drivers/clk/samsung/clk.c > >>> +++ b/drivers/clk/samsung/clk.c > >>> @@ -357,6 +357,19 @@ struct samsung_clk_provider * __init samsung_cmu_register_one( > >>> > >>> ctx = samsung_clk_init(np, reg_base, cmu->nr_clk_ids); > >>> > >>> + /* Keep bus clock running, so it's possible to access CMU registers */ > >>> + if (cmu->clk_name) { > >>> + struct clk *bus_clk; > >>> + > >>> + bus_clk = __clk_lookup(cmu->clk_name); > >>> + if (bus_clk) { > >>> + clk_prepare_enable(bus_clk); > >>> + } else { > >>> + pr_err("%s: could not find bus clock %s\n", __func__, > >>> + cmu->clk_name); > >>> + } > >>> + } > >>> + > >> > >> Solving this problem in generic way makes sense but your solution is > >> insufficient. You skipped suspend/resume paths and in such case you > >> should remove the Exynos5433-specific code. > >> > > > > Keeping core bus clocks always running seems like a separate > > independent feature to me (not related to suspend/resume). It's > > mentioned in commit 523d3de41f02 ("clk: samsung: exynos5433: Add > > support for runtime PM") this way: > > > > "Also for each CMU there is one special parent clock, which has to > > be enabled all the time when any access to CMU registers is being > > done." > > > > Why do you think suspend/resume paths have to be implemented along > > with it? Btw, I didn't add PM ops in clk-exynos850, as PM is not > > implemented on my board yet and I can't test it. > > You can skip the runtime PM, so keep your patch almost like it is now > (in respect to Sylwester's comment about __clk_lookup). However now the > Exynos5433 will enable the clk_name twice: here and in > exynos5433_cmu_probe(). > > If you keep this approach, you need to remove duplicated part in > exynos5433_cmu_probe()... > My patch is only touching samsung_cmu_register_one(), and exynos5433_cmu_probe() doesn't call samsung_cmu_register_one(). So I don't think there can be a problem there. Or I'm missing something? samsung_cmu_register_one() is actually called from 5433 clk driver, but only from CMUs registered with CLK_OF_DECLARE(), and those are not setting .clk_name field, so my code is not affecting those either. Real problem I can see is that I can't avoid using __clk_lookup() if I implement that code in samsung_cmu_register_one(). Tried to do use clk_get(NULL, ...) instead, but it doesn't work with 1st param (dev) being NULL, because samsung_clk_register_*() functions don't register clkdev (only samsung_clk_register_fixed_rate() does), hence LIST_HEAD(clocks) is empty in clkdev.c, and clk_get() fails, when not provided with actual 'dev' param, which in turn is not present in samsung_cmu_register_one()... About using platform_driver: as I can see from clk-exynos5433.c, only CMUs which belong to Power Domains are registered as platform_driver. Rest of CMUs are registered using CLK_OF_DECLARE(), thus they don't get platform_device param. That makes it harder to avoid using __clk_lookup() inside samsung_cmu_register_one(). All that said, I feel like correct way to implement this patch would be: 1. Register all PD-capable CMUs as platform_driver in clk-exynos850 (all CMUs except CMU_TOP) 2. Move bus clock enablement code from samsung_cmu_register_one() to corresponding clk-exynos850 probe function This way I would be able to use clk_get(dev, ...) instead of __clk_lookup(), and that won't affect any existing code for sure. Code will be more unified w.r.t. how it's done in clk-exynos5433, and platform_device will be a foundation for implementing PM ops later. Taking into account how much design decisions should be done for using that in common code -- I'd say let's do that later, as a separate refactoring activity. Do you think that makes sense? Thanks! > > > > If you are suggesting moving all stuff from exynos5433_cmu_probe() > > into samsung_cmu_register_one(), it would take passing platform_device > > there, and implementing all PM related operations. I guess it's not a > > super easy task, as it would require converting clk-exynos7 to > > platform_driver for instance, and re-testing everything on exynos5433 > > and exynos7 boards (which I don't have). > > > > What do you say if I pull that code to clk-exynos850.c instead for v2? > > Refactoring (merging stuff from exynos5433_cmu_probe() into > > samsung_cmu_register_one() ) can be done later, when I add PM ops into > > clk-exynos850. > > > >> Best regards, > >> Krzysztof > > > Best regards, > Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel