diff mbox

[1/1] Documentation: Add dt-binding for TI-btwilink driver

Message ID 1430106433-7132-1-git-send-email-gigi.joseph@ti.com
State New, archived
Headers show

Commit Message

Gigi Joseph April 27, 2015, 3:47 a.m. UTC
btwilink binds bluetooth hci0 interface with the shared transport driver

Signed-off-by: Gigi Joseph <gigi.joseph@ti.com>
---
 Documentation/devicetree/bindings/btwilink.txt | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/btwilink.txt

Comments

Marcel Holtmann April 27, 2015, 4:31 a.m. UTC | #1
Hi Gigi,

> btwilink binds bluetooth hci0 interface with the shared transport driver
> 
> Signed-off-by: Gigi Joseph <gigi.joseph@ti.com>
> ---
> Documentation/devicetree/bindings/btwilink.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/btwilink.txt
> 
> diff --git a/Documentation/devicetree/bindings/btwilink.txt b/Documentation/devicetree/bindings/btwilink.txt
> new file mode 100644
> index 0000000..d286aea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/btwilink.txt
> @@ -0,0 +1,15 @@
> +btwilink
> +--------
> +
> +Required properties:
> +
> +	- compatible : must be "ti,btwilink"
> +
> +Example:
> +
> +Enable the btwilink driver to bind the bluetooth hci0 interface with
> +ti-st shared transport driver
> +
> +btwilink {
> +	compatible = "ti,btwilink";
> +};

actually I wonder if someone finally starts re-writing the TI-ST driver to integrate with the new Bluetooth subsystem features (like hdev->setup, __hci_cmd_sync and h4_recv_buf) so that this complicated setup is no longer needed.

I do not think we actually would need a shared transport at all. We should have a Bluetooth HCI driver that can have children for FM radio and GPS exposed. Exposing proper platform devices with Bluetooth HCI as parent makes sense. The shared transport is not really a parent. First and foremost, this is a Bluetooth chip. The FM radio and GPS features are just glued on top of it.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reizer, Eyal April 27, 2015, 6:33 a.m. UTC | #2
Hi Marcel,

> -----Original Message-----
> From: Marcel Holtmann [mailto:marcel@holtmann.org]
> Sent: Monday, April 27, 2015 7:32 AM
> To: Gigi Joseph
> Cc: devicetree@vger.kernel.org; Rob Herring; Pawel Moll; Mark Rutland; Ian
> Campbell; Kumar Gala; linux-kernel@vger.kernel.org; Gigi, Joseph
> Subject: Re: [PATCH 1/1] Documentation: Add dt-binding for TI-btwilink driver
> 
> Hi Gigi,
> 
> > btwilink binds bluetooth hci0 interface with the shared transport
> > driver
> >
> > Signed-off-by: Gigi Joseph <gigi.joseph@ti.com>
> > ---
> > Documentation/devicetree/bindings/btwilink.txt | 15 +++++++++++++++
> > 1 file changed, 15 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/btwilink.txt
> >
> > diff --git a/Documentation/devicetree/bindings/btwilink.txt
> > b/Documentation/devicetree/bindings/btwilink.txt
> > new file mode 100644
> > index 0000000..d286aea
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/btwilink.txt
> > @@ -0,0 +1,15 @@
> > +btwilink
> > +--------
> > +
> > +Required properties:
> > +
> > +	- compatible : must be "ti,btwilink"
> > +
> > +Example:
> > +
> > +Enable the btwilink driver to bind the bluetooth hci0 interface with
> > +ti-st shared transport driver
> > +
> > +btwilink {
> > +	compatible = "ti,btwilink";
> > +};
> 
> actually I wonder if someone finally starts re-writing the TI-ST driver to
> integrate with the new Bluetooth subsystem features (like hdev->setup,
> __hci_cmd_sync and h4_recv_buf) so that this complicated setup is no longer
> needed.
> 
> I do not think we actually would need a shared transport at all. We should
> have a Bluetooth HCI driver that can have children for FM radio and GPS
> exposed. Exposing proper platform devices with Bluetooth HCI as parent
> makes sense. The shared transport is not really a parent. First and foremost,
> this is a Bluetooth chip. The FM radio and GPS features are just glued on top of
> it.
> 

Thank you for your suggestion!
One clarification: Wilink8 is not a Bluetooth chip.
It is a combo device that includes wlan subsystem (connected over sdio) and bluetooth+gps connected using a single physical uart.
The shared transport abstracts this single uart to look like two separated devices to the system.
It was written in the past and is being used today by all the wilink family based products.
My suggestion is to take a two steps approach here:

1. For the short term we need it updated in upstream (right now it is broken since 3.8 as it is lacking support for device tree) and all customers need to patch it manually.
2. Once we have it updated we can look into switching from using shared transport to the mechanism you describe above. 
    We would need to study it and make sure it can fully replace the shared transport driver.

Best Regards,
Eyal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/btwilink.txt b/Documentation/devicetree/bindings/btwilink.txt
new file mode 100644
index 0000000..d286aea
--- /dev/null
+++ b/Documentation/devicetree/bindings/btwilink.txt
@@ -0,0 +1,15 @@ 
+btwilink
+--------
+
+Required properties:
+
+	- compatible : must be "ti,btwilink"
+
+Example:
+
+Enable the btwilink driver to bind the bluetooth hci0 interface with
+ti-st shared transport driver
+
+btwilink {
+	compatible = "ti,btwilink";
+};