Re: [PATCH v2 3/3] Bluetooth: hci_bcm: Add serdev support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Marcel Holtmann <marcel@xxxxxxxxxxxx> writes:

> Hi Stefan,
>
>>>>>>>> Add basic support for Broadcom serial slave devices.
>>>>>>>> Probe the serial device, retrieve its maximum speed and
>>>>>>>> register a new hci uart device.
>>>>>>>> 
>>>>>>>> Tested/compatible with bcm43438 (RPi3).
>>>>>>>> 
>>>>>>>> Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxx>
>>>>>>>> ...
>>>>>>>> 
>>>>>>>> +static int bcm_serdev_probe(struct serdev_device *serdev)
>>>>>>>> +{
>>>>>>>> +	struct bcm_bt_device *bcmdev;
>>>>>>>> +	u32 speed;
>>>>>>>> +	int err;
>>>>>>>> +
>>>>>>>> +	bcmdev = devm_kzalloc(&serdev->dev, sizeof(*bcmdev), GFP_KERNEL);
>>>>>>>> +	if (!bcmdev)
>>>>>>>> +		return -ENOMEM;
>>>>>>>> +
>>>>>>>> +	bcmdev->hu.serdev = serdev;
>>>>>>>> +	serdev_device_set_drvdata(serdev, bcmdev);
>>>>>>>> +
>>>>>>>> +	err = of_property_read_u32(serdev->dev.of_node, "max-speed", &speed);
>>>>>>>> +	if (!err)
>>>>>>>> +		bcmdev->hu.oper_speed = speed;
>>>>>>>> +
>>>>>>>> +	return hci_uart_register_device(&bcmdev->hu, &bcm_proto);
>>>>>>>> +}
>>>>>>> 
>>>>>>> We do not need any GPIO for reset lines or anything else for the rPI3?
>>>>>>> 
>>>>>> 
>>>>>> unfortunately we don't have full schematics for RPI3, but according to firmware dt-blob.dts [1] there is a GPIO called BT_ON. This GPIO is controlled by the GPIO expander on the RPI3 board. The necessary driver for this expander is still out of tree (last mainlining attempt [2]).
>>>>> 
>>>>> so who handles this GPIO then right now (or any other GPIO for that matter)? I have seen Bluetooth being enabled and operational, but I really want to get this working in a plain upstream Fedora and without using hciattach or btattach.
>>>> 
>>>> The GPU firmware enables the GPIO and keeps this state. The mentioned expander driver should provide the ARM core (Linux) the necessary control.
>>> 
>>> what is the default behavior after reboot. BT_ON enabled or not?
>> 
>> AFAIK: enabled

Correct: it's enabled by the 2nd stage bootloader and never modified
From there.

> that would be a funny default since it means that it consumes power
> even if Bluetooth is never used. We really want to hook this up into
> the Bluetooth power control of the controller. So that on power down
> it also disables it and saves as much power as possible.

We would need a driver to talk to the firmware for the GPIO expander to
turn it off.  I wrote one last year, but my motivation got killed by DT
bikeshedding.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux