This patch implements the hardware accelarated cursor
support for MDP5 platforms.
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@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>
mdp5_ctl_set_intf()'s second argument should be "int", not "enum mdp5_intf".
The passed in value is "intf", not "intf_id".
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Modified the hard-coded hdmi connector/encoder implementations in msm drm
driver to support both edp and hdmi.
V1: Initial change
V2: Address Thierry's change
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change adds a new eDP connector in msm drm driver. With this
change, eDP panel can work with msm platform under drm framework.
v1: Initial change
v2: Address Rob's comments
Use generated header file for register definitions
Change to devm_* APIs
v3: Address Thierry's comments and rebase on top of atomic changes
Remove edp_bridge_mode_fixup
Remove backlight control code and rely on pwm-backlight
Remove continuous splash screen support for now
Change to gpiod_* APIs
v4: Fix kbuild test issue
Signed-off-by: Hai Li <hali@codeaurora.org>
[robclark: v5: rebase on drm_bridge changes in drm-next]
Signed-off-by: Rob Clark <robdclark@gmail.com>
The patch add support for YUV frame format
for MDP4 platform.
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change adds the NV12 format support for public planes.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Both MDP4 and MDP5 share some code as far as YUV support is
concerned. This change adds this information and will be followed
by the actual MDP4 and MDP5 YUV support patches.
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>
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
[robclark: drop stray ')']
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>
Only the legacy helpers use these entry points. Don't populate them
with transitional helpers, since that just makes things more confusing.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[robclark: reword commit msg]
Signed-off-by: Rob Clark <robdclark@gmail.com>
We had _power_up(), but drivers also need to be able to power down.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The atmel-hlcdc driver selects DRM_GEM_CMA_HELPER which makes use of
symbols only available when HAVE_DMA_ATTRS is selected.
Add a dependency on the ARM architecture which select this option.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The msm gpu drivers depend on both the DT mechanism and the
common clk handling code, if they are not enabled, we get
a number of build errors:
In file included from drivers/gpu/drm/msm/hdmi/hdmi.h:27:0,
from drivers/gpu/drm/msm/hdmi/hdmi_bridge.c:18:
drivers/gpu/drm/msm/msm_drv.h:45:24: fatal error: mach/board.h: No such file or directory
#include <mach/board.h>
^
drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c:503:2: error: implicit declaration of function 'devm_clk_register' [-Werror=implicit-function-declaration]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
When page flipping, we need to mark the new fb as active and unmark the active
flag for the old fb (if different).
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The shmobile drm driver selects BACKLIGHT_CLASS_DEVICE
as of 0a5a5499ad "drm: shmobile: Add dependency on
BACKLIGHT_CLASS_DEVICE", but that option in turn depends
on BACKLIGHT_LCD_SUPPORT, so we actually have to select
both, or alternatively use 'depends on BACKLIGHT_CLASS_DEVICE'.
Further, the driver uses FB_SH_MOBILE_MERAM if that is
enabled, but this breaks if MERAM is a module while
the DRM driver is built-in. To solve this, add a dependency
on "FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM", which forces
DRM_SHMOBILE to be a module if FB_SH_MOBILE_MERAM set to 'm'.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The newly added sti driver requires the drm_panel helpers,
and we get a link error if they are not enabled
ERROR: "drm_panel_attach" [drivers/gpu/drm/sti/stidvo.ko] undefined!
ERROR: "of_drm_find_panel" [drivers/gpu/drm/sti/stidvo.ko] undefined!
This adds a 'select' statement as we have for the other drivers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
When the reset controller subsystem is disabled, this driver
fails to build:
drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function 'vop_initial':
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1267:2: error: implicit declaration of function 'devm_reset_control_get' [-Werror=implicit-function-declaration]
The easiest solution is to add a dependency in Kconfig to avoid
that case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The simple panel code uses the backlight interface to
find a device, which fails when backlight is disabled:
drivers/built-in.o: In function `panel_simple_platform_probe':
:(.text+0xd3c48): undefined reference to `of_find_backlight_by_node'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The sharp panel code uses the backlight interface to
find a device, which fails when backlight is disabled:
drivers/built-in.o: In function `sharp_panel_probe':
:(.text+0x5ceac): undefined reference to `of_find_backlight_by_node'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The run-length encoding algorithm should compare 16-bit encoded pixel
values instead of comparing raw pixel values. It allows pixels
with similar but different colors to be encoded as repeat pixels, and
thus potentially save USB bandwidth.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Haixia Shi <hshi@chromium.org>
Signed-off-by: Dave Airlie <airlied@gmail.com>
This backmerges drm-fixes into drm-next mainly for the amdkfd
stuff, I'm not 100% confident, but it builds and the amdkfd
folks can fix anything up.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Conflicts:
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
Commit fbc4572e9c48e45b ("drm/bridge: make bridge registration independent of
drm flow") introduced some drm/bridge API modifications. Make the necessary
changes so that we can avoid the build breakage:
drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_bridge_destroy':
drivers/gpu/drm/bridge/dw_hdmi.c:1378:2: error: implicit declaration of function 'drm_bridge_cleanup' [-Werror=implicit-function-declaration]
drivers/gpu/drm/bridge/dw_hdmi.c: At top level:
drivers/gpu/drm/bridge/dw_hdmi.c:1471:2: error: unknown field 'destroy' specified in initializer
drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_register':
drivers/gpu/drm/bridge/dw_hdmi.c:1535:2: error: implicit declaration of function 'drm_bridge_init' [-Werror=implicit-function-declaration]
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
So sti doesn't build because the bridge interfaces changes didn't
catch up to its new DVO driver.
Now I might just carry this patch, but I might just push the
bridge pull into a side-pull until someone resolves it.
So this might not be the right solution to the problem, so
please figure it out and let me know ASAP.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
If devm_request_threaded_irq() fails we should jump to 'err_iahb' label that
will disable the clocks that were previously enabled.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When setting the video bus supported formats for a display device using
drm_display_info_set_bus_formats(), check for the proper variable after
duplicating memory.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Force bridge connector detection at the end of the bridge attach.
This is needed to detect the bridge connector early.
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>
Add drm_panel calls to the driver to make the panel and
bridge work together in tandem.
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>
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>
This patch does the following changes:
-- Use usleep_range instead of udelay.
-- Remove driver_private member from ptn3460 structure.
-- Make all possible functions and structures static.
-- Use dev_err for non-DRM errors.
-- Arrange header files alphabetically.
-- s/edid/EDID in all error messages.
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>
The Shanghai AVIC Optoelectronics TM070DDH03 is a 7" 1024x600 TFT LCD
panel connecting to a 24-bit RGB LVDS interface.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Before shutting down the display using the DCS display_off command, wait
for 4 frames according to the datasheet.
Furthermore, after enabling the power supply, the supply voltage needs
around 10 ms to settle. After that, another 120 ms is required before a
DCS exit_sleep_mode command can be sent.
While at it, no longer send the DCS soft_reset command. This is totally
unnecessary because we've just powered up the display, hence it will be
in a reset state already.
Signed-off-by: Thierry Reding <treding@nvidia.com>
After switching the display on (using the DCS display_on command), wait
for 6 frames (100ms at 60 Hz) to give the display more time to prepare.
Failing to do this results in the panel not initializing properly in a
large number of cases.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch adds support for the GiantPlus GPG48273QS5 4.3" WQVGA TFT LCD
panel to the simple-panel driver.
This panel is connected via a parallel bus and uses both HSYNC and
VSYNC, whose lengths are unfortunately not clearly defined. The
datasheet only specifies the front- and backporch length, but the timing
diagram suggests that both sync signals should be asserted for exactly
one clock cycle.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The mipi_dsi_packet_create() function dereferences the msg pointer
before checking that it's valid. Move the dereference down to where it
is required to avoid potentially dereferencing a NULL pointer.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The biggest part of these changes is the conversion to atomic mode-
setting. A lot of cleanup and demidlayering was required before the
conversion, with the result being a whole lot of changes.
Besides the atomic mode-setting support, the host1x bus now has the
proper infrastructure to support suspend/resume for child devices.
Finally, a couple of smaller cleanup patches round things off.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUx1hgAAoJEN0jrNd/PrOhpOIQAI7YAJUX7465R59vkjXOV3uP
lGMj75v22Wq2Y3poPNyxnn562W0feKVBPf13oWgZvzK1fk3+eXoVmL2F395VYXjz
rsGhJJe+/z8gtBgNXH0l6jzvQwRHzLCoMpt9Egrzbij6S+BShQZvnwg5Gyws6vBe
ZnpTjxJKZD4ADY5G1J/EFmBAW3B3abZqOLGHohbUSeN/rr3VP92eG7vnPDW8Rrry
UuBJkjdkR49cfnEvz4pCEoiucftIja7y0YhkDy6estPnO3JBDQ01tCI6HvA6CT1k
6wCkWOnPXJ1Uy1OcXgMU59azJ7d8wdwXFWCXc5yWwIj47ZmY6OjwyJfURmrlQ6nb
8lxeedCBgmTLF6sB9g8g117HWCM3InUXOeN4EhkcF6el9X+ZOAlIJO2RllfL8Bwn
O0GXgCmeeeoZG6aLpULEnAZhJZ92nvo2Zn5lddk7uiaU09Xdzc4kKN3FzYS0XtfJ
7A32m/DNPQi9yJnFFK2sWrrSBnHcDd0Cq17/V1VTcP6iV3CtRWIDX7co0QHE+EQl
7xjj2rlFEyWcvD+9pUoYEgDDCuzjy41zCQ53vj+h2xDO6maksqT1vJ1Nz8y9JmQI
F52aU+DyHleP3q0u9CmeFIo1ft5ho7IgzPJXHPqir/QcnxqiqDprEM70bQwVdF+y
iVvngQ3xfkH2RaqOwen0
=k0/3
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.20-rc1
The biggest part of these changes is the conversion to atomic mode-
setting. A lot of cleanup and demidlayering was required before the
conversion, with the result being a whole lot of changes.
Besides the atomic mode-setting support, the host1x bus now has the
proper infrastructure to support suspend/resume for child devices.
Finally, a couple of smaller cleanup patches round things off.
* tag 'drm/tegra/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux: (54 commits)
drm/tegra: Use correct relocation target offsets
drm/tegra: Add minimal power management
drm/tegra: dc: Unify enabling the display controller
drm/tegra: Track tiling and format in plane state
drm/tegra: Track active planes in CRTC state
drm/tegra: Remove unused ->mode_fixup() callbacks
drm/tegra: Atomic conversion, phase 3, step 3
drm/tegra: Atomic conversion, phase 3, step 2
drm/tegra: dc: Use atomic clock state in modeset
drm/tegra: sor: Implement ->atomic_check()
drm/tegra: hdmi: Implement ->atomic_check()
drm/tegra: dsi: Implement ->atomic_check()
drm/tegra: rgb: Implement ->atomic_check()
drm/tegra: dc: Store clock setup in atomic state
drm/tegra: Atomic conversion, phase 3, step 1
drm/tegra: Atomic conversion, phase 2
drm/tegra: Atomic conversion, phase 1
drm/tegra: dc: Do not needlessly deassert reset
drm/tegra: Output cleanup functions cannot fail
drm/tegra: Remove remnants of the output midlayer
...
When copying a relocation from userspace, copy the correct target
offset.
Signed-off-by: David Ung <davidu@nvidia.com>
Fixes: 961e3beae3 ("drm/tegra: Make job submission 64-bit safe")
Cc: stable@vger.kernel.org
[treding@nvidia.com: provide a better commit message]
Signed-off-by: Thierry Reding <treding@nvidia.com>
For now only disable the KMS hotplug polling helper logic upon suspend
and re-enable it on resume.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Mark Zhang <markz@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Previously output drivers would enable continuous display mode and power
up the display controller at various points during the initialization.
This is suboptimal because it accesses display controller registers in
output drivers and duplicates a bit of code.
Move this code into the display controller driver and enable the display
controller as the final step of the ->mode_set_nofb() implementation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
