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.
After changing from -fcommon which was the default in earlier gcc
releases, the dtc native build failed due to multiple declarations
of the form 'YYLTYPE yylloc'. Two of the declarations were removed,
which fixed the problem.
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.
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.
Due to the USB-C connector introducing a slight delay between the detection of
a stable VBUS and the data lines making contact, the delay after setting the
USB PHY into charger detection mode before reading the detection status had to
be increased from 1 ms to 500 ms, enabling the user to use 500 ms to insert the
USB-C connector fully into the device and still get a positive CDP/DCP port
detection, enabling higher charge current where this is offered.
Michal Koziel