An error occurred fetching the project authors.
- 27 Jan, 2021 9 commits
-
-
Michael Tretter authored
V4L2 specifies different controls for the QP values of different codecs. Simplify users that just care for the QP values by providing accessor function that return the correct control based on the currently set codec. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The profile and level are straight copies from the v4l2-ctrls. Avoid duplication and directly read the value of the v4l2-ctrl. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The cpb_size and the gop_size are straight copies of the values in the v4l2-ctrls. To avoid this duplication, directly get the values from the v4l2-ctrls and remove the copies. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The cbp_size_value_minus1 in the SPS can scaled using cpb_size_scale to reduce the number of bits necessary to encode the value. For simplicity, the scaling was set to 1. Restructure to the code to make it easier to drop the cbp_size from the channel and as we are at it, also properly implement the scaling. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
As the driver now uses the v4l2-ctrls to setup the channel, there is no need to explicitly set the bitrate. The initial bitrate is now set via the same path as if it is set from userspace using the v4l2-ctrl. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
v4l2_ctrl_handler_setup() calls s_ctrl for all controls of the handler. This ensures that the channel is initialized using the default values of the v4l2-ctrls. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
There are several encoding options that are hard coded in the parameter that is used to configure the hardware codec. However, some of the options must be written to the SPS/PPS by the driver. Furthermore, some of the options depend on the codec that is used (i.e. H.264 or HEVC). Therefore, move options that depend on the codec to the channel and add constants for options that are independent of the codec but must be written to the SPS/PPS. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
A format change (i.e. the frame size or the codec) has multiple effects on a channel: - The available controls - The limits of the available controls - The default encoding options To avoid scattering the changes all over the driver, add a new function that goes over the channel and does all required adjustments. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
In order to support different codecs, the driver must support changing the format on CAPTURE. Therefore, the driver needs to handle S_FMT on CAPTURE. As the driver will have a different number of formats for OUTPUT and CAPTURE, split the check for the format index in ENUM_FMT into CAPTURE and OUTPUT. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 04 Jan, 2021 4 commits
-
-
Michael Tretter authored
The dst_handle field in the PUT_STREAM_BUFFER and ENCODE_FRAME_RESPONSE is used to retrieve the V4L2 CAPTURE buffer. Calling it stream_id is confusing. Call it dst_handle inspired by src_handle for the OUTPUT buffer. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The v4l2-m2m has various helpers for correctly handle the draining. Drop the driver specific state machine and use the m2m helper functions. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The stateful encoder API was finalized. Nothing is blocking the driver from being moved out of staging. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dan Carpenter authored
The "channel" is added to the "dev->channels" but then if v4l2_m2m_ctx_init() fails then we free "channel" but it's still on the list so it could lead to a use after free. Let's not add it to the list until after v4l2_m2m_ctx_init() succeeds. Fixes: cc62c747 ("media: allegro: add missed checks in allegro_open()") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 06 Aug, 2020 1 commit
-
-
Dan Carpenter authored
The allegro_mbox_init() function returns error pointers, it never returns NULL. Fixes: 94dc7656 ("media: allegro: rework mbox handling") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 19 Jul, 2020 11 commits
-
-
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:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 04 Jul, 2020 1 commit
-
-
Dan Carpenter authored
The devm_ioremap() function doesn't return error pointers, it returns NULL on error. Fixes: f20387df ("media: allegro: add Allegro DVT video IP core driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 20 Mar, 2020 14 commits
-
-
Michael Tretter authored
Add a new struct for the channel parameters that is contained in the CREATE_CHANNEL message. This is in preparation for newer firmwares that pass the channel parameters in a dedicated buffer instead of embedding the parameters into the CREATE_CHANNEL message. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
Move the mail definitions from the driver core to a dedicated file. The mails that are exchanged between driver and firmware are not stable across firmware versions. This is in preparation to make the driver able to handle multiple firmware version by having dedicated code for handling mails. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
As we know which buffers are processed by the codec from the address in the ENCODE_FRAME response, we can queue multiple buffers in the firmware and retrieve the buffer from the response of the firmware. This enables the firmware to use the internal scheduling the codec and avoids round trips through the driver when fetching the next frame. Remove buffers that have been passed to the firmware from the m2m buffer queue and put them into a shadow queue for tracking the buffer in the driver. When we receive a ENCODE_FRAME response from the firmware, get the buffer from the shadow queue and finish the buffer. Furthermore, it is necessary to finish the job straight after passing the buffer to the firmware to allow the V4L2 framework to send further buffers to the driver. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The PUT_STREAM_BUFFER and ENCODE_FRAME request have fields that allow to pass arbitrary 64 bit values through the firmware to the ENCODE_FRAME response. Use these values to verify that the buffers when finishing the frame are actually the same buffers that have been sent for encoding a frame. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The peak bitrate must not be smaller than the configured bitrate. Update the other control whenever one of the controls changes to reflect this dependency. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
There is no need to copy the bitrate mode to a field in the channel and the value can be read directly from the control. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE control allows to enable/disable rate control on a channel. When rate control is disabled, the driver shall use constant QP, which are set by the application. Also implement the controls for configuring the QP. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The allegro dvt codec adjust the encoding speed according to a configured frame rate. Furthermore, the frame rate is written into the coded stream. Ensure that the coded video data has the correct frame rate by implementing s_parm for setting the frame rate from user space. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The driver instructs the firmware to leave some space space in front of the coded frame data for SPS/PPS data. If the driver receives an IDR, it writes the SPS/PPS into that free space and fills the rest with filler data. However, if there is no additional data, the driver can use the plane offset to skip this space instead of adding filler data. As the size of the SPS/PPS is only available after writing it, keep the filler data between the SPS/PPS and the coded frame data. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The driver uses structs to parse the responses from the VCU and expects a certain size of the responses. However, the size and format of the mails is not stable across firmware versions. Therefore, print a warning if the size does not match the expected size to warn the user that strange things might happen. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The mcu and the codec use 32 bit addresses which are sent via the firmware messages. Add helper functions for this address calculation to make it obvious which address is used in the message. As the mcu and the codec have a limited address space, print warnings if the addresses are outside the respective address space. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The Zynq UltraScale+ Devices Register Reference states that the WAKEUP bit "should be set to 0 after the MCU sleep status bit gets back to 0." If this is not done, the mcu is not going to sleep on reset and fail the reset. Set WAKEUP to 0 before triggering a reset to make sure that the reset is successful. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
The cpb_size is given in kilobytes, but the bitrate is given in bits per second. Therefore, the calculation of the initial removal delay and the cpb size for the firmware were wrong. Convert the bitrate to kilobytes before calculating the cpb size in 90 kHz units for sending it to the firmware. Also reuse the result for the initial removal delay, to make it obvious that we are setting the initial removal delay to the maximum value. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Michael Tretter authored
When creating a channel, freq_idr defines the number of frames between IDR frames in the coded stream. In V4L2, the period between IDR frames shall be taken from the GOP_SIZE control. Set the IDR frame frequency equal to the GOP size and let every GOP start with an IDR frame. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-