drm: rcar-du: Expose the VSP1 compositor through KMS planes
On R-Car Gen3 SoCs the DU lost its ability to access memory directly and
needs to work in conjunction with the VSP to do so. This commit handles
the VSP internally to hide it from the user.
Laurent Pinchart [Sat, 24 Aug 2013 00:17:03 +0000 (02:17 +0200)]
drm: rcar-du: Restart the DU group when a plane source changes
Plane sources are configured by the VSPS bit in the PnDDCR4 register.
Although the datasheet states that the bit is updated during vertical
blanking, it seems that updates only occur when the DU group is held in
reset through the DSYSR.DRES bit. Restart the group if the source
changes.
Laurent Pinchart [Fri, 21 Jun 2013 15:36:15 +0000 (17:36 +0200)]
drm: rcar-du: Add VSP1 support to the planes allocator
The R8A7790 DU can source frames directly from the VSP1 devices VSPD0
and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0
or DU0/1 plane 1.
Allocate the correct fixed plane when sourcing frames from VSPD0 or
VSPD1, and allocate planes in reverse index order otherwise to ensure
maximum availability of planes 0 and 1.
Rename plane setup functions using more explicit names, and use local
variables to store intermediate values to increase readability. This
also prepares for VSP compositor support.
drm: rcar-du: Don't update planes on disabled CRTCs
A disabled CRTC can't display planes, the driver shouldn't try to
configure it when updating planes. The DRM core will store the plane
state for us, and the plane will be configured appropriately the next
time the CRTC is enabled.
Laurent Pinchart [Sun, 24 Jan 2016 22:28:11 +0000 (00:28 +0200)]
drm: rcar-du: Remove local CRTC enabled state
The atomic framework guarantees that the CRTC enable and disable
functions will only be called when needed, there's no need to duplicate
the CRTC state check. By replacing the local CRTC enabled state check at
resume time with the CRTC active state we can remove the local CRTC
enabled state altogether.
drm: rcar-du: Perform initialization/cleanup at probe/remove time
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the remove function as
well.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/media/platform/vsp1/vsp1_drm.c:47:5: warning: no previous prototype for 'vsp1_du_init' [-Wmissing-prototypes]
int vsp1_du_init(struct device *dev)
^
drivers/media/platform/vsp1/vsp1_drm.c:76:5: warning: no previous prototype for 'vsp1_du_setup_lif' [-Wmissing-prototypes]
int vsp1_du_setup_lif(struct device *dev, unsigned int width,
^
drivers/media/platform/vsp1/vsp1_drm.c:221:6: warning: no previous prototype for 'vsp1_du_atomic_begin' [-Wmissing-prototypes]
void vsp1_du_atomic_begin(struct device *dev)
^
drivers/media/platform/vsp1/vsp1_drm.c:273:5: warning: no previous prototype for 'vsp1_du_atomic_update' [-Wmissing-prototypes]
int vsp1_du_atomic_update(struct device *dev, unsigned int rpf_index,
^
drivers/media/platform/vsp1/vsp1_drm.c:451:6: warning: no previous prototype for 'vsp1_du_atomic_flush' [-Wmissing-prototypes]
void vsp1_du_atomic_flush(struct device *dev)
^
[media] v4l: vsp1: Configure device based on IP version
The IP version number carries enough information to identify the exact
device instance features. Drop the related DT properties and use the IP
version instead.
Display lists contain lists of registers and associated values to be
applied atomically by the hardware. They lower the pressure on interrupt
processing delays when reprogramming the device as settings can be
prepared well in advance and queued to the hardware without waiting for
the end of the current frame.
Display list support is currently limited to the DRM pipeline.
[media] v4l: vsp1: Implement atomic update for the DRM driver
Add two API functions named vsp1_du_atomic_begin() and
vsp1_du_atomic_flush() to signal the start and end of an atomic update.
The vsp1_du_setup_rpf() function is renamed to vsp1_du_atomic_update()
for consistency.
With this new API, the driver will reprogram all modified inputs
atomically before restarting the video stream.
Implement internal control of the VSP pipeline to be used by the DU
DRM/KMS driver when using the VSP as an internal composer handled
through DRM/KMS only.
[media] v4l: vsp1: Don't validate links when the userspace API is disabled
As the pipeline is configured internally by the driver when the
userspace API is disabled its configuration can be trusted and link
validation isn't needed.
[media] v4l: vsp1: Set the alpha value manually in RPF and WPF s_stream handlers
The RPF and WPF alpha values are set through V4L2 controls and applied
when starting the video stream by a call to v4l2_ctrl_handler_setup().
As that function uses the control handler mutex it can't be called in
interrupt context, where the VSP+DU pipeline handler might need to
reconfigure the pipeline.
Set the alpha value manually in the RPF and WPF s_stream handler to
ensure that the hardware is properly configured even when controlled
without the userspace API. If the userspace API is enabled protect that
with the control lock to avoid race conditions with userspace.
[media] v4l: vsp1: Make pipeline inputs array index by RPF index
The pipeline inputs array stores pointers to all RPFs contained in the
pipeline. It's currently indexed contiguously by adding RPFs in the
order they are found during graph walk. This can't easily support
dynamic addition and removal of RPFs while streaming, which will be
required for combined VSP+DU support.
Make the array indexed by RPF index instead and skip NULL elements when
iterating over RPFs.
[media] v4l: vsp1: Make the userspace API optional
The R-Car Gen3 SoCs include VSP instances dedicated to the DU that will
be controlled entirely by the rcar-du-drm driver through the KMS API. To
support that use case make the userspace V4L2 API optional.
Laurent Pinchart [Fri, 14 Aug 2015 16:53:45 +0000 (13:53 -0300)]
[media] v4l: vsp1: Make the BRU optional
Not all VSP instances have a BRU on R-Car Gen3, make it optional. Set
the feature unconditionally for now, this will be fixed when adding Gen3
support.
[media] v4l: vsp1: Make number of BRU inputs configurable
The R-Car Gen3 family has 5-inputs BRUs, support them by making the
number of BRU inputs configurable.
As the driver assumes that the number of BRU inputs is equal to the
number of RPFs, replace the BRU_MAX_INPUTS macro with VSP1_MAX_RPF to
make the assumption apparent.
[media] v4l: vsp1: Set the SRU CTRL0 register when starting the stream
Commit 58f896d859ce ("[media] v4l: vsp1: sru: Make the intensity
controllable during streaming") refactored the stream start code and
removed the SRU CTRL0 register write by mistake. Add it back.
Fixes: 58f896d859ce ("[media] v4l: vsp1: sru: Make the intensity controllable during streaming") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] v4l: vsp1: Decouple pipeline end of frame processing from vsp1_video
To make the pipeline structure and operations usable without video
devices the frame end processing must be decoupled from struct
vsp1_video. Implement this by calling the video frame end function
indirectly through a function pointer in struct vsp1_pipeline.
[media] v4l: vsp1: Make rwpf operations independent of video device
The rwpf queue operation doesn't queue a buffer but sets the memory
address for the next run. Rename it to set_memory and pass it a new
structure independent of the video buffer than only contains memory
information.
[media] v4l: vsp1: Move video device out of struct vsp1_rwpf
To make the video device nodes optional we need to decouple the [rw]pf
instances from the video devices. Move video devices out of struct
vsp1_rwpf and instantiate them dynamically in the core driver code.
[media] v4l: vsp1: Change the type of the rwpf field in struct vsp1_video
The rwpf field contains a pointer to the rpf or wpf associated with the
video node. Instead of storing it as a vsp1_entity, store the
corresponding vsp1_rwpf pointer to allow accessing the vsp1_rwpf fields
directly.
ti-vpe/cal.c:387:26: warning: incorrect type in return expression (different address spaces)
ti-vpe/cal.c:459:26: warning: incorrect type in return expression (different address spaces)
ti-vpe/cal.c:503:27: warning: incorrect type in argument 6 (different address spaces)
ti-vpe/cal.c:509:47: warning: incorrect type in argument 6 (different address spaces)
ti-vpe/cal.c:518:47: warning: incorrect type in argument 6 (different address spaces)
ti-vpe/cal.c:526:31: warning: incorrect type in argument 6 (different address spaces)
ti-vpe/cal.c:1807:24: warning: Using plain integer as NULL pointer
ti-vpe/cal.c:1844:16: warning: Using plain integer as NULL pointer
Wu-Cheng Li [Tue, 19 Jan 2016 07:07:10 +0000 (05:07 -0200)]
[media] s5p-mfc: add the support of V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
There is a new control V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME to
force an encoder key frame. It is the same as requesting
V4L2_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE_I_FRAME.
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Some drivers also need a control like
V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE to force an encoder
key frame. Add a general V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
so the new drivers and applications can use it.
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Sudip Mukherjee [Fri, 12 Feb 2016 10:53:28 +0000 (08:53 -0200)]
[media] media: ti-vpe: add dependency of HAS_DMA
The build of m32r allmodconfig fails with the error:
drivers/media/v4l2-core/videobuf2-dma-contig.c:492:28: error: implicit
declaration of function 'dma_get_cache_alignment'
The build of videobuf2-dma-contig.c depends on HAS_DMA and it is
correctly mentioned in the Kconfig but the symbol VIDEO_TI_CAL also
selects VIDEOBUF2_DMA_CONTIG, so it is trying to compile
videobuf2-dma-contig.c even though HAS_DMA is not defined.
Fixes: 343e89a792a5 ("[media] media: ti-vpe: Add CAL v4l2 camera capture driver") Cc: Benoit Parrot <bparrot@ti.com> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Wed, 10 Feb 2016 07:40:56 +0000 (05:40 -0200)]
[media] timblogiw: move to staging in preparation for removal
The Timberdale FPGA video driver has not seen any real development
since 2011 (and very little before that).
One of the problems with the timblogiw driver is that it uses videobuf
instead of the newer vb2 framework. The long term goal is to either
convert or remove any driver still using videobuf. Since none of the
core v4l developers has the hardware, we cannot convert it ourselves.
As far as I can tell it was only used in an Intel demo board in 2009
using Meego:
Moving this driver to staging is the first step towards removal. After 2 or
3 kernel cycles it will be removed altogether unless someone steps up to
clean up this driver.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Richard Röjfors <richard@puffinpack.se> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Wed, 10 Feb 2016 11:32:25 +0000 (09:32 -0200)]
[media] adv7511: TX_EDID_PRESENT is still 1 after a disconnect
The V4L2_CID_TX_EDID_PRESENT control reports if an EDID is present.
The adv7511 however still reported the EDID present after disconnecting
the HDMI cable. Fix the logic regarding this control. And when the EDID
is disconnected also call ADV7511_EDID_DETECT to notify the bridge driver.
This was also missing.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v3.12 and up Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Dan Carpenter [Tue, 9 Feb 2016 11:14:12 +0000 (09:14 -0200)]
[media] usb/cpia2_core: clean up a min_t() cast
It makes sense to make the min_t() cast unsigned here since we don't
really want negative sizes. Making it signed causes a static checker
warning in Smatch. Smatch knows "fw->size - i" is positive but it
doesn't know that fw->size is less than INT_MAX so in theory casting it
to int might lead to a negative.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] v4l2-async: Don't fail if registered_async isn't implemented
After sub-dev registration in v4l2_async_test_notify(), the v4l2-async
core calls the registered_async callback but if a sub-dev driver does
not implement it, v4l2_subdev_call() will return a -ENOIOCTLCMD which
should not be considered an error.
Dave Airlie [Fri, 19 Feb 2016 03:10:18 +0000 (13:10 +1000)]
Merge branch 'drm-rockchip-next-2016-02-18' of https://github.com/markyzq/kernel-drm-rockchip into drm-next
add Innosilicon HDMI support.
* 'drm-rockchip-next-2016-02-18' of https://github.com/markyzq/kernel-drm-rockchip:
dt-bindings: add document for Innosilicon HDMI on Rockchip platform
drm/rockchip: hdmi: add Innosilicon HDMI support
Dave Airlie [Fri, 19 Feb 2016 02:51:43 +0000 (12:51 +1000)]
Merge tag 'drm-vc4-next-2016-02-17' of github.com:anholt/linux into drm-next
This pull request brings in overlay plane support for vc4.
* tag 'drm-vc4-next-2016-02-17' of github.com:anholt/linux:
drm/vc4: Add support for YUV planes.
drm/vc4: Add support a few more RGB display plane formats.
drm/vc4: Add support for scaling of display planes.
drm/vc4: Fix which value is being used for source image size.
drm/vc4: Add more display planes to each CRTC.
drm/vc4: Make the CRTCs cooperate on allocating display lists.
drm/vc4: Add a proper short-circut path for legacy cursor updates.
drm/vc4: Move the plane clipping/scaling setup to a separate function.
drm/vc4: Add missing __iomem annotation to hw_dlist.
drm/vc4: Improve comments on vc4_plane_state members.
Dave Airlie [Fri, 19 Feb 2016 01:13:01 +0000 (11:13 +1000)]
Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-next
First radeon and amdgpu pull request for 4.6. Highlights:
- ACP support for APUs with i2s audio
- CS ioctl optimizations
- GPU scheduler optimizations
- GPUVM optimizations
- Initial GPU reset support (not enabled yet)
- New powerplay sysfs interface for manually selecting clocks
- Powerplay fixes
- Virtualization fixes
- Removal of hw semaphore support
- Lots of other misc fixes and cleanups
* 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux: (118 commits)
drm/amdgpu: Don't call interval_tree_remove in amdgpu_mn_destroy
drm/amdgpu: Fix race condition in amdgpu_mn_unregister
drm/amdgpu: cleanup gem init/finit
drm/amdgpu: rework GEM info printing
drm/amdgpu: print the GPU offset as well in gem_info
drm/amdgpu: optionally print the pin count in gem_info as well
drm/amdgpu: print the BO size only once in amdgpu_gem_info
drm/amdgpu: print pid as integer
drm/amdgpu: remove page flip work queue v3
drm/amdgpu: stop blocking for page filp fences
drm/amdgpu: stop calling amdgpu_gpu_reset from the flip code
drm/amdgpu: remove fence reset detection leftovers
drm/amdgpu: Fix race condition in MMU notifier release
drm/radeon: Fix WARN_ON if DRM_DP_AUX_CHARDEV is enabled
drm/amdgpu/vi: move uvd tiling config setup into uvd code
drm/amdgpu/vi: move sdma tiling config setup into sdma code
drm/amdgpu/cik: move uvd tiling config setup into uvd code
drm/amdgpu/cik: move sdma tiling config setup into sdma code
drm/amdgpu/gfx7: rework gpu_init()
drm/amdgpu/gfx: clean up harvest configuration (v2)
...
Dave Airlie [Fri, 19 Feb 2016 00:57:44 +0000 (10:57 +1000)]
Merge tag 'topic/drm-misc-2016-02-18' of git://anongit.freedesktop.org/drm-intel into drm-next
Misc stuff all over:
- more mode_fixup removal from Carlos, there's another final pile still
left.
- final bits of vgaswitcheroo from Lukas for apple gmux, we're still
discussing an api cleanup patch to make it a bit more abuse-safe as a
follow-up
- dp aux interface for userspace for tools&tests from Rafael Antognolli
- actual interface parts for dma-buf flushing for userspace mmap
- few small bits all over
- vgaswitcheroo support for apple gmux from Lukas Wunner
- checks for ->mode_fixup in non-atomic helpers from Carlos Palminha, plus
removing dummy funcs from drivers. Carlos promised to follow up with
more, since there's lots more silly dummy functions around.
- dma-buf patches from Tiago, except the ioctl itself (that needed a
respin to address review from David Herrmann)
- encoder mask for atomic from Maarten
- bunch of random things all over.
Felix Kuehling [Tue, 16 Feb 2016 20:31:30 +0000 (15:31 -0500)]
drm/amdgpu: Don't call interval_tree_remove in amdgpu_mn_destroy
rbtree_postorder_for_each_entry_safe can skip over some entries if
the tree is rebalanced in interval_tree_remove. interval_tree_remove
is also redundant when the tree is just about to be freed.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
Felix Kuehling [Tue, 16 Feb 2016 20:29:23 +0000 (15:29 -0500)]
drm/amdgpu: Fix race condition in amdgpu_mn_unregister
Exchange locking order of adev->mn_lock and mm_sem, so that
rmn->mm->mmap_sem can be taken safely, protected by adev->mn_lock,
when amdgpu_mn_destroy runs concurrently.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
Macro module_usb_driver is used for drivers whose init and exit paths
only register and unregister to usb API. So remove boilerplate code to
make code simpler by using module_usb_driver.
This change was made with the help of the following Coccinelle
semantic patch:
@b depends on a@
identifier e, a.x;
@@
-static e(...) { usb_deregister(&x); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_usb_driver;
@@
-module_exit(e);
+module_usb_driver(x);
//</smpl>
Christian König [Thu, 11 Feb 2016 16:31:37 +0000 (17:31 +0100)]
drm/amdgpu: remove page flip work queue v3
Just use the system queue now that we don't block any more.
v2: handle DAL as well.
v3: agd: split DAL changes out
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Mykola Lysenko <mykola.lysenko@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Felix Kuehling [Thu, 14 Jan 2016 05:35:08 +0000 (00:35 -0500)]
drm/amdgpu: Fix race condition in MMU notifier release
The release notifier can get called a second time from
mmu_notifier_unregister depending on a race between
__mmu_notifier_release and amdgpu_mn_destroy. Use
mmu_notifier_unregister_no_release to avoid this.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
Eric Anholt [Wed, 30 Dec 2015 20:25:44 +0000 (12:25 -0800)]
drm/vc4: Add support for YUV planes.
This supports 420 and 422 subsampling with 2 or 3 planes, tested with
modetest. It doesn't set up chroma subsampling position (which it
appears KMS doesn't deal with yet).
The LBM memory is overallocated in many cases, but apparently the docs
aren't quite correct and I'll probably need to look at the hardware
source to really figure it out.
Eric Anholt [Tue, 20 Oct 2015 15:06:57 +0000 (16:06 +0100)]
drm/vc4: Add support for scaling of display planes.
This implements a simple policy for choosing scaling modes
(trapezoidal for decimation, PPF for magnification), and a single PPF
filter (Mitchell/Netravali's recommendation).
Eric Anholt [Tue, 20 Oct 2015 13:18:56 +0000 (14:18 +0100)]
drm/vc4: Add more display planes to each CRTC.
Previously we only did the primary and cursor plane, but overlay
planes are useful and just require this setup to add, since all planes
go into the HVS display list in the same way.
Eric Anholt [Mon, 28 Dec 2015 21:25:41 +0000 (13:25 -0800)]
drm/vc4: Make the CRTCs cooperate on allocating display lists.
So far, we've only ever lit up one CRTC, so this has been fine. To
extend to more displays or more planes, we need to make sure we don't
run our display lists into each other.
Eric Anholt [Wed, 30 Dec 2015 19:50:22 +0000 (11:50 -0800)]
drm/vc4: Add a proper short-circut path for legacy cursor updates.
Previously, on every modeset we would allocate new display list
memory, recompute changed planes, write all of them to the new memory,
and pointed scanout at the new list (which will latch approximately at
the next line of scanout). We let
drm_atomic_helper_wait_for_vblanks() decide whether we needed to wait
for a vblank after a modeset before cleaning up the old state and
letting the next modeset proceed, and on legacy cursor updates we
wouldn't wait. If you moved the cursor fast enough, we could
potentially wrap around the display list memory area and overwrite the
existing display list while it was still being scanned out, resulting
in the HVS scanning out garbage or just halting.
Instead of making cursor updates wait for scanout to move to the new
display list area (which introduces significant cursor lag in X), we
just rewrite our current display list.
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.