- 27 Jul, 2018 20 commits
-
-
Chen-Yu Tsai authored
The Pine64 H64 board uses an AXP806 PMIC in I2C and self-working mode. The H64 SoC does not have the usual RSB controller. This patch adds AXP806 to the list of devices supported in I2C mode. In theory, all RSB-based PMICs can also be used in I2C mode. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Reviewed-by:
Icenowy Zheng <icenowy@aosc.io> Tested-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org>
-
Chen-Yu Tsai authored
The AXP806 can operate in a standalone "self-working" mode, in which it is also responsible for power control of the overall system. This mode is similar to the master mode, but the EN/PWRON pin functions as a power button, instead of a level-triggered enable switch. This patch adds code checking for the new "x-powers,self-working-mode" property, and a separate mfd_cell list that includes the power button (PEK) sub-device. Signed-off-by:
-
Chen-Yu Tsai authored
The AXP806 has three operation modes: - master mode: The PMIC is the first or only AXP PMIC in the system, but is not in charge of power management, i.e. only provides regulator functions. - slave mode: The PMIC is the second AXP PMIC in the system, chained to the first, or master, one. - self-working mode: The PMIC is the only AXP PMIC in the system, and is in charge of power sequencing. The functional differences between these modes can be found in the "Control and Operation" chapter of the AXP806 (in Chinese) and AXP805 (in English) datasheets. These include how the PMIC responds to external signals, whether it takes an external voltage reference or uses its own, and whether the EN/PWRON pin functions as an enable switch or power button. We already support both slave and master mode. This patch adds a property for describing the self-working mode, and reworks the description for the mode properties. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Alberto Panizzo authored
For designs where CS/ADDR pin is floating, it is useful to allow dts to define whether to keep internal pull down or not. Signed-off-by:
Alberto Panizzo <alberto@amarulasolutions.com> Signed-off-by:
Anthony Brandon <anthony@amarulasolutions.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Alberto Panizzo authored
Configuring Speaker Mode Pullup was already supported in pdata, but not in the dts. Signed-off-by:
-
Andrey Smirnov authored
CMD_GET_STATUS is not supported by some devices implementing RDU2-compatible ICD as well as "legacy" devices. To account for that fact, add code that obtains the same information (app/bootloader FW version) using several different commands. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by:
-
Andrey Smirnov authored
This is needed to make rave-sp-wdt driver to properly ping the watchdog on "legacy" firmware. Signed-off-by:
-
Andrey Smirnov authored
This is needed to make rave-sp-eeprom driver work on "legacy" firmware. Signed-off-by:
-
Andrey Smirnov authored
Relying on serial port defaults for flow control and parity can result in complete breakdown of communication with RAVE SP on some platforms where defaults are not what we need them to be. One such case is VF610-base ZII SPU3 board (not supported upstream). To avoid this problem in the future, add code to explicitly configure both. Signed-off-by:
-
Andrey Smirnov authored
RAVE SP firmware covered by "legacy" variant uses 16-bit CCITT checksum algorithm. Change the code to correctly reflect that. Signed-off-by:
-
Andrey Smirnov authored
Remove unusded defines that are a leftover from earlier iterations of the driver. Signed-off-by:
-
Rafael David Tinoco authored
Fixes https://bugs.linaro.org/show_bug.cgi?id=3903 LTP Functional tests have caused a bad paging request when triggering the regmap_read_debugfs() logic of the device PMIC Hi6553 (reading regmap/f8000000.pmic/registers file during read_all test): Unable to handle kernel paging request at virtual address ffff0 [ffff00000984e000] pgd=0000000077ffe803, pud=0000000077ffd803,0 Internal error: Oops: 96000007 [#1] SMP ... Hardware name: HiKey Development Board (DT) ... Call trace: regmap_mmio_read8+0x24/0x40 regmap_mmio_read+0x48/0x70 _regmap_bus_reg_read+0x38/0x48 _regmap_read+0x68/0x170 regmap_read+0x50/0x78 regmap_read_debugfs+0x1a0/0x308 regmap_map_read_file+0x48/0x58 full_proxy_read+0x68/0x98 __vfs_read+0x48/0x80 vfs_read+0x94/0x150 SyS_read+0x6c/0xd8 el0_svc_naked+0x30/0x34 Code: aa1e03e0 d503201f f9400280 8b334000 (39400000) Investigations have showed that, when triggered by debugfs read() handler, the mmio regmap logic was reading a bigger (16k) register area than the one mapped by devm_ioremap_resource() during hi655x-pmic probe time (4k). This commit changes hi655x's max register, according to HW specs, to be the same as the one declared in the pmic device in hi6220's dts, fixing the issue. Cc: <stable@vger.kernel.org> #v4.9 #v4.14 #v4.16 #v4.17 Signed-off-by:
Rafael David Tinoco <rafael.tinoco@linaro.org> Signed-off-by:
-
Zumeng Chen authored
Use devm_elk_get() to let Linux manage struct clk memory to avoid the following memory leakage report: unreferenced object 0xdd75efc0 (size 64): comm "systemd-udevd", pid 186, jiffies 4294945126 (age 1195.750s) hex dump (first 32 bytes): 61 64 63 5f 74 73 63 5f 66 63 6b 00 00 00 00 00 adc_tsc_fck..... 00 00 00 00 92 03 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<c0a15260>] kmemleak_alloc+0x40/0x74 [<c0287a10>] __kmalloc_track_caller+0x198/0x388 [<c0255610>] kstrdup+0x40/0x5c [<c025565c>] kstrdup_const+0x30/0x3c [<c0636630>] __clk_create_clk+0x60/0xac [<c0630918>] clk_get_sys+0x74/0x144 [<c0630cdc>] clk_get+0x5c/0x68 [<bf0ac540>] ti_tscadc_probe+0x260/0x468 [ti_am335x_tscadc] [<c06f3c0c>] platform_drv_probe+0x60/0xac [<c06f1abc>] driver_probe_device+0x214/0x2dc [<c06f1c18>] __driver_attach+0x94/0xc0 [<c06efe2c>] bus_for_each_dev+0x90/0xa0 [<c06f1470>] driver_attach+0x28/0x30 [<c06f1030>] bus_add_driver+0x184/0x1ec [<c06f2b74>] driver_register+0xb0/0xf0 [<c06f3b4c>] __platform_driver_register+0x40/0x54 Signed-off-by:Zumeng Chen <zumeng.chen@gmail.com> Signed-off-by:
-
Christoph Fritz authored
This patch fixes documentation of tps65911 because its list of compatible regulators contains wrongly vdd3 instead of vdd2. Signed-off-by:
Christoph Fritz <chf.fritz@googlemail.com> Acked-by:
-
Sebastian Andrzej Siewior authored
The USB completion callback does not disable interrupts while acquiring the lock. We want to remove the local_irq_disable() invocation from __usb_hcd_giveback_urb() and therefore it is required for the callback handler to disable the interrupts while acquiring the lock. The callback may be invoked either in IRQ or BH context depending on the USB host controller. Use the _irqsave() variant of the locking primitives. Reviewed-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Charles Keepax authored
Some Arizona CODECs have a small timing window where they will NAK an I2C transaction if it happens before the boot done bit is set. This can cause the read of the register containing the boot done bit to fail until it is set. Since regmap_read_poll_timeout will abort polling if a read fails it can't be reliably used to poll the boot done bit over I2C. Do a partial revert of ef84f885 ("mfd: arizona: Refactor arizona_poll_reg"), removing the regmap_read_poll_timeout but leaving the refactoring to make the arizona_poll_reg take more sensible arguments. Fixes: ef84f885 ("mfd: arizona: Refactor arizona_poll_reg") Signed-off-by:
-
Mika Westerberg authored
Intel Ice Lake has the same LPSS than Intel Cannon Lake. Add the new IDs to the list of supported devices. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Anthony Brandon authored
For some errors, the wm8994_device_init function was returning or jumping to the wrong point in the error path. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by:
-
Julia Lawall authored
Add const to the declaration of various local variables of type kempld_platform_data for which the referenced value is always only dereferenced or passed to a const parameter, to record the fact that kempld_platform_data_generic is declared as const. The semantic match that finds this issue is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ identifier i,j; @@ const struct i j = { ... }; @ok@ identifier r.i; position p; @@ const struct i@p * @@ identifier r.i; position p != ok.p; @@ * struct i@p * // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Lee Jones authored
Merge branches 'ib-mfd-4.19', 'ib-mfd-gpio-pinctrl-4.19', 'ib-mfd-i915-media-platform-4.19' and 'ib-mfd-regulator-4.19', tag 'ib-platform-chrome-mfd-move-cros-ec-transport-for-4.19' into ibs-for-mfd-merged Immutable branch (mfd, chrome) due for the v4.19 window Immutable Branch which moves the cros_ec_i2c and cros_ec_spi transport drivers from mfd to platform/chrome. Changes in arm are a simple rename in defconfigs. Change in input is a rename in help text.
-
- 13 Jul, 2018 6 commits
-
-
Neil Armstrong authored
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the driver for such feature of the Embedded Controller. This driver is part of the cros-ec MFD and will be add as a sub-device when the feature bit is exposed by the EC. The controller will only handle a single logical address and handles all the messages retries and will only expose Success or Error. The controller will be tied to the HDMI CEC notifier by using the platform DMI Data and the i915 device name and connector name. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Neil Armstrong authored
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device when the CEC feature bit is present. Signed-off-by:
-
Neil Armstrong authored
The EC can expose a CEC bus, this patch adds the CEC related definitions needed by the cros-ec-cec driver. Signed-off-by:
-
Neil Armstrong authored
Having a 16 byte mkbp event size makes it possible to send CEC messages from the EC to the AP directly inside the mkbp event instead of first doing a notification and then a read. Signed-off-by:
Stefan Adolfsson <sadolfsson@chromium.org> Signed-off-by:
-
Neil Armstrong authored
This patchs adds the cec_notifier feature to the intel_hdmi part of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate between each HDMI ports. The changes will allow the i915 HDMI code to notify EDID and HPD changes to an eventual CEC adapter. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Neil Armstrong authored
In non device-tree world, we can need to get the notifier by the driver name directly and eventually defer probe if not yet created. This patch adds a variant of the get function by using the device name instead and will not create a notifier if not yet created. But the i915 driver exposes at least 2 HDMI connectors, this patch also adds the possibility to add a connector name tied to the notifier device to form a tuple and associate different CEC controllers for each HDMI connectors. Signed-off-by:
-
- 04 Jul, 2018 14 commits
-
-
Marek Vasut authored
Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC. Signed-off-by:
Marek Vasut <marek.vasut+renesas@gmail.com> Acked-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by:
-
Marek Vasut authored
Move the LDOs present only on DA9063 at the end of the list, so that the DA9063L can simply indicate less LDOs and still share the list of regulators with DA9063. Signed-off-by:
-
Marek Vasut authored
The DA9063L does not contain RTC block, unlike the full DA9063. Split the RTC block into separate mfd cell and register it only on DA9063. Signed-off-by:
-
Marek Vasut authored
The DA9063L does not have an RTC. Add custom IRQ map for DA9063L to ignore the Alarm and Tick IRQs from the PMIC. Signed-off-by:
-
Marek Vasut authored
The DA9063L does not have an RTC. Add custom regmap for DA9063L to prevent access into that register block. Signed-off-by:
-
Marek Vasut authored
Add type for DA9063L, which is a reduced variant of the DA9063 without RTC block and with less regulators. Signed-off-by:
-
Marek Vasut authored
The model number stored in the struct da9063 is the same for all variants of the da9063 since it is the chip ID, which is always the same. Replace that with a separate identifier instead, which allows us to discern the DA9063 variants by setting the type based on either DT match or otherwise. Signed-off-by:
-
Marek Vasut authored
The PMIC_DA9063 is a complete misnomer, it denotes the value of the DA9063 chip ID register, so rename it as such. It is also the value of chip ID register of DA9063L though, so drop the enum as all the DA9063 "models" share the same chip ID and thus the distinction will have to be made using DT or otherwise. Signed-off-by:
-
Marek Vasut authored
Replace DA9063_NUM_IRQ macro which is not used anywhere with plain ARRAY_SIZE(). Signed-off-by:
-
Marek Vasut authored
Use PLATFORM_DEVID_NONE instead of -1 in mfd_add_devices. Signed-off-by:
-
Marek Vasut authored
Convert the regmap_irq table to use REGMAP_IRQ_REG(). Signed-off-by:
-
Marek Vasut authored
Convert the regmap_range tables to use regmap_reg_range() macro. Signed-off-by:
-
Marek Vasut authored
Use devm_mfd_add_devices() instead of plain mfd_add_devices(), which removes the need for da9063_device_exit() altogether and also for the .remove callback in da9063-i2c.c . Signed-off-by:
-
Marek Vasut authored
Use devm_regmap_add_irq_chip() instead of plain regmap_add_irq_chip(), which removes the need for da9063_irq_exit() altogether and also fixes a bug in da9063_device_init() where the da9063_irq_exit() was not called in a failpath. Signed-off-by:
-
