[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141210205622.GA25286@amd>
Date: Wed, 10 Dec 2014 21:56:22 +0100
From: Pavel Machek <pavel@....cz>
To: Mark Rutland <mark.rutland@....com>
Cc: Arnd Bergmann <arnd@...db.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"pali.rohar@...il.com" <pali.rohar@...il.com>,
"sre@...ian.org" <sre@...ian.org>, "sre@...g0.de" <sre@...g0.de>,
kernel list <linux-kernel@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"tony@...mide.com" <tony@...mide.com>,
"khilman@...nel.org" <khilman@...nel.org>,
"aaro.koskinen@....fi" <aaro.koskinen@....fi>,
"ivo.g.dimitrov.75@...il.com" <ivo.g.dimitrov.75@...il.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
Pawel Moll <Pawel.Moll@....com>,
"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
"galak@...eaurora.org" <galak@...eaurora.org>
Subject: Re: BCM2048 bluetooth connected over OMAP serial
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.
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists