leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity
13351cd177
linux/drivers/gpu/drm/msm/Makefile

66 lines
1.4 KiB
Makefile
Raw Normal View History

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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/msm
drm/msm/dsi: Add DSI PLL clock driver support DSI byte clock and pixel clocks are sourced from DSI PLL. This change adds the DSI PLL source clock driver under common clock framework. This change handles DSI 28nm PLL only. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Wentao Xu <wentaox@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-05-15 17:04:04 +00:00
ccflags-$(CONFIG_DRM_MSM_DSI_PLL) += -Idrivers/gpu/drm/msm/dsi
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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
msm-y := \
drm/msm/adreno: split adreno device out into it's own file We'd rather not duplicate these parts as support for additional gpu generations is added. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-09-05 17:06:37 +00:00
adreno/adreno_device.o \
drm/msm: add a3xx gpu support Add initial support for a3xx 3d core. So far, with hardware that I've seen to date, we can have: + zero, one, or two z180 2d cores + a3xx or a2xx 3d core, which share a common CP (the firmware for the CP seems to implement some different PM4 packet types but the basics of cmdstream submission are the same) Which means that the eventual complete "class" hierarchy, once support for all past and present hw is in place, becomes: + msm_gpu + adreno_gpu + a3xx_gpu + a2xx_gpu + z180_gpu This commit splits out the parts that will eventually be common between a2xx/a3xx into adreno_gpu, and the parts that are even common to z180 into msm_gpu. Note that there is no cmdstream validation required. All memory access from the GPU is via IOMMU/MMU. So as long as you don't map silly things to the GPU, there isn't much damage that the GPU can do. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-07-19 16:59:32 +00:00
adreno/adreno_gpu.o \
adreno/a3xx_gpu.o \
drm/msm: a4xx support for msm-drm Added a4xx GPU support. Signed-off-by: Aravind Ganesan <aravindg@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-09-08 19:40:16 +00:00
adreno/a4xx_gpu.o \
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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
hdmi/hdmi.o \
drm/msm: hdmi audio support Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-11 19:44:02 +00:00
hdmi/hdmi_audio.o \
drm/msm: convert to drm_bridge Drop the msm_connector base class, and special calls to base class methods from the encoder, and use instead drm_bridge. This allows for a cleaner division between the hdmi (and in future dsi) blocks, from the mdp block. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-30 17:02:15 +00:00
hdmi/hdmi_bridge.o \
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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
hdmi/hdmi_connector.o \
drm/msm/hdmi: add hdmi hdcp support (V3) Add HDMI HDCP support including HDCP PartI/II/III authentication. V1: Initial Change V2: Address Bjorn&Rob's comments Refactor the authentication process to use single work instead of multiple work for different authentication stages. V3: Update to align with qcom SCM api. Signed-off-by: Jilai Wang <jilaiw@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-04-02 21:49:01 +00:00
hdmi/hdmi_hdcp.o \
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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
hdmi/hdmi_i2c.o \
hdmi/hdmi_phy_8960.o \
hdmi/hdmi_phy_8x60.o \
drm/msm: add hdmi support for apq8x74/mdp5 The HDMI block is basically the same between older SoC's with mdp4 display controller, and newer ones with mdp5. So mostly this consists of better abstracting out the different sets of regulators, clks, etc. In particular, for regulators and clks we can split it up by what is needed for hot plug detect to work, and what is needed to light up the display. Also, 8x74 has a new phy.. a very simple one, but split out into a different mmio space. And with mdp5, the irq is shared with mdp, so we don't directly register our own irq handler. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 17:12:54 +00:00
hdmi/hdmi_phy_8x74.o \
drm/msm: Initial add eDP support in msm drm driver (v5) This change adds a new eDP connector in msm drm driver. With this change, eDP panel can work with msm platform under drm framework. v1: Initial change v2: Address Rob's comments Use generated header file for register definitions Change to devm_* APIs v3: Address Thierry's comments and rebase on top of atomic changes Remove edp_bridge_mode_fixup Remove backlight control code and rely on pwm-backlight Remove continuous splash screen support for now Change to gpiod_* APIs v4: Fix kbuild test issue Signed-off-by: Hai Li <hali@codeaurora.org> [robclark: v5: rebase on drm_bridge changes in drm-next] Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-01-07 23:47:44 +00:00
edp/edp.o \
edp/edp_aux.o \
edp/edp_bridge.o \
edp/edp_connector.o \
edp/edp_ctrl.o \
edp/edp_phy.o \
drm/msm: mdp4_format -> mdp_format This can be shared between mdp4 and mdp5. Both use the same set of parameters to describe the format to the hw. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 19:58:23 +00:00
mdp/mdp_format.o \
drm/msm: move irq utils to mdp_kms We'll want basically the same thing for mdp5, so refactor it out so it can be shared. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:24:22 +00:00
mdp/mdp_kms.o \
drm/msm: move mdp4 -> mdp/mdp4 There are some little bits and pieces that mdp4 and mdp5 can share, so move things around so that we can have both in a common parent directory. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 17:37:42 +00:00
mdp/mdp4/mdp4_crtc.o \
mdp/mdp4/mdp4_dtv_encoder.o \
drm/msm/mdp4: add LVDS panel support LVDS panel support uses the LCDC (parallel) encoder. Unlike with HDMI, there is not a separate LVDS block, so no need to split things into a bridge+connector. Nor is there is anything re-used with mdp5. Note that there can be some regulators shared between HDMI and LVDS (in particular, on apq8064, ext_3v3p), so we should not use the _exclusive() variants of devm_regulator_get(). The drm_panel framework is used for panel-specific driver. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-08-01 17:08:11 +00:00
mdp/mdp4/mdp4_lcdc_encoder.o \
mdp/mdp4/mdp4_lvds_connector.o \
drm/msm: move mdp4 -> mdp/mdp4 There are some little bits and pieces that mdp4 and mdp5 can share, so move things around so that we can have both in a common parent directory. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 17:37:42 +00:00
mdp/mdp4/mdp4_irq.o \
mdp/mdp4/mdp4_kms.o \
mdp/mdp4/mdp4_plane.o \
drm/msm/mdp5: introduce mdp5_cfg module The hardware configuration modification from a version to another is quite consequent. Introducing a configuration module (mdp5_cfg) may make things more clear and easier to access when a new hardware version comes up. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-18 17:49:48 +00:00
mdp/mdp5/mdp5_cfg.o \
drm/msm: add multiple CRTC and overlay support MDP5 currently support one single CRTC with its private pipe. This change allows the configuration of multiple CRTCs with the possibility to attach several public planes to these CRTCs. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-18 17:49:49 +00:00
mdp/mdp5/mdp5_ctl.o \
drm/msm: add mdp5/apq8x74 Add support for the new MDP5 display controller block. The mapping between parts of the display controller and KMS 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, 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. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-30 22:51:47 +00:00
mdp/mdp5/mdp5_crtc.o \
mdp/mdp5/mdp5_encoder.o \
mdp/mdp5/mdp5_irq.o \
mdp/mdp5/mdp5_kms.o \
mdp/mdp5/mdp5_plane.o \
mdp/mdp5/mdp5_smp.o \
drm/msm: atomic core bits The core parts for async commit. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-08 18:21:06 +00:00
msm_atomic.o \
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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
msm_drv.o \
msm_fb.o \
drm/msm: add a3xx gpu support Add initial support for a3xx 3d core. So far, with hardware that I've seen to date, we can have: + zero, one, or two z180 2d cores + a3xx or a2xx 3d core, which share a common CP (the firmware for the CP seems to implement some different PM4 packet types but the basics of cmdstream submission are the same) Which means that the eventual complete "class" hierarchy, once support for all past and present hw is in place, becomes: + msm_gpu + adreno_gpu + a3xx_gpu + a2xx_gpu + z180_gpu This commit splits out the parts that will eventually be common between a2xx/a3xx into adreno_gpu, and the parts that are even common to z180 into msm_gpu. Note that there is no cmdstream validation required. All memory access from the GPU is via IOMMU/MMU. So as long as you don't map silly things to the GPU, there isn't much damage that the GPU can do. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-07-19 16:59:32 +00:00
msm_gem.o \
drm/msm: prime support Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: David Brown <davidb@codeaurora.org>
2013-09-28 15:28:35 +00:00
msm_gem_prime.o \
drm/msm: add a3xx gpu support Add initial support for a3xx 3d core. So far, with hardware that I've seen to date, we can have: + zero, one, or two z180 2d cores + a3xx or a2xx 3d core, which share a common CP (the firmware for the CP seems to implement some different PM4 packet types but the basics of cmdstream submission are the same) Which means that the eventual complete "class" hierarchy, once support for all past and present hw is in place, becomes: + msm_gpu + adreno_gpu + a3xx_gpu + a2xx_gpu + z180_gpu This commit splits out the parts that will eventually be common between a2xx/a3xx into adreno_gpu, and the parts that are even common to z180 into msm_gpu. Note that there is no cmdstream validation required. All memory access from the GPU is via IOMMU/MMU. So as long as you don't map silly things to the GPU, there isn't much damage that the GPU can do. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-07-19 16:59:32 +00:00
msm_gem_submit.o \
msm_gpu.o \
drm/msm: add support for non-IOMMU systems Add a VRAM carveout that is used for systems which do not have an IOMMU. The VRAM carveout uses CMA. The arch code must setup a CMA pool for the device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not cool). The user can configure the VRAM pool size using msm.vram module param. Technically, the abstraction of IOMMU behind msm_mmu is not strictly needed, but it simplifies the GEM code a bit, and will be useful later when I add support for a2xx devices with GPUMMU, so I decided to keep this part. It appears to be possible to configure the GPU to restrict access to addresses within the VRAM pool, but this is not done yet. So for now the GPU will refuse to load if there is no sort of mmu. Once address based limits are supported and tested to confirm that we aren't giving the GPU access to arbitrary memory, this restriction can be lifted Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-16 17:56:06 +00:00
msm_iommu.o \
drm/msm: add perf logging debugfs Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-05-30 18:49:43 +00:00
msm_perf.o \
drm/msm: add rd logging debugfs To ease debugging, add debugfs file which can be cat/tail'd to log submits, along with fence #. If GPU hangs, you can look at 'gpu' debugfs file to find last completed fence and current register state, and compare with logged rd file to narrow down the DRAW_INDX which triggered the GPU hang. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-05-30 18:47:38 +00:00
msm_rd.o \
drm/msm: add a3xx gpu support Add initial support for a3xx 3d core. So far, with hardware that I've seen to date, we can have: + zero, one, or two z180 2d cores + a3xx or a2xx 3d core, which share a common CP (the firmware for the CP seems to implement some different PM4 packet types but the basics of cmdstream submission are the same) Which means that the eventual complete "class" hierarchy, once support for all past and present hw is in place, becomes: + msm_gpu + adreno_gpu + a3xx_gpu + a2xx_gpu + z180_gpu This commit splits out the parts that will eventually be common between a2xx/a3xx into adreno_gpu, and the parts that are even common to z180 into msm_gpu. Note that there is no cmdstream validation required. All memory access from the GPU is via IOMMU/MMU. So as long as you don't map silly things to the GPU, there isn't much damage that the GPU can do. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-07-19 16:59:32 +00:00
msm_ringbuffer.o
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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
drm/msm/mdp4: add LVDS panel support LVDS panel support uses the LCDC (parallel) encoder. Unlike with HDMI, there is not a separate LVDS block, so no need to split things into a bridge+connector. Nor is there is anything re-used with mdp5. Note that there can be some regulators shared between HDMI and LVDS (in particular, on apq8064, ext_3v3p), so we should not use the _exclusive() variants of devm_regulator_get(). The drm_panel framework is used for panel-specific driver. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-08-01 17:08:11 +00:00
msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
drm/msm/dsi: Add DSI PLL clock driver support DSI byte clock and pixel clocks are sourced from DSI PLL. This change adds the DSI PLL source clock driver under common clock framework. This change handles DSI 28nm PLL only. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Wentao Xu <wentaox@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-05-15 17:04:04 +00:00
drm/msm: Initial add DSI connector support This change adds the DSI connector support in msm drm driver. v1: Initial change v2: - Address comments from Archit + minor clean-ups - Rebase to not depend on msm_drm_sub_dev change [Rob's comment] v3: Fix issues when initialization is failed Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-31 18:36:33 +00:00
msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
dsi/dsi_host.o \
dsi/dsi_manager.o \
drm/msm/mdp5: Enable DSI connector in msm drm driver This change adds the support in mdp5 kms driver for single and dual DSI. Dual DSI case depends on the framework API and sequence change to support dual data path. v1: Initial change v2: Address Rob Clark's comment - Separate command mode encoder to a new file mdp5_cmd_encoder.c - Rebase to not depend on msm_drm_sub_dev change Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-26 23:25:17 +00:00
dsi/dsi_phy.o \
mdp/mdp5/mdp5_cmd_encoder.o
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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
drm/msm/dsi: Add DSI PLL clock driver support DSI byte clock and pixel clocks are sourced from DSI PLL. This change adds the DSI PLL source clock driver under common clock framework. This change handles DSI 28nm PLL only. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Wentao Xu <wentaox@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-05-15 17:04:04 +00:00
msm-$(CONFIG_DRM_MSM_DSI_PLL) += dsi/pll/dsi_pll.o \
dsi/pll/dsi_pll_28nm.o
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: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
obj-$(CONFIG_DRM_MSM) += msm.o
Reference in New Issue Copy Permalink