- 05 Dec, 2018 40 commits
-
-
Dafna Hirschfeld authored
Change variables names in vicodec-core.c to *_src *_dst to improve readability Signed-off-by:
Dafna Hirschfeld <dafna3@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Niklas Söderlund authored
There is no need to hold the list_lock when initializing the local asd_list of a notifier. Remove the lock handling to simplify the code and remove a potential LOCKDEP warning. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reported-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Maxime Ripard authored
The autoexposure setup in the 1080p init array is redundant with the default value of the sensor. Remove it. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Adam Ford <aford173@gmail.com> #imx6dq Signed-off-by:
-
Maxime Ripard authored
Now that we have everything in place to compute the clock rate at runtime, we can enable the 60fps framerate for the mode we tested it with. Signed-off-by:
-
Maxime Ripard authored
The current code uses an algorithm to clamp the FPS values and round them to the closest supported one that isn't really allows to be extended to more than two values. Rework it a bit to make it much easier to extend the amount of FPS options we support. Signed-off-by:
-
Maxime Ripard authored
In the ov5640_try_frame_interval function, the ret variable actually holds the frame rate index to use, which is represented by the enum ov5640_frame_rate in the driver. Make it more obvious. Signed-off-by:
-
Maxime Ripard authored
Now that we have moved the clock generation logic out of the bytes array, these arrays are identical between the 15fps and 30fps variants. Remove the duplicate entries, and convert the code accordingly. Signed-off-by:
-
Maxime Ripard authored
The pixel clock rates were introduced to report the initially static clock rate. Since this is now handled dynamically, we can remove them entirely. Signed-off-by:
-
Maxime Ripard authored
The clock rate, while hardcoded until now, is actually a function of the resolution, framerate and bytes per pixel. Now that we have an algorithm to adjust our clock rate, we can select it dynamically when we change the mode. This changes a bit the clock rate being used, with the following effect: +------+------+------+------+-----+-----------------+----------------+-----------+ | Hact | Vact | Htot | Vtot | FPS | Hardcoded clock | Computed clock | Deviation | +------+------+------+------+-----+-----------------+----------------+-----------+ | 640 | 480 | 1896 | 1080 | 15 | 56000000 | 61430400 | 8.84 % | | 640 | 480 | 1896 | 1080 | 30 | 112000000 | 122860800 | 8.84 % | | 1024 | 768 | 1896 | 1080 | 15 | 56000000 | 61430400 | 8.84 % | | 1024 | 768 | 1896 | 1080 | 30 | 112000000 | 122860800 | 8.84 % | | 320 | 240 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 320 | 240 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 176 | 144 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 176 | 144 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 720 | 480 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 720 | 480 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 720 | 576 | 1896 | 984 | 15 | 56000000 | 55969920 | 0.05 % | | 720 | 576 | 1896 | 984 | 30 | 112000000 | 111939840 | 0.05 % | | 1280 | 720 | 1892 | 740 | 15 | 42000000 | 42002400 | 0.01 % | | 1280 | 720 | 1892 | 740 | 30 | 84000000 | 84004800 | 0.01 % | | 1920 | 1080 | 2500 | 1120 | 15 | 84000000 | 84000000 | 0.00 % | | 1920 | 1080 | 2500 | 1120 | 30 | 168000000 | 168000000 | 0.00 % | | 2592 | 1944 | 2844 | 1944 | 15 | 84000000 | 165862080 | 49.36 % | +------+------+------+------+-----+-----------------+----------------+-----------+ Only the 640x480, 1024x768 and 2592x1944 modes are significantly affected by the new formula. In this case, 640x480 and 1024x768 are actually fixed by this change. Indeed, the sensor was sending data at, for example, 27.33fps instead of 30fps. This is -9%, which is roughly what we're seeing in the array. Testing these modes with the new clock setup actually fix that error, and data are now sent at around 30fps. 2592x1944, on the other hand, is probably due to the fact that this mode can only be used using MIPI-CSI2, in a two lane mode, and never really tested with a DVP bus. Signed-off-by:
-
Maxime Ripard authored
The MIPI divider is also cleared as part of the clock setup sequence, so we can remove that code. Signed-off-by:
-
Maxime Ripard authored
The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT defines represent exactly the same setup, and are at the same value, than the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and OV5640_SCLK_ROOT_DIV. Remove them. Signed-off-by:
-
Maxime Ripard authored
Part of the hardcoded initialization sequence is to set up the proper clock dividers. However, this is now done dynamically through proper code and as such, the static one is now redundant. Let's remove it. Signed-off-by:
-
Maxime Ripard authored
The clock structure for the PCLK is quite obscure in the documentation, and was hardcoded through the bytes array of each and every mode. This is troublesome, since we cannot adjust it at runtime based on other parameters (such as the number of bytes per pixel), and we can't support either framerates that have not been used by the various vendors, since we don't have the needed initialization sequence. We can however understand how the clock tree works, and then implement some functions to derive the various parameters from a given rate. And now that those parameters are calculated at runtime, we can remove them from the initialization sequence. The modes also gained a new parameter which is the clock that they are running at, from the register writes they were doing, so for now the switch to the new algorithm should be transparent. Co-Developed-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Tested-by: Adam Ford <aford173@gmail.com> #imx6dq Signed-off-by:
-
Jacopo Mondi authored
The set_fmt operations updates the sensor format only when the image format is changed. When only the image sizes gets changed, the format do not get updated causing the sensor to always report the one that was previously in use. Without this patch, updating frame size only fails: [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ...] With this patch applied: [fmt:UYVY8_2X8/1024x768@1/30 field:none colorspace:srgb xfer:srgb ...] Fixes: 6949d864 ("media: ov5640: do not change mode if format or frame interval is unchanged") Signed-off-by:
-
Enrico Scholz authored
The chip can be configured to output data transitions on the rising or falling edge of PIXCLK (Datasheet R58:1[9]), default is on the falling edge. Parsing the fw-node is made in a subfunction to bundle all (future) dt-parsing / fw-parsing stuff. [m.grzeschik@pengutronix.de: Fix inverting clock. INV_PIX_CLOCK bit is set per default. Set bit to 0 (enable mask bit without value) to enable falling edge sampling.] [m.felsch@pengutronix.de: use fwnode helpers] [m.felsch@pengutronix.de: mv fw parsing into own function] [m.felsch@pengutronix.de: adapt commit msg] [sakari.ailus@linux.intel.com: V4L2 API usage changes to compile on media tree master] Signed-off-by:
Enrico Scholz <enrico.scholz@sigma-chemnitz.de> Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Marco Felsch authored
Add the pclk-sample property to the list of optional properties for the mt9m111 camera sensor. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Marco Felsch authored
Replace the vague binding by a more verbose. Remove the remote property from the example since the driver don't support such a property. Also remove the bus-width property from the endpoint since the driver don't take care of it. Signed-off-by:
-
Michael Grzeschik authored
This patch implements the framerate selection using the skipping and readout power-modi features. The power-modi cut the framerate by half and each context has an independent selection bit. The same applies to the 2x skipping feature. Signed-off-by:
-
Michael Grzeschik authored
Currently set_fmt don't care about the streaming status, so the format can be changed during streaming. This can lead into wrong behaviours. Check if the device is already streaming and return -EBUSY to avoid wrong behaviours. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Marco Felsch authored
Add callback to check if we are already streaming. Now other callbacks can check the state and return -EBUSY if we already streaming. Signed-off-by:
-
Luca Ceresoli authored
The imx274 driver uses regmap and the build will fail without it. Fixes: drivers/media/i2c/imx274.c:142:21: error: variable ‘imx274_regmap_config’ has initializer but incomplete type static const struct regmap_config imx274_regmap_config = { ^~~~~~~~~~~~~ drivers/media/i2c/imx274.c:1869:19: error: implicit declaration of function ‘devm_regmap_init_i2c’ [-Werror=implicit-function-declaration] imx274->regmap = devm_regmap_init_i2c(client, &imx274_regmap_config); ^~~~~~~~~~~~~~~~~~~~ and others. Signed-off-by:Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by:
-
Luca Ceresoli authored
v4l2_ctrl_handler_init() expects a hint of how many controls this handler is expected to refer to. Since this number here is always 4, let's pass exactly 4. Signed-off-by:
-
Luca Ceresoli authored
imx274_read_reg() takes a u8 pointer ("reg") and casts it to pass it to regmap_read(), which takes an unsigned int pointer. This results in a corrupted stack and random crashes. Fixes: 0985dd30 ("media: imx274: V4l2 driver for Sony imx274 CMOS sensor") Cc: stable@vger.kernel.org # for 4.15 and up Signed-off-by: -
Bingbu Cao authored
Some Sony camera sensors have same test pattern definitions, this patch unify the pattern naming to make it more clear to the userspace. Suggested-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Bingbu Cao authored
current imx355 test pattern order in ctrl menu is not correct, this patch fixes it. Signed-off-by:
-
Bingbu Cao authored
current imx319 test pattern order in ctrl menu is not correct, this patch fixes it. Signed-off-by:
-
Fabio Estevam authored
On a imx6q-wandboard the following warnings are observed: [ 4.327794] video-mux 20e0000.iomuxc-gpr:ipu1_csi0_mux: bad remote port parent [ 4.336118] video-mux 20e0000.iomuxc-gpr:ipu2_csi1_mux: bad remote port parent As explained by Philipp Zabel: "There are empty endpoint nodes (without remote-endpoint property) labeled ipu1_csi[01]_mux_from_parallel_sensor in the i.MX6 device trees for board DT implementers' convenience. See commit 2539f517 ("ARM: dts: imx6qdl: Add video multiplexers, mipi_csi, and their connections")." So demote the warning to debug level and make the wording a bit less misleading. Suggested-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
-
Nathan Chancellor authored
Clang warns: drivers/media/firewire/firedtv-avc.c:999:45: warning: implicit conversion from 'int' to 'char' changes value from 159 to -97 [-Wconstant-conversion] app_info[0] = (EN50221_TAG_APP_INFO >> 16) & 0xff; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ drivers/media/firewire/firedtv-avc.c:1000:45: warning: implicit conversion from 'int' to 'char' changes value from 128 to -128 [-Wconstant-conversion] app_info[1] = (EN50221_TAG_APP_INFO >> 8) & 0xff; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ drivers/media/firewire/firedtv-avc.c:1040:44: warning: implicit conversion from 'int' to 'char' changes value from 159 to -97 [-Wconstant-conversion] app_info[0] = (EN50221_TAG_CA_INFO >> 16) & 0xff; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ drivers/media/firewire/firedtv-avc.c:1041:44: warning: implicit conversion from 'int' to 'char' changes value from 128 to -128 [-Wconstant-conversion] app_info[1] = (EN50221_TAG_CA_INFO >> 8) & 0xff; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ 4 warnings generated. Change app_info's type to unsigned char to match the type of the member msg in struct ca_msg, which is the only thing passed into the app_info parameter in this function. Link: https://github.com/ClangBuiltLinux/linux/issues/105Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Christoph Hellwig authored
The DMA API does its own zone decisions based on the coherent_dma_mask. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
YueHaibing authored
Remove duplicated include. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
-
Andrey Abramov authored
Replaced i2c_driver::probe with i2c_driver::probe_new, because documentation says that probe method is "soon to be deprecated". Signed-off-by:
Andrey Abramov <st5pub@yandex.ru> Signed-off-by:
-
Mauro Carvalho Chehab authored
The io.h was still included twice. Having a large number of includes like that unsorted is likely the reason why we ended by having 3 includes of io.h and two includes of interrupt.h at the first place. So, let's reorder the includes on alphabetic order. That would make easier to maintain it. Fixes: 12645e06 ("media: ddbridge: remove some duplicated include file") Signed-off-by:
-
zhong jiang authored
interrupt.h and io.h have duplicated include. hence just remove redundant file. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Signed-off-by:
-
Marco Felsch authored
Commit 37c65802e76a ("media: tvp5150: Add sync lock interrupt handling") introduced the interrupt handling. But we have to free the v4l2_ctrl_handler before we can return the error code. Fixes: 37c65802e76a ("media: tvp5150: Add sync lock interrupt handling") Signed-off-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
zhong jiang authored
module.h already contained moduleparam.h, so it is safe to remove the redundant include. The issue is detected with the help of Coccinelle. Signed-off-by:
-
Iliya Iliev authored
Fix error due to assignment in conditional expression. Fix errors due to absence of empty spaces separators after commas in function calls. Fix errors due to lines longer than 80 characters. Signed-off-by:
Iliya Iliev <iliyailiev3592@gmail.com> Signed-off-by:
-
Corentin Labbe authored
friio drivers is unused and un-compilable since commit b30cc07d ("media: dvb-usb/friio, dvb-usb-v2/gl861: decompose friio and merge with gl861"). Let's remove it. Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Cc: Akihiro Tsukada <tskd2@yahoo.co.jp> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Malcolm Priestley authored
Use dvb-usb-v2 generic usb function for bulk transfers and simplify logic. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Malcolm Priestley authored
lme2510_state exists for the entire duration of driver. Move usb_buffer to lme2510_state removing the need for lme2510_exit_int for removing the buffer. Signed-off-by:
-
Sean Young authored
Clang warns that 'interleaving' is assigned to itself in this function. drivers/media/dvb-frontends/dib7000p.c:1874:15: warning: explicitly assigning value of variable of type 'int' to itself [-Wself-assign] interleaving = interleaving; ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~ 1 warning generated. Just remove the self-assign and leave existing code in place for now. Reported-by:Nick Desaulniers <ndesaulniers@google.com> Suggested-by:
-
