drivers/gpu/drm/msm/NOTES

Source file repositories/reference/linux-study-clean/drivers/gpu/drm/msm/NOTES

File Facts

System
Linux kernel
Corpus path
drivers/gpu/drm/msm/NOTES
Extension
[no extension]
Size
3701 bytes
Lines
88
Domain
Driver Families
Bucket
drivers/gpu
Inferred role
Driver Families: drivers/gpu
Status
atlas-only

Why This File Exists

Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.

Dependency Surface

Detected Declarations

Annotated Snippet

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

Annotation

Implementation Notes