It adds support of reading chipname via sysfs, so that user space can
distinguish WiFi module among AP5256, AP5256V and 1MW.
- AP5256
reMarkable: ~/ cat /sys/class/ieee80211/phy*/chipname
BCM4345/9
- AP5256V
reMarkable: ~/ cat /sys/class/ieee80211/phy*/chipname
BCM43012/2
- 1MW
reMarkable: ~/ cat /sys/class/ieee80211/phy*/chipname
BCM4345/6
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The chip id can either be four or five digits. For the chip name either
the hexadecimal value needs to be taken (four digits) or the decimal
value (five digits). The function brcmf_chip_name() does this conversion
so use it to store the name in driver revision info.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 756a2b3908 upstream)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
This is a backport of commit e3062e05e1 ("brcmfmac: Loading the
correct firmware for brcm43456") from upstream.
AP5256 is SDIO based brcm43456 and currently misdetected as brcm43455.
Correct the detection so that the firmware files can be loaded for both
1MW and AP5256 in names as below.
1MW: brcmfmac43455-sdio
AP5256: brcmfmac43456-sdio
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Although upstream accepts the solution of coding country code map in DT,
it will require different DTB between AP5256 (BCM4345/9) and AP5256V
(BCM43012/2). To support both chipsets with single kernel image and
DTB, let's hard code country code map table of AP5256 in driver, and use
it over the one from DT if any.
The map table of AP5256 comes from bcmdhd driver, ccode_43456c5[] in
drivers/net/wireless/bcmdhd/dhd_ccode.c.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
With any regulatory domain requests coming from either user space or
802.11 IE (Information Element), the country is coded in ISO3166
standard. It needs to be translated to firmware country code and
revision with the mapping info in settings->country_codes table.
Support populate country_codes table by parsing the mapping from DT.
The BRCMF_BUSTYPE_SDIO bus_type check gets separated from general DT
validation, so that country code can be handled as general part rather
than SDIO bus specific one.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Instead of aborting country code setup in firmware, use ISO3166 country
code and 0 rev as fallback, when country_codes mapping table is not
configured. This fallback saves the country_codes table setup for recent
brcmfmac chipsets/firmwares, which just use ISO3166 code and require no
revision number.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Function _pt_poll_for_fw_exit_boot_mode() is not needed to be called if
the controller is already out of boot mode. This function was delaying
resume from wakeup unnecessarly for modes other that boot.
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.
jebba