BCM2048 bluetooth connected over OMAP serial
Hi!
So, there's bluetooth chip that's connected to the SoC by UART and some GPIOs. What would be right representation in the device tree? Something like this?
bluetooth {
compatible = "broadcom,bcm2048";
uart = <&uart2>;
reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */
bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */
chip-type = <3>;
bt-sysclk = <2>;
reset-gpio-shared = <0>;
};Is there some way to prevent OMAP tty driver from binding to the device and exporting the device to userspace?
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 16 lines · On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
So, there's bluetooth chip that's connected to the SoC by UART and some GPIOs. What would be right representation in the device tree? Something like this?
bluetooth { compatible = "broadcom,bcm2048"; uart = <&uart2>; reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */ chip-type = >; bt-sysclk = <2>; reset-gpio-shared = <0>; };
Quoted 2 lines
Is there some way to prevent OMAP tty driver from binding to the device and exporting the device to userspace?
I think from the driver perspective, you want this to be a tty line discipline rather than a driver that attaches to the physical uart.
For the DT representation, I fear we haven't got a precedent. A uart phandle sounds reasonable, but there might be other ways to do it and we should consider if there are better alternatives. It could possibly be a child node of the uart, but that would require other infrastructure in the kernel because we don't currently create devices for those.
Arnd
Quoted 24 lines · Arnd Bergmann
Quoted 16 lines · On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
So, there's bluetooth chip that's connected to the SoC by UART and some GPIOs. What would be right representation in the device tree? Something like this?
bluetooth { compatible = "broadcom,bcm2048"; uart = <&uart2>; reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */ chip-type = >; bt-sysclk = <2>; reset-gpio-shared = <0>; };Quoted 2 lines
Is there some way to prevent OMAP tty driver from binding to the device and exporting the device to userspace?
I think from the driver perspective, you want this to be a tty line discipline rather than a driver that attaches to the physical uart.
Quoted 6 lines
For the DT representation, I fear we haven't got a precedent. A uart phandle sounds reasonable, but there might be other ways to do it and we should consider if there are better alternatives. It could possibly be a child node of the uart, but that would require other infrastructure in the kernel because we don't currently create devices for those.
I think the child node is the way to go; that would match what we do for I2C and SPI. We might need new infrastructure, but I don't think we should treat this differently simlpy because we don't have that yet.
Mark.
Quoted 32 lines · Mark Rutland
Quoted 24 lines · Arnd Bergmann
Quoted 16 lines · On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
So, there's bluetooth chip that's connected to the SoC by UART and some GPIOs. What would be right representation in the device tree? Something like this?
bluetooth { compatible = "broadcom,bcm2048"; uart = <&uart2>; reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */ chip-type = >; bt-sysclk = <2>; reset-gpio-shared = <0>; };Quoted 2 lines
Is there some way to prevent OMAP tty driver from binding to the device and exporting the device to userspace?
I think from the driver perspective, you want this to be a tty line discipline rather than a driver that attaches to the physical uart.
Quoted 6 lines
For the DT representation, I fear we haven't got a precedent. A uart phandle sounds reasonable, but there might be other ways to do it and we should consider if there are better alternatives. It could possibly be a child node of the uart, but that would require other infrastructure in the kernel because we don't currently create devices for those.
Quoted 3 lines
I think the child node is the way to go; that would match what we do for I2C and SPI. We might need new infrastructure, but I don't think we should treat this differently simlpy because we don't have that yet.
Well, uart in this case looks more like a GPIO than an I2C (no addressing, just few wires). And we do phandle for GPIOs.
Actually, the chip also has PCM, analog audio, and "pc compatible?" connections, plus some connection to WIFI. So we may need more phandles there....
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
Quoted 33 lines · Pavel Machek
Quoted 32 lines · Mark Rutland
Quoted 30 lines · Arnd Bergmann
Quoted 16 lines · On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
So, there's bluetooth chip that's connected to the SoC by UART and some GPIOs. What would be right representation in the device tree? Something like this?
bluetooth { compatible = "broadcom,bcm2048"; uart = <&uart2>; reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */ chip-type = >; bt-sysclk = <2>; reset-gpio-shared = <0>; };Quoted 2 lines
Is there some way to prevent OMAP tty driver from binding to the device and exporting the device to userspace?
I think from the driver perspective, you want this to be a tty line discipline rather than a driver that attaches to the physical uart.
For the DT representation, I fear we haven't got a precedent. A uart phandle sounds reasonable, but there might be other ways to do it and we should consider if there are better alternatives. It could possibly be a child node of the uart, but that would require other infrastructure in the kernel because we don't currently create devices for those.
Quoted 6 lines
Quoted 3 lines
I think the child node is the way to go; that would match what we do for I2C and SPI. We might need new infrastructure, but I don't think we should treat this differently simlpy because we don't have that yet.
Well, uart in this case looks more like a GPIO than an I2C (no addressing, just few wires). And we do phandle for GPIOs.
Right and the devices use I2C for full communication and GPIOs as helpers. I guess UART counts as full communication and not as helper.
phandle vs child node is not a matter of adressing and btw where is the difference between "5th gpio on 1st gpio controller" and "5th address on 1st i2c controller"?
Quoted 3 lines
Actually, the chip also has PCM, analog audio, and "pc compatible?" connections, plus some connection to WIFI. So we may need more phandles there....
This is much harder to solve. I think we don't have a DT binding for a device, which uses two communication interfaces as the bcm2048 (uart & i2c). OTOH we may just add a slave device for the fm-radio part like this:
uart {
bcm2048 {
stuff;
};
};i2c {
bcm2048-radio {
master = <&bcm2048>;
};
};-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141210/eb7b900d/attachment.sig>
Neil Brown send series which implement what was suggested in previous posts:
https://lkml.org/lkml/2014/12/11/454
Quoted 71 lines · sre at debian.org
Hi,
Quoted 33 lines · Pavel Machek
Quoted 32 lines · Mark Rutland
Quoted 30 lines · Arnd Bergmann
Quoted 16 lines · On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
So, there's bluetooth chip that's connected to the SoC by UART and some GPIOs. What would be right representation in the device tree? Something like this?
bluetooth { compatible = "broadcom,bcm2048"; uart = <&uart2>; reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */ chip-type = >; bt-sysclk = <2>; reset-gpio-shared = <0>; };Quoted 2 lines
Is there some way to prevent OMAP tty driver from binding to the device and exporting the device to userspace?
I think from the driver perspective, you want this to be a tty line discipline rather than a driver that attaches to the physical uart.
For the DT representation, I fear we haven't got a precedent. A uart phandle sounds reasonable, but there might be other ways to do it and we should consider if there are better alternatives. It could possibly be a child node of the uart, but that would require other infrastructure in the kernel because we don't currently create devices for those.
Quoted 6 lines
Quoted 3 lines
I think the child node is the way to go; that would match what we do for I2C and SPI. We might need new infrastructure, but I don't think we should treat this differently simlpy because we don't have that yet.
Well, uart in this case looks more like a GPIO than an I2C (no addressing, just few wires). And we do phandle for GPIOs.
Right and the devices use I2C for full communication and GPIOs as helpers. I guess UART counts as full communication and not as helper.
phandle vs child node is not a matter of adressing and btw where is the difference between "5th gpio on 1st gpio controller" and "5th address on 1st i2c controller"?
Quoted 3 lines
Actually, the chip also has PCM, analog audio, and "pc compatible?" connections, plus some connection to WIFI. So we may need more phandles there....
This is much harder to solve. I think we don't have a DT binding for a device, which uses two communication interfaces as the bcm2048 (uart & i2c). OTOH we may just add a slave device for the fm-radio part like this:
uart { bcm2048 { stuff; }; };i2c { bcm2048-radio { master = <&bcm2048>; }; };
Quoted 7 lines
-- Sebastian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
BR,
marek
Signature · 10 lines
as simple and primitive as possible ------------------------------------------------- Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com
Quoted 17 lines · Pavel Machek
Hi!
So, there's bluetooth chip that's connected to the SoC by UART and some GPIOs. What would be right representation in the device tree? Something like this?
bluetooth { compatible = "broadcom,bcm2048"; uart = <&uart2>; reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */ chip-type = <3>; bt-sysclk = <2>; reset-gpio-shared = <0>; };
Quoted 2 lines
Is there some way to prevent OMAP tty driver from binding to the device and exporting the device to userspace?
Isn't the normal way for BT to work is the uart is exposed to userspace and the BT stack is all in userspace? This is how other Broadcom BT/WiFi combo parts work.
Rob
Hi Rob,
Quoted 15 lines
Quoted 15 lines
So, there's bluetooth chip that's connected to the SoC by UART and some GPIOs. What would be right representation in the device tree? Something like this?
bluetooth { compatible = "broadcom,bcm2048"; uart = <&uart2>; reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */ chip-type = <3>; bt-sysclk = <2>; reset-gpio-shared = <0>; };
Quoted 6 lines
Quoted 2 lines
Is there some way to prevent OMAP tty driver from binding to the device and exporting the device to userspace?
Isn't the normal way for BT to work is the uart is exposed to userspace and the BT stack is all in userspace? This is how other Broadcom BT/WiFi combo parts work.
not on Linux actually. The Bluetooth core layer (including the HCI transport) are all in kernel space.
However UART based Bluetooth chips are exposed as TTY and then the N_HCI line discipline is used to attach it to the kernel Bluetooth subsystem.
Regards
Marcel