[Nexus 10 Accessories] 8008Hacker:
After not seeing any interesting signals on the pogo pins a few weeks ago, I decided to look at the software. The kernel file ".../arch/arm/mach-exynos/board-manta-pogo.c" gives a lot of clues about the pogo connector. This post has some of my initial findings. I have to preface this rather long post by saying that although I've done embedded h/w and s/w for decades, I've never done an embedded Linux system and my knowledge of the Exynos gpio came from a few hours with the 911 page Exynos 4412 User's Manual. Please feel free to critique/correct anything said here.

The good news is that the code defines much of what the dock can do. It is more complex than I would have thought. Obviously the code doesn't define how the gpio connects to the pogo pins. Looks like some may connect directly, but others go through external logic, like the audio MUX mentioned below.

Here is an overview of the dock interface:

- The dock circuitry triggers an interrupt during docking/undocking. The interrupt triggers software debouncing of a gpio input to determine the dock state: UNDOCKED, UNSTABLE, DOCKED.

- I couldn't find an ADC input. This means that its unlikely that an external resistor can set various doc states based its value as others have postulated.

- The N10 uses one pin for a bi-directional data interface. It uses a non-standard protocol that bit-bangs MFM-encoded short command-response messages. When the dock is "acquired" (i.e., connected with stable signals), it sends an ID address and DOCK_VERSION constants. This probably tells the dock which features are supported by the device. Looks like the N10 can tell if its a Samsung dock based on the response message. Haven't followed the trail to find out other command functions.

- The audio interface is SPDIF, not analog or USB as others have predicted. Makes good sense as SPDIF requires only one pin. The reason that I didn't see SPDIF when I scoped the pogo pins is that the audio gets turned on and off. One other wrinkle: the audio pin is being multiplexed with another function. The mux logic looks like it's external to the cpu.

- The code sets the power status to one of four states: NONE, 500MA, 1A, and 2A.

- The code has several interfaces to the USB interface. For example, it controls power to the vbus line.

Suggests that it might support OTG on the dock.

Based on this, here is a SWAG on what the pin-out might be. We know we've got 2 ground and 1 charging pin. Let's assume that pin 2 is the interrupt pin. The two remaining pins might be multiplexed: in one state, the pins are the proprietary command interface and the SPDIF out; in the other state they are the USB d pins.

I'll continue reading the code to refine what I've seen. It would be great if some of the kernel devs could jump in and confirm some of this. I'm not comfortable in this environment yet. If I were, I'd be running the code under the debugger to see what happens when pin 2 is stimulated. ;)

To me the data interface is the most exciting. The protocol should be hackable to extend the command set for use with custom docks. Want the docked N10 to turn on the table lamp when the alarm goes off? No problem. I'm sure that there are lots of ways that this could be used. Open source docks maybe?