Hi, On Wed, Dec 10, 2014 at 09:56:22PM +0100, Pavel Machek wrote: > On Wed 2014-12-10 18:42:03, Mark Rutland wrote: > > On Wed, Dec 10, 2014 at 05:02:42PM +0000, Arnd Bergmann wrote: > > > 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>; > > > > }; > > > > > > > > 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. > > > > 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"? > 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
Attachment:
signature.asc
Description: Digital signature