| Message ID | 1460089509-16260-3-git-send-email-cw00.choi@samsung.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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@samsung.com> > Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> > Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.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. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On Tue, Apr 12, 2016 at 12:40 AM, Rob Herring <robh@kernel.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@samsung.com> >> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> >> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On 2016? 04? 12? 05:25, Chanwoo Choi wrote: > Hi Rob, > > On Tue, Apr 12, 2016 at 12:40 AM, Rob Herring <robh@kernel.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@samsung.com> >>> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> >>> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.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. > --------------------------------------------------------------------- I'm considering about your comment about hierarchy. But, I think it is not appropriate. there is no perfect paired set between sub-block and dvfs driver for AMBA bus. For example about Exynos5420's JPEG IP, There are two JPEG IPs in the Exynos5420. But two JPEG IPs use the same source clock for AMBA AXI line to transfer data between DRAM and JPEG as following: (AXI master) (AXI slave) JPEG_0 --|-----(AXI)-----| | |---- DRAM JPEG_1 --|-----(AXI)-----| Two AMBA buses use the same source clock. So, only one dvfs driver should handle the source clock for AXI bus. Also, two JPEG use the same AMBA APB line to configure the register of JPEG IP as following: (APB slave) (APB master) JPEG_0 --|-----(APB)-----| | |---- CPU JPEG_1 --|-----(APB)-----| The JPEG_0/1 could not be included in both AXI and APB in Device Tree. Additionally, the I2C/SPI/PCI and etc use the APB bus for communication between each controller and CPU. I'll expect your reply. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. + +Required properties for bus device: +- compatible: Should be "samsung,exynos-bus". +- clock-names : the name of clock used by the bus, "bus". +- clocks : phandles for clock specified in "clock-names" property. +- operating-points-v2: the OPP table including frequency/voltage information + to support DVFS (Dynamic Voltage/Frequency Scaling) feature. +- vdd-supply: the regulator to provide the buses with the voltage. +- devfreq-events: the devfreq-event device to monitor the current utilization + of buses. + +Optional properties for bus device: +- exynos,saturation-ratio: the percentage value which is used to calibrate + the performance count against total cycle count. +- exynos,voltage-tolerance: the percentage value for bus voltage tolerance + which is used to calculate the max voltage. + +Example1: + Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to + power line (regulator). The MIF (Memory Interface) AXI bus is used to + transfer data between DRAM and CPU and uses the VDD_MIF regualtor. + + - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block + + - MIF bus's frequency/voltage table + ----------------------- + |Lv| Freq | Voltage | + ----------------------- + |L1| 50000 |800000 | + |L2| 100000 |800000 | + |L3| 134000 |800000 | + |L4| 200000 |825000 | + |L5| 400000 |875000 | + ----------------------- + +Example2 : + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi + is listed below: + + bus_dmc: bus_dmc { + compatible = "samsung,exynos-bus"; + clocks = <&cmu_dmc CLK_DIV_DMC>; + clock-names = "bus"; + operating-points-v2 = <&bus_dmc_opp_table>; + status = "disabled"; + }; + + bus_dmc_opp_table: opp_table1 { + compatible = "operating-points-v2"; + opp-shared; + + opp@50000000 { + opp-hz = /bits/ 64 <50000000>; + opp-microvolt = <800000>; + }; + opp@100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <800000>; + }; + opp@134000000 { + opp-hz = /bits/ 64 <134000000>; + opp-microvolt = <800000>; + }; + opp@200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <825000>; + }; + opp@400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <875000>; + }; + }; + + Usage case to handle the frequency and voltage of bus on runtime + in exynos3250-rinato.dts is listed below: + + &bus_dmc { + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>; + vdd-supply = <&buck1_reg>; /* VDD_MIF */ + status = "okay"; + };