The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Currently forcing the video mode from the kernel command line (for example
video=HDMI-A-1:1280x720-16@60) does not correctly set the number of bits
per pixel. This is due to a rather aggressive override in
msm_fbdev_create(). This is a particular problem for Android bring up
because the software EGL fallbacks don't support 32bpp.
Since the overrides are actually the default values anyway then this
problem can be trivially fixed by removing the overrides completely.
Change was tested by dd'ing a test image to /dev/fb0 with no video=
(still 32bpp), video=1920x1080-32@60, video=1920x1080-24@60 and
video=1920x1080-16@60 .
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add the missing unlock before return from function msm_fbdev_create()
in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change implements msm drm specific fb_mmap function for fb device
to properly map the fb address to userspace.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com> (+ minor comment tweak)
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch helps to avoid the following build issue:
drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of 'msm_gem_get_iova_locked' from incompatible pointer type [-Werror]
msm_gem_get_iova_locked(fbdev->bo, 0, &paddr);
^
In file included from drivers/gpu/drm/msm/msm_fbdev.c:18:0:
drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id,
^
Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since X11 is going to create an XR24 fb, if the pixel formats do not
match then crtc helpers will think it is a full modeset even if mode is
the same, which prevents smooth/flickerless handover from fbcon/plymouth
to X11.
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>
Markus Elfring