| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
HDMI 2.0 compliance E-DDC test requires the DDC
signal timings to meet a minimum threshold to pass
the compliance test. Current DDC settings were not
matching the requirement.
Adjust the DDC settings to meet the threshold and
also make sure to leave the remaining bits of DDC
speed register untouched.
Change-Id: I1eb9304f219906e48f8dec988cd818b879911e71
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
|
| |
|
|
|
|
|
|
|
| |
Adding a new "HPD_OFF" atomic property for the SDE Connector
which enables or disables the hpd related clocks for the hdmi
display
Change-Id: Ie46c97ae0db9bad231acf7efc660499bac28f45a
Signed-off-by: Navid Bahrani <nbahrani@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 8996 AUTO platform, too many "hdmi_i2c_xfer" warnings appear
when booting that makes boot time longer and may cause watchdog
bite. The warning is generated by WARN_ON() in hdmi_i2c_xfer()
which prints call stack like:
hdmi_i2c_xfer+0x44/0x398
__i2c_transfer+0x270/0x4b4
i2c_transfer+0x64/0xb0
hdmi_ddc_read+0x84/0xdc
sde_hdmi_scdc_write+0xac/0x178
_sde_hdmi_bridge_mode_set+0x928/0xa34
drm_bridge_mode_set+0x30/0x54
complete_commit+0x448/0x938
_msm_drm_commit_work_cb+0xb0/0x1a0
kthread_worker_fn+0xcc/0x170
kthread+0xf8/0x100
ret_from_fork+0x10/0x20
The reason is the HDMI_CTRL_ENABLE bit of REG_HDMI_CTRL register
is disabled during the reset by the first commit. This reset is
caused by the missing of HPD regulator enabling in HPD call sequence.
So to remove the HDMI i2c warning, the patch enables HPD regulator
to avoid the reset.
Change-Id: I91e853535a972f241c7aa2d28c05785569ae23db
CRs-fixed: 2093649
Signed-off-by: Yujun Zhang <yujunzhang@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
PLL_ENABLE property is used to enable or disable the PLL
update function. With this property PLL update function
only works when PLL_ENABLE is set, and all changes done
to hardware will be discarded once PLL_ENABLE is cleared.
CRs-Fixed: 2042852
Change-Id: Ia321918382b8622101cff566049284810833f63e
Signed-off-by: Ray Zhang <rayz@codeaurora.org>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Separate out the DRM HDMI utility functions into a separate
module.
Make the DRM HDMI utility functions support self retry where
they shall try for an arbitrary number of times on failure
otherwise let the client call the API to retry the number of
times as warranted.
Add a SDE HDMI utility file which shall invoke the upstream
functions in a manner as required to maintain the functionality
of legacy drivers.
Change-Id: I64af3f997a16b2d9358ea867585aa12772d22599
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
HDMI driver currently maps register addresses using ioremap()
but doesn't use the SDE driver utilities for register read/write.
Copy the mapped register spaces to SDE utility headers so that
other SDE APIs can be used seamlessly for HDMI.
Change-Id: I3cbe57778ff3a63ffd9176f1a2c60778238e3fe2
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
|
| |/
|
|
|
|
|
|
| |
When HDMI resolution is bigger than 2560 pixel of width, driver
needs to use two hardware pipes. Use virtual plane to support this feature.
Change-Id: I19e3bb32aa2a16c83393b0e3c6bec3db03827eca
Signed-off-by: wyun <wyun@codeaurora.org>
|
| |
|
|
|
|
|
|
|
| |
To support 4k@60fps resolution through HDMI, enable
scrambler feature from HDMI controller and communicate
it with sink device through DDC.
Change-Id: I17750db358df58499303ef9d735bf3301b02a7c1
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
When HDMI controller is configured as non-DVI with CEA mode, SDE
driver needs to program AVI, VSIF and SPD information into HW to
generate correct info frame.
CRs-Fixed: 2010135
Change-Id: Ib218761c63b13aa229fc24519ceb9ccd0bd34ce2
Signed-off-by: Jin Li <jinl@codeaurora.org>
Signed-off-by: Ray Zhang <rayz@codeaurora.org>
|
| |
|
|
|
|
|
|
|
| |
msm8998 needs an additional 5V pin to be
enabled to power the HPD circuit. This change
enables the support for this pin.
Change-Id: I42f91265ce56ff5505e3d9c2382858fe6c1be52b
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Add initial HDMI display driver support for SDE.
Support for configuring the HDMI TX controller
to specific resolutions. Add support for HDMI specific
ISR, uevent handling, basic debugfs support.
Add support for HDMI DRM specific calls for SDE driver.
Change-Id: I0cf7f4067e1a9b378632713b896798971971e5b9
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
| |
Pull in additional regs needed for a430, etc.
Change-Id: Ic0dedbada256c546268b2a19556a78e8912d06e4
Signed-off-by: Rob Clark <robdclark@gmail.com>
Git-commit: a2272e48eef02869dc3fa031720f36dd4cb05e4f
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
HDCP hdmi is an optional feature in DRM
and it is not needed at bringup stage. Remove
this driver from compilation from drm to
avoid any issues. It will be re-enabled when
complete feature set is supported.
This change also update the HDCP API name to
avoid conflict with FB HDCP driver.
Change-Id: I788747750e7f586c58fe0d0bd3b5a4d223adfb96
Signed-off-by: Dhaval Patel <pdhaval@codeaurora.org>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
->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>
|
| |
|
|
| |
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>
|
| |
|
|
| |
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
| |
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
Resync from rnndb database, to pull in register defines for:
* eDP
* HDMI/HDCP
* mdp4/mdp5 YUV support
* mdp5 hw cursor support
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
| |
|
|
|
|
|
|
| |
3d3f8b1f8b ("drm/bridge: make bridge registration independent of drm
flow") resulted that the hdmi bridge object would be leaked at teardown.
Just switch over to devm_kzalloc() as the easy way to solve this.
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assign the pointer to bridge ops structure(drm_bridge_funcs) in
the bridge driver itself, instead of passing it to drm_bridge_init.
This will allow bridge driver developer to pack bridge private
information inside the bridge object and pass only the drm-relevant
information to drm_bridge_init.
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>
|
| |
|
|
|
|
|
| |
Disable the HPD interrupt when acking it, to avoid spurious
interrupt.
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
|
| |
|
|
|
|
|
| |
HPD regulators need to be enabled before clocks, otherwise clock
driver will report warning.
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
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>
|
| |
|
|
| |
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
| |\
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
| |
In particular, pick up the definitions for a handful of LVDS related
registers.
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>
|
| |
|
|
|
|
|
|
| |
On downstream kernel the clk driver directly bangs hdmi phy registers.
For upstream kernel, we need to model this as a clock and register with
the clock framework.
Signed-off-by: Rob Clark <robdclark@gmail.com>
|