Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2380712yba; Thu, 25 Apr 2019 15:40:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqzdZRhiQKFFoi49Aoo/mmTfnokCaAdvWiCdvD80uk4R5dp4QnYCqkVKbi/gijD4+qJZIG9X X-Received: by 2002:a63:b811:: with SMTP id p17mr38223387pge.219.1556232046723; Thu, 25 Apr 2019 15:40:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556232046; cv=none; d=google.com; s=arc-20160816; b=hFZCBpzMQEA/XlX4XWf6at1DpAJGgeIlJwvYMrQEFrvg95s/Oz3ZHTLruiaaUuA45a apWTZxoJ+voTW8TJbXEkCbqz0cyC4Cn3T/JCSzLUjYqA6BAQoajiP9HQE1pt/X8P3jCq uXUoaZin++8O513Qvv9Fl8GPBOnidBDs5tb1Kungd3NpjxzyY3zjIwJ2rVYCQ1AGKw+I AttMFgj8dNijxSVMGmz26byvaxT8F5jt8jhJv44a9tSYDt5cY+UIkDOFCpqVT4KQ82Ia IbzZif+h+6M60hvpMFHIJUSX81pVRCj4Ae1xWM+z5Qf8PIglEWr0moCOA3zs1N2Viish lmHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:user-agent:message-id:to:subject :from:cc:references:in-reply-to:content-transfer-encoding :mime-version:dkim-signature; bh=hwxAGA2ESCy7RPavDoTIsCUaWqRMhrCuz6cHjKeQSDY=; b=CYANwfh4OotQa7dQbSaa0RFEY+pmKoCcoMMXB/eIh9Xk91UiWNuggARnBTm0GiD5ii Uw7nIBZJx4V1k8U6+Nh+9XjnX9EBCqCI31bEG2nfjFqTqGUDVo4KvEnn/u8i7ix1zjD1 M5xJAPt468gMW4gM6WH9E7UZcxYPGsRwENOQ86ova66vG00plIt4qdb0S1ibzmOEC+rg j4KGuXibb80oEsj/e9g602NUPL9j8xY+uJjSr9nZ1fnGFqwSLfb2Q4BTIN+a6rOuFc2t j6nW6wKnBzuduM25+K8+WhDTH1W3/YpKkq1FYxbXZO3OGSxvSWzqNwBBtxNOe16dYid9 1fdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=d7U0G8hs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r19si11742740pga.328.2019.04.25.15.40.31; Thu, 25 Apr 2019 15:40:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=d7U0G8hs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728328AbfDYV3H (ORCPT + 99 others); Thu, 25 Apr 2019 17:29:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:45164 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726272AbfDYV3H (ORCPT ); Thu, 25 Apr 2019 17:29:07 -0400 Received: from localhost (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 97B6D20675; Thu, 25 Apr 2019 21:29:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556227746; bh=fXKxNIi5a/B3PpIuMmHIVsGGXiZch2q1OaB5IXDPSNk=; h=In-Reply-To:References:Cc:From:Subject:To:Date:From; b=d7U0G8hsoBgurdZXSYEozG88nOcjAM6GmHc6kdo0draNUpwZ3Sh1kyhKw3Ok9k3th CugbSicsafaalHPHFjkbB1iU+u22qXon6IreJaxb6OSms4P/WPolzUnPeVmjSHUZ88 y9qNxLQjqSSaYBBpRvcuFUfdIWCS9blUklzpC+Do= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <31e17283-c374-f16e-df95-09aaf1854435@linaro.org> References: <1548700381-22376-1-git-send-email-jorge.ramirez-ortiz@linaro.org> <1548700381-22376-6-git-send-email-jorge.ramirez-ortiz@linaro.org> <155085910216.77512.12604271825136479370@swboyd.mtv.corp.google.com> <31e17283-c374-f16e-df95-09aaf1854435@linaro.org> Cc: vkoul@kernel.org, niklas.cassel@linaro.org, georgi.djakov@linaro.org, amit.kucheria@linaro.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-msm@vger.kernel.org, khasim.mohammed@linaro.org From: Stephen Boyd Subject: Re: [PATCH v2 05/14] clk: qcom: apcs-msm8916: get parent clock names from DT To: Jorge Ramirez , andy.gross@linaro.org, arnd@arndb.de, bjorn.andersson@linaro.org, david.brown@linaro.org, enric.balletbo@collabora.com, heiko@sntech.de, horms+renesas@verge.net.au, jagan@amarulasolutions.com, jassisinghbrar@gmail.com, mark.rutland@arm.com, mturquette@baylibre.com, olof@lixom.net, robh+dt@kernel.org, sibis@codeaurora.org, will.deacon@arm.com Message-ID: <155622774551.15276.4140891469702307355@swboyd.mtv.corp.google.com> User-Agent: alot/0.8 Date: Thu, 25 Apr 2019 14:29:05 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Jorge Ramirez (2019-04-22 04:44:50) > On 2/22/19 19:11, Stephen Boyd wrote: > > Quoting Jorge Ramirez-Ortiz (2019-01-28 10:32:52) > >> @@ -61,6 +65,25 @@ static int qcom_apcs_msm8916_clk_probe(struct platf= orm_device *pdev) > >> if (!a53cc) > >> return -ENOMEM; > >> =20 > >> + /* check if the parent names are present in the device tree */ > >=20 > > This looks odd. > >=20 > >> + ret =3D devm_clk_bulk_get(parent, ARRAY_SIZE(pclks), pclks); > >> + if (ret =3D=3D -EPROBE_DEFER) > >> + return ret; > >=20 > > Why can't we use of_clk_parent_fill() if we know this is always a DT > > platform? The parent clks may not be registered at the time of probe? >=20 > yes, and AFAICS the important thing at this point is that the clock is > registered hence the handling of defer. >=20 > I could use of_clk_parent_fill and then - if needed - call > devm_clk_bulk_get but I am not sure of the gains of doing it (wouldnt > this just make the code more confusing?) Yeah of_clk_parent_fill() isn't the best approach. But it at least keeps this driver from using clk consumer APIs? >=20 >=20 > > Maybe this series should wait for the parent registration stuff I'm > > working on so that this can be made simpler. >=20 > the need for the clock name is not intrinsic to this driver (the driver > itself doesnt use these names) but it just feeds these to the framework. >=20 > I was looking into your parent registration code and I am not sure how > can I use it in this particular driver other than simply removing the > names and hoping that things are handled properly at the lower > levels.... could you clarify please? >=20 I think so. I've forgotten the context of this patch, but the general idea would be to specify the parents with clock-names or DT index in the DT node for the clks registered here and not use of_clk_parent_fill() or do any sort of devm_clk_bulk_get() calls. Then the framework will take care of finding the parents for the clks and hooking things up properly for the parent-child relationship.