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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 409B3C43214 for ; Fri, 20 Aug 2021 02:51:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1F3EB6108E for ; Fri, 20 Aug 2021 02:51:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237908AbhHTCwR (ORCPT ); Thu, 19 Aug 2021 22:52:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237636AbhHTCwQ (ORCPT ); Thu, 19 Aug 2021 22:52:16 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9915FC061575; Thu, 19 Aug 2021 19:51:38 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id w20so17265865lfu.7; Thu, 19 Aug 2021 19:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zboB1Q6i9oYgbkK+DWfMo5HokGy8eox3TcOGLTI8/TQ=; b=MSPObL9gtIfvXhGm8vmuM1WlsX8S9aqUcJKehk6hQXt2kTc0FpmAMpCNdosprR8DEi /yWFr3UlXiFd2ptrMNopWEd4mvb/K8eNekkIVvnlp6AKdEAvU+jGXH5uVDxvGcdGZoGg 7d0zSU30Fr03L6Jyi08Us+ikNmam6soR3xc9TnEUbHxYKYK/+DxyeuIlb2H/R67utUeG f8Hx0eRqtRpuLlOkbbDR3VqVNtgKs+C8IJnFlLq0D7i7HgCycFYmI+7YKNlKYZOsIZqi M8cceb7ZJ2VG2spCfJmWhEcSNn6fxBgRnLJwFtl+p9dAcHXGqIRgt1IqsRHAMWfqn/Mz 6mnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zboB1Q6i9oYgbkK+DWfMo5HokGy8eox3TcOGLTI8/TQ=; b=Fte0SRty0Uxt3DppV1yP+tZesHgOhbSKOlOlG8XOO4C7v4bn6eRSmMIYCcPFIjQx4Y m9+LEH06oTnnPBpy4iCQ9CihyfKJQ5hKM+y/Yv6DZT6hKzLuU1hR89T0F/KjiI+bHHe+ UCKLw8TyX/REKdwNGQ1yZbCjLn8EdsYvg8tiIx2JxUKDoBojSER7AZtFeBkIpXRGQcrD Tp7LffUKVdqVtMgjVQkNl54jE/nNIuum/zFppghEjq3ITApPIL6xZZBpZ7jplj0hHSTJ ipBoU41s8N3k5luR1SZXKyhT1RiDbKfg2g0ljP64isLZ4GYWFjX+qgBJtgduOVBc1oG8 o7Iw== X-Gm-Message-State: AOAM533Tq8igYXOdZTPeWdpW7U7elfm3hAcEu/JYAyWryyzWbSoavb7T SdUhkP0PPyOoI2gWPzN0HF00eNjcRDk= X-Google-Smtp-Source: ABdhPJxyaLUy3vFiucIY3S77FtdQqbUhTA2/WSHmXMHR7V1HqPjJvW4kwuD0WLGfg5N30COber68xA== X-Received: by 2002:ac2:4c94:: with SMTP id d20mr12622519lfl.640.1629427896895; Thu, 19 Aug 2021 19:51:36 -0700 (PDT) Received: from [192.168.2.145] (46-138-120-72.dynamic.spd-mgts.ru. [46.138.120.72]) by smtp.googlemail.com with ESMTPSA id w9sm2965ljo.36.2021.08.19.19.51.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 19:51:36 -0700 (PDT) Subject: Re: [PATCH v8 06/34] dt-bindings: clock: tegra-car: Document new tegra-clocks sub-node To: Thierry Reding Cc: Rob Herring , Jonathan Hunter , Ulf Hansson , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Mikko Perttunen , Peter Chen , Mark Brown , Lee Jones , =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , Nishanth Menon , Vignesh Raghavendra , Richard Weinberger , Miquel Raynal , Lucas Stach , Stefan Agner , Adrian Hunter , Mauro Carvalho Chehab , Michael Turquette , linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-staging@lists.linux.dev, linux-spi@vger.kernel.org, linux-pwm@vger.kernel.org, linux-mtd@lists.infradead.org, linux-mmc@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org References: <20210817012754.8710-1-digetx@gmail.com> <20210817012754.8710-7-digetx@gmail.com> From: Dmitry Osipenko Message-ID: Date: Fri, 20 Aug 2021 05:51:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-pwm@vger.kernel.org 19.08.2021 19:31, Thierry Reding пишет: >> The "device" representation is internal to the kernel. It's okay to me >> to have PLLs represented by a device, it's a distinct h/w by itself. >> >> CCF supports managing of clock's RPM and it requires to have clock to be >> backed by a device. That's what we are using here. >> >> Please see >> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/clk/clk.c#L109 > Looking at the implementation of __clk_register() and where that device > pointer typically comes from, I don't think the way this is used here is > what was intended. The way I interpret the code is that a clock is > registered with a parent device (i.e. its provider) and > clk_pm_runtime_get() is then used internally as a way to make sure that > when a clock is prepared, it's parent device is runtime resumed. This is > presumably to ensure that any registers that the driver might need to > access in order to prepare and enable the clock are accessible (i.e. the > CAR is not powered off or in reset). > > So the struct device that is passed to __clk_register() (or its callers) > should be that of the CAR rather than virtual struct devices created by > the CAR. > > And it's a bit debatable whether or not PLLs represent distinct > hardware. Ultimately every transistor on a chip could be considered > distinct hardware. But a platform device is a device on a platform bus, > which is really just another way of saying it's a hardware block that's > accessible from the CPU via a memory-mapped address. A PLL (just like > other clocks) is merely a resource exposed by means of access to these > registers. So I don't think they should be platform devices. Even making > them struct device:s seems a bit of a stretch. > > Is there any reason why struct clk can't be used for this? I mean, the > whole purpose of that structure is to represent clocks. Why do we need > to make them special? Because we need to perform DVFS for PLLs. The only way to do it without having to reinvent existing frameworks is to use these frameworks and they require a device.