Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Marcel Holtmann <marcel@holtmann.org>]

Hi Rob,

>>> The WiFi side is actually in better shape than BT. With BT, we have
>>> Bluedroid vs. BlueZ, no real DT bindings to describe BT chips (plenty
>>> of examples of how not to do it[1]), and chip specific userspace
>>> initialization (firmware loading, baudrate setup, power mgt).
>> 
>> I was looking at it at one point and couldn't wrap my head around how
>> the BT support was devised from a kernel point of view.
>> 
>> It seems BT chips more often than not sit on a UART connection
>> (often very high speed) and since there is no "uart bus" or "serial bus"
>> akin to what we have for I2C or SPI, it is actually impossible to
>> instantiate them properly in the driver model. Instead BT drivers
>> are poked and peeked from userspace using the line discipline as
>> if they were some kind of modem, just in-kernel.
> 
> Yes, but then there's always some side band signals for regulator
> control, reset, clocks, wake-up, rf-kill, etc. that needs a glue
> driver. There's been some work by Neil Brown to create a UART slave
> bus[1] and I've gotten several other UART device bindings recently,
> but they all suffer from being one off device bindings done in
> different ways and I want to see something common here.
> 
> It also seems the BT folks are working on moving more of the setup
> into the kernel and creating a proper subsystem. I'm not sure about
> the details on that.

we are indeed moving a lot of the initialization and handling of the Bluetooth controller into the kernel. So that this can also be shared between USB and UART based controllers.

The work on UART slaves (or whatever it will be called eventually) is important for Bluetooth and most likely GPS and NFC in the future. It then allows to define all the nasty behind the curtain details of that UART via DT or ACPI in vendor drivers.

The Bluetooth driver in theory should not care at all and generally speaking it doesn't since the Bluetooth SIG has defined a Host Controller Interface (HCI) that is standard. Meaning all operation are well defined. Just the transport over UART has many vendor specific tweaks. The two most obvious ones are deep sleep modes and running the UART at high speeds.

In a perfect world I would prefer we are not using the Bluetooth HCI line discipline at all. The problem right now is that everybody wants to enable the UART as /dev/ttyFOO and then move on. However in reality they are not general purpose TTY devices. The only thing you can ever do with them is tell the Bluetooth subsystem that there is a TTY device and attach its line discipline to it.

The majority of these high speed UARTs in phones, tablets and also laptops with Bluetooth chips attached to it should just expose a special bus that we can then enumerate. Pretending to a general purpose UART is actually cumbersome and you will just see more and more of these.

While Bluetooth supports USB and SDIO as well, the most common other low power interface is the UART (using H:4 or 3-Wire Bluetooth transports). The usage of PCI or SPI or I2C as interface to Bluetooth never really happened.

Current Bluetooth/WiFi chips usually come in these flavors. WiFi on PCIe + Bluetooth on USB, WiFi + Bluetooth on USB, WiFi + Bluetooth on SDIO and WiFi on SDIO + Bluetooth on UART. Now if you are building a mobile phone, you can choose the low power version you like. And this often turns into SDIO for WiFi and UART for Bluetooth.

Or and did I mention that some manufactures actually put FM radio and GPS controls behind the Bluetooth chip. So access to these slave devices goes via the Bluetooth HCI. This means that you have this fun dependency:

FM radio -> Bluetooth HCI -> UART -> UART slave

Some nasty solution here are to double stack the line disciplines and have some sort of shared transport driver in between. I am trying to actually fix that so that Bluetooth drivers can expose proper platform buses with correctly assigned resources that the FM radio driver would just enumerate on. So that part is in the works as well.

We can also talk about A4WP and the corner cases where your battery is so drained that the Bluetooth Low Energy portion of your hardware is the only one that gets powered first before you get your device back to life. In case this is not obvious, the A4WP wireless charging technology using Bluetooth Low Energy for its communication.

Regards

Marcel