Quickfix.
The ci_hdrc crashes if the DR mode is set to HOST while
it is interpreting the "set MODE bits to 0xf" state.
Possible chip errata, where the ci_hdrc has to be
powered on and off to work again.
Fixed by adding a delay of 300-400ms between enabling
OTG power out and setting USB mode to HOST mode.
NOTE: This should be further investigated, as a
delay of 300-400ms in kernel code is A LOT.
In order to read the current GPIO state regardless of the current controller
mode, and thus regardless of whether the GPIO irq is enabled, a direct
read of the raw GPIO state is done directly from the sysfs attribute_show
method.
Required synchronization was added to the access method to prevent race
if the attribute is read at the same time the irq handler is running.
When reading the otg1_chargermode property, a list of valid strings are
returned.
Valid enum values may be given when writing to the otg1_chargermode
property, in addition to one of the strings returned when reading
the property (Charger, OTG_supply, Off).
In order to prevent need for disconnection and reconnection of the QR code
reader during typical test-runs in factory, a check for current connection
state is added when entering unauthorized mode.
In addition, the device disconnect procedure setting charger/USB OTG back
to charging/device mode is performed when entering authorized mode, in which
device connection/disconnection detection is currently disabled.
Due to the authorized mode (default state) not being implemented
properly yet with filtering and such, a concern regarding short
while in a bag or such was discussed.
As a hot fix, the device connection (POGO ID pin) is deactivated
in default mode until this has been properly implemented, but
enabled when explicitly entering unauthorized mode from the
test-application in order to use the QR code reader.
When reading the otg controller mode from sysfs before changing it, returns 0.
This is not correct, as the default mode is 1.
As the controllermode is changed, the sysfs attribute shadow value is also changed.
Now also during fsm init.
To support suspend/resume from LPSR mode, we need to select default
pinctrl state in resume, so that IOMUXC settings can be restored from
power losing.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Device-connected sysfs property is vulnerable for simultanious access by
IRQ handler and sysfs property show handler.
Fix bug causing kernel stack-dump/crash when trying to read current pinctrl state through sysfs property
Temporary skip authentication of calling application
Check connection state before changing state (to keep connection state while
changing mode).
Other cleanup
- Fix typo in devicetree causing pincontrol not being registered
- Change pin mux states to use both RX and TX pin
- Implement preliminary first attempt to communicate over ow (wip)
- Add registration as extcon device
- Add ow tty property in device-tree
- Add ow gpio property in device-tree
- Add GPIO IRQ initiation/hanndling in delayed worker
Fix compilation by including <linux/extcon-provider.h> which is required
after porting otgcontrol from kernel v4.14 to v5.4.
Additionally fix the existing rm-otgcontrol.h header guard (#ifndef).
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Differentiate SNVS button click time for LPSR sleep
and power on:
Power off -> On - 500ms
LPSR Sleep -> Wake-up - 50ms
Turn off GPIO wake-up hack when not in LPSR sleep
To support system suspend during idle, we define 'standy' as sleep
without LPSR, while 'mem' as LPSR sleep. In this case, DT property
"fsl,enable-lpsr" is not needed any more, as lpsr_enabled should always
be true to support 'mem' sleep.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
In wake-up from LPSR, all watchdog powerdown gets enabled due to the
re-powering of SoC. We need to temporarily enable root and CCGR clock
of each watchdog and clear powerdown bit. Otherwise, system will reset
after 16 seconds. This watchdog initialization has been done by U-Boot
for the first time boot, and needs to be done for LPSR resume as well.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
- 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.
Lars Ivar Miljeteig