- 08 Feb, 2017 1 commit
-
-
Dave Airlie authored
Merge branch 'drm-rockchip-next-2017-02-07' of https://github.com/markyzq/kernel-drm-rockchip into drm-next Single compile fix. * 'drm-rockchip-next-2017-02-07' of https://github.com/markyzq/kernel-drm-rockchip: drm/rockchip: cdn-dp: fix cdn-dp complie warning
-
- 07 Feb, 2017 4 commits
-
-
Mark Yao authored
fix warning: drivers/gpu/drm/rockchip/cdn-dp-reg.c:632:24: warning: 'val[1]' may be used uninitialized in this function [-Wmaybe-uninitialized] msa_misc = 2 * val[0] + 32 * val[1] + Signed-off-by:Mark Yao <mark.yao@rock-chips.com>
-
git://people.freedesktop.org/~robclark/linuxDave Airlie authored
The big things this time around are: 1) support for hw cursor on newer mdp5 devices (snapdragon 820+, tested on db820c) 2) dsi encoder cleanup 3) gpu dt bindings cleanup so we can get the gpu nodes merged upstream * 'msm-next' of git://people.freedesktop.org/~robclark/linux: (32 commits) drm/msm: return -EFAULT if copy_from_user() fails drm/msm/dsi: Add PHY/PLL for 8x96 drm/msm/dsi: Add new method to calculate 14nm PHY timings drm/msm/dsi: Move PHY operations out of host drm/msm/dsi: Reset both PHYs before clock operation for dual DSI drm/msm/dsi: Pass down use case to PHY drm/msm/dsi: Return more timings from PHY to host drm/msm/dsi: Add a PHY op that initializes version specific stuff drm/msm/dsi: Add 8x96 info in dsi_cfg drm/msm/dsi: Don't error if a DSI host doesn't have a device connected drm/msm/mdp5: Add support for legacy cursor updates drm/msm/mdp5: Refactor mdp5_plane_atomic_check drm/msm/mdp5: Add cursor planes drm/msm/mdp5: Misc cursor plane bits drm/msm/mdp5: Configure COLOR3_OUT propagation drm/msm/mdp5: Use plane helpers to configure src/dst rectangles drm/msm/mdp5: Prepare CRTC/LM for empty stages drm/msm/mdp5: Create only as many CRTCs as we need drm/msm/mdp5: cfg: Change count to unsigned int drm/msm/mdp5: Create single encoder per interface (INTF) ...
-
Dave Airlie authored
Merge branch 'drm-rockchip-next-2017-02-05' of https://github.com/markyzq/kernel-drm-rockchip into drm-next rockchip CDN-DP support. * 'drm-rockchip-next-2017-02-05' of https://github.com/markyzq/kernel-drm-rockchip: drm/rockchip: cdn-dp: don't configure hardware in mode_set drm/rockchip: cdn-dp: retry to check sink count drm/rockchip: cdn-dp: Move mutex_init to probe drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event drm/rockchip: cdn-dp: Do not run worker while suspended drm/rockchip: cdn-dp: Load firmware if no monitor connected drm/rockchip: cdn-dp: add cdn DP support for rk3399 drm/rockchip: return ERR_PTR instead of NULL drm/rockchip: vop: make vop register setting take effect
-
git://anongit.freedesktop.org/git/drm-miscDave Airlie authored
Final 4.11 feature pull request: - sii8520 bridge update from Andrzej - ->release callback, maybe somewhen in the future we'll even get drm_device lifetimes correct! (Chris Wilson) - drm_mm search improvements, and good docs for different search strategies now (Chris) - simplify fbdev emulation init parameters (Gabriel) - bunch of misc things all over ... and the first few patches from our small driver in drm-misc experiment: - cleanups for qxl and bochs from a few different people - dsi support for vc4 (not yet the panel driver, that's under discussion still) from Eric - meson rename to meson-drm to distinguish from other platform drivers (Neil Amstrong) * tag 'drm-misc-next-2017-02-03' of git://anongit.freedesktop.org/git/drm-misc: (47 commits) drm: kselftest for drm_mm and bottom-up allocation drm: Improve drm_mm search (and fix topdown allocation) with rbtrees drm: Fix build when FBDEV_EMULATION is disabled drm: Rely on mode_config data for fb_helper initialization drm: Provide a driver hook for drm_dev_release() drm: meson: rename driver name to meson-drm drm: meson: rename module name to meson-drm drm/bridge/sii8620: enable interlace modes drm/bridge/sii8620: enable MHL3 mode if possible drm/bridge/sii8620: add HSIC initialization code drm/bridge/sii8620: improve gen2 write burst IRQ routine drm/bridge/sii8620: send EMSC features on request drm/bridge/sii8620: rewrite hdmi start sequence drm/bridge/mhl: add MHL3 infoframe related definitions drm/bridge/sii8620: fix disconnect sequence drm/bridge/sii8620: split EDID read and write code drm/bridge/sii8620: add delay during cbus reset drm/bridge/sii8620: do not stop MHL output when TMDS input is stopped drm/bridge/sii8620: set gen2 write burst before sending MSC command drm/bridge/sii8620: abstract out sink detection code ...
-
- 06 Feb, 2017 32 commits
-
-
Dan Carpenter authored
copy_from_user_inatomic() is actually a local function that returns -EFAULT or positive values on error. Otherwise copy_from_user() returns the number of bytes remaining to be copied. We want to return -EFAULT here. I removed an unlikely() because we just did a copy_from_user() so I don't think it can possibly make a difference. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Archit Taneja authored
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:
-
Hai Li authored
The 14nm DSI PHY on 8x96 (called PHY v2 downstream) requires a different set of calculations for computing D-PHY timing params. Create a timing_calc_v2 func for the newer v2 PHYs. Signed-off-by:
Hai Li <hali@codeaurora.org> Signed-off-by:
-
Hai Li authored
Since DSI PHY has been a separate platform device, it should not depend on the resources in host to be functional. This change is to trigger PHY operations in manager, instead of host, so that host and PHY can be completely separated. Signed-off-by:
-
Archit Taneja authored
In case of dual DSI, some registers in PHY1 have been programmed during PLL0 clock's set_rate. The PHY1 reset called by host1 later will silently reset those PHY1 registers. This change is to reset and enable both PHYs before any PLL clock operation. [Originally worked on by Hai Li <hali@codeaurora.org>. Fixed up by Archit Taneja <architt@codeaurora.org>] Signed-off-by:
-
Hai Li authored
For some new types of DSI PHY, more settings depend on use cases controlled by DSI manager. This change allows DSI manager to setup PHY with a use case. Signed-off-by:
-
Hai Li authored
The DSI host is required to configure more timings calculated in PHY. By introducing a shared structure, this change allows more timing information passed from PHY to host. Signed-off-by:
-
Archit Taneja authored
Create an init() op for dsi_phy which sets up things specific to a given DSI PHY. The dsi_phy driver probe expects every DSI version to get a "dsi_phy_regulator" mmio base. This isn't the case for 8x96. Creating an init() op will allow us to accommodate such differences. Signed-off-by:
-
Archit Taneja authored
Add 8x96 DSI data in dsi_cfg. The downstream kernel's dsi_host driver enables core_mmss_clk. We're seeing some branch clock warnings on 8x96 when enabling this. There doesn't seem to be any negative effect with not enabling this clock, so use it once we figure out why we get the warnings. Signed-off-by:
-
Archit Taneja authored
The driver returns an error if a DSI DT node is populated, but no device is connected to it or if the data-lane map isn't present. Ideally, such a DSI node shouldn't be probed at all (i.e, its status should be set to "disabled in DT"), but there isn't any harm in registering the DSI device even if it doesn't have a bridge/panel connected to it. Signed-off-by:
-
Archit Taneja authored
This code has been more or less picked up from the vc4 and intel implementations of update_plane() funcs for cursor planes. The update_plane() func is usually the drm_atomic_helper_update_plane func that will issue an atomic commit with the plane updates. Such commits are not intended to be done faster than the vsync rate. The legacy cursor userspace API, on the other hand, expects the kernel to handle cursor updates immediately. Create a fast path in update_plane, which updates the cursor registers and flushes the configuration. The fast path is taken when there is only a change in the cursor's position in the crtc, or a change in the cursor's crop co-ordinates. For anything else, we go via the slow path. We take the slow path even when the fb changes, and when there is currently no fb tied to the plane. This should hopefully ensure that we always take a slow path for every new fb. This in turn should ensure that the fb is pinned/prepared. Signed-off-by:
-
Archit Taneja authored
In mdp5_plane_atomic_check, we get crtc_state from drm_plane_state. Later, for cursor planes, we'll populate the update_plane() func that takes a fast asynchronous path to implement cursor movements. There, we would need to call a similar atomic_check func to validate the plane state, but crtc_state would need to be derived differently. Refactor mdp5_plane_atomic_check to mdp5_plane_atomic_check_with_state such that the latter takes crtc_state as an argument. This is similar to what the intel driver has done for async cursor updates. Signed-off-by:
-
Archit Taneja authored
Register cursor drm_planes. The loop in modeset_init that inits the planes and crtcs has to be refactored a bit. We first iterate all the hwpipes to find the cursor planes. Then, we loop again to create crtcs. In msm_atomic_wait_for_commit_done, remove the check which bypasses waiting for vsyncs if state->legacy_cursor_updates is true. We will later create a fast path for cursor position changes in the cursor plane's update_plane func that doesn't go via the regular atomic commit path. For rest of cursor related updates, we will have to wait for vsyncs, so ignore the legacy_cursor_updates flag. Signed-off-by:
-
Archit Taneja authored
These are various changes added in preparation for cursor planes: - Add a pipe_cursor block for 8x96 in mdp5_cfg. - Add a new pipe CAP called MDP_PIPE_CAP_CURSOR. Use this to ensure we assign a cursor SSPP for a drm_plane with type DRM_PLANE_TYPE_CURSOR. - Update mdp5_ctl_blend_mask/ext_blend_mask funcs to incorporate cursor SSPPs. - In mdp5_ctl_blend, iterate through MAX_STAGES instead of stage_cnt, we need to do this because we can now have empty stages in between. - In mdp5_crtc_atomic_check, make sure that the cursor plane has the highest zorder, and stage the cursor plane to the maximum stage # present on the HW. - Create drm_crtc_funcs that doesn't try to implement cursors using the older LM cursor HW. - Pass drm_plane_type in mdp5_plane_init instead of a bool telling whether plane is primary or not. Signed-off-by:
-
Archit Taneja authored
In MDP5 Layer Mixer HW, the blender output is only the blended color components (i.e R, G and B, or COLOR0/1/2 in MDP5 HW terminology). This is fed to the BG input of the next blender. We also need to provide an alpha (COLOR3) value for the BG input at the next stage. This is configured via using the REG_MDP5_LM_BLEND_COLOR_OUT register. For each stage, we can propagate either the BG or FG alpha to the next stage. The approach taken by the driver is to propagate FG alpha, if the plane staged on that blender has an alpha. If it doesn't, we try to propagate the base layer's alpha. This is borrowed from downstream MDP5 kernel driver. Without this, we don't see any cursor plane content. Signed-off-by:
-
Archit Taneja authored
The MDP5 plane's atomic_check ops doesn't perform clipping tests. This didn't hurt us much in the past, but clipping becomes important with cursor planes. Use drm_plane_helper_check_state, the way rockchip/intel/mtk drivers already do. Use these drivers as reference. Clipping requires knowledge of the crtc width and height. This requires us to call drm_atomic_helper_check_modeset before drm_atomic_helper_check_planes in the driver's atomic_check op, because check_modetest will populate the mode for the crtc, needed to populate the clip rectangle. We update the plane_enabled(state) local helper to use state->visible, since state->visible and 'state->fb && state->crtc' represent the same thing. One issue with the existing code is that we don't have a way to disable the plane when it's completely clipped out. Until there isn't an update on the crtc (which would de-stage the plane), we would still see the plane in its last 'visible' configuration. Signed-off-by:
-
Archit Taneja authored
Use SSPP_NONE in mdp5_plane_pipe() if there is now hwpipe allocated for the drm_plane. Returning '0' means we are returning VIG0 pipe. Also, use the mdp5_pipe enum to pass around the stage array. Initialize the stage to SSPP_NONE by default. We do the above because 1) Cursor plane has to be staged at the topmost blender of the LM, which can result in empty stages in between 2) In the future, when we support multiple LMs per CRTC. We could have stages which don't have any pipe assigned to them. Signed-off-by:
-
Archit Taneja authored
We currently create CRTCs equaling to the # of Layer Mixer blocks we have on the MDP5 HW. This number is generally more than the # of encoders (INTFs) we have in the MDSS HW. The number of encoders connected to displays on the platform (as described by DT) would be even lesser. Create only N drm_crtcs, where N is the number of drm_encoders successfully registered. To do this, we call modeset_init_intf() before we init the drm_crtcs and drm_planes. Because of this change, setting encoder->possible_crtcs needs to be moved from construct_encoder() to a later point when we know how many CRTCs we have. Signed-off-by:
-
Archit Taneja authored
Count can't be non-zero. Changing to uint will also prevent future warnings. Signed-off-by:
-
Archit Taneja authored
For the DSI interfaces, the mdp5_kms core creates 2 encoders for video and command modes. Create only a single encoder per interface. When creating the encoder, set the interface type to MDP5_INTF_MODE_NONE. It's the bridge (DSI/HDMI/eDP) driver's responsibility to set a different interface type. It can use the the kms func op set_encoder_mode to change the mode of operation, which in turn would configure the interface type for the INTF. In mdp5_cmd_encoder.c, we remove the redundant code, and make the commmand mode funcs as helpers that are used in mdp5_encoder.c Signed-off-by:
-
Archit Taneja authored
Rename the mdp5_encoder_* ops for active displays to mdp5_vid_encoder_* ops. Signed-off-by:
-
Archit Taneja authored
The mdp5 kms driver currently sets up multiple encoders per interface (INTF), one for each kind of mode of operation it supports. We create 2 drm_encoders for DSI, one for Video Mode and the other for Command Mode operation. The reason behind this approach could have been that we aren't aware of the DSI device's mode of operation when we create the encoders. This makes things a bit complicated, since these encoders have to be further attached to the same DSI bridge. The easier way out is to create a single encoder, and make the DSI driver set its mode of operation when we know what the DSI device's mode flags are. Start with providing a way to set the mdp5_intf_mode using a kms func that sets the encoder's mode of operation. When constructing a DSI encoder, we set the mode of operation to Video Mode as default. When the DSI device is attached to the host, we probe the DSI mode flags and set the corresponding mode of operation. Signed-off-by:
-
Archit Taneja authored
We currently create 2 encoders for DSI interfaces, one for command mode and other for video mode operation. This isn't needed as we can't really use both the encoders at the same time. It also makes connecting bridges harder. Switch to creating a single encoder. For now, we assume that the encoder is configured only in video mode. Later, the same encoder would be usable in both modes. Signed-off-by:
-
Archit Taneja authored
The commit "drm: bridge: Link encoder and bridge in core code" updated the drm_bridge_attach() API to also include the drm_encoder pointer the bridge attaches to. The func msm_dsi_manager_bridge_init() now relies on the drm_encoder pointer stored in msm_dsi->encoders to pass the encoder to the bridge API. msm_dsi->encoders is unfortunately set after this function is called, resulting in us passing a NULL pointer to drm_brigde_attach. This results in an error and the DSI driver probe fails. Move the initialization of msm_dsi->encoders[] a bit up. Also, don't try to set the encoder's bridge. That's now managed by the bridge API. Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Archit Taneja authored
Signed-off-by:
-
Archit Taneja authored
Signed-off-by:
-
Archit Taneja authored
Define the block in advance so that the generated mdp5.xml.h doesn't break build. Signed-off-by:
-
Rob Clark authored
Signed-off-by: -
Rob Clark authored
Suggested by Rob Herring. We still support the old names for compatibility with downstream android dt files. Cc: Rob Herring <robh@kernel.org> Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
Rob Herring <robh@kernel.org>
-
Rob Clark authored
This was never documented or used in upstream dtb. It is used by downstream bindings from android device kernels. But the quirks are a property of the gpu revision, and as such are redundant to be listed separately in dt. Instead, move the quirks to the device table. Signed-off-by:
-
Rob Clark authored
The original way we determined the gpu version was based on downstream bindings from android kernel. A cleaner way is to get the version from the compatible string. Note that no upstream dtb uses these bindings. But the code still supports falling back to the legacy bindings (with a warning), so that we are still compatible with the gpu dt node from android device kernels. Signed-off-by:
-
Rob Clark authored
The plan is to use the OPP bindings. For now, remove the documentation for qcom,gpu-pwrlevels, and make the driver fall back to a safe low clock if the node is not present. Note that no upstream dtb use this node. For now we keep compatibility with this node to avoid breaking compatibility with downstream android dt files. Signed-off-by:
-
- 05 Feb, 2017 3 commits
-
-
Chris Zhong authored
With atomic modesetting the hardware will be powered off when the mode_set function is called. We should configure the hardware in the enable function. Signed-off-by:Chris Zhong <zyw@rock-chips.com>
-
Chris Zhong authored
Sometimes the Dock is disconnected, but cdn_dp_encoder_disable is not triggered by DRM. For example, unplug the Dock in console mode, and re-plug it again, the cdn_dp_event_work will try to get the sink count of Dock, since the DP is still active. But the Dock has been powered down, it need re-power on, and wait for a while until it is ready to DPCD communication. Signed-off-by: -
Jeffy Chen authored
We're trying to lock mutex when cdn-dp shutdown, so we need to make sure the mutex is inited in cdn-dp's probe. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Reviewed-by:
-
