Age | Commit message (Collapse) | Author | Files | Lines |
|
We no longer have any boards that require the platform data support from
the panel, so we can remove the related code.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
We no longer have any boards that require the platform data support from
the panel, so we can remove the related code.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
We no longer have any boards that require the platform data support from
the connector, so we can remove the related code.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
We no longer have any boards that require the platform data support from
the connector, so we can remove the related code.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
We no longer have any boards that require the platform data support from
the encoder, so we can remove the related code.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
We no longer have any boards that require the platform data support from
the panel, so we can remove the related code.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
core.c is the only caller of dss_disable_all_devices(). We can thus move
the function from display.c to core.c and make it static.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
For legacy reasons omapdss handles system suspend/resume via PM notifier
callback, where the driver disables/resumes all the outputs.
This doesn't work well with omapdrm. What happens on suspend is that the
omapdss disables the displays while omapdrm is still happily continuing
its work, possibly waiting for an vsync irq, which will never come if
the display output is disabled, leading to timeouts and errors sent to
userspace.
This patch moves the suspend/resume handling to omapdrm, and the
suspend/resume is now done safely inside modeset lock.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omapdrm is missing a check on the validity of the rotation property.
This leads to omapdrm possibly trying to use rotation on non-rotateable
framebuffer, which causes the overlay setup to fail.
This patch adds the necessary check to omap_plane_atomic_check().
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
Before universal planes we had to have plane specific properties for the
crtc too, as on the hardware level a crtc uses a plane. In other words,
e.g. 'zorder' property was added to both planes and crtcs, and
omap_crtc.c would delegate the property set/get to the primary plane.
However, the delegation was a bit too generic, delegating all property
set/get calls to planes. Thus it's possible to set, say, FB_ID, on a
crtc, which gets redirected to the primary plane.
This is not standard, and shouldn't be allowed. To keep backward
compatibility, we still need to redirect the properties we supported
earlier for crtcs, namely 'zorder' and 'rotation'.
This patch redirects only the allowed properties from crtcs to planes.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
Subsequent threads returning EBUSY from vm_insert_pfn() was not
handled correctly. As a result concurrent access from new threads
to mmapped data caused SIGBUS.
See e79e0fe380847493266fba557217e2773c61bd1b ("drm/i915: EBUSY status
handling added to i915_gem_fault()").
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
The DSS hardware uses the same ROW_INC value for both Y and UV planes
for NV12 format. This means that the pitches of the Y and UV planes have
to match. omapdrm doesn't check this at the moment, and this can lead
into a broken NV12 fb on the screen.
This patch adds the check.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
DISPC requires the x resolution to be divisible by 8 when stall mode is
not used.
Add a check to the DPI driver to verify this.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
Now that interlace support has been added, we can remove the check that
prevents interlace.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
Add the missing bits for interlace:
* Set VBLANK_OSC if the videomode's vblank is fractional
* Halve the vertical timings for interlace
* Double the horizontal timings for double-pixel mode
* Set FC_PRCONF properly for double-pixel mode
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
The HDMI driver copies the timing values one by one. Instead we can just
copy the whole struct.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
For some reason the HDMI FC's HSW value is programmed to hsw-1. There's
no indication in the documentation that this would be correct, and no
other blanking value needs -1 either.
So remove the -1.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
Interlace field order is different between VENC and HDMI. The driver
currently sets the field order for VENC.
This patch adds the code to set the field order for HDMI.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
The HDMI WP timings are not programmed correctly for interlace.
We need to halve the vertical timings when interlace is used, and double
the horizontal timings when pixel doubling is used.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
On OMAP4 and OMAP5 ES1.0 the HDMI_WP_VIDEO_TIMING_H:HSW field is
set directly to the HSW value. On later SoCs the field needs to be
programmed with the value of HSW-1.
Currently the driver always programs the field with the HSW value. Most
videomodes seem to work fine with that, but at least low resolution
interlaced modes don't work at all.
This patch fixes the HSW for OMAP5 ES2.0+ SoCs.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
We need double-pixel mode (pixel repetition) for interlace modes. This
patch adds the necessary support to HDMI to double the pixel clock when
double-pixel mode is used.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
We need double-pixel mode (pixel repetition) for interlace modes. This
patch adds the necessary support to omapdrm to output double-pixel mode.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
We need double-pixel mode (pixel repetition) for interlace modes. This
patch adds the necessary support to DISPC to output double-pixel mode.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
omap_crtc_wait_pending() waits until the config changes have been taken
into use, usually at next vblank. The wait-timeout used is 50ms, which
usually is enough, but in some rare cases not.
As time wait-timeout is just a safety measure for cases where something
is broken, we can just as well increase the timeout considerably.
This patch makes the timeout 250ms.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
We no longer have the omapdrm plugin system for SGX, and we can thus
remove the support for external memory and sync objects from omap_gem.c.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
OMAP GEM objects backed by dma_buf reuse the current OMAP GEM object
support as much as possible. If the imported buffer is physically
contiguous its physical address will be used directly, reusing the
OMAP_BO_MEM_DMA_API code paths. Otherwise it will be mapped through the
TILER using a pages list created from the scatterlist instead of the
shmem backing storage.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Split the individual steps of GEM object allocation and initialization
clearly. This improves readability and prepares for dma_buf import
support.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The driver assumes that only objects backed by shmem need to be mapped
through DMM. While this is true with the current code, the assumption
won't hold with dma_buf import support.
Condition the mapping based on whether the buffer has been allocated
using the DMA mapping API instead and clean up the flags to avoid having
to check both flags and GEM object filp field to decide how to process
buffers. Flags are not the authoritative source of information regarding
where the buffer memory comes from, and are renamed to make that
clearer.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
If the panel's enable fails, omap_encoder silently ignores the failure.
omapdrm should really handle the failure, but unfortunately the whole
encoder enable codepath is expected to always succeed.
So for now, catch the enable failure and print an error.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
omap_gem_dma_sync() calls dma_map_page() but does not check the possible
error with dma_mapping_error(). If DMA-API debugging is enabled, the
debug layer will give a warning if dma_mapping_error() has not been
used.
This patch adds proper error handling to omap_gem_dma_sync().
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
omap_gem_attach_pages() calls dma_map_page() but does not check the
possible error with dma_mapping_error(). If DMA-API debugging is
enabled, the debug layer will give a warning if dma_mapping_error() has
not been used.
This patch adds proper error handling to omap_gem_attach_pages().
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
tpd12s015 HW has LS_OE, CT_CP_HPD and HPD gpios. Out of these gpios,
driver only handled LS_OE as optional. The CT_CP_HPD gpio should also
be treated as optional gpio as it is just a power saving feature. Some
boards hardwire this gpio to be always enable. In this patch, all access
to CT_CP_HPD gpio is made optional.
Signed-off-by: Manisha Agrawal <[email protected]>
Acked-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
Migrated the gpio APIs to descriptor-interface based.
Signed-off-by: Manisha Agrawal <[email protected]>
Acked-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
All devices using tpd12s015 driver are doing DT boot. No need of further
supporting the platform data. This patch removes support for platform
data.
Signed-off-by: Manisha Agrawal <[email protected]>
[[email protected]: minor adjustments]
Acked-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
drm_atomic_get_plane_state() may return ERR_PTR. Handle
drm_atomic_get_plane_state() return values right in
omap_crtc_atomic_set_property().
Signed-off-by: Jyri Sarha <[email protected]>
Acked-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
This patch adds wrapper functions for readl() and writel(), dmm_read()
and dmm_write(), so that we can implement workaround for DRA7 errata
i878.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
The current driver uses non-blocking DMM fill when releasing memory.
This gives us a small performance increase as we don't have to wait for
the fill operation to finish.
However, the driver does not have any error handling for non-blocking
fill. In case of an error, the fill operation may silently fail, leading
to leaking DMM engines, which may eventually lead to deadlock if we run
out of DMM engines.
This patch makes the DMM driver always use blocking fills, so that we
can catch the errors. A more complex option would be to allow
non-blocking fills, and implement proper error handling, but that is
left for the future.
This patch is a HACK, as the proper fix is to either decide to always
use sync fills and remove all the async related code, or fix the async
code.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
We occasionally see DISPC sync-lost errors when enabling and disabling
HDMI. Sometimes we get only a few, which get handled (ignored) by the
driver, but sometimes there's a flood of the errors which doesn't seem
to stop.
The HW team has root caused this to the order in which HDMI and DISPC
are enabled/disabled. Currently we enable HDMI first, and then DISPC,
and vice versa when disabling. HW team's suggestion is to do it the
other way around.
This patch changes the order, but this has two side effects as the pixel
clock is produced by HDMI, and the clock is not running when we
enable/disable DISPC:
* When enabling DISPC first, we don't get vertical sync events
* When disabling DISPC last, we don't get FRAMEDONE event
At the moment we use both of those to verify that DISPC has been
enabled/disabled properly. Thus this patch also needs to change the
omapdrm and omapdss which handle the DISPC side.
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
|
|
The STi drm driver correctly warns about invalid format strings
when built with 64-bit dma_addr_t:
sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
sti_hqvdp.c:605:119: warning: format '%x' expects argument of type
'unsigned int', but argument 5 has type 'dma_addr_t {aka long long
unsigned int}' [-Wformat=]
sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
sti_hqvdp.c:931:118: warning: format '%x' expects argument of type
'unsigned int', but argument 5 has type 'dma_addr_t {aka long long
unsigned int}' [-Wformat=]
This could be changed to using the %pad format string, but that
does not work when printing an rvalue, so instead I'm changing
the type in the sti_hqvdp structure to u32, which is what gets
written into the registers anyway.
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Vincent Abriou <[email protected]>
|
|
Thanks to "drm: prime: Honour O_RDWR during prime-handle-to-fd"
commit we don't need to hack flags anymore.
Signed-off-by: Benjamin Gaignard <[email protected]>
Reviewed-by: Vincent Abriou <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
|
|
Fix some copy paste typos.
Signed-off-by: Flora Cui <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
into drm-fixes
Fixes for radeon and amdgpu:
- Fix GPUVM flushing on CI and VI
- Misc DPM and Powerplay fixes
- VCE DPM fixes for CZ/ST
- DP hotplug fix
* 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: return from atombios_dp_get_dpcd only when error
drm/amdgpu/cz: remove commented out call to enable vce pg
drm/amdgpu/powerplay/cz: enable/disable vce dpm independent of vce pg
drm/amdgpu/cz: enable/disable vce dpm even if vce pg is disabled
drm/amdgpu/gfx8: specify which engine to wait before vm flush
drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well
drm/amd/powerplay: send event to notify powerplay all modules are initialized.
drm/amd/powerplay: export AMD_PP_EVENT_COMPLETE_INIT task to amdgpu.
drm/radeon/pm: update current crtc info after setting the powerstate
drm/amdgpu/pm: update current crtc info after setting the powerstate
|
|
VDD regulator input was specified for MSM8916. It turns our that this
regulator is used for the display panels used on MSM8916 platforms, but
not the DSI controller itself. Drop this regulator from the list.
Reported-by: Vinay Simha <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
With the implementation of of_graph parsing, it isn't any longer
necessary for msm_host->device node to be same as dsi->dev.of_node. This
only holds true when the connected device is also a child of the dsi_host.
In the case of external bridge chips belonging to a different control
bus, these are guaranteed to be different.
Signed-off-by: Archit Taneja <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
We have a msm_fbev_free function to uninit fb_helper stuff, but we aren't
using it. Call it in msm_unload.
Signed-off-by: Archit Taneja <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
attach_dev gets called in mdp4_kms_init, but there is no corresponding
detach_dev called in the error path or in the kms driver unload path.
Detach and destroy mmu in mdp4_destroy.
Signed-off-by: Sricharan R <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Signed-off-by: Rob Clark <[email protected]>
|
|
Assign drm_atomic_helper_crtc_set_property helper to MDP4 and MDP5
crtcs' set_property ops. This replaces the custom funcs that
returned an error even for standard crtc properties.
Signed-off-by: Archit Taneja <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Instead of forcing bridges to implement empty callbacks make them all
optional.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Add support for United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT
LCD panels in the simple-panel driver.
Signed-off-by: Maciej S. Szmigiero <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|