- 12 Sep, 2016 1 commit
-
-
Hans Verkuil authored
Linking soc_mediabus into this driver causes multiple definition linker warnings if soc_camera is also enabled: drivers/media/platform/soc_camera/built-in.o:(___ksymtab+soc_mbus_image_size+0x0): multiple definition of `__ksymtab_soc_mbus_image_size' drivers/media/platform/soc_camera/soc_mediabus.o:(___ksymtab+soc_mbus_image_size+0x0): first defined here >> drivers/media/platform/soc_camera/built-in.o:(___ksymtab+soc_mbus_samples_per_pixel+0x0): multiple definition of `__ksymtab_soc_mbus_samples_per_pixel' drivers/media/platform/soc_camera/soc_mediabus.o:(___ksymtab+soc_mbus_samples_per_pixel+0x0): first defined here drivers/media/platform/soc_camera/built-in.o: In function `soc_mbus_config_compatible': (.text+0x3840): multiple definition of `soc_mbus_config_compatible' drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x134): first defined here Since we really don't want to have to use any of the soc-camera code this patch copies the relevant code and data structures from soc_mediabus and renames it to pxa_mbus_*. The large table of formats has been culled a bit, removing formats that are not supported by this driver. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
- 09 Sep, 2016 39 commits
-
-
Sergei Shtylyov authored
Add support for the R8A7792 VSP1V cores which are different from the other gen2 VSP1 cores. Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
The vsp1 driver supports tri-planar formats, but the DRM API only passes two memory addresses. Add a third one. Signed-off-by:
-
Laurent Pinchart authored
Instead of hardcoding the media device model and hardware revision to "VSP1" and 0 respectively, report the actual hardware device model and IP version number. Signed-off-by:
-
Kieran Bingham authored
The FCP must be powered up for the FDP1 to function, even when the FDP1 does not make use of the FCNL features. Extend the compatible list to allow us to use the power domain and runtime-pm support. Signed-off-by:
Kieran Bingham <kieran+renesas@bingham.xyz> Reviewed-by:
-
Laurent Pinchart authored
The rcar_fcp_enable() function immediately returns successfully when the FCP device pointer is NULL to avoid forcing the users to check the FCP device manually before every call. However, the stub version of the function used when the FCP driver is disabled returns -ENOSYS unconditionally, resulting in a different API contract for the two versions of the function. As a user that requires FCP support will fail at probe time when calling rcar_fcp_get() if the FCP driver is disabled, the stub version of the rcar_fcp_enable() function will only be called with a NULL FCP device. We can thus return 0 unconditionally to align the behaviour with the normal version of the function. Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Laurent Pinchart authored
The Renesas multimedia drivers use ret to store return values, fix the only exception in the rcar-fcp driver to keep the coding style consistent. Signed-off-by:
-
Laurent Pinchart authored
The S_FMT and TRY_FMT handlers in multiplane mode attempt at clearing the reserved fields of the v4l2_format structure after the pix_mp member. However, the reserved fields are inside pix_mp, not after it. Signed-off-by:
Kieran Bingham <kieran@bingham.xyz> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Kieran Bingham authored
The power domain must be specified to bring the device out of module standby. Document this in the bindings provided, so that new additions are not missed. Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Kieran Bingham authored
The FCP driver can also support the FCPF variant for FDP1 compatible processing. Signed-off-by:
-
Sakari Ailus authored
The driver used integers for what boolean would have been a better fit. Use boolean instead. Signed-off-by:
-
Laurent Pinchart authored
This will allow adding new operations without increasing the media_device structure size for drivers that don't implement any media device operation. Signed-off-by:
-
Sakari Ailus authored
SMIA++ supports 14 and 16 bits per pixel formats as well. Add support to these formats in the driver. Signed-off-by:
-
Sakari Ailus authored
The codes will be called: MEDIA_BUS_FMT_SBGGR16_1X16 MEDIA_BUS_FMT_SGBRG16_1X16 MEDIA_BUS_FMT_SGRBG16_1X16 MEDIA_BUS_FMT_SRGGB16_1X16 Signed-off-by:
-
Jouni Ukkonen authored
The codes will be called: MEDIA_BUS_FMT_SBGGR14_1X14 MEDIA_BUS_FMT_SGBRG14_1X14 MEDIA_BUS_FMT_SGRBG14_1X14 MEDIA_BUS_FMT_SRGGB14_1X14 Signed-off-by:
Jouni Ukkonen <jouni.ukkonen@intel.com> Signed-off-by:
-
Sakari Ailus authored
The V4L2_PIX_FMT_SBGGR16 format is documented to contain samples of fewer than 16 bits. However, we do have specific definitions for smaller sample sizes. Therefore, this note is redundant from the API point of view. Currently only two drivers, am437x and davinci, use the V4L2_PIX_FMT_SBGGR16 pixelformat currently. The sampling precision is understood to be 16 bits in all current cases. Remove the note on sampling precision. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Sakari Ailus authored
The other raw bayer formats had a single sample depth dependent definition whereas the 8-bit formats had one page for each. Unify the documentation of the 8-bit formats. Signed-off-by:
-
Sakari Ailus authored
- Explicitly state that the most significant n bits are zeroed on 10 and 12 bpp formats. - Remove extra comma from the last entry of the format list - Add a missing colon before a list - Use figures versus word numerals consistently Signed-off-by:
-
Sakari Ailus authored
The number of high order bits in samples was documented to be 6 for 12-bit data. This is clearly wrong, fix it. Signed-off-by:
-
Sakari Ailus authored
The 10-bit packed raw bayer format documented that the data of the first pixel of a four-pixel group was found in the first byte and the two highest bits of the fifth byte. This was not entirely correct. The two bits in the fifth byte are the two lowest bits. The second pixel occupies the second byte and third and fourth least significant bits and so on. Signed-off-by:
Aviv Greenberg <aviv.d.greenberg@intel.com> Acked-by:
-
Mauro Carvalho Chehab authored
As reported by smatch: drivers/media/platform/pxa_camera.c: In function 'pxa_dma_start_channels': drivers/media/platform/pxa_camera.c:457:21: warning: variable 'active' set but not used [-Wunused-but-set-variable] struct pxa_buffer *active; ^~~~~~ Signed-off-by: -
Mauro Carvalho Chehab authored
As warned by smatch: drivers/media/platform/pxa_camera.c:283:39: warning: no previous prototype for 'soc_mbus_xlate_by_fourcc' [-Wmissing-prototypes] const struct soc_camera_format_xlate *soc_mbus_xlate_by_fourcc( ^~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: -
Hans Verkuil authored
Allow building this driver if COMPILE_TEST is set. Signed-off-by:
-
Robert Jarzmik authored
This is a tiny fix for a switch case which quiets 2 checkpatch harmless warnings. The generated code is not affected. Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Robert Jarzmik authored
As the conversion to a v4l2 standalone device is finished, move pxa_camera one directory up and finish severing any dependency to soc_camera. Signed-off-by:
-
Robert Jarzmik authored
Instead of the legacy behavior where it was required to wait for all video buffers to be finished by the hardware, use a cancel like strategy : as soon as the stop_streaming() call is done, abort all DMA transfers, report the already buffers as failed and return. This makes stop_streaming() more a "cancel capture" than a "wait for end of capture" semantic. Signed-off-by:
-
Robert Jarzmik authored
Add pxa_camera registers access through advanced video debugging. Signed-off-by:
-
Robert Jarzmik authored
This patch removes the soc_camera API dependency from pxa_camera. In the current status : - all previously captures are working the same on pxa270 - the s_crop() call was removed, judged not working (see what happens soc_camera_s_crop() when get_crop() == NULL) - if the pixel clock is provided by then sensor, ie. not MCLK, the dual stage change is not handled yet. => there is no in-tree user of this, so I'll let it that way - the MCLK is not yet finished, it's as in the legacy way, ie. activated at video device opening and closed at video device closing. In a subsequence patch pxa_camera_mclk_ops should be used, and platform data MCLK ignored. It will be the sensor's duty to request the clock and enable it, which will end in pxa_camera_mclk_ops. Signed-off-by:
-
Robert Jarzmik authored
This is to be seen as a regression as the set_selection (former set_crop) function is removed. This is a temporary situation in the v4l2 porting, and will have to be added later. Signed-off-by:
-
Robert Jarzmik authored
Add sequence numbers to completed buffers. Signed-off-by:
-
Robert Jarzmik authored
Make all print consistent by always using : - dev_xxx(pcdev_to_dev(pcdev), ....) This prepares the soc_camera adherence removal by making these call rely on only pcdev, and not the soc_camera icd structure. Signed-off-by:
-
Robert Jarzmik authored
Introduce sensor_call(), which will be used for all sensor invocations. This is a preparation move to v4l2 device conversion, ie. soc_camera adherence removal. Signed-off-by:
-
Robert Jarzmik authored
Move the functions in the file to be regrouped into meaningful blocks : 1. pxa camera core handling functions, manipulating the herdware 2. videobuf2 functions, dealing with video buffers 3. video ioctl (vidioc) related functions 4. driver probing, removal, suspend and resume This patch doesn't modify a single line of code. Signed-off-by:
-
Robert Jarzmik authored
Convert pxa_camera from videobuf to videobuf2. As the soc_camera was already compatible with videobuf2, the port is quite straightforward. The special case of this code in which the vb2 to prepare is "too big" in terms of size for the new capture format, the pxa_camera will fail. Signed-off-by:
-
Robert Jarzmik authored
As the mt9m111 is now working as a standalone v4l2 subdevice sensor, move it out of soc_camera directory and sever its dependency on soc_camera. Signed-off-by:
-
Robert Jarzmik authored
mt9m111 being a camera sensor, its colorspace should always be SRGB, for both RGB based formats or YCbCr based ones. Signed-off-by:
-
Robert Jarzmik authored
Remove the soc_camera adherence. Mostly the change removes the power manipulation provided by soc_camera, and instead : - powers on the sensor when the s_power control is activated - powers on the sensor in initial probe - enables and disables the MCLK provided to it in power on/off This patch also drops support for inverters on synchronisation and clock lines. It is assumed, if any board ever needs such inverters, support for them can be added in the future Acked-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Jean-Christophe Trotin authored
Add entry for the HVA driver to the MAINTAINERS file. Signed-off-by:
Jean-Christophe Trotin <jean-christophe.trotin@st.com> Signed-off-by:
-
Jean-Christophe Trotin authored
This patch adds the H.264 video encoding capability in the V4L2 HVA video encoder driver for STMicroelectronics SoC (hva-h264.c). The main supported features are: - profile: baseline, main, high, stereo high - level: up to 4.2 - bitrate mode: CBR, VBR - entropy mode: CABAC, CAVLC - video aspect: 1x1 only Signed-off-by:
Yannick Fertre <yannick.fertre@st.com> Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Signed-off-by:
-
Jean-Christophe Trotin authored
This patch adds V4L2 HVA (Hardware Video Accelerator) video encoder driver for STMicroelectronics SoC. It uses the V4L2 mem2mem framework. This patch only contains the core parts of the driver: - the V4L2 interface with the userland (hva-v4l2.c) - the hardware services (hva-hw.c) - the memory management utilities (hva-mem.c) This patch doesn't include the support of specific codec (e.g. H.264) video encoding: this support is part of subsequent patches. Signed-off-by:
-
