From: Lukas Wunner <lukas@wunner.de>
To: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Cc: Rob Herring <robh@kernel.org>, Peter Rosin <peda@axentia.se>,
Johan Hovold <johan@kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Frederic Danis <frederic.danis.oss@gmail.com>,
Loic Poulain <loic.poulain@linaro.org>,
Hans de Goede <hdegoede@redhat.com>, Max Shavrick <mxms@me.com>,
Leif Liddy <leif.liddy@gmail.com>,
Daniel Roschka <danielroschka@phoenitydawn.de>,
Ronald Tschalaer <ronald@innovation.ch>,
"Peter Y. Chuang" <peteryuchuang@gmail.com>,
linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH 1/3] Bluetooth: hci_bcm: Support Apple GPIO handling
Date: Tue, 26 Dec 2017 18:08:15 +0100 [thread overview]
Message-ID: <20171226170815.GA31975@wunner.de> (raw)
In-Reply-To: <5e3106d673c3c41bf92c91f1f43bf30682511366.1514143015.git.lukas@wunner.de>
Hi Ulrich,
On Tue, Dec 26, 2017 at 05:07:34PM +0200, Lukas Wunner wrote:
> On the MacBook8,1 Bluetooth is muxed with a second device (a debug port
> on the SSD) under the control of PCH GPIO 36. Because serdev cannot
> deal with multiple slaves yet, it is currently necessary to patch the
> DSDT and remove the SSDC device.
Last August you posted a series to add multiplexer support for serdev:
https://www.spinics.net/lists/linux-serial/msg27329.html
Another use case has now popped up where a GPIO-controlled mux is used
to switch between two serdev slaves: As mentioned in a series I've just
posted to linux-bluetooth@ (quoted above), on the MacBook 8,1 the UART
is attached to a serial debug port on the SSD as well as to a Bluetooth
controller, subject to a mux controlled by PCH GPIO 36.
The SSD debug ported is listed first in the ACPI namespace and is attached
as a serdev slave without a hitch (see DSDT excerpt included below).
The Bluetooth controller comes next and fails to register due to a sanity
check in serdev_device_add():
[ 0.361650] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.362633] 0000:00:15.5: ttyS0 at MMIO 0xc1819000 (irq = 21, base_baud = 2764800) is a 16550A
[ 0.362769] serial serial0-0: controller busy
[ 0.362815] serial serial0-0: failure adding ACPI serdev device. status -16
[ 0.362860] serial serial0: tty port ttyS0 registered
The series you've posted in August hasn't been merged. Taking a closer
look at patch [2/6] (linked above), you've put the calls to lock and
unlock the mux in the slave, i.e. max9260.c. This works because in your
use case, the UART is shared only by MAX9260 chips. I think a more
generic solution is called for which puts the locking of the mux in the
serdev controller and makes it fully transparent to the slaves.
So whenever data is read or written to the UART's FIFO or whenever
the modem control lines are accessed, the mux needs to be locked to
the respective slave first.
The sanity check introduced by 08fcee289f34 to prevent registration
of multiple serdev slaves needs to be amended to check for presence
of a mux if more than one slave registers, and check whether the
number of switch states is sufficient to accomodate the additional
slave.
If you do find the time to amend the series in this way, it would
result in something truly useful that we could also employ to solve
Bluetooth muxing on the MacBook8,1 in a clean way.
Thanks,
Lukas
-- cut here --
Device (URT0)
{
Name (_ADR, 0x00150005) // _ADR: Address
Name (RBUF, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
{
0x00000015,
}
})
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
{
Store (Package (0x02)
{
"uart-channel-number",
Buffer (0x08)
{
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
Return (0x00)
}
Name (DBUF, ResourceTemplate ()
{
FixedDMA (0x0014, 0x0004, Width32bit, )
FixedDMA (0x0015, 0x0005, Width32bit, )
})
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Return (ConcatenateResTemplate (RBUF, DBUF))
}
}
Scope (\_SB.PCI0.URT0)
{
Device (SSDC)
{
Name (_CID, "apple-uart-ssdc") // _CID: Compatible ID
Name (_UID, 0x01) // _UID: Unique ID
Name (_ADR, 0x00) // _ADR: Address
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
{
Store (Package (0x08)
{
"baud",
Buffer (0x08)
{
0xD0, 0x12, 0x13, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */
},
"parity",
Buffer (0x08)
{
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */
},
"dataBits",
Buffer (0x08)
{
0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */
},
"stopBits",
Buffer (0x08)
{
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
Return (0x00)
}
}
}
Scope (\_SB.PCI0.URT0)
{
Device (BLTH)
{
Name (_HID, EisaId ("BCM2E7C")) // _HID: Hardware ID
Name (_CID, "apple-uart-blth") // _CID: Compatible ID
Name (_UID, 0x01) // _UID: Unique ID
Name (_ADR, 0x00) // _ADR: Address
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (UBUF, ResourceTemplate ()
{
UartSerialBus (0x0001C200, DataBitsEight, StopBitsOne,
0xC0, LittleEndian, ParityTypeNone, FlowControlHardware,
0x0020, 0x0020, "\\_SB.PCI0.URT0",
0x00, ResourceProducer, ,
)
})
Name (ABUF, ResourceTemplate ()
{
})
If (LNot (OSDW ()))
{
Return (UBUF) /* \_SB_.PCI0.URT0.BLTH._CRS.UBUF */
}
Return (ABUF) /* \_SB_.PCI0.URT0.BLTH._CRS.ABUF */
}
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
{
Store (Package (0x08)
{
"baud",
Buffer (0x08)
{
0xC0, 0xC6, 0x2D, 0x00, 0x00, 0x00, 0x00, 0x00 /* ..-..... */
},
"parity",
Buffer (0x08)
{
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */
},
"dataBits",
Buffer (0x08)
{
0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */
},
"stopBits",
Buffer (0x08)
{
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
Return (0x00)
}
Method (BTPU, 0, Serialized)
{
Store (0x01, \_SB.PCI0.LPCB.EC.BTPC)
Sleep (0x0A)
}
Method (BTPD, 0, Serialized)
{
Store (0x00, \_SB.PCI0.LPCB.EC.BTPC)
Sleep (0x0A)
}
Method (BTRS, 0, Serialized)
{
BTPD ()
BTPU ()
}
Method (BTLP, 1, Serialized)
{
If (LEqual (Arg0, 0x00))
{
Store (0x01, GD54) /* \GD54 */
}
If (LEqual (Arg0, 0x01))
{
Store (0x00, GD54) /* \GD54 */
Store (0x00, GP54) /* \GP54 */
}
}
}
}
}
next prev parent reply other threads:[~2017-12-26 17:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-26 15:07 [PATCH 1/3] Bluetooth: hci_bcm: Support Apple GPIO handling Lukas Wunner
2017-12-26 15:07 ` [PATCH 2/3] Bluetooth: hci_bcm: Streamline runtime PM code Lukas Wunner
2017-12-26 20:57 ` Marcel Holtmann
2017-12-26 15:07 ` [PATCH 3/3] Bluetooth: Avoid WARN splat due to missing GPIOLIB Lukas Wunner
2017-12-26 20:57 ` Marcel Holtmann
2017-12-28 8:41 ` Andy Shevchenko
2017-12-28 9:18 ` Lukas Wunner
2017-12-28 9:26 ` Andy Shevchenko
2017-12-28 12:29 ` Linus Walleij
2017-12-28 12:40 ` Andy Shevchenko
2017-12-28 12:45 ` Linus Walleij
2017-12-29 9:51 ` Lukas Wunner
2017-12-29 14:18 ` Loic Poulain
2017-12-29 15:12 ` Lukas Wunner
2017-12-29 15:18 ` Andy Shevchenko
2017-12-29 15:28 ` Lukas Wunner
2018-01-01 15:23 ` Linus Walleij
2018-01-02 15:27 ` Marcel Holtmann
2018-01-02 16:58 ` Lukas Wunner
2018-01-02 17:10 ` Marcel Holtmann
2017-12-26 17:08 ` Lukas Wunner [this message]
2017-12-26 20:50 ` [PATCH 1/3] Bluetooth: hci_bcm: Support Apple GPIO handling Marcel Holtmann
2017-12-27 14:17 ` Lukas Wunner
2017-12-28 7:15 ` Lukas Wunner
2017-12-28 12:40 ` Hans de Goede
2017-12-28 7:38 ` Andy Shevchenko
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=20171226170815.GA31975@wunner.de \
--to=lukas@wunner.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=danielroschka@phoenitydawn.de \
--cc=frederic.danis.oss@gmail.com \
--cc=hdegoede@redhat.com \
--cc=johan.hedberg@gmail.com \
--cc=johan@kernel.org \
--cc=leif.liddy@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=loic.poulain@linaro.org \
--cc=marcel@holtmann.org \
--cc=mika.westerberg@linux.intel.com \
--cc=mxms@me.com \
--cc=peda@axentia.se \
--cc=peteryuchuang@gmail.com \
--cc=robh@kernel.org \
--cc=ronald@innovation.ch \
--cc=ulrich.hecht+renesas@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).