Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit c8afe684 authored by Rob Clark's avatar Rob Clark
Browse files

drm/msm: basic KMS driver for snapdragon 



The snapdragon chips have multiple different display controllers,
depending on which chip variant/version.  (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.

To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.

The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently.  But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge.  This
would remove the 'msm_connector' base class.  But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..

This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.

Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
parent 0cf6c71d

drivers/gpu/drm/Kconfig

+2 −0
Original line number Diff line number Diff line
@@ -223,3 +223,5 @@ source "drivers/gpu/drm/omapdrm/Kconfig" 
source "drivers/gpu/drm/tilcdc/Kconfig"



source "drivers/gpu/drm/qxl/Kconfig"



source "drivers/gpu/drm/msm/Kconfig"

drivers/gpu/drm/Makefile

+1 −0
Original line number Diff line number Diff line
@@ -54,4 +54,5 @@ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ 
obj-$(CONFIG_DRM_OMAP)	+= omapdrm/

obj-$(CONFIG_DRM_TILCDC)	+= tilcdc/

obj-$(CONFIG_DRM_QXL) += qxl/

obj-$(CONFIG_DRM_MSM) += msm/

obj-y			+= i2c/

drivers/gpu/drm/msm/Kconfig

0 → 100644
+34 −0
Original line number Diff line number Diff line 


config DRM_MSM

	tristate "MSM DRM"

	depends on DRM

	depends on ARCH_MSM

	depends on ARCH_MSM8960

	select DRM_KMS_HELPER

	select SHMEM

	select TMPFS

	default y

	help

	  DRM/KMS driver for MSM/snapdragon.



config DRM_MSM_FBDEV

	bool "Enable legacy fbdev support for MSM modesetting driver"

	depends on DRM_MSM

	select FB_SYS_FILLRECT

	select FB_SYS_COPYAREA

	select FB_SYS_IMAGEBLIT

	select FB_SYS_FOPS

	default y

	help

	  Choose this option if you have a need for the legacy fbdev

	  support. Note that this support also provide the linux console

	  support on top of the MSM modesetting driver.



config DRM_MSM_REGISTER_LOGGING

	bool "MSM DRM register logging"

	depends on DRM_MSM

	default n

	help

	  Compile in support for logging register reads/writes in a format

	  that can be parsed by envytools demsm tool.  If enabled, register

	  logging can be switched on via msm.reglog=y module param.

drivers/gpu/drm/msm/Makefile

0 → 100644
+25 −0
Original line number Diff line number Diff line 
ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/msm

ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))

	ccflags-y += -Werror

endif



msm-y := \

	hdmi/hdmi.o \

	hdmi/hdmi_connector.o \

	hdmi/hdmi_i2c.o \

	hdmi/hdmi_phy_8960.o \

	hdmi/hdmi_phy_8x60.o \

	mdp4/mdp4_crtc.o \

	mdp4/mdp4_dtv_encoder.o \

	mdp4/mdp4_format.o \

	mdp4/mdp4_irq.o \

	mdp4/mdp4_kms.o \

	mdp4/mdp4_plane.o \

	msm_connector.o \

	msm_drv.o \

	msm_fb.o \

	msm_gem.o



msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o



obj-$(CONFIG_DRM_MSM)	+= msm.o

drivers/gpu/drm/msm/NOTES

0 → 100644
+69 −0
Original line number Diff line number Diff line 
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)

 + MDSS - 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.



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.