PIP <1.11 has no support for polling wait. A hard coded delay was used
instead, but it only delayed wakeup from sleep. The cyttsp5 driver that
was used before introduction of this pt driver did not have any delay.
To obtain the HW version from user space:
cat /sys/devices/soc0/soc/30800000.aips-bus/30a40000.i2c/i2c-2/2-0024/hw_version
HW version obtained from the pt driver through sysfs was each time read
directly from the controller. The version was sometimes reported as
FFFF.FFFF.FF.
The HW version read during probing is now reported.
A number of error messages where printed to the console on boot. These
are either not errors at all, are not handled as errors or are not severe
enough to be treated as errors. The same messages where printed on every
boot. To avoid cluttering the console and potentially overshadowing
other errors these messages where reduced from errors to warnings.
Devices implementing PIP < 1.11 do not support polling wait. This is expected, hence the debug warning level has been reduced from DL_ERROR to DL_WARN.
To support system wake-up from 'standby' sleep via single tapping with
sensed touch data, we need to distinguish suspend type between 'mem' and
'standby', and only puts touch device into sleep for 'mem' sleep. It's
basically a rewriting of suspend/resume hooks, including:
- Drop easy-wake gesture handling, as we do not support it.
- Deal with pinctrl state, touch sleep and IRQ disabling only in case
of 'mem' sleep.
- Enable touch as a system wake-up source in case of 'standby' sleep.
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.
Add an optional device tree parameter
parade,fb_blanking_disabled
This parameter controls the blanking notifier.
If the parameter is set in the device tree,
the parade device will NOT change its state
according to the state of the framebuffer
device.
VDD_3V3_TOUCH power to cyttsp5 touch is controlled by GPIO TOUCH_PWR_EN.
Rather than relying on U-Boot to initialize the power, let's use
regulator to control it.
The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.
Even though brcmfmac does not use any of the new info it's important to
provide the proper struct buffer. Without this change new firmwares will
fallback to the very limited v3 instead of something in between such as
v4.
Signed-off-by: Dan Haab <dan.haab@luxul.com>
Reviewed-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 4282ff17e5 upstream)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
That struct is used when querying firmware for the STA. It seem is has
been changing during the time. Luckily its format seems to be backward
compatible starting with v2 (the only breakage was v1 -> v2).
The version that was supported by brcmfmac so far was v4. It was what
43602a1 and 4366b1 firmwares (7.35.177.56 and 10.10.69.3309 accordingly)
were using. It also seems to be used by early 4366c0 firmwares
(10.10.69.6908 and 10.10.69.69017).
The problem appears when switching to the 10.10.122.20 firmware. It uses
v5 and instead of falling back to v4 when submitted buffer isn't big
enough it fallbacks to the v3.
To receive all v4 specific info with the newest firmware we have to
submit a struct (buffer) that matches v5.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 07b1ae4687 upstream)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
That struct is passed by a firmware when querying for STA info. Flags
are used to indicate what info could be obtained.
These new defines may allow passing more info to the cfg80211 in the
future. They had been obtained from Broadcom's SDK file wlioctl_defs.h
used by DD-WRT.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 4b4a8d808c upstream)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Probably because of some issue we see on early version hardware, 200mhz
pinctrl state for SDIO was disabled. Although the following access
failure is seen with DDR50 mode, both SDR50 and SDR104 mode works pretty
good on recent rM2 device.
[ 122.957669] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x08000, err: -84
[ 122.965816] brcmfmac: brcmf_chip_recognition: chip backplane type 15 is not supported
[ 122.973674] brcmfmac: brcmf_sdio_probe_attach: brcmf_chip_attach failed!
[ 122.980381] brcmfmac: brcmf_sdio_probe: brcmf_sdio_probe_attach failed
[ 122.987089] brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
Add back 200mhz pinctrl state, so that AP5256 can work at SDR104 mode
and provide a much better WIFI throughput.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
As indicated by function esdhc_change_pinstate(), SDR50 and DDR50
require pins_100mhz, while SDR104 and HS400 require pins_200mhz. Some
system design may support SDR50 and DDR50 with 100mhz pin state only
(without 200mhz one). Currently the combined 100/200 MHz pinctrl state
check prevents such system from running SDR50 and DDR50. Separate the
check to support such system design.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The zero-sugar-wifi-cal_defconfig is maintained only for choosing BCMDHD
driver over BRCMFMAC. Kconfig fragment is good enough for this purpose.
Rename zero-sugar-wifi-cal_defconfig to zero-sugar-wifi-cal.config and
hold the minmal required changes in there. With this update, use the
following command to generate .config for build BCMDHD driver support.
$ make ARCH=arm zero-sugar_defconfig zero-sugar-wifi-cal.config
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
BCMDHD is able to figure out file name from chip_name_map[], see
drivers/net/wireless/bcmdhd/dhd_config.c. Drop file name from FW_PATH
and NVRAM_PATH, so that the options are not bundled with AP5256 but good
for other chipsets support like AP5203.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
from patchwork.kernel.org:
The linux-firmware brcmfmac firmware files contain an embedded table with
per country allowed channels and strength info.
These versions of the firmware are specially build for linux-firmware,
the firmware files directly available from Broadcom / Cypress rely on
a separate clm_blob file for this info.
For some unknown reason Broadcom / Cypress refuse to provide the standard
firmware files + clm_blob files it uses elsewhere for inclusion into
linux-firmware, instead relying on these special builds with the clm_blob
info embedded. This means that the linux-firmware firmware versions often
lag behind, but I digress.
The brcmfmac driver does support the separate clm_blob file and always
tries to load this. Currently we use request_firmware for this. This means
that on any standard install, using the standard combo of linux-kernel +
linux-firmware, we will get a warning:
"Direct firmware load for ... failed with error -2"
On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
device may have limited channels available" and we will get a slow
fallback to the userspace firmware loading mechanism.
This commit fixes both almost any brcmfmac device logging the warning
(leaving the brcmfmac info message in pace), as well as the slow and
unnecesary fallback by switching to request_firmware_direct for
the clm_blob.
- 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
This prevents a screen freeze bug.
If the regulator checks the on-off bit at the same
time as the thermal driver, the regulator_enable
call will conclude that the regulator is already
active.
Then, when the thermal driver is done checking the
temperature, it will set the PMIC back to the state
it was when it started, which is off.
In this state, the regulator driver believes the
PMIC is on, and the thermal has turned it off.
This can be considered a bit of a quick fix, to make
minimal changes to the kernel at this point. The
correct way to solve this would be to make the
sy7636a_thermal driver use the regulator network, or
moving all register access code into the sy7636a mfd
and use a mutex from there.
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.
Make initial sensing of device connection valid only for authenticated deviced.
Disable authenticated device connection precedure until finally implemented (TBD)
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.