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>
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>
->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>
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>
Arnd Bergmann