redonkable/alistair23-linux
redonkable/alistair23-linux
1
0
Fork 0
Code Releases Activity
alistair23-linux/drivers/gpu/drm/msm/Kconfig

84 lines
2.1 KiB
Plaintext
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 10:44:06 -06:00
config DRM_MSM
tristate "MSM DRM"
depends on DRM
drm/msm: update for ARCH_MSM -> ARCH_QCOM Architecture rename/split.. ARCH_QCOM is for the non-legacy platforms (ie. device-tree, multiplatform support, etc). Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-05-30 13:37:54 -06:00
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
drm: msm: add missing dependencies on OF and COMMON_CLK The msm gpu drivers depend on both the DT mechanism and the common clk handling code, if they are not enabled, we get a number of build errors: In file included from drivers/gpu/drm/msm/hdmi/hdmi.h:27:0, from drivers/gpu/drm/msm/hdmi/hdmi_bridge.c:18: drivers/gpu/drm/msm/msm_drv.h:45:24: fatal error: mach/board.h: No such file or directory #include <mach/board.h> ^ drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c:503:2: error: implicit declaration of function 'devm_clk_register' [-Werror=implicit-function-declaration] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Dave Airlie <airlied@gmail.com>
2015-01-28 06:48:09 -07:00
depends on OF && COMMON_CLK
drm: add more MMU dependencies Many DRM drivers only work with an MMU, and after the patch to enable core DRM support without MMU, we already had one fixup for many of them. The etnaviv, armada and msm drivers were missed and have the same problem: warning: (DRM_ETNAVIV) selects IOMMU_SUPPORT which has unmet direct dependencies (MMU) warning: (DRM_I915 && DRM_MSM && DRM_ETNAVIV) selects SHMEM which has unmet direct dependencies (MMU) drivers/gpu/drm/armada/armada_gem.o: In function `armada_gem_vm_fault': armada_gem.c:(.text.armada_gem_vm_fault+0x14): undefined reference to `vm_insert_pfn' arch/arm/mm/dma-mapping.c: In function '__iommu_alloc_remap': arch/arm/mm/dma-mapping.c:1390:4: error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function) arch/arm/mm/dma-mapping.c:1456:31: error: 'atomic_pool' undeclared (first use in this function); did you mean 'atomic_xor'? Fixes: 011cda589938 ("drm: fix compilations issues introduced by "drm: allow to use mmuless SoC"") Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170111133357.3664191-2-arnd@arndb.de
2017-01-11 06:33:35 -07:00
depends on MMU
drm/msm: gpu: Enable zap shader for A5XX The A5XX GPU powers on in "secure" mode. In secure mode the GPU can only render to buffers that are marked as secure and inaccessible to the kernel and user through a series of hardware protections. In practice secure mode is used to draw things like a UI on a secure video frame. In order to switch out of secure mode the GPU executes a special shader that clears out the GMEM and other sensitve registers and then writes a register. Because the kernel can't be trusted the shader binary is signed and verified and programmed by the secure world. To do this we need to read the MDT header and the segments from the firmware location and put them in memory and present them for approval. For targets without secure support there is an out: if the secure world doesn't support secure then there are no hardware protections and we can freely write the SECVID_TRUST register from the CPU. We don't have 100% confidence that we can query the secure capabilities at run time but we have enough calls that need to go right to give us some confidence that we're at least doing something useful. Of course if we guess wrong you trigger a permissions violation which usually ends up in a system crash but thats a problem that shows up immediately. [v2: use child device per Bjorn] [v3: use generic MDT loader per Bjorn] [v4: use managed dma functions and ifdefs for the MDT loader] [v5: Add depends for QCOM_MDT_LOADER] Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> [robclark: fix Kconfig to use select instead of depends + #if IS_ENABLED()] Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-05-17 08:45:29 -06:00
select QCOM_MDT_LOADER
drm/msm: select REGULATOR Fixes a potential error, spotted by Felipe with randconfig: ----- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ‘mdp4_kms_init’: drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \ of function ‘devm_regulator_get_exclusive’ [-Werror=implicit-function-declaration] mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd"); ^ drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:16: error: assignment makes \ pointer from integer without a cast [-Werror] mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd"); ^ ----- Also add a brief comment explaining the use of _get_exclusive() Reported-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-10-31 10:19:40 -06:00
select REGULATOR
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 10:44:06 -06:00
select DRM_KMS_HELPER
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 11:08:11 -06:00
select DRM_PANEL
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 10:44:06 -06:00
select SHMEM
select TMPFS
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 15:49:01 -06:00
select QCOM_SCM
drm: msm: Add ASoC generic hdmi audio codec support. This patch adds support to generic audio codec via ASoC hdmi-codec infrastucture which is merged recently. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> [rebased on efc9194] Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-06-10 03:45:56 -06:00
select SND_SOC_HDMI_CODEC if SND_SOC
drm/msm: submit support for in-fences Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-06-16 14:08:19 -06:00
select SYNC_FILE
drm/msm: select PM_OPP Otherwise, if nothing else enabled selects it, dev_pm_opp_of_add_table() will return -ENOTSUPP. Fixes: e2af8b6 ("drm/msm: gpu: Use OPP tables if we can") Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-05-02 10:39:53 -06:00
select PM_OPP
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 10:44:06 -06:00
default y
help
DRM/KMS driver for MSM/snapdragon.
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.
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 12:36:33 -06: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 08:16:29 -06:00
config DRM_MSM_HDMI_HDCP
bool "Enable HDMI HDCP support in MSM DRM driver"
depends on DRM_MSM && QCOM_SCM
default y
help
Choose this option to enable HDCP state machine
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 12:36:33 -06:00
config DRM_MSM_DSI
bool "Enable DSI support in MSM DRM driver"
depends on DRM_MSM
select DRM_PANEL
select DRM_MIPI_DSI
default y
help
Choose this option if you have a need for MIPI DSI connector
support.
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 11:04:04 -06:00
config DRM_MSM_DSI_PLL
bool "Enable DSI PLL driver in MSM DRM"
depends on DRM_MSM_DSI && COMMON_CLK
default y
help
Choose this option to enable DSI PLL driver which provides DSI
source clocks under common clock framework.
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-13 15:45:53 -06:00
config DRM_MSM_DSI_28NM_PHY
bool "Enable DSI 28nm PHY driver in MSM DRM"
depends on DRM_MSM_DSI
default y
help
Choose this option if the 28nm DSI PHY is used on the platform.
config DRM_MSM_DSI_20NM_PHY
bool "Enable DSI 20nm PHY driver in MSM DRM"
depends on DRM_MSM_DSI
default y
help
Choose this option if the 20nm DSI PHY is used on the platform.
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 00:30:34 -06:00
config DRM_MSM_DSI_28NM_8960_PHY
bool "Enable DSI 28nm 8960 PHY driver in MSM DRM"
depends on DRM_MSM_DSI
default y
help
Choose this option if the 28nm DSI PHY 8960 variant is used on the
platform.
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 07:15:43 -07:00
config DRM_MSM_DSI_14NM_PHY
bool "Enable DSI 14nm PHY driver in MSM DRM (used by MSM8996/APQ8096)"
depends on DRM_MSM_DSI
default y
help
Choose this option if DSI PHY on 8996 is used on the platform.
Copy permalink