mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
87 lines
3.6 KiB
87 lines
3.6 KiB
NOTES about msm drm/kms driver: |
|
|
|
In the current snapdragon SoC's, we have (at least) 3 different |
|
display controller blocks at play: |
|
+ MDP3 - ?? seems to be what is on geeksphone peak device |
|
+ MDP4 - S3 (APQ8060, touchpad), S4-pro (APQ8064, nexus4 & ifc6410) |
|
+ MDP5 - snapdragon 800 |
|
|
|
(I don't have a completely clear picture on which display controller |
|
maps to which part #) |
|
|
|
Plus a handful of blocks around them for HDMI/DSI/etc output. |
|
|
|
And on gpu side of things: |
|
+ zero, one, or two 2d cores (z180) |
|
+ and either a2xx or a3xx 3d core. |
|
|
|
But, HDMI/DSI/etc blocks seem like they can be shared across multiple |
|
display controller blocks. And I for sure don't want to have to deal |
|
with N different kms devices from xf86-video-freedreno. Plus, it |
|
seems like we can do some clever tricks like use GPU to trigger |
|
pageflip after rendering completes (ie. have the kms/crtc code build |
|
up gpu cmdstream to update scanout and write FLUSH register after). |
|
|
|
So, the approach is one drm driver, with some modularity. Different |
|
'struct msm_kms' implementations, depending on display controller. |
|
And one or more 'struct msm_gpu' for the various different gpu sub- |
|
modules. |
|
|
|
(Second part is not implemented yet. So far this is just basic KMS |
|
driver, and not exposing any custom ioctls to userspace for now.) |
|
|
|
The kms module provides the plane, crtc, and encoder objects, and |
|
loads whatever connectors are appropriate. |
|
|
|
For MDP4, the mapping is: |
|
|
|
plane -> PIPE{RGBn,VGn} \ |
|
crtc -> OVLP{n} + DMA{P,S,E} (??) |-> MDP "device" |
|
encoder -> DTV/LCDC/DSI (within MDP4) / |
|
connector -> HDMI/DSI/etc --> other device(s) |
|
|
|
Since the irq's that drm core mostly cares about are vblank/framedone, |
|
we'll let msm_mdp4_kms provide the irq install/uninstall/etc functions |
|
and treat the MDP4 block's irq as "the" irq. Even though the connectors |
|
may have their own irqs which they install themselves. For this reason |
|
the display controller is the "master" device. |
|
|
|
For MDP5, the mapping is: |
|
|
|
plane -> PIPE{RGBn,VIGn} \ |
|
crtc -> LM (layer mixer) |-> MDP "device" |
|
encoder -> INTF / |
|
connector -> HDMI/DSI/eDP/etc --> other device(s) |
|
|
|
Unlike MDP4, it appears we can get by with a single encoder, rather |
|
than needing a different implementation for DTV, DSI, etc. (Ie. the |
|
register interface is same, just different bases.) |
|
|
|
Also unlike MDP4, with MDP5 all the IRQs for other blocks (HDMI, DSI, |
|
etc) are routed through MDP. |
|
|
|
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from |
|
which blocks need to be allocated to the active pipes based on fetch |
|
stride. |
|
|
|
Each connector probably ends up being a separate device, just for the |
|
logistics of finding/mapping io region, irq, etc. Idealy we would |
|
have a better way than just stashing the platform device in a global |
|
(ie. like DT super-node.. but I don't have any snapdragon hw yet that |
|
is using DT). |
|
|
|
Note that so far I've not been able to get any docs on the hw, and it |
|
seems that access to such docs would prevent me from working on the |
|
freedreno gallium driver. So there may be some mistakes in register |
|
names (I had to invent a few, since no sufficient hint was given in |
|
the downstream android fbdev driver), bitfield sizes, etc. My current |
|
state of understanding the registers is given in the envytools rnndb |
|
files at: |
|
|
|
https://github.com/freedreno/envytools/tree/master/rnndb |
|
(the mdp4/hdmi/dsi directories) |
|
|
|
These files are used both for a parser tool (in the same tree) to |
|
parse logged register reads/writes (both from downstream android fbdev |
|
driver, and this driver with register logging enabled), as well as to |
|
generate the register level headers.
|
|
|