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

[Marcel Holtmann]

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.
> 
> Hardware-wise, the UARTs on SOCs I've seen are no different whether used
> for console or BT device. Of course, running UARTs at 3-4Mbps means
> things like hooking up external DMA controllers which are kind of
> pointless for normal tty use.
> 
> Perhaps BT and other UART devices could interface directly to the
> serial_core/uart_port layer rather than the tty layer? I've got no idea
> if that would buy us anything though. I'm guessing part of the problem
> here is the requirements for a character based interface are different
> from a more packet based interface (HCI) even if the h/w is the same.

interfacing directly with the serial / UART layer would be beneficial. For example ACPI already describes if the UART is used for Bluetooth operation and what settings it expects. That means that there is really no point in hooking it up as /dev/ttyFOO and then expect userspace to discover it again and attach a line discipline to it.

However for this to work, the UART layer would have to have some smarts to turn the extra ACPI provided information into a decision between /dev/ttyFOO and the creation of platform device. If such a platform device is present, we can then easily enumerate from a simple Bluetooth H:4 or 3-Wire driver. It just bind it it similar to what USB and SDIO is doing.

And of course exposing the same via DT instead of ACPI should be possible as well. I just know that ACPI has this since on Intel platforms it has been exposed like this for a while now. The main problem is that non of this is available easily to userspace to make the same smart decision on what TTY device node is for Bluetooth and what is the actual vendor of the Bluetooth chip. We need that as well to drive different firmware loading strategies.

Instead of a platform device, the TTY / UART layer could also turn into its own bus for these kind of things. I just don't know if bus vs platform device is the right solution here.

>> 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.
> 
> SDIO is such a pain. The hosts and devices have so many quirks as there
> is no interoperability testing.

What I have found is that the quirks are in the host controller for SDIO. Once that is working, the drivers have less quirks to handle. Then again, the number of Bluetooth based SDIO devices is limited. The majority of them are UART based in embedded devices.

> Do you ever see interdependencies between the BT and WiFi portions of
> the combo chips which have different host interfaces? They seem to be
> fairly well separated AFAICT. Some things like shared irq, clocks or
> regulators can be dealt with easily, but if you had things like the WiFi
> firmware has to be loaded and running before BT can work or vice-versa
> that would be a pain to deal with. That would impact how we do DT
> bindings as well.

In the combo chips the vendor normally has figured this out. So I have not heard about large. I can speak about some funky stuff from the past that never made it to the market, but lets not go there.

Regards

Marcel