[PATCH 8/8] arm64: dts: hikey: Fix WiFi support

[...]

quoted

quoted

John, thanks for the report!

After a some investigation, I realized that the mmc pwrseq_simple
driver returns -EPROBE_DEFER as it's not able to get the "ext" clock.
Hence the SDIO card will not be detected.

To fix the problem, you need to enable CONFIG_COMMON_CLK_HI655X in the
kernel config. This is actually also the case when using the arm64
defconfig for a plain 4.12 rc3 and later. We should probably make this
driver enabled per default when building the arm64 defconfig.

Can you run a re-test at your side with the CONFIG_COMMON_CLK_HI655X
set? Just to make sure it works also with those boot binaries you are
using...

So unfortunately, now I'm seeing a side-effect from enabling
CONFIG_COMMON_CLK_HI655X.

Using the serial-dev driver for the TI bluetooth, it seems I'm seeing
failures when CONFIG_COMMON_CLK_HI655X is enabled, but configuring it
out, bluetooth works (and wifi then fails).

Looking through the dmesg logs, the bluetooth driver seems to
initialize up properly and load the firmware, but with CLK_HI655X
enabled, we see:

Bluetooth: hci0 command 0xff05 tx timeout
Bluetooth: hci0: send command failed\x0a
Bluetooth: hci0 command 0xff36 tx timeout
Bluetooth: hci0 command 0x1003 tx timeout
Bluetooth: hci0 command 0x1001 tx timeout
Bluetooth: hci0 command 0x1009 tx timeout
...

As Rob said below, this is because the blue-tooth driver doesn't
properly deal with the power on/off sequence.

I guess it works for you because your versions of the boot binaries
turns all needed resources on. That isn't the case for me, blue-tooth
is neither working before or after this change, but wifi is.

quoted

This effectively seems to make bluetooth an wifi functionality
exclusive.  So I don't think this is a sufficient solution (over
reverting the original patch that changes the dts - which allows both
to function).

Since the issues you are reporting about is depending on the
boot-binaries and not a really bugs in the kernel, may I suggest that
we invest our efforts in fixing the blue-tooth driver instead, as it's
there the real problem is!?

If the clock to the TI chip is described in DT for WiFi, then the BT
side needs it as well (as does the driver) for proper refcounting. The
same would apply to regulators as well. I looked at the regulators for
HiKey and the 2 supplies (Vbat and i/o) appear to both be always on.

Rob

Correct.

I am working on patch, I keep you on cc.

Kind regards
Uffe