Make the following changes in the HDMI gpio bindings:
- Use "-gpios" as the suffix for all the gpio names
- Move all the gpios to optional, since there are platforms that use none
of them.
- The HPD gpio is a standard one, remove the "qcom,hdmi-tx-" prefix from
it.
- Remove the HDMI DDC clk/data gpios. They are just leftovers of an old
way to configure pinctrl properties.
- Add a missing lpm gpio used on some platforms.
Make the necessary changes in the driver to incorporate these changes.
There hasn't been any upstream DT that uses the HDMI bindings, so it's
okay to change and move around these properties.
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR.
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This patch adds support to generic audio codec via
ASoC hdmi-codec infrastucture which is merged recently.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
[rebased on efc9194]
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>
Remove the old PHY ops managed by hdmi_platform_config and use them as ops
provided by the HDMI PHY driver.
Remove the old HDMI 8960 PLL code that used the top level HDMI TX mmio
base.
NOTE: With this commit, HDMI functionality will break until the HDMI
PHY/PLL register offsets in hdmi.xml.h aren't updated to be used as
separate domains.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Make HDMI core get its PHY by parsing the "phys" phandle. The core will use
this PHY reference to enable/disable PHY. The driver defers probe until PHY
isn't available.
The DT bindings used here is the same as the one used for PHYs using the
common PHY framework bindings.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Create a PHY device that represents the TX PHY and PLL parts of the HDMI
block.
This makes management of PHY specific resources (regulators and clocks)
much easier, and makes the PHY and PLL usable independently. It also
simplifies the core HDMI driver, which currently assigns phy ops among
many other things.
The PHY driver implementation done here is very similar to the PHY driver
we already have for DSI.
Keep the old hdmi_phy_funcs ops for now. The driver will use these until
the HDMI PHY/PLL register offsets aren't considered as separate
domains (i.e. their offsets start from 0).
The driver doesn't use the common PHY framework for now. This is because
it's hard to map our ops with the ops provided by the framework. The
bindings used for this is the generic phy bindings. So, this can be
adapted to the PHY framework in the future, if possible.
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>
We now only care about kernels that support DT. Remote the non-DT stuff.
While we're at it, use of_device_get_match_data to retrieve match data.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The HDMI controller is new in MDP5 v1.7. As of now, this change
doesn't reflect the novelty and only adds the basics so the probe
gets triggered.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For all of these devices, msm89xy was the lead chip, so standardize the
compatible names to align with convention used by rest of the qcom/msm
drivers.
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>
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>
In the same idea mdp5_cfg was added, this change allows us to quickly
add new instances, such as apq8084's HDMI in this case.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change add the regulator/clock configuration for MDP5 v1.3.
This config is close to the one already existing for 8x74, except
that one more regulator is needed (hpd-5v-en).
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of reporting BUG_ON when resources arrays are not
dimensioned correctly, this patch does a dynamic allocation of
these arrays. This is needed for the following patches that add a
regulator for a new target.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling "drm_bridge_add".
The parent encoder driver waits till the bridge is available
in the lookup table(by calling "of_drm_find_bridge") and then
continues with its initialization.
The encoder driver should also call "drm_bridge_attach" to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls "bridge->funcs->attach" so that
bridge can continue with drm related initializations.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.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>
For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the
mdp block. In order to decouple hdmi/eDP/etc, register an irq domain
in mdp5. When hdmi/dsi/etc are used with mdp4, they can directly setup
their irqs in their DT nodes as normal. When used with mdp5, instead
set the mdp device as the interrupt-parent, as in:
mdp: qcom,mdss_mdp@fd900000 {
compatible = "qcom,mdss_mdp";
interrupt-controller;
#interrupt-cells = <1>;
...
};
hdmi: qcom,hdmi_tx@fd922100 {
compatible = "qcom,hdmi-tx-8074";
interrupt-parent = <&mdp>;
interrupts = <8 0>; /* MDP5_HW_INTR_STATUS.INTR_HDMI */
...
};
There is a slight awkwardness, in that we cannot disable child irqs
at the mdp level, they can only be cleared in the child block. So
you must not use threaded irq handlers in the child. I'm not sure
if there is a better way to deal with that.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Split up hdmi_init() into hdmi_init() (done at hdmi sub-device
bind/probe time) and hdmi_modeset_init() done from master driver's
modeset_init().
Anything that can fail due to dependencies on other drivers which
may be missing or not probed yet should go in hdmi_init(), so that
devm error/cleanup paths work properly.
Signed-off-by: Rob Clark <robdclark@gmail.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUFjfVAAoJEHm+PkMAQRiGANkIAIU3PNrAz9dIItq8a/rEAhnx
l2shHoOyEmyNR2apholM3BPUNX50cbsc/HGdi7lZKLkA/ifAj6B9nFD2NzVsIChD
1QWVcvdkKlVuxXCDd26qbijlfmbTOAWrLw9ntvM+J6ZtECM6zCAZF4MAV/FwogPq
ETGKD76AxJtVIhBMS99troAiC1YxmQ7DKgEr8CraTOR1qwXEonnPCmN/IZA6x2/G
EXiihOuQB5me1X7k4PI0V8CDscQOn+3B2CQHIrjRB+KiTF+iKIuI8n6ORC6bpFh+
U8UZP9wLlIG1BrUHG83pIndglIHotqPcjmtfl1WGrRr2hn7abzVSfV+g5Syo3Vg=
=Ep+s
-----END PGP SIGNATURE-----
drm: backmerge tag 'v3.17-rc5' into drm-next
This is requested to get the fixes for intel and radeon into the
same tree for future development work.
i915_display.c: fix missing dev_priv conflict.
There is currently a nested function in Russel King's tree
for the msm HDMI driver.
The last nested function was removed from the Linux kernel
when the Thinkpad driver was fixed.
I believe nested functions are not desired upstream, and it
also breaks compilation with clang so here is a patch to
change the nested function into static function. The patch
works with both clang and gcc.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
LVDS panel support uses the LCDC (parallel) encoder. Unlike with HDMI,
there is not a separate LVDS block, so no need to split things into a
bridge+connector. Nor is there is anything re-used with mdp5.
Note that there can be some regulators shared between HDMI and LVDS (in
particular, on apq8064, ext_3v3p), so we should not use the _exclusive()
variants of devm_regulator_get().
The drm_panel framework is used for panel-specific driver.
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>
Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
add necessary DT support so that we can use drm/msm on upstream kernel.
v2: update for review comments
v3: rebase on component helper changes
Signed-off-by: Rob Clark <robdclark@gmail.com>
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>
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>
This adds the necessary configuration for the APQ8060A SoC (dual-core
krait + a320 gpu) as found on the bstem board.
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>
Archit Taneja