0001 NOTES about msm drm/kms driver:
0002
0003 In the current snapdragon SoC's, we have (at least) 3 different
0004 display controller blocks at play:
0005 + MDP3 - ?? seems to be what is on geeksphone peak device
0006 + MDP4 - S3 (APQ8060, touchpad), S4-pro (APQ8064, nexus4 & ifc6410)
0007 + MDP5 - snapdragon 800
0008
0009 (I don't have a completely clear picture on which display controller
0010 maps to which part #)
0011
0012 Plus a handful of blocks around them for HDMI/DSI/etc output.
0013
0014 And on gpu side of things:
0015 + zero, one, or two 2d cores (z180)
0016 + and either a2xx or a3xx 3d core.
0017
0018 But, HDMI/DSI/etc blocks seem like they can be shared across multiple
0019 display controller blocks. And I for sure don't want to have to deal
0020 with N different kms devices from xf86-video-freedreno. Plus, it
0021 seems like we can do some clever tricks like use GPU to trigger
0022 pageflip after rendering completes (ie. have the kms/crtc code build
0023 up gpu cmdstream to update scanout and write FLUSH register after).
0024
0025 So, the approach is one drm driver, with some modularity. Different
0026 'struct msm_kms' implementations, depending on display controller.
0027 And one or more 'struct msm_gpu' for the various different gpu sub-
0028 modules.
0029
0030 (Second part is not implemented yet. So far this is just basic KMS
0031 driver, and not exposing any custom ioctls to userspace for now.)
0032
0033 The kms module provides the plane, crtc, and encoder objects, and
0034 loads whatever connectors are appropriate.
0035
0036 For MDP4, the mapping is:
0037
0038 plane -> PIPE{RGBn,VGn} \
0039 crtc -> OVLP{n} + DMA{P,S,E} (??) |-> MDP "device"
0040 encoder -> DTV/LCDC/DSI (within MDP4) /
0041 connector -> HDMI/DSI/etc --> other device(s)
0042
0043 Since the irq's that drm core mostly cares about are vblank/framedone,
0044 we'll let msm_mdp4_kms provide the irq install/uninstall/etc functions
0045 and treat the MDP4 block's irq as "the" irq. Even though the connectors
0046 may have their own irqs which they install themselves. For this reason
0047 the display controller is the "master" device.
0048
0049 For MDP5, the mapping is:
0050
0051 plane -> PIPE{RGBn,VIGn} \
0052 crtc -> LM (layer mixer) |-> MDP "device"
0053 encoder -> INTF /
0054 connector -> HDMI/DSI/eDP/etc --> other device(s)
0055
0056 Unlike MDP4, it appears we can get by with a single encoder, rather
0057 than needing a different implementation for DTV, DSI, etc. (Ie. the
0058 register interface is same, just different bases.)
0059
0060 Also unlike MDP4, with MDP5 all the IRQs for other blocks (HDMI, DSI,
0061 etc) are routed through MDP.
0062
0063 And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
0064 which blocks need to be allocated to the active pipes based on fetch
0065 stride.
0066
0067 Each connector probably ends up being a separate device, just for the
0068 logistics of finding/mapping io region, irq, etc. Idealy we would
0069 have a better way than just stashing the platform device in a global
0070 (ie. like DT super-node.. but I don't have any snapdragon hw yet that
0071 is using DT).
0072
0073 Note that so far I've not been able to get any docs on the hw, and it
0074 seems that access to such docs would prevent me from working on the
0075 freedreno gallium driver. So there may be some mistakes in register
0076 names (I had to invent a few, since no sufficient hint was given in
0077 the downstream android fbdev driver), bitfield sizes, etc. My current
0078 state of understanding the registers is given in the envytools rnndb
0079 files at:
0080
0081 https://github.com/freedreno/envytools/tree/master/rnndb
0082 (the mdp4/hdmi/dsi directories)
0083
0084 These files are used both for a parser tool (in the same tree) to
0085 parse logged register reads/writes (both from downstream android fbdev
0086 driver, and this driver with register logging enabled), as well as to
0087 generate the register level headers.
