[PATCH 0/3] ARM: dts: rk3288 Tinker Board (S) updates

[PATCH 0/3] ARM: dts: rk3288 Tinker Board (S) updates

[David Summers]

Find in the following patches 3 sets of updates to the rk3288 ASUS
Tinker Board (S) device tree. The patches consist of:

       1) Changes to sd card, to remove error
       2) Add WiFi to the device tree
       3) Add an outline for Bluetooth to the device tree

The patches have been developed by both Stefan and myself, and hence
have both our sign off.

The patches have been extensivly tested by TheSaint on ArchLinux Arm
Forum, details:

https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=90

Each patch has more details on what is covered.

David.


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

[PATCH 1/3] ARM: dts: rk3288 Tinker Board (S) sdcard changes

[David Summers]

This patch makes some minor changes to how the sd card is
described in the device tree for the ASUS Tinker Board (S). In
particular on the Tinker Board S, when booted from the eMMC, and with
no card in the sd slot, and the log has endless messages about not
being able to detect the card.

Several methods to remove this error have been tried, the only one
that works is the broken-cd and so that is what is applied here.

Alas the ASUS schematic is not clear enough to indicate if the card
detect is wired up to the cpu, the schematic does not show internal
wiring on the Tinker Board!

Now this error didn't show up on the Tinker Board, as that machine
only boots where there is a sd card installed. However as the TB and
TBS are so similar it is expected that the Tinker Board also doesn't
have a functioning card detect. Hence the change here is made to the
dtsi file, so it applies to both TB and TBS.

The disable-wp is also removed, it doesnt seem needed on the micro
sdcard slots, and without thisn the card can still be written
to. Hence this flag is also removed.

Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
---
 arch/arm/boot/dts/rk3288-tinker.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
index 2b38075a2917..fceaeed44e34 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
+++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
@@ -432,9 +432,7 @@
 	bus-width = <4>;
 	cap-mmc-highspeed;
 	cap-sd-highspeed;
-	card-detect-delay = <200>;
-	disable-wp;			/* wp not hooked up */
+	broken-cd;
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
 	status = "okay";
-- 
beagleboard@davidjohnsummers.uk


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

Re: [PATCH 1/3] ARM: dts: rk3288 Tinker Board (S) sdcard changes

[Robin Murphy]

Hi David,

On 2019-02-17 12:15 pm, David Summers wrote:
> This patch makes some minor changes to how the sd card is
> described in the device tree for the ASUS Tinker Board (S). In
> particular on the Tinker Board S, when booted from the eMMC, and with
> no card in the sd slot, and the log has endless messages about not
> being able to detect the card.
> 
> Several methods to remove this error have been tried, the only one
> that works is the broken-cd and so that is what is applied here.

I don't have a Tinker Board, but the symptom sounds instantly familiar 
from hacking on another RK3288 box; have you tried adding 
"regulator-always-on" to the vccio_sd regulator?

With the reference design (which I would assume the Tinker Board has no 
reason to deviate from in this area), the CD pin is either wired 
directly to the SoC with no external pull-up, or explicitly pulled up to 
VCCIO_SD. Either way, when the dwmmc driver probes and discovers there 
is no card present, it sets the currently-unnecessary vqmmc-supply as 
inactive, and thus the regulator core turns off VCCIO_SD entirely. 
Unfortunately, this removes the voltage from the entire I/O domain 
including the internal pull-up, which ends up leaving the CD pin 
floating and generating spurious events.

Robin.

> Alas the ASUS schematic is not clear enough to indicate if the card
> detect is wired up to the cpu, the schematic does not show internal
> wiring on the Tinker Board!
> 
> Now this error didn't show up on the Tinker Board, as that machine
> only boots where there is a sd card installed. However as the TB and
> TBS are so similar it is expected that the Tinker Board also doesn't
> have a functioning card detect. Hence the change here is made to the
> dtsi file, so it applies to both TB and TBS.
> 
> The disable-wp is also removed, it doesnt seem needed on the micro
> sdcard slots, and without thisn the card can still be written
> to. Hence this flag is also removed.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> ---
>   arch/arm/boot/dts/rk3288-tinker.dtsi | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index 2b38075a2917..fceaeed44e34 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -432,9 +432,7 @@
>   	bus-width = <4>;
>   	cap-mmc-highspeed;
>   	cap-sd-highspeed;
> -	card-detect-delay = <200>;
> -	disable-wp;			/* wp not hooked up */
> +	broken-cd;
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>   	status = "okay";
> 

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

Re: [PATCH 1/3] ARM: dts: rk3288 Tinker Board (S) sdcard changes

[David Summers]

On 17/02/2019 14:00, Robin Murphy wrote:
> Hi David,
>
> On 2019-02-17 12:15 pm, David Summers wrote:
>> This patch makes some minor changes to how the sd card is
>> described in the device tree for the ASUS Tinker Board (S). In
>> particular on the Tinker Board S, when booted from the eMMC, and with
>> no card in the sd slot, and the log has endless messages about not
>> being able to detect the card.
>>
>> Several methods to remove this error have been tried, the only one
>> that works is the broken-cd and so that is what is applied here.
>
> I don't have a Tinker Board, but the symptom sounds instantly familiar 
> from hacking on another RK3288 box; have you tried adding 
> "regulator-always-on" to the vccio_sd regulator?
>
> With the reference design (which I would assume the Tinker Board has 
> no reason to deviate from in this area), the CD pin is either wired 
> directly to the SoC with no external pull-up, or explicitly pulled up 
> to VCCIO_SD. Either way, when the dwmmc driver probes and discovers 
> there is no card present, it sets the currently-unnecessary 
> vqmmc-supply as inactive, and thus the regulator core turns off 
> VCCIO_SD entirely. Unfortunately, this removes the voltage from the 
> entire I/O domain including the internal pull-up, which ends up 
> leaving the CD pin floating and generating spurious events.
>
> Robin.

Hi Robin,

An interesting suggestion - no it hasn't been tried to always set the 
vccio_sd regulator on. Will give it a go on ArchLinux Arm.

I guess this would explain why the Tinker Board booting from sd doesn't 
see the error, as its enabled probably in uboot and then keeps working.

IIRC though, if booting the TBS from eMMC, then inserting an sd card and 
the errors stop. I guess this wouldn't happen if the power wasn't applied?

I guess also that "regulator-always-on" is a quick test - but that for 
submission to kernel it would be better done via "mmc-pwrseq-simple"?

Anyway I set up a test - so we can confirm this.

David.


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

Re: [PATCH 1/3] ARM: dts: rk3288 Tinker Board (S) sdcard changes

[Robin Murphy]

On 17/02/2019 15:19, David Summers wrote:
> On 17/02/2019 14:00, Robin Murphy wrote:
>> Hi David,
>>
>> On 2019-02-17 12:15 pm, David Summers wrote:
>>> This patch makes some minor changes to how the sd card is
>>> described in the device tree for the ASUS Tinker Board (S). In
>>> particular on the Tinker Board S, when booted from the eMMC, and with
>>> no card in the sd slot, and the log has endless messages about not
>>> being able to detect the card.
>>>
>>> Several methods to remove this error have been tried, the only one
>>> that works is the broken-cd and so that is what is applied here.
>>
>> I don't have a Tinker Board, but the symptom sounds instantly familiar 
>> from hacking on another RK3288 box; have you tried adding 
>> "regulator-always-on" to the vccio_sd regulator?
>>
>> With the reference design (which I would assume the Tinker Board has 
>> no reason to deviate from in this area), the CD pin is either wired 
>> directly to the SoC with no external pull-up, or explicitly pulled up 
>> to VCCIO_SD. Either way, when the dwmmc driver probes and discovers 
>> there is no card present, it sets the currently-unnecessary 
>> vqmmc-supply as inactive, and thus the regulator core turns off 
>> VCCIO_SD entirely. Unfortunately, this removes the voltage from the 
>> entire I/O domain including the internal pull-up, which ends up 
>> leaving the CD pin floating and generating spurious events.
>>
>> Robin.
> 
> Hi Robin,
> 
> An interesting suggestion - no it hasn't been tried to always set the 
> vccio_sd regulator on. Will give it a go on ArchLinux Arm.
> 
> I guess this would explain why the Tinker Board booting from sd doesn't 
> see the error, as its enabled probably in uboot and then keeps working.
> 
> IIRC though, if booting the TBS from eMMC, then inserting an sd card and 
> the errors stop. I guess this wouldn't happen if the power wasn't applied?

That's the fun part of this scenario - the presence of a card is 
unambiguous, it's only the absence of one which depends on the pull-up 
state, so whenever as a card is inserted everything does work correctly. 
  Assuming they are the same errors I was seeing, they're from the 
driver *thinking* a card is inserted due to CD floating low, then 
failing to communicate with it, after which it powers down the I/O 
interface again and the whole cycle begins anew.

> I guess also that "regulator-always-on" is a quick test - but that for 
> submission to kernel it would be better done via "mmc-pwrseq-simple"?

No, it's a valid description of the hardware to say "disabling this 
regulator makes something fail to work as expected" if that is truly the 
case. Besides, pwrseq is about how to initialise a detected present 
card, not how to correctly detect that presence in the first place.

> Anyway I set up a test - so we can confirm this.

Great - there is of course still the possibility that the pin really 
isn't wired up at all, in which case ignoring CD and taking the CPU 
overhead of polling would be the only option, but the vendor DT doesn't 
have any signs to suggest that's the case, and makes me lean more 
towards the pull-up issue.

Robin.

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

Re: [PATCH 1/3] ARM: dts: rk3288 Tinker Board (S) sdcard changes

[David Summers]

On 18/02/2019 11:54, Robin Murphy wrote:
> On 17/02/2019 15:19, David Summers wrote:
>> On 17/02/2019 14:00, Robin Murphy wrote:
>>> Hi David,
>>>
>>> On 2019-02-17 12:15 pm, David Summers wrote:
>>>> This patch makes some minor changes to how the sd card is
>>>> described in the device tree for the ASUS Tinker Board (S). In
>>>> particular on the Tinker Board S, when booted from the eMMC, and with
>>>> no card in the sd slot, and the log has endless messages about not
>>>> being able to detect the card.
>>>>
>>>> Several methods to remove this error have been tried, the only one
>>>> that works is the broken-cd and so that is what is applied here.
>>>
>>> I don't have a Tinker Board, but the symptom sounds instantly 
>>> familiar from hacking on another RK3288 box; have you tried adding 
>>> "regulator-always-on" to the vccio_sd regulator?
>>>
>>> With the reference design (which I would assume the Tinker Board has 
>>> no reason to deviate from in this area), the CD pin is either wired 
>>> directly to the SoC with no external pull-up, or explicitly pulled 
>>> up to VCCIO_SD. Either way, when the dwmmc driver probes and 
>>> discovers there is no card present, it sets the 
>>> currently-unnecessary vqmmc-supply as inactive, and thus the 
>>> regulator core turns off VCCIO_SD entirely. Unfortunately, this 
>>> removes the voltage from the entire I/O domain including the 
>>> internal pull-up, which ends up leaving the CD pin floating and 
>>> generating spurious events.
>>>
>>> Robin.
>>
>> Hi Robin,
>>
>> An interesting suggestion - no it hasn't been tried to always set the 
>> vccio_sd regulator on. Will give it a go on ArchLinux Arm.
>>
>> I guess this would explain why the Tinker Board booting from sd 
>> doesn't see the error, as its enabled probably in uboot and then 
>> keeps working.
>>
>> IIRC though, if booting the TBS from eMMC, then inserting an sd card 
>> and the errors stop. I guess this wouldn't happen if the power wasn't 
>> applied?
>
> That's the fun part of this scenario - the presence of a card is 
> unambiguous, it's only the absence of one which depends on the pull-up 
> state, so whenever as a card is inserted everything does work 
> correctly.  Assuming they are the same errors I was seeing, they're 
> from the driver *thinking* a card is inserted due to CD floating low, 
> then failing to communicate with it, after which it powers down the 
> I/O interface again and the whole cycle begins anew.
>
>> I guess also that "regulator-always-on" is a quick test - but that 
>> for submission to kernel it would be better done via 
>> "mmc-pwrseq-simple"?
>
> No, it's a valid description of the hardware to say "disabling this 
> regulator makes something fail to work as expected" if that is truly 
> the case. Besides, pwrseq is about how to initialise a detected 
> present card, not how to correctly detect that presence in the first 
> place.
>
>> Anyway I set up a test - so we can confirm this.
>
> Great - there is of course still the possibility that the pin really 
> isn't wired up at all, in which case ignoring CD and taking the CPU 
> overhead of polling would be the only option, but the vendor DT 
> doesn't have any signs to suggest that's the case, and makes me lean 
> more towards the pull-up issue.
>
> Robin.

Robin,

Heard back from the user on ArchLinux Arm who has a tinker Board S, he 
tested your solution, and it worked.

Excellent, as it means the CPU won't have to poll the card!

I'll probably add both "regulator-always-on;" and "regulator-boot-on;", 
as reading the regulator documentation, and the Tinker Board boots from 
sd card, and the TinkerBoard S has the option of booting from the sd 
card - we can be fairly sure that uboot has already enabled the power 
supply.

So best to withdraw this patch. I'll do a fresh one, when I get time - 
probably the weekend ...

Thanks for the help, I should have though of looking beyond sdmmc part 
of device tree. So we are grateful that you remembered your solution 
when you had the problem on another board.

Regards,

David


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

Re: [PATCH 1/3] ARM: dts: rk3288 Tinker Board (S) sdcard changes

[Stefan Wahren]

Hi David,

we need a better patch subject here e.g.

ARM: dts: rk3288-tinker: Fix SD card detection

plus a Fixes tag for the commit we want to fix.

> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
> 
> 
> This patch makes some minor changes to how the sd card is
> described in the device tree for the ASUS Tinker Board (S). In
> particular on the Tinker Board S, when booted from the eMMC, and with
> no card in the sd slot, and the log has endless messages about not
> being able to detect the card.
> 
> Several methods to remove this error have been tried, the only one
> that works is the broken-cd and so that is what is applied here.
> 
> Alas the ASUS schematic is not clear enough to indicate if the card
> detect is wired up to the cpu, the schematic does not show internal
> wiring on the Tinker Board!
> 
> Now this error didn't show up on the Tinker Board, as that machine
> only boots where there is a sd card installed. However as the TB and
> TBS are so similar it is expected that the Tinker Board also doesn't
> have a functioning card detect. Hence the change here is made to the
> dtsi file, so it applies to both TB and TBS.
> 
> The disable-wp is also removed, it doesnt seem needed on the micro
> sdcard slots, and without thisn the card can still be written
> to. Hence this flag is also removed.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> ---
>  arch/arm/boot/dts/rk3288-tinker.dtsi | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index 2b38075a2917..fceaeed44e34 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -432,9 +432,7 @@
>  	bus-width = <4>;
>  	cap-mmc-highspeed;
>  	cap-sd-highspeed;
> -	card-detect-delay = <200>;
> -	disable-wp;			/* wp not hooked up */

I think we should keep as long as it doesn't hurt.

> +	broken-cd;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>  	status = "okay";
> -- 
> beagleboard@davidjohnsummers.uk
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Re: [PATCH 1/3] ARM: dts: rk3288 Tinker Board (S) sdcard changes

[David Summers]

Thanks Stefan,

If the change to make sure that power is set to vccio_sd work, and so I 
have to do another patch, I'll make sure I update.

David.

On 17/02/2019 20:29, Stefan Wahren wrote:
> Hi David,
>
> we need a better patch subject here e.g.
>
> ARM: dts: rk3288-tinker: Fix SD card detection
>
> plus a Fixes tag for the commit we want to fix.
>
>> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
>>
>>
>> This patch makes some minor changes to how the sd card is
>> described in the device tree for the ASUS Tinker Board (S). In
>> particular on the Tinker Board S, when booted from the eMMC, and with
>> no card in the sd slot, and the log has endless messages about not
>> being able to detect the card.
>>
>> Several methods to remove this error have been tried, the only one
>> that works is the broken-cd and so that is what is applied here.
>>
>> Alas the ASUS schematic is not clear enough to indicate if the card
>> detect is wired up to the cpu, the schematic does not show internal
>> wiring on the Tinker Board!
>>
>> Now this error didn't show up on the Tinker Board, as that machine
>> only boots where there is a sd card installed. However as the TB and
>> TBS are so similar it is expected that the Tinker Board also doesn't
>> have a functioning card detect. Hence the change here is made to the
>> dtsi file, so it applies to both TB and TBS.
>>
>> The disable-wp is also removed, it doesnt seem needed on the micro
>> sdcard slots, and without thisn the card can still be written
>> to. Hence this flag is also removed.
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> ---
>>   arch/arm/boot/dts/rk3288-tinker.dtsi | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> index 2b38075a2917..fceaeed44e34 100644
>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> @@ -432,9 +432,7 @@
>>   	bus-width = <4>;
>>   	cap-mmc-highspeed;
>>   	cap-sd-highspeed;
>> -	card-detect-delay = <200>;
>> -	disable-wp;			/* wp not hooked up */
> I think we should keep as long as it doesn't hurt.
>
>> +	broken-cd;
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>>   	status = "okay";
>> -- 
>> beagleboard@davidjohnsummers.uk
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



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

[PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[David Summers]

This patch adds the wifi to the ASUS Tinker Board (S) machines.

Unfortunatly neither the Tinker Board nor the Tinker Board S schematic
indicate how the WiFi is wired up on these devices. The WiFi is
provided by the RTL8723BS device, that has sdio WiFi and UART
Bluetooth. This patch just adds the WiFi interface.

With no schematic, most of the wiring has been derived from the ASUS
patch to Debian:

https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678

In conjunction with the pin out of the RTL8723BS device:

http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf

The only unusual part is that to bring the card up, both the pins
RK_PD3 and RK_PD4 need to be pulled. Why this needs to be done is not
clear, best explaination is that they are connected to the RTL8723BS
pins WL_DIS# and BT_DIS#, which the data sheet vaguely says:

Shared with GPIO9 This Pin Can Externally Shutdown the RTL8723BS WLAN
function when BT_DISn is Pulled Low. When this pin deasserted, SDIO
interface will be disabled. This pin can also support the WLAN Ra
dio-off function with host interface remaining connected.

Anyway extensive testing the TheSaint on ArchLinux Arm Forum 

https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=120#p60548

Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/rk3288-tinker.dtsi | 39 +++++++++++++++++++++++++---
 1 file changed, 36 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
index fceaeed44e34..e1796f340eef 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
+++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
@@ -3,8 +3,9 @@
  * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
  */
 
 #include "rk3288.dtsi"
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clock/rockchip,rk808.h>
 
 / {
 	chosen {
@@ -98,6 +97,15 @@
 		startup-delay-us = <100000>;
 		vin-supply = <&vcc_io>;
 	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk808 RK808_CLKOUT1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable>;
+		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
+	};
 };
 
 &cpu0 {
@@ -337,8 +345,8 @@
 
 &io_domains {
 	status = "okay";
-
 	sdcard-supply = <&vccio_sd>;
+	wifi-supply = <&vcc_18>;
 };
 
 &pinctrl {
@@ -417,6 +425,12 @@
 			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
 	};
+
+	sdio {
+		wifi_enable: wifi-enable {
+			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
 };
 
 &pwm0 {
@@ -440,6 +454,25 @@
 	vqmmc-supply = <&vccio_sd>;
 };
 
+&sdio0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
+	max-frequency = <50000000>;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	sd-uhs-sdr50;
+	sd-uhs-ddr50;
+	vmmc-supply = <&vcc_io>;
+	vqmmc-supply = <&vcc_18>;
+	status = "okay";
+};
+
 &tsadc {
 	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
 	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
-- 
beagleboard@davidjohnsummers.uk


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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[Tony McKahan]

A similar configuration has been in use on Armbian images since kernel
4.14, but not in a clean enough format for submission. I will test
this, but the only differences I see compared to ours are combination
of the mystery "chip_h" power domain/reset with the Wifi one and the
inclusion of sd_uhs_ddr50.

-Tony

On Sun, Feb 17, 2019 at 7:16 AM David Summers
<beagleboard@davidjohnsummers.uk> wrote:
>
> This patch adds the wifi to the ASUS Tinker Board (S) machines.
>
> Unfortunatly neither the Tinker Board nor the Tinker Board S schematic
> indicate how the WiFi is wired up on these devices. The WiFi is
> provided by the RTL8723BS device, that has sdio WiFi and UART
> Bluetooth. This patch just adds the WiFi interface.
>
> With no schematic, most of the wiring has been derived from the ASUS
> patch to Debian:
>
> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
>
> In conjunction with the pin out of the RTL8723BS device:
>
> http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
> http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf
>
> The only unusual part is that to bring the card up, both the pins
> RK_PD3 and RK_PD4 need to be pulled. Why this needs to be done is not
> clear, best explaination is that they are connected to the RTL8723BS
> pins WL_DIS# and BT_DIS#, which the data sheet vaguely says:
>
> Shared with GPIO9 This Pin Can Externally Shutdown the RTL8723BS WLAN
> function when BT_DISn is Pulled Low. When this pin deasserted, SDIO
> interface will be disabled. This pin can also support the WLAN Ra
> dio-off function with host interface remaining connected.
>
> Anyway extensive testing the TheSaint on ArchLinux Arm Forum
>
> https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=120#p60548
>
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>  arch/arm/boot/dts/rk3288-tinker.dtsi | 39 +++++++++++++++++++++++++---
>  1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index fceaeed44e34..e1796f340eef 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -3,8 +3,9 @@
>   * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
>   */
>
>  #include "rk3288.dtsi"
>  #include <dt-bindings/input/input.h>
> +#include <dt-bindings/clock/rockchip,rk808.h>
>
>  / {
>         chosen {
> @@ -98,6 +97,15 @@
>                 startup-delay-us = <100000>;
>                 vin-supply = <&vcc_io>;
>         };
> +
> +       sdio_pwrseq: sdio-pwrseq {
> +               compatible = "mmc-pwrseq-simple";
> +               clocks = <&rk808 RK808_CLKOUT1>;
> +               clock-names = "ext_clock";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&wifi_enable>;
> +               reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
> +       };
>  };
>
>  &cpu0 {
> @@ -337,8 +345,8 @@
>
>  &io_domains {
>         status = "okay";
> -
>         sdcard-supply = <&vccio_sd>;
> +       wifi-supply = <&vcc_18>;
>  };
>
>  &pinctrl {
> @@ -417,6 +425,12 @@
>                         rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
>                 };
>         };
> +
> +       sdio {
> +               wifi_enable: wifi-enable {
> +                       rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> +               };
> +       };
>  };
>
>  &pwm0 {
> @@ -440,6 +454,25 @@
>         vqmmc-supply = <&vccio_sd>;
>  };
>
> +&sdio0 {
> +       bus-width = <4>;
> +       cap-sd-highspeed;
> +       cap-sdio-irq;
> +       keep-power-in-suspend;
> +       mmc-pwrseq = <&sdio_pwrseq>;
> +       non-removable;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
> +       max-frequency = <50000000>;
> +       sd-uhs-sdr12;
> +       sd-uhs-sdr25;
> +       sd-uhs-sdr50;
> +       sd-uhs-ddr50;
> +       vmmc-supply = <&vcc_io>;
> +       vqmmc-supply = <&vcc_18>;
> +       status = "okay";
> +};
> +
>  &tsadc {
>         rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
>         rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> --
> beagleboard@davidjohnsummers.uk
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[David Summers]

On 17/02/2019 14:32, Tony McKahan wrote:
> A similar configuration has been in use on Armbian images since kernel
> 4.14, but not in a clean enough format for submission. I will test
> this, but the only differences I see compared to ours are combination
> of the mystery "chip_h" power domain/reset with the Wifi one and the
> inclusion of sd_uhs_ddr50.
>
> -Tony
>
> On Sun, Feb 17, 2019 at 7:16 AM David Summers
> <beagleboard@davidjohnsummers.uk> wrote:
>> This patch adds the wifi to the ASUS Tinker Board (S) machines.
>>
Tony, thanks for the interest in this and the Bluetooth RFC. To my mind 
it would be good if we could mainline an agreed solution. As much as 
anything doesn't make sense to me for Armbian and ArchLinux Arm to have 
independent solutions.

In the ArchLinux Arm  camp I'm not a fan of applying many patches to 
support a board, as much as anything it makes that board non generic - 
and so has to have its own hand crafted kernel. This to me isn't a good 
solution, so if possible prefer the pain of getting it mainlined.

Stefan Wahren has come up with a minimal patch to hci_h5 for bluetooth, 
that says the relevant properties can be read from the device tree. This 
means that acpi is no longer necessary. Thats currently out in testing.

Anyway would be good if Arch and Armbian could merge our efforts ...

Regards,

David.


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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[Tony McKahan]

Hello David,

  I agree, of course coordination is not always so simple, I did not
know Arch didn't have this configured yet.  As for patching, I agree,
but the Tinker has some... peculiarities, I am a hardware guy,
software is a passtime, so my code is not always perhaps up to
standard.  And I wasn't 100% on submitting changes to the device tree
based on a staging driver.  Most of my work has been absorbed into
https://github.com/Miouyouyou/RockMyy .  As for your approach, as I
said, the wifi is the same as I have except for the reset/enables and
the DDR50, which I didn't know the rtl8723bs supported.  BT I have no
in-kernel support for other than enabling the RTS pin to the device
tree, I handle it in user space for now.  I've been watching the
hci_h5 conversation, I'll look into testing these changes/options
tonight perhaps once I make sure our rockchip-dev recipes are still
valid with the newest RC, and can have them committed so others can
test.

Thank you,
-Tony

On Sun, Feb 17, 2019 at 10:55 AM David Summers
<beagleboard@davidjohnsummers.uk> wrote:
>
> On 17/02/2019 14:32, Tony McKahan wrote:
> > A similar configuration has been in use on Armbian images since kernel
> > 4.14, but not in a clean enough format for submission. I will test
> > this, but the only differences I see compared to ours are combination
> > of the mystery "chip_h" power domain/reset with the Wifi one and the
> > inclusion of sd_uhs_ddr50.
> >
> > -Tony
> >
> > On Sun, Feb 17, 2019 at 7:16 AM David Summers
> > <beagleboard@davidjohnsummers.uk> wrote:
> >> This patch adds the wifi to the ASUS Tinker Board (S) machines.
> >>
> Tony, thanks for the interest in this and the Bluetooth RFC. To my mind
> it would be good if we could mainline an agreed solution. As much as
> anything doesn't make sense to me for Armbian and ArchLinux Arm to have
> independent solutions.
>
> In the ArchLinux Arm  camp I'm not a fan of applying many patches to
> support a board, as much as anything it makes that board non generic -
> and so has to have its own hand crafted kernel. This to me isn't a good
> solution, so if possible prefer the pain of getting it mainlined.
>
> Stefan Wahren has come up with a minimal patch to hci_h5 for bluetooth,
> that says the relevant properties can be read from the device tree. This
> means that acpi is no longer necessary. Thats currently out in testing.
>
> Anyway would be good if Arch and Armbian could merge our efforts ...
>
> Regards,
>
> David.
>

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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[Stefan Wahren]

Hi,

> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 16:55 geschrieben:
> 
> 
> Stefan Wahren has come up with a minimal patch to hci_h5 for bluetooth, 
> that says the relevant properties can be read from the device tree. This 
> means that acpi is no longer necessary. Thats currently out in testing.
> 

this patch is more a quick hack in order to test bluetooth and don't have all features ( support for baud limitation, host-wake-up ). Also the patch [1] has only been compile tested (i don't have a Tinker Board), so please be aware. I created my patch before this series has been submitted, but Patch #3 doesn't work with this and needs changes.

Stefan

[1] - https://gist.github.com/lategoodbye/79bac99d4f1158a719a48ea3c45eb7f1

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

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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[David Summers]

Oh yes - didn't reply to the "chip_h", in asus patch called "chip_enable_h".

This is the <&gpio4 RK_PD3 GPIO_ACTIVE_LOW> IIRC. We could see that two 
pins were pulled. RK_PD3 and RK_PD4; but not knowing exactly why the 
pins were pulled, question is should they be separate?

We went the direction of putting both pins under wifi_enable.

Its not clear to me which is the least confusing, should wifi_enable 
need pulling two pins, or should there be an extra service 
"chip_enable_h" for the extra pin? Think our problem is we didn't see 
what "chip_enable_h" meant - the description doesn't help. Hence why we 
removed, and merged with wifi_enable ...

On 17/02/2019 14:32, Tony McKahan wrote:
> A similar configuration has been in use on Armbian images since kernel
> 4.14, but not in a clean enough format for submission. I will test
> this, but the only differences I see compared to ours are combination
> of the mystery "chip_h" power domain/reset with the Wifi one and the
> inclusion of sd_uhs_ddr50.
>
> -Tony
>
> On Sun, Feb 17, 2019 at 7:16 AM David Summers
> <beagleboard@davidjohnsummers.uk> wrote:
>> This patch adds the wifi to the ASUS Tinker Board (S) machines.
>>
>> Unfortunatly neither the Tinker Board nor the Tinker Board S schematic
>> indicate how the WiFi is wired up on these devices. The WiFi is
>> provided by the RTL8723BS device, that has sdio WiFi and UART
>> Bluetooth. This patch just adds the WiFi interface.
>>
>> With no schematic, most of the wiring has been derived from the ASUS
>> patch to Debian:
>>
>> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
>>
>> In conjunction with the pin out of the RTL8723BS device:
>>
>> http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
>> http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf
>>
>> The only unusual part is that to bring the card up, both the pins
>> RK_PD3 and RK_PD4 need to be pulled. Why this needs to be done is not
>> clear, best explaination is that they are connected to the RTL8723BS
>> pins WL_DIS# and BT_DIS#, which the data sheet vaguely says:
>>
>> Shared with GPIO9 This Pin Can Externally Shutdown the RTL8723BS WLAN
>> function when BT_DISn is Pulled Low. When this pin deasserted, SDIO
>> interface will be disabled. This pin can also support the WLAN Ra
>> dio-off function with host interface remaining connected.
>>
>> Anyway extensive testing the TheSaint on ArchLinux Arm Forum
>>
>> https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=120#p60548
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>
>> +
>> +       sdio_pwrseq: sdio-pwrseq {
>> +               compatible = "mmc-pwrseq-simple";
>> +               clocks = <&rk808 RK808_CLKOUT1>;
>> +               clock-names = "ext_clock";
>> +               pinctrl-names = "default";
>> +               pinctrl-0 = <&wifi_enable>;
>> +               reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
>> +       };
>>
>> +
>> +       sdio {
>> +               wifi_enable: wifi-enable {
>> +                       rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
>> +               };
>> +       };



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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[Stefan Wahren]

Hi David,

> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
> 
> 
> This patch adds the wifi to the ASUS Tinker Board (S) machines.
> 
> Unfortunatly neither the Tinker Board nor the Tinker Board S schematic
> indicate how the WiFi is wired up on these devices. The WiFi is
> provided by the RTL8723BS device, that has sdio WiFi and UART
> Bluetooth. This patch just adds the WiFi interface.
> 
> With no schematic, most of the wiring has been derived from the ASUS
> patch to Debian:
> 
> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
> 
> In conjunction with the pin out of the RTL8723BS device:
> 
> http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
> http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf
> 
> The only unusual part is that to bring the card up, both the pins
> RK_PD3 and RK_PD4 need to be pulled. Why this needs to be done is not
> clear, best explaination is that they are connected to the RTL8723BS
> pins WL_DIS# and BT_DIS#, which the data sheet vaguely says:
> 
> Shared with GPIO9 This Pin Can Externally Shutdown the RTL8723BS WLAN
> function when BT_DISn is Pulled Low. When this pin deasserted, SDIO
> interface will be disabled. This pin can also support the WLAN Ra
> dio-off function with host interface remaining connected.
> 
> Anyway extensive testing the TheSaint on ArchLinux Arm Forum 
> 
> https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=120#p60548
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>  arch/arm/boot/dts/rk3288-tinker.dtsi | 39 +++++++++++++++++++++++++---
>  1 file changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index fceaeed44e34..e1796f340eef 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -3,8 +3,9 @@
>   * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
>   */
>  
>  #include "rk3288.dtsi"
>  #include <dt-bindings/input/input.h>
> +#include <dt-bindings/clock/rockchip,rk808.h>
>  
>  / {
>  	chosen {
> @@ -98,6 +97,15 @@
>  		startup-delay-us = <100000>;
>  		vin-supply = <&vcc_io>;
>  	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&rk808 RK808_CLKOUT1>;
> +		clock-names = "ext_clock";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_enable>;

As i wrote at the Arch board it would be nice to keep the Asus comment here:

/*
 * On the module itself this is one of these (depending
 * on the actual card populated):
 * - SDIO_RESET_L_WL_REG_ON
 * - PDN (power down when low)
 */

> +		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
> +	};
>  };
>  
>  &cpu0 {
> @@ -337,8 +345,8 @@
>  
>  &io_domains {
>  	status = "okay";
> -

Please drop this whitespace change

>  	sdcard-supply = <&vccio_sd>;
> +	wifi-supply = <&vcc_18>;
>  };
>  
>  &pinctrl {
> @@ -417,6 +425,12 @@
>  			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
>  	};
> +
> +	sdio {
> +		wifi_enable: wifi-enable {
> +			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;

Please make a line break after the first pin definition

> +		};
> +	};
>  };
>  
>  &pwm0 {
> @@ -440,6 +454,25 @@
>  	vqmmc-supply = <&vccio_sd>;
>  };
>  
> +&sdio0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	keep-power-in-suspend;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
> +	max-frequency = <50000000>;
> +	sd-uhs-sdr12;
> +	sd-uhs-sdr25;
> +	sd-uhs-sdr50;
> +	sd-uhs-ddr50;

I'm okay with Tony's suggestion to remove sd-ush-ddr50.

> +	vmmc-supply = <&vcc_io>;
> +	vqmmc-supply = <&vcc_18>;
> +	status = "okay";
> +};
> +
>  &tsadc {
>  	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
>  	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> -- 
> beagleboard@davidjohnsummers.uk
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[Robin Murphy]

On 17/02/2019 20:43, Stefan Wahren wrote:
> Hi David,
> 
>> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
>>
>>
>> This patch adds the wifi to the ASUS Tinker Board (S) machines.
>>
>> Unfortunatly neither the Tinker Board nor the Tinker Board S schematic
>> indicate how the WiFi is wired up on these devices. The WiFi is
>> provided by the RTL8723BS device, that has sdio WiFi and UART
>> Bluetooth. This patch just adds the WiFi interface.
>>
>> With no schematic, most of the wiring has been derived from the ASUS
>> patch to Debian:
>>
>> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
>>
>> In conjunction with the pin out of the RTL8723BS device:
>>
>> http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
>> http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf
>>
>> The only unusual part is that to bring the card up, both the pins
>> RK_PD3 and RK_PD4 need to be pulled. Why this needs to be done is not
>> clear, best explaination is that they are connected to the RTL8723BS
>> pins WL_DIS# and BT_DIS#, which the data sheet vaguely says:
>>
>> Shared with GPIO9 This Pin Can Externally Shutdown the RTL8723BS WLAN
>> function when BT_DISn is Pulled Low. When this pin deasserted, SDIO
>> interface will be disabled. This pin can also support the WLAN Ra
>> dio-off function with host interface remaining connected.
>>
>> Anyway extensive testing the TheSaint on ArchLinux Arm Forum
>>
>> https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=120#p60548
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> ---
>>   arch/arm/boot/dts/rk3288-tinker.dtsi | 39 +++++++++++++++++++++++++---
>>   1 file changed, 36 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> index fceaeed44e34..e1796f340eef 100644
>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> @@ -3,8 +3,9 @@
>>    * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
>>    */
>>   
>>   #include "rk3288.dtsi"
>>   #include <dt-bindings/input/input.h>
>> +#include <dt-bindings/clock/rockchip,rk808.h>
>>   
>>   / {
>>   	chosen {
>> @@ -98,6 +97,15 @@
>>   		startup-delay-us = <100000>;
>>   		vin-supply = <&vcc_io>;
>>   	};
>> +
>> +	sdio_pwrseq: sdio-pwrseq {
>> +		compatible = "mmc-pwrseq-simple";
>> +		clocks = <&rk808 RK808_CLKOUT1>;
>> +		clock-names = "ext_clock";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&wifi_enable>;
> 
> As i wrote at the Arch board it would be nice to keep the Asus comment here:
> 
> /*
>   * On the module itself this is one of these (depending
>   * on the actual card populated):
>   * - SDIO_RESET_L_WL_REG_ON
>   * - PDN (power down when low)
>   */

Note that that comment (like many others) is merely copy-pasted from the 
Rockchip evaluation board DT, so is of dubious relevance here. If 
anything it becomes actively misleading when we already know that "this" 
is two pins on a module where nothing matches either of those names.

Robin.

>> +		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
>> +	};
>>   };
>>   
>>   &cpu0 {
>> @@ -337,8 +345,8 @@
>>   
>>   &io_domains {
>>   	status = "okay";
>> -
> 
> Please drop this whitespace change
> 
>>   	sdcard-supply = <&vccio_sd>;
>> +	wifi-supply = <&vcc_18>;
>>   };
>>   
>>   &pinctrl {
>> @@ -417,6 +425,12 @@
>>   			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
>>   		};
>>   	};
>> +
>> +	sdio {
>> +		wifi_enable: wifi-enable {
>> +			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> 
> Please make a line break after the first pin definition
> 
>> +		};
>> +	};
>>   };
>>   
>>   &pwm0 {
>> @@ -440,6 +454,25 @@
>>   	vqmmc-supply = <&vccio_sd>;
>>   };
>>   
>> +&sdio0 {
>> +	bus-width = <4>;
>> +	cap-sd-highspeed;
>> +	cap-sdio-irq;
>> +	keep-power-in-suspend;
>> +	mmc-pwrseq = <&sdio_pwrseq>;
>> +	non-removable;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
>> +	max-frequency = <50000000>;
>> +	sd-uhs-sdr12;
>> +	sd-uhs-sdr25;
>> +	sd-uhs-sdr50;
>> +	sd-uhs-ddr50;
> 
> I'm okay with Tony's suggestion to remove sd-ush-ddr50.
> 
>> +	vmmc-supply = <&vcc_io>;
>> +	vqmmc-supply = <&vcc_18>;
>> +	status = "okay";
>> +};
>> +
>>   &tsadc {
>>   	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
>>   	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
>> -- 
>> beagleboard@davidjohnsummers.uk
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[David Summers]

On 17/02/2019 20:43, Stefan Wahren wrote:
> Hi David,
>
>> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
>>
>>
>> +
>> +	sdio_pwrseq: sdio-pwrseq {
>> +		compatible = "mmc-pwrseq-simple";
>> +		clocks = <&rk808 RK808_CLKOUT1>;
>> +		clock-names = "ext_clock";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&wifi_enable>;
> As i wrote at the Arch board it would be nice to keep the Asus comment here:
>
> /*
>   * On the module itself this is one of these (depending
>   * on the actual card populated):
>   * - SDIO_RESET_L_WL_REG_ON
>   * - PDN (power down when low)
>   */
>
Sorry Stefan,

I'm with Robin on this one. Three reasons:

1) When you look at where ASUS added these comments:

https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678

They has only added RK_PD4 = 28

So at best to only applies to that change.

2) If you look at datasheet:

http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf

Then neither of the two pins are mentioned, and the comment is not helpful

3) Should dts have comments in? Over time I'm got to like git, and that 
you click on blame. That is what showed in post one that the comment 
only applied to one pin. To me blame point to the patch - and that 
usually gives more details. Its why I explain that we don't know what 
these two pins are attached to - this doesn't sound good, but actually 
its all we know. So it explains things. So I now think that dts should 
have very few comments in, and only where they *really* add something. 
In this case we don't know what the comment means ..


>> +		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
>> +	};
>>   };
>>   
>>   &cpu0 {
>> @@ -337,8 +345,8 @@
>>   
>>   &io_domains {
>>   	status = "okay";
>> -
> Please drop this whitespace change
Most {} in dts don't have white space line in - only between {} {}. So a 
white space line in the middle of a single {} is unusual. I can't see 
what its needed for, or what it makes clearer. So to me removing makes 
it more in line with everything else. If people are unhappy though I'll 
add the white line back in again.
>>   	sdcard-supply = <&vccio_sd>;
>> +	wifi-supply = <&vcc_18>;
>>   };
>>   
>>   &pinctrl {
>> @@ -417,6 +425,12 @@
>>   			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
>>   		};
>>   	};
>> +
>> +	sdio {
>> +		wifi_enable: wifi-enable {
>> +			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> Please make a line break after the first pin definition
Yes that makes sense

David


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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[Stefan Wahren]

Hi,

> David Summers <beagleboard@davidjohnsummers.uk> hat am 18. Februar 2019 um 21:26 geschrieben:
> 
> 
> On 17/02/2019 20:43, Stefan Wahren wrote:
> > Hi David,
> >
> >> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
> >>
> >>
> >> +
> >> +	sdio_pwrseq: sdio-pwrseq {
> >> +		compatible = "mmc-pwrseq-simple";
> >> +		clocks = <&rk808 RK808_CLKOUT1>;
> >> +		clock-names = "ext_clock";
> >> +		pinctrl-names = "default";
> >> +		pinctrl-0 = <&wifi_enable>;
> > As i wrote at the Arch board it would be nice to keep the Asus comment here:
> >
> > /*
> >   * On the module itself this is one of these (depending
> >   * on the actual card populated):
> >   * - SDIO_RESET_L_WL_REG_ON
> >   * - PDN (power down when low)
> >   */
> >
> Sorry Stefan,
> 
> I'm with Robin on this one.

i don't known anything about the reference design. So please ignore my comment.

> 
> 
> >> +		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
> >> +	};
> >>   };
> >>   
> >>   &cpu0 {
> >> @@ -337,8 +345,8 @@
> >>   
> >>   &io_domains {
> >>   	status = "okay";
> >> -
> > Please drop this whitespace change
> Most {} in dts don't have white space line in - only between {} {}. So a 
> white space line in the middle of a single {} is unusual. I can't see 
> what its needed for, or what it makes clearer. So to me removing makes 
> it more in line with everything else. If people are unhappy though I'll 
> add the white line back in again.

I don't have a problem with dropping the empy line in general. But it's unrelated to this change. So please make it a separate patch or drop it completely.

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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[David Summers]

And so synthesis on where we are on the WiFi patch for the Thinker Boards.

There have been very few comments, only really Tony McKahan from Armbian 
- where they apply a similar patch. Tony was going to test the patch, 
but we have heard nothing back. The patch has been tested on ArchLinux 
Arm, and found to work.

So with no further comments, I propose this is accepted as is. Heiko, 
let me know if you want me to respin this patch to apply cleanly after 
the sd card changes.

David.



On 17/02/2019 12:15, David Summers wrote:
> This patch adds the wifi to the ASUS Tinker Board (S) machines.
>
> Unfortunatly neither the Tinker Board nor the Tinker Board S schematic
> indicate how the WiFi is wired up on these devices. The WiFi is
> provided by the RTL8723BS device, that has sdio WiFi and UART
> Bluetooth. This patch just adds the WiFi interface.
>
> With no schematic, most of the wiring has been derived from the ASUS
> patch to Debian:
>
> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
>
> In conjunction with the pin out of the RTL8723BS device:
>
> http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
> http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf
>
> The only unusual part is that to bring the card up, both the pins
> RK_PD3 and RK_PD4 need to be pulled. Why this needs to be done is not
> clear, best explaination is that they are connected to the RTL8723BS
> pins WL_DIS# and BT_DIS#, which the data sheet vaguely says:
>
> Shared with GPIO9 This Pin Can Externally Shutdown the RTL8723BS WLAN
> function when BT_DISn is Pulled Low. When this pin deasserted, SDIO
> interface will be disabled. This pin can also support the WLAN Ra
> dio-off function with host interface remaining connected.
>
> Anyway extensive testing the TheSaint on ArchLinux Arm Forum
>
> https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=120#p60548
>
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>   arch/arm/boot/dts/rk3288-tinker.dtsi | 39 +++++++++++++++++++++++++---
>   1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index fceaeed44e34..e1796f340eef 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -3,8 +3,9 @@
>    * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
>    */
>   
>   #include "rk3288.dtsi"
>   #include <dt-bindings/input/input.h>
> +#include <dt-bindings/clock/rockchip,rk808.h>
>   
>   / {
>   	chosen {
> @@ -98,6 +97,15 @@
>   		startup-delay-us = <100000>;
>   		vin-supply = <&vcc_io>;
>   	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&rk808 RK808_CLKOUT1>;
> +		clock-names = "ext_clock";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_enable>;
> +		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
> +	};
>   };
>   
>   &cpu0 {
> @@ -337,8 +345,8 @@
>   
>   &io_domains {
>   	status = "okay";
> -
>   	sdcard-supply = <&vccio_sd>;
> +	wifi-supply = <&vcc_18>;
>   };
>   
>   &pinctrl {
> @@ -417,6 +425,12 @@
>   			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
>   		};
>   	};
> +
> +	sdio {
> +		wifi_enable: wifi-enable {
> +			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
>   };
>   
>   &pwm0 {
> @@ -440,6 +454,25 @@
>   	vqmmc-supply = <&vccio_sd>;
>   };
>   
> +&sdio0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	keep-power-in-suspend;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
> +	max-frequency = <50000000>;
> +	sd-uhs-sdr12;
> +	sd-uhs-sdr25;
> +	sd-uhs-sdr50;
> +	sd-uhs-ddr50;
> +	vmmc-supply = <&vcc_io>;
> +	vqmmc-supply = <&vcc_18>;
> +	status = "okay";
> +};
> +
>   &tsadc {
>   	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
>   	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */



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

Re: [PATCH 2/3] ARM: dts: rk3288 Tinker Board (S) add wi-fi

[Tony McKahan]

On Sun, Mar 3, 2019 at 2:40 PM David Summers
<beagleboard@davidjohnsummers.uk> wrote:
>
> And so synthesis on where we are on the WiFi patch for the Thinker Boards.
>
> There have been very few comments, only really Tony McKahan from Armbian
> - where they apply a similar patch. Tony was going to test the patch,
> but we have heard nothing back. The patch has been tested on ArchLinux
> Arm, and found to work.

Apologies, I've got too many things going at once, and it sounded like
there would/should be a V2 of this patch.  I tested it against 5.0 rc8
with sd-uhs-ddr50 removed as discussed previously, no issues
encountered.

Tony

>
> So with no further comments, I propose this is accepted as is. Heiko,
> let me know if you want me to respin this patch to apply cleanly after
> the sd card changes.
>
> David.
>
>
>
> On 17/02/2019 12:15, David Summers wrote:
> > This patch adds the wifi to the ASUS Tinker Board (S) machines.
> >
> > Unfortunatly neither the Tinker Board nor the Tinker Board S schematic
> > indicate how the WiFi is wired up on these devices. The WiFi is
> > provided by the RTL8723BS device, that has sdio WiFi and UART
> > Bluetooth. This patch just adds the WiFi interface.
> >
> > With no schematic, most of the wiring has been derived from the ASUS
> > patch to Debian:
> >
> > https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
> >
> > In conjunction with the pin out of the RTL8723BS device:
> >
> > http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
> > http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf
> >
> > The only unusual part is that to bring the card up, both the pins
> > RK_PD3 and RK_PD4 need to be pulled. Why this needs to be done is not
> > clear, best explaination is that they are connected to the RTL8723BS
> > pins WL_DIS# and BT_DIS#, which the data sheet vaguely says:
> >
> > Shared with GPIO9 This Pin Can Externally Shutdown the RTL8723BS WLAN
> > function when BT_DISn is Pulled Low. When this pin deasserted, SDIO
> > interface will be disabled. This pin can also support the WLAN Ra
> > dio-off function with host interface remaining connected.
> >
> > Anyway extensive testing the TheSaint on ArchLinux Arm Forum
> >
> > https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=120#p60548
> >
> > Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > ---
> >   arch/arm/boot/dts/rk3288-tinker.dtsi | 39 +++++++++++++++++++++++++---
> >   1 file changed, 36 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> > index fceaeed44e34..e1796f340eef 100644
> > --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> > +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> > @@ -3,8 +3,9 @@
> >    * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> >    */
> >
> >   #include "rk3288.dtsi"
> >   #include <dt-bindings/input/input.h>
> > +#include <dt-bindings/clock/rockchip,rk808.h>
> >
> >   / {
> >       chosen {
> > @@ -98,6 +97,15 @@
> >               startup-delay-us = <100000>;
> >               vin-supply = <&vcc_io>;
> >       };
> > +
> > +     sdio_pwrseq: sdio-pwrseq {
> > +             compatible = "mmc-pwrseq-simple";
> > +             clocks = <&rk808 RK808_CLKOUT1>;
> > +             clock-names = "ext_clock";
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&wifi_enable>;
> > +             reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
> > +     };
> >   };
> >
> >   &cpu0 {
> > @@ -337,8 +345,8 @@
> >
> >   &io_domains {
> >       status = "okay";
> > -
> >       sdcard-supply = <&vccio_sd>;
> > +     wifi-supply = <&vcc_18>;
> >   };
> >
> >   &pinctrl {
> > @@ -417,6 +425,12 @@
> >                       rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
> >               };
> >       };
> > +
> > +     sdio {
> > +             wifi_enable: wifi-enable {
> > +                     rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> > +             };
> > +     };
> >   };
> >
> >   &pwm0 {
> > @@ -440,6 +454,25 @@
> >       vqmmc-supply = <&vccio_sd>;
> >   };
> >
> > +&sdio0 {
> > +     bus-width = <4>;
> > +     cap-sd-highspeed;
> > +     cap-sdio-irq;
> > +     keep-power-in-suspend;
> > +     mmc-pwrseq = <&sdio_pwrseq>;
> > +     non-removable;
> > +     pinctrl-names = "default";
> > +     pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
> > +     max-frequency = <50000000>;
> > +     sd-uhs-sdr12;
> > +     sd-uhs-sdr25;
> > +     sd-uhs-sdr50;
> > +     sd-uhs-ddr50;
> > +     vmmc-supply = <&vcc_io>;
> > +     vqmmc-supply = <&vcc_18>;
> > +     status = "okay";
> > +};
> > +
> >   &tsadc {
> >       rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
> >       rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
>
>

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

[PATCH 3/3] ARM: dts: rk3288 Tinker Board (S) add bluetooth

[David Summers]

This patch is to add Bluetooth to the ASUS Tinker Board (S) device
tree.

This patch is more contraversal - so probably view it as a request for
comments.

The reason behind this, is this patch does not currently set Bluetooth
working on the these boards. The problem is that the
bluetooth/hci_h5.c driver, that is used for Realtek serial devices,
depends on ACPI. Unfortantly ACPI can not be enabled on armv7 machines
such as the TB(S). And so the kernel module for the RTL8723BS
Bluetooth can not be loaded.

However this patch is believed to be an accurate description of the
Tinker Board (S) wiring. It is strongly based on the ASUS patch:

https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678

As the Bluetooth is connected via a UART and this is wired into uart0,
this has been described as a SerDev.

The ASUS patch mentions the UART_CTS, but not the _RTS. Now as the
RTL8723BS has both CTS and RTS on the uart, it has been assumed both
are wired into uart0 on the cpu.

The Bluetooth connection has several wake up pins both device and host
and a reset pin. The wiring of these has been described; however how
the kernel driver will use these isn't clear. E.g. should HOST_WAKE be
an interupt?

The main reason for asking for comments, is that when it comes time to
make the changes to the bluetooth uart code, and add compatible flags,
robh has indicated that this will only be accepted with a valid
example. So the code below is that example. So I would like comments
that this approach is valid, which can be used when the later
submission comes. 

Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
---
 arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
index e1796f340eef..931b4c652fdc 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
+++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
@@ -481,6 +481,17 @@
 
 &uart0 {
 	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
+
+	bluetooth {
+		clocks = <&rk808 RK808_CLKOUT1>;
+		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_LOW>;
+		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
+		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
+		vcc-18-supply = <&vcc_18>;
+		vcc-io-supply = <&vcc_io>;
+	};
 };
 
 &uart1 {
-- 
beagleboard@davidjohnsummers.uk


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

Re: [PATCH 3/3] ARM: dts: rk3288 Tinker Board (S) add bluetooth

[Tony McKahan]

Hello Dave,

For the Bluetooth I can confirm _RTS is required, quite a lot of work
went into creating a userspace
solution for the Tinker Board bluetooth for Armbian by myself and by
Miouyouyou for a more
generic mainline patchset. Without RTS the rtk_hciattach handshake fails.

On Sun, Feb 17, 2019 at 7:17 AM David Summers
<beagleboard@davidjohnsummers.uk> wrote:
>
> This patch is to add Bluetooth to the ASUS Tinker Board (S) device
> tree.
>
> This patch is more contraversal - so probably view it as a request for
> comments.
>
> The reason behind this, is this patch does not currently set Bluetooth
> working on the these boards. The problem is that the
> bluetooth/hci_h5.c driver, that is used for Realtek serial devices,
> depends on ACPI. Unfortantly ACPI can not be enabled on armv7 machines
> such as the TB(S). And so the kernel module for the RTL8723BS
> Bluetooth can not be loaded.
>
> However this patch is believed to be an accurate description of the
> Tinker Board (S) wiring. It is strongly based on the ASUS patch:
>
> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
>
> As the Bluetooth is connected via a UART and this is wired into uart0,
> this has been described as a SerDev.
>
> The ASUS patch mentions the UART_CTS, but not the _RTS. Now as the
> RTL8723BS has both CTS and RTS on the uart, it has been assumed both
> are wired into uart0 on the cpu.
>
> The Bluetooth connection has several wake up pins both device and host
> and a reset pin. The wiring of these has been described; however how
> the kernel driver will use these isn't clear. E.g. should HOST_WAKE be
> an interupt?
>
> The main reason for asking for comments, is that when it comes time to
> make the changes to the bluetooth uart code, and add compatible flags,
> robh has indicated that this will only be accepted with a valid
> example. So the code below is that example. So I would like comments
> that this approach is valid, which can be used when the later
> submission comes.
>
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> ---
>  arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index e1796f340eef..931b4c652fdc 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -481,6 +481,17 @@
>
>  &uart0 {
>         status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
> +
> +       bluetooth {
> +               clocks = <&rk808 RK808_CLKOUT1>;
> +               reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_LOW>;
> +               device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
> +               host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
> +               vcc-18-supply = <&vcc_18>;
> +               vcc-io-supply = <&vcc_io>;
> +       };
>  };
>
>  &uart1 {
> --
> beagleboard@davidjohnsummers.uk
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip



-- 
--------------
Thomas McKahan

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

Re: [PATCH 3/3] ARM: dts: rk3288 Tinker Board (S) add bluetooth

[Stefan Wahren]

Hi David,

> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
> 
> 
> This patch is to add Bluetooth to the ASUS Tinker Board (S) device
> tree.
> 
> This patch is more contraversal - so probably view it as a request for
> comments.
> 
> The reason behind this, is this patch does not currently set Bluetooth
> working on the these boards. The problem is that the
> bluetooth/hci_h5.c driver, that is used for Realtek serial devices,
> depends on ACPI. Unfortantly ACPI can not be enabled on armv7 machines
> such as the TB(S). And so the kernel module for the RTL8723BS
> Bluetooth can not be loaded.
> 
> However this patch is believed to be an accurate description of the
> Tinker Board (S) wiring. It is strongly based on the ASUS patch:
> 
> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
> 
> As the Bluetooth is connected via a UART and this is wired into uart0,
> this has been described as a SerDev.
> 
> The ASUS patch mentions the UART_CTS, but not the _RTS. Now as the
> RTL8723BS has both CTS and RTS on the uart, it has been assumed both
> are wired into uart0 on the cpu.

which would be very strange, because we could use H4 instead of H5.

> 
> The Bluetooth connection has several wake up pins both device and host
> and a reset pin. The wiring of these has been described; however how
> the kernel driver will use these isn't clear. E.g. should HOST_WAKE be
> an interupt?
> 
> The main reason for asking for comments, is that when it comes time to
> make the changes to the bluetooth uart code, and add compatible flags,
> robh has indicated that this will only be accepted with a valid
> example. So the code below is that example. So I would like comments
> that this approach is valid, which can be used when the later
> submission comes. 

Asking for comment should be mark with RFC in the patch subject.

> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> ---
>  arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index e1796f340eef..931b4c652fdc 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -481,6 +481,17 @@
>  
>  &uart0 {
>  	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
> +
> +	bluetooth {
> +		clocks = <&rk808 RK808_CLKOUT1>;

As we already linked the RK808 clock in the sdio pwrseq, we shouldn't do this here again.

> +		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_LOW>;

reset-gpios isn't compatible to hci_h5, please use my preliminary dt-binding

> +		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
> +		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;

AFAIK hci_h5 doesn't support host-wake yet. So if you want to keep for the future we should make a comment.

> +		vcc-18-supply = <&vcc_18>;
> +		vcc-io-supply = <&vcc_io>;

Please drop these as the driver doesn't use it and it's already linked in the sdio pwrseq.

Thanks Stefan

> +	};

[1] - https://gist.github.com/lategoodbye/79bac99d4f1158a719a48ea3c45eb7f1#file-0002-dt-bindings-add-support-for-realtek-bluetooth-serial-patch

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

Re: [PATCH 3/3] ARM: dts: rk3288 Tinker Board (S) add bluetooth

[David Summers]

On 17/02/2019 21:05, Stefan Wahren wrote:
> Hi David,
>
>> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
>>
>>
>> This patch is to add Bluetooth to the ASUS Tinker Board (S) device
>> tree.
>>
>> This patch is more contraversal - so probably view it as a request for
>> comments.
>>
>> The reason behind this, is this patch does not currently set Bluetooth
>> working on the these boards. The problem is that the
>> bluetooth/hci_h5.c driver, that is used for Realtek serial devices,
>> depends on ACPI. Unfortantly ACPI can not be enabled on armv7 machines
>> such as the TB(S). And so the kernel module for the RTL8723BS
>> Bluetooth can not be loaded.
>>
>> However this patch is believed to be an accurate description of the
>> Tinker Board (S) wiring. It is strongly based on the ASUS patch:
>>
>> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
>>
>> As the Bluetooth is connected via a UART and this is wired into uart0,
>> this has been described as a SerDev.
>>
>> The ASUS patch mentions the UART_CTS, but not the _RTS. Now as the
>> RTL8723BS has both CTS and RTS on the uart, it has been assumed both
>> are wired into uart0 on the cpu.
> which would be very strange, because we could use H4 instead of H5.

Well the bluetooth maintainer said it was hci_h5.

The device is BT4.0 and that under Volume 4 HCI, Part D - 2 wire UART 
Transport Layer, in section 11.2 says that Hardware flow control may be 
used.

Also if you check what ASUS did:

https://github.com/TinkerBoard/debian_kernel/commit/5106d9486cf1c2bad4f701611f51a526191c56ad

They added H5 code to the hci_h4.c, seems strange but thats what they 
said they did.

Now maybe the RTL8723BS could work with the UART Transport Layer, but 
that hasn't been done yet. 3 wire has some overhead, but it doesn't look 
like much.

To my mind though it down to the bluetooth Maintainer - so CCing Marcel 
Holtmann in ...


>> The Bluetooth connection has several wake up pins both device and host
>> and a reset pin. The wiring of these has been described; however how
>> the kernel driver will use these isn't clear. E.g. should HOST_WAKE be
>> an interupt?
>>
>> The main reason for asking for comments, is that when it comes time to
>> make the changes to the bluetooth uart code, and add compatible flags,
>> robh has indicated that this will only be accepted with a valid
>> example. So the code below is that example. So I would like comments
>> that this approach is valid, which can be used when the later
>> submission comes.
> Asking for comment should be mark with RFC in the patch subject.
OOps my mistake.
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> ---
>>   arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> index e1796f340eef..931b4c652fdc 100644
>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> @@ -481,6 +481,17 @@
>>   
>>   &uart0 {
>>   	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
>> +
>> +	bluetooth {
>> +		clocks = <&rk808 RK808_CLKOUT1>;
> As we already linked the RK808 clock in the sdio pwrseq, we shouldn't do this here again.
>
>> +		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_LOW>;
> reset-gpios isn't compatible to hci_h5, please use my preliminary dt-binding
>
>> +		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
>> +		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
> AFAIK hci_h5 doesn't support host-wake yet. So if you want to keep for the future we should make a comment.
>
>> +		vcc-18-supply = <&vcc_18>;
>> +		vcc-io-supply = <&vcc_io>;
> Please drop these as the driver doesn't use it and it's already linked in the sdio pwrseq.
>
> Thanks Stefan
>
>> +	};
> [1] - https://gist.github.com/lategoodbye/79bac99d4f1158a719a48ea3c45eb7f1#file-0002-dt-bindings-add-support-for-realtek-bluetooth-serial-patch

Sorry I disagree here.

Last time I posted an example patch like this robh said clearly that 
these should give clocks, power, etc:

https://www.spinics.net/lists/linux-bluetooth/msg78545.html
https://www.spinics.net/lists/linux-bluetooth/msg78585.html 
<https://www.spinics.net/lists/linux-bluetooth/msg78585.html>

and as he is maintainer he wins.

I can understand Robs position, device tree are for describing hardware, 
they aren't primarily for helping code to load. Yes that is a second 
effect, its so it knows what is in  the hardware. In this case what if 
someone wanted Bluetooth, but not WiFi - then the Bluetooth should know 
what power and clocks are needed. Now that the driver doesn't understand 
these things is secondary. Maybe that will be cured in future?


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

Re: [PATCH 3/3] ARM: dts: rk3288 Tinker Board (S) add bluetooth

[Stefan Wahren]

Hi David,

> David Summers <beagleboard@davidjohnsummers.uk> hat am 18. Februar 2019 um 21:47 geschrieben:
> 
> 
> On 17/02/2019 21:05, Stefan Wahren wrote:
> > Hi David,
> >
> >> David Summers <beagleboard@davidjohnsummers.uk> hat am 17. Februar 2019 um 13:15 geschrieben:
> >>
> >> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> >> @@ -481,6 +481,17 @@
> >>   
> >>   &uart0 {
> >>   	status = "okay";
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
> >> +
> >> +	bluetooth {
> >> +		clocks = <&rk808 RK808_CLKOUT1>;
> > As we already linked the RK808 clock in the sdio pwrseq, we shouldn't do this here again.
> >
> >> +		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_LOW>;
> > reset-gpios isn't compatible to hci_h5, please use my preliminary dt-binding
> >
> >> +		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
> >> +		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
> > AFAIK hci_h5 doesn't support host-wake yet. So if you want to keep for the future we should make a comment.
> >
> >> +		vcc-18-supply = <&vcc_18>;
> >> +		vcc-io-supply = <&vcc_io>;
> > Please drop these as the driver doesn't use it and it's already linked in the sdio pwrseq.
> >
> > Thanks Stefan
> >
> >> +	};
> > [1] - https://gist.github.com/lategoodbye/79bac99d4f1158a719a48ea3c45eb7f1#file-0002-dt-bindings-add-support-for-realtek-bluetooth-serial-patch
> 
> Sorry I disagree here.
> 
> Last time I posted an example patch like this robh said clearly that 
> these should give clocks, power, etc:
> 
> https://www.spinics.net/lists/linux-bluetooth/msg78545.html
> https://www.spinics.net/lists/linux-bluetooth/msg78585.html 
> <https://www.spinics.net/lists/linux-bluetooth/msg78585.html>
> 
> and as he is maintainer he wins.
> 
> I can understand Robs position, device tree are for describing hardware, 
> they aren't primarily for helping code to load. Yes that is a second 
> effect, its so it knows what is in  the hardware. In this case what if 
> someone wanted Bluetooth, but not WiFi - then the Bluetooth should know 
> what power and clocks are needed. Now that the driver doesn't understand 
> these things is secondary. Maybe that will be cured in future?
>

you need to consider to context of the discussion. The link pointed to a discussion about the dt-binding. A binding should describe all parts (even optional) of the hardware and that is the reason why i explained in Arch board that we need 3 parts for bluetooth (dt-binding, driver change and finally the dts change). Since you avoid that and send only the last part without compatibles causes confusion.

We usually don't change DTS properties because it's considered as an ABI, which means we should do it properly in the first run. So lets make the step one (test bluetooth) and not step four ...

Regards
Stefan

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

Re: [PATCH 3/3] ARM: dts: rk3288 Tinker Board (S) add bluetooth

[David Summers]

Finally on the patch to give an outline description to Bluetooth on the 
Tinker Boards.

Synthesis here is harder.

On the one hand, it is non functioning - because although it describes 
the hardware, it has no compatible flag, and there is no current driver 
in the kernel.

It should be said though there is a patch for a proposed driver:

https://www.spinics.net/lists/linux-bluetooth/msg78661.html

And if accepted this would give the compatible flag. So should this 
change wait until that is added?

An alternative approach though arises from what Tony McKahan of Armbian 
writes

"For the Bluetooth I can confirm _RTS is required"

So this device tree segment is useful - it correctly describes the uart 
portion of the interface, and that is hard to determine from the ASUS 
dts. So this is useful information to capture.

On the pinout information of the rtl8723. Two points:

1) information like clock, and voltage supplies, are formally hardware 
correct, but practically will probably never be applied via bluetooth. 
Instead its the wifi that brings this hardware up. So should these be 
supplied if unlikly to be used? I think they should as they formally 
describe the hardware.

2) Confusion over enable-gpios vs reset-gpios

The second appeared on the bluetooth thread:

https://www.spinics.net/lists/linux-bluetooth/msg78654.html

should this be written:

enable-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_LOW>;

or

reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;

The datasheet (as available as it is): 
http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf

Says it is BT_RST - BT Reset IN

but the current kernel driver hci_h5 says:

https://github.com/torvalds/linux/blob/master/drivers/bluetooth/hci_h5.c#L989

     { "enable-gpios", &btrtl_enable_gpios, 1 },

And RobH clearly has a view:

https://www.spinics.net/lists/linux-bluetooth/msg79138.html

So there is still some confusion.

Guess its a question of it a partial hardware description, with possible 
faults, is better than no device tree description of the hardware?

Any views?



On 17/02/2019 12:15, David Summers wrote:
> This patch is to add Bluetooth to the ASUS Tinker Board (S) device
> tree.
>
> This patch is more contraversal - so probably view it as a request for
> comments.
>
> The reason behind this, is this patch does not currently set Bluetooth
> working on the these boards. The problem is that the
> bluetooth/hci_h5.c driver, that is used for Realtek serial devices,
> depends on ACPI. Unfortantly ACPI can not be enabled on armv7 machines
> such as the TB(S). And so the kernel module for the RTL8723BS
> Bluetooth can not be loaded.
>
> However this patch is believed to be an accurate description of the
> Tinker Board (S) wiring. It is strongly based on the ASUS patch:
>
> https://github.com/TinkerBoard/debian_kernel/commit/6a3128ade33f758887048578ada61a4b7ab8e678
>
> As the Bluetooth is connected via a UART and this is wired into uart0,
> this has been described as a SerDev.
>
> The ASUS patch mentions the UART_CTS, but not the _RTS. Now as the
> RTL8723BS has both CTS and RTS on the uart, it has been assumed both
> are wired into uart0 on the cpu.
>
> The Bluetooth connection has several wake up pins both device and host
> and a reset pin. The wiring of these has been described; however how
> the kernel driver will use these isn't clear. E.g. should HOST_WAKE be
> an interupt?
>
> The main reason for asking for comments, is that when it comes time to
> make the changes to the bluetooth uart code, and add compatible flags,
> robh has indicated that this will only be accepted with a valid
> example. So the code below is that example. So I would like comments
> that this approach is valid, which can be used when the later
> submission comes.
>
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> ---
>   arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
>   1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index e1796f340eef..931b4c652fdc 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -481,6 +481,17 @@
>   
>   &uart0 {
>   	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
> +
> +	bluetooth {
> +		clocks = <&rk808 RK808_CLKOUT1>;
> +		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_LOW>;
> +		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
> +		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
> +		vcc-18-supply = <&vcc_18>;
> +		vcc-io-supply = <&vcc_io>;
> +	};
>   };
>   
>   &uart1 {



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

Re: [PATCH 0/3] ARM: dts: rk3288 Tinker Board (S) updates

[David Summers]

On 17/02/2019 12:15, David Summers wrote:
> Find in the following patches 3 sets of updates to the rk3288 ASUS
> Tinker Board (S) device tree. The patches consist of:
>
>         1) Changes to sd card, to remove error
>         2) Add WiFi to the device tree
>         3) Add an outline for Bluetooth to the device tree
>
> The patches have been developed by both Stefan and myself, and hence
> have both our sign off.
>
> The patches have been extensivly tested by TheSaint on ArchLinux Arm
> Forum, details:
>
> https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=90
>
> Each patch has more details on what is covered.
>
> David.
>
Oh yes - should note in this covering patch, that the 1st patch to 
correct sd card detection; has been updated to v2. Now as this was the 
first patch applied, it may affect the applying the second (and third 
patch). So if these need to be updated based on the v2 version of the 
first patch - just let me know. But whilst sill in the reviewing stage, 
might as well stick with the original post for wifi.

Regards,

David.


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

[PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[David Summers]

The Problem:

On ASUS Tinker Board S, when booting from the eMMC, and there is card
in the sd slot, there are constant errors.

Also when warm reboot, uboot can not access the sd slot

Cause:

Identified by Robin Murphy @ ARM. The Card Detect on rk3288
devices is pulled up by vccio-sd; so when the regulator powers this
off, card detect gives spurious errors. A second problem, is during
power down, vccio-sd apprears to be powered down. This causes a
problem when warm rebooting from the sd card. This was identified by
Jonas Karlman.

History:

A common fault on these rk3288 board, which impliment the reference
design.

When this arose before:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.html

And Ulf and Jaehoon clearly said this was a broken card detect design,
which should be solved via polling

Solution:

Hence broken-cd is set as a property. This cures the errors. The
powering down of vccio-sd during reboot is cured by adding
regulator-boot-on.

This solutions has been fairly widely reviewed and tested.

Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
Reviewed by: Robin Murphy <robin.murphy at arm.com>
Reviewed by: Jonas Karlman <jonas at kwiboo.se>
Test by: TheSaint < @ ArchLinux Arm >
---
 arch/arm/boot/dts/rk3288-tinker.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
index aa107ee41b8b..ef653c3209bc 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
+++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
@@ -254,6 +254,7 @@
 			};
 
 			vccio_sd: LDO_REG5 {
+				regulator-boot-on;
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-name = "vccio_sd";
@@ -430,7 +431,7 @@
 	bus-width = <4>;
 	cap-mmc-highspeed;
 	cap-sd-highspeed;
-	card-detect-delay = <200>;
+	broken-cd;
 	disable-wp;			/* wp not hooked up */
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
-- 
beagleboard@davidjohnsummers.uk


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

[PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[David Summers]

The Problem:

On ASUS Tinker Board S, when booting from the eMMC, and there is card
in the sd slot, there are constant errors.

Also when warm reboot, uboot can not access the sd slot

Cause:

Identified by Robin Murphy @ ARM. The Card Detect on rk3288
devices is pulled up by vccio-sd; so when the regulator powers this
off, card detect gives spurious errors. A second problem, is during
power down, vccio-sd apprears to be powered down. This causes a
problem when warm rebooting from the sd card. This was identified by
Jonas Karlman.

History:

A common fault on these rk3288 board, which impliment the reference
design.

When this arose before:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.html

And Ulf and Jaehoon clearly said this was a broken card detect design,
which should be solved via polling

Solution:

Hence broken-cd is set as a property. This cures the errors. The
powering down of vccio-sd during reboot is cured by adding
regulator-boot-on.

This solutions has been fairly widely reviewed and tested.

Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
Reviewed by: Robin Murphy <robin.murphy@arm.com>
Reviewed by: Jonas Karlman <jonas@kwiboo.se>
Test by: TheSaint @ ArchLinux Arm
---
 arch/arm/boot/dts/rk3288-tinker.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
index aa107ee41b8b..ef653c3209bc 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
+++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
@@ -254,6 +254,7 @@
 			};
 
 			vccio_sd: LDO_REG5 {
+				regulator-boot-on;
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-name = "vccio_sd";
@@ -430,7 +431,7 @@
 	bus-width = <4>;
 	cap-mmc-highspeed;
 	cap-sd-highspeed;
-	card-detect-delay = <200>;
+	broken-cd;
 	disable-wp;			/* wp not hooked up */
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
-- 
beagleboard@davidjohnsummers.uk


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

[PATCH v3 2/3] arm: dts: rk3288-tinker.dtsi: Enable WiFi

[David Summers]

This patch adds wifi support to the ASUS Tinker Board (S) machines.

This is provided by an wifi card (RTL8723BS) wired into the sdio interface.

It requires certain pins pulled, to enable the WiFi.

The schematics for these board do not show the WiFi connection, so the
connections have been taken from:

https://github.com/TinkerBoard/debian_kernel/blob/develop/arch/arm/boot/dts/rk3288-miniarm.dts

In particular the pulling of two pins.

This patch is almost identical to v1. A few additional line breaks for
readability. On Armbian, they did not use sd-uhs-ddr50, so this has
been removed. It does not change functionality. The ASUS patch set
sd-uhs-sdr104;.

Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Tony McKahan <tonymckahan@gmail.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com> 
Test-by: TheSaint @ ArchLinux ARM 

---
 arch/arm/boot/dts/rk3288-tinker.dtsi | 40 +++++++++++++++++++++++++++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
index ef653c3209bc..0ffab1b7c940 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
+++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
@@ -5,6 +5,7 @@
 
 #include "rk3288.dtsi"
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clock/rockchip,rk808.h>
 
 / {
 	chosen {
@@ -96,6 +97,17 @@
 		startup-delay-us = <100000>;
 		vin-supply = <&vcc_io>;
 	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk808 RK808_CLKOUT1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable>;
+		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>,
+			<&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
+	};
+
 };
 
 &cpu0 {
@@ -336,7 +348,7 @@
 
 &io_domains {
 	status = "okay";
-
+	wifi-supply = <&vcc_18>;
 	sdcard-supply = <&vccio_sd>;
 };
 
@@ -416,6 +428,13 @@
 			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
 	};
+
+	sdio {
+		wifi_enable: wifi-enable {
+			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>,
+				<4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
 };
 
 &pwm0 {
@@ -440,6 +459,25 @@
 	vqmmc-supply = <&vccio_sd>;
 };
 
+&sdio0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
+	max-frequency = <50000000>;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	sd-uhs-sdr50;
+	vmmc-supply = <&vcc_io>;
+	vqmmc-supply = <&vcc_18>;
+	status = "okay";
+};
+
+
 &tsadc {
 	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
 	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
-- 
beagleboard@davidjohnsummers.uk


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

Re: [PATCH v3 2/3] arm: dts: rk3288-tinker.dtsi: Enable WiFi

[Robin Murphy]

On 2019-03-09 3:39 pm, David Summers wrote:
> This patch adds wifi support to the ASUS Tinker Board (S) machines.
> 
> This is provided by an wifi card (RTL8723BS) wired into the sdio interface.
> 
> It requires certain pins pulled, to enable the WiFi.
> 
> The schematics for these board do not show the WiFi connection, so the
> connections have been taken from:
> 
> https://github.com/TinkerBoard/debian_kernel/blob/develop/arch/arm/boot/dts/rk3288-miniarm.dts
> 
> In particular the pulling of two pins.
> 
> This patch is almost identical to v1. A few additional line breaks for
> readability. On Armbian, they did not use sd-uhs-ddr50, so this has
> been removed. It does not change functionality. The ASUS patch set
> sd-uhs-sdr104;.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Tested-by: Tony McKahan <tonymckahan@gmail.com>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>

Erm, I don't think I did... :(

Please see section 13 of Documentation/process/submitting-patches.rst 
for what that tag means.

FWIW this is the kind of patch I might have considered formally 
reviewing if I had enough first-hand experience of the Tinker Board or 
Realtek SDIO modules to judge correctness, but sadly I have zero of either.

Robin.

> Test-by: TheSaint @ ArchLinux ARM
> 
> ---
>   arch/arm/boot/dts/rk3288-tinker.dtsi | 40 +++++++++++++++++++++++++++-
>   1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index ef653c3209bc..0ffab1b7c940 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -5,6 +5,7 @@
>   
>   #include "rk3288.dtsi"
>   #include <dt-bindings/input/input.h>
> +#include <dt-bindings/clock/rockchip,rk808.h>
>   
>   / {
>   	chosen {
> @@ -96,6 +97,17 @@
>   		startup-delay-us = <100000>;
>   		vin-supply = <&vcc_io>;
>   	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&rk808 RK808_CLKOUT1>;
> +		clock-names = "ext_clock";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_enable>;
> +		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>,
> +			<&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
> +	};
> +
>   };
>   
>   &cpu0 {
> @@ -336,7 +348,7 @@
>   
>   &io_domains {
>   	status = "okay";
> -
> +	wifi-supply = <&vcc_18>;
>   	sdcard-supply = <&vccio_sd>;
>   };
>   
> @@ -416,6 +428,13 @@
>   			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
>   		};
>   	};
> +
> +	sdio {
> +		wifi_enable: wifi-enable {
> +			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>,
> +				<4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
>   };
>   
>   &pwm0 {
> @@ -440,6 +459,25 @@
>   	vqmmc-supply = <&vccio_sd>;
>   };
>   
> +&sdio0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	keep-power-in-suspend;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
> +	max-frequency = <50000000>;
> +	sd-uhs-sdr12;
> +	sd-uhs-sdr25;
> +	sd-uhs-sdr50;
> +	vmmc-supply = <&vcc_io>;
> +	vqmmc-supply = <&vcc_18>;
> +	status = "okay";
> +};
> +
> +
>   &tsadc {
>   	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
>   	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> 

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

Re: [PATCH v3 2/3] arm: dts: rk3288-tinker.dtsi: Enable WiFi

[David Summers]

On 11/03/2019 22:18, Robin Murphy wrote:
> On 2019-03-09 3:39 pm, David Summers wrote:
>>
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> Tested-by: Tony McKahan <tonymckahan@gmail.com>
>> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
> Erm, I don't think I did... :(
>
> Please see section 13 of Documentation/process/submitting-patches.rst 
> for what that tag means.
>
> FWIW this is the kind of patch I might have considered formally 
> reviewing if I had enough first-hand experience of the Tinker Board or 
> Realtek SDIO modules to judge correctness, but sadly I have zero of 
> either.
>
> Robin.
>
>> Test-by: TheSaint @ ArchLinux ARM

Apols Robin. I read to much into your understanding of the comments that 
were talked to be added....

Yes Stefan but at least as much, maybe more work into this patch than I 
did. He was the man that made it close to what we could mainline. I only 
added very little, but then again I was also the one pushing for mainlining.

So if only one sign off - Probably Stefan did most.

Heiko: Same question as before do you want me to resend which cleared up 
signoff? Just send me an email - and I'll do whatever is best for you.

David.


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

Re: [PATCH v3 2/3] arm: dts: rk3288-tinker.dtsi: Enable WiFi

[Heiko Stübner]

Am Dienstag, 12. März 2019, 21:41:24 CET schrieb David Summers:
> On 11/03/2019 22:18, Robin Murphy wrote:
> > On 2019-03-09 3:39 pm, David Summers wrote:
> >> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> >> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >> Tested-by: Tony McKahan <tonymckahan@gmail.com>
> >> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> > 
> > Erm, I don't think I did... :(
> > 
> > Please see section 13 of Documentation/process/submitting-patches.rst
> > for what that tag means.
> > 
> > FWIW this is the kind of patch I might have considered formally
> > reviewing if I had enough first-hand experience of the Tinker Board or
> > Realtek SDIO modules to judge correctness, but sadly I have zero of
> > either.
> > 
> > Robin.
> > 
> >> Test-by: TheSaint @ ArchLinux ARM
> 
> Apols Robin. I read to much into your understanding of the comments that
> were talked to be added....
> 
> Yes Stefan but at least as much, maybe more work into this patch than I
> did. He was the man that made it close to what we could mainline. I only
> added very little, but then again I was also the one pushing for mainlining.
> 
> So if only one sign off - Probably Stefan did most.

Nope, that was the reason for my Co-developed-by question.
If you look into the submitting patches document there is a special tag
Co-Developed-by to give credit to the author that is not the "patch-from".

And in this case all authors also get a signed-off-by line.

> 
> Heiko: Same question as before do you want me to resend which cleared up
> signoff? Just send me an email - and I'll do whatever is best for you.

As in the other mail, resending for things like that is not necessary in my
case. I just need to hunt down the relevant information as you can see :-D

Heiko



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

Re: [PATCH v3 2/3] arm: dts: rk3288-tinker.dtsi: Enable WiFi

[Heiko Stuebner]

Am Samstag, 9. März 2019, 16:39:22 CET schrieb David Summers:
> This patch adds wifi support to the ASUS Tinker Board (S) machines.
> 
> This is provided by an wifi card (RTL8723BS) wired into the sdio interface.
> 
> It requires certain pins pulled, to enable the WiFi.
> 
> The schematics for these board do not show the WiFi connection, so the
> connections have been taken from:
> 
> https://github.com/TinkerBoard/debian_kernel/blob/develop/arch/arm/boot/dts/rk3288-miniarm.dts
> 
> In particular the pulling of two pins.
> 
> This patch is almost identical to v1. A few additional line breaks for
> readability. On Armbian, they did not use sd-uhs-ddr50, so this has
> been removed. It does not change functionality. The ASUS patch set
> sd-uhs-sdr104;.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>

trying to understand the relationship here, is that a
"Co-developed-by: Stefan Wahren <...>" case?

Because individual Signed-off-bys would be (1) author, (2) sender
and (3) me and Stefan obviously didn't send the patch :-)

> Tested-by: Tony McKahan <tonymckahan@gmail.com>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com> 
> Test-by: TheSaint @ ArchLinux ARM 

Same comment about Tested-by with an actual name+mail please.

Other than that bit of bureaucracy this looks good, minus some
reordering. If you need to resend for whatever reason, please try to
order devicetree nodes and properties alphabetical if they don't have
an address in the name (otherwise obviously by address).

But I can do that reordering myself and also drop the Review-tag naming
Robin above, if you clear up the "paperwork" above :-).

Heiko
Heiko



> 
> ---
>  arch/arm/boot/dts/rk3288-tinker.dtsi | 40 +++++++++++++++++++++++++++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index ef653c3209bc..0ffab1b7c940 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -5,6 +5,7 @@
>  
>  #include "rk3288.dtsi"
>  #include <dt-bindings/input/input.h>
> +#include <dt-bindings/clock/rockchip,rk808.h>
>  
>  / {
>  	chosen {
> @@ -96,6 +97,17 @@
>  		startup-delay-us = <100000>;
>  		vin-supply = <&vcc_io>;
>  	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&rk808 RK808_CLKOUT1>;
> +		clock-names = "ext_clock";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_enable>;
> +		reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>,
> +			<&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
> +	};
> +
>  };
>  
>  &cpu0 {
> @@ -336,7 +348,7 @@
>  
>  &io_domains {
>  	status = "okay";
> -
> +	wifi-supply = <&vcc_18>;
>  	sdcard-supply = <&vccio_sd>;
>  };
>  
> @@ -416,6 +428,13 @@
>  			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
>  	};
> +
> +	sdio {
> +		wifi_enable: wifi-enable {
> +			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>,
> +				<4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
>  };
>  
>  &pwm0 {
> @@ -440,6 +459,25 @@
>  	vqmmc-supply = <&vccio_sd>;
>  };
>  
> +&sdio0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	keep-power-in-suspend;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
> +	max-frequency = <50000000>;
> +	sd-uhs-sdr12;
> +	sd-uhs-sdr25;
> +	sd-uhs-sdr50;
> +	vmmc-supply = <&vcc_io>;
> +	vqmmc-supply = <&vcc_18>;
> +	status = "okay";
> +};
> +
> +
>  &tsadc {
>  	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
>  	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> 





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

Re: [PATCH v3 2/3] arm: dts: rk3288-tinker.dtsi: Enable WiFi

[Stefan Wahren]

Hi Heiko,

Am 12.03.19 um 15:18 schrieb Heiko Stuebner:
> Am Samstag, 9. März 2019, 16:39:22 CET schrieb David Summers:
>> This patch adds wifi support to the ASUS Tinker Board (S) machines.
>>
>> This is provided by an wifi card (RTL8723BS) wired into the sdio interface.
>>
>> It requires certain pins pulled, to enable the WiFi.
>>
>> The schematics for these board do not show the WiFi connection, so the
>> connections have been taken from:
>>
>> https://github.com/TinkerBoard/debian_kernel/blob/develop/arch/arm/boot/dts/rk3288-miniarm.dts
>>
>> In particular the pulling of two pins.
>>
>> This patch is almost identical to v1. A few additional line breaks for
>> readability. On Armbian, they did not use sd-uhs-ddr50, so this has
>> been removed. It does not change functionality. The ASUS patch set
>> sd-uhs-sdr104;.
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> trying to understand the relationship here, is that a
> "Co-developed-by: Stefan Wahren <...>" case?

yes it is.

Regards Stefan


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

Re: [PATCH v3 2/3] arm: dts: rk3288-tinker.dtsi: Enable WiFi

[Heiko Stübner]

Am Samstag, 9. März 2019, 16:39:22 CET schrieb David Summers:
> This patch adds wifi support to the ASUS Tinker Board (S) machines.
> 
> This is provided by an wifi card (RTL8723BS) wired into the sdio interface.
> 
> It requires certain pins pulled, to enable the WiFi.
> 
> The schematics for these board do not show the WiFi connection, so the
> connections have been taken from:
> 
> https://github.com/TinkerBoard/debian_kernel/blob/develop/arch/arm/boot/dts/
> rk3288-miniarm.dts
> 
> In particular the pulling of two pins.
> 
> This patch is almost identical to v1. A few additional line breaks for
> readability. On Armbian, they did not use sd-uhs-ddr50, so this has
> been removed. It does not change functionality. The ASUS patch set
> sd-uhs-sdr104;.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Tested-by: Tony McKahan <tonymckahan@gmail.com>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Test-by: TheSaint @ ArchLinux ARM

applied for 5.2 with the following changes:
- adapted subject to match the subsystem
- updated received tags as negotiated yesterday
- reordered some nodes and properties to match general sorting
  (by @address first, otherwise largely alphabetical)

Thanks
Heiko



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

[PATCH v3 3/3] arm: dts: rk3288-tinker.dtsi: Add outline Bluetooth support

[David Summers]

This patch is an outline for bluetooth on the ASUS Tinker Board (S).

Bluetooth is provided my RTL8723BS on these machine, and this is wired
into UART0.

Here this is performed as a SerDev device.

Now as presented, this does not give functioning bluetooth. The
updates needed to the device driver:

https://www.spinics.net/lists/linux-bluetooth/msg78661.html

Haven't yet been accepted. So this device tree hook doesn't yet have
"realtek,rtl8723bs-bt" compatible flag.

It is however still submitted as a patch, as it sets the UART up
correctly. And so basic communciation can be had with the device. This
has been confirmed by Tony McKahan @ Armbian, in particular that the
CTS/RTS is needed.

When Vasily patch is accepted, this will be added as a minor patch on
top of this patch; as this patch gives the pins needed.

The one oddity, is the RESET pin, it is labeled this way on the
schematic. However the hci_h5.c driver calls this ENABLE. Here we have
stuck with the schematic name.

Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
---
 arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
index 0ffab1b7c940..d29f5b34d7e6 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
+++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
@@ -486,6 +486,17 @@
 
 &uart0 {
 	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
+
+	bluetooth {
+		clocks = <&rk808 RK808_CLKOUT1>;
+		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
+		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
+		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
+		vcc-18-supply = <&vcc_18>;
+		vcc-io-supply = <&vcc_io>;
+	};
 };
 
 &uart1 {
-- 
beagleboard@davidjohnsummers.uk


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

Re: [PATCH v3 3/3] arm: dts: rk3288-tinker.dtsi: Add outline Bluetooth support

[Marcel Holtmann]

Hi David,

> This patch is an outline for bluetooth on the ASUS Tinker Board (S).
> 
> Bluetooth is provided my RTL8723BS on these machine, and this is wired
> into UART0.
> 
> Here this is performed as a SerDev device.
> 
> Now as presented, this does not give functioning bluetooth. The
> updates needed to the device driver:
> 
> https://www.spinics.net/lists/linux-bluetooth/msg78661.html
> 
> Haven't yet been accepted. So this device tree hook doesn't yet have
> "realtek,rtl8723bs-bt" compatible flag.
> 
> It is however still submitted as a patch, as it sets the UART up
> correctly. And so basic communciation can be had with the device. This
> has been confirmed by Tony McKahan @ Armbian, in particular that the
> CTS/RTS is needed.
> 
> When Vasily patch is accepted, this will be added as a minor patch on
> top of this patch; as this patch gives the pins needed.
> 
> The one oddity, is the RESET pin, it is labeled this way on the
> schematic. However the hci_h5.c driver calls this ENABLE. Here we have
> stuck with the schematic name.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> ---
> arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index 0ffab1b7c940..d29f5b34d7e6 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -486,6 +486,17 @@
> 
> &uart0 {
> 	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
> +
> +	bluetooth {
> +		clocks = <&rk808 RK808_CLKOUT1>;
> +		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
> +		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
> +		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
> +		vcc-18-supply = <&vcc_18>;
> +		vcc-io-supply = <&vcc_io>;
> +	};
> };

I need an ACK from Rob for this and also you might want to send the whole series for me to review in full context.

Regards

Marcel


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

Re: [PATCH v3 3/3] arm: dts: rk3288-tinker.dtsi: Add outline Bluetooth support

[David Summers]

Hi Marcel,

On 11/03/2019 16:41, Marcel Holtmann wrote:
> Hi David,
>
>> This patch is an outline for bluetooth on the ASUS Tinker Board (S).
>>
>> Bluetooth is provided my RTL8723BS on these machine, and this is wired
>> into UART0.
>>
>> Here this is performed as a SerDev device.
>>
>> Now as presented, this does not give functioning bluetooth. The
>> updates needed to the device driver:
>>
>> https://www.spinics.net/lists/linux-bluetooth/msg78661.html
>>
>> Haven't yet been accepted. So this device tree hook doesn't yet have
>> "realtek,rtl8723bs-bt" compatible flag.
>>
>> It is however still submitted as a patch, as it sets the UART up
>> correctly. And so basic communciation can be had with the device. This
>> has been confirmed by Tony McKahan @ Armbian, in particular that the
>> CTS/RTS is needed.
>>
>> When Vasily patch is accepted, this will be added as a minor patch on
>> top of this patch; as this patch gives the pins needed.
>>
>> The one oddity, is the RESET pin, it is labeled this way on the
>> schematic. However the hci_h5.c driver calls this ENABLE. Here we have
>> stuck with the schematic name.
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> ---
>> arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> index 0ffab1b7c940..d29f5b34d7e6 100644
>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> @@ -486,6 +486,17 @@
>>
>> &uart0 {
>> 	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
>> +
>> +	bluetooth {
>> +		clocks = <&rk808 RK808_CLKOUT1>;
>> +		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
>> +		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
>> +		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
>> +		vcc-18-supply = <&vcc_18>;
>> +		vcc-io-supply = <&vcc_io>;
>> +	};
>> };
> I need an ACK from Rob for this and also you might want to send the whole series for me to review in full context.
>
> Regards
>
> Marcel
>
Yes happy to wait for ACK from Rob. Of the 3 patches done this is the 
least urgent, as Bluetooth is currently non functioning on these 
machines, so delay in this doesn't change the status quo. Patch 3 is 
self standing, e.g. not applying it doesn't affect the other two. 
However patch 3 probably has to be applied sequentially after patches 
1&2 as all are on the single file.

Following on from Robs comments on last patch sent adding bluetooth, 
I've made this one FAR more detailed. That said though the drivers for 
bluetooth in this case doesn't use clock or supply ASAIK. Most things 
are brought up by the wifi part of the device tree which was patch 2. 
However adding to the bluetooth device tree as well, at least leaves the 
option open to a user just loading bluetooth, and not wifi.

The one thing missing from this bluetooth device tree, is explaining 
which pins need to be pulled to bring up the card. This is part be 
design (the tinker board and rt8723bs both have bad public documentation 
- so exact operation is hard to guess ...); but also because I couldn't 
see a way of getting a SerDev device to pull pins on loading, unlike 
sdio (used for wifi).

Full series:

Part 1 - device tree changes for sd card
Part 2 - adding wifi to the device tree
Part 3 - adding outline bluetooth

So are each fairly self standing. However if interested in parts 1 and 2 
they can be found:

http://lists.infradead.org/pipermail/linux-rockchip/2019-March/023330.html
http://lists.infradead.org/pipermail/linux-rockchip/2019-March/023331.html

Regards, and yes happy to wait and see what Rob has to say.

David.



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

Re: [PATCH v3 3/3] arm: dts: rk3288-tinker.dtsi: Add outline Bluetooth support

[Heiko Stübner]

Hi David,

Am Samstag, 9. März 2019, 16:39:23 CET schrieb David Summers:
> This patch is an outline for bluetooth on the ASUS Tinker Board (S).
> 
> Bluetooth is provided my RTL8723BS on these machine, and this is wired
> into UART0.
> 
> Here this is performed as a SerDev device.
> 
> Now as presented, this does not give functioning bluetooth. The
> updates needed to the device driver:
> 
> https://www.spinics.net/lists/linux-bluetooth/msg78661.html
> 
> Haven't yet been accepted. So this device tree hook doesn't yet have
> "realtek,rtl8723bs-bt" compatible flag.
> 
> It is however still submitted as a patch, as it sets the UART up
> correctly. And so basic communciation can be had with the device. This
> has been confirmed by Tony McKahan @ Armbian, in particular that the
> CTS/RTS is needed.
> 
> When Vasily patch is accepted, this will be added as a minor patch on
> top of this patch; as this patch gives the pins needed.
> 
> The one oddity, is the RESET pin, it is labeled this way on the
> schematic. However the hci_h5.c driver calls this ENABLE. Here we have
> stuck with the schematic name.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> ---
>  arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi
> b/arch/arm/boot/dts/rk3288-tinker.dtsi index 0ffab1b7c940..d29f5b34d7e6
> 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -486,6 +486,17 @@
> 
>  &uart0 {
>  	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
> +
> +	bluetooth {
> +		clocks = <&rk808 RK808_CLKOUT1>;
> +		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
> +		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
> +		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
> +		vcc-18-supply = <&vcc_18>;
> +		vcc-io-supply = <&vcc_io>;
> +	};

As this is supposed to work as serial attached device it should follow a
dt-binding, so first of all definitly needs a compatible and a binding
specifying all the properties declared above.

See for example Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
for a similar device.

Heiko



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

Re: [PATCH v3 3/3] arm: dts: rk3288-tinker.dtsi: Add outline Bluetooth support

[David Summers]

On 13/03/2019 10:56, Heiko Stübner wrote:
> Hi David,
>
> Am Samstag, 9. März 2019, 16:39:23 CET schrieb David Summers:
>> This patch is an outline for bluetooth on the ASUS Tinker Board (S).
>>
>> Bluetooth is provided my RTL8723BS on these machine, and this is wired
>> into UART0.
>>
>> Here this is performed as a SerDev device.
>>
>> Now as presented, this does not give functioning bluetooth. The
>> updates needed to the device driver:
>>
>> https://www.spinics.net/lists/linux-bluetooth/msg78661.html
>>
>> Haven't yet been accepted. So this device tree hook doesn't yet have
>> "realtek,rtl8723bs-bt" compatible flag.
>>
>> It is however still submitted as a patch, as it sets the UART up
>> correctly. And so basic communciation can be had with the device. This
>> has been confirmed by Tony McKahan @ Armbian, in particular that the
>> CTS/RTS is needed.
>>
>> When Vasily patch is accepted, this will be added as a minor patch on
>> top of this patch; as this patch gives the pins needed.
>>
>> The one oddity, is the RESET pin, it is labeled this way on the
>> schematic. However the hci_h5.c driver calls this ENABLE. Here we have
>> stuck with the schematic name.
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> ---
>>   arch/arm/boot/dts/rk3288-tinker.dtsi | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi
>> b/arch/arm/boot/dts/rk3288-tinker.dtsi index 0ffab1b7c940..d29f5b34d7e6
>> 100644
>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> @@ -486,6 +486,17 @@
>>
>>   &uart0 {
>>   	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
>> +
>> +	bluetooth {
>> +		clocks = <&rk808 RK808_CLKOUT1>;
>> +		reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
>> +		device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
>> +		host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
>> +		vcc-18-supply = <&vcc_18>;
>> +		vcc-io-supply = <&vcc_io>;
>> +	};
> As this is supposed to work as serial attached device it should follow a
> dt-binding, so first of all definitly needs a compatible and a binding
> specifying all the properties declared above.
>
> See for example Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
> for a similar device.
>
> Heiko
>
>
Heiko,

Yes I understand. Means I'll need to take care not to loose these email, 
as getting all the pins right took some time ...

I'll probably follow 
https://www.spinics.net/lists/linux-bluetooth/msg78654.html if it gets 
accepted. That is the main problem here, at the moment there is no 
compatible that can be used, as none yet accepted.

Rob H, Question for you, before you said [1]:

> There's no interrupts, GPIO control lines, power supplies, etc. for
> these chips? The binding should be complete even if your platform
> doesn't need these.
Now its clear that so far the driver for bluetooth doesn't know about 
supply, and clocks etc.

So should these be included in the dts, as a correct description as how 
its wired; even if not used in the current driver, they may be used in 
future.

Am happy to do whatever best.

Regards,

David.

[1] https://www.spinics.net/lists/linux-bluetooth/msg78545.html



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

Re: [PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[Heiko Stuebner]

Am Samstag, 9. März 2019, 16:39:21 CET schrieb David Summers:
> The Problem:
> 
> On ASUS Tinker Board S, when booting from the eMMC, and there is card
> in the sd slot, there are constant errors.
> 
> Also when warm reboot, uboot can not access the sd slot
> 
> Cause:
> 
> Identified by Robin Murphy @ ARM. The Card Detect on rk3288
> devices is pulled up by vccio-sd; so when the regulator powers this
> off, card detect gives spurious errors. A second problem, is during
> power down, vccio-sd apprears to be powered down. This causes a
> problem when warm rebooting from the sd card. This was identified by
> Jonas Karlman.
> 
> History:
> 
> A common fault on these rk3288 board, which impliment the reference
> design.
> 
> When this arose before:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.html
> 
> And Ulf and Jaehoon clearly said this was a broken card detect design,
> which should be solved via polling
> 
> Solution:
> 
> Hence broken-cd is set as a property. This cures the errors. The
> powering down of vccio-sd during reboot is cured by adding
> regulator-boot-on.
> 
> This solutions has been fairly widely reviewed and tested.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Reviewed by: Robin Murphy <robin.murphy@arm.com>
> Reviewed by: Jonas Karlman <jonas@kwiboo.se>
> Test by: TheSaint @ ArchLinux Arm

please follow patch submission guidelines, here it would be
Tested-by: ... with an actual Name + mail address

Also I did try to go through the way big mail thread but didn't
find an actual "Reviewed-by" from Robin Murphy, similar to what
he pointed out in patch2

Other than that and including the past discussions, this looks good.


Heiko

> ---
>  arch/arm/boot/dts/rk3288-tinker.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
> index aa107ee41b8b..ef653c3209bc 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -254,6 +254,7 @@
>  			};
>  
>  			vccio_sd: LDO_REG5 {
> +				regulator-boot-on;
>  				regulator-min-microvolt = <1800000>;
>  				regulator-max-microvolt = <3300000>;
>  				regulator-name = "vccio_sd";
> @@ -430,7 +431,7 @@
>  	bus-width = <4>;
>  	cap-mmc-highspeed;
>  	cap-sd-highspeed;
> -	card-detect-delay = <200>;
> +	broken-cd;
>  	disable-wp;			/* wp not hooked up */
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
> 





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

Re: [PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[Robin Murphy]

On 2019-03-12 2:08 pm, Heiko Stuebner wrote:
> Am Samstag, 9. März 2019, 16:39:21 CET schrieb David Summers:
>> The Problem:
>>
>> On ASUS Tinker Board S, when booting from the eMMC, and there is card
>> in the sd slot, there are constant errors.
>>
>> Also when warm reboot, uboot can not access the sd slot
>>
>> Cause:
>>
>> Identified by Robin Murphy @ ARM. The Card Detect on rk3288
>> devices is pulled up by vccio-sd; so when the regulator powers this
>> off, card detect gives spurious errors. A second problem, is during
>> power down, vccio-sd apprears to be powered down. This causes a
>> problem when warm rebooting from the sd card. This was identified by
>> Jonas Karlman.
>>
>> History:
>>
>> A common fault on these rk3288 board, which impliment the reference
>> design.
>>
>> When this arose before:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.html
>>
>> And Ulf and Jaehoon clearly said this was a broken card detect design,
>> which should be solved via polling
>>
>> Solution:
>>
>> Hence broken-cd is set as a property. This cures the errors. The
>> powering down of vccio-sd during reboot is cured by adding
>> regulator-boot-on.
>>
>> This solutions has been fairly widely reviewed and tested.
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> Reviewed by: Robin Murphy <robin.murphy@arm.com>
>> Reviewed by: Jonas Karlman <jonas@kwiboo.se>
>> Test by: TheSaint @ ArchLinux Arm
> 
> please follow patch submission guidelines, here it would be
> Tested-by: ... with an actual Name + mail address
> 
> Also I did try to go through the way big mail thread but didn't
> find an actual "Reviewed-by" from Robin Murphy, similar to what
> he pointed out in patch2

Ah, I didn't get a direct CC of this patch so I hadn't spotted that - 
FWIW though, I'm happy with Doug's reasoning for "broken-cd" being the 
most robust solution for now, so feel free to keep

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

for this one.

Cheers,
Robin.

> 
> Other than that and including the past discussions, this looks good.
> 
> 
> Heiko
> 
>> ---
>>   arch/arm/boot/dts/rk3288-tinker.dtsi | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> index aa107ee41b8b..ef653c3209bc 100644
>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> @@ -254,6 +254,7 @@
>>   			};
>>   
>>   			vccio_sd: LDO_REG5 {
>> +				regulator-boot-on;
>>   				regulator-min-microvolt = <1800000>;
>>   				regulator-max-microvolt = <3300000>;
>>   				regulator-name = "vccio_sd";
>> @@ -430,7 +431,7 @@
>>   	bus-width = <4>;
>>   	cap-mmc-highspeed;
>>   	cap-sd-highspeed;
>> -	card-detect-delay = <200>;
>> +	broken-cd;
>>   	disable-wp;			/* wp not hooked up */
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>>
> 
> 
> 
> 

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

Re: [PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[Heiko Stuebner]

Hi Jonas,

Am Samstag, 9. März 2019, 16:39:21 CET schrieb David Summers:
> The Problem:
> 
> On ASUS Tinker Board S, when booting from the eMMC, and there is card
> in the sd slot, there are constant errors.
> 
> Also when warm reboot, uboot can not access the sd slot
> 
> Cause:
> 
> Identified by Robin Murphy @ ARM. The Card Detect on rk3288
> devices is pulled up by vccio-sd; so when the regulator powers this
> off, card detect gives spurious errors. A second problem, is during
> power down, vccio-sd apprears to be powered down. This causes a
> problem when warm rebooting from the sd card. This was identified by
> Jonas Karlman.
> 
> History:
> 
> A common fault on these rk3288 board, which impliment the reference
> design.
> 
> When this arose before:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.html
> 
> And Ulf and Jaehoon clearly said this was a broken card detect design,
> which should be solved via polling
> 
> Solution:
> 
> Hence broken-cd is set as a property. This cures the errors. The
> powering down of vccio-sd during reboot is cured by adding
> regulator-boot-on.
> 
> This solutions has been fairly widely reviewed and tested.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Reviewed by: Robin Murphy <robin.murphy@arm.com>
> Reviewed by: Jonas Karlman <jonas@kwiboo.se>

in v2, you gave a
Tested-by: Jonas Karlman <jonas@kwiboo.se>
it seems, which somehow transformed into a reviewed-by in v3.

V3 did change a bit in its approach - for the better, but do you approve
of adding that Reviewed-by above (and maybe also providing a Tested-by
for the new approach)?

Thanks
Heiko



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

Re: [PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[David Summers]

On 12/03/2019 14:22, Heiko Stuebner wrote:
> Hi Jonas,
>
> Am Samstag, 9. März 2019, 16:39:21 CET schrieb David Summers:
>> The Problem:
>>
>> On ASUS Tinker Board S, when booting from the eMMC, and there is card
>> in the sd slot, there are constant errors.
>>
>> Also when warm reboot, uboot can not access the sd slot
>>
>> Cause:
>>
>> Identified by Robin Murphy @ ARM. The Card Detect on rk3288
>> devices is pulled up by vccio-sd; so when the regulator powers this
>> off, card detect gives spurious errors. A second problem, is during
>> power down, vccio-sd apprears to be powered down. This causes a
>> problem when warm rebooting from the sd card. This was identified by
>> Jonas Karlman.
>>
>> History:
>>
>> A common fault on these rk3288 board, which impliment the reference
>> design.
>>
>> When this arose before:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.html
>>
>> And Ulf and Jaehoon clearly said this was a broken card detect design,
>> which should be solved via polling
>>
>> Solution:
>>
>> Hence broken-cd is set as a property. This cures the errors. The
>> powering down of vccio-sd during reboot is cured by adding
>> regulator-boot-on.
>>
>> This solutions has been fairly widely reviewed and tested.
>>
>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>> Reviewed by: Robin Murphy <robin.murphy@arm.com>
>> Reviewed by: Jonas Karlman <jonas@kwiboo.se>
> in v2, you gave a
> Tested-by: Jonas Karlman <jonas@kwiboo.se>
> it seems, which somehow transformed into a reviewed-by in v3.
>
> V3 did change a bit in its approach - for the better, but do you approve
> of adding that Reviewed-by above (and maybe also providing a Tested-by
> for the new approach)?
>
> Thanks
> Heiko
>
>
Hi all,

Yes apologies for these signed-off lines etc wrong. Its still a learning 
experiment for me!

Both Robin and Jonas added a lot to Patch, as explained in the write up. 
Robin came up with the cause of the fault, and Jonas noticed a second 
fault. So the question is to give these two their due. I think what they 
both added was important.

Thanks Robin for the official "Reviewed-by".

Jonas tested the second version, which kept power on vccio-sd all the 
time, whereas v1 and v3 cured the problem with broken-cd. So although 
both fixed the problem, they way performed is different. So don't think 
I can say Jonas Tested-by v3.

As for the tested by "TheSaint @ ArchLinux Arm", he actually tested just 
above every single version of the patch, and a whole lot more before it 
was sent in - he is our ASUS Tinker Board user on arch. He doesn't 
really want his email in the open, but if push comes to shove he'll 
allow it. Question is do you need this for the Patch to pass?

Heiko, I'm happy to change the sign off etc, and resent the patch (as 
v4). But would be the same patch. Think the question is what is best for 
you. Don't want to send unneeded email ... anyway let me know (private 
email?) and I'll do whatever is best for you.

Regards,

David.

P.S. Eventually I'll get better at these patches , alas the day job 
keeps me too busy - and I forget the rules :(


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

Re: [PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[Heiko Stübner]

Hi David,

Am Dienstag, 12. März 2019, 21:34:00 CET schrieb David Summers:
> On 12/03/2019 14:22, Heiko Stuebner wrote:
> > Hi Jonas,
> > 
> > Am Samstag, 9. März 2019, 16:39:21 CET schrieb David Summers:
> >> The Problem:
> >> 
> >> On ASUS Tinker Board S, when booting from the eMMC, and there is card
> >> in the sd slot, there are constant errors.
> >> 
> >> Also when warm reboot, uboot can not access the sd slot
> >> 
> >> Cause:
> >> 
> >> Identified by Robin Murphy @ ARM. The Card Detect on rk3288
> >> devices is pulled up by vccio-sd; so when the regulator powers this
> >> off, card detect gives spurious errors. A second problem, is during
> >> power down, vccio-sd apprears to be powered down. This causes a
> >> problem when warm rebooting from the sd card. This was identified by
> >> Jonas Karlman.
> >> 
> >> History:
> >> 
> >> A common fault on these rk3288 board, which impliment the reference
> >> design.
> >> 
> >> When this arose before:
> >> 
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.
> >> html
> >> 
> >> And Ulf and Jaehoon clearly said this was a broken card detect design,
> >> which should be solved via polling
> >> 
> >> Solution:
> >> 
> >> Hence broken-cd is set as a property. This cures the errors. The
> >> powering down of vccio-sd during reboot is cured by adding
> >> regulator-boot-on.
> >> 
> >> This solutions has been fairly widely reviewed and tested.
> >> 
> >> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> >> Reviewed by: Robin Murphy <robin.murphy@arm.com>
> >> Reviewed by: Jonas Karlman <jonas@kwiboo.se>
> > 
> > in v2, you gave a
> > Tested-by: Jonas Karlman <jonas@kwiboo.se>
> > it seems, which somehow transformed into a reviewed-by in v3.
> > 
> > V3 did change a bit in its approach - for the better, but do you approve
> > of adding that Reviewed-by above (and maybe also providing a Tested-by
> > for the new approach)?
> > 
> > Thanks
> > Heiko
> 
> Hi all,
> 
> Yes apologies for these signed-off lines etc wrong. Its still a learning
> experiment for me!
> 
> Both Robin and Jonas added a lot to Patch, as explained in the write up.
> Robin came up with the cause of the fault, and Jonas noticed a second
> fault. So the question is to give these two their due. I think what they
> both added was important.
> 
> Thanks Robin for the official "Reviewed-by".
> 
> Jonas tested the second version, which kept power on vccio-sd all the
> time, whereas v1 and v3 cured the problem with broken-cd. So although
> both fixed the problem, they way performed is different. So don't think
> I can say Jonas Tested-by v3.

We'll just give Jonas a bit more time to reply then :-) .


> As for the tested by "TheSaint @ ArchLinux Arm", he actually tested just
> above every single version of the patch, and a whole lot more before it
> was sent in - he is our ASUS Tinker Board user on arch. He doesn't
> really want his email in the open, but if push comes to shove he'll
> allow it. Question is do you need this for the Patch to pass?

No, that is not necessary. I'll just drop the line when applying.
In general for a tag to mean something we need the Name, but any
tags other than Signed-off-by are optional anyway.


> Heiko, I'm happy to change the sign off etc, and resent the patch (as
> v4). But would be the same patch. Think the question is what is best for
> you. Don't want to send unneeded email ... anyway let me know (private
> email?) and I'll do whatever is best for you.

No, re-sending just to correct tags is not necessary in _my_ case
as I generally just fix up the relevant lines myself when applying.
Just keep in mind, other maintainers may handle this differently :-) .


> P.S. Eventually I'll get better at these patches , alas the day job
> keeps me too busy - and I forget the rules :(

Really no problem, it's always a learning experience.
So don't worry too much :-) .


Heiko



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

Re: [PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[Jonas Karlman]

On 2019-03-12 21:52, Heiko Stübner wrote:
> Hi David,
>
> Am Dienstag, 12. März 2019, 21:34:00 CET schrieb David Summers:
>> On 12/03/2019 14:22, Heiko Stuebner wrote:
>>> Hi Jonas,
>>>
>>> Am Samstag, 9. März 2019, 16:39:21 CET schrieb David Summers:
>>>> The Problem:
>>>>
>>>> On ASUS Tinker Board S, when booting from the eMMC, and there is card
>>>> in the sd slot, there are constant errors.
>>>>
>>>> Also when warm reboot, uboot can not access the sd slot
>>>>
>>>> Cause:
>>>>
>>>> Identified by Robin Murphy @ ARM. The Card Detect on rk3288
>>>> devices is pulled up by vccio-sd; so when the regulator powers this
>>>> off, card detect gives spurious errors. A second problem, is during
>>>> power down, vccio-sd apprears to be powered down. This causes a
>>>> problem when warm rebooting from the sd card. This was identified by
>>>> Jonas Karlman.
>>>>
>>>> History:
>>>>
>>>> A common fault on these rk3288 board, which impliment the reference
>>>> design.
>>>>
>>>> When this arose before:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.
>>>> html
>>>>
>>>> And Ulf and Jaehoon clearly said this was a broken card detect design,
>>>> which should be solved via polling
>>>>
>>>> Solution:
>>>>
>>>> Hence broken-cd is set as a property. This cures the errors. The
>>>> powering down of vccio-sd during reboot is cured by adding
>>>> regulator-boot-on.
>>>>
>>>> This solutions has been fairly widely reviewed and tested.
>>>>
>>>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>>>> Reviewed by: Robin Murphy <robin.murphy@arm.com>
>>>> Reviewed by: Jonas Karlman <jonas@kwiboo.se>
>>> in v2, you gave a
>>> Tested-by: Jonas Karlman <jonas@kwiboo.se>
>>> it seems, which somehow transformed into a reviewed-by in v3.
>>>
>>> V3 did change a bit in its approach - for the better, but do you approve
>>> of adding that Reviewed-by above (and maybe also providing a Tested-by
>>> for the new approach)?
>>>
>>> Thanks
>>> Heiko
>> Hi all,
>>
>> Yes apologies for these signed-off lines etc wrong. Its still a learning
>> experiment for me!
>>
>> Both Robin and Jonas added a lot to Patch, as explained in the write up.
>> Robin came up with the cause of the fault, and Jonas noticed a second
>> fault. So the question is to give these two their due. I think what they
>> both added was important.
>>
>> Thanks Robin for the official "Reviewed-by".
>>
>> Jonas tested the second version, which kept power on vccio-sd all the
>> time, whereas v1 and v3 cured the problem with broken-cd. So although
>> both fixed the problem, they way performed is different. So don't think
>> I can say Jonas Tested-by v3.
> We'll just give Jonas a bit more time to reply then :-) .

I have now tested v3 on a Tinker Board and a Tinker Board S using u-boot 2019.01 on sd-card,
both devices can now soft reboot when running bootloader from sd-card thanks to the "regulator-boot-on".

I am happy to add both tags :-)

Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Jonas Karlman <jonas@kwiboo.se>

Regards,
Jonas

>
>> As for the tested by "TheSaint @ ArchLinux Arm", he actually tested just
>> above every single version of the patch, and a whole lot more before it
>> was sent in - he is our ASUS Tinker Board user on arch. He doesn't
>> really want his email in the open, but if push comes to shove he'll
>> allow it. Question is do you need this for the Patch to pass?
> No, that is not necessary. I'll just drop the line when applying.
> In general for a tag to mean something we need the Name, but any
> tags other than Signed-off-by are optional anyway.
>
>
>> Heiko, I'm happy to change the sign off etc, and resent the patch (as
>> v4). But would be the same patch. Think the question is what is best for
>> you. Don't want to send unneeded email ... anyway let me know (private
>> email?) and I'll do whatever is best for you.
> No, re-sending just to correct tags is not necessary in _my_ case
> as I generally just fix up the relevant lines myself when applying.
> Just keep in mind, other maintainers may handle this differently :-) .
>
>
>> P.S. Eventually I'll get better at these patches , alas the day job
>> keeps me too busy - and I forget the rules :(
> Really no problem, it's always a learning experience.
> So don't worry too much :-) .
>
>
> Heiko
>
>


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

Re: [PATCH v3 1/3] arm: dts: rk3288-tinker.dtsi: Fix SD card detection

[Heiko Stübner]

Am Samstag, 9. März 2019, 16:39:21 CET schrieb David Summers:
> The Problem:
> 
> On ASUS Tinker Board S, when booting from the eMMC, and there is card
> in the sd slot, there are constant errors.
> 
> Also when warm reboot, uboot can not access the sd slot
> 
> Cause:
> 
> Identified by Robin Murphy @ ARM. The Card Detect on rk3288
> devices is pulled up by vccio-sd; so when the regulator powers this
> off, card detect gives spurious errors. A second problem, is during
> power down, vccio-sd apprears to be powered down. This causes a
> problem when warm rebooting from the sd card. This was identified by
> Jonas Karlman.
> 
> History:
> 
> A common fault on these rk3288 board, which impliment the reference
> design.
> 
> When this arose before:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281153.htm
> l
> 
> And Ulf and Jaehoon clearly said this was a broken card detect design,
> which should be solved via polling
> 
> Solution:
> 
> Hence broken-cd is set as a property. This cures the errors. The
> powering down of vccio-sd during reboot is cured by adding
> regulator-boot-on.
> 
> This solutions has been fairly widely reviewed and tested.
> 
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> Reviewed by: Robin Murphy <robin.murphy@arm.com>
> Reviewed by: Jonas Karlman <jonas@kwiboo.se>
> Test by: TheSaint @ ArchLinux Arm

applied as fix for 5.1 with the following modifications:
- new subject: "ARM: dts: rockchip: Fix SD card detection on rk3288-tinker"
  to match the subsystem
- adapted Reviewed and Tested tags as collected from involved parties
- added Fixes and Cc-stable tags (pointing to the dtsi-split only to ease
  load of stable maintainers, as hopefully most people will use somewhat
  recent kernels on sbcs]


Heiko



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