From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: BCM2048 bluetooth connected over OMAP serial
Date: Wed, 10 Dec 2014 21:56:22 +0100 [thread overview]
Message-ID: <20141210205622.GA25286@amd> (raw)
In-Reply-To: <20141210184203.GA28150@leverpostej>
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
next prev parent reply other threads:[~2014-12-10 20:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 16:43 BCM2048 bluetooth connected over OMAP serial Pavel Machek
2014-12-10 17:02 ` Arnd Bergmann
2014-12-10 18:42 ` Mark Rutland
2014-12-10 20:56 ` Pavel Machek [this message]
2014-12-10 22:50 ` sre@debian.org
2014-12-11 22:10 ` Belisko Marek
2014-12-10 17:35 ` Rob Herring
2014-12-10 17:42 ` Marcel Holtmann
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=20141210205622.GA25286@amd \
--to=pavel@ucw.cz \
--cc=linux-arm-kernel@lists.infradead.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox