NOTES about msm drm/kms driver: In the current snapdragon SoC's, we have (at least) 3 differentdisplay controller blocks at play: + MDP3 - ?? seems to be what is on geeksphone peak device + MDP4 - S3 (APQ8060, touchpad), S4-pro (APQ8064, nexus4 & ifc6410) + MDP5 - snapdragon 800 (I don't have a completely clear picture on which display controllermaps to which part #) Plus a handful of blocks around them for HDMI/DSI/etc output. And on gpu side of things: + zero, one, or two 2d cores (z180) + and either a2xx or a3xx 3d core. But, HDMI/DSI/etc blocks seem like they can be shared across multipledisplay controller blocks.  And I for sure don't want to have to dealwith N different kms devices from xf86-video-freedreno.  Plus, itseems like we can do some clever tricks like use GPU to triggerpageflip after rendering completes (ie. have the kms/crtc code buildup gpu cmdstream to update scanout and write FLUSH register after). So, the approach is one drm driver, with some modularity.  Different'struct msm_kms' implementations, depending on display controller.And one or more 'struct msm_gpu' for the various different gpu sub-modules. (Second part is not implemented yet.  So far this is just basic KMSdriver, and not exposing any custom ioctls to userspace for now.) The kms module provides the plane, crtc, and encoder objects, andloads whatever connectors are appropriate. For MDP4, the mapping is:   plane   -> PIPE{RGBn,VGn}              \  crtc    -> OVLP{n} + DMA{P,S,E} (??)   |-> MDP "device"  encoder -> DTV/LCDC/DSI (within MDP4)  /  connector -> HDMI/DSI/etc              --> other device(s) Since the irq's that drm core mostly cares about are vblank/framedone,we'll let msm_mdp4_kms provide the irq install/uninstall/etc functionsand treat the MDP4 block's irq as "the" irq.  Even though the connectorsmay have their own irqs which they install themselves.  For this reasonthe display controller is the "master" device. For MDP5, the mapping is:   plane   -> PIPE{RGBn,VIGn}             \  crtc    -> LM (layer mixer)            |-> MDP "device"  encoder -> INTF                        /  connector -> HDMI/DSI/eDP/etc          --> other device(s) Unlike MDP4, it appears we can get by with a single encoder, ratherthan needing a different implementation for DTV, DSI, etc.  (Ie. theregister interface is same, just different bases.) Also unlike MDP4, with MDP5 all the IRQs for other blocks (HDMI, DSI,etc) are routed through MDP. And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), fromwhich blocks need to be allocated to the active pipes based on fetchstride. Each connector probably ends up being a separate device, just for thelogistics of finding/mapping io region, irq, etc.  Idealy we wouldhave a better way than just stashing the platform device in a global(ie. like DT super-node.. but I don't have any snapdragon hw yet thatis using DT). Note that so far I've not been able to get any docs on the hw, and itseems that access to such docs would prevent me from working on thefreedreno gallium driver.  So there may be some mistakes in registernames (I had to invent a few, since no sufficient hint was given inthe downstream android fbdev driver), bitfield sizes, etc.  My currentstate of understanding the registers is given in the envytools rnndbfiles at:   https://github.com/freedreno/envytools/tree/master/rnndb  (the mdp4/hdmi/dsi directories) These files are used both for a parser tool (in the same tree) toparse logged register reads/writes (both from downstream android fbdevdriver, and this driver with register logging enabled), as well as togenerate the register level headers.