Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi

[Icenowy Zheng <icenowy@aosc.xyz>]

16.12.2016, 20:47, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Fri, Dec 09, 2016 at 07:49:00PM +0800, Icenowy Zheng wrote:
>>  2016年12月9日 下午4:07于 Maxime Ripard <maxime.ripard@free-electrons.com>写道：
>>  >
>>  > On Tue, Dec 06, 2016 at 04:08:38PM +0800, Icenowy Zheng wrote:
>>  > > Some SDIO Wi-Fi chips (such as RTL8703AS) have a UART bluetooth, which
>>  > > has a dedicated enable pin (PL8 in the reference design).
>>  > >
>>  > > Enable the pin in the same way as the WLAN enable pins.
>>  > >
>>  > > Tested on an A33 Q8 tablet with RTL8703AS.
>>  > >
>>  > > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>  > > ---
>>  > >
>>  > > This patch should be coupled with the uart1 node patch I send before:
>>  > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/471997.html
>>  > >
>>  > > For RTL8703AS, the rtl8723bs bluetooth code is used, which can be retrieve from:
>>  > > https://github.com/lwfinger/rtl8723bs_bt
>>  > >
>>  > >  arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 +-
>>  > >  1 file changed, 1 insertion(+), 1 deletion(-)
>>  > >
>>  > > diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
>>  > > index c676940..4aeb5bb 100644
>>  > > --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
>>  > > +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
>>  > > @@ -88,7 +88,7 @@
>>  > >
>>  > >  &r_pio {
>>  > >  wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
>>  > > - pins = "PL6", "PL7", "PL11";
>>  > > + pins = "PL6", "PL7", "PL8", "PL11";
>>  > >  function = "gpio_in";
>>  > >  bias-pull-up;
>>  > >  };
>>  >
>>  > There's several things wrong here. The first one is that you rely
>>  > solely on the pinctrl state to maintain a reset line. This is very
>>  > fragile (especially since the GPIO pinctrl state are likely to go away
>>  > at some point), but it also means that if your driver wants to recover
>>  > from that situation at some point, it won't work.
>>  >
>>  > The other one is that the bluetooth and wifi chips are two devices in
>>  > linux, and you assign that pin to the wrong device (wifi).
>>  >
>>  > rfkill-gpio is made just for that, so please use it.
>>
>>  The GPIO is not for the radio, but for the full Bluetooth part.
>
> I know.
>
>>  If it's set to 0, then the bluetooth part will reset, and the
>>  hciattach will fail.
>
> Both rfkill-gpio and rfkill-regulator will shutdown when called
> (either by poking the reset pin or shutting down the regulator), so
> that definitely seems like an expected behavior to put the device in
> reset.
>
>>  The BSP uses this as a rfkill, and the result is that the bluetooth
>>  on/off switch do not work properly.
>
> Then rfkill needs fixing, but working around it by hoping that the
> core will probe an entirely different device, and enforcing a default
> that the rest of the kernel might or might not change is both fragile
> and wrong.

I think a rfkill-gpio here works just like the BSP rfkill...

The real problem is that the Realtek UART bluetooth driver is a userspace
program (a modified hciattach), which is not capable of the GPIO reset...

>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel