[EVO 4G Android Development] halfline:
Hey guys,

Over the last few days, I've been reading through the code and just trying to understand how it all works.

I think I've got some pretty good guesses on how the panel interacts with the video hardware now, so I thought I'd share. Some of you probably already know this stuff, so if I'm getting anything wrong, please tell me. Note this whole post is pretty much 100% guesses, so take it all with salt.

The phone uses a "Mobile Station Modem" (msm) chipset which is this specialized chipset made for hand held devices that provides a grab bag of features.

This chipset seems to be what drives access to the various features of the phone (video, cameras, gps, etc). The chipset can be used in a variety of phones and things, so it provides some features that aren't relevant or wired up to the evo 4g.

Inside msm_fb.h there's a list of the output interfaces:

enum {

MSM_MDDI_PMDH_INTERFACE = 0,

MSM_MDDI_EMDH_INTERFACE,

MSM_EBI2_INTERFACE,

MSM_LCDC_INTERFACE,

MSM_TV_INTERFACE,

MSM_MDP_NUM_INTERFACES = MSM_TV_INTERFACE + 1

};

In reverse order, I'm guessing this translates to, "old school tv out", "typical digital video output (for LCDs and other digital outputs)", "memory i/o (unrelated to video? or maybe for driving 'dumb framebuffers'?)", "External mobile display via mddi", "primary mobile display via mddi".

mddi is apparently "Mobile Display Digital Interface" which is some new way to connect lcd panels to the video hardware using less wires than more typical digital video outputs. I guess a usecase for mddi would be a flip phone, where the big screen would take the primary interface, and the little viewfinder screen you use when the phone is closed would be driven via the external interface.

Apparently, the HDMI port on the EVO is hooked up to the LCDC interface (where on other android phones, the LCDC interface is used for the screen). So that leaves the two mddi interfaces left. Which one of the mddi interfaces does driver use for the main display? Unsurprisingly, it seems to use the "primary interface" aka mddi0

Note this code in board-supersonic-panel.c:

if (panel_type == 0) {

mddi_pdata.power_client = mddi_epson_power;

} else {

mddi_pdata.power_client = mddi_novatec_power;

}

msm_device_mddi0.dev.platform_data = &mddi_pdata;

and this code in devices.c:

static struct resource resources_mddi0[] = {

...

.start = MSM_PMDH_PHYS;

...

}

struct platform_device msm_device_mddi0 = {

...

.resource = resources_mddi0

...

}

Okay, so now we know the panel talks to the graphics hardware via mddi. But, how is the image data transferred? Apparently, there are two possible DMA channels. The "primary" dma channel and the "secondary" dma channel. I think these channels are closely tied with the interface the panel is hooked up to. i.e. the panel uses the primary interface, so it would use the primary dma channel. I'm not 100% sure though. It might be that either channel is okay. I suspect the former is true, though, because at some point the epson panels weren't working when they were trying to use the secondary dma channel and Joe Hansche made them work by forcing them to use the primary channel (among other changes).

There is a little mystery here, though. mdp_probe has this:

if (pdata == NULL || pdata->dma_channel == MDP_DMA_P) {

ret = mdp_out_if_register(&mdp->mdp_dev,

MSM_MDDI_PMDH_INTERFACE, mdp, MDP_DMA_P_DONE,

mdp_dma_to_mddi);

} else if (pdata->dma_channel == MDP_DMA_S) {

ret = mdp_out_if_register(&mdp->mdp_dev,

MSM_MDDI_PMDH_INTERFACE, mdp, MDP_DMA_S_DONE,

mdp_dmas_to_mddi);

}

The else half of that code says something like:

if we've found a panel in our devices database that is configured to use the secondary dma channel, then link the primary interface up to the secondary dma channel code.

As the code stands now, there is no panel in the devices database configured for the secondary dma channel, so that else clause will never run, afaict. Anyway the driver is at least structured to allow the primary interface to use the secondary dma channel. It just might not work in practice.

The driver looks incomplete for handling the external interfaces. It hardcodes using the primary interface. That's okay though, since the evo4g apparently doesn't use that interface (since it's not a clamshell phone with a viewfinder display i guess).