The haptics boost can be used to supply either USB or wireless sourcing
mode by the charger firmware, and it needs to notify haptics driver to
clamp the haptics Vmax settings accordingly. Handle the VMAX_CLAMP
notification from charger firmware and notify the haptics driver through
a notifier call.
Change-Id: If06fa8631d9f4dc264b729ccb9fbc7c154ad3f27
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Currently during fast charging, charger FW on ADSP sends battery power
supply notifications to HLOS even while in sleep. These notifications
cause HLOS to come out of sleep to process the request. This is not needed
as display is OFF and any change in battery status will not be updated on
screen.
Add panel event notifiers to receive notifications from display FW so that
power supply notifications from the charger FW can be disabled when the
panel is turned off and re-enabled when the panel is on.
Change-Id: Ibf9e688f1571fd40ca18a1155fce95efd039690b
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Currently, thermal mitigation is supported with "qcom,thermal-mitigation"
property where different fast charging current(FCC) levels can be
specified as an array. This would be applied when thermal SW votes for a
mitigation level through CHARGE_CONTROL_LIMIT property.
For some boards, the number of levels can be simply obtained by specifying
a fixed FCC tep as the maximum FCC supported is already obtained from the
charger FW. Add Support for this via "qcom,thermal-mitigation-step"
property. With this, we don't have to override "qcom,thermal-mitigation"
property for battery type variation (1S vs 2S).
Change-Id: I16af90545924d8880a6c49d02935b4d21a86c417
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Userspace health HAL implementation waits for capacity property from
the battery power supply to be available before starting health HAL
service. This is needed to ensure the battery power supply device
is found by health HAL consistently. However, if the registration
of other power supply devices like USB and Wireless takes time and
health HAL initializes before that, Android battery monitor would
not be reading any properties from these power supply devices.
Fix this by registering the battery power supply after registering
USB and Wireless power supply. This would ensure that by the time
health HAL initializes, USB and Wireless power supply devices can
be available.
CRs-Fixed: 2998433
Change-Id: I3b71c86eaa774bdfcef3686109d7a25ac52be16c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Currently, when SOC reaches 0 and device is not charging, we
depend on the userspace (e.g. Android battery manager service)
to initiate a shutdown. Sometimes, this takes more time than
expected (> 20 seconds). When the device is discharging with a
high system load, this may cause device to brown out as the
battery voltage can go below the safe operating level. Add
support to initiate an emergency shutdown when the following
conditions are met.
- Battery SOC is 0
- Battery is not charging
- Battery voltage is lower than a specified level
Add "qcom,shutdown-voltage" to support this.
Change-Id: I542ae08037c4e9db23d338b8de2eeb32c809a0a6
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Currently, prepare time for wireless FW update is set to 300 ms.
This was sufficient enough for previous targets which had used
wireless receiver IDT9412. For IDT9415, a prepare time > 300 ms
is required to make sure pre-regulator is disabled and WLS_IN is
plugged out. Hence, increase this to 1 second so that it can be
well accommodated.
Change-Id: Ibff4ec606257e04fcf0405c3f145585d30a38ed7
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
During shutdown when configuring ship mode based on user request,
battery charger driver sends BC_SHIP_MODE_REQ_SET message to the
charger firmware to do configuration before the shutdown. However
the response from the charger firmware is not handled and hence a
timeout is observed in the logs. Fix it.
Fixes: 1df95fc50926 ("power: supply: qti_battery_charger: Enable Ship mode shutdown")
Change-Id: I9149a256e4af40c3dcf2f0019f27e711a97f4493
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Currently, during wireless FW update process, qti_battery_charger
driver waits for FW update status for a period of 1 second after
sending all of the FW chunks. This wireless FW update time depends
on the wireless transceiver being used. E.g. IDT9412 needed only
1 second but IDT9415 requires up to 2 seconds as computing and
validating the CRC seems to be consuming more time. To support
such variance in wireless FW update time, add a parameter which
can be configured at runtime.
This can be configured (in ms) as below.
echo 2000 > /sys/class/qcom-battery/wireless_fw_update_time_ms
Change-Id: Ifa8104544138254e1029ab1fcaa9f40e61cc0961
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
During shutdown, battery charger driver sends BC_SHUTDOWN_NOTIFY
message to the charger firmware to do configuration before the
shutdown. However, the response from the charger firmware is not
handled and hence a timeout is observed in the logs. Fix it.
Fixes: eab52908558f ("power: qti_battery_charger: Add a shutdown notification")
Change-Id: I56f06b60bea0f1059f10684c32e9a7cf7acbdc9e
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Currently, updating USB type only depends on USB status change
notification from the charger firmware. During a reboot with USB
connected, there is a chance that a USB power supply notification would
have been sent by the charger firmware little earlier even before the
battery charger driver was ready to handle it. Hence it would've got
missed and USB type is not updated properly. Fix it by scheduling
usb_type_work once the driver probes.
Change-Id: I0ae482e90a76a0b2128fcc45561adb77a2ca017c
Signed-off-by: Fenglin Wu <fenglinw@codeaurora.org>
Due to a race condition between the probe and glink message
callback, it is observed that the glink messages/notifications
can be handled even after the probe failure which leads to
an invalid memory access. Fix it by introducing "initialized"
flag. While at it, add few error logs to identify the exact
message failures.
Change-Id: I18e61dea734efde6a11ee072793da8eead269b12
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Currently, wireless FW update is done by the user once a FW file
is pushed to one of the firmware folders and with user writing
to "wireless_fw_update" or "wireless_fw_force_update" under
/sys/class/qcom-battery.
As per the recent requirements to add CRC check during wireless
firmware update process, add "wireless_fw_crc" property through
which the user can pass CRC before doing FW update. Since this
adds extra time for validating the CRC, increase the wait time
for FW update completion from 500 ms to 1 second. Also, print an
error log if FW update is not done.
E.g.
echo 0x1234 > /sys/class/qcom-battery/wireless_fw_crc
echo 1 > /sys/class/qcom-battery/wireless_fw_update
Now with adding this support, if CRC is not set, FW update would
fail as the charger firmware validates the CRC passed.
Change-Id: Id66cd84984b6206bf866ee1f18f7b32d9090c5dd
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
When the remote subsystem restarts (SSR) or the charger firmware
restarts (PDR), resend the ICL/FCC votes from clients like USB
driver, thermal SW once the subsystem is up.
Change-Id: Ia0da3747fdb98c7873b65c948b76f6b6a286e31c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
With adding support to restricted charging through properties
restricted_chg and restricted_cur under /sys/class/qcom-battery,
configuring fast charging current (FCC) via "charge_control"
property in battery power supply is not working as expected.
Especially, when the restricted charging is disabled, FCC
configured (i.e. after setting it in ascending order first and
in descending order) is based on the previous request instead of
the current request. Fix it.
Fixes: 9c3f7e472cb6 ("power: supply: qti_battery_charger: add some more properties")
Change-Id: I6c591a0e1e914b37764350fb7389824410800868
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Now that the power supply framework has POWER_SUPPLY_TYPE_WIRELESS
change the wireless power supply type from MAINS to WIRELESS. This
would help android healthd to show "chg=w" rather than "chg=a" in
logs when a wireless charger is connected.
Change-Id: I871779aa806f775e2cdf1e0994593fc991fe77f9
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
USB driver can request for an ICL override (e.g. 2 mA when the
host enters suspend) when the device is connected to the host to
a SDP or a port that supports USB_PD. With USB_PD, if PDO 1 has
bit 28 set to 1, it advertises that suspend is supported. Hence
allow setting ICL for USB_PD charger as well.
Change-Id: I5a9eea05c58a7c8140c2910be97788f7f63efb05
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Currently, USB power supply type is set to POWER_SUPPLY_TYPE_USB
in power supply descriptor. power_supply_show_property() would
show POWER_SUPPLY_PROP_TYPE based on psy->desc->type. Userspace
process like healthd would read POWER_SUPPLY_PROP_TYPE to print
the adapter type in logs (e.g. "chg=u" for SDP, "chg=a" for DCP).
Hence update usb_psy_desc type runtime to show the USB power
supply type accordingly. This is useful for testing.
Change-Id: Icd88098f97beba053105d826614b4182f3716144
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
To support userspace application and testing, add some more
properties under USB power supply and qcom-battery class.
To show USB connector temperature, following property is added.
- /sys/class/power_supply/usb/temp
To support restricted charging similar to legacy targets,
following parameters are added.
- /sys/class/qcom-battery/restrict_cur
- /sys/class/qcom-battery/restrict_chg
To show whether the Type-C sink/source connected is compliant,
following parameter is added.
- /sys/class/qcom-battery/usb_typec_compliant
To show the custom USB_TYPE for Quick charge adapters like HVDCP,
HVDCP3 etc., following parameter is added.
- /sys/class/qcom-battery/usb_real_type.
Change-Id: Ia8dfba41c6ed3056dda588a1955a60ef19568112
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
With charger mode enabled in android, device boots into charger
mode when it is powered on with USB insertion. In this mode,
health HAL and charger service handles the power supply uevents
sent from power supply framework to take certain actions. For
example, when the USB or travel adapter (TA) is removed, device
would shut down in 10 seconds.
With a TA connected, device can enter suspend whenever possible
during charging. When the TA is removed after the device has
entered suspend, device comes out of suspend upon the notification
received from charger firmware (CHGFW) over PMIC Glink. Battery
charger driver handles this and calls power_supply_changed on one
of the power supply devices. However, before this uevent is
received and handled by charger service in the userspace, device
can enter suspend immediately.
In a low power discharging state, device stays in this state for
minutes until it gets another notification from CHGFW for battery
power supply, a periodic event which makes charger service to
initiate a shutdown. This conflicts with the user expectation
where the device has to shutdown in 10 seconds upon TA removal.
Workaround this problem by keeping the device awake for at least
50 ms when a notification is received from CHGFW. This way,
userspace process like charger could get a chance to receive and
handle the power supply uevents.
Change-Id: I9ea78eb6565988ffac0e6c5eee1ccae8dc7e3e3a
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
This feature is to enable the disconnection of the battery from the
device as the final step in the assembly of a phone on the factory floor
to prevent battery rundown while in transit to the hands of the final
consumer.
Usage:
# echo 1 > /sys/class/qcom-battery/ship_mode_en
Following this, either manually shut down using power key, or:
# reboot -p
Change-Id: Ifef053c6ebb3b86c10f9dbe3c9c47d7c3548d95b
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Add support for wireless charger firmware update in battery charger
driver through "wireless_fw_update" and "wireless_fw_force_update"
properties under "/sys/class/qcom-battery". Support firmware update
for wireless charger (IDT9412) for which firmware is split into
multiple chunks (128 bytes each) and sent over PMIC Glink. Charger
firmware running on the remote subsystem does the FW update by
communicating with IDT9412.
Wireless charger firmware name should be specified via a device tree
property "qcom,wireless-fw-name".
To update wireless firmware, user has to push the FW binary to a
firmware partition (e.g. /vendor/firmware) and then do one of the
following.
Normal update for which FW version check is made:
# echo 1 > /sys/class/qcom-battery/wireless_fw_update
Forced update for which FW version check is skipped:
# echo 1 > /sys/class/qcom-battery/wireless_fw_force_update
To read back FW version:
# cat /sys/class/qcom-battery/wireless_fw_version
Change-Id: Id565e7d5a73041d6e0340edc66eb8b1615396435
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
There are clients who are waiting for power supply change events
when fake soc is set during testing. Call power_supply_changed()
to support them.
Change-Id: I6a1f4e7daa136b3783f5ed35f37abafad7447378
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
The remote subsystem does not transmit PMIC GLINK notifications
triggered by charging parameter changes when a debug battery (one whose
battery ID is set to 7.5 Kohms) is detected. This allows it to enter low
power mode provided no queries for individual power supply (PSY)
properties are made of it.
Power consumption monitoring tests require it to enter low power mode
and stay there, which can happen only if it is not disturbed by having
to respond to queries made by HLOS for PSY properties. This change
enables the user to block all PMIC GLINK Tx messages from this driver to
remote subsystem by setting the boolean debugfs property "block_tx".
Once this is done, all subsequent reads of PSY properties will return
not the instantaneous values of those quantities, but the last (stale)
values obtained during the last read that was made prior to Tx being
blocked. To return to normal behaviour and obtain instantaneous values
from the remote subsystem, the debugfs property must be cleared.
Change-Id: Ie9b6ec78dcb8ec00102e9d7d23e238445045206f
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Currently, prop_id (u32) and val (u32) are obtained for all messages
in handle_message(). However, the response for notification request
doesn't have the same payload but only an u32 return code. Because
of this, an unintentional memory read for u32 is being made even
though it is not used.
Fix this by getting prop_id and val only for response messages that
are intended to get battery/USB/wireless power supply properties.
CRs-Fixed: 2655408
Change-Id: I4d17d965f911eb6a4357e29117191f78830e9e5c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Currently, when "qcom,thermal-levels" is specified and the
values are not in descending order, an error is returned which
fails the driver probe thereby causing battery/USB power supply
not available. Same problem can happen when charger firmware
returns a lower value for BATT_CHG_CTRL_LIM_MAX than the maximum
value specified under "qcom,thermal-levels" property. Without a
battery power supply, user would not know the battery charging
status. To avoid this, just return 0 after printing an error.
This would only affect the user by disallowing a change to the
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT property under battery
power supply.
Change-Id: I216d4d370e71ec5003adbee2600191e36a45e870
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Setting a fake battery SOC (state of charge) is useful to test
different mitigation levels. Add support for it by exposing
fake_soc under qcom-battery class which can be set only when
CONFIG_QTI_PMIC_GLINK_CLIENT_DEBUG is enabled.
To set fake_soc of 50%,
echo 50 > /sys/class/qcom-battery/fake_soc
To clear fake_soc so that actual battery SOC can be displayed,
any value other than 0-100 can be set to fake_soc.
echo -1 > /sys/class/qcom-battery/fake_soc
Change-Id: Ibff337fb4da9d4e9aadbe148f3eecca9e2d69604
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Add subsystem restart (SSR) support to battery charger driver so
that it can stop read/write properties when subsystem goes down.
Also, send message to enable notification again once subsystem
comes up.
Change-Id: I64f3abfa1d12c4e6a65fd01d7f66155c8741e68a
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Input Current Limit (ICL) needs to be set only for SDP and not
for other charger types. Add that logic.
Change-Id: Ib48acf5666ea4190b7a11c27ab9cefbb534632fb
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Fix pmic_glink_client_data initialization without which ssr_cb
that would be added in the upcoming patch causes an incorrect
list addition to PMIC Glink notification list.
Change-Id: I7588ae894e8188c30456f4c16711bc6b757a9863
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Add "qcom,thermal-mitigation" property to specify charging
current thresholds for thermal mitigation levels. These values
will be passed on to the charger firmware running on a remote
subsystem when thermal SW sets CHARGE_CONTROL_LIMIT property in
battery power supply.
Change-Id: I67be3f9012718de9b2cd529ed6043fb54f503003
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Charger firmware sends some battery related events with a generic
notification opcode. Handle such notifications as well to send
events up to the userspace.
Change-Id: Ia35fb7dbe56183d3c7c7a66b5f387b94072e6ed0
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Add Qualcomm Technologies, Inc. battery charger driver which
interfaces with the charger firmware running on the remote
subsystem (e.g. DSP) by communicating over PMIC Glink channel and
provides information about the battery, USB and wireless charging
by exposing them as power supply devices.
Change-Id: I36a2efd0b66bc5f79515b5faa318c537a5927e76
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Add a check to ensure that the remote subsystem sends the full and
expected length of the notification message.
Change-Id: I78d2c708c924cb864b7636bda81f290e310beb54
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Execute the client's callback in a separate thread to avoid the
following deadlock situation:
- altmode_callback() calls the client's callback when a valid amclient
is found and program execution waits for it to finish.
- The client's callback calls altmode_send_data() to send the PAN_ACK.
- altmode_send_data() eventually calls altmode_write(), which is waiting
for the response_received to be "completed" in altmode_callback().
- For response_received to be "completed", altmode_callback() must
finish executing in order to process the USBC_CMD_WRITE_REQ message
received from the remote subsystem.
- altmode_callback() cannot finish executing until altmode_send_data()
returns.
- altmode_send_data() times out and passes on the error to the client.
Also perform the following:
- Add a check to ensure that the payload received from the remote
subsystem is at least 9 bytes long.
- Prevent out of bounds access for USBC_CMD_WRITE_REQ message (which is
of a different format than struct usbc_notify_ind_msg) by moving the
port_index reading to only the USBC_NOTIFY_IND message in
altmode_callback().
CRs-Fixed: 2713590
Fixes: 6c0ffc67e574 ("soc: altmode: Detect when remote subsys fails to respond")
Change-Id: I0f2c6ce0f843c43c9e7e301be9ff3ad913310f62
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
The remote subsystem acknowledges all Altmode PMIC GLINK messages sent
to it. Print an error message anytime it fails to do this.
In the case when no client is found for a received message, do the
sending of the ack in a separate worker thread instead of a plain
function call to altmode_send_ack(). This is to avoid a deadlock and
consequent timing out in altmode_write(), which will happen in the
following scenario:
- A message is received for a nonexistent client.
- altmode_send_ack() is called from within altmode_callback().
- The PAN ACK is sent to the remote subsystem via pmic_glink_write() in
altmode_write() and the remote subsystem replies with an ACK (opcode
USBC_CMD_WRITE_REQ).
- Subsequently, in altmode_write() we wait for completion timeout, which
will happen only if this new ACK message is processed by PMIC GLINK.
- PMIC GLINK is waiting for altmode_callback() to return so that it can
process the new message.
- We are still waiting in altmode_callback() for altmode_send_ack() to
complete.
- We time out in altmode_write() waiting for the completion to occur.
This problem is solved by firing off a worker thread to send the PAN ACK
so that altmode_callback() can exit quickly and allow the incoming new
ACK to hit the complete() in the USBC_CMD_WRITE_REQ case in
altmode_callback().
Also add a couple of minor fixes to some debug messages while we're at
it.
Change-Id: I3d80b1a7d6cc03b0eba61b5c9cc660ce7d377942
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Add debugfs nodes to send Pin Assignment Notifications Enable (PAN EN)
and Acknowledgment (ACK) commands manually if needed, to aid in
debugging situations where it is unclear whether clients are sending
these commands synchronously as per design.
Change-Id: I7a68d676df86cbf6952158202c8e4958db032d5b
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Remove the device tree property "qcom,altmode-name" and the logic it
feeds as it was meant to help in the cases when there are multiple
altmode devices. Since there is going to be only one altmode device as
per design, this is no longer needed.
Change-Id: Ife15e39becee5f4ff03bdcc56ff62ae812fe2726
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Client API changes:
- Update client APIs to align them more closely with upstream
conventions.
- In particular, change the link between altmode device and client from
the altmode device's name string to a phandle to the altmode device
followed by the port index of the client.
- Instead of using solely the client's SVID as the key for idr_alloc,
include port_index as well because the unique identifier of a client
is the (SVID, port_index) tuple.
Updates to client notifying mechanism:
- Get rid of the standard notifier APIs in favour of a simpler callback
function-based mechanism to notify clients of probe completion.
- In addition, if clients probe after altmode finishes probing, they
will not get notified of probe completion as this is done only once at
the end of altmode_probe(). Fix this so that if a client registers for
probe completion notifications after altmode probes, they get notified
immediately.
While at it, get rid of the global list of altmode devices (amdev_list)
as there will only be a single altmode device in the system as per
design.
Change-Id: Iea450d30d9cc94671f505b7ff0c6e98b0b8a4467
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Add subsystem restart (SSR) support to altmode glink driver so
that when subsystem goes down and comes up again, it can send
PAN_EN to charger firmware to receive notifications about altmode
interface.
Change-Id: Ie011d5110b6c26790fe1dd6149115019f8bc261c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
The Type-C standard defines various "alternate (alt) modes" which enable
standard Type-C connectors to carry non-USB signals and data.
This driver provides an interface for Type-C alternate mode clients to
receive data such as Pin Assignment Notifications from the Type-C stack
running on a remote subsystem (e.g. DSP) via the PMIC GLINK interface.
Change-Id: Ic7eacb6901830cab181d91a1775cf02cddbccae2
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Currently, qti_battery_debug driver supports collecting QBG
context dump only for 1S battery. Add support to collect QBG
context dump for more than single cell to support 2S battery.
User can set "battery_cell_id" to select the QBG context dump
they would like to receive from the charger firmware that runs
on a remote subsystem.
Change-Id: I863b908a8c5bfae441431d31ac4dc8a491a0310c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Replace the "qbg_context" debugfs blob with a binary file associated
with the battery_debug device that provides the same functionality as
the existing debugfs blob for getting QBG context.
Usage:
# cd /sys/devices/platform/soc/soc:qcom,pmic_glink_log/\
soc:qcom,pmic_glink_log:qcom,battery_debug
# echo 1 > qbg_context
# cat qbg_context > file.bin
Change-Id: I59cfea2880362a95d8c87c02b4d823bfdca4e1e2
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Ensure that valid memory is allocated for the array of all votables
before an attempt is made to populate it.
Change-Id: I9a0c3e35e345a88560e39d47484348b6c476628d
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
As a preparatory move to adding device attributes to the battery_debug
device, remove the dependency on DEBUG_FS for driver enablement and add
config guards in the driver instead.
Change-Id: I8fcb385a583564935ce472416552e25ca79f4a84
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Add debugfs nodes to read and set votables from the firmware running on
the remote subsystem (e.g. DSP).
Also modify error handling logic in battery_dbg_add_debugfs().
Change-Id: I50f191add22cd500e04475f264e86cf16c6be48f
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
QBG device context dump length has been increased to 598 words in
the charger firmware. Increase the length to support upto 4KB.
Change-Id: I4a0a28044a54cdbde146101384f5a1ccf73b1562
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
QTI battery debug driver helps to get logs and debug information
by communicating with charger firmware (CHGFW) running on the
remote subsystem (e.g. DSP) over PMIC Glink. Currently, it
supports getting the device context dump of battery gauging
software which is part of CHGFW.
Change-Id: I7bb303cf61a97f3087f8c024fc6b37e68e5d1f1e
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
