sunxi: a20-LIME2 update regulator description
Subsystems (2)
PATCH 1/2 sunxi: a20-LIME2 update regulator description
configure regulators as per the manufacturers recomendations from their 3.4.x fex file.
this is necessary to prevent operating points in the dtsi selecting inappropriate values and causing the board to lockup
--- arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 34 +++++++++++++++++-------- 1 file changed, 24 insertions(+), 10 deletions(-)
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +24 -10
@@ -123,41 +123,55 @@ ldo24in-supply = <®_axp_ipsout>; ldo3in-supply = <®_axp_ipsout>; + x-powers,dcdc-freq = <1500>; + regulators { vdd_rtc: ldo1 { regulator-min-microvolt = <1300000>; regulator-max-microvolt = <1300000>; regulator-always-on; + regulator-name="vdd_rtc"; }; avcc: ldo2 { - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; regulator-always-on; + regulator-name="avcc"; }; vcc_csi0: ldo3 { - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <3500000>; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; regulator-always-on; + regulator-name="vcc_csi0"; }; vcc_csi1: ldo4 { - regulator-min-microvolt = <1250000>; - regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; regulator-always-on; + regulator-name="vcc_csi1"; + }; + + ldo5 { + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-name="reg_unused"; }; vdd_cpu: dcdc2 { - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <2275000>; + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1450000>; regulator-always-on; + regulator-name="vdd_cpu"; }; vdd_int: dcdc3 { - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <3500000>; + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1300000>; regulator-always-on; + regulator-name="vdd_int"; }; }; };
Signature · 1 line
2.1.3
PATCH 2/2 sunxi: a20-LIME2 define board specific operating points
these settings override the inappropriate ones in the dtsi with the manufacturers provided settings from their 3.4.x fex file for this board
--- arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +19 -0
@@ -83,6 +83,25 @@ status = "okay"; }; +&cpu0 { + cpu-supply = <&vdd_cpu>; + clocks = <&cpu>; + clock-latency = <244144>; /* 8 32k periods */ + operating-points = < + /* kHz uV */ + 1008000 1450000 + 912000 1425000 + 864000 1350000 + 720000 1250000 + 528000 1150000 + 312000 1100000 + 144000 1050000 + >; + #cooling-cells = <2>; + cooling-min-level = <0>; + cooling-max-level = <6>; +}; + &ehci0 { status = "okay"; };
Signature · 1 line
2.1.3
PATCH 2/2 sunxi: a20-LIME2 define board specific operating points
Quoted 2 lines · Iain Paton
these settings override the inappropriate ones in the dtsi with the manufacturers provided settings from their 3.4.x fex file for this board
Inappropriate how?
Quoted 11 lines
Signed-off-by Iain Paton <[email protected]>--- arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +0
-0
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts line 89
Quoted 7 lines
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +4
-0@@ -83,6 +83,25 @@ status = "okay"; }; +&cpu0 { + cpu-supply = <&vdd_cpu>; + clocks = <&cpu>; + clock-latency = <244144>; /* 8 32k periods */
This is already defined in the DTSI
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts line 99
Quoted 10 lines
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +10
-0+ operating-points = < + /* kHz uV */ + 1008000 1450000 + 912000 1425000 + 864000 1350000 + 720000 1250000 + 528000 1150000 + 312000 1100000 + 144000 1050000 + >;
I'd rather have a better common operating points set and change that to accomodate all boards, rather than duplicating that information everywhere.
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts line 100
Quoted 1 line
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +1
-0+ #cooling-cells = <2>;
This is also defined in the DTSI.
Quoted 10 lines
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +4
-0+ cooling-min-level = <0>; + cooling-max-level = <6>; +}; + &ehci0 { status = "okay"; };Signature · 1 line
2.1.3
Thanks,
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150330/a0160020/attachment.sig>
PATCH 2/2 sunxi: a20-LIME2 define board specific operating points
Quoted 5 lines · Maxime Ripard
Quoted 2 lines · Iain Paton
these settings override the inappropriate ones in the dtsi with the manufacturers provided settings from their 3.4.x fex file for this board
Inappropriate how?
inappropriate in that the dtsi sets values that cause the board to lockup or to be unstable
Quoted 3 lines
I'd rather have a better common operating points set and change that to accomodate all boards, rather than duplicating that information everywhere.
then anything that you have common needs to cope with the worst cases for *all* boards, to the detriment of anything that's capable of doing better. i.e. the smallest most conservative subset.
Whether we like it or not, stuff like this is simply going to end up being board specific. You can't easily deal with cases like a particular PCB design requiring an extra 0.05v due to a too-thin trace somewhere without having board-specific knowledge.
So rather than us, as software people, trying to second guess the board designers, I believe we should simply use the settings they provide if we have them in the fex files. Likely the manufacturer has tested those settings on a much larger number of boards than we'll ever be able to do.
The default settings for a board need to be reliable for everyone.
Quoted 3 lines
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts line 100
Quoted 1 line
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +1
-0+ #cooling-cells = <2>;This is also defined in the DTSI.
Yes, exactly. The point being to completely isolate the board from changes to this section of the dtsi.
To further illustrate, let's take a look at the sun7i opp table in your sunxi/for-next tree
/* kHz uV */
960000 1400000 912000 1400000 864000 1300000 720000 1200000 528000 1100000 312000 1000000 144000 900000
Comparing to the 38 A20 fex files in https://github.com/linux-sunxi/sunxi-boards
as of today
boot_freq: 912=37, 1008=1max_freq: 1200=1, 1008=10, 912=27min_freq: 720MHz=7, 408MHz=3, 60MHz=28
The dvfs section doesn't define 960MHz in any of the 38 files, so that entry is pure conjecture and likely not properly tested by any of the manufacturers.
On the voltage front:
912MHz: 1425=7, 1400=27, 1350=4
864MHz: 1350=7, 1300=27, 1250=4
720MHz: 1300=1, 1250=7, 1200=30
528MHz: 1150=8, 1100=30
312MHz: 1100=8, 1050=27, 1000=3
144MHz is only defined for 12 out of 38 boards
144MHz: 1050=9, 1000=3
There are additional settings at 792MHz and 624MHz in the fex files, both defined by 26 out of 38 boards.
1008MHz @ 1450 is defined by all 38.
To come to a generic subset, we need to exclude things as follows
1. anything greater than the lowest max_freq
2. anything less than the highest min_freq
3. anything less than the highest required voltage at a given frequency
That leaves us with this:
/* kHz uV */
912000 1425000 864000 1350000 720000 1300000
Even then, we can't guarantee those three will be safe or reliable for everything. The A20 datasheet gives 1.4v as the absolute maximum which means we need to remove the 912MHz completely as some devices require overvolting to reach it and that may be unsafe for the rest.
So a generic dtsi subset is limited to
/* kHz uV */
864000 1350000
720000 1300000
as that's the subset that covers all devices we have data on and doesn't involve overclocking, overvolting, undervolting, operating outside AllWinner SoC ratings, outside device manufacturer specified settings, and doesn't require any board specific knowledge.
So in the case of a generic, not board-specific, dtsi file most of what's currently in the dtsi is inappropriate for a large proportion of devices. The commonality is tiny, without board specific knowledge we can't do any better.
While we can be relatively confident the remaining two settings will work on almost all boards, confidence in the other settings is at best uncertain. I certainly have little interest in 7.9% at 312MHz, or 0% at 144MHz possibility of success.
While the faster speeds aren't quite so bad, you're still suggesting that 18-21% of boards having problems is ok.
Sorry, thats simply not acceptable.
I hope this explains my point of view and why I believe this data to be board specific stuff that belongs in the boards dts file and not in the dtsi.
Rgds,
Iain
PATCH 2/2 sunxi: a20-LIME2 define board specific operating points
Quoted 9 lines · Iain Paton
Quoted 5 lines · Maxime Ripard
Quoted 2 lines · Iain Paton
these settings override the inappropriate ones in the dtsi with the manufacturers provided settings from their 3.4.x fex file for this board
Inappropriate how?
inappropriate in that the dtsi sets values that cause the board to lockup or to be unstable
And it's the whole point of it. If the DTSI sets inappropriate values that locks up your system, then it's because the board uses this regulator. If the board uses it, appropriate values must be defined in the board DTS.
Quoted 13 lines
Quoted 3 lines
I'd rather have a better common operating points set and change that to accomodate all boards, rather than duplicating that information everywhere.
then anything that you have common needs to cope with the worst cases for *all* boards, to the detriment of anything that's capable of doing better. i.e. the smallest most conservative subset.
Whether we like it or not, stuff like this is simply going to end up being board specific. You can't easily deal with cases like a particular PCB design requiring an extra 0.05v due to a too-thin trace somewhere without having board-specific knowledge.
Quoted 4 lines
So rather than us, as software people, trying to second guess the board designers, I believe we should simply use the settings they provide if we have them in the fex files. Likely the manufacturer has tested those settings on a much larger number of boards than we'll ever be able to do.
Except that everything happening with cpufreq is internal to the SoC. So unless you can back up the fact that different revisions of the SoC *need* different OPPs, then no, we're going to have the same for each and every board.
Quoted 1 line
The default settings for a board need to be reliable for everyone.
Exactly. And the FEX files have been shown wrong already on that.
Quoted 19 lines
Quoted 3 lines
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts line 100
Quoted 1 line
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +1
-0+ #cooling-cells = <2>;This is also defined in the DTSI.
Yes, exactly. The point being to completely isolate the board from changes to this section of the dtsi.
To further illustrate, let's take a look at the sun7i opp table in your sunxi/for-next tree
/* kHz uV */
960000 1400000 912000 1400000 864000 1300000 720000 1200000 528000 1100000 312000 1000000 144000 900000
Quoted 6 lines
Comparing to the 38 A20 fex files in https://github.com/linux-sunxi/sunxi-boards
as of today
boot_freq: 912=37, 1008=1max_freq: 1200=1, 1008=10, 912=27min_freq: 720MHz=7, 408MHz=3, 60MHz=28
Again, the FEX files have been proven wrong several times on this already, so using them as argument is not really meaningful in any way.
Quoted 2 lines
The dvfs section doesn't define 960MHz in any of the 38 files, so that entry is pure conjecture and likely not properly tested by any of the manufacturers.
That's true. Feel free to edit the DTSI.
Quoted 7 lines
On the voltage front:
912MHz: 1425=7, 1400=27, 1350=4
864MHz: 1350=7, 1300=27, 1250=4
720MHz: 1300=1, 1250=7, 1200=30
528MHz: 1150=8, 1100=30
312MHz: 1100=8, 1050=27, 1000=3
Quoted 7 lines
144MHz is only defined for 12 out of 38 boards
144MHz: 1050=9, 1000=3There are additional settings at 792MHz and 624MHz in the fex files, both defined by 26 out of 38 boards.
1008MHz @ 1450 is defined by all 38.
And has been proven not reliable on some. Do you want to come back on that "properly tested by any of the manufacturers" argument?
Quoted 33 lines
To come to a generic subset, we need to exclude things as follows
1. anything greater than the lowestmax_freq
2. anything less than the highestmin_freq
3. anything less than the highest required voltage at a given frequencyThat leaves us with this:
/* kHz uV */
912000 1425000 864000 1350000 720000 1300000Even then, we can't guarantee those three will be safe or reliable for everything. The A20 datasheet gives 1.4v as the absolute maximum which means we need to remove the 912MHz completely as some devices require overvolting to reach it and that may be unsafe for the rest.
So a generic dtsi subset is limited to
/* kHz uV */
864000 1350000
720000 1300000as that's the subset that covers all devices we have data on and doesn't involve overclocking, overvolting, undervolting, operating outside AllWinner SoC ratings, outside device manufacturer specified settings, and doesn't require any board specific knowledge.
So in the case of a generic, not board-specific, dtsi file most of what's currently in the dtsi is inappropriate for a large proportion of devices. The commonality is tiny, without board specific knowledge we can't do any better.
Quoted 7 lines
While we can be relatively confident the remaining two settings will work on almost all boards, confidence in the other settings is at best uncertain. I certainly have little interest in 7.9% at 312MHz, or 0% at 144MHz possibility of success.
While the faster speeds aren't quite so bad, you're still suggesting that 18-21% of boards having problems is ok.
Sorry, thats simply not acceptable.
Indeed, and that's not what I'm suggesting at all. What I do suggest is to figure out a set of OPPs that are known to be working for everyone.
Do you really feel like sunxi is so special and soooo different from any other ARM SoC, running on virtually any ARM board on earth but sunxi, properly tested (by properly, I do mean properly.), shipped into products, and actually using a common set of OPPs?
Quoted 2 lines
I hope this explains my point of view and why I believe this data to be board specific stuff that belongs in the boards dts file and not in the dtsi.
I guess we do have a very different point of view. Yours is "just trust whatever the fex file tells us", mine is "fex file is going to be wrong/incomplete, let's figure out our own".
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150404/2eedc9fb/attachment.sig>
PATCH 2/2 sunxi: a20-LIME2 define board specific operating points
Quoted 69 lines · Maxime Ripard
Quoted 9 lines · Iain Paton
Quoted 5 lines · Maxime Ripard
Quoted 2 lines · Iain Paton
these settings override the inappropriate ones in the dtsi with the manufacturers provided settings from their 3.4.x fex file for this board
Inappropriate how?
inappropriate in that the dtsi sets values that cause the board to lockup or to be unstable
And it's the whole point of it. If the DTSI sets inappropriate values that locks up your system, then it's because the board uses this regulator. If the board uses it, appropriate values must be defined in the board DTS.
Quoted 13 lines
Quoted 3 lines
I'd rather have a better common operating points set and change that to accomodate all boards, rather than duplicating that information everywhere.
then anything that you have common needs to cope with the worst cases for *all* boards, to the detriment of anything that's capable of doing better. i.e. the smallest most conservative subset.
Whether we like it or not, stuff like this is simply going to end up being board specific. You can't easily deal with cases like a particular PCB design requiring an extra 0.05v due to a too-thin trace somewhere without having board-specific knowledge.
Quoted 4 lines
So rather than us, as software people, trying to second guess the board designers, I believe we should simply use the settings they provide if we have them in the fex files. Likely the manufacturer has tested those settings on a much larger number of boards than we'll ever be able to do.
Except that everything happening with cpufreq is internal to the SoC. So unless you can back up the fact that different revisions of the SoC *need* different OPPs, then no, we're going to have the same for each and every board.
Quoted 1 line
The default settings for a board need to be reliable for everyone.
Exactly. And the FEX files have been shown wrong already on that.
Quoted 19 lines
Quoted 3 lines
Quoted 1 line
+ #cooling-cells = <2>;
This is also defined in the DTSI.
Yes, exactly. The point being to completely isolate the board from changes to this section of the dtsi.
To further illustrate, let's take a look at the sun7i opp table in your sunxi/for-next tree
/* kHz uV */
960000 1400000 912000 1400000 864000 1300000 720000 1200000 528000 1100000 312000 1000000 144000 900000Quoted 6 lines
Comparing to the 38 A20 fex files in https://github.com/linux-sunxi/sunxi-boards
as of today
boot_freq: 912=37, 1008=1max_freq: 1200=1, 1008=10, 912=27min_freq: 720MHz=7, 408MHz=3, 60MHz=28
Quoted 8 lines
Again, the FEX files have been proven wrong several times on this already, so using them as argument is not really meaningful in any way.
Quoted 2 lines
The dvfs section doesn't define 960MHz in any of the 38 files, so that entry is pure conjecture and likely not properly tested by any of the manufacturers.
That's true. Feel free to edit the DTSI.
Some clarification:
960 MHz / 1.4V was added by me, as that was the value set up by U-boot mainline. If someone complains it is not stable, then either we drop it, or someone overrides the OPPs for that specific board.
Now the fex file dvfs section defines brackets, not points. For example it says up to 912MHz it can use 1.4V, up to 864MHz it can use 1.3V, and so on.
With v2 OPP bindings, we should be able to specify brackets and "boost" frequencies.
Quoted 10 lines
Quoted 10 lines
On the voltage front:
912MHz: 1425=7, 1400=27, 1350=4
864MHz: 1350=7, 1300=27, 1250=4
720MHz: 1300=1, 1250=7, 1200=30
528MHz: 1150=8, 1100=30
312MHz: 1100=8, 1050=27, 1000=3144MHz is only defined for 12 out of 38 boards
144MHz: 1050=9, 1000=3
Quoted 7 lines
Quoted 4 lines
There are additional settings at 792MHz and 624MHz in the fex files, both defined by 26 out of 38 boards.
1008MHz @ 1450 is defined by all 38.
And has been proven not reliable on some. Do you want to come back on that "properly tested by any of the manufacturers" argument?
This one was removed specifically because without regulator support to boost the voltage, it would not be stable. Boards with regulators added to the board dts can also add this OPP.
ChenYu
Quoted 69 lines
Quoted 33 lines
To come to a generic subset, we need to exclude things as follows
1. anything greater than the lowestmax_freq
2. anything less than the highestmin_freq
3. anything less than the highest required voltage at a given frequencyThat leaves us with this:
/* kHz uV */
912000 1425000 864000 1350000 720000 1300000Even then, we can't guarantee those three will be safe or reliable for everything. The A20 datasheet gives 1.4v as the absolute maximum which means we need to remove the 912MHz completely as some devices require overvolting to reach it and that may be unsafe for the rest.
So a generic dtsi subset is limited to
/* kHz uV */
864000 1350000
720000 1300000as that's the subset that covers all devices we have data on and doesn't involve overclocking, overvolting, undervolting, operating outside AllWinner SoC ratings, outside device manufacturer specified settings, and doesn't require any board specific knowledge.
So in the case of a generic, not board-specific, dtsi file most of what's currently in the dtsi is inappropriate for a large proportion of devices. The commonality is tiny, without board specific knowledge we can't do any better.
Quoted 7 lines
While we can be relatively confident the remaining two settings will work on almost all boards, confidence in the other settings is at best uncertain. I certainly have little interest in 7.9% at 312MHz, or 0% at 144MHz possibility of success.
While the faster speeds aren't quite so bad, you're still suggesting that 18-21% of boards having problems is ok.
Sorry, thats simply not acceptable.Indeed, and that's not what I'm suggesting at all. What I do suggest is to figure out a set of OPPs that are known to be working for everyone.
Do you really feel like sunxi is so special and soooo different from any other ARM SoC, running on virtually any ARM board on earth but sunxi, properly tested (by properly, I do mean properly.), shipped into products, and actually using a common set of OPPs?
Quoted 2 lines
I hope this explains my point of view and why I believe this data to be board specific stuff that belongs in the boards dts file and not in the dtsi.
I guess we do have a very different point of view. Yours is "just trust whatever the fex file tells us", mine is "fex file is going to be wrong/incomplete, let's figure out our own".
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/2 sunxi: a20-LIME2 update regulator description
In reply to Iain PatonHi,
Quoted 68 lines · Iain Paton
configure regulators as per the manufacturers recomendations from their 3.4.x fex file.
this is necessary to prevent operating points in the dtsi selecting inappropriate values and causing the board to lockup
Signed-off-by Iain Paton <[email protected]>--- arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 34 +++++++++++++++++-------- 1 file changed, 24 insertions(+), 10 deletions(-)arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +20
-8@@ -123,41 +123,55 @@ ldo24in-supply = <®_axp_ipsout>; ldo3in-supply = <®_axp_ipsout>; + x-powers,dcdc-freq = <1500>; + regulators { vdd_rtc: ldo1 { regulator-min-microvolt = <1300000>; regulator-max-microvolt = <1300000>; regulator-always-on; + regulator-name="vdd_rtc"; }; avcc: ldo2 { - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; regulator-always-on; + regulator-name="avcc"; }; vcc_csi0: ldo3 { - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <3500000>; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; regulator-always-on; + regulator-name="vcc_csi0"; }; vcc_csi1: ldo4 { - regulator-min-microvolt = <1250000>; - regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; regulator-always-on; + regulator-name="vcc_csi1"; + }; + + ldo5 { + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-name="reg_unused"; }; vdd_cpu: dcdc2 { - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <2275000>; + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1450000>; regulator-always-on;
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts line 174
Quoted 10 lines
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +4
-2+ regulator-name="vdd_cpu"; }; vdd_int: dcdc3 { - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <3500000>; + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1300000>; regulator-always-on; + regulator-name="vdd_int";
Could you use the axp DTSI please?
That will remove most of the chunk defined in there.
Thanks!
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150330/55a47e9b/attachment.sig>
PATCH 1/2 sunxi: a20-LIME2 update regulator description
Quoted 6 lines · Maxime Ripard
Hi,
Quoted 3 lines · Iain Paton
configure regulators as per the manufacturers recomendations from their 3.4.x fex file.
Quoted 6 lines
Quoted 2 lines
this is necessary to prevent operating points in the dtsi selecting inappropriate values and causing the board to lockup
Could you use the axp DTSI please?
That will remove most of the chunk defined in there.
No. See my other reply. The regulators are even more board specific than the opp data and the interaction between the two is hard to handle at the best of times.
Using the axp dtsi means that the board dts really has to override every single possible item that could ever be added to the dtsi just to ensure stability. This won't remove anything, it'll just add extra unnecessary stuff to the mix as well as the additional burden on people taking care of a board watching the axp dtsi to catch any additions there casuing further problems.
Wishing these things were suitable for a common dtsi unfortunately doesn't change the reality whatsoever.
I'm with you that exploiting commonality is generally a good thing. It's just not appropriate here.
It also seems that most other boards have realised that the pmic setup is board specific and keep it in the appropriate place in the dts. The only other obvious example I can find apart from sunxi is TI, everyone else is doing the opposite.
So why the resistance? A repeat of the label based syntax / alphabetical ordering thing?
Rgds,
Iain
PATCH 1/2 sunxi: a20-LIME2 update regulator description
Quoted 14 lines · Iain Paton
Quoted 6 lines · Maxime Ripard
Hi,
Quoted 3 lines · Iain Paton
configure regulators as per the manufacturers recomendations from their 3.4.x fex file.
Quoted 6 lines
Quoted 2 lines
this is necessary to prevent operating points in the dtsi selecting inappropriate values and causing the board to lockup
Could you use the axp DTSI please?
That will remove most of the chunk defined in there.
Quoted 7 lines
No. See my other reply. The regulators are even more board specific than the opp data and the interaction between the two is hard to handle at the best of times.
Using the axp dtsi means that the board dts really has to override every single possible item that could ever be added to the dtsi just to ensure stability.
Every single possible item it actually uses. Which should be defined anyway in the board DTS anyway.
The *only* difference being that you won't have to define all the regulators in your board DTS to have the *unused* ones disabled.
Quoted 4 lines
This won't remove anything, it'll just add extra unnecessary stuff to the mix as well as the additional burden on people taking care of a board watching the axp dtsi to catch any additions there casuing further problems.
Again, it actually removes the fact that you have to declare all the regulators in all the boards DTS, even if there not used at all on the board. So the fact is it removes that churn
Quoted 2 lines
Wishing these things were suitable for a common dtsi unfortunately doesn't change the reality whatsoever.
The reality being in this case that you defined an incomplete set of regulators? Fair enough.
Quoted 9 lines
I'm with you that exploiting commonality is generally a good thing. It's just not appropriate here.
It also seems that most other boards have realised that the pmic setup is board specific and keep it in the appropriate place in the dts.
The only other obvious example I can find apart from sunxi is TI, everyone else is doing the opposite.
Which means what exactly? Apart from being the only two users, I mean?
Quoted 1 line
So why the resistance?
You won't have to maintain these changes, I will. More uselessly duplicated code means more useless effort, and I'm not really fond of wasting my time.
Quoted 1 line
A repeat of the label based syntax / alphabetical ordering thing?
How is that even related?
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150409/b368f930/attachment.sig>