88 lines
3.6 KiB
Plaintext
88 lines
3.6 KiB
Plaintext
|
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.
|