[PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
Sean Wang
sean.wang at mediatek.com
Fri Apr 27 02:14:28 PDT 2018
On Fri, 2018-04-27 at 07:25 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>>>> This adds a driver for the MediaTek serial protocol based on H4 protocol,
> >>>>> which can enable the built-in Bluetooth device inside MT7622 SoC.
> >>>>>
> >>>>> Signed-off-by: Sean Wang <sean.wang at mediatek.com>
> >>>>> ---
> >
[... snip ...]
> >
> > where could I find the newest btuart.c (which seems cannot be found in
> > 4.17 rc2)? It seems a time to rewrite the driver based on btuart.c
>
> It is not merged yet. I posted RFC patches to the mailing list.
>
got it.
> >
> > the Bluetooth device can't survive in a power/down cycle and
> >
> > * power on should be including
> > - enable clk and power domain
> > - download firmware through specific ACL command
> > - send specific commands to configure bluetooth (Required to note that
> > the steps should be after downloading firmware because the behavior for
> > the command might be changed by the firmware)
>
> Then this sounds like you need a quirk that runs setup() after every open() and not just after the first open(). You would be the first hardware that looses their firmware, but that is fine, I almost expect that at some point someone comes along and requires this. So just create a new HCI_QUIRK_NON_PERSISTENT_SETUP.
>
Yes, it should be good to have an option HCI_QUIRK_NON_PERSISTENT_SETUP
to allow us to run setup() for every open().
When users are feeling unexpected thing happening on its device, they
always have a habit trying to restart device from UI.
If close() -> open() can completely power reset a bluetooth device and
then it can recover from any fatal error to the initial state as at
boot. It's good for these problems specially hard to be reproduced and
required to reboot the whole machine to save.
However, it would take a little longer time on open() since it takes
extra time to make firmware download and reconfiguration.
> > * power off should be including
> > - send specific commands, such as to disable bluetooth
>
> So try to put these in shutdown()
>
got it.
> > - disable power domain and clk
>
> And do this in close().
>
got it.
> >
> >>>
> >>>>> +
> >>>>> + return err;
[ ... snip ....]
> .open = mtk_open,
> >>
>
> Go with a brand new btmtkuart.c driver. I really sounds you don’t want the hci_ldisc.c framework in your way. You want direct control over the core callbacks.
>
1)
In fact. the device is working via a internal serial bus, rather than
via uart for mt7622. so could i call it btmtkserial.c ?
Becasue mediatek indeed also have bluetooth over uart, if i called it
btmtkserialc, the same code logic I think can be fit to all other
devices using either uart or internal serial bus.
2)
Yes, i don't want hci_ldisc. so far i thought serdev version is enough,
and i preferred that bluetotoh device don't depend on any utility on
user space to launch.
3)
last question
if i have bluetooth over usb, the usb version bluetooth can reuse
btmtkserial.c code?
> Regards
>
> Marcel
>
More information about the Linux-mediatek
mailing list