[Kernel][android_kernel_lge_msm7x27-3.0.x][bigsuperkernel-3.08]

[bigsupersquid]

v5.0
turned on regulators instead of vreg for ld012 (wlan) and cut them to 2.4v from 2.85v in board-thunderc-mmc and board-msm7627-regulator. Since it seems to work, I can't figure out why the thunderg was still using vreg in the board-*-mmc code. They had created the regulator code and commented it out, adding the 2.6.35 vreg stuff back in instead.
It still runs, dunno if it compensates by drawing more amps... I don't have mmarz's ammeter rig to test current draw from the battery.
added an bunch of patches for linaro 4.8 but they don't help.
messing with ami304d some more.
and I'm now going to have to post selinux-enforcing and selinux-disabled kernel binaries or just leave it enforcing until there's problems.

 

[bigsupersquid]

upgraded to home-built linaro 4.7.4 armv6k-tweaked toolchain.
sensors seem stable.
Too bad linaro 4.8 and up makes something that just hangs instead of booting.

 

[bigsupersquid]

well, I am finally satisfied with the accelerometer/compass.

the two thunderc ami304d binary blobs (froyo and gingerbread) both jittered really badly in google skymap and threw repetitive logcat errors, plus they had that nasty sleep/calibration loop issue.

the thunderg blob had output smooth as butter in the skymap, and didn't throw any errors or have sleep issues. but the skymap was like looking in an inside-out mirror. I figured out the magnetic x and y were both negative (flipped around their respective axes.) I suspect the ami chip is mounted backwards or something in the thunderc.

I tried and tried to fight the thunderc blobs into working without jitter, but always at north and especially south they were horrid. (they do jitter a bit in mirage, even, in the skymap compared to my evo.)

I gave up on the thunderc blobs and decided to invert the kernel output to the closed-source middleware thunderg blob instead.
So I dug until I found a likely spot in the ami304.c driver, grabbed debug output code for the mag sensor

	if (AMI304_DEBUG_DEV_STATUS & ami304_debug_mask) {
		int mx, my, mz;
		mx = my = mz = 0;

		mx = (int)(databuf[0] | (databuf[1] << 8));
		my = (int)(databuf[2] | (databuf[3] << 8));
		mz = (int)(databuf[4] | (databuf[5] << 8));

		if (mx>32768)  mx = mx-65536;
		if (my>32768)  my = my-65536;
		if (mz>32768)  mz = mz-65536;

		AMID("Magnetic Raw Data: X=%d, Y=%d, Z=%d\n", mx, my, mz);
	}

and modified it to read the 16-bit (two-byte each) mag x and y outputs, negate the translated results, and translate those back to two single bytes before writing the buffer to the kernel output.

// invert mx and my for thunderc to use better resolving thunderg ami304d blob
		int mx, my;
		mx = my = 0;
		mx = (int)(databuf[0] | (databuf[1] << 8));
		my = (int)(databuf[2] | (databuf[3] << 8));
		if (mx>32768)  mx = mx-65536;
		if (my>32768)  my = my-65536;
		mx=-mx;
		my=-my;
		if (mx<0) mx=mx+65536;
		if (my<0) my=my+65536;
		databuf[0]=(mx&255);
		databuf[1]=(mx>>8);
		databuf[2]=(my&255);
		databuf[3]=(my>>8);

in front of the line that outputs the buffer it read from the chip to the middleware...

	sprintf(buf, "%02x %02x %02x %02x %02x %02x", 
			(databuf[0]), (databuf[1]), (databuf[2]), 
			(databuf[3]), (databuf[4]), (databuf[5]));

now the skymap looks just like my evo, except the evo actually jitters more than the V
and my old 8-bit assembly programming gimmicks got put to use with the & | << >> (AND OR shift left shift right) binary operators
and, the most fun part, I shimmed one of those stupid closed-source binary blobs into working right.

I'm posting this code for other searchers in case someone is trying to find a method for inverting the mag outputs on an ami304 driver.

this will mark r5.5, but 5.0 on up with the TLS and mtd system/data reversing hack won't flash right on older roms and I'll have to mark this checkpoint somehow.

 

[inceyet]

Hey sorry for going off subject but i need the diver for the lg optimus v . I have since moved to the LG G2 but gave my v to my son and wanted to change the rom but i recently cleaned out my laptop and erased the drivers. So if any one has them and can dm me or just post them her that would be fantastic. Thank you in advance

 

[bigsupersquid]

Hey sorry for going off subject but i need the diver for the lg optimus v . I have since moved to the LG G2 but gave my v to my son and wanted to change the rom but i recently cleaned out my laptop and erased the drivers. So if any one has them and can dm me or just post them her that would be fantastic. Thank you in advance

http://forums.androidcentral.com/op...-how-simplified-root-recovery-custom-rom.html

 

[bigsupersquid]

well, this should be interesting.

I just spent about an hour and a half trying to unify my kernel with androidarmv6 so that it's rebased on theirs but with my addons (thunderc device, aufs, usb fastcharge, fbconsole, frandom, uhid support) and hopefully made it a decent enough merge that I can build both thunderg and thunderc from the same source code now.
I felt lucky, I got a handle on checking for specific device config in the source code earlier than I remembered, and patching around instead of over the thunderg wasn't too bad at all.
if it tests out ok on both devices, I may even clean out the extra changes for a vanilla 'add thunderc' commit and submit a pull request to get it all upstream. If. //edit: well whaddaya know. they both boot up and seem to work ok.

Anyway, now it's up to kernel 3.0.101 with f2fs. Thanks HardLight. After some testing I'll finally get an up-to-date binary up here.
Actually one with TLS and mtd swap, and one without those, once I get this all together.

//edit edit: dang anykernel zips won't run the unmkbootimg and stuff but segfault. replacing with newer binaries seems to work. and the p500 kernel starts up fine built with my linaro 4.8 but thunderc refuses no matter what I try. Something in my port is obviously tweaky with higher gcc versions.

 

[bigsupersquid]

3.0.101 r6.0 noTLS noMTDswap uploaded. f2fs enabled. use on old pre TLS ROM to fix accelerometer and tweak it out more.
3.0.101 r6.0 TLS MTDswapped. also f2fs enabled. use with new ROM like most recent OS2SD to fix accelerometer mostly.

I'm not throwing the twrp2.8 out there yet, it's still slightly buggy.

 

[Casey Campanile]

I flashed tls mtd swapped, but while flashing, any kernel updater says no TLS no mtdswap. Is that a problem?

 

[bigsupersquid]

I flashed tls mtd swapped, but while flashing, any kernel updater says no TLS no mtdswap. Is that a problem?

oops, I forgot to change the ui_print line in the updater-script.
It's got the correct kernel and stuff in it, anyway. It should work fine.
Thanks for the report, I'll fix and reupload.

 

[dark_samus]

hello, first I'd like to thank you for all of your work on the 3.0.x kernel for the optimus V, I'm currently trying to port it over to a similar device (optimus slider) mainly just for fun and learning, but hey if I can get it running I'll port kitkat over to it... anyways I had some questions for you regarding the regulator... it seems that the old 2.6.35 kernel didn't have a board-msm7627-regulator.c file and I was wonder where/how you got the PCOM_VREG_LDO values for thunderc in there, I can't seem to find any reference to those things in the old kernel source for thunderc or gelato (the device I'm porting the kernel to) I'd very much appreciate it, also in board-thunderc-panel.c (I assume this is for the display panel?) there are a few seemingly conflicting lines...

static char *msm_fb_vreg[] = {
//	"gp1",
	"gp4",
	"gp2",
};

I assume this tells us which vregs to use in board-msm7627-regulator.c file, gp1 is commented out so I assume gp4 would be msm_fb_vreg[0] and gp2 would be msm_fb_vreg[1] but then looking at some code further down things get weird...

rc = regulator_set_voltage(vreg_gp1, 1800000, 1800000);
		if (rc) {
			pr_err("set_voltage vreg_gp1 failed, rc=%d\n", rc);
			regulator_put(vreg_gp1);
			regulator_put(vreg_gp2);
			return -EINVAL;
		}

		rc = regulator_set_voltage(vreg_gp2, 2800000, 2800000);
		if (rc) {
			pr_err("set_voltage vreg_gp2 failed, rc=%d\n", rc);
			regulator_put(vreg_gp1);
			regulator_put(vreg_gp2);
			return -EINVAL;
		}

this seems to show that gp1 and gp2 are being affected but not gp4 which was used above, now I was thinking that maybe gp1 and 2 were being referred to as gp1 and gp2 only for the panel but after looking in board-msm7627-regulator.c
gp1 is ldo09, gp4 is ldo10 and gp2 is ldo11 as shown in the code above vreg_gp1's voltages are shown as 1800000 (microvolts I believe) but comparing that to the board-msm7627-regulator.c values if indeed vreg_gp1 is gp4 then the voltages in the table are different... I believe something similar goes with vreg_gp2 in the panel file but I don't remember at the moment, so could you explain what is going on with this? Again I'd very much appreciate it
thanks
~dark_samus

 

[bigsupersquid]

I'll answer more completely on pc,
but in a nutshell...
the gpio_tlmm_config, vreg_get, and vreg_put in the old kernel board-*.c files have the voltages and ldo info.

the weird-looking display gpio code has a hardcoded selector line based on lge board rev, in that panel file. the thunderc is "special" (read either advanced or retarded depending on your view) with a composite Hitachi/Novatek video driver that detects which hardware is present at boot.

hopefully that helps some.

more details later .

 

[bigsupersquid]

I'll answer more completely on pc,
but in a nutshell...
the gpio_tlmm_config, vreg_get, and vreg_put in the old kernel board-*.c files have the voltages and ldo info.

In the 3.0... you have to #include "../board-msm7627-regulator.h"
and things change like so:
static struct vreg *vreg_mmc;
becomes
static struct regulator *vreg_mmc;
and
rc = vreg_set_level(vreg_mmc, VREG_SD_LEVEL);
to
rc = regulator_set_voltage(vreg_mmc, VREG_SD_LEVEL*1000, VREG_SD_LEVEL*1000);

the regulators can be figured out looking for lines like:

static void __init msm7x2x_init_mmc(void)
{
	if (!machine_is_msm7x25_ffa() && !machine_is_msm7x27_ffa()) {
[COLOR="#0000FF"]//		vreg_mmc = vreg_get(NULL, "wlan");
		vreg_mmc = regulator_get(NULL, "wlan");
[/COLOR]		if (IS_ERR(vreg_mmc)) {
			printk(KERN_ERR "%s: regulator get failed (%ld)\n",
//			printk(KERN_ERR "%s: vreg get failed (%ld)\n",
			       __func__, PTR_ERR(vreg_mmc));
			return;
		}
	}

and then look in board-msm7627-regulator.c for the named device:

PCOM_VREG_CONSUMERS(ldo13) = {
	REGULATOR_SUPPLY("ldo13",	NULL),
	REGULATOR_SUPPLY("wlan",	NULL),
};

then match the voltages (*1000) from the original board files,

#ifdef CONFIG_MMC_MSM_CARD_HW_DETECTION
			rc = vreg_set_level(vreg_mmc, VREG_SD_LEVEL);
#else		
			rc = vreg_set_level(vreg_mmc, 2850);
#endif

later in the regulator file

	PCOM_VREG_LDO(ldo13, 15, NULL,  2400000,  3000000, 0, -1, 0, 0, 0, 0),

though I forget where I found the low voltage, it's around somewhere. Or I used the thunderg setting... (VREG_SD_LEVEL is set in board-*.h)

the weird-looking display gpio code has a hardcoded selector line based on lge board rev, in that panel file. the thunderc is "special" (read either advanced or retarded depending on your view) with a composite Hitachi/Novatek video driver that detects which hardware is present at boot.
...

ok, the original files used the board rev found by the kernel, but that's broke in the port, so it pulls that variable from kernel command line and isn't relevant to this question after all.
but... the funny bit you're asking about in board-thunderc-panel.c is here.
It took me a while to originally puzzle out 'cause I didn't have any real C++ experience yet... Now I actually know what it does.

static char *msm_fb_vreg[] = {
//	"gp1",
	"gp4",
	"gp2",
};

notice gp1 is commented out (to match sprint 2.6.35 thunderc code,) and the other gp* names are in an array.
and here

	if (!mddi_power_save_on) {
		[COLOR="#0000CD"]vreg_gp1 = regulator_get(0, msm_fb_vreg[0]);[/COLOR]
		if (IS_ERR_OR_NULL(vreg_gp1)) {
			pr_err("could not get vreg_gp1, rc = %ld\n",
				PTR_ERR(vreg_gp1));
			return -ENODEV;
		}

it uses vreg_gp1, but that value is set from the array position 0, which is actually gp4 instead of gp1. The same thing later for vreg_gp2, which is pulled from the array as gp2.

		[COLOR="#0000FF"]vreg_gp2 = regulator_get(0, msm_fb_vreg[1]);[/COLOR]
		if (IS_ERR_OR_NULL(vreg_gp2)) {
			pr_err("could not get vreg_gp2, rc = %ld\n",
				PTR_ERR(vreg_gp2));
			regulator_put(vreg_gp1);
			return -ENODEV;
		}

 

[dark_samus]

thank you very much this will help with my port tremendously (though I still need to get the low voltages but I'm sure those can be figured out) also I have never once looked up any tutorials on coding in C but somehow it all just kinda clicks in my head when reading it... so basically the way it is used here (vreg_g1 and vreg_gp2) are just names in that specific file and don't matter as they're really pulling gp4 and gp2 from board-msm7627-regulator.c?

 

[bigsupersquid]

thank you very much this will help with my port tremendously (though I still need to get the low voltages but I'm sure those can be figured out) also I have never once looked up any tutorials on coding in C but somehow it all just kinda clicks in my head when reading it... so basically the way it is used here (vreg_g1 and vreg_gp2) are just names in that specific file and don't matter as they're really pulling gp4 and gp2 from board-msm7627-regulator.c?

true, for this particular device. You'll have to get the correct registers from your board files. 'Course, a lot of what I did was guessing and learn-by-trial-of-fire work, and I can't guarantee anything this was my one and only kernel port to date.

 

[dark_samus]

true, for this particular device. You'll have to get the correct registers from your board files. 'Course, a lot of what I did was guessing and learn-by-trial-of-fire work, and I can't guarantee anything this was my one and only kernel port to date.

heh... you should actually see how similar the board files are.... gelato is the Virgin Mobile older brother of the V, same CPU and i believe same camera, bcm4330 instead of bcm4325 and a bunch of other similarities (in most cases, if I see an #if defined(CONFIG_MACH_MSM7X27_THUNDERC) I can turn it into #if defined(CONFIG_MACH_MSM7X27_THUNDERC) || defined(CONFIG_MACH_MSM7X27_GELATO)) so this port should be too hard... even the panel files are similar it also uses the hitachi driver for the screen and a bunch of other things