summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-12-10remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCsSuman Anna
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem, commonly referred to as ICSSG. Each ICSSG processor subsystem on AM65x SR1.0 contains two primary PRU cores and two new auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs. This IP instance has two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs. Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than a PRU), Control and debug feature sets, but is different in terms of sub-modules integrated around it and does not have the full capabilities associated with a PRU core. The RTU core is typically used to aid a PRU core in accelerating data transfers, while the Tx_PRU cores is normally used to control the TX L2 FIFO if enabled in Ethernet applications. Both can also be used to run independent applications. The RTU and Tx_PRU cores though share the same Data RAMs as the PRU cores, so the memories have to be partitioned carefully between different applications. The new cores also support a new sub-module called Task Manager to support two different context thread executions. Enhance the existing PRU remoteproc driver to support these new PRU, RTU and Tx PRU cores by using specific compatibles. The initial names for the firmware images for each PRU core are retrieved from DT nodes, and can be adjusted through sysfs if required. The PRU remoteproc driver has to be specifically modified to use a custom memcpy function within its ELF loader implementation for these new cores in order to overcome a limitation with copying data into each of the core's IRAM memories. These memory ports support only 4-byte writes, and any sub-word order byte writes clear out the remaining bytes other than the bytes being written within the containing word. The default ARM64 memcpy also cannot be used as it throws an exception when the preferred 8-byte copy operation is attempted. This choice is made by using a state flag that is set only on K3 SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-6-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add pru-specific debugfs supportSuman Anna
The remoteproc core creates certain standard debugfs entries, that does not give a whole lot of useful information for the PRUs. The PRU remoteproc driver is enhanced to add additional debugfs entries for PRU. These will be auto-cleaned up when the parent rproc debug directory is removed. The enhanced debugfs support adds two new entries: 'regs' and 'single_step'. The 'regs' dumps out the useful CTRL sub-module registers as well as each of the 32 GPREGs and CT_REGs registers. The GPREGs and CT_REGs though are printed only when the PRU is halted and accessible as per the IP design. The 'single_step' utilizes the single-step execution of the PRU cores. Writing a non-zero value performs a single step, and a zero value restores the PRU to execute in the same mode as the mode before the first single step. (note: if the PRU is halted because of a halt instruction, then no change occurs). Logic for setting the PC and jumping over a halt instruction shall be added in the future. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-5-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add support for PRU specific interrupt configurationGrzegorz Jaszczyk
The firmware blob can contain optional ELF sections: .resource_table section and .pru_irq_map one. The second one contains the PRUSS interrupt mapping description, which needs to be setup before powering on the PRU core. To avoid RAM wastage this ELF section is not mapped to any ELF segment (by the firmware linker) and therefore is not loaded to PRU memory. The PRU interrupt configuration is handled within the PRUSS INTC irqchip driver and leverages the system events to interrupt channels and host interrupts mapping configuration. Relevant irq routing information is passed through a special .pru_irq_map ELF section (for interrupts routed to and used by PRU cores) or via the PRU application's device tree node (for interrupts routed to and used by the main CPU). The mappings are currently programmed during the booting/shutdown of the PRU. The interrupt configuration passed through .pru_irq_map ELF section is optional. It varies on specific firmware functionality and therefore have to be unwinded during PRU stop and performed again during PRU start. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Co-developed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-4-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add a PRU remoteproc driverSuman Anna
The Programmable Real-Time Unit Subsystem (PRUSS) consists of dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs) for program execution. This patch adds a remoteproc platform driver for managing the individual PRU RISC cores life cycle. The PRUs do not have a unified address space (have an Instruction RAM and a primary Data RAM at both 0x0). The PRU remoteproc driver therefore uses a custom remoteproc core ELF loader ops. The added .da_to_va ops is only used to provide translations for the PRU Data RAMs. This remoteproc driver does not have support for error recovery and system suspend/resume features. Different compatibles are used to allow providing scalability for instance-specific device data if needed. The driver uses a default firmware-name retrieved from device-tree for each PRU core, and the firmwares are expected to be present in the standard Linux firmware search paths. They can also be adjusted by userspace if required through the sysfs interface provided by the remoteproc core. The PRU remoteproc driver uses a client-driven boot methodology: it does _not_ support auto-boot so that the PRU load and boot is dictated by the corresponding client drivers for achieving various usecases. This allows flexibility for the client drivers or applications to set a firmware name (if needed) based on their desired functionality and boot the PRU. The sysfs bind and unbind attributes have also been suppressed so that the PRU devices cannot be unbound and thereby shutdown a PRU from underneath a PRU client driver. The driver currently supports the AM335x, AM437x, AM57xx and 66AK2G SoCs, and support for other TI SoCs will be added in subsequent patches. Co-developed-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-3-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10RDMA/mlx5: Remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Link: https://lore.kernel.org/r/20201031134638.2135060-1-trix@redhat.com Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-12-10misc: pvpanic: Replace OF headers by mod_devicetable.hAndy Shevchenko
There is no use for OF headers in the driver, but mod_devicetable.h must be included. Update driver accordingly. Cc: Peng Hao <peng.hao2@zte.com.cn> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-5-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10misc: pvpanic: Combine ACPI and platform driversAndy Shevchenko
There is nothing special in the driver that requires to have a special ACPI driver for it. Combine both into simple platform driver. Cc: Peng Hao <peng.hao2@zte.com.cn> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10usb: host: sl811: Switch to use platform_get_mem_or_io()Andy Shevchenko
Switch to use new platform_get_mem_or_io() instead of home grown analogue. Note, the code has been moved upper in the function to allow farther cleanups, such as resource sanity check. Cc: linux-usb@vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10vfio: platform: Switch to use platform_get_mem_or_io()Andy Shevchenko
Switch to use new platform_get_mem_or_io() instead of home grown analogue. Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: kvm@vger.kernel.org Acked-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10driver core: platform: Introduce platform_get_mem_or_io()Andy Shevchenko
There are at least few existing users of the proposed API which retrieves either MEM or IO resource from platform device. Make it common to utilize in the existing and new users. Cc: Eric Auger <eric.auger@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: kvm@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: Peng Hao <peng.hao2@zte.com.cn> Cc: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10serial: 8250_omap: Avoid FIFO corruption caused by MDR1 accessAlexander Sverdlin
It has been observed that once per 300-1300 port openings the first transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared as "e" on the wire). It only happened if single byte has been transmitted right after port open, which means, DMA is not used for this transfer and the corruption never happened afterwards. Therefore I've carefully re-read the MDR1 errata (link below), which says "when accessing the MDR1 registers that causes a dummy under-run condition that will freeze the UART in IrDA transmission. In UART mode, this may corrupt the transferred data". Strictly speaking, omap_8250_mdr1_errataset() performs a read access and if the value is the same as should be written, exits without errata-recommended FIFO reset. A brief check of the serial_omap_mdr1_errataset() from the competing omap-serial driver showed it has no read access of MDR1. After removing the read access from omap_8250_mdr1_errataset() the data corruption never happened any more. Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10serial: imx: Move imx_uart_probe_dt() content into probe()Fabio Estevam
Now that the driver only probes via devicetree, we can move the content of imx_uart_probe_dt() directly into imx_uart_probe() to make the code simpler. Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201209214712.15247-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10slimbus: qcom: fix potential NULL dereference in qcom_slim_prg_slew()Zhang Changzhong
platform_get_resource_byname() may fail and in this case a NULL dereference will occur. Fix it to use devm_platform_ioremap_resource_byname() instead of calling platform_get_resource_byname() and devm_ioremap(). This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Fixes: ad7fcbc308b0 ("slimbus: qcom: Add Qualcomm Slimbus controller driver") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1607392473-20610-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10siox: Make remove callback return voidUwe Kleine-König
The driver core ignores the return value of the remove callback, so don't give siox drivers the chance to provide a value. All siox drivers only allocate devm-managed resources in .probe, so there is no .remove callback to fix. Tested-by: Thorsten Scherer <t.scherer@eckelmann.de> Acked-by: Thorsten Scherer <t.scherer@eckelmann.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201125093106.240643-3-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10siox: Use bus_type functions for probe, remove and shutdownUwe Kleine-König
The eventual goal is to get rid of the callbacks in struct device_driver. Tested-by: Thorsten Scherer <t.scherer@eckelmann.de> Acked-by: Thorsten Scherer <t.scherer@eckelmann.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201125093106.240643-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10USB: gadget: f_fs: remove likely/unlikelyGreg Kroah-Hartman
They are used way too often in this file, in some ways that are actually wrong. Almost all of these are already known by the compiler and CPU so just remove them all as none of these should be on any "hot paths" where it actually matters. Cc: Felipe Balbi <balbi@kernel.org> Reported-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20201127140559.381351-6-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10usb: gadget: f_fs: Re-use SS descriptors for SuperSpeedPlusJack Pham
In many cases a function that supports SuperSpeed can very well operate in SuperSpeedPlus, if a gadget controller supports it, as the endpoint descriptors (and companion descriptors) are generally identical and can be re-used. This is true for two commonly used functions: Android's ADB and MTP. So we can simply assign the usb_function's ssp_descriptors array to point to its ss_descriptors, if available. Similarly, we need to allow an epfile's ioctl for FUNCTIONFS_ENDPOINT_DESC to correctly return the corresponding SuperSpeed endpoint descriptor in case the connected speed is SuperSpeedPlus as well. The only exception is if a function wants to implement an Isochronous endpoint capable of transferring more than 48KB per service interval when operating at greater than USB 3.1 Gen1 speed, in which case it would require an additional SuperSpeedPlus Isochronous Endpoint Companion descriptor to be returned as part of the Configuration Descriptor. Support for that would need to be separately added to the userspace-facing FunctionFS API which may not be a trivial task--likely a new descriptor format (v3?) may need to be devised to allow for separate SS and SSP descriptors to be supplied. Signed-off-by: Jack Pham <jackp@codeaurora.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201027230731.9073-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10USB: gadget: f_midi: setup SuperSpeed Plus descriptorsWill McVicker
Needed for SuperSpeed Plus support for f_midi. This allows the gadget to work properly without crashing at SuperSpeed rates. Cc: Felipe Balbi <balbi@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20201127140559.381351-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10USB: gadget: f_acm: add support for SuperSpeed Plustaehyun.cho
Setup the SuperSpeed Plus descriptors for f_acm. This allows the gadget to work properly without crashing at SuperSpeed rates. Cc: Felipe Balbi <balbi@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: taehyun.cho <taehyun.cho@samsung.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20201127140559.381351-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10USB: gadget: f_rndis: fix bitrate for SuperSpeed and aboveWill McVicker
Align the SuperSpeed Plus bitrate for f_rndis to match f_ncm's ncm_bitrate defined by commit 1650113888fe ("usb: gadget: f_ncm: add SuperSpeed descriptors for CDC NCM"). Cc: Felipe Balbi <balbi@kernel.org> Cc: EJ Hsu <ejh@nvidia.com> Cc: Peter Chen <peter.chen@nxp.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20201127140559.381351-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10usb: typec: intel_pmc_mux: Configure cable generation value for USB4Utkarsh Patel
USB4 specification chapter 3 indicates that cable data rates have to be rounded for USB4 device to operate as USB4. With that configure cable generation value to use rounded data rates for USB4. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Utkarsh Patel <utkarsh.h.patel@intel.com> Link: https://lore.kernel.org/r/20201209042408.23079-2-utkarsh.h.patel@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10PCI: j721e: Get offset within "syscon" from "ti,syscon-pcie-ctrl" phandle argKishon Vijay Abraham I
Get "syscon" pcie_ctrl offset from the argument of "ti,syscon-pcie-ctrl" phandle. Previously a subnode to "syscon" node was added which has the exact memory mapped address of pcie_ctrl but now the offset of pcie_ctrl within "syscon" is now being passed as argument to "ti,syscon-pcie-ctrl" phandle. If the offset is not provided in "ti,syscon-pcie-ctrl", the full memory mapped address of pcie_ctrl is used in order to maintain old DT compatibility. This change is as discussed in [1] [1] -> http://lore.kernel.org/r/CAL_JsqKiUcO76bo1GoepWM1TusJWoty_BRy2hFSgtEVMqtrvvQ@mail.gmail.com Link: https://lore.kernel.org/r/20201210124917.24185-5-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-12-10soc: mediatek: mmsys: Specify HAS_IOMEM dependency for MTK_MMSYSEnric Balletbo i Serra
Because mtk-mmsys uses the 'devm_platform_ioremap_resource' function, it should depend on HAS_IOMEM. Fixes: cc6576029aed ("soc: mediatek: mmsys: Use devm_platform_ioremap_resource()") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20201203121447.3366406-1-enric.balletbo@collabora.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-10regulator: max14577: Add proper module aliases stringsMarek Szyprowski
Add proper modalias structures to let this driver load automatically if compiled as module, because max14577 MFD driver creates MFD cells with such compatible strings. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210112139.5370-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-10thermal: intel: pch: use macro for temperature calculationSumeet Pawnikar
Use macro for temperature calculation Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201210124801.13850-1-sumeet.r.pawnikar@intel.com
2020-12-10Merge series "spi: spi-geni-qcom: Use gpio descriptors for CS" from Stephen ↵Mark Brown
Boyd <swboyd@chromium.org>: Collected patches from the two series below and associated tags so they can be merged in one pile through the spi tree. Merry December! SPI: https://lore.kernel.org/r/20201202214935.1114381-1-swboyd@chromium.org cros-ec: https://lore.kernel.org/r/20201203011649.1405292-1-swboyd@chromium.org Cc: Akash Asthana <akashast@codeaurora.org> Cc: Simon Glass <sjg@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Alexandru M Stan <amstan@chromium.org> Stephen Boyd (3): platform/chrome: cros_ec_spi: Don't overwrite spi::mode platform/chrome: cros_ec_spi: Drop bits_per_word assignment spi: spi-geni-qcom: Use the new method of gpio CS control drivers/platform/chrome/cros_ec_spi.c | 2 -- drivers/spi/spi-geni-qcom.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) base-commit: b65054597872ce3aefbc6a666385eabdf9e288da -- https://chromeos.dev
2020-12-10PCI: dwc: Set 32-bit DMA mask for MSI target address allocationVidya Sagar
Set DMA mask to 32-bit while allocating the MSI target address so that the address is usable for both 32-bit and 64-bit MSI capable devices. Throw a warning if it fails to set the mask to 32-bit to alert that devices that are only 32-bit MSI capable may not work properly. Link: https://lore.kernel.org/r/20201117165312.25847-1-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2020-12-10thermal: int340x: processor_thermal: Add mailbox driverSrinivas Pandruvada
Added processor thermal device mail box interface for workload hints setting. These hints will give indication to hardware to better manage power and thermals. The supported hints are: idle semi_active burusty sustained battery_life For example when the system is on battery, the hardware can be less aggressive in power ramp up. This will create an attribute group at /sys/bus/pci/devices/0000:00:04.0/workload_request This folder contains two attributes: workload_available_types : (RO): This shows available workload types workload_type: (RW) : Allows to set and get current workload type setting Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126171829.945969-4-srinivas.pandruvada@linux.intel.com
2020-12-10thermal: int340x: processor_thermal: Add RFIM driverSrinivas Pandruvada
Add support for RFIM (Radio Frequency Interference Mitigation) support via processor thermal PCI device. This drivers allows adjustment of FIVR (Fully Integrated Voltage Regulator) and DDR (Double Data Rate) frequencies to avoid RF interference with WiFi and 5G. Switching voltage regulators (VR) generate radiated EMI or RFI at the fundamental frequency and its harmonics. Some harmonics may interfere with very sensitive wireless receivers such as Wi-Fi and cellular that are integrated into host systems like notebook PCs. One of mitigation methods is requesting SOC integrated VR (IVR) switching frequency to a small % and shift away the switching noise harmonic interference from radio channels. OEM or ODMs can use the driver to control SOC IVR operation within the range where it does not impact IVR performance. DRAM devices of DDR IO interface and their power plane can generate EMI at the data rates. Similar to IVR control mechanism, Intel offers a mechanism by which DDR data rates can be changed if several conditions are met: there is strong RFI interference because of DDR; CPU power management has no other restriction in changing DDR data rates; PC ODMs enable this feature (real time DDR RFI Mitigation referred to as DDR-RFIM) for Wi-Fi from BIOS. This change exports two folders under /sys/bus/pci/devices/0000:00:04.0. One folder "fivr" contains all attributes exposed for controling FIVR features. The other folder "dvfs" contains all attributes for DDR features. Changes done to implement: - New module for rfim interfaces - Two new per processor features for DDR and FIVR - Enable feature for Tiger Lake (FIVR only) and Alder Lake The attributes exposed and explanation: FIVR attributes vco_ref_code_lo (RW): The VCO reference code is an 11-bit field and controls the FIVR switching frequency. This is the 3-bit LSB field. vco_ref_code_hi (RW): The VCO reference code is an 11-bit field and controls the FIVR switching frequency. This is the 8-bit MSB field. spread_spectrum_pct (RW): Set the FIVR spread spectrum clocking percentage spread_spectrum_clk_enable (RW): Enable/disable of the FIVR spread spectrum clocking feature rfi_vco_ref_code (RW): This field is a read only status register which reflects the current FIVR switching frequency fivr_fffc_rev (RW): This field indicated the revision of the FIVR HW. DVFS attributes rfi_restriction_run_busy (RW): Request the restriction of specific DDR data rate and set this value 1. Self reset to 0 after operation. rfi_restriction_err_code (RW): Values: 0 :Request is accepted, 1:Feature disabled, 2: the request restricts more points than it is allowed rfi_restriction_data_rate_Delta (RW): Restricted DDR data rate for RFI protection: Lower Limit rfi_restriction_data_rate_Base (RW): Restricted DDR data rate for RFI protection: Upper Limit ddr_data_rate_point_0 (RO): DDR data rate selection 1st point ddr_data_rate_point_1 (RO): DDR data rate selection 2nd point ddr_data_rate_point_2 (RO): DDR data rate selection 3rd point ddr_data_rate_point_3 (RO): DDR data rate selection 4th point rfi_disable (RW): Disable DDR rate change feature Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126171829.945969-3-srinivas.pandruvada@linux.intel.com
2020-12-10thermal: int340x: processor_thermal: Add AlderLake PCI device idSrinivas Pandruvada
Added AlderLake PCI device id to support processor thermal driver. Reuse the feature set (just includes RAPL) from previous generations. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126171829.945969-2-srinivas.pandruvada@linux.intel.com
2020-12-10thermal: int340x: processor_thermal: Refactor MMIO interfaceSrinivas Pandruvada
The Processor Thermal PCI device supports multiple features. Currently we export only RAPL. But we need more features from this device exposed for Tiger Lake and Alder Lake based platforms. So re-structure the current MMIO interface, so that more features can be added cleanly. No functional changes are expected with this change. Changes done in this patch: - Using PCI_DEVICE_DATA(), hence names of defines changed - Move RAPL MMIO code to its own module - Move the RAPL MMIO offsets to RAPL MMIO module - Adjust Kconfig dependency of PROC_THERMAL_MMIO_RAPL - Per processor driver data now contains the supported features - Moved all the common data structures and defines to a common header file - This new header file contains all the processor_thermal_* interfaces - Based on the features supported the module interface is called - Each module atleast provides one add and one remove function Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126171829.945969-1-srinivas.pandruvada@linux.intel.com
2020-12-10Merge tag 'usb-v5.11-rc1' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-next Peter writes: Below are main changes for v5.11-rc1: For Chipidea USB2: - Add tracepoint support for UDC - Some tiny improvements For Cadence USB3 - Add some quirks for host mode, and let host work well at more use cases * SKIP_PHY_INIT * Disable BEI * Enable runtime PM default for i.mx platform - Some tiny improvements * tag 'usb-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb: MAINTAINERS: Add myself as a reviewer for CADENCE USB3 DRD IP DRIVER usb: chipidea: ci_hdrc_imx: Use of_device_get_match_data() usb: chipidea: usbmisc_imx: Use of_device_get_match_data() usb: cdns3: fix NULL pointer dereference on no platform data usb: chipidea: trace: fix the endian issue usb: chipidea: add tracepoint support for udc doc: dt-binding: cdns,usb3: add wakeup-irq usb: cdns3: imx: enable runtime pm by default usb: cdns3: add quirk for enable runtime pm by default usb: cdns3: host: disable BEI support usb: cdns3: host: add xhci_plat_priv quirk XHCI_SKIP_PHY_INIT usb: cdns3: host: add .suspend_quirk for xhci-plat.c usb: cdns3: Rids of duplicate error message usb: cdns3: Add static to cdns3_gadget_exit function
2020-12-10spmi: Add driver shutdown supportHsin-Hsiung Wang
Add new shutdown() method. Use it in the standard driver model style. Link: https://lore.kernel.org/r/1603187810-30481-2-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20201210023344.2838141-4-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10spmi: fix some coding style issues at the spmi coreMauro Carvalho Chehab
While preparing to port the HiSilicon 6421v600 SPMI driver, I noticed some coding style issues at the SPMI core. Address them. Link: https://lore.kernel.org/r/fec878502147336cbf2cf86e476e9dd797cd7e6f.1601360391.git.mchehab+huawei@kernel.org Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20201210023344.2838141-3-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10spmi: get rid of a warning when built with W=1Mauro Carvalho Chehab
The SPMI core complaing with this warning when built with W=1: drivers/spmi/spmi.c: In function ‘spmi_controller_remove’: drivers/spmi/spmi.c:548:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] 548 | int dummy; | ^~~~~ As the dummy var isn't needed, remove it. Link: https://lore.kernel.org/r/aacfd03835b7d1b3b6c21665b44000fe7242e535.1601360391.git.mchehab+huawei@kernel.org Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20201210023344.2838141-2-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10can: mcp251xfd: Add support for internal loopback modeManivannan Sadhasivam
MCP251xFD supports internal loopback mode which can be used to verify CAN functionality in the absence of a real CAN device. Link: https://lore.kernel.org/r/20201201054019.11012-1-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [mkl: mcp251xfd_get_normal_mode(): move CAN_CTRLMODE_LOOPBACK check to front] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-12-10can: flexcan: convert the driver to DT-onlyFabio Estevam
The flexcan driver runs only on DT platforms, so simplify the code by using of_device_get_match_data() to retrieve the driver data and also by removing the unused id_table. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201128132855.7724-1-festevam@gmail.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-12-10can: m_can: add PCI glue driver for Intel Elkhart LakeJarkko Nikula
Add support for M_CAN controller on Intel Elkhart Lake attached to the PCI bus. It integrates the Bosch M_CAN controller with Message RAM and the wrapper IP block with additional registers which all of them are within the same MMIO range. Currently only interrupt control register from wrapper IP is used and the MRAM configuration is expected to come from the firmware via "bosch,mram-cfg" device property and parsed by m_can.c core. Initial implementation is done by Felipe Balbi while he was working at Intel with later changes from Raymond Tan and me. Co-developed-by: Felipe Balbi (Intel) <balbi@kernel.org> Co-developed-by: Raymond Tan <raymond.tan@intel.com> Signed-off-by: Felipe Balbi (Intel) <balbi@kernel.org> Signed-off-by: Raymond Tan <raymond.tan@intel.com> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20201117160827.3636264-1-jarkko.nikula@linux.intel.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-12-10can: m_can: move runtime PM enable/disable to m_can_platformPatrik Flykt
This is a preparatory patch for upcoming PCI based M_CAN devices. The current PM implementation would cause PCI based drivers to enable PM twice, once when the PCI device is added and a second time in m_can_class_register(). This will cause 'Unbalanced pm_runtime_enable!' to be logged, and is a situation that should be avoided. Therefore, in anticipation of PCI devices, move PM enabling out from M_CAN class registration to its only user, the m_can_platform driver. Signed-off-by: Patrik Flykt <patrik.flykt@linux.intel.com> Link: https://lore.kernel.org/r/20201023115800.46538-2-patrik.flykt@linux.intel.com [mkl: m_can_plat_probe(): fix error handling m_can_class_register(): simplify error handling] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-12-10usb: chipidea: ci_hdrc_imx: Use of_device_get_match_data()Fabio Estevam
The retrieval of driver data via of_device_get_match_data() can make the code simpler. Use of_device_get_match_data() to simplify the code. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Chen <peter.chen@nxp.com>
2020-12-10usb: chipidea: usbmisc_imx: Use of_device_get_match_data()Fabio Estevam
The retrieval of driver data via of_device_get_match_data() can make the code simpler. Use of_device_get_match_data() to simplify the code. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Chen <peter.chen@nxp.com>
2020-12-10usb: cdns3: fix NULL pointer dereference on no platform dataRoger Quadros
Some platforms (e.g. TI) will not have any platform data which will lead to NULL pointer dereference if we don't check for NULL pdata. Fixes: 7cea9657756b ("usb: cdns3: add quirk for enable runtime pm by default") Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Acked-by: Pawel Laszczak <pawell@cadence.com> Signed-off-by: Peter Chen <peter.chen@nxp.com>
2020-12-10can: m_can: m_can_config_endisable(): remove double clearing of clock stop ↵Sean Nyekjaer
request bit The CSR bit is already cleared when arriving here so remove this section of duplicate code. The registers set in m_can_config_endisable() is set to same exact values as before this patch. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Acked-by: Sriram Dash <sriram.dash@samsung.com> Acked-by: Dan Murphy <dmurphy@ti.com> Link: https://lore.kernel.org/r/20191211063227.84259-1-sean@geanix.com Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-12-10can: rx-offload: can_rx_offload_offload_one(): avoid double unlikely() ↵Antonio Quartulli
notation when using IS_ERR() The definition of IS_ERR() already applies the unlikely() notation when checking the error status of the passed pointer. For this reason there is no need to have the same notation outside of IS_ERR() itself. Clean up code by removing redundant notation. Signed-off-by: Antonio Quartulli <a@unstable.cc> Link: https://lore.kernel.org/r/20201210085321.18693-1-a@unstable.cc Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-12-10clk: renesas: sh73a0: Stop using __raw_*() I/O accessorsGeert Uytterhoeven
There is no reason to keep on using the __raw_{read,write}l() I/O accessors in Renesas ARM driver code. Switch to using the plain {read,write}l() I/O accessors, to have a chance that this works on big-endian. Suggested-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20201119125053.4065746-1-geert+renesas@glider.be
2020-12-10clk: renesas: r8a774c0: Add RPC clocksLad Prabhakar
Describe the RPCSRC internal clock and the RPC[D2] clocks derived from it, as well as the RPC-IF module clock, in the RZ/G2E (R8A774C0) CPG/MSSR driver. Add new clk type CLK_TYPE_GEN3_E3_RPCSRC to register rpcsrc as a fixed clock on R-Car Gen3 E3 (and also RZ/G2E which is identical to E3 SoC), parent and the divider is set based on the register value CPG_RPCCKCR[4:3] which has been set prior to booting the kernel. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20201116101002.5986-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-12-10clk: renesas: r8a779a0: Fix R and OSC clocksGeert Uytterhoeven
The R-Car V3U clock driver defines the R and OSC clocks using R-Car Gen3 clock types. However, The R-Car V3U clock driver does not use the R-Car Gen3 clock driver core, hence registering the R and OSC clocks fails: renesas-cpg-mssr e6150000.clock-controller: Failed to register core clock osc: -22 renesas-cpg-mssr e6150000.clock-controller: Failed to register core clock r: -22 Fix this by introducing clock definition macros specific to R-Car V3U. Note that rcar_r8a779a0_cpg_clk_register() already handled the related clock types. Drop the now unneeded include of rcar-gen3-cpg.h. Fixes: 17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20201109152614.2465483-1-geert+renesas@glider.be
2020-12-10clk: renesas: cpg-mssr: fix kerneldoc of cpg_mssr_privKrzysztof Kozlowski
The struct cpg_mssr_priv missed proper formatting: drivers/clk/renesas/renesas-cpg-mssr.c:142: warning: cannot understand function prototype: 'struct cpg_mssr_priv ' Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201103162435.13689-7-krzk@kernel.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-12-10clk: renesas: rcar-usb2-clock-sel: Replace devm_reset_control_array_get()Yejune Deng
devm_reset_control_array_get_shared() looks more readable Signed-off-by: Yejune Deng <yejune.deng@gmail.com> Link: https://lore.kernel.org/r/1604375093-6451-1-git-send-email-yejune.deng@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-12-10clk: renesas: r8a774b1: Add RPC clocksBiju Das
Describe the RPCSRC internal clock and the RPC[D2] clocks derived from it, as well as the RPC-IF module clock, in the RZ/G2N (R8A774B1) CPG/MSSR driver. Inspired by commit 94e3935b5756 ("clk: renesas: r8a77980: Add RPC clocks"). Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20201016121709.8447-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
generated by cgit (git 2.34.1) at 2025-09-17 07:16:11 +0000