From: "Andreas Färber" <afaerber@suse.de> To: aleksandr.aleksandrov@emlid.com, Maxime Ripard <maxime.ripard@bootlin.com>, Rob Herring <robh+dt@kernel.org> Cc: "Mark Rutland" <mark.rutland@arm.com>, "Chen-Yu Tsai" <wens@csie.org>, "David Lechner" <david@lechnology.com>, "Thierry Reding" <treding@nvidia.com>, "Noralf Trønnes" <noralf@tronnes.org>, "Johan Hovold" <johan@kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v3] arm64: new board - Emlid Neutis N5 Date: Thu, 11 Oct 2018 15:20:11 +0200 [thread overview] Message-ID: <2d09d6c0-0404-589d-2c34-da846cff4fb8@suse.de> (raw) In-Reply-To: <9398571539259289@myt4-929fb874f3f2.qloud-c.yandex.net> Hi Aleksandr, Please keep your replies in text-only format, not HTML. Am 11.10.18 um 14:01 schrieb aleksandr.aleksandrov@emlid.com: >> +/ { >> + model = "Emlid Neutis N5 Developer board"; >> + compatible = "emlid,emlid-neutis-n5-devboard", >> + "emlid,emlid-neutis-n5", >> >> Do you need the two emlid there? What comes before the comma is the >> vendor, while what is after is the model. > > I think emlid-neutis-n5 module could be useful in the future, no need > this now. You misunderstand: The point would be to use, e.g., "emlid,neutis-n5" instead of "emlid,emlid-neutis-n5" with duplicate "emlid,emlid-". It is orthogonal to having multiple compatible strings. >> +&uart1 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; >> + status = "okay"; >> +}; >> >> I guess this is for bluetooth? Have you tested serdev drivers? >> > Yes, bluetooth is connected over uart1. > You mean if I have tested bluetooth stack via serial device? Not quite, we're missing a child node within uart1 for a serdev driver. Is there no such driver yet for your Bluetooth chipset, or did you not yet check? > Bluez works stably with bcm43xx over uart 1500000 baud rate. > >> >> Also, I have a general comments, and it really depends on what your >> intention about the board ecosystem is. Do you expect the SOM to be >> swappable in multiple boards, or do you expect to send it as something >> that is just fixed into a daughter board? >> >> In the former case, you probably want to use overlays instead. In the >> latter, you're fine. >> > Right, we expect the SoM to be swappable. I agree, to use overlays is > more convenient, but > the devboard DT file will be a reference for the overlays and the future > boards based on Neutis. What about just keeping the common nodes enabled in a SoM .dts, so that the average board doesn't need an Overlay for booting? @Maxime/Rob, is it possible to merge .dtso files these days? If not, could that be considered in the big dts Makefile refactoring? :) Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
WARNING: multiple messages have this Message-ID (diff)
From: afaerber@suse.de (Andreas Färber) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3] arm64: new board - Emlid Neutis N5 Date: Thu, 11 Oct 2018 15:20:11 +0200 [thread overview] Message-ID: <2d09d6c0-0404-589d-2c34-da846cff4fb8@suse.de> (raw) In-Reply-To: <9398571539259289@myt4-929fb874f3f2.qloud-c.yandex.net> Hi Aleksandr, Please keep your replies in text-only format, not HTML. Am 11.10.18 um 14:01 schrieb aleksandr.aleksandrov at emlid.com: >> ?+/ { >> ?+ model = "Emlid Neutis N5 Developer board"; >> ?+ compatible = "emlid,emlid-neutis-n5-devboard", >> ?+ "emlid,emlid-neutis-n5", >> >> Do you need the two emlid there? What comes before the comma is the >> vendor, while what is after is the model. > ? > I think emlid-neutis-n5 module could be useful in the future, no need > this now. You misunderstand: The point would be to use, e.g., "emlid,neutis-n5" instead of "emlid,emlid-neutis-n5" with duplicate "emlid,emlid-". It is orthogonal to having multiple compatible strings. >> ?+&uart1 { >> ?+ pinctrl-names = "default"; >> ?+ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; >> ?+ status = "okay"; >> ?+}; >> >> I guess this is for bluetooth? Have you tested serdev drivers? >> > Yes, bluetooth is connected over uart1. > You mean if I have tested bluetooth stack via serial device? Not quite, we're missing a child node within uart1 for a serdev driver. Is there no such driver yet for your Bluetooth chipset, or did you not yet check? > Bluez works stably with bcm43xx over uart 1500000 baud rate. > ? >> >> Also, I have a general comments, and it really depends on what your >> intention about the board ecosystem is. Do you expect the SOM to be >> swappable in multiple boards, or do you expect to send it as something >> that is just fixed into a daughter board? >> >> In the former case, you probably want to use overlays instead. In the >> latter, you're fine. >> > Right, we expect the SoM to be swappable. I agree, to use overlays is > more convenient, but > the devboard DT file will be a reference for the overlays and the future > boards based on Neutis. What about just keeping the common nodes enabled in a SoM .dts, so that the average board doesn't need an Overlay for booting? @Maxime/Rob, is it possible to merge .dtso files these days? If not, could that be considered in the big dts Makefile refactoring? :) Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg)
next prev parent reply other threads:[~2018-10-11 13:20 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-05 13:25 [PATCH v3] Neutis N5 support Aleksandr Aleksandrov 2018-10-05 13:25 ` [PATCH v3] arm64: new board - Emlid Neutis N5 Aleksandr Aleksandrov 2018-10-05 14:48 ` Maxime Ripard 2018-10-08 15:20 ` [PATCH v3] Neutis N5 support Aleksandr Aleksandrov 2018-10-08 15:20 ` Aleksandr Aleksandrov 2018-10-08 15:20 ` Aleksandr Aleksandrov 2018-10-08 15:20 ` [PATCH v3] arm64: new board - Emlid Neutis N5 Aleksandr Aleksandrov 2018-10-08 15:20 ` Aleksandr Aleksandrov 2018-10-08 15:20 ` Aleksandr Aleksandrov 2018-10-10 14:49 ` Maxime Ripard 2018-10-10 14:49 ` Maxime Ripard 2018-10-11 12:01 ` aleksandr.aleksandrov 2018-10-11 13:20 ` Andreas Färber [this message] 2018-10-11 13:20 ` Andreas Färber 2018-10-11 16:40 ` Maxime Ripard 2018-10-11 16:40 ` Maxime Ripard 2018-10-12 9:35 ` Aleksandr Aleksandrov 2018-10-12 9:35 ` Aleksandr Aleksandrov 2018-10-12 9:57 ` Maxime Ripard 2018-10-12 9:57 ` Maxime Ripard 2018-10-12 10:23 ` [PATCH v4 0/2] Neutis N5 support Aleksandr Aleksandrov 2018-10-12 10:23 ` Aleksandr Aleksandrov 2018-10-12 10:23 ` Aleksandr Aleksandrov 2018-10-12 10:23 ` [PATCH v4 1/2] arm64: dts: allwinner: new board - Emlid Neutis N5 Aleksandr Aleksandrov 2018-10-12 10:23 ` Aleksandr Aleksandrov 2018-10-12 10:23 ` Aleksandr Aleksandrov 2018-10-12 12:19 ` Andreas Färber 2018-10-12 12:19 ` Andreas Färber 2018-10-12 13:39 ` Aleksandr Aleksandrov 2018-10-12 13:39 ` Aleksandr Aleksandrov 2018-10-12 20:23 ` Maxime Ripard 2018-10-12 20:23 ` Maxime Ripard 2018-10-13 2:26 ` Chen-Yu Tsai 2018-10-13 2:26 ` Chen-Yu Tsai 2018-10-15 11:49 ` [PATCH v5 0/2] Neutis N5 support Aleksandr Aleksandrov 2018-10-15 11:49 ` Aleksandr Aleksandrov 2018-10-15 11:49 ` Aleksandr Aleksandrov 2018-10-15 11:49 ` [PATCH v5 1/2] dt-bindings: vendor-prefix: new vendor - Emlid Aleksandr Aleksandrov 2018-10-15 11:49 ` Aleksandr Aleksandrov 2018-10-15 11:49 ` Aleksandr Aleksandrov 2018-10-15 11:49 ` [PATCH v5 2/2] arm64: dts: allwinner: new board - Emlid Neutis N5 Aleksandr Aleksandrov 2018-10-15 11:49 ` Aleksandr Aleksandrov 2018-10-15 11:49 ` Aleksandr Aleksandrov 2018-10-16 7:21 ` [PATCH v5 0/2] Neutis N5 support Maxime Ripard 2018-10-16 7:21 ` Maxime Ripard 2018-10-12 10:23 ` [PATCH v4 2/2] doc: devicetree: vendor-prefixes: new vendor - Emlid Aleksandr Aleksandrov 2018-10-12 10:23 ` Aleksandr Aleksandrov 2018-10-12 10:23 ` Aleksandr Aleksandrov 2018-10-12 11:39 ` Rob Herring 2018-10-12 11:39 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2d09d6c0-0404-589d-2c34-da846cff4fb8@suse.de \ --to=afaerber@suse.de \ --cc=aleksandr.aleksandrov@emlid.com \ --cc=david@lechnology.com \ --cc=devicetree@vger.kernel.org \ --cc=johan@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maxime.ripard@bootlin.com \ --cc=noralf@tronnes.org \ --cc=robh+dt@kernel.org \ --cc=treding@nvidia.com \ --cc=wens@csie.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.