linux-kernel - Re: [PATCH v8 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Apr 2016 05:25:58 +0900
From:	Chanwoo Choi <cwchoi00@...il.com>
To:	Rob Herring <robh@...nel.org>
Cc:	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Krzysztof Kozłowski <k.kozlowski@...sung.com>,
	Kukjin Kim <kgene@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Anand Moon <linux.amoon@...il.com>,
	Markus Reichl <m.reichl@...etechno.de>,
	Tobias Jakobi <tjakobi@...h.uni-bielefeld.de>,
	"inki.dae@...sung.com" <inki.dae@...sung.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH v8 02/20] PM / devfreq: exynos: Add documentation for
 generic exynos bus frequency driver

Hi Rob,

On Tue, Apr 12, 2016 at 12:40 AM, Rob Herring <robh@...nel.org> wrote:
> On Fri, Apr 08, 2016 at 01:24:51PM +0900, Chanwoo Choi wrote:
>> This patch adds the documentation for generic exynos bus frequency
>> driver.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@...sung.com>
>> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@...sung.com>
>> Signed-off-by: MyungJoo Ham <myungjoo.ham@...sung.com>
>> ---
>>  .../devicetree/bindings/devfreq/exynos-bus.txt     | 95 ++++++++++++++++++++++
>>  1 file changed, 95 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> new file mode 100644
>> index 000000000000..78171b918e3f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -0,0 +1,95 @@
>> +* Generic Exynos Bus frequency device
>> +
>> +The Samsung Exynos SoC has many buses for data transfer between DRAM
>> +and sub-blocks in SoC. Most Exynos SoCs share the common architecture
>> +for buses. Generally, each bus of Exynos SoC includes a source clock
>> +and a power line, which are able to change the clock frequency
>> +of the bus in runtime. To monitor the usage of each bus in runtime,
>> +the driver uses the PPMU (Platform Performance Monitoring Unit), which
>> +is able to measure the current load of sub-blocks.
>> +
>> +There are a little different composition among Exynos SoC because each Exynos
>> +SoC has different sub-blocks. Therefore, shch difference should be specified
>> +in devicetree file instead of each device driver. In result, this driver
>> +is able to support the bus frequency for all Exynos SoCs.
>
> I still have issues with this whole series. The DT hierarchy represents
> buses. You are describing buses here and control of them. I would expect
> to see some hierarchy, but there is none. What this looks like is you
> are adding nodes based on what fits the current driver.

I already replied[1] about your same question on v2 patchset four 4 months ago.
[1] https://lkml.org/lkml/2015/12/10/943

I attach the your question and my reply history as following:
---------------------------------------------------------------------
[ Discussion between you and me on v2 patchset[1] ]
>>>
>>> This still has the same problem as before. I would expect that the bus
>>> hierarchy in the dts match the hierarchy here. You just have flat nodes
>>> in the example below. So all IP blocks affected by frequency scaling
>>> should be under the bus node defining the OPPs. Something like this:
>>
>> The each bus of sub-block has not h/w dependency among sub-blocks
>> and has the owned source clock / OPP table. Just they share the same
>> power line. So, I think that flat nodes in the example below is not problem.
>
> I'm talking about the peripherals not described here. Is the ISP block
> not a child of the bus_isp node? Same for the display controller block
> and bus_lcd0. And so on.

>From the H/W point of view, ISP block is really not included in ISP's
AXI bus (bus_isp).
Just, the bus_isp connect to between ISP block and DRAM.
---------------------------------------------------------------------

Thanks,
Chanwoo Choi