linux-toradex.git/drivers/gpu/drm/tegra/fb.c, branch v4.2-rc8

drm/tegra: Move tegra_drm_mode_funcs to the core

2015-01-27T09:14:44+00:00

This structure will be extended using non-framebuffer related callbacks
in subsequent patches, so it should move to a more central location.

Signed-off-by: Thierry Reding

drm/tegra: fb: Add error codes to error messages

2014-11-13T15:18:34+00:00

This helps in determining what errors happened at specifics points in
the initialization sequence.

Signed-off-by: Thierry Reding

drm/tegra: fb: Properly release GEM objects on failure

2014-11-13T15:18:33+00:00

When fbdev initialization fails, make sure to unreference the GEM
objects properly. Note that we can't do this in the general error
unwinding path because ownership of the GEM object references is
transferred to the framebuffer upon creation.

Signed-off-by: Thierry Reding

drm/tegra: fb: Do not destroy framebuffer

2014-11-13T15:18:32+00:00

Drop a reference instead of directly calling the framebuffer .destroy()
callback at fbdev free time. This is necessary to make sure the object
isn't destroyed if anyone else still has a reference.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding

drm/tegra: Add IOMMU support

2014-11-13T15:14:48+00:00

When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
can then scan out non-contiguous buffers by mapping them through the
IOMMU.

Signed-off-by: Thierry Reding

drm/tegra: Fix error handling cleanup

2014-11-13T15:14:48+00:00

The DRM driver's ->load() implementation didn't do a good job (no job at
all really) cleaning up on failure. Fix that by undoing any prior setup
when an error occurs. This requires a bit of rework to make it possible
to clean up fbdev midway.

This was tested by injecting errors at various points during the
initialization sequence and verifying that error cleanup didn't crash
and no memory leaked (using kmemleak).

Reported-by: Stéphane Marchesin 
Reported-by: Sean Paul 
Reviewed-by: Sean Paul 
Signed-off-by: Thierry Reding

drm/tegra: Properly align stride for framebuffers

2014-08-04T08:07:38+00:00

Tegra20 and Tegra30 both required the buffer line stride to be aligned
on 8 byte boundaries. Tegra114 and Tegra124 increased the alignment to
64 bytes. Introduce a parameter to specify the alignment requirements
for each display controller and round up the pitch of newly allocated
framebuffers appropriately.

Originally-by: Stéphane Marchesin 
Signed-off-by: Thierry Reding

drm/tegra: Implement more tiling modes

2014-08-04T08:07:34+00:00

Tegra124 supports a block-linear mode in addition to the regular pitch
linear and tiled modes. Add support for these by moving the internal
representation into a structure rather than a simple flag.

Tested-by: Alexandre Courbot 
Signed-off-by: Thierry Reding

drm/tegra: Implement race-free hotplug detection

2014-07-08T01:31:36+00:00

A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized yet. This happens
because on some boards the HDMI driver can control the regulator that
supplies the +5V pin on the HDMI connector. Therefore depending on the
timing between the initialization of the HDMI driver and the rest of
DRM, it's possible that the monitor returns the hotplug signal right
within the window where we would miss it.

Unfortunately, drm_kms_helper_poll_init() will wreak havoc when called
before at least some parts of the FB helpers have been set up.

This commit fixes this by splitting out the minimum of initialization
required to make drm_kms_helper_poll_init() work into a separate
function that can be called early. It is then safe to move all of the
poll helper initialization to an earlier point in time (before the
HDMI output driver has a chance to enable the +5V supply). That way if
the hotplug signal is returned before the initial FB helper setup, the
monitor will be forcefully detected at that point, and if the hotplug
signal is returned after that it will be properly handled by the poll
helpers.

Signed-off-by: Thierry Reding 
Signed-off-by: Dave Airlie

drm: Introduce drm_fb_helper_prepare()

2014-07-08T01:31:28+00:00

To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.

At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.

Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
Signed-off-by: Dave Airlie