* [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
From: Paul Kocialkowski @ 2018-06-14 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d5357ae3-9dc1-b0ac-47bf-8742d55c4f3b@micronovasrl.com>
Hi,
On Wed, 2018-06-13 at 23:52 +0200, Giulio Benetti wrote:
> Hello,
>
> sorry for my ignorance.
> I don't know the right patch workflow in the case of "revert commit".
> When I fix this bug, should I have to re-submit the previous patch
> entire plus bug-fix?
>
> Or do I have to submit patch with bug-fix only?
Yes, that is usually how it works! The revert patch will be picked up by
the maintainer (Maxime), integrated in his tree and eventually merged
into Linus' tree (along with stable trees).
Fixup patches for this will need to take into account the revert patch,
so it becomes equivalent to submitting the same patch with that issue
resolved.
> Thanks in advance to everybody
Cheers !
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180614/539bddbd/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
From: Simon Horman @ 2018-06-14 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c78f1228-afb0-54cf-5d9e-5c812b678de3@cogentembedded.com>
On Wed, Jun 13, 2018 at 11:12:40PM +0300, Sergei Shtylyov wrote:
> Define the Condor/V3HSK board dependent parts of the DU and LVDS device
> nodes. Also add the device nodes for Thine THC63LVD1024 LVDS decoder and
> Analog Devices ADV7511W HDMI transmitter...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Changes in version 2:
> - added the V3HSK DT update, reworded the description, renamed the patch;
> - added a space between the HDMI node name and a brace.
>
> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 +++++++++++++++++++++
> arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 120 ++++++++++++++++++++++++
Laurent, could you review this?
> 2 files changed, 226 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> ===================================================================
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> @@ -45,6 +45,56 @@
> regulator-boot-on;
> regulator-always-on;
> };
> +
> + d1_8v: regulator-2 {
> + compatible = "regulator-fixed";
> + regulator-name = "D1.8V";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con: endpoint {
> + remote-endpoint = <&adv7511_out>;
> + };
> + };
> + };
> +
> + lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> + vcc-supply = <&d3_3v>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + thc63lvd1024_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> +
> + port at 2 {
> + reg = <2>;
> + thc63lvd1024_out: endpoint {
> + remote-endpoint = <&adv7511_in>;
> + };
> + };
> + };
> + };
> +
> + x1_clk: x1-clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <148500000>;
> + };
> };
>
> &avb {
> @@ -74,6 +124,13 @@
> };
> };
>
> +&du {
> + clocks = <&cpg CPG_MOD 724>,
> + <&x1_clk>;
> + clock-names = "du.0", "dclkin.0";
> + status = "okay";
> +};
> +
> &extal_clk {
> clock-frequency = <16666666>;
> };
> @@ -102,6 +159,55 @@
> gpio-controller;
> #gpio-cells = <2>;
> };
> +
> + hdmi at 39 {
> + compatible = "adi,adv7511w";
> + reg = <0x39>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> + avdd-supply = <&d1_8v>;
> + dvdd-supply = <&d1_8v>;
> + pvdd-supply = <&d1_8v>;
> + bgvdd-supply = <&d1_8v>;
> + dvdd-3v-supply = <&d3_3v>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "rgb";
> + adi,input-clock = "1x";
> + adi,input-style = <1>;
> + adi,input-justification = "evenly";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7511_in: endpoint {
> + remote-endpoint = <&thc63lvd1024_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_con>;
> + };
> + };
> + };
> + };
> +};
> +
> +&lvds0 {
> + status = "okay";
> +
> + ports {
> + port at 1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <&thc63lvd1024_in>;
> + };
> + };
> + };
> };
>
> &mmc0 {
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> ===================================================================
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> @@ -27,6 +27,63 @@
> /* first 128MB is reserved for secure area. */
> reg = <0 0x48000000 0 0x78000000>;
> };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con: endpoint {
> + remote-endpoint = <&adv7511_out>;
> + };
> + };
> + };
> +
> + lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> + vcc-supply = <&vcc3v3_d5>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + thc63lvd1024_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> +
> + port at 2 {
> + reg = <2>;
> + thc63lvd1024_out: endpoint {
> + remote-endpoint = <&adv7511_in>;
> + };
> + };
> + };
> + };
> +
> + vcc1v8_d4: regulator-0 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC1V8_D4";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vcc3v3_d5: regulator-1 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC3V3_D5";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +};
> +
> +&du {
> + status = "okay";
> };
>
> &extal_clk {
> @@ -53,6 +110,64 @@
> };
> };
>
> +&lvds0 {
> + status = "okay";
> +
> + ports {
> + port at 1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <&thc63lvd1024_in>;
> + };
> + };
> + };
> +};
> +
> +&i2c0 {
> + pinctrl-0 = <&i2c0_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> + clock-frequency = <400000>;
> +
> + hdmi at 39 {
> + compatible = "adi,adv7511w";
> + #sound-dai-cells = <0>;
> + reg = <0x39>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> + avdd-supply = <&vcc1v8_d4>;
> + dvdd-supply = <&vcc1v8_d4>;
> + pvdd-supply = <&vcc1v8_d4>;
> + bgvdd-supply = <&vcc1v8_d4>;
> + dvdd-3v-supply = <&vcc3v3_d5>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "rgb";
> + adi,input-clock = "1x";
> + adi,input-style = <1>;
> + adi,input-justification = "evenly";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7511_in: endpoint {
> + remote-endpoint = <&thc63lvd1024_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_con>;
> + };
> + };
> + };
> + };
> +};
> +
> &pfc {
> gether_pins: gether {
> groups = "gether_mdio_a", "gether_rgmii",
> @@ -60,6 +175,11 @@
> function = "gether";
> };
>
> + i2c0_pins: i2c0 {
> + groups = "i2c0";
> + function = "i2c0";
> + };
> +
> scif0_pins: scif0 {
> groups = "scif0_data";
> function = "scif0";
>
^ permalink raw reply
* [PATCH v3 1/2] arm64: dts: renesas: r8a77980: add FCPVD/VSPD/DU/LVDS support
From: Simon Horman @ 2018-06-14 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1611fe94-07dd-fc8b-e94f-143e1ed26a17@cogentembedded.com>
On Wed, Jun 13, 2018 at 11:11:27PM +0300, Sergei Shtylyov wrote:
> Describe the interconnected FCPVD0, VSPD0, DU, and LVDS0 devices in the
> R8A77980 device tree...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> ---
> Changes in version 3:
> - merged in the VSPD/DU/LVDS patches, renamed the patch, and updated the patch
> description accordingly;
> - fixed the VSPD0's "reg" property.
Thanks Sergei, applied.
^ permalink raw reply
* [PATCH v2] arm64: dts: renesas: condor/v3hsk: specify Ethernet PHY IRQs
From: Simon Horman @ 2018-06-14 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d6f18ad-47d1-eb81-1a86-d124ca03e1c9@cogentembedded.com>
On Wed, Jun 13, 2018 at 07:44:02PM +0300, Sergei Shtylyov wrote:
> On 06/13/2018 07:42 PM, Sergei Shtylyov wrote:
>
> > Specify Ethernet PHY IRQs in the Condor/V3HSK board device trees, now that
> > we have the GPIO support (previously phylib had to resort to polling).
> >
> > Based on the original (and large) patch by Vladimir Barinov.
> >
> > Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >
> > ---
>
> Forgot to add the the patch is against the 'renesas-devel-20180613-v4.17' tag.
>
Thanks Sergei, applied.
^ permalink raw reply
* [RFC PATCH] sdhci-of-arasan: card initialization failure -84
From: Adrian Hunter @ 2018-06-14 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604064211.q2thyftgpffuaer2@laureti-dev>
And again without mangling Atul's email address.
On 04/06/18 09:42, Helmut Grohne wrote:
> Work around repeated:
>
> mmc0: error -84 whilst initialising SD card
> ---
> drivers/mmc/host/sdhci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> I'm seeing the above error -84 with a series of Kingston cards of 4GB capacity
> when used with an arasan host controller. Using the cards with other hosts or
> using other cards with the host is not problematic. The host controller has the
> following device tree:
>
> ps7-sdio at e0100000 {
> compatible = "arasan,sdhci-8.9a";
> reg = <0xe0100000 0x1000>;
> clock-names = "clk_xin", "clk_ahb";
> clock-frequency = <50000000>;
> clocks = <&clkc 21>, <&clkc 32>;
> interrupt-parent = <&ps7_scugic_0>;
> interrupts = <0 24 4>;
> };
>
> When enabling sufficient debugging (and thus slowing the kernel down), the
> problem goes away. Without debug features, the insertion of this delay suffices
> for my particular instance. Inserting the same delay before the
> SDHCI_CLOCK_CARD_EN write also makes the error go away.
>
> While instrumenting the code I found that the loop waiting for the
> SDHCI_CLOCK_INT_STABLE would always terminate immediately (regardless of the
> card being used). Only when the card is removed, the loop would spin once. This
> hints that potentially the stable checking is broken for this host controller.
>
> During my testing I checked 7 Kingston cards, 2 Transcend Cards, 1 Apacer card,
> 3 arasn hosts, 3 non-arasan hosts and had consistent reports for a similar
> number of devices from others.
>
> If my hypothesis is reasonable, I can turn this patch into a new quirk that
> replaces the stable polling with msleep(20), which is the poll timeout. Is
> there anything else I should investigate before doing so?
Please avoid quirks. Perhaps use the ->set_clock() callback.
>
> Helmut
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 90cc1977b792..5d2809aeb4eb 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1430,6 +1430,7 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 clk)
>
> clk |= SDHCI_CLOCK_CARD_EN;
> sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> + udelay(80);
> }
> EXPORT_SYMBOL_GPL(sdhci_enable_clk);
>
>
^ permalink raw reply
* [RFC PATCH] sdhci-of-arasan: card initialization failure -84
From: Adrian Hunter @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604064211.q2thyftgpffuaer2@laureti-dev>
On 04/06/18 09:42, Helmut Grohne wrote:
> Work around repeated:
>
> mmc0: error -84 whilst initialising SD card
> ---
> drivers/mmc/host/sdhci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> I'm seeing the above error -84 with a series of Kingston cards of 4GB capacity
> when used with an arasan host controller. Using the cards with other hosts or
> using other cards with the host is not problematic. The host controller has the
> following device tree:
>
> ps7-sdio at e0100000 {
> compatible = "arasan,sdhci-8.9a";
> reg = <0xe0100000 0x1000>;
> clock-names = "clk_xin", "clk_ahb";
> clock-frequency = <50000000>;
> clocks = <&clkc 21>, <&clkc 32>;
> interrupt-parent = <&ps7_scugic_0>;
> interrupts = <0 24 4>;
> };
>
> When enabling sufficient debugging (and thus slowing the kernel down), the
> problem goes away. Without debug features, the insertion of this delay suffices
> for my particular instance. Inserting the same delay before the
> SDHCI_CLOCK_CARD_EN write also makes the error go away.
>
> While instrumenting the code I found that the loop waiting for the
> SDHCI_CLOCK_INT_STABLE would always terminate immediately (regardless of the
> card being used). Only when the card is removed, the loop would spin once. This
> hints that potentially the stable checking is broken for this host controller.
>
> During my testing I checked 7 Kingston cards, 2 Transcend Cards, 1 Apacer card,
> 3 arasn hosts, 3 non-arasan hosts and had consistent reports for a similar
> number of devices from others.
>
> If my hypothesis is reasonable, I can turn this patch into a new quirk that
> replaces the stable polling with msleep(20), which is the poll timeout. Is
> there anything else I should investigate before doing so?
Please avoid quirks. Perhaps use the ->set_clock() callback.
>
> Helmut
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 90cc1977b792..5d2809aeb4eb 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1430,6 +1430,7 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 clk)
>
> clk |= SDHCI_CLOCK_CARD_EN;
> sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> + udelay(80);
> }
> EXPORT_SYMBOL_GPL(sdhci_enable_clk);
>
>
^ permalink raw reply
* [PATCH v3 7/7] MAINTAINERS: add an entry for MediaTek Bluetooth driver
From: sean.wang at mediatek.com @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528960095.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Add an entry for the MediaTek Bluetooth driver.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f15bc83..71e25f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8988,6 +8988,14 @@ F: include/uapi/linux/meye.h
F: include/uapi/linux/ivtv*
F: include/uapi/linux/uvcvideo.h
+MEDIATEK BLUETOOTH DRIVER
+M: Sean Wang <sean.wang@mediatek.com>
+L: linux-bluetooth at vger.kernel.org
+L: linux-mediatek at lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
+F: drivers/bluetooth/btmtkuart.c
+
MEDIATEK CIR DRIVER
M: Sean Wang <sean.wang@mediatek.com>
S: Maintained
--
2.7.4
^ permalink raw reply related
* [PATCH v3 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices
From: sean.wang at mediatek.com @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528960095.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This adds a driver to run on the top of btuart driver for the MediaTek
serial protocol based on running H:4, which can enable the built-in
Bluetooth device inside MT7622 SoC.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/bluetooth/Kconfig | 12 ++
drivers/bluetooth/Makefile | 2 +
drivers/bluetooth/btmtkuart.c | 355 ++++++++++++++++++++++++++++++++++++++++++
drivers/bluetooth/btmtkuart.h | 119 ++++++++++++++
drivers/bluetooth/btuart.c | 18 +++
5 files changed, 506 insertions(+)
create mode 100644 drivers/bluetooth/btmtkuart.c
create mode 100644 drivers/bluetooth/btmtkuart.h
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 00fdf5f..1a44afd 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -85,6 +85,18 @@ config BT_HCIBTUART
Say Y here to compile support for Bluetooth UART devices into the
kernel or say M to compile it as module (btuart).
+config BT_HCIBTUART_MTK
+ tristate "MediaTek HCI UART driver"
+ depends on BT_HCIBTUART
+ default y
+ help
+ MediaTek Bluetooth HCI UART driver.
+ This driver is required if you want to use MediaTek Bluetooth
+ with serial interface.
+
+ Say Y here to compile support for MediaTek Bluetooth UART devices
+ into the kernel or say M to compile it as module (btmtkuart).
+
config BT_HCIUART
tristate "HCI UART driver"
depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 60a19cb..c9a8926 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_BT_BCM) += btbcm.o
obj-$(CONFIG_BT_RTL) += btrtl.o
obj-$(CONFIG_BT_QCA) += btqca.o
+obj-$(CONFIG_BT_HCIBTUART_MTK) += btmtkuart.o
+
obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o
obj-$(CONFIG_BT_HCIRSI) += btrsi.o
diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
new file mode 100644
index 0000000..3118f61
--- /dev/null
+++ b/drivers/bluetooth/btmtkuart.c
@@ -0,0 +1,355 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018 MediaTek Inc.
+
+/*
+ * Bluetooth support for MediaTek serial devices
+ *
+ * Author: Sean Wang <sean.wang@mediatek.com>
+ *
+ */
+
+#include <asm/unaligned.h>
+#include <linux/atomic.h>
+#include <linux/clk.h>
+#include <linux/firmware.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/serdev.h>
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "h4_recv.h"
+#include "btuart.h"
+#include "btmtkuart.h"
+
+static void mtk_stp_reset(struct mtk_stp_splitter *sp)
+{
+ sp->cursor = 2;
+ sp->dlen = 0;
+}
+
+static const unsigned char *
+mtk_stp_split(struct btuart_dev *bdev, struct mtk_stp_splitter *sp,
+ const unsigned char *data, int count, int *sz_h4)
+{
+ struct mtk_stp_hdr *shdr;
+
+ /* The cursor is reset when all the data of STP is consumed out. */
+ if (!sp->dlen && sp->cursor >= 6)
+ sp->cursor = 0;
+
+ /* Filling pad until all STP info is obtained. */
+ while (sp->cursor < 6 && count > 0) {
+ sp->pad[sp->cursor] = *data;
+ sp->cursor++;
+ data++;
+ count--;
+ }
+
+ /* Retrieve STP info and have a sanity check. */
+ if (!sp->dlen && sp->cursor >= 6) {
+ shdr = (struct mtk_stp_hdr *)&sp->pad[2];
+ sp->dlen = shdr->dlen1 << 8 | shdr->dlen2;
+
+ /* Resync STP when unexpected data is being read. */
+ if (shdr->prefix != 0x80 || sp->dlen > 2048) {
+ bt_dev_err(bdev->hdev, "stp format unexpect (%d, %d)",
+ shdr->prefix, sp->dlen);
+ mtk_stp_reset(sp);
+ }
+ }
+
+ /* Directly quit when there's no data found for H4 can process. */
+ if (count <= 0)
+ return NULL;
+
+ /* Tranlate to how much the size of data H4 can handle so far. */
+ *sz_h4 = min_t(int, count, sp->dlen);
+ /* Update the remaining size of STP packet. */
+ sp->dlen -= *sz_h4;
+
+ /* Data points to STP payload which can be handled by H4. */
+ return data;
+}
+
+static int mtk_stp_send(struct btuart_dev *bdev, struct sk_buff *skb)
+{
+ struct mtk_stp_hdr *shdr;
+ struct sk_buff *new_skb;
+ int dlen;
+
+ memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
+ dlen = skb->len;
+
+ /* Make sure of STP header at least has 4-bytes free space to fill. */
+ if (unlikely(skb_headroom(skb) < MTK_STP_HDR_SIZE)) {
+ new_skb = skb_realloc_headroom(skb, MTK_STP_HDR_SIZE);
+ kfree_skb(skb);
+ skb = new_skb;
+ }
+
+ /* Build for STP packet format. */
+ shdr = skb_push(skb, MTK_STP_HDR_SIZE);
+ mtk_make_stp_hdr(shdr, 0, dlen);
+ skb_put_zero(skb, MTK_STP_TLR_SIZE);
+
+ skb_queue_tail(&bdev->txq, skb);
+
+ return 0;
+}
+
+static int mtk_hci_wmt_sync(struct btuart_dev *bdev, u8 opcode, u8 flag,
+ u16 plen, const void *param)
+{
+ struct mtk_hci_wmt_cmd wc;
+ struct mtk_wmt_hdr *hdr;
+ struct sk_buff *skb;
+ u32 hlen;
+
+ hlen = sizeof(*hdr) + plen;
+ if (hlen > 255)
+ return -EINVAL;
+
+ hdr = (struct mtk_wmt_hdr *)&wc;
+ mtk_make_wmt_hdr(hdr, opcode, plen, flag);
+ memcpy(wc.data, param, plen);
+
+ atomic_inc(&bdev->hdev->cmd_cnt);
+
+ skb = __hci_cmd_sync_ev(bdev->hdev, 0xfc6f, hlen, &wc, HCI_VENDOR_PKT,
+ HCI_INIT_TIMEOUT);
+
+ if (IS_ERR(skb)) {
+ int err = PTR_ERR(skb);
+
+ bt_dev_err(bdev->hdev, "Failed to send wmt cmd (%d)\n", err);
+ return err;
+ }
+
+ kfree_skb(skb);
+
+ return 0;
+}
+
+static int mtk_setup_fw(struct btuart_dev *bdev)
+{
+ const struct firmware *fw;
+ struct device *dev;
+ const char *fwname;
+ const u8 *fw_ptr;
+ size_t fw_size;
+ int err, dlen;
+ u8 flag;
+
+ dev = &bdev->serdev->dev;
+ fwname = FIRMWARE_MT7622;
+
+ err = request_firmware(&fw, fwname, dev);
+ if (err < 0) {
+ bt_dev_err(bdev->hdev, "Failed to load firmware file (%d)",
+ err);
+ return err;
+ }
+
+ fw_ptr = fw->data;
+ fw_size = fw->size;
+
+ /* The size of patch header is 30 bytes, should be skip. */
+ if (fw_size < 30)
+ return -EINVAL;
+
+ fw_size -= 30;
+ fw_ptr += 30;
+
+ while (fw_size > 0) {
+ dlen = min_t(int, 250, fw_size);
+
+ /* Tell deivice the position in sequence. */
+ flag = (fw_size - dlen <= 0) ? 3 :
+ (fw_size < fw->size - 30) ? 2 : 1;
+
+ err = mtk_hci_wmt_sync(bdev, MTK_WMT_PATCH_DWNLD, flag, dlen,
+ fw_ptr);
+ if (err < 0)
+ break;
+
+ fw_size -= dlen;
+ fw_ptr += dlen;
+ }
+
+ release_firmware(fw);
+
+ return err;
+}
+
+void *mtk_btuart_init(struct device *dev)
+{
+ struct mtk_bt_dev *soc;
+
+ soc = devm_kzalloc(dev, sizeof(*soc), GFP_KERNEL);
+ if (!soc)
+ return ERR_PTR(-ENOMEM);
+
+ soc->sp = devm_kzalloc(dev, sizeof(*soc->sp), GFP_KERNEL);
+ if (!soc->sp)
+ return ERR_PTR(-ENOMEM);
+
+ soc->clk = devm_clk_get(dev, "ref");
+ if (IS_ERR(soc->clk))
+ return ERR_CAST(soc->clk);
+
+ return soc;
+}
+EXPORT_SYMBOL_GPL(mtk_btuart_init);
+
+int mtk_btuart_send(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ return mtk_stp_send(bdev, skb);
+}
+EXPORT_SYMBOL_GPL(mtk_btuart_send);
+
+int mtk_btuart_hci_frame(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct hci_event_hdr *hdr = (void *)skb->data;
+
+ /* Fix up the vendor event id with HCI_VENDOR_PKT instead of
+ * 0xe4 so that btmon can parse the kind of vendor event properly.
+ */
+ if (hdr->evt == 0xe4)
+ hdr->evt = HCI_VENDOR_PKT;
+
+ /* Each HCI event would go through the core. */
+ return hci_recv_frame(hdev, skb);
+}
+EXPORT_SYMBOL_GPL(mtk_btuart_hci_frame);
+
+int mtk_btuart_recv(struct hci_dev *hdev, const u8 *data, size_t count)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ const unsigned char *p_left = data, *p_h4;
+ const struct btuart_vnd *vnd = bdev->vnd;
+ struct mtk_bt_dev *soc = bdev->data;
+ int sz_left = count, sz_h4, adv;
+ struct device *dev;
+ int err;
+
+ dev = &bdev->serdev->dev;
+
+ while (sz_left > 0) {
+ /* The serial data received from MT7622 BT controller is
+ * at all time padded around with the STP header and tailer.
+ *
+ * A full STP packet is looking like
+ * -----------------------------------
+ * | STP header | H:4 | STP tailer |
+ * -----------------------------------
+ * but it don't guarantee to contain a full H:4 packet which
+ * means that it's possible for multiple STP packets forms a
+ * full H:4 packet and whose length recorded in STP header can
+ * shows up the most length the H:4 engine can handle in one
+ * time.
+ */
+
+ p_h4 = mtk_stp_split(bdev, soc->sp, p_left, sz_left, &sz_h4);
+ if (!p_h4)
+ break;
+
+ adv = p_h4 - p_left;
+ sz_left -= adv;
+ p_left += adv;
+
+ bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb, p_h4,
+ sz_h4, vnd->recv_pkts,
+ vnd->recv_pkts_cnt);
+ if (IS_ERR(bdev->rx_skb)) {
+ err = PTR_ERR(bdev->rx_skb);
+ bt_dev_err(bdev->hdev,
+ "Frame reassembly failed (%d)", err);
+ bdev->rx_skb = NULL;
+ return err;
+ }
+
+ sz_left -= sz_h4;
+ p_left += sz_h4;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mtk_btuart_recv);
+
+int mtk_btuart_setup(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ struct mtk_bt_dev *soc = bdev->data;
+ struct device *dev;
+ u8 param = 0x1;
+ int err = 0;
+
+ dev = &bdev->serdev->dev;
+
+ mtk_stp_reset(soc->sp);
+
+ /* Enable the power domain and clock the device requires. */
+ pm_runtime_enable(dev);
+ err = pm_runtime_get_sync(dev);
+ if (err < 0)
+ goto err_pm2;
+
+ err = clk_prepare_enable(soc->clk);
+ if (err < 0)
+ goto err_pm1;
+
+ /* Setup a firmware which the device definitely requires. */
+ err = mtk_setup_fw(bdev);
+ if (err < 0)
+ goto err_clk;
+
+ /* Activate funciton the firmware providing to. */
+ err = mtk_hci_wmt_sync(bdev, MTK_WMT_RST, 0x4, 0, 0);
+ if (err < 0)
+ goto err_clk;
+
+ /* Enable Bluetooth protocol. */
+ err = mtk_hci_wmt_sync(bdev, MTK_WMT_FUNC_CTRL, 0x0, sizeof(param),
+ ¶m);
+ if (err < 0)
+ goto err_clk;
+
+ set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks);
+
+ return 0;
+err_clk:
+ clk_disable_unprepare(soc->clk);
+err_pm1:
+ pm_runtime_put_sync(dev);
+err_pm2:
+ pm_runtime_disable(dev);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(mtk_btuart_setup);
+
+int mtk_btuart_shutdown(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ struct device *dev = &bdev->serdev->dev;
+ struct mtk_bt_dev *soc = bdev->data;
+ u8 param = 0x0;
+
+ /* Disable the device. */
+ mtk_hci_wmt_sync(bdev, MTK_WMT_FUNC_CTRL, 0x0, sizeof(param), ¶m);
+
+ /* Shutdown the clock and power domain the device requires. */
+ clk_disable_unprepare(soc->clk);
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mtk_btuart_shutdown);
+
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_DESCRIPTION("Bluetooth Support for MediaTek Serial Devices");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/bluetooth/btmtkuart.h b/drivers/bluetooth/btmtkuart.h
new file mode 100644
index 0000000..e76ab23e
--- /dev/null
+++ b/drivers/bluetooth/btmtkuart.h
@@ -0,0 +1,119 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ *
+ * Bluetooth support for MediaTek serial devices
+ *
+ * Author: Sean Wang <sean.wang@mediatek.com>
+ *
+ */
+
+#define FIRMWARE_MT7622 "mediatek/mt7622pr2h.bin"
+
+#define MTK_STP_HDR_SIZE 4
+#define MTK_STP_TLR_SIZE 2
+#define MTK_WMT_HDR_SIZE 5
+#define MTK_WMT_CMD_SIZE (MTK_WMT_HDR_SIZE + MTK_STP_HDR_SIZE + \
+ MTK_STP_TLR_SIZE + HCI_ACL_HDR_SIZE)
+
+enum {
+ MTK_WMT_PATCH_DWNLD = 0x1,
+ MTK_WMT_FUNC_CTRL = 0x6,
+ MTK_WMT_RST = 0x7
+};
+
+struct mtk_stp_hdr {
+ __u8 prefix;
+ __u8 dlen1:4;
+ __u8 type:4;
+ __u8 dlen2:8;
+ __u8 cs;
+} __packed;
+
+struct mtk_wmt_hdr {
+ __u8 dir;
+ __u8 op;
+ __le16 dlen;
+ __u8 flag;
+} __packed;
+
+struct mtk_hci_wmt_cmd {
+ struct mtk_wmt_hdr hdr;
+ __u8 data[256];
+} __packed;
+
+struct mtk_stp_splitter {
+ u8 pad[6];
+ u8 cursor;
+ u16 dlen;
+};
+
+struct mtk_bt_dev {
+ struct clk *clk;
+ struct completion wmt_cmd;
+ struct mtk_stp_splitter *sp;
+};
+
+static inline void mtk_make_stp_hdr(struct mtk_stp_hdr *hdr, u8 type, u32 dlen)
+{
+ __u8 *p = (__u8 *)hdr;
+
+ hdr->prefix = 0x80;
+ hdr->dlen1 = (dlen & 0xf00) >> 8;
+ hdr->type = type;
+ hdr->dlen2 = dlen & 0xff;
+ hdr->cs = p[0] + p[1] + p[2];
+}
+
+static inline void mtk_make_wmt_hdr(struct mtk_wmt_hdr *hdr, u8 op, u16 plen,
+ u8 flag)
+{
+ hdr->dir = 1;
+ hdr->op = op;
+ hdr->dlen = cpu_to_le16(plen + 1);
+ hdr->flag = flag;
+}
+
+#if IS_ENABLED(CONFIG_BT_HCIBTUART_MTK)
+
+void *mtk_btuart_init(struct device *dev);
+int mtk_btuart_setup(struct hci_dev *hdev);
+int mtk_btuart_shutdown(struct hci_dev *hdev);
+int mtk_btuart_send(struct hci_dev *hdev, struct sk_buff *skb);
+int mtk_btuart_hci_frame(struct hci_dev *hdev, struct sk_buff *skb);
+int mtk_btuart_recv(struct hci_dev *hdev, const u8 *data, size_t count);
+
+#else
+
+static void *mtk_btuart_init(struct device *dev)
+{
+ return 0;
+}
+
+static inline int mtk_btuart_setup(struct hci_dev *hdev)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int mtk_btuart_shutdown(struct hci_dev *hdev)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int mtk_btuart_send(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ return -EOPNOTSUPP;
+}
+
+static int mtk_btuart_hci_frame(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int mtk_btuart_recv(struct hci_dev *hdev, const u8 *data,
+ size_t count)
+{
+ return -EOPNOTSUPP;
+}
+
+#endif
diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
index ab7f836..169bf1a 100644
--- a/drivers/bluetooth/btuart.c
+++ b/drivers/bluetooth/btuart.c
@@ -35,6 +35,7 @@
#include "h4_recv.h"
#include "btuart.h"
#include "btbcm.h"
+#include "btmtkuart.h"
#define VERSION "1.0"
@@ -396,6 +397,12 @@ static const struct h4_recv_pkt bcm_recv_pkts[] = {
{ BCM_RECV_NULL, .recv = hci_recv_diag },
};
+static const struct h4_recv_pkt mtk_recv_pkts[] = {
+ { H4_RECV_ACL, .recv = hci_recv_frame },
+ { H4_RECV_SCO, .recv = hci_recv_frame },
+ { H4_RECV_EVENT, .recv = mtk_btuart_hci_frame },
+};
+
static const struct btuart_vnd bcm_vnd = {
.recv_pkts = bcm_recv_pkts,
.recv_pkts_cnt = ARRAY_SIZE(bcm_recv_pkts),
@@ -403,6 +410,16 @@ static const struct btuart_vnd bcm_vnd = {
.setup = bcm_setup,
};
+static const struct btuart_vnd mtk_vnd = {
+ .recv_pkts = mtk_recv_pkts,
+ .recv_pkts_cnt = ARRAY_SIZE(mtk_recv_pkts),
+ .init = mtk_btuart_init,
+ .setup = mtk_btuart_setup,
+ .shutdown = mtk_btuart_shutdown,
+ .send = mtk_btuart_send,
+ .recv = mtk_btuart_recv,
+};
+
static const struct h4_recv_pkt default_recv_pkts[] = {
{ H4_RECV_ACL, .recv = hci_recv_frame },
{ H4_RECV_SCO, .recv = hci_recv_frame },
@@ -487,6 +504,7 @@ static void btuart_remove(struct serdev_device *serdev)
#ifdef CONFIG_OF
static const struct of_device_id btuart_of_match_table[] = {
{ .compatible = "brcm,bcm43438-bt", .data = &bcm_vnd },
+ { .compatible = "mediatek,mt7622-bluetooth", .data = &mtk_vnd },
{ }
};
MODULE_DEVICE_TABLE(of, btuart_of_match_table);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 5/7] Bluetooth: Extend btuart driver for join more vendor devices
From: sean.wang at mediatek.com @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528960095.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Adding an independent btuart.h header allows these essential definitions
can be reused in vendor driver. Also, struct btuart_vnd is extended with
additional callbacks such as .init initializing vendor data, .shtudown,
.recv and .send supporting SoC specific framing for that btuart can
simply adapt to various Bluetooth uart-based devices.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/bluetooth/btuart.c | 73 ++++++++++++++++++++++++----------------------
drivers/bluetooth/btuart.h | 30 +++++++++++++++++++
2 files changed, 68 insertions(+), 35 deletions(-)
create mode 100644 drivers/bluetooth/btuart.h
diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
index 03e980f..ab7f836 100644
--- a/drivers/bluetooth/btuart.c
+++ b/drivers/bluetooth/btuart.c
@@ -33,35 +33,11 @@
#include <net/bluetooth/hci_core.h>
#include "h4_recv.h"
+#include "btuart.h"
#include "btbcm.h"
#define VERSION "1.0"
-struct btuart_vnd {
- const struct h4_recv_pkt *recv_pkts;
- int recv_pkts_cnt;
- unsigned int manufacturer;
- int (*open)(struct hci_dev *hdev);
- int (*close)(struct hci_dev *hdev);
- int (*setup)(struct hci_dev *hdev);
-};
-
-struct btuart_dev {
- struct hci_dev *hdev;
- struct serdev_device *serdev;
-
- struct work_struct tx_work;
- unsigned long tx_state;
- struct sk_buff_head txq;
-
- struct sk_buff *rx_skb;
-
- const struct btuart_vnd *vnd;
-};
-
-#define BTUART_TX_STATE_ACTIVE 1
-#define BTUART_TX_STATE_WAKEUP 2
-
static void btuart_tx_work(struct work_struct *work)
{
struct btuart_dev *bdev = container_of(work, struct btuart_dev,
@@ -187,13 +163,27 @@ static int btuart_setup(struct hci_dev *hdev)
return 0;
}
+static int btuart_shutdown(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ if (bdev->vnd->shutdown)
+ return bdev->vnd->shutdown(hdev);
+
+ return 0;
+}
+
static int btuart_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
{
struct btuart_dev *bdev = hci_get_drvdata(hdev);
- /* Prepend skb with frame type */
- memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
- skb_queue_tail(&bdev->txq, skb);
+ if (bdev->vnd->send) {
+ bdev->vnd->send(hdev, skb);
+ } else {
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
+ skb_queue_tail(&bdev->txq, skb);
+ }
btuart_tx_wakeup(bdev);
return 0;
@@ -204,14 +194,23 @@ static int btuart_receive_buf(struct serdev_device *serdev, const u8 *data,
{
struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
const struct btuart_vnd *vnd = bdev->vnd;
+ int err;
- bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb, data, count,
- vnd->recv_pkts, vnd->recv_pkts_cnt);
- if (IS_ERR(bdev->rx_skb)) {
- int err = PTR_ERR(bdev->rx_skb);
- bt_dev_err(bdev->hdev, "Frame reassembly failed (%d)", err);
- bdev->rx_skb = NULL;
- return err;
+ if (bdev->vnd->recv) {
+ err = bdev->vnd->recv(bdev->hdev, data, count);
+ if (err < 0)
+ return err;
+ } else {
+ bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb,
+ data, count, vnd->recv_pkts,
+ vnd->recv_pkts_cnt);
+ if (IS_ERR(bdev->rx_skb)) {
+ err = PTR_ERR(bdev->rx_skb);
+ bt_dev_err(bdev->hdev,
+ "Frame reassembly failed (%d)", err);
+ bdev->rx_skb = NULL;
+ return err;
+ }
}
bdev->hdev->stat.byte_rx += count;
@@ -429,6 +428,9 @@ static int btuart_probe(struct serdev_device *serdev)
if (!bdev->vnd)
bdev->vnd = &default_vnd;
+ if (bdev->vnd->init)
+ bdev->data = bdev->vnd->init(&serdev->dev);
+
bdev->serdev = serdev;
serdev_device_set_drvdata(serdev, bdev);
@@ -460,6 +462,7 @@ static int btuart_probe(struct serdev_device *serdev)
hdev->close = btuart_close;
hdev->flush = btuart_flush;
hdev->setup = btuart_setup;
+ hdev->shutdown = btuart_shutdown;
hdev->send = btuart_send_frame;
SET_HCIDEV_DEV(hdev, &serdev->dev);
diff --git a/drivers/bluetooth/btuart.h b/drivers/bluetooth/btuart.h
new file mode 100644
index 0000000..6c1fe31
--- /dev/null
+++ b/drivers/bluetooth/btuart.h
@@ -0,0 +1,30 @@
+struct btuart_vnd {
+ const struct h4_recv_pkt *recv_pkts;
+ int recv_pkts_cnt;
+ unsigned int manufacturer;
+ void *(*init)(struct device *dev);
+
+ int (*open)(struct hci_dev *hdev);
+ int (*close)(struct hci_dev *hdev);
+ int (*setup)(struct hci_dev *hdev);
+ int (*shutdown)(struct hci_dev *hdev);
+ int (*send)(struct hci_dev *hdev, struct sk_buff *skb);
+ int (*recv)(struct hci_dev *hdev, const u8 *data, size_t count);
+};
+
+struct btuart_dev {
+ struct hci_dev *hdev;
+ struct serdev_device *serdev;
+
+ struct work_struct tx_work;
+ unsigned long tx_state;
+ struct sk_buff_head txq;
+
+ struct sk_buff *rx_skb;
+
+ const struct btuart_vnd *vnd;
+ void *data;
+};
+
+#define BTUART_TX_STATE_ACTIVE 1
+#define BTUART_TX_STATE_WAKEUP 2
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: sean.wang at mediatek.com @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528960095.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that
runs setup() after every open() and not just after the first open().
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
include/net/bluetooth/hci.h | 9 +++++++++
net/bluetooth/hci_core.c | 3 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 1668211..b37d973 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -183,6 +183,15 @@ enum {
* during the hdev->setup vendor callback.
*/
HCI_QUIRK_NON_PERSISTENT_DIAG,
+
+ /* When this quirk is set, setup() would be run after every
+ * open() and not just after the first open().
+ *
+ * This quirk can be set before hci_register_dev is called or
+ * during the hdev->setup vendor callback.
+ *
+ */
+ HCI_QUIRK_NON_PERSISTENT_SETUP,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 1dec337..b917fa31 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1368,7 +1368,8 @@ static int hci_dev_do_open(struct hci_dev *hdev)
atomic_set(&hdev->cmd_cnt, 1);
set_bit(HCI_INIT, &hdev->flags);
- if (hci_dev_test_flag(hdev, HCI_SETUP)) {
+ if (hci_dev_test_flag(hdev, HCI_SETUP) ||
+ test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
hci_sock_dev_event(hdev, HCI_DEV_SETUP);
if (hdev->setup)
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/7] Bluetooth: Add new serdev based driver for UART attached controllers
From: sean.wang at mediatek.com @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528960095.git.sean.wang@mediatek.com>
From: Marcel Holtmann <marcel@holtmann.org>
This is a from scratch written driver to run H:4 on serdev based system
with a Bluetooth controller attached via an UART. It is currently tested
on RPi3 and it has Broadcom integration. It is DT only and is missing
GPIO and runtime power management integration. Also Apple or ACPI
support is currently not added.
To integrate with controllers from Intel and Qualcomm, similar handling
like with btusb.c has to be done. A simple abstraction for that has been
provided to make it similar to hci_uart.
The goal is to run individual drivers on serdev capable systems so that
we can retire hci_uart on these system and continue with a lot simpler
and easier to maintain driver. It seems that hci_uart has too many race
conditions due to handling TTY and line disciplines. And fixes for that
are not really related to serdev based drivers. In a serdev only world
it makes sense to remove any of the complex code.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
drivers/bluetooth/Kconfig | 11 +
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/btuart.c | 506 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 518 insertions(+)
create mode 100644 drivers/bluetooth/btuart.c
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index f3c643a..00fdf5f 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -74,6 +74,17 @@ config BT_HCIBTSDIO
Say Y here to compile support for Bluetooth SDIO devices into the
kernel or say M to compile it as module (btsdio).
+config BT_HCIBTUART
+ tristate "HCI UART driver"
+ depends on SERIAL_DEV_BUS
+ help
+ Bluetooth HCI UART driver.
+ This driver is required if you want to use Bluetooth device with
+ UART interface.
+
+ Say Y here to compile support for Bluetooth UART devices into the
+ kernel or say M to compile it as module (btuart).
+
config BT_HCIUART
tristate "HCI UART driver"
depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index ec16c55..60a19cb 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_BT_HCIBLUECARD) += bluecard_cs.o
obj-$(CONFIG_BT_HCIBTUSB) += btusb.o
obj-$(CONFIG_BT_HCIBTSDIO) += btsdio.o
+obj-$(CONFIG_BT_HCIBTUART) += btuart.o
obj-$(CONFIG_BT_INTEL) += btintel.o
obj-$(CONFIG_BT_ATH3K) += ath3k.o
diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
new file mode 100644
index 0000000..03e980f
--- /dev/null
+++ b/drivers/bluetooth/btuart.c
@@ -0,0 +1,506 @@
+/*
+ *
+ * Generic Bluetooth HCI UART driver
+ *
+ * Copyright (C) 2015-2018 Intel Corporation
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/serdev.h>
+#include <linux/of.h>
+#include <linux/firmware.h>
+#include <asm/unaligned.h>
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "h4_recv.h"
+#include "btbcm.h"
+
+#define VERSION "1.0"
+
+struct btuart_vnd {
+ const struct h4_recv_pkt *recv_pkts;
+ int recv_pkts_cnt;
+ unsigned int manufacturer;
+ int (*open)(struct hci_dev *hdev);
+ int (*close)(struct hci_dev *hdev);
+ int (*setup)(struct hci_dev *hdev);
+};
+
+struct btuart_dev {
+ struct hci_dev *hdev;
+ struct serdev_device *serdev;
+
+ struct work_struct tx_work;
+ unsigned long tx_state;
+ struct sk_buff_head txq;
+
+ struct sk_buff *rx_skb;
+
+ const struct btuart_vnd *vnd;
+};
+
+#define BTUART_TX_STATE_ACTIVE 1
+#define BTUART_TX_STATE_WAKEUP 2
+
+static void btuart_tx_work(struct work_struct *work)
+{
+ struct btuart_dev *bdev = container_of(work, struct btuart_dev,
+ tx_work);
+ struct serdev_device *serdev = bdev->serdev;
+ struct hci_dev *hdev = bdev->hdev;
+
+ while (1) {
+ clear_bit(BTUART_TX_STATE_WAKEUP, &bdev->tx_state);
+
+ while (1) {
+ struct sk_buff *skb = skb_dequeue(&bdev->txq);
+ int len;
+
+ if (!skb)
+ break;
+
+ len = serdev_device_write_buf(serdev, skb->data,
+ skb->len);
+ hdev->stat.byte_tx += len;
+
+ skb_pull(skb, len);
+ if (skb->len > 0) {
+ skb_queue_head(&bdev->txq, skb);
+ break;
+ }
+
+ switch (hci_skb_pkt_type(skb)) {
+ case HCI_COMMAND_PKT:
+ hdev->stat.cmd_tx++;
+ break;
+ case HCI_ACLDATA_PKT:
+ hdev->stat.acl_tx++;
+ break;
+ case HCI_SCODATA_PKT:
+ hdev->stat.sco_tx++;
+ break;
+ }
+
+ kfree_skb(skb);
+ }
+
+ if (!test_bit(BTUART_TX_STATE_WAKEUP, &bdev->tx_state))
+ break;
+ }
+
+ clear_bit(BTUART_TX_STATE_ACTIVE, &bdev->tx_state);
+}
+
+static int btuart_tx_wakeup(struct btuart_dev *bdev)
+{
+ if (test_and_set_bit(BTUART_TX_STATE_ACTIVE, &bdev->tx_state)) {
+ set_bit(BTUART_TX_STATE_WAKEUP, &bdev->tx_state);
+ return 0;
+ }
+
+ schedule_work(&bdev->tx_work);
+ return 0;
+}
+
+static int btuart_open(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ int err;
+
+ err = serdev_device_open(bdev->serdev);
+ if (err) {
+ bt_dev_err(hdev, "Unable to open UART device %s",
+ dev_name(&bdev->serdev->dev));
+ return err;
+ }
+
+ if (bdev->vnd->open) {
+ err = bdev->vnd->open(hdev);
+ if (err) {
+ serdev_device_close(bdev->serdev);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
+static int btuart_close(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ int err;
+
+ if (bdev->vnd->close) {
+ err = bdev->vnd->close(hdev);
+ if (err)
+ return err;
+ }
+
+ serdev_device_close(bdev->serdev);
+
+ return 0;
+}
+
+static int btuart_flush(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ /* Flush any pending characters */
+ serdev_device_write_flush(bdev->serdev);
+ skb_queue_purge(&bdev->txq);
+
+ cancel_work_sync(&bdev->tx_work);
+
+ kfree_skb(bdev->rx_skb);
+ bdev->rx_skb = NULL;
+
+ return 0;
+}
+
+static int btuart_setup(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ if (bdev->vnd->setup)
+ return bdev->vnd->setup(hdev);
+
+ return 0;
+}
+
+static int btuart_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
+ skb_queue_tail(&bdev->txq, skb);
+
+ btuart_tx_wakeup(bdev);
+ return 0;
+}
+
+static int btuart_receive_buf(struct serdev_device *serdev, const u8 *data,
+ size_t count)
+{
+ struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
+ const struct btuart_vnd *vnd = bdev->vnd;
+
+ bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb, data, count,
+ vnd->recv_pkts, vnd->recv_pkts_cnt);
+ if (IS_ERR(bdev->rx_skb)) {
+ int err = PTR_ERR(bdev->rx_skb);
+ bt_dev_err(bdev->hdev, "Frame reassembly failed (%d)", err);
+ bdev->rx_skb = NULL;
+ return err;
+ }
+
+ bdev->hdev->stat.byte_rx += count;
+
+ return count;
+}
+
+static void btuart_write_wakeup(struct serdev_device *serdev)
+{
+ struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
+
+ btuart_tx_wakeup(bdev);
+}
+
+static const struct serdev_device_ops btuart_client_ops = {
+ .receive_buf = btuart_receive_buf,
+ .write_wakeup = btuart_write_wakeup,
+};
+
+#define BCM_NULL_PKT 0x00
+#define BCM_NULL_SIZE 0
+
+#define BCM_LM_DIAG_PKT 0x07
+#define BCM_LM_DIAG_SIZE 63
+
+#define BCM_RECV_LM_DIAG \
+ .type = BCM_LM_DIAG_PKT, \
+ .hlen = BCM_LM_DIAG_SIZE, \
+ .loff = 0, \
+ .lsize = 0, \
+ .maxlen = BCM_LM_DIAG_SIZE
+
+#define BCM_RECV_NULL \
+ .type = BCM_NULL_PKT, \
+ .hlen = BCM_NULL_SIZE, \
+ .loff = 0, \
+ .lsize = 0, \
+ .maxlen = BCM_NULL_SIZE
+
+static int bcm_set_diag(struct hci_dev *hdev, bool enable)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ struct sk_buff *skb;
+
+ if (!test_bit(HCI_RUNNING, &hdev->flags))
+ return -ENETDOWN;
+
+ skb = bt_skb_alloc(3, GFP_KERNEL);
+ if (!skb)
+ return -ENOMEM;
+
+ skb_put_u8(skb, BCM_LM_DIAG_PKT);
+ skb_put_u8(skb, 0xf0);
+ skb_put_u8(skb, enable);
+
+ skb_queue_tail(&bdev->txq, skb);
+ btuart_tx_wakeup(bdev);
+
+ return 0;
+}
+
+static int bcm_set_baudrate(struct btuart_dev *bdev, unsigned int speed)
+{
+ struct hci_dev *hdev = bdev->hdev;
+ struct sk_buff *skb;
+ struct bcm_update_uart_baud_rate param;
+
+ if (speed > 3000000) {
+ struct bcm_write_uart_clock_setting clock;
+
+ clock.type = BCM_UART_CLOCK_48MHZ;
+
+ bt_dev_dbg(hdev, "Set Controller clock (%d)", clock.type);
+
+ /* This Broadcom specific command changes the UART's controller
+ * clock for baud rate > 3000000.
+ */
+ skb = __hci_cmd_sync(hdev, 0xfc45, 1, &clock, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ int err = PTR_ERR(skb);
+ bt_dev_err(hdev, "Failed to write clock (%d)", err);
+ return err;
+ }
+
+ kfree_skb(skb);
+ }
+
+ bt_dev_dbg(hdev, "Set Controller UART speed to %d bit/s", speed);
+
+ param.zero = cpu_to_le16(0);
+ param.baud_rate = cpu_to_le32(speed);
+
+ /* This Broadcom specific command changes the UART's controller baud
+ * rate.
+ */
+ skb = __hci_cmd_sync(hdev, 0xfc18, sizeof(param), ¶m,
+ HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ int err = PTR_ERR(skb);
+ bt_dev_err(hdev, "Failed to write update baudrate (%d)", err);
+ return err;
+ }
+
+ kfree_skb(skb);
+
+ return 0;
+}
+
+static int bcm_setup(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ char fw_name[64];
+ const struct firmware *fw;
+ unsigned int speed;
+ int err;
+
+ hdev->set_diag = bcm_set_diag;
+ hdev->set_bdaddr = btbcm_set_bdaddr;
+
+ /* Init speed if any */
+ speed = 115200;
+
+ if (speed)
+ serdev_device_set_baudrate(bdev->serdev, speed);
+
+ /* Operational speed if any */
+ speed = 115200;
+
+ if (speed) {
+ err = bcm_set_baudrate(bdev, speed);
+ if (err)
+ bt_dev_err(hdev, "Failed to set baudrate");
+ else
+ serdev_device_set_baudrate(bdev->serdev, speed);
+ }
+
+ err = btbcm_initialize(hdev, fw_name, sizeof(fw_name));
+ if (err)
+ return err;
+
+ err = request_firmware(&fw, fw_name, &hdev->dev);
+ if (err < 0) {
+ bt_dev_warn(hdev, "Patch %s not found", fw_name);
+ return 0;
+ }
+
+ err = btbcm_patchram(bdev->hdev, fw);
+ if (err) {
+ bt_dev_err(hdev, "Patching failed (%d)", err);
+ goto finalize;
+ }
+
+ /* Init speed if any */
+ speed = 115200;
+
+ if (speed)
+ serdev_device_set_baudrate(bdev->serdev, speed);
+
+ /* Operational speed if any */
+ speed = 115200;
+
+ if (speed) {
+ err = bcm_set_baudrate(bdev, speed);
+ if (!err)
+ serdev_device_set_baudrate(bdev->serdev, speed);
+ }
+
+finalize:
+ release_firmware(fw);
+
+ err = btbcm_finalize(hdev);
+ if (err)
+ return err;
+
+ return err;
+}
+
+static const struct h4_recv_pkt bcm_recv_pkts[] = {
+ { H4_RECV_ACL, .recv = hci_recv_frame },
+ { H4_RECV_SCO, .recv = hci_recv_frame },
+ { H4_RECV_EVENT, .recv = hci_recv_frame },
+ { BCM_RECV_LM_DIAG, .recv = hci_recv_diag },
+ { BCM_RECV_NULL, .recv = hci_recv_diag },
+};
+
+static const struct btuart_vnd bcm_vnd = {
+ .recv_pkts = bcm_recv_pkts,
+ .recv_pkts_cnt = ARRAY_SIZE(bcm_recv_pkts),
+ .manufacturer = 15,
+ .setup = bcm_setup,
+};
+
+static const struct h4_recv_pkt default_recv_pkts[] = {
+ { H4_RECV_ACL, .recv = hci_recv_frame },
+ { H4_RECV_SCO, .recv = hci_recv_frame },
+ { H4_RECV_EVENT, .recv = hci_recv_frame },
+};
+
+static const struct btuart_vnd default_vnd = {
+ .recv_pkts = default_recv_pkts,
+ .recv_pkts_cnt = ARRAY_SIZE(default_recv_pkts),
+};
+
+static int btuart_probe(struct serdev_device *serdev)
+{
+ struct btuart_dev *bdev;
+ struct hci_dev *hdev;
+
+ bdev = devm_kzalloc(&serdev->dev, sizeof(*bdev), GFP_KERNEL);
+ if (!bdev)
+ return -ENOMEM;
+
+ /* Request the vendor specific data and callbacks */
+ bdev->vnd = device_get_match_data(&serdev->dev);
+ if (!bdev->vnd)
+ bdev->vnd = &default_vnd;
+
+ bdev->serdev = serdev;
+ serdev_device_set_drvdata(serdev, bdev);
+
+ serdev_device_set_client_ops(serdev, &btuart_client_ops);
+
+ INIT_WORK(&bdev->tx_work, btuart_tx_work);
+ skb_queue_head_init(&bdev->txq);
+
+ /* Initialize and register HCI device */
+ hdev = hci_alloc_dev();
+ if (!hdev) {
+ dev_err(&serdev->dev, "Can't allocate HCI device\n");
+ return -ENOMEM;
+ }
+
+ bdev->hdev = hdev;
+
+ hdev->bus = HCI_UART;
+ hci_set_drvdata(hdev, bdev);
+
+ /* Only when vendor specific setup callback is provided, consider
+ * the manufacturer information valid. This avoids filling in the
+ * value for Ericsson when nothing is specified.
+ */
+ if (bdev->vnd->setup)
+ hdev->manufacturer = bdev->vnd->manufacturer;
+
+ hdev->open = btuart_open;
+ hdev->close = btuart_close;
+ hdev->flush = btuart_flush;
+ hdev->setup = btuart_setup;
+ hdev->send = btuart_send_frame;
+ SET_HCIDEV_DEV(hdev, &serdev->dev);
+
+ if (hci_register_dev(hdev) < 0) {
+ dev_err(&serdev->dev, "Can't register HCI device\n");
+ hci_free_dev(hdev);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void btuart_remove(struct serdev_device *serdev)
+{
+ struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
+ struct hci_dev *hdev = bdev->hdev;
+
+ hci_unregister_dev(hdev);
+ hci_free_dev(hdev);
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id btuart_of_match_table[] = {
+ { .compatible = "brcm,bcm43438-bt", .data = &bcm_vnd },
+ { }
+};
+MODULE_DEVICE_TABLE(of, btuart_of_match_table);
+#endif
+
+static struct serdev_device_driver btuart_driver = {
+ .probe = btuart_probe,
+ .remove = btuart_remove,
+ .driver = {
+ .name = "btuart",
+ .of_match_table = of_match_ptr(btuart_of_match_table),
+ },
+};
+
+module_serdev_device_driver(btuart_driver);
+
+MODULE_AUTHOR("Marcel Holtmann <marcel@holtmann.org>");
+MODULE_DESCRIPTION("Generic Bluetooth UART driver ver " VERSION);
+MODULE_VERSION(VERSION);
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/7] serdev: add dev_pm_domain_attach|detach()
From: sean.wang at mediatek.com @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528960095.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
In order to open up the required power gate before any operation can be
effectively performed over the serial bus between CPU and serdev, it's
clearly essential to add common attach functions for PM domains to serdev
at the probe phase.
Similarly, the relevant dettach function for the PM domains should be
properly and reversely added at the remove phase.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial at vger.kernel.org
---
drivers/tty/serdev/core.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index df93b72..c93d8ee 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/pm_domain.h>
#include <linux/serdev.h>
#include <linux/slab.h>
@@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
static int serdev_drv_probe(struct device *dev)
{
const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
+ int ret;
+
+ ret = dev_pm_domain_attach(dev, true);
+ if (ret != -EPROBE_DEFER) {
+ ret = sdrv->probe(to_serdev_device(dev));
+ if (ret)
+ dev_pm_domain_detach(dev, true);
+ }
- return sdrv->probe(to_serdev_device(dev));
+ return ret;
}
static int serdev_drv_remove(struct device *dev)
@@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
if (sdrv->remove)
sdrv->remove(to_serdev_device(dev));
+
+ dev_pm_domain_detach(dev, true);
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth
From: sean.wang at mediatek.com @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528960095.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Add binding document for a SoC built-in device using MediaTek protocol.
Which could be found on MT7622 SoC or other similar MediaTek SoCs.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
new file mode 100644
index 0000000..1335429
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
@@ -0,0 +1,35 @@
+MediaTek SoC built-in Bluetooth Devices
+==================================
+
+This device is a serial attached device to BTIF device and thus it must be a
+child node of the serial node with BTIF. The dt-bindings details for BTIF
+device can be known via Documentation/devicetree/bindings/serial/8250.txt.
+
+Required properties:
+
+- compatible: Must be one of
+ "mediatek,mt7622-bluetooth"": for MT7622 SoC
+- clocks: Should be the clock specifiers corresponding to the entry in
+ clock-names property.
+- clock-names: Should contain "ref" entries.
+- power-domains: Phandle to the power domain that the device is part of
+
+Example:
+
+ btif: serial at 1100c000 {
+ compatible = "mediatek,mt7622-btif",
+ "mediatek,mtk-btif";
+ reg = <0 0x1100c000 0 0x1000>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_BTIF_PD>;
+ clock-names = "main";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+
+ bluetooth {
+ compatible = "mediatek,mt7622-bluetooth";
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
+ clocks = <&clk25m>;
+ clock-names = "ref";
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/7] add support for Bluetooth on MT7622 SoC
From: sean.wang at mediatek.com @ 2018-06-14 7:14 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
v3 and changes since v2
* all changes happen on patch 6
- fix up SPDX license style for btmtkuart.h.
- change firmware download from in ACL data to in HCI commands
and then remove unused mtk_acl_wmt_sync and related code.
- add a workaround replacing bad vendor event id 0xe4 with 0xff every
vendor should use.
- add a sanity check for mtk_hci_wmt_sync to verifying if
input parameters are valid.
- add an atomic_inc(&bdev->hdev->cmd_cnt) for __hci_cmd_sync_ev.
- be changed to use firmware with a header called mt7622pr2h.bin.
v2 and changes since v1
- Dropped patches already being applied
- Rewirte the whole driver using btuart [1], and add slight extension
of btuart to fit into btmtkuart driver. Beware that [1] is also pulled
into one part of the series for avoiding any breakage when the patchset
is being compiled.
[1] btuart
https://www.spinics.net/lists/linux-bluetooth/msg74918.html
v1:
Hi,
This patchset introduces built-in Bluetooth support on MT7622 SoC.
And, it should be simple to make an extension to support other
MediaTek SoCs with adjusting a few of changes on the initialization
sequence of the device.
Before the main driver is being introduced, a few of things about
power-domain management should be re-worked for serdev core and MediaTek
SCPSYS to allow the Bluetooth to properly power up.
Patch 2: add a generic way attaching power domain to serdev
Patch 3 and 4: add cleanups with reuse APIs from Linux core
Patch 5: fix a limitation about power enablement Bluetooth depends on
Patch 1, 6 and 7: the major part of adding Bluetooth support to MT7622
Sean
Marcel Holtmann (1):
Bluetooth: Add new serdev based driver for UART attached controllers
Sean Wang (6):
dt-bindings: net: bluetooth: Add mediatek-bluetooth
serdev: add dev_pm_domain_attach|detach()
Bluetooth: Add new quirk for non-persistent setup settings
Bluetooth: Extend btuart driver for join more vendor devices
Bluetooth: mediatek: Add protocol support for MediaTek serial devices
MAINTAINERS: add an entry for MediaTek Bluetooth driver
.../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++
MAINTAINERS | 8 +
drivers/bluetooth/Kconfig | 23 +
drivers/bluetooth/Makefile | 3 +
drivers/bluetooth/btmtkuart.c | 355 ++++++++++++++
drivers/bluetooth/btmtkuart.h | 119 +++++
drivers/bluetooth/btuart.c | 527 +++++++++++++++++++++
drivers/bluetooth/btuart.h | 30 ++
drivers/tty/serdev/core.c | 14 +-
include/net/bluetooth/hci.h | 9 +
net/bluetooth/hci_core.c | 3 +-
11 files changed, 1124 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
create mode 100644 drivers/bluetooth/btmtkuart.c
create mode 100644 drivers/bluetooth/btmtkuart.h
create mode 100644 drivers/bluetooth/btuart.c
create mode 100644 drivers/bluetooth/btuart.h
--
2.7.4
^ permalink raw reply
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
From: Jagan Teki @ 2018-06-14 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> This series adds support for R40 HDMI pipeline. It is a bit special
> than other already supported pipelines because it has additional unit
> called TCON TOP responsible for relationship configuration between
> mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> and TV TCONs, TV encoder clock settings and pin muxing between LCD
> and TV encoders.
>
> However, it seems that TCON TOP will become a norm, since newer
> Allwinner SoCs like H6 also have this unit.
>
> I tested different possible configurations:
> - mixer0 <> TCON-TV0 <> HDMI
> - mixer0 <> TCON-TV1 <> HDMI
> - mixer1 <> TCON-TV0 <> HDMI
> - mixer1 <> TCON-TV1 <> HDMI
>
> Please review.
>
> Best regards,
> Jernej
>
> Changes from v1:
> - Split DT bindings patch and updated description
> - Split HDMI PHY patch
> - Move header file from TCON TOP patch to dt bindings patch
> - Added Rob reviewed-by tag
> - Used clk_hw_register_gate() instead of custom gate registration code
> - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> new patches were added.
> - Droped mixer index quirk patch
> - Reworked TCON support for TCON TOP
> - Updated commit messages
>
> Jernej Skrabec (27):
> clk: sunxi-ng: r40: Add minimal rate for video PLLs
> clk: sunxi-ng: r40: Allow setting parent rate to display related
> clocks
> clk: sunxi-ng: r40: Export video PLLs
> dt-bindings: display: sunxi-drm: Add TCON TOP description
> drm/sun4i: Add TCON TOP driver
> drm/sun4i: Fix releasing node when enumerating enpoints
> drm/sun4i: Split out code for enumerating endpoints in output port
> drm/sun4i: Add support for traversing graph with TCON TOP
> drm/sun4i: Don't skip TCONs if they don't have channel 0
> dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> drm/sun4i: tcon: Add support for tcon-top gate
> drm/sun4i: tcon: Generalize engine search algorithm
> drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> drm/sun4i: Don't check for panel or bridge on TV TCONs
> drm/sun4i: Add support for R40 TV TCON
> dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> drm/sun4i: Add support for R40 mixers
> dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> drm/sun4i: Enable DW HDMI PHY clock
> drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> drm/sun4i: DW HDMI PHY: Add support for second PLL
> drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> driver
> drm/sun4i: Add support for A64 HDMI PHY
> drm: of: Export drm_crtc_port_mask()
> drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> ARM: dts: sun8i: r40: Add HDMI pipeline
> ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
Tested whole series on top of linux-next.
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
^ permalink raw reply
* [EXTERNAL] Re: [PATCH] arm64: dts: hikey: Define wl1835 power capabilities
From: Reizer, Eyal @ 2018-06-14 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tvq6a577.fsf@kamboji.qca.qualcomm.com>
> >> These properties are required for compatibility with runtime PM.
> >> Without these properties, MMC host controller will not be aware
> >> of power capabilities. When the wlcore driver attempts to power
> >> on the device, it will erroneously fail with -EACCES.
> >>
> >> Signed-off-by: Ryan Grachek <ryan@edited.us>
> >
> > Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
> > Tested-by: John Stultz <john.stultz@linaro.org>
> > Acked-by: John Stultz <john.stultz@linaro.org>
> >
> > Wei Xu: This fixes a functional regression with wifi on the HiKey
> > board that was introduced in 4.18-rc with commit 60f36637bbbd
> > ("wlcore: sdio: allow pm to handle sdio power").
> >
> > Could you please be sure to queue this for the 4.18-rc ?
>
> Adding linux-wireless so that wireless folks are aware of this wlcore
> regression fix as well.
>
Actually "cap-power-off-card" is normally included with all .dts files supporting wilink
So it should have been there from the start for this board as well.
It probably worked without it due to the explicit call to mmc_power_restore_host()
that was there as an old workaround for trying to control the power explicitly from the
driver which was actually causing other failures on suspend/resume as the mmc layer
already power the module on resume.
"keep-power-in-suspend" is needed in case of planning to use "WoWLAN":
Iw phy0 wowlan enable....
Best Regards,
Eyal
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Hanjun Guo @ 2018-06-14 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmce60y3.fsf@e105922-lin.cambridge.arm.com>
Hi Punit,
On 2018/6/14 1:39, Punit Agrawal wrote:
> Punit Agrawal <punit.agrawal@arm.com> writes:
>
>
> [...]
>
>>
>> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end
>> up returning the original node in the fallback path.
>>
>> Xie, does the below patch help? I can submit a proper patch if this
>> fixes the issue for you.
>>
>> -- >8 --
>> Subject: [PATCH] arm64/numa: Enable memoryless numa nodes
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> ---
>> arch/arm64/Kconfig | 4 ++++
>> arch/arm64/mm/numa.c | 2 ++
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index eb2cf4938f6d..5317e9aa93ab 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -756,6 +756,10 @@ config USE_PERCPU_NUMA_NODE_ID
>> def_bool y
>> depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> + def_bool y
>> + depends on NUMA
>> +
>> config HAVE_SETUP_PER_CPU_AREA
>> def_bool y
>> depends on NUMA
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index dad128ba98bf..c699dcfe93de 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -73,6 +73,8 @@ EXPORT_SYMBOL(cpumask_of_node);
>> static void map_cpu_to_node(unsigned int cpu, int nid)
>> {
>> set_cpu_numa_node(cpu, nid);
>> + set_numa_mem(local_memory_node(nid));
>
> Argh, this should be
>
> set_cpu_numa_mem(cpu, local_memory_node(nid));
>
> There is not guarantee that map_cpu_to_node() will be called on the
> local cpu.
>
> Hanjun, Xie - can you try with the update please?
Thanks for looking into this, we will try this tomorrow
(the hardware is occupied now) and update here.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-14 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613101124.GB26280@arm.com>
Hi Will,
On Wed, Jun 13, 2018 at 3:41 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Jun 13, 2018 at 10:46:56AM +0530, Bhupesh Sharma wrote:
>> On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com> wrote:
>> > On 12/06/18 09:25, Bhupesh Sharma wrote:
>> >> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
>> >> <ard.biesheuvel@linaro.org> wrote:
>> >>> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>> >>>> The start of the linear region map on a KASLR enabled ARM64 machine -
>> >>>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
>> >>>> support), is no longer correctly represented by the PAGE_OFFSET macro,
>> >>>> since it is defined as:
>> >>>>
>> >>>> (UL(1) << (VA_BITS - 1)) + 1)
>> >
>> >>> PAGE_OFFSET is the VA of the start of the linear map. The linear map
>> >>> can be sparsely populated with actual memory, regardless of whether
>> >>> KASLR is in effect or not. The only difference in the presence of
>> >>> KASLR is that there may be such a hole at the beginning, but that does
>> >>> not mean the linear map has moved, or that the value of PAGE_OFFSET is
>> >>> now wrong.
>> >
>> >>>> So taking an example of a platform with VA_BITS=48, this gives a static
>> >>>> value of:
>> >>>> PAGE_OFFSET = 0xffff800000000000
>> >>>>
>> >>>> However, for the KASLR case, we use the 'memstart_offset_seed'
>> >>>> to randomize the linear region - since 'memstart_addr' indicates the
>> >>>> start of physical RAM, we randomize the same on basis
>> >>>> of 'memstart_offset_seed' value.
>> >>>>
>> >>>> As the PAGE_OFFSET value is used presently by several user space
>> >>>> tools (for e.g. makedumpfile and crash tools) to determine the start
>> >>>> of linear region and hence to read addresses (like PT_NOTE fields) from
>> >>>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
>> >>>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
>> >>>> the start of linear region for the KASLR cases and default to
>> >>>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
>> >>>> linear region.
>> >
>> >>> Userland code that assumes that the linear map cannot have a hole at
>> >>> the beginning should be fixed.
>> >
>> >> That is a separate case (although that needs fixing as well via a
>> >> kernel patch probably as the user-space tools rely on '/proc/iomem'
>> >> contents to determine the first System RAM/reserved range).
>> >
>> > This is for kexec-tools generating the kdump vmcore ELF headers in user-space?
>>
>> Yes, but again, I would like to reiterate that the case where I see a
>> hole at the start of the System RAM range (as I listed above) is just
>> a specific case, which probably deserves a separate patch. The current
>> patch though is for a generic issue (please see more details below).
>>
>> >> 1. In that particular case (see [1]) the EFI firmware sets the first
>> >> EFI block as EfiReservedMemType:
>> >>
>> >> Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
>> >> Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
>> >>
>> >> Since EFI firmware won't return the "EfiReservedMemType" memory to
>> >> Linux kernel,
>> >
>> > (Its linux that makes this choice in
>> > drivers/firmware/efi/arm-init.c::is_usable_memory())
>> >
>> >
>> >> so the kernel can't get any info about the first mem
>> >> block, and kernel can only see region2 as below:
>> >>
>> >> efi: Processing EFI memory map:
>> >> efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
>> >> | | | | |WB|WT|WC|UC]
>> >>
>> >> # head -1 /proc/iomem
>> >> 00200000-0021ffff : reserved
>> >>
>> >> 2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
>> >> kernel Virtual map we can see that the memory node is set to:
>> >>
>> >> # dmesg | grep memory
>> >> ..........
>> >> memory : 0xffff800000200000 - 0xffff801800000000
>> >>
>> >> 2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
>> >> if we use 'readelf' to get the last program Header from vmcore (logs
>> >> below are for the non-kaslr case):
>> >>
>> >> # readelf -l vmcore
>> >>
>> >> ELF Header:
>> >> ........................
>> >>
>> >> Program Headers:
>> >> Type Offset VirtAddr PhysAddr
>> >> FileSiz MemSiz Flags Align
>> >> ..............................................................................................................................................................
>> >> LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
>> >> 0x0000001680000000 0x0000001680000000 RWE 0
>> >>
>> >> 3. So if we do a simple calculation:
>> >>
>> >> (VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
>> >> 0xFFFF8017FFE00000 != 0xffff801800000000.
>> >>
>> >> which indicates that the end virtual memory nodes are not the same
>> >> between vmlinux and vmcore.
>> >
>> > If I've followed this properly: the problem is that to generate the ELF headers
>> > in the post-kdump vmcore, at kdump-load-time kexec-tools has to guess the
>> > virtual addresses of the 'System RAM' regions it can see in /proc/iomem.
>> >
>> > The problem you are hitting is an invisible hole at the beginning of RAM,
>> > meaning user-space's guess_phys_to_virt() is off by the size of this hole.
>> >
>> > Isn't KASLR a special case for this? You must have to correct for that after
>> > kdump has happened, based on an elf-note in the vmcore. Can't we always do this?
>>
>> No, I hit this issue both for the KASLR and non-KASLR boot cases. We
>> can fix this either in kernel or user-space.
>>
>> Fixing this in kernel space seems better to me as the definition of
>> 'memstart_addr' is that it indicates the start of the physical ram,
>> but since in this case there is a hole at the start of the system ram
>> visible in Linux (and thus to user-space), but 'memstart_addr' is
>> still 0 which seems contradictory at the least. This causes PHY_OFFSET
>> to be 0 as well, which is again contradictory.
>
> Contradictory to who?
I meant that the 'memstart_addr' and PHY_OFFSET value are computed as
0 in the above particular case, which is not the real representation
of the start of System RAM as the 1st memory block available in Linux
starts from 2MB [as confirmed by the 'memblock_start_of_DRAM()' value
of 0x200000] and indicated by '/proc/iomem':
# head -1 /proc/iomem
00200000-0021ffff : reserved
> Userspace has no business messing around with this
> stuff and I'm reluctant to make this an ABI by adding a symbol with a
> special name. Why can't the various constants needed by these tools be
> exported in the ELF headers for kcore/vmcore, or as a NOTE as James
> suggests? That sounds a lot less fragile to me.
But we already add the 'memstart_addr' variable to kallsyms in the
kernel, don't we? And so user-space tools do use the same - so we
already have a precedent available.
Again this patch was an attempt to start a conversation as my query
towards determining the base of linear range by either:
- reading the 'memstart_addr' and backcomputing the start of linear range, or
- adding a new variable (which this patch does), or
- use other approaches
did not see a conclusion (please see [1]).
[1] https://www.spinics.net/lists/arm-kernel/msg655933.html
Regards,
Bhupesh
^ permalink raw reply
* [PATCH] arm64: dts: hikey960: Define wl1837 power capabilities
From: Kalle Valo @ 2018-06-14 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALAqxLWuUJYfXszaO01KODbom8WykKQKm0X3fzPTwSRK+G3zqw@mail.gmail.com>
John Stultz <john.stultz@linaro.org> writes:
> On Wed, Jun 13, 2018 at 11:03 AM, Ryan Grachek <ryan@edited.us> wrote:
>> These properties are required for compatibility with runtime PM.
>> Without these properties, MMC host controller will not be aware
>> of power capabilities. When the wlcore driver attempts to power
>> on the device, it will erroneously fail with -EACCES. This fixes
>> a regression found here: https://lkml.org/lkml/2018/6/12/930
>>
>> Signed-off-by: Ryan Grachek <ryan@edited.us>
>
> Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
> Tested-by: John Stultz <john.stultz@linaro.org>
> Acked-by: John Stultz <john.stultz@linaro.org>
>
> Wei Xu: This also fixes a functional regression with wifi on the
> HiKey960 board that was introduced in 4.18-rc with commit 60f36637bbbd
> ("wlcore: sdio: allow pm to handle sdio power").
>
> Could you please be sure to queue this for the 4.18-rc too?
CCing wireless folks as well.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: David Wu @ 2018-06-14 6:15 UTC (permalink / raw)
To: linux-arm-kernel
Add constants and callback functions for the dwmac on PX30 Soc.
The base structure is the same, but registers and the bits in
them are moved slightly, and add the clk_mac_speed for selecting
mac speed.
Signed-off-by: David Wu <david.wu@rock-chips.com>
---
Change in v2:
- Fix some error in commit title and message
.../devicetree/bindings/net/rockchip-dwmac.txt | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 64 ++++++++++++++++++++++
2 files changed, 65 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
index 9c16ee2..3b71da7 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
@@ -4,6 +4,7 @@ The device node has following properties.
Required properties:
- compatible: should be "rockchip,<name>-gamc"
+ "rockchip,px30-gmac": found on PX30 SoCs
"rockchip,rk3128-gmac": found on RK312x SoCs
"rockchip,rk3228-gmac": found on RK322x SoCs
"rockchip,rk3288-gmac": found on RK3288 SoCs
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 13133b3..5e69dd0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -61,6 +61,7 @@ struct rk_priv_data {
struct clk *mac_clk_tx;
struct clk *clk_mac_ref;
struct clk *clk_mac_refout;
+ struct clk *clk_mac_speed;
struct clk *aclk_mac;
struct clk *pclk_mac;
struct clk *clk_phy;
@@ -83,6 +84,64 @@ struct rk_priv_data {
(((tx) ? soc##_GMAC_TXCLK_DLY_ENABLE : soc##_GMAC_TXCLK_DLY_DISABLE) | \
((rx) ? soc##_GMAC_RXCLK_DLY_ENABLE : soc##_GMAC_RXCLK_DLY_DISABLE))
+#define PX30_GRF_GMAC_CON1 0x0904
+
+/* PX30_GRF_GMAC_CON1 */
+#define PX30_GMAC_PHY_INTF_SEL_RMII (GRF_CLR_BIT(4) | GRF_CLR_BIT(5) | \
+ GRF_BIT(6))
+#define PX30_GMAC_SPEED_10M GRF_CLR_BIT(2)
+#define PX30_GMAC_SPEED_100M GRF_BIT(2)
+
+static void px30_set_to_rmii(struct rk_priv_data *bsp_priv)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ regmap_write(bsp_priv->grf, PX30_GRF_GMAC_CON1,
+ PX30_GMAC_PHY_INTF_SEL_RMII);
+}
+
+static void px30_set_rmii_speed(struct rk_priv_data *bsp_priv, int speed)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+ int ret;
+
+ if (IS_ERR(bsp_priv->clk_mac_speed)) {
+ dev_err(dev, "%s: Missing clk_mac_speed clock\n", __func__);
+ return;
+ }
+
+ if (speed == 10) {
+ regmap_write(bsp_priv->grf, PX30_GRF_GMAC_CON1,
+ PX30_GMAC_SPEED_10M);
+
+ ret = clk_set_rate(bsp_priv->clk_mac_speed, 2500000);
+ if (ret)
+ dev_err(dev, "%s: set clk_mac_speed rate 2500000 failed: %d\n",
+ __func__, ret);
+ } else if (speed == 100) {
+ regmap_write(bsp_priv->grf, PX30_GRF_GMAC_CON1,
+ PX30_GMAC_SPEED_100M);
+
+ ret = clk_set_rate(bsp_priv->clk_mac_speed, 25000000);
+ if (ret)
+ dev_err(dev, "%s: set clk_mac_speed rate 25000000 failed: %d\n",
+ __func__, ret);
+
+ } else {
+ dev_err(dev, "unknown speed value for RMII! speed=%d", speed);
+ }
+}
+
+static const struct rk_gmac_ops px30_ops = {
+ .set_to_rmii = px30_set_to_rmii,
+ .set_rmii_speed = px30_set_rmii_speed,
+};
+
#define RK3128_GRF_MAC_CON0 0x0168
#define RK3128_GRF_MAC_CON1 0x016c
@@ -1042,6 +1101,10 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
}
}
+ bsp_priv->clk_mac_speed = devm_clk_get(dev, "clk_mac_speed");
+ if (IS_ERR(bsp_priv->clk_mac_speed))
+ dev_err(dev, "cannot get clock %s\n", "clk_mac_speed");
+
if (bsp_priv->clock_input) {
dev_info(dev, "clock input from PHY\n");
} else {
@@ -1424,6 +1487,7 @@ static int rk_gmac_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(rk_gmac_pm_ops, rk_gmac_suspend, rk_gmac_resume);
static const struct of_device_id rk_gmac_dwmac_match[] = {
+ { .compatible = "rockchip,px30-gmac", .data = &px30_ops },
{ .compatible = "rockchip,rk3128-gmac", .data = &rk3128_ops },
{ .compatible = "rockchip,rk3228-gmac", .data = &rk3228_ops },
{ .compatible = "rockchip,rk3288-gmac", .data = &rk3288_ops },
--
2.7.4
^ permalink raw reply related
* [PATCH] gpio: uniphier: set legitimate irq trigger type in .to_irq hook
From: Masahiro Yamada @ 2018-06-14 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528954065-25563-1-git-send-email-yamada.masahiro@socionext.com>
2018-06-14 14:27 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> If a GPIO chip is a part of a hierarchy IRQ domain, there is no
> way to specify the trigger type when gpio(d)_to_irq() allocates an
> interrupt on-the-fly.
>
> Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes
> an error in the .alloc() hook of the parent domain.
> (drivers/irq/irq-uniphier-aidet.c)
>
> Even if we change irq-uniphier-aidet.c to accept the NONE type,
> GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic:
> Loudly complain about the use of IRQ_TYPE_NONE").
>
> Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq
> is allocated. irq_set_irq_type() will override it when the irq is
> really requested.
>
> Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
> Reported-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Tested-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
BTW, gpio-xgene-sb.c is also suspicious.
https://github.com/torvalds/linux/blob/v4.17/drivers/gpio/gpio-xgene-sb.c#L136
I do not have that hardware, but GIC will complain about NONE type
if gpio(d)_to_irq() is used.
Commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
only mentions DT cases.
It is unclear how to take care of GPIO-originated IRQs.
> drivers/gpio/gpio-uniphier.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
> index d3cf950..58faeb1 100644
> --- a/drivers/gpio/gpio-uniphier.c
> +++ b/drivers/gpio/gpio-uniphier.c
> @@ -181,7 +181,11 @@ static int uniphier_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
> fwspec.fwnode = of_node_to_fwnode(chip->parent->of_node);
> fwspec.param_count = 2;
> fwspec.param[0] = offset - UNIPHIER_GPIO_IRQ_OFFSET;
> - fwspec.param[1] = IRQ_TYPE_NONE;
> + /*
> + * IRQ_TYPE_NONE is rejected by the parent irq domain. Set LEVEL_HIGH
> + * temporarily. Anyway, ->irq_set_type() will override it later.
> + */
> + fwspec.param[1] = IRQ_TYPE_LEVEL_HIGH;
>
> return irq_create_fwspec_mapping(&fwspec);
> }
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values from DT
From: Manish Narani @ 2018-06-14 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528373500-24663-3-git-send-email-manish.narani@xilinx.com>
Ping for RFC
> -----Original Message-----
> From: Manish Narani [mailto:manish.narani at xilinx.com]
> Sent: Thursday, June 7, 2018 5:42 PM
> To: robh+dt at kernel.org; mark.rutland at arm.com; catalin.marinas at arm.com;
> will.deacon at arm.com; mdf at kernel.org; stefan.krsmanovic at aggios.com;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> mmc at vger.kernel.org; devicetree at vger.kernel.org;
> adrian.hunter at intel.com; michal.simek at xilinx.com; ulf.hansson at linaro.org
> Cc: Manish Narani <MNARANI@xilinx.com>
> Subject: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values
> from DT
>
> This patch adds support for reading Tap Delay values from Device Tree and
> write them via eemi calls. The macros containing these tap delay values are
> removed from the driver.
>
> Signed-off-by: Manish Narani <manish.narani@xilinx.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 131
> +++++++++++++++++++++++++++++++++++++
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-
> of-arasan.c
> index e3332a5..fc0fd01 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -36,6 +36,8 @@
>
> #define PHY_CLK_TOO_SLOW_HZ 400000
>
> +#define MMC_BANK2 0x2
> +
> /*
> * On some SoCs the syscon area has a feature where the upper 16-bits of
> * each 32-bit register act as a write mask for the lower 16-bits. This allows
> @@ -90,6 +92,10 @@ struct sdhci_arasan_data {
> struct sdhci_host *host;
> struct clk *clk_ahb;
> struct phy *phy;
> + u32 mio_bank;
> + u32 device_id;
> + u32 itapdly[MMC_TIMING_MMC_HS400 + 1];
> + u32 otapdly[MMC_TIMING_MMC_HS400 + 1];
> bool is_phy_on;
>
> bool has_cqe;
> @@ -160,11 +166,36 @@ static int sdhci_arasan_syscon_write(struct
> sdhci_host *host,
> return ret;
> }
>
> +/**
> + * arasan_zynqmp_set_tap_delay - Program the tap delays.
> + * @deviceid: Unique Id of device
> + * @itap_delay: Input Tap Delay
> + * @oitap_delay: Output Tap Delay
> + */
> +static void arasan_zynqmp_set_tap_delay(u8 deviceid, u8 itap_delay, u8
> +otap_delay) {
> + const struct zynqmp_eemi_ops *eemi_ops =
> zynqmp_pm_get_eemi_ops();
> + u32 node_id = (deviceid == 0) ? NODE_SD_0 : NODE_SD_1;
> +
> + if (!eemi_ops || !eemi_ops->ioctl)
> + return;
> +
> + if (itap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_INPUT, itap_delay, NULL);
> +
> + if (otap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_OUTPUT, otap_delay, NULL);
> }
> +
> static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int
> clock) {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> bool ctrl_phy = false;
> + u8 itap_delay;
> + u8 otap_delay;
>
> if (!IS_ERR(sdhci_arasan->phy)) {
> if (!sdhci_arasan->is_phy_on && clock <=
> PHY_CLK_TOO_SLOW_HZ) { @@ -200,6 +231,16 @@ static void
> sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
> }
> }
>
> + if (host->version >= SDHCI_SPEC_300) {
> + if ((host->timing != MMC_TIMING_LEGACY) &&
> + (host->timing != MMC_TIMING_UHS_SDR12)) {
> + itap_delay = sdhci_arasan->itapdly[host->timing];
> + otap_delay = sdhci_arasan->otapdly[host->timing];
> + arasan_zynqmp_set_tap_delay(sdhci_arasan-
> >device_id,
> + itap_delay, otap_delay);
> + }
> + }
> +
> if (ctrl_phy && sdhci_arasan->is_phy_on) {
> phy_power_off(sdhci_arasan->phy);
> sdhci_arasan->is_phy_on = false;
> @@ -456,6 +497,7 @@ static const struct of_device_id
> sdhci_arasan_of_match[] = {
> { .compatible = "arasan,sdhci-8.9a" },
> { .compatible = "arasan,sdhci-5.1" },
> { .compatible = "arasan,sdhci-4.9a" },
> + { .compatible = "xlnx,zynqmp-8.9a" },
>
> { /* sentinel */ }
> };
> @@ -641,6 +683,74 @@ static void sdhci_arasan_unregister_sdclk(struct
> device *dev)
> of_clk_del_provider(dev->of_node);
> }
>
> +/**
> + * arasan_zynqmp_dt_parse_tap_delays - Read Tap Delay values from DT
> + *
> + * Called at initialization to parse the values of Tap Delays.
> + *
> + * @dev: Pointer to our struct device.
> + */
> +static void arasan_zynqmp_dt_parse_tap_delays(struct device *dev) {
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> + struct device_node *np = dev->of_node;
> +
> + of_property_read_u32(np, "xlnx,itap_delay_sd_hsd",
> + &sdhci_arasan->itapdly[MMC_TIMING_SD_HS]);
> + of_property_read_u32(np, "xlnx,otap_delay_sd_hsd",
> + &sdhci_arasan->otapdly[MMC_TIMING_SD_HS]);
> + of_property_read_u32(np, "xlnx,itap_delay_sdr25",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_UHS_SDR25]);
> + of_property_read_u32(np, "xlnx,otap_delay_sdr25",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_UHS_SDR25]);
> + of_property_read_u32(np, "xlnx,itap_delay_sdr50",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_UHS_SDR50]);
> + of_property_read_u32(np, "xlnx,otap_delay_sdr50",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_UHS_SDR50]);
> + of_property_read_u32(np, "xlnx,itap_delay_sd_ddr50",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_UHS_DDR50]);
> + of_property_read_u32(np, "xlnx,otap_delay_sd_ddr50",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_UHS_DDR50]);
> + of_property_read_u32(np, "xlnx,itap_delay_mmc_hsd",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_MMC_HS]);
> + of_property_read_u32(np, "xlnx,otap_delay_mmc_hsd",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_MMC_HS]);
> + of_property_read_u32(np, "xlnx,itap_delay_mmc_ddr50",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_MMC_DDR52]);
> + of_property_read_u32(np, "xlnx,otap_delay_mmc_ddr50",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_MMC_DDR52]);
> + if (sdhci_arasan->mio_bank == MMC_BANK2) {
> + of_property_read_u32(np,
> + "xlnx,itap_delay_sdr104_b2",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_UHS_SDR104]);
> + of_property_read_u32(np,
> + "xlnx,otap_delay_sdr104_b2",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_UHS_SDR104]);
> + of_property_read_u32(np,
> + "xlnx,itap_delay_mmc_hs200_b2",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_MMC_HS200]);
> + of_property_read_u32(np,
> + "xlnx,otap_delay_mmc_hs200_b2",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_MMC_HS200]);
> + } else {
> + of_property_read_u32(np,
> + "xlnx,itap_delay_sdr104_b0",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_UHS_SDR104]);
> + of_property_read_u32(np,
> + "xlnx,otap_delay_sdr104_b0",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_UHS_SDR104]);
> + of_property_read_u32(np,
> + "xlnx,itap_delay_mmc_hs200_b0",
> + &sdhci_arasan-
> >itapdly[MMC_TIMING_MMC_HS200]);
> + of_property_read_u32(np,
> + "xlnx,otap_delay_mmc_hs200_b0",
> + &sdhci_arasan-
> >otapdly[MMC_TIMING_MMC_HS200]);
> + }
> +}
> +
> static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan) {
> struct sdhci_host *host = sdhci_arasan->host; @@ -776,6 +886,27
> @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> goto unreg_clk;
> }
>
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "xlnx,zynqmp-8.9a")) {
> + ret = of_property_read_u32(pdev->dev.of_node,
> + "xlnx,mio_bank",
> + &sdhci_arasan->mio_bank);
> + if (ret < 0) {
> + dev_err(&pdev->dev,
> + "\"xlnx,mio_bank \" property is missing.\n");
> + goto clk_disable_all;
> + }
> + ret = of_property_read_u32(pdev->dev.of_node,
> + "xlnx,device_id",
> + &sdhci_arasan->device_id);
> + if (ret < 0) {
> + dev_err(&pdev->dev,
> + "\"xlnx,device_id \" property is missing.\n");
> + goto clk_disable_all;
> + }
> + arasan_zynqmp_dt_parse_tap_delays(&pdev->dev);
> + }
> +
> sdhci_arasan->phy = ERR_PTR(-ENODEV);
> if (of_device_is_compatible(pdev->dev.of_node,
> "arasan,sdhci-5.1")) {
> --
> 2.7.4
^ permalink raw reply
* [PATCH] gpio: uniphier: set legitimate irq trigger type in .to_irq hook
From: Masahiro Yamada @ 2018-06-14 5:27 UTC (permalink / raw)
To: linux-arm-kernel
If a GPIO chip is a part of a hierarchy IRQ domain, there is no
way to specify the trigger type when gpio(d)_to_irq() allocates an
interrupt on-the-fly.
Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes
an error in the .alloc() hook of the parent domain.
(drivers/irq/irq-uniphier-aidet.c)
Even if we change irq-uniphier-aidet.c to accept the NONE type,
GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic:
Loudly complain about the use of IRQ_TYPE_NONE").
Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq
is allocated. irq_set_irq_type() will override it when the irq is
really requested.
Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
Reported-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
drivers/gpio/gpio-uniphier.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
index d3cf950..58faeb1 100644
--- a/drivers/gpio/gpio-uniphier.c
+++ b/drivers/gpio/gpio-uniphier.c
@@ -181,7 +181,11 @@ static int uniphier_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
fwspec.fwnode = of_node_to_fwnode(chip->parent->of_node);
fwspec.param_count = 2;
fwspec.param[0] = offset - UNIPHIER_GPIO_IRQ_OFFSET;
- fwspec.param[1] = IRQ_TYPE_NONE;
+ /*
+ * IRQ_TYPE_NONE is rejected by the parent irq domain. Set LEVEL_HIGH
+ * temporarily. Anyway, ->irq_set_type() will override it later.
+ */
+ fwspec.param[1] = IRQ_TYPE_LEVEL_HIGH;
return irq_create_fwspec_mapping(&fwspec);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm: dts: Update AST2400 device-tree
From: Benjamin Herrenschmidt @ 2018-06-14 3:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614035605.25286-1-benh@kernel.crashing.org>
Add the missing node for the CVIC (the coprocessor interrupt
controller) and add a label to the SRAM node so it can be
referenced from the board device-tree file.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 75df1573380e..435595534ec4 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -92,6 +92,11 @@
reg = <0x1e6c0080 0x80>;
};
+ cvic: interrupt-controller at 1e6c2000 {
+ compatible = "aspeed,ast2400-cvic";
+ reg = <0x1e6c2000 0x80>;
+ };
+
mac0: ethernet at 1e660000 {
compatible = "aspeed,ast2400-mac", "faraday,ftgmac100";
reg = <0x1e660000 0x180>;
@@ -161,7 +166,7 @@
status = "disabled";
};
- sram at 1e720000 {
+ sram: sram at 1e720000 {
compatible = "mmio-sram";
reg = <0x1e720000 0x8000>; // 32K
};
--
2.17.0
^ permalink raw reply related
* [PATCH 2/3] arm: dts: Update AST2500 device-tree
From: Benjamin Herrenschmidt @ 2018-06-14 3:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614035605.25286-1-benh@kernel.crashing.org>
Add the missing node for the CVIC (the coprocessor interrupt
controller) and add a label to the SRAM node so it can be
referenced from the board device-tree file.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-g5.dtsi | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 17f2714d18a7..251664984398 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -127,6 +127,11 @@
reg = <0x1e6c0080 0x80>;
};
+ cvic: interrupt-controller at 1e6c2000 {
+ compatible = "aspeed,ast2400-cvic";
+ reg = <0x1e6c2000 0x80>;
+ };
+
mac0: ethernet at 1e660000 {
compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e660000 0x180>;
@@ -211,7 +216,7 @@
status = "disabled";
};
- sram at 1e720000 {
+ sram: sram at 1e720000 {
compatible = "mmio-sram";
reg = <0x1e720000 0x9000>; // 36K
};
--
2.17.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox