summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-20phy: phy-mtk-tphy: add a property for internal resistanceChunfeng Yun
This is used to tune J-K voltage by internal R (resistance), the range is [0, 31], the resistance value is about 6.9K ohm for 0, 3.8K ohm for 31, and the step is 1K ohm Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: phy-mtk-tphy: add a property for disconnect thresholdChunfeng Yun
This is used to tune the threshold of disconnect, the index range is [0, 15], the threshold voltage is about 400mV for 0, 700mV for 15, and the step is 20mV. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20dt-bindings: phy-mtk-tphy: add the properties about address mappingChunfeng Yun
Add three required properties about the address mapping, including '#address-cells', '#size-cells' and 'ranges' Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20dt-bindings: phy-mtk-tphy: add a new reference clockChunfeng Yun
Usually the digital and analog phys use the same reference clock, but on some platforms, they are separated, so add another optional clock to support it. In order to keep the clock names consistent with PHY IP's, use the da_ref for analog phy and ref clock for digital phy. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20dt-bindings: phy-mtk-tphy: remove unused u3phya_ref clockChunfeng Yun
The u3phya_ref clock is already moved into sub-node, and renamed as ref clock, no used anymore now, so remove it to avoid confusion Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20dt-bindings: phy-mtk-tphy: make the ref clock optionalChunfeng Yun
Make the ref clock optional, then we no need refer to a fixed-clock in DTS anymore when the clock of USB3 PHY comes from oscillator directly Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20dt-bindings: phy-mtk-tphy: add two optional properties for u2phyChunfeng Yun
Add two optional properties, one for tuning J-K voltage by INTR, another for disconnect threshold, both of them are related with connect detection Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: amlogic: G12A: Fix misuse of GENMASK macroJoe Perches
Arguments are supposed to be ordered high then low. Signed-off-by: Joe Perches <joe@perches.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: qcom: qmp: Use power_on/off ops for PCIeBjorn Andersson
The PCIe PHY initialization requires the attached device to be present, which is primarily achieved by the PCI controller driver. So move the logic from init/exit to power_on/power_off. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: uniphier-pcie: Add SoC-dependent phy-mode function supportKunihiko Hayashi
Since this phy is shared by multiple devices including USB and PCIe, it is necessary to determine which device use this phy. This patch adds SoC-dependent functions to determine a device using this phy. When there is 'socionext,syscon' property in the pcie-phy node, the driver calls SoC-dependt function instead of checking .has_syscon in SoC-dependent data. The function configures the system controller to use phy for PCIe. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20phy: uniphier-pcie: Add legacy SoC support for Pro5Kunihiko Hayashi
Add legacy SoC support that needs to manage gio clock and reset and to skip setting unimplemented phy parameters. This supports Pro5. This specifies only 1 port use because Pro5 doesn't set it in the power-on sequence. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
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-20lockdep: Teach lockdep about "USED" <- "IN-NMI" inversionsPeter Zijlstra
nmi_enter() does lockdep_off() and hence lockdep ignores everything. And NMI context makes it impossible to do full IN-NMI tracking like we do IN-HARDIRQ, that could result in graph_lock recursion. However, since look_up_lock_class() is lockless, we can find the class of a lock that has prior use and detect IN-NMI after USED, just not USED after IN-NMI. NOTE: By shifting the lockdep_off() recursion count to bit-16, we can easily differentiate between actual recursion and off. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Link: https://lkml.kernel.org/r/20200221134215.090538203@infradead.org
2020-03-20locking/lockdep: Rework lockdep_lockPeter Zijlstra
A few sites want to assert we own the graph_lock/lockdep_lock, provide a more conventional lock interface for it with a number of trivial debug checks. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200313102107.GX12561@hirez.programming.kicks-ass.net
2020-03-20locking/lockdep: Fix bad recursion patternPeter Zijlstra
There were two patterns for lockdep_recursion: Pattern-A: if (current->lockdep_recursion) return current->lockdep_recursion = 1; /* do stuff */ current->lockdep_recursion = 0; Pattern-B: current->lockdep_recursion++; /* do stuff */ current->lockdep_recursion--; But a third pattern has emerged: Pattern-C: current->lockdep_recursion = 1; /* do stuff */ current->lockdep_recursion = 0; And while this isn't broken per-se, it is highly dangerous because it doesn't nest properly. Get rid of all Pattern-C instances and shore up Pattern-A with a warning. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200313093325.GW12561@hirez.programming.kicks-ass.net
2020-03-20locking/lockdep: Avoid recursion in lockdep_count_{for,back}ward_deps()Boqun Feng
Qian Cai reported a bug when PROVE_RCU_LIST=y, and read on /proc/lockdep triggered a warning: [ ] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled) ... [ ] Call Trace: [ ] lock_is_held_type+0x5d/0x150 [ ] ? rcu_lockdep_current_cpu_online+0x64/0x80 [ ] rcu_read_lock_any_held+0xac/0x100 [ ] ? rcu_read_lock_held+0xc0/0xc0 [ ] ? __slab_free+0x421/0x540 [ ] ? kasan_kmalloc+0x9/0x10 [ ] ? __kmalloc_node+0x1d7/0x320 [ ] ? kvmalloc_node+0x6f/0x80 [ ] __bfs+0x28a/0x3c0 [ ] ? class_equal+0x30/0x30 [ ] lockdep_count_forward_deps+0x11a/0x1a0 The warning got triggered because lockdep_count_forward_deps() call __bfs() without current->lockdep_recursion being set, as a result a lockdep internal function (__bfs()) is checked by lockdep, which is unexpected, and the inconsistency between the irq-off state and the state traced by lockdep caused the warning. Apart from this warning, lockdep internal functions like __bfs() should always be protected by current->lockdep_recursion to avoid potential deadlocks and data inconsistency, therefore add the current->lockdep_recursion on-and-off section to protect __bfs() in both lockdep_count_forward_deps() and lockdep_count_backward_deps() Reported-by: Qian Cai <cai@lca.pw> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200312151258.128036-1-boqun.feng@gmail.com
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>
generated by cgit (git 2.34.1) at 2025-09-22 06:22:40 +0000