A recent commit introduces a bug in dsi_mgr_phy_enable. In the non
dual DSI mode, we reset the mdsi (master DSI) PHY. This isn't right
since master and slave DSI exist only in dual DSI mode. For the normal
mode of operation, we should simply reset the PHY of the DSI device
(i.e. msm_dsi) corresponding to the current bridge.
Usage of the wrong DSI pointer also resulted in a static checker
warning. That too is resolved with this fix.
Fixes: b62aa70a98 (drm/msm/dsi: Move PHY operations out of host)
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
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: Hai Li <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
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: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
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 <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
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: Hai Li <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
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 <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
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 <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of linking encoders and bridges in every driver (and getting it
wrong half of the time, as many drivers forget to set the drm_bridge
encoder pointer), do so in core code. The drm_bridge_attach() function
needs the encoder and optional previous bridge to perform that task,
update all the callers.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Stefan Agner <stefan@agner.ch> # For DCU
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> # For atmel-hlcdc
Acked-by: Vincent Abriou <vincent.abriou@st.com> # For STI
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> # For sun4i
Acked-by: Xinliang Liu <z.liuxinliang@hisilicon.com> # For hisilicon
Acked-by: Jyri Sarha <jsarha@ti.com> # For tilcdc
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com
Move the drm_connector registration from the encoder(HDMI/DSI etc) drivers
to the msm platform driver. This will simplify the task of ensuring that
the connectors are registered only after the drm_device itself is
registered.
The connectors' destroy ops are made to use kzalloc instead of
devm_kzalloc to ensure that that the connectors can be successfully
unregistered when the msm driver module is removed. The memory for the
connectors is unallocated when drm_mode_config_cleanup() is called
during either during an error or during driver remove.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We currently use iommu allocated DMA buffers for sending DSI commands.
DSIv2 doesn't have a port connected to the MDP iommu. Therefore, it
can't use iommu allocated buffers to fetch DSI commands.
Use a regular contiguous DMA buffer if we are DSIv2.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The dsi bridge ops call drm_panel functions to set up the connected
drm_panel. Add checks to make sure these aren't called when we're
connected to an external bridge.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
There are platforms where the DSI output can be connected to another
encoder bridge chip (DSI to HDMI, DSI to LVDS etc).
Add support for external bridge support to the dsi driver. We assume that
the external bridge chip would be of the type drm_bridge. The dsi driver's
internal drm_bridge (msm_dsi->bridge) is linked to the external bridge's
drm_bridge struct.
In the case we're connected to an external bridge, we don't need to create
and manage a connector within our driver, it's the bridge driver's
responsibility to create one.
v2:
- Move the external bridge attaching stuff to dsi manager to make things
cleaner.
- Force the bridge to connect to a video mode encoder for now (the dsi
mode flags may have not been populated by modeset_init)
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Create a helper msm_dsi_device_connected() which checks whether we have a
device connected to the dsi host or not. This check gets messy when we
have support external bridges too. Having an inline function makes it
more legible.
For now, the check only consists of msm_dsi->panel being non-NULL. Later,
this will check if we have an external bridge or not.
This helper isn't used in dsi_connector related code as that's specific
to only when a drm_panel is connected.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We currently support only panels connected to dsi output. We're going to
also support external bridge chips now.
Change 'panel_node' to 'device_node' in the struct msm_dsi_host and
'panel_flags' to 'device_flags' in msm_dsi. This makes things sound a
bit more generic.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reset DSI PHY silently changes its PLL registers to reset status,
which will make cached status in clock driver invalid and result
in wrong output rate of link clocks. The current restore mechanism
in DSI PLL does not cover all the cases. This change is to recover
PLL status after PHY reset to match HW status with cached status
in clock driver.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The current term of *dual panel* in DSI driver code causes confusion.
It is supposed to indicate the panel using two DSI links. Rename it
to *dual DSI*.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The source PLL to be used by each DSI PHY should be decided by
DSI manager based on dual DSI information, while the register
programming to select PLL is different from one type of PHY to
another. This change adds the H/W difference to PHY configuration
and updates the interface between DSI manager and PHY.
With this change, PLL selection can be supported on different
targets.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change activates PLL driver for DSI to work with
common clock framework.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
drm_mode_connector_attach_encoder() function call is missing
during eDP and DSI connector initialization. As a result,
no encoder is returned by DRM_IOCTL_MODE_GETCONNECTOR system
call. This change is to fix this issue.
Signed-off-by: Hai Li <hali@codeaurora.org>
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>
