- 01 Mar, 2016 4 commits
-
-
Marek Szyprowski authored
Drivers should use %p for printing pointers instead of hardcoding them as hexadecimal integers. This patch fixes compilation warnings on 64bit architectures. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Joonyoung Shim authored
Because PLAT_SAMSUNG isn't include exynos SoCs for arm64, but ARCH_EXYNOS can do it. And it also needs to add ARCH_S3C64XX instead of PLAT_SAMSUNG. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
- lots and lots of fbc work from Paulo - max pixel clock checks from Mika Kahola - prep work for nv12 offset handling from Ville - piles of small fixes and refactorings all around * tag 'drm-intel-next-2016-02-14' of git://anongit.freedesktop.org/drm-intel: (113 commits) drm/i915: Update DRIVER_DATE to 20160214 drm/i915: edp resume/On time optimization. agp/intel-gtt: Only register fake agp driver for gen1 drm/i915: TV pixel clock check drm/i915: CRT pixel clock check drm/i915: SDVO pixel clock check drm/i915: DisplayPort-MST pixel clock check drm/i915: HDMI pixel clock check drm/i915: DisplayPort pixel clock check drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem drm/i915: fix error path in intel_setup_gmbus() drm/i915: Stop depending upon CONFIG_AGP_INTEL agp/intel-gtt: Don't leak the scratch page drm/i915: Capture PCI revision and subsytem details in error state drm/i915: fix context/engine cleanup order drm/i915: Handle PipeC fused off on IVB/HSW/BDW drm/i915/skl: Fix typo in DPLL_CFGCR1 definition drm/i915: Skip DDI PLL selection for DSI drm/i915/skl: Explicitly check for eDP in skl_ddi_pll_select() drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select() ...
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
Here are a few amdkfd patches for 4.6. These patches defer radeon/amdgpu loading in case amdkfd is not yet loaded, by returning -EPROBE_DEFER during their probing stage. * tag 'drm-amdkfd-next-2016-02-27' of git://people.freedesktop.org/~gabbayo/linux: drm/amdgpu: Return -EPROBE_DEFER when amdkfd not loaded drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded drm/amdkfd: Track when module's init is complete
-
- 27 Feb, 2016 3 commits
-
-
Oded Gabbay authored
amdgpu must load only after amdkfd's loading has been completed. If that is not enforced, then amdgpu's call into amdkfd's functions will cause a kernel BUG. When amdgpu and amdkfd are built as kernel modules, that rule is enforced by the kernel's modules loading mechanism. When amdgpu and amdkfd are built inside the kernel image, that rule is enforced by ordering in the drm Makefile (amdkfd before amdgpu). Instead of using drm Makefile ordering, we can now use deferred loading as amdkfd now returns -EPROBE_DEFER in kgd2kfd_init() when it is not yet loaded. This patch defers amdgpu loading by propagating -EPROBE_DEFER to the kernel's drivers loading infrastructure. That will put amdgpu into the pending drivers list (see description in dd.c). Once amdkfd is loaded, a call to kgd2kfd_init() will return successfully and amdgpu will be able to load. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Oded Gabbay authored
radeon must load only after amdkfd's loading has been completed. If that is not enforced, then radeon's call into amdkfd's functions will cause a kernel BUG. When radeon and amdkfd are built as kernel modules, that rule is enforced by the kernel's modules loading mechanism. When radeon and amdkfd are built inside the kernel image, that rule is enforced by ordering in the drm Makefile (amdkfd before radeon). Instead of using drm Makefile ordering, we can now use deferred loading as amdkfd now returns -EPROBE_DEFER in kgd2kfd_init() when it is not yet loaded. This patch defers radeon loading by propagating -EPROBE_DEFER to the kernel's drivers loading infrastructure. That will put radeon into the pending drivers list (see description in dd.c). Once amdkfd is loaded, a call to kgd2kfd_init() will return successfully and radeon will be able to load. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Oded Gabbay authored
Current dependencies between amdkfd and radeon/amdgpu force the loading of amdkfd _before_ radeon and/or amdgpu are loaded. When all these kernel drivers are built as modules, this ordering is enforced by the kernel built-in mechanism of loading dependent modules. However, there is no such mechanism in case where all these drivers are compiled inside the kernel image (not as modules). The current way to enforce loading of amdkfd before radeon/amdgpu, is to put amdkfd before radeon/amdgpu in the drm Makefile, but that method is way too fragile. In addition, there is no kernel mechanism to check whether a kernel driver that is built inside the kernel image, has already been loaded. To solve this, this patch adds to kfd_module.c a new static variable, amdkfd_init_completed, that is set to 1 only when amdkfd's module initialization function has been completed (successfully). kgd2kfd_init(), which is the initialization function of the kgd-->kfd interface, and which is the first function in amdkfd called by radeon/amdgpu, will return successfully only if amdkfd_init_completed is equal 1. If amdkfd_init_completed is not equal to 1, kgd2kfd_init() will return -EPROBE_DEFER to signal radeon/amdgpu they need to defer their loading until amdkfd is loaded. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
- 26 Feb, 2016 11 commits
-
-
http://git.agner.ch/git/linux-drm-fsl-dcuDave Airlie authored
As previously discussed, this is my first pull request for the DCU DRM driver along with the change in MAINTAINERS. https://lkml.org/lkml/2016/1/7/26 The pull contains some code cleanup changes (e.g. removing all error handling for the regmap calls) and several fixes. * 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu: drm/fsl-dcu: fix register initialization drm/fsl-dcu: use mode flags for hsync/vsync polarity drm/fsl-dcu: fix alpha blending drm/fsl-dcu: mask all interrupts on initialization drm/fsl-dcu: handle initialization errors properly drm/fsl-dcu: avoid memory leak on errors drm/fsl-dcu: remove regmap return value checks drm/fsl-dcu: specify volatile registers drm: fsl-dcu: Fix no fb check bug MAINTAINERS: update for Freescale DCU DRM driver
-
Stefan Agner authored
The layer enumeration start with 0 (0-15 for LS1021a and 0-63 for Vybrid) whereas the register enumeration start from 1 (1-10 for LS1021a and 1-9 for Vybrid). The loop started off from 0 for both iterations and initialized the number of layers inclusive, which is one layer too many. All extensively written registers seem to be unassigned, it seems that the write to those registers did not do any harm in practice. Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Stefan Agner authored
The current default configuration is as follows: - Invert VSYNC signal (active LOW) - Invert HSYNC signal (active LOW) The mode flags allow to specify the required polarity per mode. Furthermore, none of the current driver settings is actually a standard polarity. This patch applies the current driver default polarities as explicit flags to the display which has been introduced with the driver (NEC WQVGA "nec,nl4827hc19-05b"). The driver now also parses the flags field and applies the configuration accordingly, by using the following values as standard polarities: (e.g. when no flags are specified): - VSYNC signal not inverted (active HIGH) - HSYNC signal not inverted (active HIGH) Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Stefan Agner authored
Fix alpha blending by enabling alpha blending for the whole frame if a color mode with alpha channel is selected (DRM_FORMAT_ARGB*). Also support color modes without alpha channel (DRM_FORMAT_XRGB*) by just not enabling alpha blending on layer level. Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Stefan Agner authored
The state of the interrupt mask register on initialization is unknown, e.g. U-Boot could already used the DCU. So depending on the boot loader, the outcome of the interrupt mask register could be different. A defined state is much more preferable. Also, there is no value in keeping interrupts enabled which we don't need. Therefor, mask all interrupts on initialization. Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Stefan Agner authored
If initialization fails (e.g. due to missing panel node or deferred probe) make sure to roll-back all operations and return the error code. Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Stefan Agner authored
Improve error handling during CRTC initialization. Especially avoid memory leaks in the primary plane initialization error path. Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Stefan Agner authored
It is not common to do regmap return value checks, especially not for memory mapped device. We can rule out most error returns since the conditions are static and we know they are ok (e.g. offset aligned to register stride). Also without proper error handling they are not really valuable for the user. Hence remove most of them. The check in the interrupt handler is worth keeping since a volatile register won't be readable in case register caching is still enabled. Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Stefan Agner authored
Since we are using cached registers, we need to specify volatile registers explicitly to avoid reading their value from the cache. This allows to read the correct interrupt status in fsl_dcu_drm_irq and clear the asserted bits only. Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Meng Yi authored
For state->fb or state->crtc may be NULL in fsl_dcu_drm_plane_atomic_check function, if so, return 0. Signed-off-by: Meng Yi <meng.yi@nxp.com> Signed-off-by: Jianwei Wang <jianwei.wang.chn@gmail.com> Signed-off-by: Stefan Agner <stefan@agner.ch>
-
Stefan Agner authored
Promote myself as new maintainer of the Freescale DCU DRM driver. Acked-by: Jianwei Wang <jianwei.wang.chn@gmail.com> Signed-off-by: Stefan Agner <stefan@agner.ch>
-
- 25 Feb, 2016 1 commit
-
-
git://linuxtv.org/pinchartl/fbdevDave Airlie authored
rcar-du updates. * 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev: (281 commits) drm: rcar-du: Add tri-planar memory formats support drm: rcar-du: Add probe deferral debug messages drm: rcar-du: lvds: Add R-Car Gen3 support drm: rcar-du: lvds: Rename PLLEN bit to PLLON drm: rcar-du: lvds: Fix PLL frequency-related configuration drm: rcar-du: lvds: Avoid duplication of clock clamp code drm: rcar-du: Add R8A7795 device support drm: rcar-du: Output the DISP signal on the ODDF pin drm: rcar-du: Output the DISP signal on the DISP pin drm: rcar-du: Support up to 4 CRTCs drm: rcar-du: Drop LVDS double dependency on OF drm: rcar-du: Enable compilation on ARM64 drm: rcar-du: Fix compile warning on 64-bit platforms drm: rcar-du: Expose the VSP1 compositor through KMS planes drm: rcar-du: Move plane allocator to rcar_du_plane.c drm: rcar-du: Restart the DU group when a plane source changes drm: rcar-du: Add VSP1 compositor support drm: rcar-du: Add VSP1 support to the planes allocator drm: rcar-du: Refactor plane setup drm: rcar-du: Compute plane DDCR4 register value directly ...
-
- 23 Feb, 2016 14 commits
-
-
Laurent Pinchart authored
Those formats are supported on Gen3 only. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
Print a message when the HDMI I2C slave encoder can't be found to help debugging probe deferral issues. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Koji Matsuoka authored
The LVDS encoder differs slightly in Gen3 SoCs in its PLL configuration. Add support for the Gen3 LVDS PLL parameters and startup procedure. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
The bit is named PLLON in the datasheet, rename it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
The frequency checks don't match the datasheet, fix them. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
Replace the duplicate code by a single central function. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
Document the R8A7795-specific DT bindings and support them in the driver. The HDMI and LVDS outputs are currently not supported. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
The ODDF signal, output by default on the ODDF pin, isn't used on any board supported in the kernel. As the Gen3 Salvator-X board uses the ODDF pin as a DISP signal, hardcode that configuration in the driver. Use of the ODDF signal will be implemented later through proper DT-based configuration of the DU pins. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
The DE signal is currently configured to be identical to the DISP signal and is used for the same purpose. To make it clearer that the DISP pin outputs the DISP signal, select it explicitly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Koji Matsuoka authored
The Gen3 R8A7795 DU has 4 CRTCs, support them all. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
LVDS support depends on DRM_RCAR_DU which already depends on OF. Drop the explicit dependency. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Koji Matsuoka authored
The R8A7795 SoC is ARM64-based and include a DU. Enable driver compilation on ARM64. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Koji Matsuoka authored
Use %tu instead of %u to print difference between pointers. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
On R-Car Gen3 SoCs the DU lost its ability to access memory directly and needs to work in conjunction with the VSP to do so. This commit handles the VSP internally to hide it from the user. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
- 20 Feb, 2016 7 commits
-
-
Laurent Pinchart authored
The plane allocator is specific to DU planes and won't be used for VSP-based planes, move it with the rest of the DU planes code where it belongs. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
Plane sources are configured by the VSPS bit in the PnDDCR4 register. Although the datasheet states that the bit is updated during vertical blanking, it seems that updates only occur when the DU group is held in reset through the DSYSR.DRES bit. Restart the group if the source changes. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
Configure the plane source at plane setup time to source frames from memory or from the VSP1. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
The R8A7790 DU can source frames directly from the VSP1 devices VSPD0 and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0 or DU0/1 plane 1. Allocate the correct fixed plane when sourcing frames from VSPD0 or VSPD1, and allocate planes in reverse index order otherwise to ensure maximum availability of planes 0 and 1. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
Rename plane setup functions using more explicit names, and use local variables to store intermediate values to increase readability. This also prepares for VSP compositor support. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
There's no need for a read-modify-write pattern, all register bits can be set explicitly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
A disabled CRTC can't display planes, the driver shouldn't try to configure it when updating planes. The DRM core will store the plane state for us, and the plane will be configured appropriately the next time the CRTC is enabled. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-