- 19 Jul, 2022 21 commits
-
-
Lee Jones authored
Maintaining a local driver data structure that is never shared outside of the core device is an unnecessary complexity. Half of the attributes were not used outside of a single function, one of which was not used at all. The remaining 2 are generic and can be passed around as required. Signed-off-by:Lee Jones <lee.jones@linaro.org>
-
Uwe Kleine-König authored
There is no in-tree machine that provides a struct twl4030_platform_data since commit e92fc4f0 ("ARM: OMAP2+: Drop legacy board file for LDP"). So assume dev_get_platdata() returns NULL in twl_probe() and simplify accordingly. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Saravanan Sekar authored
Add new compatible for mp2733 mfd driver. Signed-off-by:
Saravanan Sekar <sravanhome@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Document the (already used) TCSR on MDM9615. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Qualcomm Top Control and Status Register to DT Schema. Signed-off-by:
-
Tinghan Shen authored
MT8195 System Companion Processors(SCP) is a dual-core RISC-V MCU. Add a new CrOS feature ID to represent the SCP's 2nd core. The 1st core is referred to as 'core 0', and the 2nd core is referred to as 'core 1'. Signed-off-by:
Tinghan Shen <tinghan.shen@mediatek.com> Signed-off-by:
-
Fabien Parent authored
Add MT6357 PMIC IRQ support. Signed-off-by:
Fabien Parent <fparent@baylibre.com> Signed-off-by:
-
Fabien Parent authored
Adds support for PMIC keys, Regulator, and RTC for the MT6357 PMIC. Signed-off-by:
-
AngeloGioacchino Del Regno authored
Add a compatible for the MT6331 PMIC MFD device. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by:
-
Uwe Kleine-König authored
The timer units in the stm32mp1 CPUs have interrupts, depending on the timer flavour either one "global" or four dedicated ones. Document how to formalize these in a device tree. Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by:
-
Miaoqian Lin authored
of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 327156c5 ("mfd: max77620: Add core driver for MAX77620/MAX20024") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Reviewed-by:
-
Lukas Bulwahn authored
Commit b38213c6 ("dt-bindings: mfd: maxim,max77693: Convert to dtschema") converts max77693.txt to maxim,max77693.yaml and adjusts the file entry in MAINTAINERS accordingly. Unfortunately, the merge commit afb67df3 ("Merge branches [...] into ibs-for-mfd-merged") resolves some conflict in MAINTAINERS in such a way that the file entry for the converted text file max77693.txt, removed in the commit above, is added back into MAINTAINERS. Remove the file entry to this converted text file in MAXIM PMIC AND MUIC DRIVERS FOR EXYNOS BASED BOARDS. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Instead of explicit casting, use %pa specifier to format the variable of resource_size_t type. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Uwe Kleine-König authored
The driver never calls the disable callback, so drop the member from the platform struct and all callbacks from the actual platform datas. Signed-off-by:
-
Uwe Kleine-König authored
None of the in-tree instantiations of struct t7l66xb_platform_data provides a disable callback. So better don't dereference this function pointer unconditionally. As there is no user, drop it completely instead of calling it conditional. This is a preparation for making platform remove callbacks return void. Fixes: 1f192015 ("mfd: driver for the T7L66XB TMIO SoC") Signed-off-by:
-
Uwe Kleine-König authored
Up to now asic3_gpio_remove() returns zero unconditionally. This makes it easier to see in the caller that there is no error to handle. This is a preparation for making platform remove callbacks return void. Signed-off-by:
-
Andy Shevchenko authored
The actual status of the code is Supported. Reported-by:
Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by:
-
Rahul T R authored
Add a pattern property for clock-controller, also update the example with a clock-controller node Signed-off-by:
Rahul T R <r-ravikumar@ti.com> Reviewed-by:
-
Conor Dooley authored
Convert the dt binding for the da9063/da9063l to yaml. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
Luca Ceresoli authored
My Bootlin address is preferred from now on. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by:
Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by:
-
Lee Jones authored
Merge branches 'ib-mfd-acpi-for-rafael-5.20', 'ib-mfd-edac-i2c-leds-pinctrl-platform-watchdog-5.20' and 'ib-mfd-soc-bcm-5.20' into ibs-for-mfd-merged
-
- 14 Jul, 2022 12 commits
-
-
Henning Schild authored
On Apollo Lake the pinctrl drivers will now come up without ACPI. Use that instead of open coding it. Create a new driver for that which can later be filled with more GPIO based models, and which has different dependencies. Signed-off-by:
Henning Schild <henning.schild@siemens.com> Signed-off-by:
Lee Jones <lee@kernel.org>
-
Henning Schild authored
The two drivers that used to use this have been switched over to the common P2SB accessor, so this code is not needed any longer. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Henning Schild authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
-
Henning Schild authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Andy Shevchenko authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Andy Shevchenko authored
The driver uses rather voodoo kind of castings and I/O accessors. Replace it with proper __iomem annotation and readl()/readq() calls. Signed-off-by:
-
Andy Shevchenko authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Acked-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Tan Jui Nee authored
Add support for non-ACPI systems, such as system that uses Advanced Boot Loader (ABL) whereby a platform device has to be created in order to bind with pin control and GPIO. At the moment, Intel Apollo Lake In-Vehicle Infotainment (IVI) system requires a driver to hide and unhide P2SB to lookup P2SB BAR and pass the PCI BAR address to GPIO. Signed-off-by:
Tan Jui Nee <jui.nee.tan@intel.com> Co-developed-by:
-
Andy Shevchenko authored
Instead of open coding p2sb_bar() functionality we are going to use generic library. There is one more user en route. This is more than just a clean-up. It also fixes a potential issue seen when SPI BAR is 64-bit. The current code works if and only if the PCI BAR of the hidden device is inside 4G address space. In case when firmware decides to go above 4G, we will get a wrong address. Signed-off-by:
-
Andy Shevchenko authored
Factor out duplicate code to lpc_ich_enable_spi_write() helper function. Signed-off-by:
-
Andy Shevchenko authored
In some cases we may get a platform device that has ACPI companion which is different to the pin control described in the ACPI tables. This is primarily happens when device is instantiated by board file. In order to allow this device being enumerated, refactor intel_pinctrl_get_soc_data() to check the matching data instead of ACPI companion. Reported-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
-
Jonathan Yong authored
SoC features such as GPIO are accessed via a reserved MMIO area, we don't know its address but can obtain it from the BAR of the P2SB device, that device is normally hidden so we have to temporarily unhide it, read address and hide it back. There are already a few users and at least one more is coming which require an access to Primary to Sideband (P2SB) bridge in order to get IO or MMIO BAR hidden by BIOS. Create a library to access P2SB for x86 devices in a unified way. Background information ====================== Note, the term "bridge" is used in the documentation and it has nothing to do with a PCI (host) bridge as per the PCI specifications. The P2SB is an interesting device by its nature and hardware design. First of all, it has several devices in the hardware behind it. These devices may or may not be represented as ACPI devices by a firmware. It also has a hardwired (to 0s) the least significant bits of the base address register which is represented by the only 64-bit BAR0. It means that OS mustn't reallocate the BAR. On top of that in some cases P2SB is represented by function 0 on PCI slot (in terms of B:D.F) and according to the PCI specification any other function can't be seen until function 0 is present and visible. In the PCI configuration space of P2SB device the full 32-bit register is allocated for the only purpose of hiding the entire P2SB device. As per [3]: 3.1.39 P2SB Control (P2SBC)—Offset E0h Hide Device (HIDE): When this bit is set, the P2SB will return 1s on any PCI Configuration Read on IOSF-P. All other transactions including PCI Configuration Writes on IOSF-P are unaffected by this. This does not affect reads performed on the IOSF-SB interface. This doesn't prevent MMIO accesses, although preventing the OS from assigning these addresses. The firmware on the affected platforms marks the region as unusable (by cutting it off from the PCI host bridge resources) as depicted in the Apollo Lake example below: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0070-0x0077] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] pci_bus 0000:00: root bus resource [mem 0x7c000001-0x7fffffff window] pci_bus 0000:00: root bus resource [mem 0x7b800001-0x7bffffff window] pci_bus 0000:00: root bus resource [mem 0x80000000-0xcfffffff window] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xefffffff window] pci_bus 0000:00: root bus resource [bus 00-ff] The P2SB 16MB BAR is located at 0xd0000000-0xd0ffffff memory window. The generic solution ==================== The generic solution for all cases when we need to access to the information behind P2SB device is a library code where users ask for necessary resources by demand and hence those users take care of not being run on the systems where this access is not required. The library provides the p2sb_bar() API to retrieve the MMIO of the BAR0 of the device from P2SB device slot. P2SB unconditional unhiding awareness ===================================== Technically it's possible to unhide the P2SB device and devices on the same PCI slot and access them at any time as needed. But there are several potential issues with that: - the systems were never tested against such configuration and hence nobody knows what kind of bugs it may bring, especially when we talk about SPI NOR case which contains Intel FirmWare Image (IFWI) code (including BIOS) and already known to be problematic in the past for end users - the PCI by its nature is a hotpluggable bus and in case somebody attaches a driver to the functions of a P2SB slot device(s) the end user experience and system behaviour can be unpredictable - the kernel code would need some ugly hacks (or code looking as an ugly hack) under arch/x86/pci in order to enable these devices on only selected platforms (which may include CPU ID table followed by a potentially growing number of DMI strings The future improvements ======================= The future improvements with this code may go in order to gain some kind of cache, if it's possible at all, to prevent unhiding and hiding many times to take static information that may be saved once per boot. Links ===== [1]: https://lab.whitequark.org/notes/2017-11-08/accessing-intel-ich-pch-gpios/ [2]: https://cdrdv2.intel.com/v1/dl/getContent/332690?wapkw=332690 [3]: https://cdrdv2.intel.com/v1/dl/getContent/332691?wapkw=332691 [4]: https://medium.com/@jacksonchen_43335/bios-gpio-p2sb-70e9b829b403Signed-off-by:
Jonathan Yong <jonathan.yong@intel.com> Co-developed-by:
-
- 04 Jul, 2022 6 commits
-
-
Nicolas Saenz Julienne authored
Bypass power_on/power_off() when running on BCM2711 as they are not needed. Signed-off-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Peter Robinson <pbrobinson@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Stefan Wahren authored
In BCM2711 the new RPiVid ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one. Use the fact that 'pm->rpivid_asb' is populated as a hint that we're on BCM2711. Signed-off-by:
-
Stefan Wahren authored
The macros in order to access the ASB registers have a hard coded base address. So extending them for other platforms would make them harder to read. As a solution resolve these macros. Signed-off-by:
-
Stefan Wahren authored
The functions to control the async AXI bridges are almost identical. So define a general function to handle it and keep the original ones as wrapper. This should make this driver easier to extend. Signed-off-by:
-
Stefan Wahren authored
In BCM2711 the new RPiVid ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one. As per the devicetree bindings, BCM2711 will provide both the old and new ASB resources, so get both of them and pass them into 'bcm2835-power,' which will take care of selecting which one to use accordingly. Since the RPiVid ASB's resources were being provided prior to formalizing the bindings[1], also support the old DT files that didn't use 'reg-names.' [1] See: 7dbe8c62 ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by:
-
Nicolas Saenz Julienne authored
If available in firmware, find resources by their 'reg-names' position instead of relying on hardcoded offsets. Care is taken to support old firmware nonetheless. Signed-off-by:
-
- 27 Jun, 2022 1 commit
-
-
Rafael J. Wysocki authored
Instead of walking the list of children of an ACPI device directly, use acpi_dev_for_each_child() to carry out an action for all of the given ACPI device's children. This will help to eliminate the children list head from struct acpi_device as it is redundant and it is used in questionable ways in some places (in particular, locking is needed for walking the list pointed to it safely, but it is often missing). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
