AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-27 00:05:11 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
e6a5203399
linux_dsm_epyc7002/drivers/gpu/drm/msm/Makefile

90 lines
2.2 KiB
Makefile
Raw Normal View History

drm/msm: fix include notation and remove -Iinclude/drm flag Include <drm/*.h> instead of relative path from include/drm, then remove the -Iinclude/drm compiler flag. While we are here, sort the touched parts with public headers first. mdp4_kms.h must declare struct device_node to be self-contained. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1493009447-31524-11-git-send-email-yamada.masahiro@socionext.com
2017-04-24 11:50:28 +07:00
ccflags-y := -Idrivers/gpu/drm/msm
drm/msm/dsi: Split PHY drivers to separate files This change moves each PHY type specific code into separate files. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-08-14 04:45:52 +07:00
ccflags-$(CONFIG_DRM_MSM_DSI) += -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 23:44:06 +07: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-06 00:06:37 +07: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 23:59:32 +07: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-09 02:40:16 +07:00
adreno/a4xx_gpu.o \
drm/msm: gpu: Add A5XX target support Add support for the A5XX family of Adreno GPUs. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-29 02:28:33 +07:00
adreno/a5xx_gpu.o \
drm/msm: gpu: Add support for the GPMU Most 5XX targets have GPMU (Graphics Power Management Unit) that handles a lot of the heavy lifting for power management including thermal and limits management and dynamic power collapse. While the GPMU itself is optional, it is usually nessesary to hit aggressive power targets. The GPMU firmware needs to be loaded into the GPMU at init time via a shared hardware block of registers. Using the GPU to write the microcode is more efficient than using the CPU so at first load create an indirect buffer that can be executed during subsequent initalization sequences. After loading the GPMU gets initalized through a shared register interface and then we mostly get out of its way and let it do its thing. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-29 02:28:34 +07:00
adreno/a5xx_power.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 23:44:06 +07:00
hdmi/hdmi.o \
drm/msm: hdmi audio support Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-12 02:44:02 +07: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-31 00:02:15 +07: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 23:44:06 +07:00
hdmi/hdmi_connector.o \
hdmi/hdmi_i2c.o \
drm/msm/hdmi: Create a separate HDMI PHY driver Create a PHY device that represents the TX PHY and PLL parts of the HDMI block. This makes management of PHY specific resources (regulators and clocks) much easier, and makes the PHY and PLL usable independently. It also simplifies the core HDMI driver, which currently assigns phy ops among many other things. The PHY driver implementation done here is very similar to the PHY driver we already have for DSI. Keep the old hdmi_phy_funcs ops for now. The driver will use these until the HDMI PHY/PLL register offsets aren't considered as separate domains (i.e. their offsets start from 0). The driver doesn't use the common PHY framework for now. This is because it's hard to map our ops with the ops provided by the framework. The bindings used for this is the generic phy bindings. So, this can be adapted to the PHY framework in the future, if possible. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-02-25 12:52:38 +07:00
hdmi/hdmi_phy.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 23:44:06 +07:00
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-02 00:12:54 +07: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-08 06:47:44 +07: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-12-01 02:58:23 +07: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-12-01 05:24:22 +07: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-12-01 00:37:42 +07: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-02 00:08:11 +07: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-12-01 00:37:42 +07: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-19 00:49:48 +07: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-19 00:49:49 +07: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-12-01 05:51:47 +07:00
mdp/mdp5/mdp5_crtc.o \
mdp/mdp5/mdp5_encoder.o \
mdp/mdp5/mdp5_irq.o \
drm/msm/mdp5: Add MDSS top level driver SoCs that contain MDP5 have a top level wrapper called MDSS that manages clocks, power and irq for the sub-blocks within it. Currently, the MDSS portions are stuffed into the MDP5 driver. This makes it hard to represent the DT bindings in the correct way. We create a top level MDSS helper that handles these parts. This is essentially moving out some of the mdp5_kms irq code and MDSS register space and keeping it as a separate entity. We haven't given any clocks to the top level MDSS yet, but a AHB clock would be added in the future to access registers. One thing to note is that the resources allocated by this helper are tied to the top level platform_device (the one that allocates the drm_device struct too). This device would be the parent to MDSS sub-blocks like MDP5, DSI, eDP etc. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-08 00:41:25 +07:00
mdp/mdp5/mdp5_mdss.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-12-01 05:51:47 +07:00
mdp/mdp5/mdp5_kms.o \
drm/msm/mdp5: introduce mdp5_hw_pipe Split out the hardware pipe specifics from mdp5_plane. To start, the hw pipes are statically assigned to planes, but next step is to assign the hw pipes during plane->atomic_check() based on requested caps (scaling, YUV, etc). And then hw pipe re-assignment if required if required SMP blocks changes. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Archit Taneja <architt@codeaurora.org>
2016-11-01 20:56:51 +07:00
mdp/mdp5/mdp5_pipe.o \
drm/msm/mdp5: Add structs for hw Layer Mixers Create a struct to represent MDP5 Layer Mixer instances. This will eventually allow us to detach CRTCs from the Layer Mixers, and generally clean things up a bit. This is very similar to how hwpipes were previously abstracted away from drm planes. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-03-23 17:27:56 +07:00
mdp/mdp5/mdp5_mixer.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-12-01 05:51:47 +07:00
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-09 01:21:06 +07:00
msm_atomic.o \
drm/msm: move debugfs code to it's own file Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-03-16 23:56:12 +07:00
msm_debugfs.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 23:44:06 +07:00
msm_drv.o \
msm_fb.o \
drm/msm: move fence code to it's own file Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-03-16 02:35:08 +07:00
msm_fence.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 23:59:32 +07: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 22:28:35 +07:00
msm_gem_prime.o \
drm/msm: shrinker support For a first step, only purge obj->madv==DONTNEED objects. We could be more agressive and next try unpinning inactive objects.. but that is only useful if you have swap. Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-18 03:19:32 +07:00
msm_gem_shrinker.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 23:59:32 +07:00
msm_gem_submit.o \
drm/msm: support multiple address spaces We can have various combinations of 64b and 32b address space, ie. 64b CPU but 32b display and gpu, or 64b CPU and GPU but 32b display. So best to decouple the device iova's from mmap offset. Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-09-29 06:58:32 +07:00
msm_gem_vma.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 23:59:32 +07:00
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-17 00:56:06 +07:00
msm_iommu.o \
drm/msm: add perf logging debugfs Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-05-31 01:49:43 +07: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-31 01:47:38 +07: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 23:59:32 +07: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 23:44:06 +07:00
drm/msm: Remove local fbdev emulation Kconfig option DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the msm kms driver. Replace this with the top level DRM_FBDEV_EMULATION config option where applicable. This also prevents build breaks caused by undefined drm_fb_helper_* functions when legacy fbdev support was disabled. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-07-13 13:42:07 +07:00
msm-$(CONFIG_DRM_FBDEV_EMULATION) += 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-02 00:08:11 +07:00
msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
drm/msm/hdmi: Manage HDMI PLL through PHY driver Add a helper to initialize PLL in the PHY driver. HDMI PLLs are going to have their own mmio base different from that of PHY. For the clock code in hdmi_phy_8960.c, some changes were needed for it to work with the updated register offsets. Create a copy of the updated clock code in hdmi_pll_8960.c, instead of rewriting it in hdmi_phy_8960.c itself. This removes the need to place CONFIG_COMMON_CLOCK checks all around, makes the code more legible, and also removes some old checkpatch warnings with the original code. The older hdmi pll clock ops in hdmi_phy_8960.c will be removed later. The driver will use these until the HDMI PHY/PLL register offsets aren't considered as separate domains (i.e. their offsets start from 0). Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-02-25 12:52:39 +07:00
msm-$(CONFIG_COMMON_CLK) += hdmi/hdmi_pll_8960.o
drm/msm/hdmi: HDMI 8996 PHY/PLL support Add support for the HDMI PHY/PLL found in MSM8996/APQ8096. Unlike the previous PHYs supported in the driver, this doesn't need the powerup/powerdown ops. The PLL prepare/unprepare clock ops enable/disable the phy itself. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-02-25 12:52:44 +07:00
msm-$(CONFIG_COMMON_CLK) += hdmi/hdmi_phy_8996.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-16 00:04:04 +07:00
drm/msm: make HDCP support optional It is already optional at runtime. But this at least simplifies backports to kernels without QCOM_SCM. Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-03-20 21:16:29 +07:00
msm-$(CONFIG_DRM_MSM_HDMI_HDCP) += hdmi/hdmi_hdcp.o
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-04-01 01:36:33 +07:00
msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
drm/msm/dsi: Add a mdp4 encoder for DSI Create an mdp4 incoder for DSI. Only DSI video mode is supported as of now. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Vinay Simha BN <vinaysimha@inforcecomputing.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-19 13:57:11 +07:00
mdp/mdp4/mdp4_dsi_encoder.o \
drm/msm/dsi: Introduce DSI configuration module With more platforms supported, the DSI host configuration array keeps expanding. This change moves those to a separate dsi_cfg module. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-08-14 04:49:29 +07:00
dsi/dsi_cfg.o \
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-04-01 01:36:33 +07:00
dsi/dsi_host.o \
dsi/dsi_manager.o \
drm/msm/dsi: Split PHY drivers to separate files This change moves each PHY type specific code into separate files. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-08-14 04:45:52 +07:00
dsi/phy/dsi_phy.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-27 06:25:17 +07:00
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 23:44:06 +07:00
drm/msm/dsi: Make each PHY type compilation independent On a certain platform, only one type of DSI PHY is used. This change allows the user to only compile the PHY type which is being used. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-08-14 04:45:53 +07:00
msm-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += dsi/phy/dsi_phy_28nm.o
msm-$(CONFIG_DRM_MSM_DSI_20NM_PHY) += dsi/phy/dsi_phy_20nm.o
drm/msm/dsi: Add support for 28nm PHY on 8960 DSI PHY on MSM8960 and APQ8064 is a 28nm PHY that's different from the supported 28nm LP PHY found in newer chips. Add support for the new PHY. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-14 13:30:34 +07:00
msm-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += dsi/phy/dsi_phy_28nm_8960.o
drm/msm/dsi: Add PHY/PLL for 8x96 Extend the DSI PHY/PLL drivers to support the DSI 14nm PHY/PLL found on 8x96. These are picked up from the downstream driver. The PHY part is similar to the other DSI PHYs. The PLL driver requires some trickery so that one DSI PLL can drive both the DSIs (i.e, dual DSI mode). In the case of dual DSI mode. One DSI instance becomes the clock master, and other the clock slave. The master PLL's output (Byte and Pixel clock) is fed to both the DSI hosts/PHYs. When the DSIs are configured in dual DSI mode, the PHY driver communicates to the PLL driver using msm_dsi_pll_set_usecase() which instance is the master and which one is the slave. When setting rate, the master PLL also configures some of the slave PLL/PHY registers which need to be identical to the master's for correct dual DSI behaviour. There are 2 PLL post dividers that should have ideally been modelled as generic clk_divider clocks, but require some customization for dual DSI. In particular, when the master PLL's post-diviers are set, the slave PLL's post-dividers need to be set too. The clk_ops for these use clk_divider's helper ops and flags internally to prevent redundant code. Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-01-03 21:15:43 +07:00
msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += dsi/phy/dsi_phy_14nm.o
drm/msm/dsi: Make each PHY type compilation independent On a certain platform, only one type of DSI PHY is used. This change allows the user to only compile the PHY type which is being used. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-08-14 04:45:53 +07:00
ifeq ($(CONFIG_DRM_MSM_DSI_PLL),y)
msm-y += dsi/pll/dsi_pll.o
msm-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += dsi/pll/dsi_pll_28nm.o
drm/msm/dsi: Add DSI PLL for 28nm 8960 PHY Add DSI PLL common clock framework clocks for 8960 PHY. The PLL here is different from the ones found in B family msm chips. As before, the DSI provides two clocks to the outside world. dsixpll and dsixpllbyte (x = 1, 2). dsixpll is a regular clock divider, but dsixpllbyte is modelled as a custom clock divider. dsixpllbyte is the starting point of the PLL configuration. It is the one that sets up the VCO clock rate. We need the VCO clock rate in the form: F * byteclk, where F is a multiplication factor that varies on the byte clock the DSI driver is trying to set. We use the custom clk_ops for dsixpllbyte to ensure that the parent (VCO) is set at this rate. An additional divider (POSTDIV1) generates the bitclk. Since bit clock can be derived from byteclock, we calculate it internally, and don't expose it as a clock. Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-14 13:33:44 +07:00
msm-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += dsi/pll/dsi_pll_28nm_8960.o
drm/msm/dsi: Add PHY/PLL for 8x96 Extend the DSI PHY/PLL drivers to support the DSI 14nm PHY/PLL found on 8x96. These are picked up from the downstream driver. The PHY part is similar to the other DSI PHYs. The PLL driver requires some trickery so that one DSI PLL can drive both the DSIs (i.e, dual DSI mode). In the case of dual DSI mode. One DSI instance becomes the clock master, and other the clock slave. The master PLL's output (Byte and Pixel clock) is fed to both the DSI hosts/PHYs. When the DSIs are configured in dual DSI mode, the PHY driver communicates to the PLL driver using msm_dsi_pll_set_usecase() which instance is the master and which one is the slave. When setting rate, the master PLL also configures some of the slave PLL/PHY registers which need to be identical to the master's for correct dual DSI behaviour. There are 2 PLL post dividers that should have ideally been modelled as generic clk_divider clocks, but require some customization for dual DSI. In particular, when the master PLL's post-diviers are set, the slave PLL's post-dividers need to be set too. The clk_ops for these use clk_divider's helper ops and flags internally to prevent redundant code. Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-01-03 21:15:43 +07:00
msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += dsi/pll/dsi_pll_14nm.o
drm/msm/dsi: Make each PHY type compilation independent On a certain platform, only one type of DSI PHY is used. This change allows the user to only compile the PHY type which is being used. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-08-14 04:45:53 +07:00
endif
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-16 00:04:04 +07:00
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 23:44:06 +07:00
obj-$(CONFIG_DRM_MSM) += msm.o
Reference in New Issue Copy Permalink