- Handle return code for regmap_write & regmap_read
- Rename some functions with misleading names
i.e "verify" when it actually writes, differentiate
between reading params from chip or device tree, etc
- Don't clear POR bit if writing data failed
- Set init complete even if "write custom params" fail,
as it will eventually time out and continue init anyhow
The max77818 charger device reports a valid connection status for
the chgin interface, regardless of whether it has been disabled or not
with chgin_sel.
The charging status is thus not reported correct, as the device is not
charging from the pogo interface even if the connection state indicates
otherweiz.
In order to report a correct state to userspace, the charger connection
state is now always reported to be false for the chgin interface (as
this is always turned off as soon as the connection state changes)
In order to be able to synchronize initial register write with other
drivers possibly accessing the same registers during init, an option
to apply a mutex lock (defined at the mfd level) is introduced.
The config register is also given a requirement to be locked, as this
register holds the FGCC bit which is the main cause of this option.
Due to uncertainty related to how safe it is to verify each custom
param during every boot, set the skip_verify flag for every custom param except
for the config register which is verified against current DT and reset if changed
for some reason since last boot.
This ensures that if an operation performed through the max77818 charger driver
was aborted by a reboot for instance, and the FGCC bit remained 0, it will be
restored to 1 after a reboot.
Due to the normal FG driver init configuring FGCC to be enabled during its normal
run, where all custom params configured in DT are verified and restored to the
original value if changed since last boot, charger driver sync has to be done
after completion of normal init.
This is now done in a separate worker which waits for the other init to complete
using a simple completion obj.
Also, unlock mutex at early return errors.
The status_ex is read during driver initiation, but the local shadow
variable was not updated, causing the status_ex to be "not connected"
even if the device was powered on with USB-C charger connected.max77818-battery: fix initial status_ex read bug
Failed read from device is likely to occur when the charger driver
properties are read directly from the charger driver and not via
the FG driver which makes sure the FGCC mode is turned off before
trying to access the charger device.
The warnings generated clutters the journal, and cause suspicion that
the driver or device is not working properly.
Operations done during FG driver initiation which address the charger driver is
collected in new init routine, which now reads initial status information required
to be shadowed in the FG driver (status_ex) and disables the chgin interface by
default.
When charger driver receives a request to set max current for the chgin
interface to 0, the CHGINSEL bit is set to 0 to disable the interface.
When it receives a request to set a non-zero max current for the chgin
interface, the CHGINSEL bit is reset to 1 to re-enable the interface.
When the FG driver receives a notification about a connection change
for the chgin interface, it set the max current for the chgin interface
to 0 (i.e turning it off) through the charger driver.
During driver init, the default safe value is set rather than the max possible
input current, which might draw too much from a normal USB host not capable of
supplying extended charge current.
- Do initiation of the charger irq regmap in the MFD driver while disabling FGCC
- Initiate charger interrupts in battery driver while disabling FGCC
- Add new charger irq handler in battery driver requesting status_ex
property from charger driver while disabling FGCC
(enabling separate status for chgin/wcin)
POWER_SUPPLY_PROP_STATUS_EX_CHANGING and POWER_SUPPLY_PROP_STATUS_EX_UNKNOWN
is added to the set of defined values for the power supply status_ex property.
This is required to indicate to userspace that an interrupt has occured,
and that the connection state is changing, and if the new connection state
could not be read, the status is unknown.
In order to do a set of operations in sequence while disabling FGCC,
two macros are defined to start by disabling FGCC mode end finish by
re-enabling FGCC mode, while ensuring that the operation is not interrupted
by another similar sequence by applying the same lock as used in the
MAX77818_DO_NON_FGCC_OP macro when starting the operation and releasing
the lock when finishin the opration.
In order for the FGCC flag to be flipped from modules/drivers external to the
max77818-battery driver, the FGCC enable/disable routine and corresponding
macro doing a non-FGCC operation by flipping the FGCC bit to disable FGCC,
do the operation and re-enable FGCC is moved to an external module max77818-utils.
All operations performed by charger driver which require FGCC mode to be disabled
in order for the driver to be able to communicate with the charger device
basically do the following which now are done with the MAX77818_DO_NON_FGCC_OP
macro:
Disable FGCC
Do required operation
Re-enable FGCC
The POWER_SUPPLY_PROP_CURRENT_MAX is used to set max current draw on CHGIN,
and the new POWER_SUPPLY_PROP_CURRENT_MAX2 (added to power-supply core for
this purpose) is used to set max current draw on WCIN.
In order for the MAX77818 driver to be able to set the max current separately
for the two VBUS lines, a new property was added (POWER_SUPPLY_PROP_CURRENT_MAX2),
enabling POWER_SUPPLY_PROP_CURRENT_MAX to configure USB1 max current draw and
POWER_SUPPLY_PROP_CURRENT_MAX2 to configure USB2 max current respectively.
The max77818-charger driver is used to set updated max current on given
interface, flipping the FGCC bit appropriately to enable charger device config
temporarily.
When going into LPSR sleep, the power is taken from the GPIO bank used for the
charge state GPIOs.
When returning from LPSR sleep, the GPIO pinctrl state has to be re-initialized
in order to enable the internal pull-up.
As the GPIOs are used as inputs and no other initialization is done during the
initial probe/init of the driver, no further action is required.
Add support for recognizing all expected read back charger_mode values.
Remove unwanted side-effect causing charger_mode to be written when
unrecognized value is read back.
When reading back charger_mode and the batery is (nearly) full,
the read back charger_mode from the charger device is not necessarily the same
as the written value due to internal states being triggered by current state
if charge. A mode 0x05 (Charger) written might yield a read back value of 0x04,
which is ok when the capacity is 100% but still an indication that the charger_mode
is set to "Charger".
Also when writing mode 0x00 (Off), the read back value might yield 0x01..0x03,
which has to be accepted as "Off".
Add post_fgcc_change_delay_us module parameter with default value
100000 us.
Move delay into FGCC enable/disable function.
Add delay both after FGCC enable and disable.
As the dpacc and dqacc registers change over time, these are skipped in addition
to other learned values to prevent them from being overwritten on every boot.
Unlock and re-lock of extra config registers were separated into common
functions to be used both in initial write_custom_params and new verify/write
routine.
Verification of the RelaxCfg register was also added to the new verify/write routine.
- Set 'verify' as the default config-update mode
- Add flag in max77818_of_property (is_learned_value) in order to prevent config
values given in DT as initial values that is expected to change from being
reset when device reboots and params are synced to curent DT.
The power_supply get_property handler is protected by a flag indicating
when the config init/update thread is complete, but this flag was not
synchronized.
In addition to this, the flag is now cleared before the driver is registered
as a power_supply device to properly tell the power_supply initiation to wait.
Add module parameter enabling complete FG config rewrite from DT or
only custom params update from DT depending on what is required.
The driver may be given either "max77818_battery.config_update=complete" or
"max77818_battery.config_update=partial" respectively through the kernel commandline
from u-boot.
Versioning scheme may then be implemented outside of the kernel if required,
and which update to apply to a given device will then be chosen by update scripts.
To get GPIO1/2 LPSR wakeup work, we have commit 57673afb8d27 ("zero-sugar:
init SNVS for LPSR GPIO wakeup") in U-Boot to set bit 7 of SNVS register
0x48. Unfortunately, it brings us a side effect, that is setting TOP
(Turn off System Power) bit of SNVS LPCR register results in an immeidate
reset instead of poweroff. To work around the issue, let's clear the bit
right before setting TOP bit for powering system off.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Fix flaw in probe causing IRQ init to be performed in FGCC mode and not when
FGCC is disabled (which is the intension).
Simplify FGCC re-enable code during FG driver init.
The current_max property was not read correctly in FGCC mode,
due to missing errorhandling when charger device is not accessible
over the I2C bus.
An error message is now returned instead of a false value when FGCC
mode is active.
The charger regmap should not be NULL, but to be sure that the regmap is never used
if NULL or ERR_PTR, a check for this has been introduced wherever this is used in
the charger driver.
A check is also done in the MFD driver before trying to initialize the charger irq.
In addition to this, a bug causing a stack dump during boot was found, causing
the powersupply subsystem's initial calls to get_property to fail due to the
mutex was created too late in the probe routine.
Lars Ivar Miljeteig