I hope I've brought something useful here.
I figured out how to load mDNIe color profiles from sdcard.
So this I found out so far:
1. you have to be rooted;
2. profiles MUST be placed in /sdcard/mdnie folder;
3. profile is a text file and can be edited with any text editor;
4. file name is irrelevant ;
5. you have to edit two titles inside profile file to correspond to profile, you're going to override, eg. you're using AMOLED cinema mode. It's internal name is DYNAMIC_UI, so titles inside profile should be DYNAMIC_UI_1 for longer array and DYNAMIC_UI_2 for shorter one.
The whole list of model with corresponding internal names:
AMOLED cinema mode - DYNAMIC_UI;
AMOLED photo - STANDARD_UI;
Basic - NATURAL_UI;
6. first lines (bytes) of arrays are special marks (0xEC and 0xEB) and should not be touched;
7. to enable profile you have to write into /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning:
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning
8. PROFILE WILL RESET AFTER SCREEN OFF/ON CYCLE. For now I'm using Tasker to refresh it on screen on event. Maybe later we'll figure out some more elegant way;
UPDATE:
Written a small app for PC to tune colors through ADB. Useful for displaying some fullscreen test picture on device and drag sliders on PC to see effect (if any).
Profile structure description is in 2nd post.
That's it by now. There are comments from kernel source, but not too much descriptive (attached here).
I'd extracted and formated properly some major profiles. Attaching them here. Now we need to play allot with them to find out what each byte is doing exactly.
All profiles attached here have matching line numbers. I suggest to keep this pattern, so it will allow us to refer particular byte by line number while discussing here.
Profile bytes with description:
Description will be updated as figured out.
Code:
1 : BYPASS_2
2 : {
3 : 0xEB,
4 : 0x01, /* mdnie_en */
5 : 0x00, /* data_width mask 00 0000 */
6 : 0x00, /* ascr_roi 1 ascr 00 1 0 */ (only odd values 1-155, affects lines 132-155)
7 : 0x02, /* algo_roi 1 algo lce_roi 1 lce 00 1 0 00 1 0 */
8 : 0x00, /* roi_ctrl 00 */
9 : 0x00, /* roi0_x_start 12 */
10 : 0x00,
11 : 0x00, /* roi0_x_end */
12 : 0x00,
13 : 0x00, /* roi0_y_start */
14 : 0x00,
15 : 0x00, /* roi0_y_end */
16 : 0x00,
17 : 0x00, /* roi1_x_strat */
18 : 0x00,
19 : 0x00, /* roi1_x_end */
20 : 0x00,
21 : 0x00, /* roi1_y_start */
22 : 0x00,
23 : 0x00, /* roi1_y_end */
24 : 0x00,
25 : };
26 : BYPASS_1
27 : {
28 : 0xEC,
29 : 0x18, /* lce_on 0 lce_gain 0 0 00 0000 */
30 : 0x24, /* lce_color_gain 00 0000 */
31 : 0x10, /* lce_scene_change_on scene_trans 0 0000 */
32 : 0x14, /* lce_min_diff */
33 : 0xb3, /* lce_illum_gain */
34 : 0x01, /* lce_ref_offset 9 */
35 : 0x0e,
36 : 0x01, /* lce_ref_gain 9 */
37 : 0x00,
38 : 0x66, /* lce_block_size h v 0000 0000 */
39 : 0xfa, /* lce_bright_th */
40 : 0x2d, /* lce_bin_size_ratio */
41 : 0x03, /* lce_dark_th 000 */
42 : 0x96, /* lce_min_ref_offset */
43 : 0x00, /* nr sharp cs gamma 0000 */ (unsharpen mask radius (0-15))
44 : 0xff, /* nr_mask_th */ (unsharpen mask threshold)
45 : 0x00, /* sharpen_weight 10 */ (unsharpen mask strength (0-199))
46 : 0x00,
47 : 0x07, /* sharpen_maxplus 11 */
48 : 0xff,
49 : 0x07, /* sharpen_maxminus 11 */
50 : 0xff,
51 : 0x01, /* cs_gain 10 */
52 : 0x00,
53 : 0x00, /* curve_1_b */
54 : 0x20, /* curve_1_a */
55 : 0x00, /* curve_2_b */
56 : 0x20, /* curve_2_a */
57 : 0x00, /* curve_3_b */
58 : 0x20, /* curve_3_a */
59 : 0x00, /* curve_4_b */
60 : 0x20, /* curve_4_a */
61 : 0x00, /* curve_5_b */
62 : 0x20, /* curve_5_a */
63 : 0x00, /* curve_6_b */
64 : 0x20, /* curve_6_a */
65 : 0x00, /* curve_7_b */
66 : 0x20, /* curve_7_a */
67 : 0x00, /* curve_8_b */
68 : 0x20, /* curve_8_a */
69 : 0x00, /* curve_9_b */
70 : 0x20, /* curve_9_a */
71 : 0x00, /* curve10_b */
72 : 0x20, /* curve10_a */
73 : 0x00, /* curve11_b */
74 : 0x20, /* curve11_a */
75 : 0x00, /* curve12_b */
76 : 0x20, /* curve12_a */
77 : 0x00, /* curve13_b */
78 : 0x20, /* curve13_a */
79 : 0x00, /* curve14_b */
80 : 0x20, /* curve14_a */
81 : 0x00, /* curve15_b */
82 : 0x20, /* curve15_a */
83 : 0x00, /* curve16_b */
84 : 0x20, /* curve16_a */
85 : 0x00, /* curve17_b */
86 : 0x20, /* curve17_a */
87 : 0x00, /* curve18_b */
88 : 0x20, /* curve18_a */
89 : 0x00, /* curve19_b */
90 : 0x20, /* curve19_a */
91 : 0x00, /* curve20_b */
92 : 0x20, /* curve20_a */
93 : 0x00, /* curve21_b */
94 : 0x20, /* curve21_a */
95 : 0x00, /* curve22_b */
96 : 0x20, /* curve22_a */
97 : 0x00, /* curve23_b */
98 : 0x20, /* curve23_a */
99 : 0x00, /* curve24_b */
100 : 0xff, /* curve24_a */
101 : 0x20, /* ascr_skin_on strength 0 00000 */
102 : 0x67, /* ascr_skin_cb */
103 : 0xa9, /* ascr_skin_cr */
104 : 0x0c, /* ascr_dist_up */
105 : 0x0c, /* ascr_dist_down */
106 : 0x0c, /* ascr_dist_right */
107 : 0x0c, /* ascr_dist_left */
108 : 0x00, /* ascr_div_up 20 */
109 : 0xaa,
110 : 0xab,
111 : 0x00, /* ascr_div_down */
112 : 0xaa,
113 : 0xab,
114 : 0x00, /* ascr_div_right */
115 : 0xaa,
116 : 0xab,
117 : 0x00, /* ascr_div_left */
118 : 0xaa,
119 : 0xab,
120 : 0xff, /* ascr_skin_Rr */
121 : 0x00, /* ascr_skin_Rg */
122 : 0x00, /* ascr_skin_Rb */
123 : 0xff, /* ascr_skin_Yr */
124 : 0xff, /* ascr_skin_Yg */
125 : 0x00, /* ascr_skin_Yb */
126 : 0xff, /* ascr_skin_Mr */
127 : 0x00, /* ascr_skin_Mg */
128 : 0xff, /* ascr_skin_Mb */
129 : 0xff, /* ascr_skin_Wr */
130 : 0xff, /* ascr_skin_Wg */
131 : 0xff, /* ascr_skin_Wb */
132 : 0x00, /* ascr_Cr */ red in cyan
133 : 0xff, /* ascr_Rr */ red in red
134 : 0xff, /* ascr_Cg */ green in cyan
135 : 0x00, /* ascr_Rg */ green in red
136 : 0xff, /* ascr_Cb */ blue in cyan
137 : 0x00, /* ascr_Rb */ blue in red
138 : 0xff, /* ascr_Mr */ red in magenta
139 : 0x00, /* ascr_Gr */ red in green
140 : 0x00, /* ascr_Mg */ green in magenta
141 : 0xff, /* ascr_Gg */ green in green
142 : 0xff, /* ascr_Mb */ blue in magenta
143 : 0x00, /* ascr_Gb */ blue in green
144 : 0xff, /* ascr_Yr */ red in yellow
145 : 0x00, /* ascr_Br */ red in blue
146 : 0xff, /* ascr_Yg */ green in yellow
147 : 0x00, /* ascr_Bg */ green in blue
148 : 0x00, /* ascr_Yb */ blue in yellow
149 : 0xff, /* ascr_Bb */ blue in blue
150 : 0xff, /* ascr_Wr */ red in white
151 : 0x00, /* ascr_Kr */ red in black
152 : 0xff, /* ascr_Wg */ green in white
153 : 0x00, /* ascr_Kg */ green in black
154 : 0xff, /* ascr_Wb */ blue in white
155 : 0x00, /* ascr_Kb */ blue in black
156 : };
Hey, this looks useful.
Do you mind if I incorporate a variation of this into my SkyHigh kernel. Just an idea ATM to make it Synapse compatible and switchable etc. I'm sure it's doable
Won't be able to try for a few weeks though, still away and have some other kernel commitments on my return
Sent from my SM-N9005 using XDA Premium 4 mobile app
UpInTheAir said:
Hey, this looks useful.
Do you mind if I incorporate a variation of this into my SkyHigh kernel. Just an idea ATM to make it Synapse compatible and switchable etc. I'm sure it's doable
Won't be able to try for a few weeks though, still away and have some other kernel commitments on my return
Sent from my SM-N9005 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Actually, there is nothing here to do with kernel, stock kernel is already capable of loading profiles.
On the other hand, to load profile I do use Tasker so as for reloading on every screen on, 'cause it gets reset every time.
And I do understand that not every user can handle this with such creepy app like Tasker.
So implementing some easy way to handle choosing/loading/reloading plofiles sounds really useful.
The method and app I introduced here are only a comfortable way to investigate a profile structure and build a fine tuned, personolized profile for a particular display and taste. Further usage of that profile yet needs to be developed.
heyjoe66 said:
Actually, there is nothing here to do with kernel, stock kernel is already capable of loading profiles.
On the other hand, to load profile I do use Tasker so as for reloading on every screen on, 'cause it gets reset every time.
And I do understand that not every user can handle this with such creepy app like Tasker.
So implementing some easy way to handle choosing/loading/reloading plofiles sounds really useful.
The method and app I introduced here are only a comfortable way to investigate a profile structure and build a fine tuned, personolized profile for a particular display and taste. Further usage of that profile yet needs to be developed.
Click to expand...
Click to collapse
Yes, I understand that. I wish to add the control into Synapse, no need for scripts or other apps, that's all
I do have control for similar with my Note 3 kernel. I just might try implement some of it, stock or not.
Sent from my SM-N9005 using XDA Premium 4 mobile app
Ok, let me be the first who admits it, I have no glue how to calibrate the screen with your tools. Could you post a step by step guide or even Youtube video? That would be awesome.
Hi,
There is an application on the PlayStore : ColorTRUE
A workmate has the Colormonki Display calibration tool.
I will ask him share it to see how it works and if I can make a "real life" calibrated color screen.
Orphee said:
Hi,
There is an application on the PlayStore : ColorTRUE
A workmate has the Colormonki Display calibration tool.
I will ask him share it to see how it works and if I can make a "real life" calibrated color screen.
Click to expand...
Click to collapse
Hi,
(from app description)
Look for other ColorTRUE Aware Apps
Unlike your laptop or desktop operating system, Android mobile apps do not have system wide color management capabilities. Therefore, each app must apply color profiles individually. For this reason, X-Rite has created the ColorTRUE Aware Partner Program. We are currently collaborating with other app developers to allow them to seamlessly access your ColorTRUE profile so any app can display colors accurately and consistently. ColorTRUE Aware apps will be color managed once you create a profile with ColorTRUE. Just look for the ColorTRUE Aware logo for compatibility.
Click to expand...
Click to collapse
Looks like it doesn't use mdnie.
heyjoe66 said:
Hi,
(from app description)
Looks like it doesn't use mdnie.
Click to expand...
Click to collapse
You are right, I tried the display calibration tool, it only works in X-rite app.
I don't know if it can help, but I extracted ICC profile from data application.
mDNIe is quite obscure for me...
Edit : There is a tool to open ICC profiles here : http://www.color.org/profileinspector.xalter
Orphee said:
You are right, I tried the display calibration tool, it only works in X-rite app.
I don't know if it can help, but I extracted ICC profile from data application.
mDNIe is quite obscure for me...
Edit : There is a tool to open ICC profiles here : http://www.color.org/profileinspector.xalter
Click to expand...
Click to collapse
Not sure if I know what to do with this. I can see some values in the Profile Explorer you provided, but I have no idea, what threy mean.
I tried to read a bit about ICC, like here and here, but seriously, that's too much new info for me right now.
The most terrible thing about color here that bothers me is that color reproduction is heavily depend on screen brightness. With low brightness level grayscale goes totally green. I think I'll try to implement some callback for brightness changes in mdnie in kernel and apply some color correction there. Have no idea, how I'm gonna do that, but I'll try.
Do you want me to do a titanium backup of X-rite ColorTrue to leave you try it (with it own gallery)
Orphee said:
Do you want me to do a titanium backup of X-rite ColorTrue to leave you try it (with it own gallery)
Click to expand...
Click to collapse
Well, thanks indeed, but what I'm saying is that I have no idea how to correlate values from ICC with mdnie values. I don't know what values in ICC profile mean, some kind of coordinates of base RGB colors on some colorspace. I don't know how to translate them into values like red-in-black, red-in-green, red-in-white.
That's what problem is.
If you know anything about ICC profile structure, if can somehow describe all that values to me, maybe then we could figure out something to do with all that.
heyjoe66 said:
8. PROFILE WILL RESET AFTER SCREEN OFF/ON CYCLE. For now I'm using Tasker to refresh it on screen on event. Maybe later we'll figure out some more elegant way;
Click to expand...
Click to collapse
You can use a init.d script for profile reloading when screen is reactivated:
Code:
#!/system/bin/sh
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
sleep 1
fi
done &)
It's nothing else than a modified screenstate scaling script, i use that on my S2 and it works very good.
regards,
lombartz
lombartz said:
You can use a init.d script for profile reloading when screen is reactivated:
Code:
#!/system/bin/sh
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
sleep 1
fi
done &)
It's nothing else than a modified screenstate scaling script, i use that on my S2 and it works very good.
regards,
lombartz
Click to expand...
Click to collapse
Nice. That looks really useful. Sadly, these wait_for_fb_* attributes are missing on our device, or maybe moved to some place else. Need to look for them.
Regarding the problem you're referring to, it's actually a bug in samsung's code. They are trying to read profile from /sdcard when sdcard is not ready yet. I've fixed it in my own kernel build by moving the mdnie folder to /data. So now profile is updated as it meant to.
Can this be used to raise the gamma levels on the sm-t805 lollipop screen?
I have been playing around with this today but cant seem to get it to affect the color.
I have loaded up ABD, and loaded the DYNAMIC_UI profile into your little app but none of the sliders seem to affect anything on screen.
This is on a T800 running Cyanogenmod
Wow, I have a x-rite i1 display pro and it's working with color True application, can I load a profile at startup?
Astania said:
Wow, I have a x-rite i1 display pro and it's working with color True application, can I load a profile at startup?
Click to expand...
Click to collapse
Nope, thats not what this is for. I have the same piece of hardware but it only creates a profile that other apps can use if they support the x-rite sdk, such apps are nonexistent on Android except the x-rite app itself, and that app only works for displaying photos.
The mDNIe profiles are going to bare zero relation to the x-rite profiles so you cant use the x-rite profiles system wide even if you had the means.
I dont think there is enough dev backing on this to make it happen, but the ultimate goal would be to create a tool which is able to adjust the various settings of these profiles so it can be used in conjunction with a colorometer to create a color accurate profile that can be loaded up system wide.
Well, ICC profiles are universal standard, not only used by X-rite. X-rite is only making devices to measure color differences between the display and the standard.
So if you have another standard colour profile for display like mDNIe , you somehow must know what is a difference between a display you are profiling and standard, so you need a device to measure it.
Maybe there's a tool that can convert ICC to mDNIe profile?
It would be great to have possibility to turn on the display profiling at startup, especially that it can display wide range of AdobeRGB palette. ColorTrue app makes an ICC when you connect a profiler via USB and difference after and before profiling is huge. But profiles work only in the application, so it's not good.
Astania said:
Well, ICC profiles are universal standard, not only used by X-rite. X-rite is only making devices to measure color differences between the display and the standard.
So if you have another standard colour profile for display like mDNIe , you somehow must know what is a difference between a display you are profiling and standard, so you need a device to measure it.
Maybe there's a tool that can convert ICC to mDNIe profile?
It would be great to have possibility to turn on the display profiling at startup, especially that it can display wide range of AdobeRGB palette. ColorTrue app makes an ICC when you connect a profiler via USB and difference after and before profiling is huge. But profiles work only in the application, so it's not good.
Click to expand...
Click to collapse
Yup, I completely agree with what you are saying.
The screen on the Galaxy Tab S is really great, a very capable screen. But it's hampered by being locked to the few profiles Samsung provides.
Unfortunately mDNIe is a Samsung-only affair, and the tool posted earlier is full of sliders that seem to do nothing to the colour of the screen.
The profiles created by the X-Rite app are just a correction on top of a correction, this is fine and all as the chances of us getting low-level calibration seem non-existent, but there are no apps out whatsoever that actually use the X-Rite sdk (other than the x-rite app).
Without an advanced developer on board who knows all of this stuff inside out, I dont think we are going to get anywhere with conversion of mDNIe to ICC or anything like this.
The X-Rite app is great for photos, if there was any support for the X-Rite SDK in a video app this would be a good enough solution for me even if it is a correction on top of a correction, as colour accuracy in the OS is not important.
I'm trying to compile the kernel but either I'm doing something wrong or LG forgot to add a few files. So I contacted LG and they actually responded saying they'll contact the devs to see when they can distribute the fix. When that happens I'll compile it and see if I can add a few lower frequencies because 598mhz min is a battery hog and 200mhz min will probably be more battery-friendly. For now I've added lagfree because it's arguably the best governor and all the other ones that came with the kernel blob (like "balanced") I haven't played with adding I/O schedulers yet, but I will once LG write back. Don't expect much of this because this is my first kernel and I barely have any idea what I am doing other than copy-pasting into the right place because I understand file context and syntax.
Thumbs up, even if I don't use the H420.
Tomo123 said:
Thumbs up, even if I don't use the H420.
Click to expand...
Click to collapse
Don't worry, I'm sure the crazy Russians over at 4pda will unlock the bootloader :good:
TheFagulousFag said:
Don't worry, I'm sure the crazy Russians over at 4pda will unlock the bootloader :good:
Click to expand...
Click to collapse
If you are talking about H420's bootloader, it's already been unlocked. As for the H440N, the guy who unlocked the H420's bootloader says that H440N should use a method similar to Bump. He says aboot can't be patched, sth like that.
Fobos531 said:
If you are talking about H420's bootloader, it's already been unlocked. As for the H440N, the guy who unlocked the H420's bootloader says that H440N should use a method similar to Bump. He says aboot can't be patched, sth like that.
Click to expand...
Click to collapse
If it uses bump can't you use openbump, or did lg patch that?
TheFagulousFag said:
If it uses bump can't you use openbump, or did lg patch that?
Click to expand...
Click to collapse
I don't know, I haven't tried it yet. I'll give it a try and report.
---------- Post added at 05:33 PM ---------- Previous post was at 05:16 PM ----------
Fobos531 said:
I don't know, I haven't tried it yet. I'll give it a try and report.
Click to expand...
Click to collapse
Before I do anything, can I do this?
dump aboot partition ---> use open bump on aboot.img --> trasnfer it back on the device and see if it works. Do I risk my device getting bricked or what? I also saw an abootbak partition.
Well, it would make sense to ask the original Bump dev about the possibility for porting this to H440N. Just send him the aboot.
Fobos531 said:
I don't know, I haven't tried it yet. I'll give it a try and report.
---------- Post added at 05:33 PM ---------- Previous post was at 05:16 PM ----------
Before I do anything, can I do this?
dump aboot partition ---> use open bump on aboot.img --> trasnfer it back on the device and see if it works. Do I risk my device getting bricked or what? I also saw an abootbak partition.
Click to expand...
Click to collapse
Try to bump the recovery instead, just don't forget to make a backup copy.
TheFagulousFag said:
Try to bump the recovery instead, just don't forget to make a backup copy.
Click to expand...
Click to collapse
Bump was tried on our device long ago, but it didnt work.
---------- Post added at 08:12 PM ---------- Previous post was at 08:06 PM ----------
Tomo123 said:
Well, it would make sense to ask the original Bump dev about the possibility for porting this to H440N. Just send him the aboot.
Click to expand...
Click to collapse
Bump as a project is dead if Im right. It surely wont work, because LG made changes in LP bootloader in comparison to KitKat so Bump wont work. Take a thorough look at this thread: http://forum.xda-developers.com/lg-g2/orig-development/tool-bump-sign-boot-images-t2950595
Btw. I have issues registrating on 4pda.ru so I cant yet ask the guy who patched the H420 bootloader why our cant be patched through IDA.
Serious issues.
LG sent me an email saying they fixed it and it was an error in the txt file. Following the instructions, I decided to make a fully untouched stock kernel to see if it would compile. When I run the last command which programs and packs the kernel "make zImage" it errors after literally 4 lines and stops. I decided to ignore errors and forced it. It still fails. I logged the command and sent it to LG. Hopefully they will fix this, I am now even more eager to compile this.
Can someone post all the list of cpu governors, cpu frequencies and default cpu settings for the H420? Maybe I can tweak those to some better values.
Tomo123 said:
Can someone post all the list of cpu governors, cpu frequencies and default cpu settings for the H420? Maybe I can tweak those to some better values.
Click to expand...
Click to collapse
Only hotplug is modiefiable. If you want I could give you the source files.
I would not mind taking a look at those.
Keep in mind it is C code. I'll send you a pm with the files zipped when I get home.
Overclock already defined?
Looking at mtk_cpufreq.c has some interesting stuff, like defined frequencies.
Code:
#define DVFS_F0_1 (1690000) // KHz
#define DVFS_F0_2 (1599000) // KHz
#define DVFS_F0_3 (1495000) // KHz
#define DVFS_F0_4 (1391000) // KHz
#define DVFS_F0 (1300000) // KHz
#define DVFS_F1 (1196000) // KHz
#define DVFS_F1_1 (1092000) // KHz
#define DVFS_F2 (1040000) // KHz
#define DVFS_F2_1 (1001000) // KHz
#define DVFS_F3 ( 747500) // KHz
#define DVFS_F4 ( 598000) // KHz
#if defined(HQA_LV_1_09V)
#define DVFS_V0 (1200) // mV
#define DVFS_V1 (1150) // mV
#define DVFS_V2 (1090) // mV
#define DVFS_V3 (1090) // mV
#elif defined(HQA_NV_1_15V)
#define DVFS_V0 (1260) // mV
#define DVFS_V1 (1200) // mV
#define DVFS_V2 (1150) // mV
#define DVFS_V3 (1050) // mV /*Not used */
#elif defined(HQA_HV_1_21V)
#define DVFS_V0 (1320) // mV
#define DVFS_V1 (1210) // mV
#define DVFS_V2 (1150) // mV /*Not used */
#define DVFS_V3 (1050) // mV /*Not used */
#else /* Normal case */
#define DVFS_V0 (1250) // mV
#define DVFS_V1 (1200) // mV
#ifdef CPUFREQ_SDIO_TRANSFER
#define DVFS_V2_0 (1185) // mV
#endif
#define DVFS_V2 (1150) // mV
#ifdef MT_DVFS_LOW_VOLTAGE_SUPPORT
#define DVFS_V3 (1050) // mV
#endif
#endif
Even though I'm a complete noob at kernel compiling, this seems easy enough for me to try and get it to work at 1.69ghz, which seems a bit overkill actually :laugh: