[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0551C926975A174EA8972327741C7889EE6B1490@RS-MBS01.realsil.com.cn>
Date: Mon, 4 Mar 2019 05:17:45 +0000
From: 陆朱伟 <alex_lu@...lsil.com.cn>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
CC: "anarsoul@...il.com" <anarsoul@...il.com>,
"beagleboard@...idjohnsummers.uk" <beagleboard@...idjohnsummers.uk>,
"davem@...emloft.net" <davem@...emloft.net>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"johan.hedberg@...il.com" <johan.hedberg@...il.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
"marcel@...tmann.org" <marcel@...tmann.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"maxime.ripard@...tlin.com" <maxime.ripard@...tlin.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"robh@...nel.org" <robh@...nel.org>,
"stefan.wahren@...e.com" <stefan.wahren@...e.com>,
"wens@...e.org" <wens@...e.org>
Subject: 答复: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
Hi Martin,
You're right about the config blob.
Thanks for your invitation to the discussion.
In my option, specifying the properties of the connection to the chip would be better.
Thanks,
BRs,
Alex Lu.
-----邮件原件-----
发件人: Martin Blumenstingl [mailto:martin.blumenstingl@...glemail.com]
发送时间: 2019年3月3日 0:44
收件人: 陆朱伟
抄送: anarsoul@...il.com; beagleboard@...idjohnsummers.uk; davem@...emloft.net; devicetree@...r.kernel.org; johan.hedberg@...il.com; linux-arm-kernel@...ts.infradead.org; linux-bluetooth@...r.kernel.org; marcel@...tmann.org; mark.rutland@....com; maxime.ripard@...tlin.com; netdev@...r.kernel.org; robh@...nel.org; stefan.wahren@...e.com; wens@...e.org
主题: Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
Hi Alex,
On Sat, Mar 2, 2019 at 10:30 AM 陆朱伟 <alex_lu@...lsil.com.cn> wrote:
>
> Hi Martin,
> Thanks for your information.
thank you for the quick reply!
> The config is related to eFuse in chips. I'm sorry that the details can't be open.
> Only some special configurations are related to the host platforms, such as UART working baudrate, hardware flow control, PCM settings, etc. These are the settings for HCI UART and PCM Interface.
> Most of configurations are only relevant to chips.
please let me repeat this with my own words to see if I understand the
"config blob" correctly. Feel free to correct me if anything is wrong:
- the data in the config blob "patches" eFuse values at runtime (non-persistent)
- we know the offsets of the UART_CONFIG, PCM_SETTING and BD_ADDR -
these can be "board specific" (like baud rate, flow control, ...)
- most other values from the "config blob" are "chip specific" -
meaning they are identical for each board and they only depend on the
chip
do you have any suggestions how we can support multiple boards (the
main goal of this whole discussion is: how to do this "correct")?
so far different approaches were discussed (not only in this thread,
but also in the past):
- use a separate config blob for each board. this means that whenever
a new board is supported (for example by adding a .dts for it to the
mainline kernel) then Bluetooth won't work out-of-the-box unless a
config is provided.
- specify the properties of the connection to the chip (for example by
adding a device-tree property for the speed, flow control, ...) and
generate the config based on the device-tree properties.
- (I am open for other suggestions, please let us know if you have any)
I would like to hear your opinion on this topic and especially the
reasons behind your suggestions.
Best regards
Martin
------Please consider the environment before printing this e-mail.
Powered by blists - more mailing lists