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