yashsingh1/xdaforums huggingface dataset:
[T-Mobile LG G2x] Core Memory:
If you want to monitor what the phone's radio/modem is doing in real time, read and implement the instructions in my OP about how to do it.

http://xdaforums.com/showthread.php?t=1977221
[T-Mobile LG G2x] nickleo642000:
this post has some good close ups of the mainboard the service in the trouble shooting section does have pics with labels of the motherboard

http://xdaforums.com/showthread.php?t=1163392

also i have found a copy of the original driver for the mdm6600 for our phone but its the v10e labeling in the driver i can post if it will help
[T-Mobile LG G2x] Naberus:
The baud rate thing is a nice tip, thanks. I'll try that.

I think the [MS]RDYs should be okay in the new code, so long as they're using the correct GPIOs.... Which I'm not sure of. I find the NvOdm code in the 2.6.32 kernel to be completely illegible, versus the newer 2.6.39 code which is comprehensible even without documentation. (I.e. mediocre v.s. good.) The P999DW service manual lists another set of GPIOs for MRDY and SRDY, so I'm going to try those:

The MDM6600 [MS]RDYs were listed as PU6/PJ6 in spi_mdm6600.c. The P999DW service manual lists IPC_[MS]RDY1 as PJ4/PU6. If anyone can figure out hard values from the GB kernel source, that might help. (Alternately, a few debug printk's added to the GB kernel could get that data, but I'm not in the mood to set up another build tree when I can't even be sure that's the problem.)

Edit 2: The P999DW service manual lists two sets of values: page 175 lists IPC_[MS]RDY as stated above, page 168 lists them swapped around. Awesome.

I know my ldisc ID hack interferes with CAIF, but I was worried the old RIL would use the CAIF/TS0710 ldisc when it configures the termios... So I made sure CAIF was disabled, so it wouldn't register a conflicting ldisc.

Effectively, my -ts0710 branch is my "hackery" branch. If I get the radio working, I plan on cleaning it up so it could be merged back to the upstream lge-kernel-star (i.e. define everything in such a way as to not break the SU660/P990). As is, it's just a rough hack - the fact that I interfere with CAIF (and a number of other things) doesn't bother me. (I could add a CONFIG_MACH_STAR_P999_BBCOMPAT kernel option or something that is mutually exclusive with CAIF when "old" baseband compatibility is configured.)

The repeated open failure on pts1 is the RIL. The open and close once on pts29 is the little run-once utility (bbversion/cpversion.c) that gets baseband info from the radio. I'm not worrying about either until I can talk to at least one of the SPIs.

Edit: Also, in terms of whether or not the dual SPI functionality is required, the way I read it I think it's hard-coded. The spi sync function in spi_mdm6600.c in the GB kernel is wrapped in "#ifdef LGE_DUAL_SPI_1" (different from the config option, hardcoded in the Makefile). If not defined, a syntax error occurs and the kernel won't compile. I think the "missing" second SPI in the service manual is also expected since the second piggybacks it's buffers and the [MS]RDY GPIOs off the first.
[T-Mobile LG G2x] nickleo642000:
tech manual

From reading it sounds like the dual spi function is the high band and low band freq controls to the rf amplifiers ???? this was on the page 21 and 22 of the service manual it also shows all the input and output from the mdm6600 chip set

A single analog baseband Tx input is shared by all the MDM transmit paths. Two quadrature upconverters, onededicated for each band category (low band and high band), translate the Tx waveform directly to the desiredRF band. The RF signal is then routed to the appropriate driver amplifier output
[T-Mobile LG G2x] Mazout360:
Hehe yes nvodm functions are crap... But you can get to understand how they work by seeing them in context...I'm happy this is gone.

How did it perform with the new GPIOs ? Did it break something ? I used to make the GPIO board settings out of the manual and many features such as the touchscreen broke up, so I don't think it's much reliable.. As you stated, even the values in the manual are conflicting.

Thanks for the tip on pts29 I did not know that.
[T-Mobile LG G2x] Naberus:
The new gpio values didn't cause any change in behavior, but at least I know where the EINVAL is coming from: spi_master->transfer called from __spi_async in spi.c.

What I don't get right now is the master/slave naming scheme. I was surprised to find out that when the spi code calls spi_master->transfer that it actually ends up calling code in spi_slave_tegra...?

Edit: EINVAL was because I'm stupid:

struct spi_transfer t_sec; // Random bytes in whatever memory the struct ends up allocated to.
struct spi_transfer t_sec = {}; // Should have been this.

Both spi_[a]sync calls now proceed normally, but never come back...
[T-Mobile LG G2x] Mazout360:
Spi master (of course) and spi slave tegra are required..did you find anything wrong with the slave ?

So the sync functions sends a call, but it never returns...so I guess it calls via a pts node and doesn't come back since the node is closed, or is it the call itself that is incorrect and has no response, thus returning a "closed node" issue ?
[T-Mobile LG G2x] Naberus:
No idea. Still digging downwards.

It *is* the pts node. (Or, more accurately, one of the functions along the code path that provides the device node.)

If you look at it like a stack, the /dev/pts node is on top, with the tty interface one layer down, then the line discipline, then the SPI code, then further down into depths I haven't looked at yet.

Going down the stack: The RIL tries to open /dev/pts1, which triggers an open in the tty layer, which uses the line discipline as a translator, sending some kind of init packet (sabm?) through the SPIs.

The response to the init packet takes too long (and we go back up the stack), and the line discipline decides the reply isn't coming and times out returning failure, which causes the tty open to return -ENODEV, which is in turn returned to the RIL which displays the error for us to see.
[T-Mobile LG G2x] apolkosnik:
Sounds like the radio/modem is not turned on.
[T-Mobile LG G2x] Core Memory:
Is there an external way to force the radio/modem on?

I've emailed someone at Motorola asking for assistance. They have extensive experience with the mdm6600 and Android. Here's part of their resume:

4+ years of mobile wireless device product development software engineer team member responsible for end-to-end development of new product introduction and launch to North America wireless carriers.

Experience working as a Software Engineer/Configuration Management

Worked as a Software Configuration Management Engineer using GIT version control for the Android platform

Worked on builds integration of Qualcomm code in Motorola baseline.

Worked on secure signed builds for MDM6600.

Worked on Baseband flex, CEFS generation and expertise in bash scripting.

Worked on Product customizations for various motorola products (Backflip for ATT, Droid X2 for Verizon and currently Droid4) using overlays.

Expertise in Over-the-air system update for MotoBlur products.

Excellent Programming and Debugging skills using C.

Knowledge of Digital Communication Systems and Signal Processing fundamentals.

Experience in defect tracking using DDTS, Bugzilla, Jira.

• Worked in the product team that successfully launched Droid X2, Droid 4, Droid Razr ICS upgrade Droid 4 ICS upgrade.

• Android Product Stability tracking, issue triage and resolution (Phone resets, Force close, Tombstones, Linux Kernel crashes)

• Generation and Verification of Over-the-air software upgrade packages.

• Triage, determine root cause analysis, review and approve fixes at all layers for Android based mobile phones.

• Triage and resolution of User Trial reported functional software problems.

• Investigation, Debug and Bug Fixes of mobile device modem related defects (includes interfacing with external modem vendor - Qualcomm).

• Worked on the Motorola software security implementation feature which included software feature design, implementation and verification.
[T-Mobile LG G2x] xp99:
If they want to help, tell them to come join us on here.
[T-Mobile LG G2x] Core Memory:
I did.
[T-Mobile LG G2x] Naberus:
Not sure if this is correct, but I think I found where the SPI GPIOs are defined in the GB kernel:

arch/arm/mach-tegra/odm_kit/star/query/subboards/nvodm_query_discovery_starsmartphone_addresses.h

This file lists the following GPIOs for [MS]RDY:

//20100729-1, , Crazy!!, it changed [START]
{ NvOdmIoModule_Gpio, 'u' - 'a', 6, 0}, //SRDY1 //{ NvOdmIoModule_Gpio, 'o' - 'a', 5}, //SRDY2
{ NvOdmIoModule_Gpio, 'j' - 'a', 6, 0}, //MRDY1//{ NvOdmIoModule_Gpio, 'o' - 'a', 0}, //MRDY2
//20100729, , Crazy!!, it changed [END]

PU6/PJ6 are the same values as were listed in v30a spi_mdm6600.c, but swapped. If I use the swapped order I get an MRDY IRQ just after the first spi transfer is initiated, which I take to be a good sign. (Same result though - spi transfers hang.) Just for kicks, tried the unmodified v30a source with swapped GPIOs to see what it would do. Also no dice.

The same GB header also lists the [MS]RDY2 values in an #ifdef CONFIG_DUAL_SPI, which makes me think I probably do need that second set of GPIOs integrated before I'll even get anything... But I really am blind because I'm terrible reading the NvOdm stuff.

Expect not to hear anything from me for the next while because I think I need to understand the old code better before I can continue digging into why the new code isn't working.
[T-Mobile LG G2x] xBIGREDDx:
It looks like the complete GPIO is defined in:

arch/arm/mach-tegra/gpio.c

The same pins are listed as you posted:

/* All GPIO output pins should be defined here */
// CP sleep status (high : +3mA)
{ 'j'-'a', 6, GPIO_ENABLE, GPIO_OUTPUT, GPIO_SLEEP_LOW, IRRX}, // IPC_MRDY1
{ 'o'-'a', 0, GPIO_ENABLE, GPIO_OUTPUT, GPIO_SLEEP_LOW, UAB}, // IPC_MRDY
/* All wakeup pins should be defined here : gpio input enable */
{ 'o'-'a', 5, GPIO_ENABLE, GPIO_INPUT, GPIO_SLEEP_LOW, UAB}, // IPC_SRDY2
/* tristate group's input pins */
{ 'u'-'a', 6, GPIO_ENABLE, GPIO_INPUT, GPIO_SLEEP_LOW, GPU}, // IPC_SRDY1

The "2" is missing from MRDY2, not sure if that's important.

EDIT: I guess these were already present in the v30a you've got in your ts0710 repo, at "arch / arm / mach-tegra / lge / star / include / lge / board_star_su660_gpio.h"
[T-Mobile LG G2x] Core Memory:
Tegra 2 technical reference manual:

http://www.chiark.greenend.org.uk/~theom/riscos/docs/Tegra2_TRM_DP04508001v01p.pdf
[T-Mobile LG G2x] Core Memory:
I've looked at Vork's gpio.c and found there are specific differences in the GPIO pin function assignments between the P990 (CONFIG_MACH_STAR_REV_F) and P999 (CONFIG_MACH_STAR_TMUS): https://bitbucket.org/Vork/lge-kernel-star/src/f1a261d39845/arch/arm/mach-tegra/gpio.c

The differences would apply to ICS/JB code differences between the P990 and P999 which would interfere with enabling the radio/modem.

Even though the P990 and P999 are identical hardware except for the radio/modem, it's as if two separate programmers independently assigned the functions for the P990 and P999 Tegra 2 pins.

I hate LG.
[T-Mobile LG G2x] Mazout360:
I got the [MS]RDY2 gpios integrated and loaded the same way the [MS]RDY gpios are in MDM6600 and now the probe fails and bluetooth is now broken...I wonder if they changed again the gpio names for these.
[T-Mobile LG G2x] King-Nai:
I was examining the two mux drivers ts0710mux and ts0710mux_mdm and the ts0710mux looks very similar to the CM ics version. It's LG that forces us to compile the ts0710mux_mdm version, it's in their makefile. This may be a better place to start, compare the ts0710_mux.c and the ts0710_mux_p999.c files from the CM ICS source. There are only a few diffs.

Just more things to look into -.-
[T-Mobile LG G2x] Mazout360:
Well the mdm version should be made to communicate with a mdm6600 modem I guess ? I don't know if being similar to the ICS version is a good thing since it doesn't work and on GB it does.

What bugs me more in their makefiles is that in GB kernels it compiles ifx_n721_spi and not spi_mdm6600. By looking at both drivers in ICS, they're quite similar.
[T-Mobile LG G2x] King-Nai:
What I was saying, the GB tsmux works and ours doesn't. What we could do is look at the tsmux and the tsmux_p999 differences in the GB kernel and apply those changes to the JB kernel. It compiles just fine with a few makefile changes using the non mdm version. The issue is still that the line discipline never opens. It's what allocates the buffer and such.
[T-Mobile LG G2x] apolkosnik:
It seems that one of my last unreleased builds opens up /dev/ttyspi0 gets an fd, but can't seem to get hold of /dev/

pts1 (no such device)
[T-Mobile LG G2x] Mazout360:
That's a starting point, but I don't understand why you have issues with your line discipline...it doesn't show up if you do cat /proc/tty/ldiscs in a terminal ?

That's your latest build ? I couldn't get anything concerning RIL working on build 7, but on CM10 it works.

I just talked to LG to get infos on the proprietary blobs missing in the source code...Wow these guys really don't want to help you at all when you call for help. He gave me two phone no 800-793-8896 or 800-243-0000 to try to reach some tech service somehow but seemingly they will not help us.
[T-Mobile LG G2x] King-Nai:
I'm pretty sure it's dying here: https://github.com/Naberus/lge-kern.../drivers/spi/ts0710mux_mdm/ts0710_mux.c#L2021

Because the ldisc never inits ipc_tty. Which branch or yours makes tty_register_ldisc 20 and not 21? I'm pretty sure that's a bit one, you have to open the right number. Did you compile the rild yourself or is that the CM version?

The ldisc never is opened. I'm starting to thing it's the ldisc numbers. The rild is probably trying to open 20 and our kernel defines it as 21. That's what I can tell from what I've been researching.
[T-Mobile LG G2x] Mazout360:
Naberus in his ts0710 branch uses 20 for N_TS0710 ldisc, and it shows up in the list of ldisc. Have you added printks to verify where it's hanging in the tsmux code ?
[T-Mobile LG G2x] Naberus:
A little lower: https://github.com/Naberus/lge-kern.../drivers/spi/ts0710mux_mdm/ts0710_mux.c#L2028

ts0710_open_channel(0) fails. If you trace it further down the code, you'll find that ts0710_open_channel calls send_sabm, which then times out. Tracing that further down the code yeilds some of the things I've been babbling on about for the past few days, starting around here: http://xdaforums.com/showthread.php?p=36081749#post36081749 (A lot of what I'm talking about is sort of guessing, so take it with a grain of salt.)

It *does* fail at 2021 as well, but only because a separate process (not the ril) opens pts29 before the ril has successfully opened pts1. (I.e. the failure at 2021 wouldn't happen if the ril had opened pts1 properly.) In other builds, it may also fail at 2021 for the reasons you mention.

The rild in my build is CM. The LG binary ril libraries appear to open everything with ldisc 20 as all the pieces line up. (I.e. in my build, the ENODEV happens at line 2028, rather than line 2021 in the source link posted above.)

(In my -ts0710 branch, I'm defining N_TS0710 as 20: https://github.com/Naberus/lge-kernel-star/blob/jellybean-ts0710/include/linux/tty.h)
[T-Mobile LG G2x] Mazout360:
At this point, dlci returns 1 and ipc_tty returns -807518208...is this normal ?
[T-Mobile LG G2x] Naberus:
It's just a pointer to an address in memory. I should have done %x rather than %d, but I really only needed to see that it wasn't null.
[T-Mobile LG G2x] Mazout360:
So...there's a problem with ts0710_open_channel, which goes back to the SABM timeout returning -ENODEV...

I did some research on this and the only thing I found is somebody else who had this issue with a ts0710 modem which was caused by the device not opening the channels fast enough after boot up...It was not quite clear why it did that though.
[T-Mobile LG G2x] Naberus:
The SABM timeout is because the message is either not successfully transmitted or the response is not successfully received over the SPIs.

In my -ts0710 branch, you can see a bunch of debug/printk output that follows the SABM message attempting to go out to the mdm6600 through the tegra slave, but I'm not sure how far it actually gets. I've traced it down to where the kernel initiates a DMA transfer to the slave SPI, but I can't trace it down any further.

Encouragingly, I do see an MRDY IRQ handler, which means (maybe*) that the master sees the tegra slave assert the slave ready GPIO ("SRDY") to which it responds by asserting the master ready GPIO ("MRDY"). The exact sequence of what's supposed to happen between the two is where I'm stuck learning to read the damned NvOdm stuff. :)

*maybe = there are a bunch of different contexts for SRDY, so it's totally possible the master/slaves aren't doing what I think.... Or if I have my [MS]RDY GPIO pins wrong, maybe I'm really just hooking the driver up to who knows what signal which just happens to trigger a response.
[T-Mobile LG G2x] Mazout360:
That's quite possible.

Another thing that I noticed is the lack of tegra platform-specific GPIO settings in the spi_mdm6600.h file. In every device you will see power on/reset/wake or other GPIO references there...and in this case you only have the wake GPIO for an OMAP device. I don't think this is normal.
[T-Mobile LG G2x] apolkosnik:
There are some diagrams exposing the GPIOs for instance see page 167 in

http://www.scribd.com/doc/77272596/LG-P999-P999DW-T-Mobile-G2x-Service-Manual
[T-Mobile LG G2x] xBIGREDDx:
Those three connections (MDM_RESET_1.8V, MDM_PWRON_1.8V, MDM_RESET_FLAG) are listed in gpio-names.h as:

#define TEGRA_GPIO_PV0	168
#define TEGRA_GPIO_PV1	169
#define TEGRA_GPIO_PV3	171

(Although that manual has already sort of proven it can't be trusted.)

Meanwhile ifx_n721_spi.h in the GB source (which spi_mdm6600.h is derived from) has:

#define MODEM_GPIO_AUDIO	95
#define MODEM_GPIO_RESET	103
#define MODEM_GPIO_PWRON	110

EDIT: Also, @Naberus, you were talking about the ifx_spi_sync_data function earlier, and i noticed the half_buffer is being filled by mspi_curr_dma_data_len which is a variable, whereas in the GB code hf_buffer was just set by the constants. Have you tried just setting half_buffer to MSPI_DEF_BUFF_SIZE/2 ?
[T-Mobile LG G2x] Naberus:
Good call. That's on my list of things to check now. :)

Yes, that was the first thing I tried. I later decided that since the data was going out via the spi_slave using DMA that I should either honor the mspi_curr_dma_data_len variable or drop it entirely... So I compromised. I set both the MSPI_(DEF|MAX)_BUFF_SIZE to the value from GB so the value would always be set to MSPI_DEF_MAX_BUF SIZE.

The variable is set to MSPI_DEF_BUFF_LEN elsewhere in the code anyway, so they should be the same..
[T-Mobile LG G2x] Mazout360:
Same here :p

but I don't think these definitions are handled by the kernel, since there's no reference to the variables defined for the gpio settings in GB elsewhere in the code...so I'm not sure what to do about that...

Is a Tx/Rx buffer of 30680 normal? (max_buf * 10)

Oh also, @naberus Did you get a probe for two SPI devices in your logcats or did you get one probe and one error status? We should also concentrate on finding out if the TS modem can correctly send data on the SPI bus as RC mentioned.
[T-Mobile LG G2x] Mazout360:
..and that is why pastebin is not a reliable reference lol :p

We already know that the p999 uses a mdm6600 spi and the dual spi functionality is required by looking at the GB kernel code. Watch out because here you have the modem config for KoreanBSSQ models which uses the same spi as the p999. We are already working with the newer p990 sources, not the su660.
[T-Mobile LG G2x] Core Memory:
I don't want to start an argument and I am not challenging your abilities or anyone else's, I am only interested in helping.

I know that the P999 uses the mdm6600 spi because that's the Qualcomm radio/modem in it versus the Infineon radio/modem in the P990. In fact, I have posted a lot of technical information on XDA about the mdm6600 which others have referenced and used. Also, that P999DW service manual adampk referenced on Scribd.com at http://www.scribd.com/doc/77272596/LG-P999-P999DW-T-Mobile-G2x-Service-Manual was uploaded by me under another pseudonym I use, Grim Reaper, on forums and sites such as that one OSX86, etc. It may be useful to compare the information in it with the information in the P990 service manual which can be obtained from http://depositfiles.com/files/p8q50ilu0

I don't understand your statement "Watch out because here you have the modem config for KoreanBSSQ models which uses the same spi as the p999." If that's the modem config for the "KoreanBSSQ model which uses the same spi as the p999", then why isn't it relevant? Wouldn't it be more relevant than the P990?

The pastebin indicates that there's a conflict between which setup is relevant. If SPI isn't setup correctly that would possibly result in no communication and cause a timeout wouldn't it? Also, do you trust LG to not purposely screw up the ICS code to mislead anyone who wants to port it to the P999 or is LG's programmer just incompetent? It also doesn't help that the OEM driver source code is secret and the available Android source code is such a mess to the point that it turns Open Source into a farce. It's more than enough to drive one totally crazy.
[T-Mobile LG G2x] Mazout360:
Sorry I must have expressed myself badly. I do not want to start an argument either and I do not question your implication in our community. In fact the service manual on scribd has been very useful :p

The BSSQ drivers are sightly different from the ones we use. EDIT: Damn wow...hey Naberus the BSSQ drivers from the newer sources already have dual spi functionalities implemented...I just noticed it..now it becomes more interesting, yet it requires some modifications to fit the newer kernel. So...LG did use the wrong MDM driver for the p999, amazing (and not surprising at the same time).

Our setup *should* be okay. The problem with this pastebin is that it compares the old su660 source with the p990 V30A source..and both doesn't fully support the p999. If only LG could release the source for their RIL libraries, but they would never do that. Actually, they are probably quite agains't the fact that Android is open source.
[T-Mobile LG G2x] Core Memory:
Thanks for your thoughtful reply. I am now looking at the AP20 pinouts for IPC_MRDY = N7, IFX1_AP20 = N6, IPC_SRDY = N5, IFX2_AP20 = N4 in the P990 service manual (page 135) and will compare them to the ones in the P999 service manual to determine if they're using the same pins. If they aren't, but they are in the source code, that's a possible cause of no response too.
[T-Mobile LG G2x] Mazout360:
These should be the correct pins :

IPC_MRDY1 = TEGRA_GPIO_PJ6;

IPC_SRDY1 = TEGRA_GPIO_PU6;

IPC_MRDY2 = TEGRA_GPIO_PO0;

IPC_SRDY2 = TEGRA_GPIO_PO5;

Needs confirmation

EDIT Here's the logcat using the adapted BSSQ MDM6600 driver.

Seems like it works, isn't it :p Even better, both SPIs are initialized

Also...

We used several different driver versions up to now and none of them worked on the pts nodes, maybe the problem is somewhere else now...

EDIT Updated attached with split transmission from GB.
[T-Mobile LG G2x] Core Memory:
Is this an IO error?

<4>[13:02:03 18:27:05.870] [TEGRA SLAVE SPI] : spi_tegra_abort_transfer (309 line): m->status = -5(-EIO)

If it is, what would cause that?
[T-Mobile LG G2x] Mazout360:
Yes there are errors in the slave tegra driver...but I'm in class right now I'll try to work this out without looking too uninterested and report back :p

EDIT : At first look it seems okay...it simply tells that the SPI transfer was aborted (because of the node issue again).

EDIT2: @Naberus Hey, if the RIL requests pts1, why does the logcat reports that TS0710mux tries to open channel 0 (pts0) ?
[T-Mobile LG G2x] King-Nai:
Channel 0 is the master channel as far as I can tell. It always opens it before it opens the other channels.