- 04 Apr, 2017 1 commit
-
-
Lucas Stach authored
The PRE/PRG drivers, which need the DRM infrastructure, are only used from the output path, so we skip building them into the ipu-v3 driver if CONFIG_DRM is not enabled. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de>
-
- 16 Mar, 2017 7 commits
-
-
Liu Ying authored
No one is using the structure imx_drm_component, so let's remove the definition to save several lines. Signed-off-by:
Liu Ying <gnuiyl@gmail.com> Signed-off-by:
-
Lucas Stach authored
Allow the planes to use the PRG/PRE units as linear prefetchers when possible. This improves DRAM efficiency a bit and reduces the chance for display underflow when the memory subsystem is under load. This does not yet support scanning out tiled buffers directly, as this needs more work, but it already wires up the basic interaction between imx-drm, the IPUv3 driver and the PRG and PRE drivers. Signed-off-by:
-
Lucas Stach authored
On i.MX6 QuadPlus the PRG needs to be clocked in order to pass through the data access requests from the IDMAC. This call is a no-op for other all other SoCs. Signed-off-by:
-
Lucas Stach authored
Using non-zero AXI IDs for anything other than the display channels collides with the PRG AXI snooping, so only do this if there is no PRG present. Signed-off-by:
-
Lucas Stach authored
The i.MX6 QuadPlus IPU needs to PRG unit to gain access to the data bus. Make sure it is present and available to be used. Signed-off-by:
-
Lucas Stach authored
Document the valid compatible strings for the IPUv3. On i.MX6 QuadPlus the IPU needs to know which PRG has to be used for this IPU instance. Add a "fsl,prg" property containing a phandle pointing to the correct PRG device. Signed-off-by:
-
Lucas Stach authored
This adds support for the i.MX6 QUadPlus PRG unit. It glues together the IPU and the PRE units. Signed-off-by:
-
- 15 Mar, 2017 16 commits
-
-
Lucas Stach authored
This adds the the devicetree binding for the Prefetch Resolve Gasket, as found on i.MX6 QuadPlus. The PRG is fairly simple in that it only has a configuration register range and two clocks, one for the AHB slave port and one for the AXI ports and the functional units. The PRE connections need to be described in the DT, as the PRE<->PRG assignment is a mix between fixed and muxable connections. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Lucas Stach authored
This adds support for the i.MX6 QuadPlus PRE units. Currently only linear prefetch into SRAM is supported, other modes of operation like the tiled-to-linear conversion will be added later. Signed-off-by:
-
Lucas Stach authored
The Prefetch Resolve Engine is a prefetch and tile resolve engine which prefetches display data from DRAM to an internal SRAM region. It has a single clock for configuration register access and the functional units. A single shared interrupt is used for status and error signaling. The only external dependency is the SRAM region to use for the prefetch double buffer. Signed-off-by:
-
Philipp Zabel authored
The IPUv3 can read 8-bit alpha values from a separate plane buffer using a companion IDMAC channel driven by the Alpha Transparency Controller (ATC) for the graphics channels. The conditional read mechanism allows to reduce memory bandwidth by skipping reads of color data for completely transparent bursts. Signed-off-by: -
Philipp Zabel authored
Allow to calculate EBA for planes other than plane 0. This is in preparation for the following patch, which adds support for separate alpha planes. Signed-off-by: -
Philipp Zabel authored
The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels. This allows to reduce memory bandwidth via a conditional read mechanism or to support planar YUV formats with alpha transparency. Signed-off-by: -
Philipp Zabel authored
Some hardware can read the alpha components separately and then conditionally fetch color components only for non-zero alpha values. This patch adds fourcc definitions for two-plane RGB formats with an 8-bit alpha channel on a second plane. Signed-off-by: -
Philipp Zabel authored
The DP (display processor) channel disable code tried to busy wait for the DP sync flow end interrupt status bit when disabling the partial plane without a full modeset. That never worked reliably, and it was disabled completely by the recent "gpu: ipu-v3: remove IRQ dance on DC channel disable" patch, causing ipu_wait_interrupt to always time out after 50 ms, which in turn would trigger a timeout in drm_atomic_helper_wait_for_vblanks. This patch changes ipu_plane_atomic_disable to only queue a DP channel register update at the next frame boundary and set a flag, which can be done without any waiting whatsoever. The imx_drm_atomic_commit_tail then calls a new ipu_plane_disable_deferred function that does the actual IDMAC teardown of the planes that are flagged for deferred disabling, after waiting for the vblank. Signed-off-by:
-
Philipp Zabel authored
drm_atomic_helper_cleanup_planes only calls the cleanup_fb plane helpers, which we don't implement as a CMA framebuffer based driver. There is no reason to wait for vblanks in commit_tail only to do nothing afterwards. Signed-off-by:
-
Philipp Zabel authored
When disabling the foreground DP channel during a modeset, the DC is already disabled without waiting for end of frame. There is no reason to wait for a frame boundary before updating the DP registers in that case. Add support to apply updates immediately. No functional changes, yet. Signed-off-by:
-
Lucas Stach authored
This has never worked properly, as the IRQ got retriggered immediately on unmask. Remove the IRQ wait dance, as it is apparently safe to disable the DC channel at any point in time. Signed-off-by:
-
Philipp Zabel authored
The IPU does not natively understand bayer formats, but it can pass them through unchanged. Add support for setting the image base address and cropping offset to ipu_cpmem_set_image. Signed-off-by: -
Philipp Zabel authored
Otherwise, if the image base address is kept at zero, and if the user ignores the error return value, the IPU may be configured to write into the dma-apbh@00110000 region for large frames, which will lock up the system. Reported-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Philipp Zabel authored
Previously, the overlay plane position would only be updated when the plane was first enabled or during a modeset. We can instruct the DP to move the plane also when just updating the EBA. Signed-off-by: -
Philipp Zabel authored
Use drm_plane_helper_check_state to clip raw user coordinates to crtc bounds. This checks for full plane coverage and scaling already, so we can drop some custom checks. Use the clipped coordinates everywhere. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
git://anongit.freedesktop.org/git/drm-miscDave Airlie authored
More drm-misc stuff for 4.12: - drm_platform removal from Laurent - more dw-hdmi bridge driver updates (Laurent, Kieran, Neil) - more header cleanup and documentation - more drm_debugs_remove_files removal (Noralf) - minor qxl updates (Gerd) - edp crc support in helper + analogix_dp (Tomeu) for more igt testing! - old/new iterator roll-out (Maarten) - new bridge drivers: lvds (Laurent), megachips-something (Peter Senna) * tag 'drm-misc-next-2017-03-12' of git://anongit.freedesktop.org/git/drm-misc: (51 commits) drm: bridge: dw-hdmi: Move the driver to a separate directory. drm: bridge: dw-hdmi: Switch to regmap for register access drm: bridge: dw-hdmi: Remove device type from platform data drm: bridge: dw-hdmi: Add support for custom PHY configuration drm: bridge: dw-hdmi: Create PHY operations drm: bridge: dw-hdmi: Fix the PHY power up sequence drm: bridge: dw-hdmi: Fix the PHY power down sequence drm: bridge: dw-hdmi: Enable CSC even for DVI drm: bridge: dw-hdmi: Move CSC configuration out of PHY code drm: bridge: dw-hdmi: Remove unused functions drm: Extract drm_file.h drm: Remove DRM_MINOR_CNT drm: rename drm_fops.c to drm_file.c drm/doc: document fallback behaviour for atomic events drm: Remove drmP.h include from drm_kms_helper_common.c drm: Extract drm_pci.h drm: Move drm_lock_data out of drmP.h drm: Extract drm_prime.h drm/doc: Add todo about connector_list_iter drm/qxl: Remove qxl_debugfs_remove_files() ...
-
- 11 Mar, 2017 1 commit
-
-
git://linuxtv.org/pinchartl/mediaDaniel Vetter authored
Merge Laurent's drm_platform removal code. Only conflict is with the drm_pci.h extraction, which allows me to fix up the misplayed drm_platform_init fumble that 0day and Stephen Rothwell reported. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
- 10 Mar, 2017 10 commits
-
-
Laurent Pinchart authored
The driver is already made of 5 separate source files. Move it to a newly created directory named synopsys where more Synopsys bridge drivers can be added later (for the DisplayPort controller for instance). Suggested-by:
Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
-
Neil Armstrong authored
The Synopsys Designware HDMI TX Controller does not enforce register access on platforms instanciating it. The current driver supports two different types of memory-mapped flat register access, but in order to support the Amlogic Meson SoCs integration, and provide a more generic way to handle all sorts of register mapping, switch the register access to use the regmap infrastructure. In the case of registers that are not flat memory-mapped or do not conform to the current driver implementation, a regmap struct can be given in the plat_data and be used at probe or bind. Since the AHB audio driver is only available with direct memory access, only allow the I2S audio driver to be registered is directly memory-mapped. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
-
Kieran Bingham authored
The device type isn't used anymore now that workarounds and PHY-specific operations are performed based on version information read at runtime. Remove it. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Kieran Bingham authored
The DWC HDMI TX controller interfaces with a companion PHY. While Synopsys provides multiple standard PHYs, SoC vendors can also integrate a custom PHY. Modularize PHY configuration to support vendor PHYs through platform data. The existing PHY configuration code was originally written to support the DWC HDMI 3D TX PHY, and seems to be compatible with the DWC MLP PHY. The HDMI 2.0 PHY will require a separate configuration function. Signed-off-by:
-
Laurent Pinchart authored
The HDMI TX controller support different PHYs whose programming interface can vary significantly, especially with vendor PHYs that are not provided by Synopsys. To support them, create a PHY operation structure that can be provided by the platform glue layer. The existing PHY handling code (limited to Synopsys PHY support) is refactored into a set of default PHY operations that are used automatically when the platform glue doesn't provide its own operations. Signed-off-by:
-
Laurent Pinchart authored
When powering the PHY up we need to wait for the PLL to lock. This is done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register (interrupt-based wait could be implemented as well but is likely overkill). The bit is asserted when the PLL locks, but the current code incorrectly waits for the bit to be deasserted. Fix it, and while at it, replace the udelay() with a sleep as the code never runs in non-sleepable context. To be consistent with the power down implementation move the poll loop to the power off function. Signed-off-by:
-
Laurent Pinchart authored
The PHY requires us to wait for the PHY to switch to low power mode after deasserting TXPWRON and before asserting PDDQ in the power down sequence, otherwise power down will fail. The PHY power down can be monitored though the TX_READY bit, available through I2C in the PHY registers, or the TX_PHY_LOCK bit, available through the HDMI TX registers. As the two are equivalent, let's pick the easier solution of polling the TX_PHY_LOCK bit. The power down code is currently duplicated in multiple places. To avoid spreading multiple calls to a TX_PHY_LOCK poll function, we have to refactor the power down code and group it all in a single function. Tests showed that one poll iteration was enough for TX_PHY_LOCK to become low, without requiring any additional delay. Retrying the read five times with a 1ms to 2ms delay between each attempt should thus be more than enough. Signed-off-by:
-
Neil Armstrong authored
If the input pixel format is not RGB, the CSC must be enabled in order to provide valid pixel to DVI sinks. This patch removes the hdmi only dependency on the CSC enabling. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
The color space converter isn't part of the PHY, move its configuration out of PHY code. Signed-off-by:
-
Laurent Pinchart authored
Most of the hdmi_phy_test_*() functions are unused. Remove them. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
-
- 09 Mar, 2017 5 commits
-
-
Daniel Vetter authored
I'm torn on whether drm_minor really should be here or somewhere else. Maybe with more clarity after untangling drmP.h more this is easier to decide, for now I've put a FIXME comment right next to it. Right now we need struct drm_minor for the inline drm_file type helpers, and so it does kinda make sense to have them here. Next patch will kerneldoc-ify the entire pile. Reviewed-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by:
-
Daniel Vetter authored
This was originally added by David Herrmann for range checks, but entirely unused. It confused me, so let's remove it. Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Daniel Vetter authored
It's not just file ops, but drm_file stuff in general. This is prep work to extracting a drm_file.h header in the next patch. Reviewed-by:
-
Daniel Vetter authored
Worst case if the hw can't support completion signalling in a race-free way we want the event to be too late, not too early. Text adapted from a proposal from Laurent - the other side of how to make hw work correctly where it's possible is imo already sufficiently documented. v2: Review from Laurent. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
An easy one as a drive-by. Reviewed-by:
-
