On Tue, Aug 16, 2016 at 6:28 PM, Sebastian Reichel [off-list ref] wrote:

Hi Rob,

On Tue, Aug 16, 2016 at 08:51:55AM -0500, Rob Herring wrote:

quoted

On Sat, Aug 13, 2016 at 05:14:34AM +0200, Sebastian Reichel wrote:

quoted

---
 .../devicetree/bindings/net/nokia-bluetooth.txt    | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/nokia-bluetooth.txt

diff --git a/Documentation/devicetree/bindings/net/nokia-bluetooth.txt b/Documentation/devicetree/bindings/net/nokia-bluetooth.txt
new file mode 100644
index 000000000000..a0fceabb4cce
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nokia-bluetooth.txt

@@ -0,0 +1,43 @@
+Nokia bluetooth UART devices
+------
+
+Some vendors have custom versions of their chips, that can be found in Nokia
+devices. These chips are controlled differently, than the non-Nokia version,
+so a different binding is required. All chips listed here implement the Nokia
+H4+ protocol.
+
+Required properties:
+
+  - compatible: should be one of the following:
+   * "nokia,brcm,bcm2048"
+   * "nokia,ti,wl1271-bluetooth"

Perhaps these should be 2 separate strings. Something like
'"nokia,n900-bt", "brcm,bcm2048"'. However, if they are in no way
compatible with the default version from the vendors, then just a single
string is fine, but it doesn't need to be aligned to the vendor
compatible string. So just "nokia,n900-bcm2048" or similar is fine.

The default bcm2048 variant uses different initialization process
and does not use word alignment as far as I know. I think having
"brcm,bcm2048" in the compatible string is wrong.

Okay.

I guess "brcm,bcm2048-nokia" would also be an option, since the
chip has been built buy broadcom, but it has a custom Nokia
interface.

That would be okay. Though, in theory Nokia could have different
products with bcm2048 all with different versions.

I was going with defining it as a board level compatible string. Even
if chips are the same, s/w can need to know board level differences so
using the board vendor and name are common.

quoted

quoted

+  - reset-gpios:           Should specify the gpio for bluetooth reset
+  - host-wakeup-gpios:             Should specify the gpio for host wakeup

Should be interrupt instead?

Yes this is mostly an interrupt, but I need to read the current
line state.

When? If the interrupt is level triggered, then you can get the line
state based on whether you get an interrupt or not. If this needs to
be a wakeup source (see the wakeup source binding), then it needs to
be an interrupt.

Reading the line state is a common problem. It would be nice if the
irq API provided a function to read the line state though that is not
always possible.

quoted

quoted

+  - bluetooth-wakeup-gpios:        Should specify the gpio for bluetooth wakeup

State direction and active state for gpios.

ok.

quoted

quoted

+  - clock-names:           Should be "sysclk"
+  - clocks:                        Should contain a clock phandle for system clock
+
+Example:
+
+/ {
+   /* controlled (enabled/disabled) directly by wl1271 */
+   vctcxo: vctcxo {
+           compatible = "fixed-clock";
+           #clock-cells = <0>;
+           clock-frequency = <38400000>;
+   };
+};
+
+&uart2 {

I want to see a common serial device binding doc before accepting any
device bindings. It's not going to say much initially other than devices
are child nodes of uarts. Perhaps something on baudrate settings.

Neil added a short sentence about this in "[RFC 2/7] tty: add
support for "tty slave" devices". I just took the unmodified patch
from Neil (*), so it's not in its own patch.

But that is in the 8250 binding. It needs to be a common binding.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html