summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-20phy: uniphier-usb3hs: Change Rx sync mode to avoid communication failureKunihiko Hayashi
In case of using default parameters, communication failure might occur in rare cases. This sets Rx sync mode parameter to avoid the issue. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: uniphier-usb3hs: Add legacy SoC support for Pro5Kunihiko Hayashi
Add legacy SoC support that needs to manage gio clock and reset. This supports Pro5. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: uniphier-usb3ss: Add Pro5 supportKunihiko Hayashi
Pro5 SoC has same scheme of USB3 ss-phy as Pro4, so the data for Pro5 is equivalent to Pro4. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20dt-bindings: phy: socionext: Add Pro5 support and remove Pro4 from usb3-hsphyKunihiko Hayashi
This adds compatible string for Pro5 SoC that needs to manage gio clock and reset. And Pro4 SoC uses USB2 PHY instead of USB3 HS-PHY, so this removes Pro4 description from usb3-hsphy. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: socionext: Use devm_platform_ioremap_resource()Kunihiko Hayashi
Use devm_platform_ioremap_resource() to simplify the code. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: qcom-qmp: Add MSM8996 UFS QMP supportBjorn Andersson
The support for the 14nm MSM8996 UFS PHY is currently handled by the UFS-specific 14nm QMP driver, due to the earlier need for additional operations beyond the standard PHY API. Add support for this PHY to the common QMP driver, to allow us to remove the old driver. Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Add support for subnode bindingsSwapnil Jakhade
Implement single link subnode support to the phy driver. Add reset support including PHY reset and individual lane reset. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Add platform dependent initialization structureSwapnil Jakhade
Add platform dependent initialization data for Torrent PHY used in TI's J721E SoC. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Use regmap to read and write DPTX PHY registersSwapnil Jakhade
Use regmap to read and write DPTX specific PHY registers. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Use regmap to read and write Torrent PHY registersSwapnil Jakhade
Use regmap for accessing Torrent PHY registers. Modify register offsets as defined in Torrent PHY user guide. Abstract address calculation using regmap APIs. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Implement PHY configure APIsSwapnil Jakhade
Add support for PHY configuration APIs. These will mainly reconfigure link rate, number of lanes, voltage swing and pre-emphasis values. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Add 19.2 MHz reference clock supportSwapnil Jakhade
Add configuration functions for 19.2 MHz refclock support. Add register configurations for SSC support. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Refactor code for reusabilitySwapnil Jakhade
Add a separate function to set different power state values. Use uniform polling timeout value. Also check return values of functions for proper error handling. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Add wrapper for DPTX register accessSwapnil Jakhade
Add wrapper functions to read, write DisplayPort specific PHY registers to improve code readability. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Add wrapper for PHY register accessSwapnil Jakhade
Add a wrapper function to write Torrent PHY registers to improve code readability. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-torrent: Adopt Torrent nomenclatureSwapnil Jakhade
- Change private data struct cdns_dp_phy to cdns_torrent_phy - Change module description and registration accordingly - Generic torrent functions have prefix cdns_torrent_phy_* - Functions specific to Torrent phy for DisplayPort are prefixed as cdns_torrent_dp_* Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: cadence-dp: Rename to phy-cadence-torrentYuti Amonkar
Rename Cadence DP PHY driver from phy-cadence-dp to phy-cadence-torrent to make it more generic for future use. Modifiy Makefile and Kconfig accordingly. Also, change driver compatible from "cdns,dp-phy" to "cdns,torrent-phy".This will not affect ABI as the driver has never been functional, and therefore do not exist in any active use case. Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20dt-bindings: phy: Add Cadence MHDP PHY bindings in YAML format.Yuti Amonkar
- Add Cadence MHDP PHY bindings in YAML format. - Add Torrent PHY reference clock bindings. - Add sub-node bindings for each group of PHY lanes based on PHY type. Each sub-node includes properties such as master lane number, link reset, phy type, number of lanes etc. - Add reset support including PHY reset and individual lane reset. - Add a new compatible string used for TI SoCs using Torrent PHY. This will not affect ABI as the driver has never been functional, and therefore do not exist in any active use case. Signed-off-by: Yuti Amonkar <yamonkar@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tabletHans de Goede
Add touchscreen info for the Chuwi Vi8 Plus tablet. This tablet uses a Chipone ICN8505 touchscreen controller, with the firmware used by the touchscreen embedded in the EFI firmware. Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-11-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20platform/x86: touchscreen_dmi: Add EFI embedded firmware info supportHans de Goede
Sofar we have been unable to get permission from the vendors to put the firmware for touchscreens listed in touchscreen_dmi in linux-firmware. Some of the tablets with such a touchscreen have a touchscreen driver, and thus a copy of the firmware, as part of their EFI code. This commit adds the necessary info for the new EFI embedded-firmware code to extract these firmwares, making the touchscreen work OOTB without the user needing to manually add the firmware. Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-10-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20Input: icn8505 - Switch to firmware_request_platform for retreiving the fwHans de Goede
Unfortunately sofar we have been unable to get permission to redistribute icn8505 touchscreen firmwares in linux-firmware. This means that people need to find and install the firmware themselves before the touchscreen will work Some UEFI/x86 tablets with an icn8505 touchscreen have a copy of the fw embedded in their UEFI boot-services code. This commit makes the icn8505 driver use the new firmware_request_platform function, which will fallback to looking for such an embedded copy when direct filesystem lookup fails. This will make the touchscreen work OOTB on devices where there is a fw copy embedded in the UEFI code. Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-9-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20Input: silead - Switch to firmware_request_platform for retreiving the fwHans de Goede
Unfortunately sofar we have been unable to get permission to redistribute Silead touchscreen firmwares in linux-firmware. This means that people need to find and install the firmware themselves before the touchscreen will work Some UEFI/x86 tablets with a Silead touchscreen have a copy of the fw embedded in their UEFI boot-services code. This commit makes the silead driver use the new firmware_request_platform function, which will fallback to looking for such an embedded copy when direct filesystem lookup fails. This will make the touchscreen work OOTB on devices where there is a fw copy embedded in the UEFI code. Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-8-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20selftests: firmware: Add firmware_request_platform testsHans de Goede
Add tests cases for checking the new firmware_request_platform api. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Link: https://lore.kernel.org/r/20200115163554.101315-7-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20test_firmware: add support for firmware_request_platformHans de Goede
Add support for testing firmware_request_platform through a new trigger_request_platform trigger. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Link: https://lore.kernel.org/r/20200115163554.101315-6-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20firmware: Add new platform fallback mechanism and firmware_request_platform()Hans de Goede
In some cases the platform's main firmware (e.g. the UEFI fw) may contain an embedded copy of device firmware which needs to be (re)loaded into the peripheral. Normally such firmware would be part of linux-firmware, but in some cases this is not feasible, for 2 reasons: 1) The firmware is customized for a specific use-case of the chipset / use with a specific hardware model, so we cannot have a single firmware file for the chipset. E.g. touchscreen controller firmwares are compiled specifically for the hardware model they are used with, as they are calibrated for a specific model digitizer. 2) Despite repeated attempts we have failed to get permission to redistribute the firmware. This is especially a problem with customized firmwares, these get created by the chip vendor for a specific ODM and the copyright may partially belong with the ODM, so the chip vendor cannot give a blanket permission to distribute these. This commit adds a new platform fallback mechanism to the firmware loader which will try to lookup a device fw copy embedded in the platform's main firmware if direct filesystem lookup fails. Drivers which need such embedded fw copies can enable this fallback mechanism by using the new firmware_request_platform() function. Note that for now this is only supported on EFI platforms and even on these platforms firmware_fallback_platform() only works if CONFIG_EFI_EMBEDDED_FIRMWARE is enabled (this gets selected by drivers which need this), in all other cases firmware_fallback_platform() simply always returns -ENOENT. Reported-by: Dave Olsthoorn <dave@bewaar.me> Suggested-by: Peter Jones <pjones@redhat.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-5-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20Merge tag 'stable-shared-branch-for-driver-tree' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into driver-core-next Ard writes: Stable shared branch between EFI and driver tree Stable shared branch to ease the integration of Hans's series to support device firmware loaded from EFI boot service memory regions. [PATCH v12 00/10] efi/firmware/platform-x86: Add EFI embedded fw support https://lore.kernel.org/linux-efi/20200115163554.101315-1-hdegoede@redhat.com/ * tag 'stable-shared-branch-for-driver-tree' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: Add embedded peripheral firmware support efi: Export boot-services code and data as debugfs-blobs
2020-03-20spi: atmel-quadspi: Add verbose debug facilities to monitor register accessesTudor Ambarus
This feature should not be enabled in release but can be useful for developers who need to monitor register accesses at some specific places. Helped me identify a bug in u-boot, by comparing the register accesses from the linux driver with the ones from its u-boot variant. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200320065058.891221-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-20arm64: alternative: fix build with clang integrated assemblerIlie Halip
Building an arm64 defconfig with clang's integrated assembler, this error occurs: <instantiation>:2:2: error: unrecognized instruction mnemonic _ASM_EXTABLE 9999b, 9f ^ arch/arm64/mm/cache.S:50:1: note: while in macro instantiation user_alt 9f, "dc cvau, x4", "dc civac, x4", 0 ^ While GNU as seems fine with case-sensitive macro instantiations, clang doesn't, so use the actual macro name (_asm_extable) as in the rest of the file. Also checked that the generated assembly matches the GCC output. Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Fixes: 290622efc76e ("arm64: fix "dc cvau" cache operation on errata-affected core") Link: https://github.com/ClangBuiltLinux/linux/issues/924 Signed-off-by: Ilie Halip <ilie.halip@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-03-20media: allegro: create new struct for channel parametersMichael Tretter
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>
2020-03-20media: allegro: move mail definitions to separate fileMichael Tretter
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>
2020-03-20media: allegro: pass buffers through firmwareMichael Tretter
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>
2020-03-20media: allegro: verify source and destination buffer in VCU responseMichael Tretter
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>
2020-03-20media: allegro: handle dependency of bitrate and bitrate_peakMichael Tretter
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>
2020-03-20media: allegro: read bitrate mode directly from controlMichael Tretter
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>
2020-03-20media: allegro: make QP configurableMichael Tretter
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>
2020-03-20media: allegro: make frame rate configurableMichael Tretter
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>
2020-03-20media: allegro: skip filler data if possibleMichael Tretter
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>
2020-03-20media: allegro: warn if response message has an unexpected sizeMichael Tretter
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>
2020-03-20media: allegro: extract mcu and codec address calculationMichael Tretter
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>
2020-03-20media: allegro: fix reset if WAKEUP has not been set properlyMichael Tretter
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>
2020-03-20media: allegro: fix calculation of CPB sizeMichael Tretter
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>
2020-03-20media: allegro: start a GOP with an IDR frameMichael Tretter
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>
2020-03-20media: allegro: remove unknown39 field from create_channelMichael Tretter
The subframe_latency and lda_control_mode fields directly follow freq_golden_ref field and there is no unknown field in between. The unknown field it at the end of the message. Reorder the fields accordingly. This further allows to drop the hard coded value from the lda_control_mode field and set the mode to 0. 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>
2020-03-20media: allegro: fix type of gop_length in channel_create messageMichael Tretter
The gop_length field is actually only u16 and there are two more u8 fields in the message: - the number of consecutive b-frames - frequency of golden frames Fix the message and thus fix the configuration of the GOP length. 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>
2020-03-20media: allegro: fail encoding only on actual errorsMichael Tretter
Only negative values are actual errors and positive values are used for warnings. Warnings should not fail the encoding process. 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>
2020-03-20media: allegro: print message on mcu errorMichael Tretter
The codec firmware uses error codes to report errors during the configuration of a channel or while encoding a frame. Translate them into human readable strings for debugging. 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>
2020-03-20media: staging: allegro: fix broken registration of controlsMichael Tretter
Since commit cc62c74749a3 ("media: allegro: add missed checks in allegro_open()") the allegro device does provide v4l2 controls to user space anymore. The reason is that v4l2_fh_init() initializes fh->ctrl_handler to vdev->ctrl_handler, which invalidates the previous driver override of the ctrl_handler. Therefore, v4l2_fh_init() must be called before the driver overrides the fh->ctrl_handler with its own handler. Move the initialization of the fh back to the top, as the initialization does not does not need to be reverted on errors, but it is enough to free the channel. Fixes: cc62c74749a3 ("media: allegro: add missed checks in allegro_open()") 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>
2020-03-20media: cec-notifier: make cec_notifier_get_conn() staticHans Verkuil
This function is no longer used by other drivers, so it can be made static. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-20media: cec-notifier: rename conn_name to port_nameHans Verkuil
This argument refers to a stable name for an HDMI port, mostly i915 (ACPI) specific. Since we'll be introducing a more generic 'name' argument as well later, rename this now to avoid confusion. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-20media: am437x-vpfe: Make use of to_vpfe() to get a pointer to vpfe_deviceLad Prabhakar
This patch makes use of to_vpfe() to get a pointer to vpfe_device Signed-off-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-12 20:37:22 +0000