1NOTES about msm drm/kms driver: 2 3In the current snapdragon SoC's, we have (at least) 3 different 4display controller blocks at play: 5 + MDP3 - ?? seems to be what is on geeksphone peak device 6 + MDP4 - S3 (APQ8060, touchpad), S4-pro (APQ8064, nexus4 & ifc6410) 7 + MDP5 - snapdragon 800 8 9(I don't have a completely clear picture on which display controller 10maps to which part #) 11 12Plus a handful of blocks around them for HDMI/DSI/etc output. 13 14And on gpu side of things: 15 + zero, one, or two 2d cores (z180) 16 + and either a2xx or a3xx 3d core. 17 18But, HDMI/DSI/etc blocks seem like they can be shared across multiple 19display controller blocks. And I for sure don't want to have to deal 20with N different kms devices from xf86-video-freedreno. Plus, it 21seems like we can do some clever tricks like use GPU to trigger 22pageflip after rendering completes (ie. have the kms/crtc code build 23up gpu cmdstream to update scanout and write FLUSH register after). 24 25So, the approach is one drm driver, with some modularity. Different 26'struct msm_kms' implementations, depending on display controller. 27And one or more 'struct msm_gpu' for the various different gpu sub- 28modules. 29 30(Second part is not implemented yet. So far this is just basic KMS 31driver, and not exposing any custom ioctls to userspace for now.) 32 33The kms module provides the plane, crtc, and encoder objects, and 34loads whatever connectors are appropriate. 35 36For MDP4, the mapping is: 37 38 plane -> PIPE{RGBn,VGn} \ 39 crtc -> OVLP{n} + DMA{P,S,E} (??) |-> MDP "device" 40 encoder -> DTV/LCDC/DSI (within MDP4) / 41 connector -> HDMI/DSI/etc --> other device(s) 42 43Since the irq's that drm core mostly cares about are vblank/framedone, 44we'll let msm_mdp4_kms provide the irq install/uninstall/etc functions 45and treat the MDP4 block's irq as "the" irq. Even though the connectors 46may have their own irqs which they install themselves. For this reason 47the display controller is the "master" device. 48 49For MDP5, the mapping is: 50 51 plane -> PIPE{RGBn,VIGn} \ 52 crtc -> LM (layer mixer) |-> MDP "device" 53 encoder -> INTF / 54 connector -> HDMI/DSI/eDP/etc --> other device(s) 55 56Unlike MDP4, it appears we can get by with a single encoder, rather 57than needing a different implementation for DTV, DSI, etc. (Ie. the 58register interface is same, just different bases.) 59 60Also unlike MDP4, with MDP5 all the IRQs for other blocks (HDMI, DSI, 61etc) are routed through MDP. 62 63And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from 64which blocks need to be allocated to the active pipes based on fetch 65stride. 66 67Each connector probably ends up being a separate device, just for the 68logistics of finding/mapping io region, irq, etc. Idealy we would 69have a better way than just stashing the platform device in a global 70(ie. like DT super-node.. but I don't have any snapdragon hw yet that 71is using DT). 72 73Note that so far I've not been able to get any docs on the hw, and it 74seems that access to such docs would prevent me from working on the 75freedreno gallium driver. So there may be some mistakes in register 76names (I had to invent a few, since no sufficient hint was given in 77the downstream android fbdev driver), bitfield sizes, etc. My current 78state of understanding the registers is given in the envytools rnndb 79files at: 80 81 https://github.com/freedreno/envytools/tree/master/rnndb 82 (the mdp4/hdmi/dsi directories) 83 84These files are used both for a parser tool (in the same tree) to 85parse logged register reads/writes (both from downstream android fbdev 86driver, and this driver with register logging enabled), as well as to 87generate the register level headers. 88