| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <e17bbe8d-7c0f-fc3d-03c7-d75c54c24a43@gmail.com>
Date: Fri, 20 Aug 2021 01:09:46 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Jonathan Hunter <jonathanh@...dia.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Viresh Kumar <vireshk@...nel.org>,
Stephen Boyd <sboyd@...nel.org>,
Peter De Schrijver <pdeschrijver@...dia.com>,
Mikko Perttunen <mperttunen@...dia.com>,
Peter Chen <peter.chen@...nel.org>,
Mark Brown <broonie@...nel.org>,
Lee Jones <lee.jones@...aro.org>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
Nishanth Menon <nm@...com>,
Vignesh Raghavendra <vigneshr@...com>,
Richard Weinberger <richard@....at>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Lucas Stach <dev@...xeye.de>, Stefan Agner <stefan@...er.ch>,
Adrian Hunter <adrian.hunter@...el.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-pm@...r.kernel.org, linux-usb@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-spi@...r.kernel.org,
linux-pwm@...r.kernel.org, linux-mtd@...ts.infradead.org,
linux-mmc@...r.kernel.org, linux-media@...r.kernel.org,
dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
linux-clk@...r.kernel.org
Subject: Re: [PATCH v8 07/34] clk: tegra: Support runtime PM and power domain
19.08.2021 19:54, Thierry Reding пишет:
> On Wed, Aug 18, 2021 at 08:11:03PM +0300, Dmitry Osipenko wrote:
>> 18.08.2021 19:42, Thierry Reding пишет:
>>> On Wed, Aug 18, 2021 at 06:05:21PM +0300, Dmitry Osipenko wrote:
>>>> 18.08.2021 17:07, Thierry Reding пишет:
>>>>> On Tue, Aug 17, 2021 at 04:27:27AM +0300, Dmitry Osipenko wrote:
>>>>> [...]
>>>>>> +struct clk *tegra_clk_register(struct clk_hw *hw)
>>>>>> +{
>>>>>> + struct platform_device *pdev;
>>>>>> + struct device *dev = NULL;
>>>>>> + struct device_node *np;
>>>>>> + const char *dev_name;
>>>>>> +
>>>>>> + np = tegra_clk_get_of_node(hw);
>>>>>> +
>>>>>> + if (!of_device_is_available(np))
>>>>>> + goto put_node;
>>>>>> +
>>>>>> + dev_name = kasprintf(GFP_KERNEL, "tegra_clk_%s", hw->init->name);
>>>>>> + if (!dev_name)
>>>>>> + goto put_node;
>>>>>> +
>>>>>> + pdev = of_platform_device_create(np, dev_name, NULL);
>>>>>> + if (!pdev) {
>>>>>> + pr_err("%s: failed to create device for %pOF\n", __func__, np);
>>>>>> + kfree(dev_name);
>>>>>> + goto put_node;
>>>>>> + }
>>>>>> +
>>>>>> + dev = &pdev->dev;
>>>>>> + pm_runtime_enable(dev);
>>>>>> +put_node:
>>>>>> + of_node_put(np);
>>>>>> +
>>>>>> + return clk_register(dev, hw);
>>>>>> +}
>>>>>
>>>>> This looks wrong. Why do we need struct platform_device objects for each
>>>>> of these clocks? That's going to be a massive amount of platform devices
>>>>> and they will completely mess up sysfs.
>>>>
>>>> RPM works with a device. It's not a massive amount of devices, it's one
>>>> device for T20 and four devices for T30.
>>>
>>> I'm still not sure I understand why we need to call RPM functions on a
>>> clock. And even if they are few, it seems wrong to make these platform
>>> devices.
>>
>> Before clock is enabled, we need to raise core voltage. After clock is
>> disabled, the voltage should be dropped. CCF+RPM takes care of handling
>> this for us.
>
> That's the part that I do understand. What I don't understand is why a
> clock needs to be runtime suspend/resumed. Typically we suspend/resume
> devices, and doing so typically involves disabling/enabling clocks. So
> I don't understand why the clocks themselves now need to be runtime
> suspended/resumed.
CCF provides RPM management for a device that backs clock. When clock is enabled, it resumes the backing device.
RPM, GENPD and OPP frameworks work with a device. We use all these frameworks here. Since we don't have a dedicated device for a PLL clock, we need to create it in order to leverage the existing generic kernel APIs.
In this case clocks are not runtime suspended/resumed, the device which backs clock is suspended/resumed.
>>> Perhaps they can be simple struct device:s instead? Ideally they would
>>> also be parented to the CAR so that they appear in the right place in
>>> the sysfs hierarchy.
>>
>> Could you please clarify what do you mean by 'simple struct device:s'?
>> These clock devices should be OF devices with a of_node and etc,
>> otherwise we can't use OPP framework.
>
> Perhaps I misunderstand the goal of the OPP framework. My understanding
> was that this was to attach a table of operating points with a device so
> that appropriate operating points could be selected and switched to when
> the workload changes.
>
> Typically these operating points would be roughly a clock rate and a
> corresponding voltage for a regulator, so that when a certain clock rate
> is requested, the regulator can be set to the matching voltage.
>
> Hm... so is it that each of these clocks that you want to create a
> platform device for has its own regulator? Because the patch series only
> mentions the CORE domain, so I assumed that we would accumulate all the
> clock rates for the clocks that are part of that CORE domain and then
> derive a voltage to be supplied to that CORE domain.
>
> But perhaps I just don't understand correctly how this is tied together.
We don't use regulators, we use power domain that controls regulator. GENPD takes care of accumulating performance requests on a per-device basis.
I'm creating platform device for the clocks that require DVFS. These clocks don't use regulator, they are attached to the CORE domain. GENPD framework manages the performance state, aggregating perf votes from each device, i.e. from each clock individually.
You want to reinvent another layer of aggregation on top of GENPD. This doesn't worth the effort, we won't get anything from it, it should be a lot of extra complexity for nothing. We will also lose from it because pm_genpd_summary won't show you a per-device info.
domain status children performance
/device runtime status
----------------------------------------------------------------------------------------------
heg on 1000000
/devices/soc0/50000000.host1x active 1000000
/devices/soc0/50000000.host1x/54140000.gr2d suspended 0
mpe off-0 0
vdec off-0 0
/devices/soc0/6001a000.vde suspended 0
venc off-0 0
3d1 off-0 0
/devices/genpd:1:54180000.gr3d suspended 0
3d0 off-0 0
/devices/genpd:0:54180000.gr3d suspended 0
core-domain on 1000000
3d0, 3d1, venc, vdec, mpe, heg
/devices/soc0/7d000000.usb active 1000000
/devices/soc0/78000400.mmc active 950000
/devices/soc0/7000f400.memory-controller unsupported 1000000
/devices/soc0/7000a000.pwm active 1000000
/devices/soc0/60006000.clock/tegra_clk_pll_c active 1000000
/devices/soc0/60006000.clock/tegra_clk_pll_e suspended 0
/devices/soc0/60006000.clock/tegra_clk_pll_m active 1000000
/devices/soc0/60006000.clock/tegra_clk_sclk active 1000000
>> We don't have driver for CAR to bind. I guess we could try to add a
>> 'dummy' CAR driver that will create sub-devices for the rpm-clocks, is
>> this what you're wanting?
>
> I got confused by the "tegra-clock" driver that this series was adding.
> This is actually a driver that will bind to the virtual clocks rather
> than the CAR device itself.
>
> For some reason I had assumed that you wanted to create a CAR driver in
> order to get at the struct device embedded in the CAR's platform device
> and use that as the parent for all these clocks.
>
> So even if we absolutely need some struct device for these clocks, maybe
> adding that CAR driver and making the clock struct device:s children of
> the CAR device will help keep a bit of a proper hierarchy in sysfs.
Alright, that's easy to do. We will have to move out some clk data out of __init then. I already implemented it as you may see in the above PD summary.
Powered by blists - more mailing lists