]>
Commit | Line | Data |
---|---|---|
c8afe684 RC |
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) | |
06c0dd96 | 7 | + MDP5 - snapdragon 800 |
c8afe684 RC |
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 | ||
06c0dd96 RC |
49 | For 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 | ||
56 | Unlike MDP4, it appears we can get by with a single encoder, rather | |
57 | than needing a different implementation for DTV, DSI, etc. (Ie. the | |
58 | register interface is same, just different bases.) | |
59 | ||
60 | Also unlike MDP4, with MDP5 all the IRQs for other blocks (HDMI, DSI, | |
61 | etc) are routed through MDP. | |
62 | ||
63 | And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from | |
64 | which blocks need to be allocated to the active pipes based on fetch | |
65 | stride. | |
66 | ||
c8afe684 RC |
67 | Each connector probably ends up being a separate device, just for the |
68 | logistics of finding/mapping io region, irq, etc. Idealy we would | |
69 | have 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 | |
71 | is using DT). | |
72 | ||
73 | Note that so far I've not been able to get any docs on the hw, and it | |
74 | seems that access to such docs would prevent me from working on the | |
75 | freedreno gallium driver. So there may be some mistakes in register | |
76 | names (I had to invent a few, since no sufficient hint was given in | |
77 | the downstream android fbdev driver), bitfield sizes, etc. My current | |
78 | state of understanding the registers is given in the envytools rnndb | |
79 | files at: | |
80 | ||
81 | https://github.com/freedreno/envytools/tree/master/rnndb | |
82 | (the mdp4/hdmi/dsi directories) | |
83 | ||
84 | These files are used both for a parser tool (in the same tree) to | |
85 | parse logged register reads/writes (both from downstream android fbdev | |
86 | driver, and this driver with register logging enabled), as well as to | |
87 | generate the register level headers. |