summaryrefslogtreecommitdiffstats
path: root/drivers/media/platform/ti-vpe/csc.c
AgeCommit message (Collapse)AuthorFilesLines
2022-03-18media: platform: re-structure TI driversPratyush Yadav1-279/+0
The ti-vpe/ sub-directory does not only contain the VPE-specific things. It also contains the CAL driver, which is a completely different subsystem. This is also not a good place to add new drivers for other TI platforms since they will all get mixed up. Separate the VPE and CAL parts into different sub-directories and rename the ti-vpe/ sub-directory to ti/. This is now the place where new TI platform drivers can be added. [mchehab: rebased to apple on the top of media/platform/Kconfig series] Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2021-04-06media: ti-vpe: csc: remove redundant dev_err call in csc_create()Yang Yingliang1-3/+1
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2019-12-13media: ti-vpe: csc: fix single vs multiplanar format handlingBenoit Parrot1-20/+12
In csc_set_coeff() we were previously checking if the format type was V4L2_BUF_TYPE_VIDEO_OUTPUT or V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE as a mean to figure out if the format was multiplanar or not. This was not entirely accurate as the format type could also be a CAPTURE type instead. Fix this by removing the 'switch' construct and replacing them with "if (V4L2_TYPE_IS_MULTIPLANAR(type))" instead. Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2019-10-24media: ti-vpe: vpe: use r2y instead of y2r, copy-paste errorColin Ian King1-1/+1
There appears to be a copy-paste error on the access of csc_coeffs.y2r.r601.full.coeff, I believe csc_coeffs.2yr.r601.full.coeff should be used instead. This is a moot point as the code is never reached, but at least use the correct structure element. Addresses-Coverity: ("Copy-paste error") Fixes: 3ff3a712a9ea ("media: ti-vpe: vpe: don't rely on colorspace member for conversion") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-10media: ti-vpe: vpe: don't rely on colorspace member for conversionBenoit Parrot1-83/+171
Up to now VPE was relying on the colorspace value of struct v4l2_format as an indication to perform color space conversion from YUV to RGB or not. Instead we should used the source/destination fourcc codes as a more reliable indication to perform color space conversion or not. To do so, we rework the csc module to use "struct v4l2_format *" as parameters, and reorganize the coefficients tables in a more logical way. Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-10media: ti-vpe: csc: rgb-to-yuv HD full range coeff are wrongBenoit Parrot1-2/+2
The RGB to YUV HD full range coefficients did not match the TRM values and appeared to be a cut-n-paste from the YUV to RGB section. Replace the entries with the values from the TRM. Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner1-4/+1
Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-22[media] media: ti-vpe: csc: Add debug support for multi-instanceBenoit Parrot1-0/+2
Since there might be more then one instance it is better to show the base address when dumping registers to help with debugging. Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-11-22[media] media: ti-vpe: Make colorspace converter library into its own moduleBenoit Parrot1-3/+13
In preparation to add colorspace conversion support to VIP, we need to turn csc.c into its own kernel module. Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2014-11-05[media] ti-vpe: fix sparse warningsHans Verkuil1-1/+1
sc.c:303:26: warning: incorrect type in return expression (different address spaces) csc.c:188:27: warning: incorrect type in return expression (different address spaces) Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-10-30[media] ti-fpe: LLVMLinux: Remove nested function from ti-vpeBehan Webster1-6/+2
Replace the use of nested functions where a normal function will suffice. Nested functions are not liked by upstream kernel developers in general. Their use breaks the use of clang as a compiler, and doesn't make the code any better. This code now works for both gcc and clang. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Behan Webster <behanw@converseincode.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-05-23[media] v4l: ti-vpe: Rename csc memory resource nameArchit Taneja1-1/+1
Rename the memory block resource "vpe_csc" to "csc" since it also exists within the VIP IP block. This would make the name more generic, and both VPE and VIP DT nodes in the future can use it. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-05-23[media] v4l: ti-vpe: fix devm_ioremap_resource() return value checkingBartlomiej Zolnierkiewicz1-2/+2
devm_ioremap_resource() returns a pointer to the remapped memory or an ERR_PTR() encoded error code on failure. Fix the checks inside csc_create() and sc_create() accordingly. Cc: Archit Taneja <archit@ti.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Tested-by: Archit Taneja<archit@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-01-07[media] v4l: ti-vpe: Add helper to perform color conversionArchit Taneja1-0/+120
The CSC block can be used for color space conversion between YUV and RGB formats. It is configurable via a programmable set of coefficients. Add functionality to choose the appropriate CSC coefficients and program them in the CSC registers. We take the source and destination colorspace formats as the arguments, and choose the coefficient table accordingly. YUV to RGB coefficients are provided for standard and high definition colorspaces. The coefficients can also be limited or full range. For now, only full range coefficients are chosen. We would need some sort of control ioctl for the user to specify the range needed. Not sure if there is a generic control ioctl for this already? Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-01-07[media] v4l: ti-vpe: create a color space converter block libraryArchit Taneja1-0/+76
VPE and VIP IPs in DAR7x contain a color space converter(CSC) sub block. Create a library which will perform CSC related configurations and hold CSC register definitions. The functions provided by this library will be called by the vpe and vip drivers using a csc_data handle. The vpe_dev holds the csc_data handle. The handle represents an instance of the CSC hardware, and the vpe driver uses it to access the CSC register offsets or helper functions to configure these registers. The CSC register offsets are now relative to the CSC block itself, so we need to use the macro GET_OFFSET_TOP to get the CSC register offset relative to the VPE IP in the vpe driver. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>