|
| 1 | +NOTES about msm drm/kms driver: |
| 2 | + |
| 3 | +In the current snapdragon SoC's, we have (at least) 3 different |
| 4 | +display 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 | + + MDSS - snapdragon 800 |
| 8 | + |
| 9 | +(I don't have a completely clear picture on which display controller |
| 10 | +maps to which part #) |
| 11 | + |
| 12 | +Plus a handful of blocks around them for HDMI/DSI/etc output. |
| 13 | + |
| 14 | +And on gpu side of things: |
| 15 | + + zero, one, or two 2d cores (z180) |
| 16 | + + and either a2xx or a3xx 3d core. |
| 17 | + |
| 18 | +But, HDMI/DSI/etc blocks seem like they can be shared across multiple |
| 19 | +display controller blocks. And I for sure don't want to have to deal |
| 20 | +with N different kms devices from xf86-video-freedreno. Plus, it |
| 21 | +seems like we can do some clever tricks like use GPU to trigger |
| 22 | +pageflip after rendering completes (ie. have the kms/crtc code build |
| 23 | +up gpu cmdstream to update scanout and write FLUSH register after). |
| 24 | + |
| 25 | +So, the approach is one drm driver, with some modularity. Different |
| 26 | +'struct msm_kms' implementations, depending on display controller. |
| 27 | +And one or more 'struct msm_gpu' for the various different gpu sub- |
| 28 | +modules. |
| 29 | + |
| 30 | +(Second part is not implemented yet. So far this is just basic KMS |
| 31 | +driver, and not exposing any custom ioctls to userspace for now.) |
| 32 | + |
| 33 | +The kms module provides the plane, crtc, and encoder objects, and |
| 34 | +loads whatever connectors are appropriate. |
| 35 | + |
| 36 | +For 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 | + |
| 43 | +Since the irq's that drm core mostly cares about are vblank/framedone, |
| 44 | +we'll let msm_mdp4_kms provide the irq install/uninstall/etc functions |
| 45 | +and treat the MDP4 block's irq as "the" irq. Even though the connectors |
| 46 | +may have their own irqs which they install themselves. For this reason |
| 47 | +the display controller is the "master" device. |
| 48 | + |
| 49 | +Each connector probably ends up being a separate device, just for the |
| 50 | +logistics of finding/mapping io region, irq, etc. Idealy we would |
| 51 | +have a better way than just stashing the platform device in a global |
| 52 | +(ie. like DT super-node.. but I don't have any snapdragon hw yet that |
| 53 | +is using DT). |
| 54 | + |
| 55 | +Note that so far I've not been able to get any docs on the hw, and it |
| 56 | +seems that access to such docs would prevent me from working on the |
| 57 | +freedreno gallium driver. So there may be some mistakes in register |
| 58 | +names (I had to invent a few, since no sufficient hint was given in |
| 59 | +the downstream android fbdev driver), bitfield sizes, etc. My current |
| 60 | +state of understanding the registers is given in the envytools rnndb |
| 61 | +files at: |
| 62 | + |
| 63 | + https://github.com/freedreno/envytools/tree/master/rnndb |
| 64 | + (the mdp4/hdmi/dsi directories) |
| 65 | + |
| 66 | +These files are used both for a parser tool (in the same tree) to |
| 67 | +parse logged register reads/writes (both from downstream android fbdev |
| 68 | +driver, and this driver with register logging enabled), as well as to |
| 69 | +generate the register level headers. |
0 commit comments