Hi Phil,

[add Marcel to CC]

Phil Elwell [off-list ref] hat am 14. Dezember 2018 um 22:49 geschrieben:


Hi Stefan,

On 15/11/2018 23:00, Stefan Wahren wrote:

quoted

The Raspberry Pi 3 A+ is similar to the Pi 3 B+ but has only 512 MB RAM,
1 USB 2.0 port and no Ethernet.

Signed-off-by: Stefan Wahren <redacted>
---
  arch/arm/boot/dts/Makefile                 |   1 +
  arch/arm/boot/dts/bcm2837-rpi-3-a-plus.dts | 107 +++++++++++++++++++++++++++++
  2 files changed, 108 insertions(+)
  create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3-a-plus.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b0e966d..15bbd0d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile

@@ -79,6 +79,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
  	bcm2835-rpi-a-plus.dtb \
  	bcm2835-rpi-cm1-io1.dtb \
  	bcm2836-rpi-2-b.dtb \
+	bcm2837-rpi-3-a-plus.dtb \
  	bcm2837-rpi-3-b.dtb \
  	bcm2837-rpi-3-b-plus.dtb \
  	bcm2837-rpi-cm3-io3.dtb \

diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-a-plus.dts b/arch/arm/boot/dts/bcm2837-rpi-3-a-plus.dts
new file mode 100644
index 0000000..75785dd
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-a-plus.dts

@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2837.dtsi"
+#include "bcm2836-rpi.dtsi"
+#include "bcm283x-rpi-usb-host.dtsi"
+
+/ {
+	compatible = "raspberrypi,3-model-a-plus", "brcm,bcm2837";
+	model = "Raspberry Pi 3 Model A+";
+
+	chosen {
+		/* 8250 auxiliary UART instead of pl011 */
+		stdout-path = "serial1:115200n8";
+	};
+
+	memory {
+		reg = <0 0x20000000>;
+	};
+
+	leds {
+		act {
+			gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
+		};
+
+		pwr {
+			label = "PWR";
+			gpios = <&expgpio 2 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	wifi_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&expgpio 1 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&firmware {
+	expgpio: gpio {
+		compatible = "raspberrypi,firmware-gpio";
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names = "BT_ON",
+				  "WL_ON",
+				  "STATUS_LED",
+				  "",
+				  "",
+				  "CAM_GPIO0",
+				  "CAM_GPIO1",
+				  "";
+		status = "okay";
+	};
+};
+
+&hdmi {
+	hpd-gpios = <&gpio 28 GPIO_ACTIVE_LOW>;
+};
+
+&pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm0_gpio40 &pwm1_gpio41>;
+	status = "okay";
+};
+
+/* SDHCI is used to control the SDIO for wireless */
+&sdhci {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_gpio34>;
+	status = "okay";
+	bus-width = <4>;
+	non-removable;
+	mmc-pwrseq = <&wifi_pwrseq>;
+
+	brcmf: wifi@1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+	};
+};
+
+/* SDHOST is used to drive the SD card */
+&sdhost {
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdhost_gpio48>;
+	status = "okay";
+	bus-width = <4>;
+};
+
+/* uart0 communicates with the BT module */
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_ctsrts_gpio30 &uart0_gpio32 &gpclk2_gpio43>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		max-speed = <2000000>;
+		shutdown-gpios = <&expgpio 0 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+/* uart1 is mapped to the pin header */
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_gpio14>;
+	status = "okay";
+};

Although this DTS originally looked correct to me, I learnt yesterday from
poring over the schematic that, due to routing congestion around the WiFi combo
chip, the 3A+ drives the BT_ON pin from the same source - GPIO1 on the expander -
as the WL_ON pin. GPIO0 on the expander is not connected. This means that the
shutdown-gpios property of the bluetooth node is incorrect.

thanks for pointing out. I tested this on my RPi 3 A+ with some gpio-exp hacking and can confirm this behavior.

I don't know the reason for this design decision, but both drivers (wifi and BT) can't share the control of GPIO1. Additionally we can't give the control to only one of them, because the other one could be unexpectedly tied into reset. So i decided to drop the reset control of both ones with all the consequences (no power management, default baudrate usage of BT) in V4 of this series.

Furthermore, I've been told that the current production 3B+ is the same in this
regard - a change since the 3B+ schematic with which the firmware support was
developed - so the 3B+ DTS should ideally also be changed, although leaving it
as it stands is likely to make little practical difference.

Oh dear. I think there is no hurry for changing 3B+. So i would like to wait until this series has been applied.

Stefan

Phil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel