For all outputs except DSI we have a 1:1 relationship between connectors
and encoders and the driver is relying on the atomic helpers: we can
drop the custom ->best_encoder() and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465300095-16971-9-git-send-email-boris.brezillon@free-electrons.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>
Calling the legacy gpio_free on an invalid GPIO (a GPIO numbered -1)
results in kernel warnings. This causes a lot of backtraces when
we try to unload the drm/msm module.
Call gpio_free only on valid GPIOs.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Global symbols in the kernel should be prefixed by the name
of the subsystem and/or driver to avoid conflicts when all
code is built-in.
In this case, function names like 'hdmi_register' or 'hdmi_set_mode'
are way too generic for an MSM specific DRM driver, so I'm renaming
them all to msm_hdmi_* here.
I also rename a lot of the 'static' symbols along with the global
names for consistency, even though those are relatively harmless;
they might only be slightly confusing when they show up in
backtraces.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Some platforms may not have a HPD gpio line to detect Hot Plug signal from
the connector. They need to rely only on reading REG_HDMI_HPD_INT_STATUS
for HPD.
Modify hdmi_connector_detect logic such that it checks for HPD only using
the status register if there is no HPD gpio.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Make gpio allocation and usage iterative by parsing the gpios on a given
platform from a list. This gives us flexibility over what all gpios exist
for a platform, whether they are input or output, and what value they
should be set to.
In particular, this will make HDMI on 8x96 platforms easier to integrate
with the driver, as it doesn't have a HPD gpio input to them. Also, it
cleans things up a bit.
We still use the legacy gpio api here, as we might need to backport this
driver to downstream kernels.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change adds the MDP and HDMI support for msm8x94.
Note that HDMI PHY registers are not being accessed anymore from
the driver.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
[rename compatible s/8x94/8994/ since preference is to not trust the
marketing folks who invent chip #'s but instead name things after the
lead chip.. we should rename some 80XY to 89XY to standardize on the
lead chip but leave that for another patch. Also, update dt bindings
doc]
Signed-off-by: Rob Clark <robdclark@gmail.com>
->reset() currently only accesses HDMI core registers, and yet it
is located in hdmi_phy*. Since no PHY registers are being
accessed during ->reset(), it would be better to bring that
function in hdmi core module where HDMI core registers are
usually being accessed.
This will also help for msm8x94 for which no PHY registers
accesses are done (->phy_init == NULL) but the HDMI PHY reset
from HDMI core still needs to be done.
Note:
SW_RESET_PLL bit is not written in hdmi_phy_8x60_reset(); this
write should not affect anything if the corresponding field is
not writable.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
[fixed warning about unused 'phy' in hpd_enable() while merging]
Signed-off-by: Rob Clark <robdclark@gmail.com>
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>
Some targets (eg: msm8994) use the pinctrl framework to configure
interface pins. This change adds support for initialization and
pinctrl active/sleep state control for the HDMI driver.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
DRM device's dev (hdmi->dev->dev) points to the mdss_mdp device
handle. Instead, we should get a reference to the mdss_hdmi
handle.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
So after clarification from qcom, it seems mdp4 and mdp5 support
*de*interlacing but not generating an interlaced signal. Which would
explain why interlaced modes never worked properly.
So disable in the one connector which was claiming to support
interlaced.
Signed-off-by: Rob Clark <robdclark@gmail.com>
As a result of atomic DPMS support, the various prepare/commit hooks get
called in a way that msm dislikes. We were expecting prepare/commit to
bracket a modeset, which is no longer the case. This was needed to hold
various extra clk's (such as interface clks) on while we are touching
registers, and in the case of mdp4 holding vblank enabled.
The most straightforward way to deal with this, since we already have
our own atomic_commit(), is to just handle prepare/commit internally to
the driver (with some additional vfuncs for mdp4 vs mdp5), and switch
everything over to instead use the new enable/disable hooks. It doesn't
really change too much, despite the code motion. What used to be in the
encoder/crtc dpms() fxns is split out into enable/disable.
We should be able to drop our own enable-state tracking, as the atomic
helpers should do this for us. But keeping that for the short term for
extra debugging as atomic stablizes.
Signed-off-by: Rob Clark <robdclark@gmail.com>
A left-over from prior to component framework. The original intent was
to deal with hdmi getting unloaded before the master component, but that
isn't really going to work anyways. These days with the component
framework taking care to unload the master component first, we don't
have to worry about this.
Signed-off-by: Rob Clark <robdclark@gmail.com>
HDMI_MUX_EN gpio is requested. If an error occurs, the same name
should be printed (HDMI_MUX_EN) instead of HDMI_MUX_SEL (typo).
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Rob Clark <robdclark@gmail.com>
lpm-mux is programmed to enable HDMI connector
on the docking station for S805 chipset based
devices.
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
misc core patches picked up by Daniel and Jani.
* tag 'topic/core-stuff-2014-06-30' of git://anongit.freedesktop.org/drm-intel:
drm/fb-helper: Remove unnecessary list empty check in drm_fb_helper_debug_enter()
drm/fb-helper: Redundant info->fix.type_aux setting in drm_fb_helper_fill_fix()
drm/debugfs: add an "edid_override" file per connector
drm/debugfs: add a "force" file per connector
drm: add register and unregister functions for connectors
drm: fix uninitialized acquire_ctx fields (v2)
drm: Driver-specific ioctls range from 0x40 to 0x9f
drm: Don't export internal module variables
The clock driver usually complains when a clock is being prepared
before setting its rate. It is the case here for "core_clk" which
needs to be set at 19.2 MHz before we attempt a prepare_enable().
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Introduce generic functions to register and unregister connectors. This
provides a common place to add and remove associated user space
interfaces.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hotplug detect and irq does not seem to be reliable on all devices
for some reason. For now it is more reliable to use polling, and give
preference to raw gpio status if it disagrees with the debounced hpd
status.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The HDMI block is basically the same between older SoC's with mdp4
display controller, and newer ones with mdp5.
So mostly this consists of better abstracting out the different sets of
regulators, clks, etc. In particular, for regulators and clks we can
split it up by what is needed for hot plug detect to work, and what is
needed to light up the display.
Also, 8x74 has a new phy.. a very simple one, but split out into a
different mmio space. And with mdp5, the irq is shared with mdp, so we
don't directly register our own irq handler.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Drop the msm_connector base class, and special calls to base class
methods from the encoder, and use instead drm_bridge. This allows for a
cleaner division between the hdmi (and in future dsi) blocks, from the
mdp block.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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>
Boris Brezillon