- Aug 22, 2018
-
-
Ezequiel Garcia authored
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Add support for the VDEC IP block available on Rockchip SoCs. Currently only H264 decoding is supported, for RK3399 platforms. TODO: Split patch in boilerplate and h264 support. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Add the Video Decoder for the RK3399 SoC. Also, fix the VDEC IOMMU node, which was disabled and lacking its power domain property. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Add V4L2_CID_JPEG_LUMA/CHROMA_QUANTIZATION controls to allow userspace configure the JPEG quantization tables. Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Add V4L2_PIX_FMT_JPEG_RAW format that does not contain JPEG header in the output frame. Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Pass the v4l2_ctrl_config->dims array to v4l2_ctrl_fill, so the dimensions can be overridden for standard controls. This will be used to fill V4L2_CID_JPEG_LUMA_QUANTIZATION and V4L2_CID_JPEG_CHROMA_QUANTIZATION. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Add the Video Processing Unit node for the RK3399 SoC. Also, fix the VPU IOMMU node, which was disabled and lacking its power domain property. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Add the Video Processing Unit node for RK3288 SoC. Fix the VPU IOMMU node, which was disabled and lacking its power domain property. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Ezequiel Garcia authored
Add devicetree binding documentation for Rockchip Video Processing Unit IP. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
- Aug 18, 2018
-
-
Ezequiel Garcia authored
The RK3399 Ficus board is an Enterprise Edition board manufactured by Vamrs Ltd., based on the Rockchip RK3399 SoC. The board exposes a bunch of nice peripherals, including SATA, HDMI, MIPI CSI, Ethernet, WiFi, and PCIe. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org>
-
Those pins would be used by many boards. Signed-off-by: Randy Li <ayaka@soulik.info> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Judging from the iommu code, both the hclk and aclk are necessary for register access. Split them off into separate functions from the regular vop enablement, so that we can use them elsewhere as well. Fixes: d0b912bd ("iommu/rockchip: Request irqs in rk_iommu_probe()") Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org>
-
The vop irq is shared between vop and iommu and irq probing in the iommu driver moved to the probe function recently. This can in some cases lead to a stall if the irq is triggered while the vop driver still has it disabled, but the vop irq handler gets called. But there is no real need to disable the irq, as the vop can simply also track its enabled state and ignore irqs in that case. For this we can simply check the power-domain state of the vop, similar to how the iommu driver does it. So remove the enable/disable handling and add appropriate condition to the irq handler. changes in v2: - move to just check the power-domain state - add clock handling changes in v3: - clarify comment to speak of runtime-pm not power-domain changes in v4: - address Marc's comments (clk-enable WARN_ON and style improvement) Fixes: d0b912bd ("iommu/rockchip: Request irqs in rk_iommu_probe()") Cc: stable@vger.kernel.org Signed-off-by: Sandy Huang <hjc@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
-
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
-
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
-
Introduce some basic H264 decoding support in cedrus. So far, only the baseline profile videos have been tested, and some more advanced features used in higher profiles are not even implemented. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
-
Signed-off-by: Pawel Osciak <posciak@chromium.org> Reviewed-by: Wu-cheng Li <wuchengli@chromium.org> Tested-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
-
This adds nodes for the Video Engine and the associated reserved memory for the H3. Up to 96 MiB of memory are dedicated to the CMA pool. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds nodes for the Video Engine and the associated reserved memory for the A33. Up to 96 MiB of memory are dedicated to the CMA pool. The VPU can only map the first 256 MiB of DRAM, so the reserved memory pool has to be located in that area. Following Allwinner's decision in downstream software, the last 96 MiB of the first 256 MiB of RAM are reserved for this purpose. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds nodes for the Video Engine and the associated reserved memory for the A20. Up to 96 MiB of memory are dedicated to the CMA pool. The VPU can only map the first 256 MiB of DRAM, so the reserved memory pool has to be located in that area. Following Allwinner's decision in downstream software, the last 96 MiB of the first 256 MiB of RAM are reserved for this purpose. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds nodes for the Video Engine and the associated reserved memory for sun5i-based platforms. Up to 96 MiB of memory are dedicated to the CMA pool. The VPU can only map the first 256 MiB of DRAM, so the reserved memory pool has to be located in that area. Following Allwinner's decision in downstream software, the last 96 MiB of the first 256 MiB of RAM are reserved for this purpose. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This introduces the Cedrus VPU driver that supports the VPU found in Allwinner SoCs, also known as Video Engine. It is implemented through a v4l2 m2m decoder device and a media device (used for media requests). So far, it only supports MPEG2 decoding. Since this VPU is stateless, synchronization with media requests is required in order to ensure consistency between frame headers that contain metadata about the frame to process and the raw slice data that is used to generate the frame. This driver was made possible thanks to the long-standing effort carried out by the linux-sunxi community in the interest of reverse engineering, documenting and implementing support for Allwinner VPU. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds a device-tree binding document that specifies the properties used by the Cedurs VPU driver, as well as examples. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org>
-
This introduces support for the Sunxi tiled NV12 format, where each component of the YUV frame is divided into macroblocks. Hence, the size of each plane requires specific alignment. The pixels inside each macroblock are coded in linear order (line after line from top to bottom). This tiled NV12 format is used by the video engine on Allwinner platforms: it is the default format for decoded frames (and the only one available in the oldest supported platforms). Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
Stateless video decoding engines require both the MPEG slices and associated metadata from the video stream in order to decode frames. This introduces definitions for a new pixel format, describing buffers with MPEG2 slice data, as well as a control structure for passing the frame metadata to drivers. This is based on work from both Florent Revest and Hugues Fruchet. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds a SRAM controller node for the H3, with support for the C1 SRAM region that is shared between the Video Engine and the CPU. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds a SRAM controller node for the A23 and A33, with support for the C1 SRAM region that is shared between the Video Engine and the CPU. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds support for the C1 SRAM region (to be used with the SRAM controller driver) for the A20 platform. The region is shared between the Video Engine and the CPU. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds support for the C1 SRAM region (to be used with the SRAM controller driver) for sun5i-based platforms. The region is shared between the Video Engine and the CPU. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This switches the sun7i-a20 dtsi to use the most qualified compatibles for the system-control block (previously named SRAM controller) as well as the SRAM blocks. The sun4i-a10 compatibles are kept since these hardware blocks are backward-compatible. The phandle for system control is also updated to reflect the fact that the controller described is really about system control rather than SRAM control. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This switches the sun5i dtsi to use the most qualified compatibles for the system-control block (previously named SRAM controller) as well as the SRAM blocks. The sun4i-a10 compatibles are kept since these hardware blocks are backward-compatible. The phandle for system control is also updated to reflect the fact that the controller described is really about system control rather than SRAM control. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This switches the sun4i-a10 dtsi to use the new compatible for the system-control block (previously named SRAM controller) instead of the deprecated one. The phandle is also updated to reflect the fact that the controller described is really about system control rather than SRAM control. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This introduces support for the SRAM C1 section, that is controlled by the system controller. This SRAM area can be muxed either to the CPU or the Video Engine, that needs this area to store various tables (e.g. the Huffman VLD decoding tables). This only supports devices with the same layout as the A10 (which also includes the A13, A20, A33 and other SoCs). Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This binds the new A10 system-control compatible to the associated driver, with the same driver data as the previous compatible. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This adds a list of valid SRAM sections compatibles for the A13, A20, A23 and H3 platforms. Per-platform compatibles are introduced for the SRAM sections of these platforms, with the A10 compatibles also listed as valid when applicable. In particular, compatibles for the C1 SRAM section are introduced. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
This introduces dedicated bindings for the system control blocks found on the A13, A20, A23 and H3 sunxi platforms. Since the controllers on the A33 are the very same as those on the A23, no specific compatible is introduced for it. These bindings are introduced to allow reflecting the differences that exist between these controllers, that may become significant to driver implementations. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
Following-up on the introduction of a new binding for the A64, this introduces a system-control binding for the A10 as a replacement of the sram-controller binding. This change is motivated by consistency with the Allwinner literature, that mentions system control over SRAM controller. Moreover, the system control block is sometimes used for more than SRAM (e.g. for muxing related to the ethernet PHY). Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-