[Hardware Hacking General] thebeerbaron:
Certainly happy to explain as much as I can... let's see:

I got the term "pogo pins" from this thread. They are three tiny pins on the side of the Galaxy Nexus. They allow for car and desktop docks. They provide charging through the outermost pins and a digital signal of some kind (don't care about that one for this project) on the center.

I've simply assumed from the kernel messages and from screwing around via the i2c bus (as explained before). It may not be there, it may be something completely different, but from the software side, it behaves exactly like I'd expect the 9480 to...

Yes, I glossed over that fact. Expansion: We've got a USB accessory that we would prefer to never disconnect from the phone. Since even having just the OTG cable connected drains the battery, our app is already managing power by binding/unbinding the fsa9480 driver. When unbound, the driver leaves the phone pins in (afaik) a floating state and the accessory/OTG cable does not draw current. When we want to poll the accessory, our app binds the fsa9480 driver, which results in the USB system seeing the OTG cable and connecting everything up nicely. When it's done, it unbinds the driver again and saves battery.

Since we don't want to/can't disconnect the accessory from the micro usb port, charging is an issue. So we'd like to charge the phone via the side pins (what I perhaps erroneously called the "pogo pins"). Since we're only polling for short periods, we'd like to be able to switch from USB host mode to charging mode during the period in which we are not accessing the device.

Now, I had forgotten that dedicated chargers short D+/D-. My hope was that by controlling the fsa9480, I could connect the +5V and GND pins to the battery and charge the phone, while keeping the USB accessory offline. I'm afraid I'm so tired and burnt out this may not be making sense, so please tell me what's confusing!

Sure! Where to start...

OK, so based on Adam's thread "Build Your Own Music Dock", linked above, I grabbed the spec sheet for the fsa9280a, which he claims is "functionally the same" as the 9480.

As you can see in the datasheet, the chip is controlled via the i2c bus. Looking at the file layout of the Nexus, I figured out the address of the chip on the bus and started plugging in commands outlined in the datasheet.

for example, setting the "Manual Switch 1" register on my Nexus is done by the command

i2cset 4 37 19 <your value>

(4 being the bus where the chip is located, 37 (0x25) being the address of the device, and 19 (0x13) being the address of the register)

The datasheet outlines all the register addresses, default values, values under certain conditions, etc. I assured myself that the datasheet was valid and I was communicating with the device I thought I was by setting and observing registers.

That "Manual Switch 1" register controls where the different wires are connected and is very important to me, as far as I know.

this is the block diagram from the spec sheet in Adam's thread above. I should have linked directly to the spec sheet, sorry.

And this is the register description from the same document

So... let's simplify my goals and say that I want to charge the phone from the micro usb port without connecting the USB host device (USB HS in the block diagram) to the micro USB connector: I'd want DP_CON and DM_CON floating and Vbus_in (on the micro connector) connected to Vbus_out (on the blue CHARGER IC in the upper left). I set the proper registers to do that, and things "should just work", right? (this is assuming I do things like initing the device, etc in the proper order, which I think I am)

They don't. Because I'm confident that the proper registers are set on the FSA, I'm assuming that the internal connections are all as I expect. Thus, my suspicion is that I need to do something more to get Android to start charging off the current coming in through Vbus_in...

Oh, and before I forget: unless I unbind/unload the driver for the FSA9480, I can't write to its address via the i2c tools because the driver already owns that address. I think of this driver as a kernel module, maybe that's incorrect or imprecise. Apologies.

I hope the block diagram cleared this up. I too was confused by the Vbus_in/Vbus_out thing. I really should have linked that datasheet.

Agreed.

With that massive clarification, does that help? I'm starting to think this is something hovering right at the intersection of hardware and software. Maybe it's time I looked at writing my own device driver, or expanding the existing one?