- 19 Jul, 2020 40 commits
-
-
Kieran Bingham authored
The MAX9286 is a 4-channel GMSL deserializer with coax or STP input and CSI-2 output. The device supports multicamera streaming applications, and features the ability to synchronise the attached cameras. CSI-2 output can be configured with 1 to 4 lanes, and a control channel is supported over I2C, which implements an I2C mux to facilitate communications with connected cameras across the reverse control channel. Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Laurent Pinchart authored
The MAX9286 deserializes video data received on up to 4 Gigabit Multimedia Serial Links (GMSL) and outputs them on a CSI-2 port using up to 4 data lanes. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Dongchun Zhu authored
Add a V4L2 sub-device driver for DW9768 voice coil motor, providing control to set the desired focus via IIC serial interface. Signed-off-by:
Dongchun Zhu <dongchun.zhu@mediatek.com> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Dongchun Zhu authored
Add DeviceTree Binding Documentation for Dongwoon Anatech DW9768 voice coil actuator. Reviewed-by:
-
Andrey Konovalov authored
This fixes checkpatch warnings of "msleep < 20ms can sleep for up to 20ms". Signed-off-by:
Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by:
-
Dafna Hirschfeld authored
Currently the 'pads' and 'pad_cfg' arrays of the rkisp1_resizer are of size 'RKISP1_ISP_PAD_MAX' which is 4. But the resizer has only two pads. Change the size of the arrays to 2 by adding and using 'RKISP1_RSZ_PAD_MAX' similar to the way it is done in the isp entity. [hverkuil: fix typos in commit log] Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Dafna Hirschfeld authored
The field alloc_ctx in struct rkisp1_device is not used. This patch removes it. Signed-off-by:
-
Dafna Hirschfeld authored
The field ctrl_handler in struct rkisp1_device is not used. This patch removes it. Signed-off-by:
-
Dafna Hirschfeld authored
media: staging: rkisp1: cap: in stream start, replace calls to rkisp1_handle_buffer with rkisp1_set_next_buf The function 'rkisp1_stream_start' calls 'rkisp1_handle_buffer' in order to update the 'buf.curr' and 'buf.next' fields and configure the device before streaming starts. This cause a wrong increment of the debugs field 'frame_drop'. This patch replaces the call to 'rkisp1_handle_buffer' with a call to 'rkisp1_set_next_buf'. Signed-off-by:
-
Dafna Hirschfeld authored
The function 'rkisp1_set_next_buf' configures the registers according to 'cap->buf.next'. It is called after updating 'cap->buf.next' and 'cap->buf.curr'. This patch moves the code that updates those fields to rkisp1_set_next_buf. This is a preparation for later patch that change a call to 'rkisp1_handle_buffer' with a call to 'rkisp1_set_next_buf'. Signed-off-by:
-
Dafna Hirschfeld authored
The spinlock buf.lock should protect access to the buffers. This includes the buffers in buf.queue and also buf.curr and buf.next. The function 'rkisp1_set_next_buf' access buf.next therefore it should also be protected with the lock. Signed-off-by:
-
Dafna Hirschfeld authored
The function 'rkisp1_vb2_buf_queue' sets the next buffer directly in case the capture is already streaming but no frame yet arrived from the sensor. This is an optimization that tries to avoid dropping a frame. The call atomic_read(&cap->rkisp1->isp.frame_sequence) is used to check if a frame arrived. Reading the 'frame_sequence' should be avoided outside irq handlers to avoid race conditions. This patch removes this optimization. Dropping of the first frames can be avoided if userspace queues the buffers before start streaming. If userspace starts queueing buffers only after calling 'streamon' he risks frame drops anyway. Signed-off-by:
-
Lukas Bulwahn authored
Commit 7f52faab ("media: dt-bindings: Add ch7322 media i2c device") slipped in a typo in the CHRONTEL CH7322 CEC DRIVER section. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains: warning: no file matches F: \ Documentation/devicetree/bindings/media/i2c/chontel,ch7322.yaml Fix the typo to address this warning. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by:Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by:
-
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: -
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: -
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: -
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: -
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: -
Michael Tretter authored
Encode messages as necessary for the firmware 2019.2 and, thus, support the more recent firmware version in the driver, too. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
-
Michael Tretter authored
In order to distinguish the message format that is expected by the firmware, add a version field to the message header. This allows to encode and decode the messages for the version of the firmware that was loaded by the driver. Signed-off-by:
-
Michael Tretter authored
The length of the message will be determined when the message is encoded. Writing the size of the struct into the message in the driver won't be the actual length of the message that is send to the firmware. Therefore, drop the length field from the message. Since the header is the same for all response messages, it does not make sense to read the header in each decoding function, but we can simply decode it once before dispatching to the respective functions. Signed-off-by:
-
Michael Tretter authored
The firmware decides how many reference frames shall be used und returns this information via the config blob. In order to set the number of reference frames in the PPS, the driver has to read these values from the config blob after the channel has been created in the firmware. Signed-off-by:
-
Michael Tretter authored
Firmware versions >= 2019.2 do not configure the channel via the mailbox interface anymore, but use a separate chunk of memory that is only referenced by the message. As the configuration must be in a format that is understood by the firmware and this format can change between firmware versions, handle it similar to the message and treat is as a blob. In order to support both methods in the driver, always use a separate blob for the channel configuration and copy that blob into the mailbox if the firmware requires it and otherwise reference it. Signed-off-by:
-
Michael Tretter authored
Even bits in bitfields do not keep their position, but move around or move to other bitfields. Therefore, the driver has to handle bitfields differently depending on the firmware version. Create separate fields for the options that have been in bitfields and handle the bitfields when encoding the message. As a side effect, this makes the messages a bit more readable. Signed-off-by:
-
Michael Tretter authored
Like the message format, also the identifiers in the messages differ between firmware versions. This especially affects the identifier for the codec that shall be used. As the messages used by the driver are now independent from the firmware, we can use the values defined by V4L2 as identifiers in the messages. Convert the V4L2 codec format to the respective firmware value when encoding the messages to binary format instead beforehand. Signed-off-by:
-
Michael Tretter authored
The messages are now explicitly converted from the struct to the binary representation used by the firmware. Therefore, there is no need to keep the structs packed anymore. Drop the attribute and avoid confusion why the mails are packed. Signed-off-by:
-
Michael Tretter authored
When pushing the buffers for the intermediate and reference frames to the MCU, the driver relied on the message size to calculate the number of buffers. As it is not necessary anymore to keep the messages binary compatible to the firmware, we can just explicitly write the number of buffers into the message. Signed-off-by:
-
Michael Tretter authored
The message format in the mailboxes differ between firmware versions. Therefore, it is necessary to decouple the mailbox format of the driver from the message format of the firmware. This allows to keep a consistent message format in the driver while still supporting various firmware versions. Add an intermediate step to encode and decode message before writing the mails to the mailboxes. On the other hand, this allows to handle optional fields in the messages, which is required for advanced features of the encoder and was not possible until now. Signed-off-by:
-
Michael Tretter authored
Rework the functions that read and write the SRAM that is used to communicate with the MCU. As the functions will not operate on structs but on prepared binary buffers, make the buffer stride more explicit. Also, avoid any uses of struct mcu_msg_header to analyze messages in memory, because the header will be made independent of the binary representation in the mailbox. Instead explicitly access the mail size field in the mailbox. As at it, further reduce the dependency between the mailboxes and struct allegro_dev. Signed-off-by:
-
Michael Tretter authored
Add a send/notify abstraction for the mailbox and separate the message handling in the driver from the code to read and write message to the mailbox. This untangles how mails are written into the MCU's SRAM and signaled to the MCU from the protocol between the driver and the firmware. Signed-off-by:
-
Randy Dunlap authored
Delete the doubled words "the" in comments. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Randy Dunlap authored
Delete the doubled word "flag" in a comment. Signed-off-by:
-
Randy Dunlap authored
Change the doubled word "the" in a comment to "to the". Signed-off-by:
-
Randy Dunlap authored
Delete the doubled word "the" in a comment. Signed-off-by:
-
Randy Dunlap authored
Delete the doubled word "the" in a comment. Signed-off-by:
-
Krzysztof Hałasa authored
I don't know what minimal image dimensions are, but 32x32 appears to be ok according to the docs. This is needed for small sensors like 80x80 thermal imagers. Signed-off-by:
Krzysztof Halasa <khalasa@piap.pl> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Tested-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
-
Kaaira Gupta authored
Add a control in VIMC to display information such as the correct order of colors for a given test pattern, counter, brightness, hue, saturation, contrast, width and height at sensor over test image. Signed-off-by:
Kaaira Gupta <kgupta@es.iitr.ac.in> Acked-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
-
Kaaira Gupta authored
Currently there is no method to know the correct order of the colors for a test image generated by tpg. Write a function that returns a string of colors' order given a tpg. It returns a NULL pointer in case of test patterns which do not have a well defined colors' order. Hence add a NULL check for text in tpg_gen_text(). [hverkuil: white -> White (for consistency)] Signed-off-by:
-
Kaaira Gupta authored
Change the argument of type char * to const char * for function tpg_gen_text(). This function should take in a const char * as opposed to char * as it does not make changes to the text. This issue was found while passing the order of colors of tpg generated test image (which is a const char *) to this function. Signed-off-by:
-
