Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 21 January 2015 at 11:42, Chanwoo Choi wrote: > OK, I understand. > I'll try to update exynos memory bus according to your comment. Great. @Rob: So there is nothing special required for devfreq drivers in new OPP bindings, right ? :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 01/21/2015 01:37 PM, Viresh Kumar wrote:
> On 21 January 2015 at 09:50, Chanwoo Choi wrote:
>> If the clock will be stayed on highest voltage, will reduce
>> the considerable benefit of power-consumption.
>
> But this is exactly what you must be doing right now as well..
> I think I didn't make it clear enough with an example. Let me
> try..
>
> This is how I feel it should look like:
>
>memory_bus_int: memory_bus@1 {
>// Regulator is shared for all below
>blocks {
>peri_block: memory_bus_block1 {
> operating-points = <
> 10 85
> 5 85>;
>};
>
>display_block: memory_bus_block2 {
> operating-points = <
> 20 95
> 16 95
> 10 925000
> 8 85
> 5 85>;
>};
>
>isp_block: memory_bus_block3 {
> operating-points = <
> 20 95
> 10 925000
> 8 85
> 5 85>;
>};
>
>gps_block: memory_bus_block4 {
> operating-points = <
> 30 95
> 20 95
> 133000 925000
> 10 85
> 5 85>;
>};
>
>
> Now suppose these are the requirements from all the blocks
> at any point of time:
> - block1: 10 85
> - block2: 10 925000
> - block3: 8 85
> - block4: 133000 925000
>
> Now, all of them can control freq separately and we don't need to
> worry for that. But regulator is shared between them. We can check
> what's the highest voltage requested at this point of time and can
> switch to that.
>
> i.e. 925000 in this case. And that's not the highest possible one.
> And you will reach to similar conclusion with your current code as
> well I believe.
>
OK, I understand.
I'll try to update exynos memory bus according to your comment.
Thanks
Chanwoo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 21 January 2015 at 09:50, Chanwoo Choi wrote:
> If the clock will be stayed on highest voltage, will reduce
> the considerable benefit of power-consumption.
But this is exactly what you must be doing right now as well..
I think I didn't make it clear enough with an example. Let me
try..
This is how I feel it should look like:
memory_bus_int: memory_bus@1 {
// Regulator is shared for all below
blocks {
peri_block: memory_bus_block1 {
operating-points = <
10 85
5 85>;
};
display_block: memory_bus_block2 {
operating-points = <
20 95
16 95
10 925000
8 85
5 85>;
};
isp_block: memory_bus_block3 {
operating-points = <
20 95
10 925000
8 85
5 85>;
};
gps_block: memory_bus_block4 {
operating-points = <
30 95
20 95
133000 925000
10 85
5 85>;
};
Now suppose these are the requirements from all the blocks
at any point of time:
- block1: 10 85
- block2: 10 925000
- block3: 8 85
- block4: 133000 925000
Now, all of them can control freq separately and we don't need to
worry for that. But regulator is shared between them. We can check
what's the highest voltage requested at this point of time and can
switch to that.
i.e. 925000 in this case. And that's not the highest possible one.
And you will reach to similar conclusion with your current code as
well I believe.
> I think it is DFS instead of DVFS. Is it right?
No. I am still talking about DVFS, V being the highest requested one.
> What is the correct picture? do you need more detailed explanation
> of Exynos memory bus structure?
The correct picture is what i showed in the above dts example.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 01/21/2015 12:17 PM, Viresh Kumar wrote: > On 20 January 2015 at 17:07, Chanwoo Choi wrote: >> If each bus-block has separate regulator independently, each bus-block can >> be registered >> separately. But, exynos bus-blocks in mem-bus-group share the same regulator. > > This can be managed easily within the driver. Just stay the highest > voltage requested. If the clock will be stayed on highest voltage, will reduce the considerable benefit of power-consumption. I think it is DFS instead of DVFS. Is it right? > I don't think its not manageable. But it will be much more convenient > as that will show > the correct picture and get rid of unnecessarily virtualizing things.. What is the correct picture? do you need more detailed explanation of Exynos memory bus structure? Thanks, Chanwoo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 20 January 2015 at 17:07, Chanwoo Choi wrote: > If each bus-block has separate regulator independently, each bus-block can be > registered > separately. But, exynos bus-blocks in mem-bus-group share the same regulator. This can be managed easily within the driver. Just stay the highest voltage requested. I don't think its not manageable. But it will be much more convenient as that will show the correct picture and get rid of unnecessarily virtualizing things.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 01/20/2015 08:22 PM, Viresh Kumar wrote:
> On 20 January 2015 at 13:53, Chanwoo Choi wrote:
>> But, the frequency of OPPs is only used for devfreq ondemand governor.
>> After deciding the proper frequency of memory bus on ondemand governor,
>> exynos-bus.c (exynos memory bus frequency driver) use the frequency table
>> of memory bus blocks on below to change the clock rate of memory bus block.
>
>> Firs of all,
>> I explain the hierarchy of Exynos memory buses.
>>
>> For example of Exynos3250 memory bus,
>> This patch divide the memory bus group according to power rail (regulator).
>> - MIF (Memory Interface ) memory bus group uses the VDD_MIF regulator.
>> - INT (Internal) memory bus group uses the VDD_INT regulator.
>>
>> Each memory bus group contains only one power rail(regulator) and one more
>> memory bus blocks as follwing:
>>
>> - MIF memory bus group
>> power rail(VDD_MIF)-->|--- memory bus for DMC (Dynamic Memory Controller)
>> block (dmc clock)
>>
>> - INT memory bus group
>> |--- memory bus for PERI block (aclk_100 clock)
>> |
>> |--- memory bus for DISPLAY block (aclk_160 clock)
>> |
>> |--- memory bus for ISP block (aclk_200 clock)
>> |
>> |--- memory bus for GPS block (aclk_266 clock)
>> power rail(VDD_INT)-->|
>> |--- memory bus for MCUISP block (aclk_400_mcuisp
>> clock)
>> |
>> |--- memory bus for Leftbus block (gdl clock)
>> |
>> |--- memory bus for Rightbus block (gdr clock)
>> |
>> |--- memory bus for MFC block (mfc clock)
>>
>>
>> Exynos3250 has following table for INT memory bus group:
>> All clocks of INT memory bus group have to contain the same entry count
>> againt the number of 'virtual freqw'. So, each memory bus clock could have
>> duplicate clocks.
>>
>>
>> Level|virtual freq|PERI's clk|Display's clk|ISP's clk|GPS's clk| voltage|
>>
>> L6 |40 |10|20 |20 |30 | 95000 |
>> L5 |20 |10|16 |20 |20 | 95000 |
>> L4 |133000 |10|10 |10 |133000 | 92500 |
>> L3 |10 |10|8|8|10 | 85000 |
>> L2 |8 |5 |8|5|5| 85000 |
>> L1 |5 |5 |5|5|5| 85000 |
>> -
>> (Except for mcuisp, leftbus, rightbus, mfc block)
>>
>> This table is used for devfreq ondemand governor as following:
>> 1. ondemand governor in devfreq use the 'virtual freq' to devcide the proper
>>frequency for memory bus.
>> 2. ondemand governor executes the *_target() function to set clock rate and
>> voltage.
>> 3. *_target() function in exynos-bus.c changes the clock rate of
>> {PERIS|Display|ISP|GPS} clk
>>according to decided 'Level' by devfreq ondemand governor.
>
> I see..
>
> Please confirm if my understanding is correct.
> - mem-bus-group: all blocks sharing a regulator
> - mem-bus-block: individual blocks managing their clock rate
Right and mem-bus-blcoks are included in a mem-bus-group.
>
> What you do in kernel is register group as a device (with virtual OPPs)
> and then manage blocks within the driver. And so you need to do this
> dummy mapping of virtual to physical frequencies.
Right.
>
> It *may* not have done it this way, if I was to design this driver.
>
> Each bus-block is a separately controllable device and so must be registered
> separately. In that case all bus-blocks will have separate OPP tables and
> all this dummy-v2p mapping will go away.
If each bus-block has separate regulator independently, each bus-block can be
registered
separately. But, exynos bus-blocks in mem-bus-group share the same regulator.
>
> I believe that you are over complicating stuff without any need..
>
> --
> viresh
>
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 20 January 2015 at 13:53, Chanwoo Choi wrote:
> But, the frequency of OPPs is only used for devfreq ondemand governor.
> After deciding the proper frequency of memory bus on ondemand governor,
> exynos-bus.c (exynos memory bus frequency driver) use the frequency table
> of memory bus blocks on below to change the clock rate of memory bus block.
> Firs of all,
> I explain the hierarchy of Exynos memory buses.
>
> For example of Exynos3250 memory bus,
> This patch divide the memory bus group according to power rail (regulator).
> - MIF (Memory Interface ) memory bus group uses the VDD_MIF regulator.
> - INT (Internal) memory bus group uses the VDD_INT regulator.
>
> Each memory bus group contains only one power rail(regulator) and one more
> memory bus blocks as follwing:
>
> - MIF memory bus group
> power rail(VDD_MIF)-->|--- memory bus for DMC (Dynamic Memory Controller)
> block (dmc clock)
>
> - INT memory bus group
> |--- memory bus for PERI block (aclk_100 clock)
> |
> |--- memory bus for DISPLAY block (aclk_160 clock)
> |
> |--- memory bus for ISP block (aclk_200 clock)
> |
> |--- memory bus for GPS block (aclk_266 clock)
> power rail(VDD_INT)-->|
> |--- memory bus for MCUISP block (aclk_400_mcuisp clock)
> |
> |--- memory bus for Leftbus block (gdl clock)
> |
> |--- memory bus for Rightbus block (gdr clock)
> |
> |--- memory bus for MFC block (mfc clock)
>
>
> Exynos3250 has following table for INT memory bus group:
> All clocks of INT memory bus group have to contain the same entry count
> againt the number of 'virtual freqw'. So, each memory bus clock could have
> duplicate clocks.
>
>
> Level|virtual freq|PERI's clk|Display's clk|ISP's clk|GPS's clk| voltage|
>
> L6 |40 |10|20 |20 |30 | 95000 |
> L5 |20 |10|16 |20 |20 | 95000 |
> L4 |133000 |10|10 |10 |133000 | 92500 |
> L3 |10 |10|8|8|10 | 85000 |
> L2 |8 |5 |8|5|5| 85000 |
> L1 |5 |5 |5|5|5| 85000 |
> -
> (Except for mcuisp, leftbus, rightbus, mfc block)
>
> This table is used for devfreq ondemand governor as following:
> 1. ondemand governor in devfreq use the 'virtual freq' to devcide the proper
>frequency for memory bus.
> 2. ondemand governor executes the *_target() function to set clock rate and
> voltage.
> 3. *_target() function in exynos-bus.c changes the clock rate of
> {PERIS|Display|ISP|GPS} clk
>according to decided 'Level' by devfreq ondemand governor.
I see..
Please confirm if my understanding is correct.
- mem-bus-group: all blocks sharing a regulator
- mem-bus-block: individual blocks managing their clock rate
What you do in kernel is register group as a device (with virtual OPPs)
and then manage blocks within the driver. And so you need to do this
dummy mapping of virtual to physical frequencies.
It *may* not have done it this way, if I was to design this driver.
Each bus-block is a separately controllable device and so must be registered
separately. In that case all bus-blocks will have separate OPP tables and
all this dummy-v2p mapping will go away.
I believe that you are over complicating stuff without any need..
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Hi Viresh,
I explained the relation between memory bus group and memory bus block on
following patch[1].
- [1] https://lkml.org/lkml/2015/1/8/642
On 01/20/2015 04:19 PM, Viresh Kumar wrote:
> On 9 January 2015 at 02:48, Rob Herring wrote:
>> Adding Viresh.
>
> Sorry for being too late, I was very busy with other cpufreq stuff I was doing
> and saved this thread for later as it required me to understand it properly..
>
>>> +Required properties for memory bus block:
>>> +- clock-names : the name of clock used by the memory bus, "memory-bus".
>>> +- clocks : phandles for clock specified in "clock-names" property.
>>> +- #clock-cells: should be 1.
>>> +- frequency: the frequency table to support DVFS feature.
>>
>> So you have just defined a new OPP table format. We already have one
>> and Viresh is working to create a more extendable one. He asked about
>> what's needed in devfreq, so Viresh here you go. :)
>
> I failed to understand what's new here, probably I need more clarity on
> what we are doing here..
>
> So, this is what I see from OPPs point of view, everything else stripped out.
>
>>> + memory_bus_int: memory_bus@1 {
>
>>> + operating-points = <
>>> + 40 95
>>> + 20 95
>>> + 133000 925000
>>> + 10 85
>>> + 8 85
>>> + 5 85>;
>
> So these are the OPPs your "groups" support and below ones are
> the frequencies that each block will support. Right ?
Right.
But, the frequency of OPPs is only used for devfreq ondemand governor.
After deciding the proper frequency of memory bus on ondemand governor,
exynos-bus.c (exynos memory bus frequency driver) use the frequency table
of memory bus blocks on below to change the clock rate of memory bus block.
>
>>> + blocks {
>
>>> + frequency = <
>>> + 10
>>> + 10
>>> + 10
>>> + 10
>
> Why this replication here ?
Firs of all,
I explain the hierarchy of Exynos memory buses.
For example of Exynos3250 memory bus,
This patch divide the memory bus group according to power rail (regulator).
- MIF (Memory Interface ) memory bus group uses the VDD_MIF regulator.
- INT (Internal) memory bus group uses the VDD_INT regulator.
Each memory bus group contains only one power rail(regulator) and one more
memory bus blocks as follwing:
- MIF memory bus group
power rail(VDD_MIF)-->|--- memory bus for DMC (Dynamic Memory Controller) block
(dmc clock)
- INT memory bus group
|--- memory bus for PERI block (aclk_100 clock)
|
|--- memory bus for DISPLAY block (aclk_160 clock)
|
|--- memory bus for ISP block (aclk_200 clock)
|
|--- memory bus for GPS block (aclk_266 clock)
power rail(VDD_INT)-->|
|--- memory bus for MCUISP block (aclk_400_mcuisp clock)
|
|--- memory bus for Leftbus block (gdl clock)
|
|--- memory bus for Rightbus block (gdr clock)
|
|--- memory bus for MFC block (mfc clock)
Exynos3250 has following table for INT memory bus group:
All clocks of INT memory bus group have to contain the same entry count
againt the number of 'virtual freqw'. So, each memory bus clock could have
duplicate clocks.
Level|virtual freq|PERI's clk|Display's clk|ISP's clk|GPS's clk| voltage|
L6 |40 |10|20 |20 |30 | 95000 |
L5 |20 |10|16 |20 |20 | 95000 |
L4 |133000 |10|10 |10 |133000 | 92500 |
L3 |10 |10|8|8|10 | 85000 |
L2 |8 |5 |8|5|5| 85000 |
L1 |5 |5 |5|5|5| 85000 |
-
(Except for mcuisp, leftbus, rightbus, mfc block)
This table is used for devfreq ondemand governor as following:
1. ondemand governor in devfreq use the 'virtual freq' to devcide the proper
frequency for memory bus.
2. ondemand governor executes the *_target() function to set clock rate and
voltage.
3. *_target() function in exynos-bus.c changes the clock rate of
{PERIS|Display|ISP|GPS} clk
according to decided 'Level' by devfreq ondemand governor.
>
>>> + 5
>>>
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Hi Viresh,
I explained the relation between memory bus group and memory bus block on
following patch[1].
- [1] https://lkml.org/lkml/2015/1/8/642
On 01/20/2015 04:19 PM, Viresh Kumar wrote:
On 9 January 2015 at 02:48, Rob Herring robherri...@gmail.com wrote:
Adding Viresh.
Sorry for being too late, I was very busy with other cpufreq stuff I was doing
and saved this thread for later as it required me to understand it properly..
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, memory-bus.
+- clocks : phandles for clock specified in clock-names property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
So you have just defined a new OPP table format. We already have one
and Viresh is working to create a more extendable one. He asked about
what's needed in devfreq, so Viresh here you go. :)
I failed to understand what's new here, probably I need more clarity on
what we are doing here..
So, this is what I see from OPPs point of view, everything else stripped out.
+ memory_bus_int: memory_bus@1 {
+ operating-points =
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85;
So these are the OPPs your groups support and below ones are
the frequencies that each block will support. Right ?
Right.
But, the frequency of OPPs is only used for devfreq ondemand governor.
After deciding the proper frequency of memory bus on ondemand governor,
exynos-bus.c (exynos memory bus frequency driver) use the frequency table
of memory bus blocks on below to change the clock rate of memory bus block.
+ blocks {
+ frequency =
+ 10
+ 10
+ 10
+ 10
Why this replication here ?
Firs of all,
I explain the hierarchy of Exynos memory buses.
For example of Exynos3250 memory bus,
This patch divide the memory bus group according to power rail (regulator).
- MIF (Memory Interface ) memory bus group uses the VDD_MIF regulator.
- INT (Internal) memory bus group uses the VDD_INT regulator.
Each memory bus group contains only one power rail(regulator) and one more
memory bus blocks as follwing:
- MIF memory bus group
power rail(VDD_MIF)--|--- memory bus for DMC (Dynamic Memory Controller) block
(dmc clock)
- INT memory bus group
|--- memory bus for PERI block (aclk_100 clock)
|
|--- memory bus for DISPLAY block (aclk_160 clock)
|
|--- memory bus for ISP block (aclk_200 clock)
|
|--- memory bus for GPS block (aclk_266 clock)
power rail(VDD_INT)--|
|--- memory bus for MCUISP block (aclk_400_mcuisp clock)
|
|--- memory bus for Leftbus block (gdl clock)
|
|--- memory bus for Rightbus block (gdr clock)
|
|--- memory bus for MFC block (mfc clock)
Exynos3250 has following table for INT memory bus group:
All clocks of INT memory bus group have to contain the same entry count
againt the number of 'virtual freqw'. So, each memory bus clock could have
duplicate clocks.
Level|virtual freq|PERI's clk|Display's clk|ISP's clk|GPS's clk| voltage|
L6 |40 |10|20 |20 |30 | 95000 |
L5 |20 |10|16 |20 |20 | 95000 |
L4 |133000 |10|10 |10 |133000 | 92500 |
L3 |10 |10|8|8|10 | 85000 |
L2 |8 |5 |8|5|5| 85000 |
L1 |5 |5 |5|5|5| 85000 |
-
(Except for mcuisp, leftbus, rightbus, mfc block)
This table is used for devfreq ondemand governor as following:
1. ondemand governor in devfreq use the 'virtual freq' to devcide the proper
frequency for memory bus.
2. ondemand governor executes the *_target() function to set clock rate and
voltage.
3. *_target() function in exynos-bus.c changes the clock rate of
{PERIS|Display|ISP|GPS} clk
according to decided 'Level' by devfreq ondemand governor.
+ 5
+ 5;
+ };
How
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 20 January 2015 at 13:53, Chanwoo Choi cw00.c...@samsung.com wrote:
But, the frequency of OPPs is only used for devfreq ondemand governor.
After deciding the proper frequency of memory bus on ondemand governor,
exynos-bus.c (exynos memory bus frequency driver) use the frequency table
of memory bus blocks on below to change the clock rate of memory bus block.
Firs of all,
I explain the hierarchy of Exynos memory buses.
For example of Exynos3250 memory bus,
This patch divide the memory bus group according to power rail (regulator).
- MIF (Memory Interface ) memory bus group uses the VDD_MIF regulator.
- INT (Internal) memory bus group uses the VDD_INT regulator.
Each memory bus group contains only one power rail(regulator) and one more
memory bus blocks as follwing:
- MIF memory bus group
power rail(VDD_MIF)--|--- memory bus for DMC (Dynamic Memory Controller)
block (dmc clock)
- INT memory bus group
|--- memory bus for PERI block (aclk_100 clock)
|
|--- memory bus for DISPLAY block (aclk_160 clock)
|
|--- memory bus for ISP block (aclk_200 clock)
|
|--- memory bus for GPS block (aclk_266 clock)
power rail(VDD_INT)--|
|--- memory bus for MCUISP block (aclk_400_mcuisp clock)
|
|--- memory bus for Leftbus block (gdl clock)
|
|--- memory bus for Rightbus block (gdr clock)
|
|--- memory bus for MFC block (mfc clock)
Exynos3250 has following table for INT memory bus group:
All clocks of INT memory bus group have to contain the same entry count
againt the number of 'virtual freqw'. So, each memory bus clock could have
duplicate clocks.
Level|virtual freq|PERI's clk|Display's clk|ISP's clk|GPS's clk| voltage|
L6 |40 |10|20 |20 |30 | 95000 |
L5 |20 |10|16 |20 |20 | 95000 |
L4 |133000 |10|10 |10 |133000 | 92500 |
L3 |10 |10|8|8|10 | 85000 |
L2 |8 |5 |8|5|5| 85000 |
L1 |5 |5 |5|5|5| 85000 |
-
(Except for mcuisp, leftbus, rightbus, mfc block)
This table is used for devfreq ondemand governor as following:
1. ondemand governor in devfreq use the 'virtual freq' to devcide the proper
frequency for memory bus.
2. ondemand governor executes the *_target() function to set clock rate and
voltage.
3. *_target() function in exynos-bus.c changes the clock rate of
{PERIS|Display|ISP|GPS} clk
according to decided 'Level' by devfreq ondemand governor.
I see..
Please confirm if my understanding is correct.
- mem-bus-group: all blocks sharing a regulator
- mem-bus-block: individual blocks managing their clock rate
What you do in kernel is register group as a device (with virtual OPPs)
and then manage blocks within the driver. And so you need to do this
dummy mapping of virtual to physical frequencies.
It *may* not have done it this way, if I was to design this driver.
Each bus-block is a separately controllable device and so must be registered
separately. In that case all bus-blocks will have separate OPP tables and
all this dummy-v2p mapping will go away.
I believe that you are over complicating stuff without any need..
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 01/20/2015 08:22 PM, Viresh Kumar wrote:
On 20 January 2015 at 13:53, Chanwoo Choi cw00.c...@samsung.com wrote:
But, the frequency of OPPs is only used for devfreq ondemand governor.
After deciding the proper frequency of memory bus on ondemand governor,
exynos-bus.c (exynos memory bus frequency driver) use the frequency table
of memory bus blocks on below to change the clock rate of memory bus block.
Firs of all,
I explain the hierarchy of Exynos memory buses.
For example of Exynos3250 memory bus,
This patch divide the memory bus group according to power rail (regulator).
- MIF (Memory Interface ) memory bus group uses the VDD_MIF regulator.
- INT (Internal) memory bus group uses the VDD_INT regulator.
Each memory bus group contains only one power rail(regulator) and one more
memory bus blocks as follwing:
- MIF memory bus group
power rail(VDD_MIF)--|--- memory bus for DMC (Dynamic Memory Controller)
block (dmc clock)
- INT memory bus group
|--- memory bus for PERI block (aclk_100 clock)
|
|--- memory bus for DISPLAY block (aclk_160 clock)
|
|--- memory bus for ISP block (aclk_200 clock)
|
|--- memory bus for GPS block (aclk_266 clock)
power rail(VDD_INT)--|
|--- memory bus for MCUISP block (aclk_400_mcuisp
clock)
|
|--- memory bus for Leftbus block (gdl clock)
|
|--- memory bus for Rightbus block (gdr clock)
|
|--- memory bus for MFC block (mfc clock)
Exynos3250 has following table for INT memory bus group:
All clocks of INT memory bus group have to contain the same entry count
againt the number of 'virtual freqw'. So, each memory bus clock could have
duplicate clocks.
Level|virtual freq|PERI's clk|Display's clk|ISP's clk|GPS's clk| voltage|
L6 |40 |10|20 |20 |30 | 95000 |
L5 |20 |10|16 |20 |20 | 95000 |
L4 |133000 |10|10 |10 |133000 | 92500 |
L3 |10 |10|8|8|10 | 85000 |
L2 |8 |5 |8|5|5| 85000 |
L1 |5 |5 |5|5|5| 85000 |
-
(Except for mcuisp, leftbus, rightbus, mfc block)
This table is used for devfreq ondemand governor as following:
1. ondemand governor in devfreq use the 'virtual freq' to devcide the proper
frequency for memory bus.
2. ondemand governor executes the *_target() function to set clock rate and
voltage.
3. *_target() function in exynos-bus.c changes the clock rate of
{PERIS|Display|ISP|GPS} clk
according to decided 'Level' by devfreq ondemand governor.
I see..
Please confirm if my understanding is correct.
- mem-bus-group: all blocks sharing a regulator
- mem-bus-block: individual blocks managing their clock rate
Right and mem-bus-blcoks are included in a mem-bus-group.
What you do in kernel is register group as a device (with virtual OPPs)
and then manage blocks within the driver. And so you need to do this
dummy mapping of virtual to physical frequencies.
Right.
It *may* not have done it this way, if I was to design this driver.
Each bus-block is a separately controllable device and so must be registered
separately. In that case all bus-blocks will have separate OPP tables and
all this dummy-v2p mapping will go away.
If each bus-block has separate regulator independently, each bus-block can be
registered
separately. But, exynos bus-blocks in mem-bus-group share the same regulator.
I believe that you are over complicating stuff without any need..
--
viresh
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 01/21/2015 12:17 PM, Viresh Kumar wrote: On 20 January 2015 at 17:07, Chanwoo Choi cw00.c...@samsung.com wrote: If each bus-block has separate regulator independently, each bus-block can be registered separately. But, exynos bus-blocks in mem-bus-group share the same regulator. This can be managed easily within the driver. Just stay the highest voltage requested. If the clock will be stayed on highest voltage, will reduce the considerable benefit of power-consumption. I think it is DFS instead of DVFS. Is it right? I don't think its not manageable. But it will be much more convenient as that will show the correct picture and get rid of unnecessarily virtualizing things.. What is the correct picture? do you need more detailed explanation of Exynos memory bus structure? Thanks, Chanwoo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 20 January 2015 at 17:07, Chanwoo Choi cw00.c...@samsung.com wrote: If each bus-block has separate regulator independently, each bus-block can be registered separately. But, exynos bus-blocks in mem-bus-group share the same regulator. This can be managed easily within the driver. Just stay the highest voltage requested. I don't think its not manageable. But it will be much more convenient as that will show the correct picture and get rid of unnecessarily virtualizing things.. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 21 January 2015 at 09:50, Chanwoo Choi cw00.c...@samsung.com wrote:
If the clock will be stayed on highest voltage, will reduce
the considerable benefit of power-consumption.
But this is exactly what you must be doing right now as well..
I think I didn't make it clear enough with an example. Let me
try..
This is how I feel it should look like:
memory_bus_int: memory_bus@1 {
// Regulator is shared for all below
blocks {
peri_block: memory_bus_block1 {
operating-points =
10 85
5 85;
};
display_block: memory_bus_block2 {
operating-points =
20 95
16 95
10 925000
8 85
5 85;
};
isp_block: memory_bus_block3 {
operating-points =
20 95
10 925000
8 85
5 85;
};
gps_block: memory_bus_block4 {
operating-points =
30 95
20 95
133000 925000
10 85
5 85;
};
Now suppose these are the requirements from all the blocks
at any point of time:
- block1: 10 85
- block2: 10 925000
- block3: 8 85
- block4: 133000 925000
Now, all of them can control freq separately and we don't need to
worry for that. But regulator is shared between them. We can check
what's the highest voltage requested at this point of time and can
switch to that.
i.e. 925000 in this case. And that's not the highest possible one.
And you will reach to similar conclusion with your current code as
well I believe.
I think it is DFS instead of DVFS. Is it right?
No. I am still talking about DVFS, V being the highest requested one.
What is the correct picture? do you need more detailed explanation
of Exynos memory bus structure?
The correct picture is what i showed in the above dts example.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 21 January 2015 at 11:42, Chanwoo Choi cw00.c...@samsung.com wrote: OK, I understand. I'll try to update exynos memory bus according to your comment. Great. @Rob: So there is nothing special required for devfreq drivers in new OPP bindings, right ? :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 01/21/2015 01:37 PM, Viresh Kumar wrote:
On 21 January 2015 at 09:50, Chanwoo Choi cw00.c...@samsung.com wrote:
If the clock will be stayed on highest voltage, will reduce
the considerable benefit of power-consumption.
But this is exactly what you must be doing right now as well..
I think I didn't make it clear enough with an example. Let me
try..
This is how I feel it should look like:
memory_bus_int: memory_bus@1 {
// Regulator is shared for all below
blocks {
peri_block: memory_bus_block1 {
operating-points =
10 85
5 85;
};
display_block: memory_bus_block2 {
operating-points =
20 95
16 95
10 925000
8 85
5 85;
};
isp_block: memory_bus_block3 {
operating-points =
20 95
10 925000
8 85
5 85;
};
gps_block: memory_bus_block4 {
operating-points =
30 95
20 95
133000 925000
10 85
5 85;
};
Now suppose these are the requirements from all the blocks
at any point of time:
- block1: 10 85
- block2: 10 925000
- block3: 8 85
- block4: 133000 925000
Now, all of them can control freq separately and we don't need to
worry for that. But regulator is shared between them. We can check
what's the highest voltage requested at this point of time and can
switch to that.
i.e. 925000 in this case. And that's not the highest possible one.
And you will reach to similar conclusion with your current code as
well I believe.
OK, I understand.
I'll try to update exynos memory bus according to your comment.
Thanks
Chanwoo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 9 January 2015 at 02:48, Rob Herring wrote:
> Adding Viresh.
Sorry for being too late, I was very busy with other cpufreq stuff I was doing
and saved this thread for later as it required me to understand it properly..
>> +Required properties for memory bus block:
>> +- clock-names : the name of clock used by the memory bus, "memory-bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- #clock-cells: should be 1.
>> +- frequency: the frequency table to support DVFS feature.
>
> So you have just defined a new OPP table format. We already have one
> and Viresh is working to create a more extendable one. He asked about
> what's needed in devfreq, so Viresh here you go. :)
I failed to understand what's new here, probably I need more clarity on
what we are doing here..
So, this is what I see from OPPs point of view, everything else stripped out.
>> + memory_bus_int: memory_bus@1 {
>> + operating-points = <
>> + 40 95
>> + 20 95
>> + 133000 925000
>> + 10 85
>> + 8 85
>> + 5 85>;
So these are the OPPs your "groups" support and below ones are
the frequencies that each block will support. Right ?
>> + blocks {
>> + frequency = <
>> + 10
>> + 10
>> + 10
>> + 10
Why this replication here ?
>> + 5
>> + 5>;
>> + };
How are the above two tables (operating-points and frequency) related
here? What about the voltages at which these frequencies are possible ?
>> + display_block: memory_bus_block2 {
>> + frequency = <
>> + 20
>> + 16
>> + 10
>> + 8
>> + 8
>> + 5>;
>> + };
>> + isp_block: memory_bus_block3 {
>> + frequency = <
>> + 20
>> + 20
>> + 10
>> + 8
>> + 5
>> + 5>;
>> + };
>> + gps_block: memory_bus_block4 {
>> + frequency = <
>> + 30
>> + 20
>> + 133000
>> + 10
>> + 5
>> + 5>;
>> + };
same for others as well..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 9 January 2015 at 02:48, Rob Herring robherri...@gmail.com wrote:
Adding Viresh.
Sorry for being too late, I was very busy with other cpufreq stuff I was doing
and saved this thread for later as it required me to understand it properly..
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, memory-bus.
+- clocks : phandles for clock specified in clock-names property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
So you have just defined a new OPP table format. We already have one
and Viresh is working to create a more extendable one. He asked about
what's needed in devfreq, so Viresh here you go. :)
I failed to understand what's new here, probably I need more clarity on
what we are doing here..
So, this is what I see from OPPs point of view, everything else stripped out.
+ memory_bus_int: memory_bus@1 {
+ operating-points =
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85;
So these are the OPPs your groups support and below ones are
the frequencies that each block will support. Right ?
+ blocks {
+ frequency =
+ 10
+ 10
+ 10
+ 10
Why this replication here ?
+ 5
+ 5;
+ };
How are the above two tables (operating-points and frequency) related
here? What about the voltages at which these frequencies are possible ?
+ display_block: memory_bus_block2 {
+ frequency =
+ 20
+ 16
+ 10
+ 8
+ 8
+ 5;
+ };
+ isp_block: memory_bus_block3 {
+ frequency =
+ 20
+ 20
+ 10
+ 8
+ 5
+ 5;
+ };
+ gps_block: memory_bus_block4 {
+ frequency =
+ 30
+ 20
+ 133000
+ 10
+ 5
+ 5;
+ };
same for others as well..
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Acked-by: MyungJoo Ham Adding to Chanwoo's reply: If I understand Chanwoo's intention correctly, this patchset is to provide a common bus & memory-interface DVFS driver for several Exynos SoCs, which allows DT to express per-SoC hardware details so that we do not need to hardcode them with seperated drivers (as it is now) or a driver with a lot of unused definitions (partly as it is now). Having that many looking ugly frequency definitions is because Exynos SoCs that I've seen until today have many on-SoC IPs that should change configurations (usually clock speed) according to the clock speed of bus. Thus, they may look duplicated. We may hide such details IF we make one driver per SoC model; however, it is very inefficient with DT supported kernels if we can write such details in DTS and make the driver simple and unified. Cheers, MyungJoo. > > Hi Rob, > >First of all, thanks for your review. > >On 01/09/2015 06:18 AM, Rob Herring wrote: >> Adding Viresh. >> >> On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi wrote: >>> This patch adds the documentation for generic exynos memory bus frequency >>> driver. >>> >>> Cc: MyungJoo Ham >>> Cc: Kyungmin Park >>> Cc: Kukjin Kim >>> Signed-off-by: Chanwoo Choi >>> --- >>> .../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 >>> + >>> 1 file changed, 184 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt >>>
Re: Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Acked-by: MyungJoo Ham myungjoo@samsung.com Adding to Chanwoo's reply: If I understand Chanwoo's intention correctly, this patchset is to provide a common bus memory-interface DVFS driver for several Exynos SoCs, which allows DT to express per-SoC hardware details so that we do not need to hardcode them with seperated drivers (as it is now) or a driver with a lot of unused definitions (partly as it is now). Having that many looking ugly frequency definitions is because Exynos SoCs that I've seen until today have many on-SoC IPs that should change configurations (usually clock speed) according to the clock speed of bus. Thus, they may look duplicated. We may hide such details IF we make one driver per SoC model; however, it is very inefficient with DT supported kernels if we can write such details in DTS and make the driver simple and unified. Cheers, MyungJoo. Hi Rob, First of all, thanks for your review. On 01/09/2015 06:18 AM, Rob Herring wrote: Adding Viresh. On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds the documentation for generic exynos memory bus frequency driver. Cc: MyungJoo Ham myungjoo@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Kukjin Kim kg...@kernel.org Signed-off-by: Chanwoo Choi cw00.c...@samsung.com --- .../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 + 1 file changed, 184 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Hi Rob,
First of all, thanks for your review.
On 01/09/2015 06:18 AM, Rob Herring wrote:
> Adding Viresh.
>
> On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi wrote:
>> This patch adds the documentation for generic exynos memory bus frequency
>> driver.
>>
>> Cc: MyungJoo Ham
>> Cc: Kyungmin Park
>> Cc: Kukjin Kim
>> Signed-off-by: Chanwoo Choi
>> ---
>> .../devicetree/bindings/devfreq/exynos-busfreq.txt | 184
>> +
>> 1 file changed, 184 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
>> b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
>> new file mode 100644
>> index 000..c601e88
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
>> @@ -0,0 +1,184 @@
>> +
>> +* Generic Exynos Memory Bus device
>> +
>> +The Samsung Exynos SoCs have many memory buses for data transfer between
>> DRAM
>> +memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common
>> architecture
>> +for memory buses. Generally, Exynos SoC express the memory bus by using
>> memory
>> +bus group and block. The memory bus group has one more memory bus blocks and
>> +OPP table (including frequency and voltage for DVFS), regulator,
>> devfreq-event
>> +devices. Each memory bus block has a clock for own memory bus speen and
>> +frequency table for DVFS. There are a little different among Exynos SoCs
>> +because each Exynos SoC has the different sub-IP and differnt memory bus.
>> +So, this difference should be specified in devicetree file.
>> +
>> +Required properties for memory bus group:
>> +- compatible: Should be "samsung,exynos-memory-bus".
>> +- operating-points: the OPP table including frequency/voltage information to
>> + support DVFS (Dynamic Voltage/Frequency Scaling) feature.
>> +- devfreq-events: the devfreq-event device to monitor the curret state of
>> + memory bus group.
>
> I don't understand what goes in here.
CPUFREQ use the cpu utilization data to decide the current state of CPU
by CPUFREQ governor.
Exynos busfreq with DEVFREQ must need the data to monitor the current state
of memory bus of Exynos SoC. So, the devfreq-events provide the current state
of memory bus like as cpu utilization. Exynos busfreq could decide the state
of memory bus by using the devfreq-events.
The summary of devfreq-event device is as following:
(https://lkml.org/lkml/2015/1/7/795)
: This patch add new devfreq_event class for devfreq_event device which provide
raw data (e.g., memory bus utilization/GPU utilization). This raw data from
devfreq_event data would be used for the governor of devfreq subsystem.
- devfreq_event device : Provide raw data for governor of existing devfreq
device
- devfreq device : Monitor device state and change frequency/voltage of
device
using the raw data from devfreq_event device
>
>> +- vdd-mem-supply: the regulator to provide memory bus group with the
>> voltage.
>> +
>> +Required properties for memory bus block:
>> +- clock-names : the name of clock used by the memory bus, "memory-bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- #clock-cells: should be 1.
>> +- frequency: the frequency table to support DVFS feature.
>
> So you have just defined a new OPP table format. We already have one
> and Viresh is working to create a more extendable one. He asked about
> what's needed in devfreq, so Viresh here you go. :)
>
>> +
>> +Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
>> + Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
>> + group includes one memory bus block between DRAM and eMMC. Also, INT
>> + memory bus group includes eight memory bus blocks which support each
>> + sub-IPs between DRAM and sub-IPs.
>> +
>> + memory_bus_mif: memory_bus@0 {
>> + compatible = "samsung,exynos-memory-bus";
>> +
>> + operating-points = <
>> + 40 875000
>> + 20 80
>> + 133000 80
>> + 10 80
>> + 5 80>;
>> + status = "disabled";
>
> Why is this not part of the DDR controller or /memory node?
Because the memory bus node in this patch was dependent on only Exynos SoC.
I didn't check the memory bus of another SoC except for Exynos SoC.
>
>> + blocks {
>> + dmc_block: memory_bus_block1 {
>> + clocks = <_dmc CLK_DIV_DMC>;
>> + clock-names = "memory-bus";
>> + frequency = <
>> + 40
>> + 20
>> + 133000
>> +
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Adding Viresh.
On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi wrote:
> This patch adds the documentation for generic exynos memory bus frequency
> driver.
>
> Cc: MyungJoo Ham
> Cc: Kyungmin Park
> Cc: Kukjin Kim
> Signed-off-by: Chanwoo Choi
> ---
> .../devicetree/bindings/devfreq/exynos-busfreq.txt | 184
> +
> 1 file changed, 184 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
> b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
> new file mode 100644
> index 000..c601e88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
> @@ -0,0 +1,184 @@
> +
> +* Generic Exynos Memory Bus device
> +
> +The Samsung Exynos SoCs have many memory buses for data transfer between DRAM
> +memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common architecture
> +for memory buses. Generally, Exynos SoC express the memory bus by using
> memory
> +bus group and block. The memory bus group has one more memory bus blocks and
> +OPP table (including frequency and voltage for DVFS), regulator,
> devfreq-event
> +devices. Each memory bus block has a clock for own memory bus speen and
> +frequency table for DVFS. There are a little different among Exynos SoCs
> +because each Exynos SoC has the different sub-IP and differnt memory bus.
> +So, this difference should be specified in devicetree file.
> +
> +Required properties for memory bus group:
> +- compatible: Should be "samsung,exynos-memory-bus".
> +- operating-points: the OPP table including frequency/voltage information to
> + support DVFS (Dynamic Voltage/Frequency Scaling) feature.
> +- devfreq-events: the devfreq-event device to monitor the curret state of
> + memory bus group.
I don't understand what goes in here.
> +- vdd-mem-supply: the regulator to provide memory bus group with the voltage.
> +
> +Required properties for memory bus block:
> +- clock-names : the name of clock used by the memory bus, "memory-bus".
> +- clocks : phandles for clock specified in "clock-names" property.
> +- #clock-cells: should be 1.
> +- frequency: the frequency table to support DVFS feature.
So you have just defined a new OPP table format. We already have one
and Viresh is working to create a more extendable one. He asked about
what's needed in devfreq, so Viresh here you go. :)
> +
> +Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
> + Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
> + group includes one memory bus block between DRAM and eMMC. Also, INT
> + memory bus group includes eight memory bus blocks which support each
> + sub-IPs between DRAM and sub-IPs.
> +
> + memory_bus_mif: memory_bus@0 {
> + compatible = "samsung,exynos-memory-bus";
> +
> + operating-points = <
> + 40 875000
> + 20 80
> + 133000 80
> + 10 80
> + 5 80>;
> + status = "disabled";
Why is this not part of the DDR controller or /memory node?
> + blocks {
> + dmc_block: memory_bus_block1 {
> + clocks = <_dmc CLK_DIV_DMC>;
> + clock-names = "memory-bus";
> + frequency = <
> + 40
> + 20
> + 133000
> + 10
> + 5>;
This is just duplicated from the operating-points table.
> + };
> + };
> + };
> +
> + memory_bus_int: memory_bus@1 {
> + compatible = "samsung,exynos-memory-bus";
> +
> + operating-points = <
> + 40 95
> + 20 95
> + 133000 925000
> + 10 85
> + 8 85
> + 5 85>;
> +
> + status = "disabled";
> +
> + blocks {
> + peri_block: memory_bus_block1 {
Why is this and the following nodes not part of the respective
peripheral nodes or buses. If you need more hierarchy in your bus add
that to DT first. I'm sure just a flat "simple-bus" was done which
doesn't reflect the actual bus and now you need it to.
> + clocks = < CLK_DIV_ACLK_100>;
> + clock-names = "memory-bus";
> + frequency = <
> + 10
> + 10
> +
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Hi Rob,
First of all, thanks for your review.
On 01/09/2015 06:18 AM, Rob Herring wrote:
Adding Viresh.
On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch adds the documentation for generic exynos memory bus frequency
driver.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../devicetree/bindings/devfreq/exynos-busfreq.txt | 184
+
1 file changed, 184 insertions(+)
create mode 100644
Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
new file mode 100644
index 000..c601e88
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
@@ -0,0 +1,184 @@
+
+* Generic Exynos Memory Bus device
+
+The Samsung Exynos SoCs have many memory buses for data transfer between
DRAM
+memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common
architecture
+for memory buses. Generally, Exynos SoC express the memory bus by using
memory
+bus group and block. The memory bus group has one more memory bus blocks and
+OPP table (including frequency and voltage for DVFS), regulator,
devfreq-event
+devices. Each memory bus block has a clock for own memory bus speen and
+frequency table for DVFS. There are a little different among Exynos SoCs
+because each Exynos SoC has the different sub-IP and differnt memory bus.
+So, this difference should be specified in devicetree file.
+
+Required properties for memory bus group:
+- compatible: Should be samsung,exynos-memory-bus.
+- operating-points: the OPP table including frequency/voltage information to
+ support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- devfreq-events: the devfreq-event device to monitor the curret state of
+ memory bus group.
I don't understand what goes in here.
CPUFREQ use the cpu utilization data to decide the current state of CPU
by CPUFREQ governor.
Exynos busfreq with DEVFREQ must need the data to monitor the current state
of memory bus of Exynos SoC. So, the devfreq-events provide the current state
of memory bus like as cpu utilization. Exynos busfreq could decide the state
of memory bus by using the devfreq-events.
The summary of devfreq-event device is as following:
(https://lkml.org/lkml/2015/1/7/795)
: This patch add new devfreq_event class for devfreq_event device which provide
raw data (e.g., memory bus utilization/GPU utilization). This raw data from
devfreq_event data would be used for the governor of devfreq subsystem.
- devfreq_event device : Provide raw data for governor of existing devfreq
device
- devfreq device : Monitor device state and change frequency/voltage of
device
using the raw data from devfreq_event device
+- vdd-mem-supply: the regulator to provide memory bus group with the
voltage.
+
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, memory-bus.
+- clocks : phandles for clock specified in clock-names property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
So you have just defined a new OPP table format. We already have one
and Viresh is working to create a more extendable one. He asked about
what's needed in devfreq, so Viresh here you go. :)
+
+Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
+ Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
+ group includes one memory bus block between DRAM and eMMC. Also, INT
+ memory bus group includes eight memory bus blocks which support each
+ sub-IPs between DRAM and sub-IPs.
+
+ memory_bus_mif: memory_bus@0 {
+ compatible = samsung,exynos-memory-bus;
+
+ operating-points =
+ 40 875000
+ 20 80
+ 133000 80
+ 10 80
+ 5 80;
+ status = disabled;
Why is this not part of the DDR controller or /memory node?
Because the memory bus node in this patch was dependent on only Exynos SoC.
I didn't check the memory bus of another SoC except for Exynos SoC.
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = cmu_dmc CLK_DIV_DMC;
+ clock-names = memory-bus;
+ frequency =
+ 40
+ 20
+ 133000
+ 10
+
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Adding Viresh.
On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch adds the documentation for generic exynos memory bus frequency
driver.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../devicetree/bindings/devfreq/exynos-busfreq.txt | 184
+
1 file changed, 184 insertions(+)
create mode 100644
Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
new file mode 100644
index 000..c601e88
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
@@ -0,0 +1,184 @@
+
+* Generic Exynos Memory Bus device
+
+The Samsung Exynos SoCs have many memory buses for data transfer between DRAM
+memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common architecture
+for memory buses. Generally, Exynos SoC express the memory bus by using
memory
+bus group and block. The memory bus group has one more memory bus blocks and
+OPP table (including frequency and voltage for DVFS), regulator,
devfreq-event
+devices. Each memory bus block has a clock for own memory bus speen and
+frequency table for DVFS. There are a little different among Exynos SoCs
+because each Exynos SoC has the different sub-IP and differnt memory bus.
+So, this difference should be specified in devicetree file.
+
+Required properties for memory bus group:
+- compatible: Should be samsung,exynos-memory-bus.
+- operating-points: the OPP table including frequency/voltage information to
+ support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- devfreq-events: the devfreq-event device to monitor the curret state of
+ memory bus group.
I don't understand what goes in here.
+- vdd-mem-supply: the regulator to provide memory bus group with the voltage.
+
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, memory-bus.
+- clocks : phandles for clock specified in clock-names property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
So you have just defined a new OPP table format. We already have one
and Viresh is working to create a more extendable one. He asked about
what's needed in devfreq, so Viresh here you go. :)
+
+Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
+ Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
+ group includes one memory bus block between DRAM and eMMC. Also, INT
+ memory bus group includes eight memory bus blocks which support each
+ sub-IPs between DRAM and sub-IPs.
+
+ memory_bus_mif: memory_bus@0 {
+ compatible = samsung,exynos-memory-bus;
+
+ operating-points =
+ 40 875000
+ 20 80
+ 133000 80
+ 10 80
+ 5 80;
+ status = disabled;
Why is this not part of the DDR controller or /memory node?
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = cmu_dmc CLK_DIV_DMC;
+ clock-names = memory-bus;
+ frequency =
+ 40
+ 20
+ 133000
+ 10
+ 5;
This is just duplicated from the operating-points table.
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = samsung,exynos-memory-bus;
+
+ operating-points =
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85;
+
+ status = disabled;
+
+ blocks {
+ peri_block: memory_bus_block1 {
Why is this and the following nodes not part of the respective
peripheral nodes or buses. If you need more hierarchy in your bus add
that to DT first. I'm sure just a flat simple-bus was done which
doesn't reflect the actual bus and now you need it to.
+ clocks = cmu CLK_DIV_ACLK_100;
+ clock-names = memory-bus;
+ frequency =
+ 10
+ 10
+
[PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
This patch adds the documentation for generic exynos memory bus frequency
driver.
Cc: MyungJoo Ham
Cc: Kyungmin Park
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
---
.../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 +
1 file changed, 184 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
new file mode 100644
index 000..c601e88
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
@@ -0,0 +1,184 @@
+
+* Generic Exynos Memory Bus device
+
+The Samsung Exynos SoCs have many memory buses for data transfer between DRAM
+memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common architecture
+for memory buses. Generally, Exynos SoC express the memory bus by using memory
+bus group and block. The memory bus group has one more memory bus blocks and
+OPP table (including frequency and voltage for DVFS), regulator, devfreq-event
+devices. Each memory bus block has a clock for own memory bus speen and
+frequency table for DVFS. There are a little different among Exynos SoCs
+because each Exynos SoC has the different sub-IP and differnt memory bus.
+So, this difference should be specified in devicetree file.
+
+Required properties for memory bus group:
+- compatible: Should be "samsung,exynos-memory-bus".
+- operating-points: the OPP table including frequency/voltage information to
+ support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- devfreq-events: the devfreq-event device to monitor the curret state of
+ memory bus group.
+- vdd-mem-supply: the regulator to provide memory bus group with the voltage.
+
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, "memory-bus".
+- clocks : phandles for clock specified in "clock-names" property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
+
+Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
+ Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
+ group includes one memory bus block between DRAM and eMMC. Also, INT
+ memory bus group includes eight memory bus blocks which support each
+ sub-IPs between DRAM and sub-IPs.
+
+ memory_bus_mif: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 875000
+ 20 80
+ 133000 80
+ 10 80
+ 5 80>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = <_dmc CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 133000
+ 10
+ 5>;
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85>;
+
+ status = "disabled";
+
+ blocks {
+ peri_block: memory_bus_block1 {
+ clocks = < CLK_DIV_ACLK_100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10
+ 10
+ 5
+ 5>;
+ };
+
+ display_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACLK_160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10
+ 8
+ 8
+ 5>;
+ };
+
+ isp_block: memory_bus_block3 {
+ clocks = < CLK_DIV_ACLK_200>;
+
[PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
This patch adds the documentation for generic exynos memory bus frequency
driver.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 +
1 file changed, 184 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
new file mode 100644
index 000..c601e88
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
@@ -0,0 +1,184 @@
+
+* Generic Exynos Memory Bus device
+
+The Samsung Exynos SoCs have many memory buses for data transfer between DRAM
+memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common architecture
+for memory buses. Generally, Exynos SoC express the memory bus by using memory
+bus group and block. The memory bus group has one more memory bus blocks and
+OPP table (including frequency and voltage for DVFS), regulator, devfreq-event
+devices. Each memory bus block has a clock for own memory bus speen and
+frequency table for DVFS. There are a little different among Exynos SoCs
+because each Exynos SoC has the different sub-IP and differnt memory bus.
+So, this difference should be specified in devicetree file.
+
+Required properties for memory bus group:
+- compatible: Should be samsung,exynos-memory-bus.
+- operating-points: the OPP table including frequency/voltage information to
+ support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- devfreq-events: the devfreq-event device to monitor the curret state of
+ memory bus group.
+- vdd-mem-supply: the regulator to provide memory bus group with the voltage.
+
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, memory-bus.
+- clocks : phandles for clock specified in clock-names property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
+
+Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
+ Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
+ group includes one memory bus block between DRAM and eMMC. Also, INT
+ memory bus group includes eight memory bus blocks which support each
+ sub-IPs between DRAM and sub-IPs.
+
+ memory_bus_mif: memory_bus@0 {
+ compatible = samsung,exynos-memory-bus;
+
+ operating-points =
+ 40 875000
+ 20 80
+ 133000 80
+ 10 80
+ 5 80;
+ status = disabled;
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = cmu_dmc CLK_DIV_DMC;
+ clock-names = memory-bus;
+ frequency =
+ 40
+ 20
+ 133000
+ 10
+ 5;
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = samsung,exynos-memory-bus;
+
+ operating-points =
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85;
+
+ status = disabled;
+
+ blocks {
+ peri_block: memory_bus_block1 {
+ clocks = cmu CLK_DIV_ACLK_100;
+ clock-names = memory-bus;
+ frequency =
+ 10
+ 10
+ 10
+ 10
+ 5
+ 5;
+ };
+
+ display_block: memory_bus_block2 {
+ clocks = cmu CLK_DIV_ACLK_160;
+ clock-names = memory-bus;
+ frequency =
+ 20
+ 16
+ 10
+ 8
+ 8
+ 5;
+ };
+
+ isp_block: memory_bus_block3 {
+
