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

[Ulf Hansson]

[...]

>>>
>>> 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.

>>
>> 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