- 13 Aug, 2021 10 commits
-
-
Pawel Dembicki authored
This commit prepare driver for another device support. New power_off_cfg structure describes two most important things: name of mdio bus and pointer to register setting function. It allow to add new device with different mdio bus node and other phy register config. Signed-off-by:
Pawel Dembicki <paweldembicki@gmail.com> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com>
-
Sebastian Reichel authored
Immutable branch between regulator and power-supply for for 5.15 This immutable branch introduces the MT6360 charger driver, which requires a new linear range helper. Signed-off-by:Sebastian Reichel <sre@kernel.org>
-
Bruno Meneguele authored
Rename ChargeOption macros to match the others for ChargeCurrent and ChargeVoltage and also separate the command & masks macros from the bits of interest macros for each command. This macro doesn't introduce any functional change, only code re-org. Signed-off-by:
Bruno Meneguele <bruno.meneguele@smartgreen.net> Signed-off-by:
-
Andreas Kemnade authored
Read voltage_now via IIO and provide the property. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Reported-by: kernel test robot <lkp@intel.com> # missing depends on IIO Acked-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Andreas Kemnade authored
Add iio map to allow power driver to read out values as a consumer. This approach does not block later addition of devicetree support which would be helpful if there is an in-kernel consumer for AIN0/1. Signed-off-by:
-
Gene Chen authored
Add basic support for the battery charger for MT6360 PMIC Signed-off-by:
Gene Chen <gene_chen@richtek.com> Reviewed-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by:
-
Gene Chen authored
Add bindings document for Charger support on MT6360 PMIC Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Gene Chen authored
Add linear range get selector within for choose closest selector between minimum and maximum selector. Signed-off-by:
-
Colin Ian King authored
Clean up a handful of checkpatch warnings: - static const char * array should probably be static const char * const - function arguments should have identifier names - else should follow close brace '}' - suspect code indent for conditional statements - unnecessary parentheses in an if condition - avoid multiple line dereference - remove debug showing function execution, ftrace can trace these better - prefer 'long' over 'long int' as the int is unnecessary Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Tang Bin authored
Use the defined variable "dev" to make the code cleaner. Co-developed-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 06 Aug, 2021 7 commits
-
-
Matthias Schiffer authored
As defined by the Smart Battery Data Specification. An _AVG suffix is added to the enum values REG_TIME_TO_EMPTY and REG_TIME_TO_FULL to make the distinction clear. Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by:
-
Matthias Schiffer authored
The Smart Battery Data Specification allows for values 0..65535 mV, there is no reason to limit the value to 20000. Signed-off-by:
-
Tang Bin authored
In the probe function, when get irq failed, the function platform_get_irq_byname() logs an error message, so remove redundant message here. Co-developed-by:
-
Maxime Ripard authored
The AXP209 compatible was used in Device Trees and the driver, but it was never documented. Cc: Chen-Yu Tsai <wens@csie.org> Cc: linux-pm@vger.kernel.org Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
-
Maxime Ripard authored
The AXP803 compatible was introduced recently with a fallback to the AXP813, but it was never documented. Cc: Chen-Yu Tsai <wens@csie.org> Cc: linux-pm@vger.kernel.org Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Nikita Travkin authored
MAX77849 is a combined fuel-gauge, charger and MUIC IC. Notably, fuel-gauge has dedicated i2c lines and seems to be fully compatible with max17047. Add new compatible for it reusing max17047 code paths. Signed-off-by:
Nikita Travkin <nikita@trvn.ru> Signed-off-by:
-
Nikita Travkin authored
max77849 is a combined fuel-gauge, charger and MUIC device. Add it to the bindings documentation. Signed-off-by:
-
- 05 Aug, 2021 11 commits
-
-
Hans de Goede authored
The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus. If not explicitly taken by the I2C-driver, then this semaphore is automatically taken by the I2C-bus-driver for each I2C-transfer and this is a quite expensive operation. Explicitly take the semaphore in probe() around the register-accesses done during probe, so that this only needs to be done once, rather then once per register-access. Signed-off-by:
-
Hans de Goede authored
The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus. If not explicitly taken by the I2C-driver, then this semaphore is automatically taken by the I2C-bus-driver for each I2C-transfer. Move the AXP20X_CC_CTRL check done in probe() together with the other register-accesses done in probe, so that we can take the semaphore once for the entire set of register-accesses. Signed-off-by:
-
Andrejus Basovas authored
The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus and while the kernel holds the semaphore the CPU and GPU power-states must not be changed otherwise the system will freeze. This is a complex process, which is quite expensive. This is all done by iosf_mbi_block_punit_i2c_access(). To ensure that no unguarded I2C-bus accesses happen, iosf_mbi_block_punit_i2c_access() gets called by the I2C-bus-driver for every I2C transfer. Because this is so expensive it is allowed to call iosf_mbi_block_punit_i2c_access() in a nested fashion, so that higher-level code which does multiple I2C-transfers can call it once for a group of transfers, turning the calls done by the I2C-bus-driver into no-ops. Userspace power-supply API users typically will read all provided properties in one go, refreshing the last read values when power_supply_changed() is called by the driver and/or periodically (e.g. every 2 minutes). The reading of all properties in one go causes the P-Unit semaphore to quickly be taken and released multiple times in a row. Certain PMIC registers like AXP20X_FG_RES are even used in multiple properties so they get read multiple times, leading to a P-Unit take + release each time the register is read. As already mentioned the taking of the P-Unit semaphore is a quite expensive operation and it has also been reported that the "hammering" of the P-Unit semaphore done by the axp288_fuel_gauge driver can even cause stability issues with the system as a whole. Switch over to a scheme where the axp288_fuel_gauge driver keeps a local copy of all the registers which it uses for properties and make it only refresh its copy of the registers if the values are older then 1 minute; or when a fuel-gauge interrupt has triggered since the last read. This not only reduces the amount of reads, it also makes the code do all the reads in one go, rather then reading specific registers based on which property is being queried. This allows calling iosf_mbi_block_punit_i2c_access() once before doing all the reads, so that we now only take the P-Unit semaphore once per update. Tested-by:
Andrejus Basovas <cpp@gcc.lt> Signed-off-by:
-
Hans de Goede authored
Accessing registers on the AXP288 is quite expensive, so we should avoid doing unnecessary accesses. The FG_LOW_CAP_REG never changes underneath us, so we only need to read it once. Devices with an AXP288 do not have user-replace (let alone hot-swappable) batteries and the only bit we care about in the PWR_OP_MODE register is the CHRG_STAT_BAT_PRESENT bit, so we can get away with only reading the PWR_OP_MODE register once too. Note that the FG_LOW_CAP_REG is not marked volatile in the regmap, so we were effectively already reading it once. This change makes this explicit, this is done as preparation of a further patch which moves all remaining register accesses in fuel_gauge_get_property() out of that function. Signed-off-by:
-
Hans de Goede authored
Directly store the struct device pointer in axp288_fg_info, rather then storing a pointer to the struct platform_device there and then using "&info->pdev->dev" everywhere. Signed-off-by:
-
Hans de Goede authored
The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus. This semaphore is automatically taken by the I2C-bus-driver. The retry on -EBUSY logic in fuel_gauge_reg_readb() likely was added to deal with the I2C-bus-drive returning -EBUSY when it failed to take the semaphore, but this really should never happen. The semaphore code even has a WARN_ON(ret) to log a kernel backtrace if this does somehow happen, when this happens something is seriously wrong and the system typically freezes soon afterwards. TL;DR: the regmap_read() should never fail with -EBUSY so the retries are unnecessary. Signed-off-by:
-
Hans de Goede authored
When fuel_gauge_reg_readb()/_writeb() fails, report which register we were trying to read / write when the error happened. Also reword the message a bit: - Drop the axp288 prefix, dev_err() already prints this - Switch from telegram / abbreviated style to a normal sentence, aligning the message with those from fuel_gauge_read_*bit_word() Signed-off-by:
-
Hans de Goede authored
Drop the IRQ mapping messages, because they are really not interesting at all. Signed-off-by:
-
Hans de Goede authored
The debugfs code is simply just dumping a bunch of registers, the same information can also easily be gotten through the regmap debugfs interface or through the i2cdump utility. I've not used the debugfs interface once in all these years that I've been working on the axp288_fuel_gauge driver, so lets just remove it. Note this also removes the temperature-channels from the list of IIO ADC channels used by the driver, since these were only used in the debugfs interface. Signed-off-by:
-
Hans de Goede authored
The values of various defines used in the driver are not aligned properly when tabsize is set to 8 (I guess they were created with a different tabsize). Properly align the defines to make the code easier to read. Signed-off-by:
-
Tang Bin authored
In the function sc27xx_fgu_probe(), when get irq failed, platform_get_irq() logs an error message, so remove redundant message here. Signed-off-by:
-
- 16 Jul, 2021 7 commits
-
-
Peter Robinson authored
Deal with deferred probe using dev_err_probe so the error is handled and avoid logging lots probe defer information like the following: [ 9.125121] cw2015 4-0062: Failed to register power supply [ 9.211131] cw2015 4-0062: Failed to register power supply Fixes: b4c7715c ("power: supply: add CellWise cw2015 fuel gauge driver") Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Daisuke Nojiri authored
This patch adds a driver for PCHG (Peripheral CHarGer). PCHG is a framework managing power supplies for peripheral devices. This driver creates a sysfs node for each peripheral charge port: /sys/class/power_supply/peripheral<n> where <n> is the index of a charge port. For example, when a stylus is connected to a NFC/WLC port, the node returns: /sys/class/power_supply/peripheral0/ capacity=50 charge_type=Standard scope=Device status=Charging type=Battery Signed-off-by:
Daisuke Nojiri <dnojiri@chromium.org> Signed-off-by:
-
Linus Walleij authored
This file isn't using any AB8500 symbols so drop these includes. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
If we rename the "abx500_chargalg" supply to "ab8500_chargalg" as it should be named, the existing supplies are supplying that supply but that was obviously not working since it had the wrong name. Now that the dependency kicks in we get a bunch of NULL references from ab8500_chargalg_external_power_changed() so check that the workqueue is allocated before we try to queue work on it. Signed-off-by:
-
Linus Walleij authored
Drop the entire idea with abx500 being abstract and different from ab8500 in the AB8500 charging drivers. This rids the two identical definitions of a slew of structs in ab8500-bm.h and makes things less confusion and easier to understand. Signed-off-by:
-
Linus Walleij authored
The "abx500" name on the charging algorithm stems from the ambition to produce a series of these analog basebands, re-using the same charging algorithm driver. No ASICs beside AB8500 and AB8505 were ever produced so this terminology is confusing. Rename the algorithm file and symbols to reflect the more narrow scope. Signed-off-by:
-
Linus Walleij authored
The kernel already has a static inline for linear interpolation so use that instead of rolling our own. Signed-off-by:
-
- 11 Jul, 2021 5 commits
-
-
Linus Torvalds authored
-
Hugh Dickins authored
I know nothing about zone_device pages and !device_private pages; but if try_to_migrate_one() will do nothing for them, then it's better that try_to_migrate() filter them first, than trawl through all their vmas. Signed-off-by:
Hugh Dickins <hughd@google.com> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Reviewed-by:
Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/1241d356-8ec9-f47b-a5ec-9b2bf66d242@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
In the unlikely race case that page_mlock_one() finds VM_LOCKED has been cleared by the time it got page table lock, page_vma_mapped_walk_done() must be called before returning, either explicitly, or by a final call to page_vma_mapped_walk() - otherwise the page table remains locked. Fixes: cd62734c ("mm/rmap: split try_to_munlock from try_to_unmap") Signed-off-by:
kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/lkml/20210711151446.GB4070@xsang-OptiPlex-9020/ Link: https://lore.kernel.org/lkml/f71f8523-cba7-3342-40a7-114abc5d1f51@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Hugh Dickins authored
The kernel recovers in due course from missing Mlocked pages: but there was no point in calling page_mlock() (formerly known as try_to_munlock()) on a THP, because nothing got done even when it was found to be mapped in another VM_LOCKED vma. It's true that we need to be careful: Mlocked accounting of pte-mapped THPs is too difficult (so consistently avoided); but Mlocked accounting of only-pmd-mapped THPs is supposed to work, even when multiple mappings are mlocked and munlocked or munmapped. Refine the tests. There is already a VM_BUG_ON_PAGE(PageDoubleMap) in page_mlock(), so page_mlock_one() does not even have to worry about that complication. (I said the kernel recovers: but would page reclaim be likely to split THP before rediscovering that it's VM_LOCKED? I've not followed that up) Fixes: 9a73f61b ("thp, mlock: do not mlock PTE-mapped file huge pages") Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/lkml/cfa154c-d595-406-eb7d-eb9df730f944@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by:
-
Hugh Dickins authored
Parallel developments in mm/rmap.c have left behind some out-of-date comments: try_to_migrate_one() also accepts TTU_SYNC (already commented in try_to_migrate() itself), and try_to_migrate() returns nothing at all. TTU_SPLIT_FREEZE has just been deleted, so reword the comment about it in mm/huge_memory.c; and TTU_IGNORE_ACCESS was removed in 5.11, so delete the "recently referenced" comment from try_to_unmap_one() (once upon a time the comment was near the removed codeblock, but they drifted apart). Signed-off-by:
-
