| 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: <53244A88.9070806@gmail.com>
Date: Sat, 15 Mar 2014 13:41:44 +0100
From: Tomasz Figa <tomasz.figa@...il.com>
To: Kyungmin Park <kmpark@...radead.org>,
Tomasz Figa <t.figa@...sung.com>
CC: Chanwoo Choi <cw00.choi@...sung.com>,
Mark Rutland <mark.rutland@....com>,
"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
"rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
"nm@...com" <nm@...com>,
"b.zolnierkie@...saung.com" <b.zolnierkie@...saung.com>,
Pawel Moll <Pawel.Moll@....com>,
"swarren@...dotorg.org" <swarren@...dotorg.org>,
"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-samsung-soc@...r.kernel.org"
<linux-samsung-soc@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12
On 15.03.2014 12:36, Kyungmin Park wrote:
> On Sat, Mar 15, 2014 at 2:35 AM, Tomasz Figa <t.figa@...sung.com> wrote:
>> Hi Chanwoo, Mark,
>>
>>
>> On 14.03.2014 11:56, Chanwoo Choi wrote:
>>>
>>> Hi Mark,
>>>
>>> On 03/14/2014 07:35 PM, Mark Rutland wrote:
>>>>
>>>> On Fri, Mar 14, 2014 at 07:14:37AM +0000, Chanwoo Choi wrote:
>>>>>
>>>>> Hi Mark,
>>>>>
>>>>> On 03/14/2014 02:53 AM, Mark Rutland wrote:
>>>>>>
>>>>>> On Thu, Mar 13, 2014 at 08:17:29AM +0000, Chanwoo Choi wrote:
>>>>>>>
>>>>>>> This patch add busfreq driver for Exynos4210/Exynos4x12 memory
>>>>>>> interface
>>>>>>> and bus to support DVFS(Dynamic Voltage Frequency Scaling) according
>>>>>>> to PPMU
>>>>>>> counters. PPMU (Performance Profiling Monitorings Units) of Exynos4
>>>>>>> SoC provides
>>>>>>> PPMU counters for DMC(Dynamic Memory Controller) to check memory bus
>>>>>>> utilization
>>>>>>> and then busfreq driver adjusts dynamically the operating
>>>>>>> frequency/voltage
>>>>>>> by using DEVFREQ Subsystem.
>>>>>>>
>>>>>>> Signed-off-by: Chanwoo Choi <cw00.choi@...sung.com>
>>>>>>> ---
>>>>>>> .../devicetree/bindings/devfreq/exynos4_bus.txt | 49
>>>>>>> ++++++++++++++++++++++
>>>>>>> 1 file changed, 49 insertions(+)
>>>>>>> create mode 100644
>>>>>>> Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
>>>>>>> b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
>>>>>>> new file mode 100644
>>>>>>> index 0000000..2a83fcc
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
>>>>>>> @@ -0,0 +1,49 @@
>>>>>>> +
>>>>>>> +Exynos4210/4x12 busfreq driver
>>>>>>> +-----------------------------
>>>>>>> +
>>>>>>> +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus
>>>>>>> frequency/voltage
>>>>>>> +scaling according to PPMU counters of memory controllers
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +- compatible : should contain Exynos4 SoC type as follwoing:
>>>>>>> + - "samsung,exynos4x12-busfreq" for Exynos4x12
>>>>>>> + - "samsung,exynos4210-busfreq" for Exynos4210
>>>>>>
>>>>>>
>>>>>> Is there a device called "busfreq"? What device does this binding
>>>>>> describe?
>>>>>
>>>>>
>>>>> I'll add detailed description of busfreq as following:
>>>>>
>>>>> "busfreq(bus frequendcy)" driver means that busfreq driver control
>>>>> dynamically
>>>>> memory bus frequency/voltage by checking memory bus utilization to
>>>>> optimize
>>>>> power-consumption. When checking memeory bus utilization,
>>>>> exynos4_busfreq driver
>>>>> would use PPMU(Performance Profiling Monitoring Units).
>>>>
>>>>
>>>> This still sounds like a description of the _driver_, not the _device_.
>>>> The binding should describe the hardware, now the high level abstraction
>>>> that software is going to build atop of it.
>>>>
>>>> It sounds like this is a binding for the DMC PPMU?
>>>>
>>>> Is the PPMU a component of the DMC, or is it bolted on the side?
>>>
>>>
>>> PPMU(Performance Profiling Monitoring Unit) is to profile performance
>>> event of
>>> various IP on Exynos4. Each PPMU provide perforamnce event for each IP.
>>> We can check various PPMU as following:
>>>
>>> PPMU_3D
>>> PPMU_ACP
>>> PPMU_CAMIF
>>> PPMU_CPU
>>> PPMU_DMC0
>>> PPMU_DMC1
>>> PPMU_FSYS
>>> PPMU_IMAGE
>>> PPMU_LCD0
>>> PPMU_LCD1
>>> PPMU_MFC_L
>>> PPMU_MFC_R
>>> PPMU_TV
>>> PPMU_LEFT_BUS
>>> PPMU_RIGHT_BUS
>>>
>>> DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4
>>> SoC.
>>> If we need to get memory bust utilization of DMC, we can get memory bus
>>> utilization
>>> from PPMU_DMC0/PPMU_DMC1.
>>>
>>> So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various
>>> PPMU list.
>>
>>
>> Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs.
>> Busfreq/devfreq is just a Linux-specific abstraction responsible for
>> collecting data using PPMUs and controlling frequencies and voltages of
>> appropriate power planes, vdd_int responsible for powering DMC0 and DMC1
>> blocks in this case.
>>
>> I'm afraid that the binding you're proposing is unfortunately incorrect,
>> because it represents the software abstraction, not the real hardware.
>>
>> Instead, this should be separated into several independent bindings:
>>
>> - PPMU bindings to list all the PPMU instances present in the SoC and
>> resources they need,
>>
>> - power plane bindings, which define a power plane in which multiple IP
>> blocks might reside, can be monitored by one or more PPMU units and
>> frequency and voltage of which can be configured according to determined
>> performance level. Needed resources will be clocks and regulators to scale
>> and probably also operating points.
>>
>> Then, exynos-busfreq driver should bind to such power planes, parse
>> necessary data from DT (list of PPMUs and IP blocks, clocks, regulators and
>> operating points) and register a devfreq entity.
>
> How about to use component DT like DRM?
Well, basically this is what I proposed. Each "power plane" would be a
"subsystem" built from components - PPMUs, IP blocks, clocks,
regulators, etc, specified in DT by existing means, e.g.
ppmu_disp: ppmu@...40000 {
/* Resources of PPMU */
}
fimd: fimd@...50000 {
/* Resources of FIMD */
};
power-plane-display {
compatible = "samsung,power-plane";
samsung,ppmus = <&ppmu_disp>, ...;
samsung,devices = <&fimd>, ...;
clock-names = "aclk_xxx", "sclk_xxx", ...;
clocks = ...;
vdd_xxx-supply = ...;
};
However I'm still wondering whether there shouldn't be a relation
between power planes and power domains and simply existing power domain
nodes shouldn't be extended with the data I put above in
power-plane-display node. I need to check this in the documentation back
at work on Monday.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists