[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.

[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

[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";
> 

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.

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.

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

[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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> ---
>  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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
>> ---
>>   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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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 1/3 v2] 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 no
card sd slot, then there are constant errors.

Cause:

Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
rk808 on the Tinker Board and Tinker Board S has many regulators, one
vccio_sd powers the IO for the sd card. Unfortunatly this is also used
in the card detect. Now when no card is install, the regulator is
powered down. This means that the card detect floats, and this means
random card detection.

The Solution:

Make sure that the sd IO is always powered, this means card detection
is always active, which is what should be done on a board with an sd
slot, which both the Tinker Board and Tinker Board S are. Hence change
is made to the .dtsi which takes effect on all Tinker Boards as
required.

The change also adds "regulator-boot-on" the Tinker Board boot from
uboot, and the sd card is always one option. Hence the IO must be
powered in uboot, and so setting this flag.

Also removed is "disable-wp" the micro sd card which are used have no
write  protection, so the concept doesn't mean anything, and the
Tinker Boards work without this. Hence it is removed to simply.

This change came from ArchLinux Arm, but we note it is the fix also
used by Armbian:

https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v5.0/DTS/0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch

Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
---
 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..6b7e55085b0c 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
+++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
@@ -254,6 +254,8 @@
 			};
 
 			vccio_sd: LDO_REG5 {
+				regulator-always-on;
+				regulator-boot-on;
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-name = "vccio_sd";
@@ -431,7 +433,6 @@
 	cap-mmc-highspeed;
 	cap-sd-highspeed;
 	card-detect-delay = <200>;
-	disable-wp;			/* wp not hooked up */
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
 	status = "okay";
-- 
beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org

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

[Jonas Karlman]

On 2019-02-22 19:47, David Summers wrote:
> The Problem:
>
> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> card sd slot, then there are constant errors.
>
> Cause:
>
> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> in the card detect. Now when no card is install, the regulator is
> powered down. This means that the card detect floats, and this means
> random card detection.
>
> The Solution:
>
> Make sure that the sd IO is always powered, this means card detection
> is always active, which is what should be done on a board with an sd
> slot, which both the Tinker Board and Tinker Board S are. Hence change
> is made to the .dtsi which takes effect on all Tinker Boards as
> required.
>
> The change also adds "regulator-boot-on" the Tinker Board boot from
> uboot, and the sd card is always one option. Hence the IO must be
> powered in uboot, and so setting this flag.
>
> Also removed is "disable-wp" the micro sd card which are used have no
> write  protection, so the concept doesn't mean anything, and the
> Tinker Boards work without this. Hence it is removed to simply.
>
> This change came from ArchLinux Arm, but we note it is the fix also
> used by Armbian:
>
> https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v5.0/DTS/0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch
>
> Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> ---
>  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..6b7e55085b0c 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -254,6 +254,8 @@
>  			};
>  
>  			vccio_sd: LDO_REG5 {
> +				regulator-always-on;
> +				regulator-boot-on;
>  				regulator-min-microvolt = <1800000>;
>  				regulator-max-microvolt = <3300000>;
>  				regulator-name = "vccio_sd";
> @@ -431,7 +433,6 @@
>  	cap-mmc-highspeed;
>  	cap-sd-highspeed;
>  	card-detect-delay = <200>;
> -	disable-wp;			/* wp not hooked up */

I think disable-wp correctly describes that wp is not expected to work and should not be removed.

>From comment in mmc_sd_get_ro():
"Some systems don't feature a write-protect pin and don't need one.
E.g. because they only have micro-SD card slot. For those systems
assume that the SD card is always read-write."

Without disable-wp core will call dw_mci_get_ro() to get wp status.


This patch also fixes reboot when booting from sd-card and having emmc zeroed out.

Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>

Regards,
Jonas

>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>  	status = "okay";

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

[Jonas Karlman]

On 2019-02-22 19:47, David Summers wrote:
> The Problem:
>
> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> card sd slot, then there are constant errors.
>
> Cause:
>
> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> in the card detect. Now when no card is install, the regulator is
> powered down. This means that the card detect floats, and this means
> random card detection.
>
> The Solution:
>
> Make sure that the sd IO is always powered, this means card detection
> is always active, which is what should be done on a board with an sd
> slot, which both the Tinker Board and Tinker Board S are. Hence change
> is made to the .dtsi which takes effect on all Tinker Boards as
> required.
>
> The change also adds "regulator-boot-on" the Tinker Board boot from
> uboot, and the sd card is always one option. Hence the IO must be
> powered in uboot, and so setting this flag.
>
> Also removed is "disable-wp" the micro sd card which are used have no
> write  protection, so the concept doesn't mean anything, and the
> Tinker Boards work without this. Hence it is removed to simply.
>
> This change came from ArchLinux Arm, but we note it is the fix also
> used by Armbian:
>
> https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v5.0/DTS/0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch
>
> Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> ---
>  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..6b7e55085b0c 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -254,6 +254,8 @@
>  			};
>  
>  			vccio_sd: LDO_REG5 {
> +				regulator-always-on;
> +				regulator-boot-on;
>  				regulator-min-microvolt = <1800000>;
>  				regulator-max-microvolt = <3300000>;
>  				regulator-name = "vccio_sd";
> @@ -431,7 +433,6 @@
>  	cap-mmc-highspeed;
>  	cap-sd-highspeed;
>  	card-detect-delay = <200>;
> -	disable-wp;			/* wp not hooked up */

I think disable-wp correctly describes that wp is not expected to work and should not be removed.

From comment in mmc_sd_get_ro():
"Some systems don't feature a write-protect pin and don't need one.
E.g. because they only have micro-SD card slot. For those systems
assume that the SD card is always read-write."

Without disable-wp core will call dw_mci_get_ro() to get wp status.


This patch also fixes reboot when booting from sd-card and having emmc zeroed out.

Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>

Regards,
Jonas

>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>  	status = "okay";

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

[David Summers]

On 24/02/2019 19:26, Jonas Karlman wrote:
> On 2019-02-22 19:47, David Summers wrote:
>> The Problem:
>>
>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
>> card sd slot, then there are constant errors.
>>
>> Cause:
>>
>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
>> in the card detect. Now when no card is install, the regulator is
>> powered down. This means that the card detect floats, and this means
>> random card detection.
>>
>> The Solution:
>>
>> Make sure that the sd IO is always powered, this means card detection
>> is always active, which is what should be done on a board with an sd
>> slot, which both the Tinker Board and Tinker Board S are. Hence change
>> is made to the .dtsi which takes effect on all Tinker Boards as
>> required.
>>
>> The change also adds "regulator-boot-on" the Tinker Board boot from
>> uboot, and the sd card is always one option. Hence the IO must be
>> powered in uboot, and so setting this flag.
>>
>> Also removed is "disable-wp" the micro sd card which are used have no
>> write  protection, so the concept doesn't mean anything, and the
>> Tinker Boards work without this. Hence it is removed to simply.
>>
>> This change came from ArchLinux Arm, but we note it is the fix also
>> used by Armbian:
>>
>> https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v5.0/DTS/0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch
>>
>> Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
>> ---
>>   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..6b7e55085b0c 100644
>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>> @@ -254,6 +254,8 @@
>>   			};
>>   
>>   			vccio_sd: LDO_REG5 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>>   				regulator-min-microvolt = <1800000>;
>>   				regulator-max-microvolt = <3300000>;
>>   				regulator-name = "vccio_sd";
>> @@ -431,7 +433,6 @@
>>   	cap-mmc-highspeed;
>>   	cap-sd-highspeed;
>>   	card-detect-delay = <200>;
>> -	disable-wp;			/* wp not hooked up */
> I think disable-wp correctly describes that wp is not expected to work and should not be removed.
>
>  From comment in mmc_sd_get_ro():
> "Some systems don't feature a write-protect pin and don't need one.
> E.g. because they only have micro-SD card slot. For those systems
> assume that the SD card is always read-write."
>
> Without disable-wp core will call dw_mci_get_ro() to get wp status.
>
>
> This patch also fixes reboot when booting from sd-card and having emmc zeroed out.
>
> Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
>
> Regards,
> Jonas
>
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>>   	status = "okay";

Hi Jonas,

Thanks for testing - did you get an error with "disable-wp" ?

We tested this with @TheSaint On ArchLinux Arm, and it worked!

With the "regulator-boot-on" and on reboot, it should keep power on the 
sd card - so reboot should work.

Regards,

David.

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

[Jonas Karlman]

On 2019-02-24 20:35, David Summers wrote:
> On 24/02/2019 19:26, Jonas Karlman wrote:
>> On 2019-02-22 19:47, David Summers wrote:
>>> The Problem:
>>>
>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
>>> card sd slot, then there are constant errors.
>>>
>>> Cause:
>>>
>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
>>> in the card detect. Now when no card is install, the regulator is
>>> powered down. This means that the card detect floats, and this means
>>> random card detection.
>>>
>>> The Solution:
>>>
>>> Make sure that the sd IO is always powered, this means card detection
>>> is always active, which is what should be done on a board with an sd
>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
>>> is made to the .dtsi which takes effect on all Tinker Boards as
>>> required.
>>>
>>> The change also adds "regulator-boot-on" the Tinker Board boot from
>>> uboot, and the sd card is always one option. Hence the IO must be
>>> powered in uboot, and so setting this flag.
>>>
>>> Also removed is "disable-wp" the micro sd card which are used have no
>>> write  protection, so the concept doesn't mean anything, and the
>>> Tinker Boards work without this. Hence it is removed to simply.
>>>
>>> This change came from ArchLinux Arm, but we note it is the fix also
>>> used by Armbian:
>>>
>>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMiouyouyou%2FRockMyy%2Fblob%2Fmaster%2Fpatches%2Fkernel%2Fv5.0%2FDTS%2F0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch&data=02%7C01%7C%7Cf5937082939e4163c84b08d69a8f3b61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636866337295767294&sdata=tK8QE3bsG9LW%2FJcvFzLKa8%2BPj5u%2F8exbEn8m2vqKly0%3D&reserved=0
>>>
>>> Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
>>> ---
>>>   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..6b7e55085b0c 100644
>>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>>> @@ -254,6 +254,8 @@
>>>   			};
>>>   
>>>   			vccio_sd: LDO_REG5 {
>>> +				regulator-always-on;
>>> +				regulator-boot-on;
>>>   				regulator-min-microvolt = <1800000>;
>>>   				regulator-max-microvolt = <3300000>;
>>>   				regulator-name = "vccio_sd";
>>> @@ -431,7 +433,6 @@
>>>   	cap-mmc-highspeed;
>>>   	cap-sd-highspeed;
>>>   	card-detect-delay = <200>;
>>> -	disable-wp;			/* wp not hooked up */
>> I think disable-wp correctly describes that wp is not expected to work and should not be removed.
>>
>>  From comment in mmc_sd_get_ro():
>> "Some systems don't feature a write-protect pin and don't need one.
>> E.g. because they only have micro-SD card slot. For those systems
>> assume that the SD card is always read-write."
>>
>> Without disable-wp core will call dw_mci_get_ro() to get wp status.
>>
>>
>> This patch also fixes reboot when booting from sd-card and having emmc zeroed out.
>>
>> Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
>>
>> Regards,
>> Jonas
>>
>>>   	pinctrl-names = "default";
>>>   	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>>>   	status = "okay";
> Hi Jonas,
>
> Thanks for testing - did you get an error with "disable-wp" ?
>
> We tested this with @TheSaint On ArchLinux Arm, and it worked!
>
> With the "regulator-boot-on" and on reboot, it should keep power on the 
> sd card - so reboot should work.

I tested both with and without "disable-wp" removed and both works without error.
SD-card reboots now works as it should thanks to "regulator-always-on" and "regulator-boot-on", I only tested using both.

On a side note I have also been testing [1] to make reboot with UHS signal voltage work and will send out a RFC v2
after I have concluded testing on my other devices supporting UHS signal voltage.

[1] https://github.com/Kwiboo/linux-rockchip/compare/patch-rk-5.x-tinker-uhs%5E%5E%5E...patch-rk-5.x-tinker-uhs

Regards,
Jonas

>
> Regards,
>
> David.
>
>

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

[David Summers]

On 24/02/2019 19:56, Jonas Karlman wrote:
> On 2019-02-24 20:35, David Summers wrote:
>> On 24/02/2019 19:26, Jonas Karlman wrote:
>>> On 2019-02-22 19:47, David Summers wrote:
>>>> The Problem:
>>>>
>>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
>>>> card sd slot, then there are constant errors.
>>>>
>>>> Cause:
>>>>
>>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
>>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
>>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
>>>> in the card detect. Now when no card is install, the regulator is
>>>> powered down. This means that the card detect floats, and this means
>>>> random card detection.
>>>>
>>>> The Solution:
>>>>
>>>> Make sure that the sd IO is always powered, this means card detection
>>>> is always active, which is what should be done on a board with an sd
>>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
>>>> is made to the .dtsi which takes effect on all Tinker Boards as
>>>> required.
>>>>
>>>> The change also adds "regulator-boot-on" the Tinker Board boot from
>>>> uboot, and the sd card is always one option. Hence the IO must be
>>>> powered in uboot, and so setting this flag.
>>>>
>>>> Also removed is "disable-wp" the micro sd card which are used have no
>>>> write  protection, so the concept doesn't mean anything, and the
>>>> Tinker Boards work without this. Hence it is removed to simply.
>>>>
>>>> This change came from ArchLinux Arm, but we note it is the fix also
>>>> used by Armbian:
>>>>
>>>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMiouyouyou%2FRockMyy%2Fblob%2Fmaster%2Fpatches%2Fkernel%2Fv5.0%2FDTS%2F0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch&data=02%7C01%7C%7Cf5937082939e4163c84b08d69a8f3b61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636866337295767294&sdata=tK8QE3bsG9LW%2FJcvFzLKa8%2BPj5u%2F8exbEn8m2vqKly0%3D&reserved=0
>>>>
>>>> Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
>>>> ---
>>>>    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..6b7e55085b0c 100644
>>>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>>>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>>>> @@ -254,6 +254,8 @@
>>>>    			};
>>>>    
>>>>    			vccio_sd: LDO_REG5 {
>>>> +				regulator-always-on;
>>>> +				regulator-boot-on;
>>>>    				regulator-min-microvolt = <1800000>;
>>>>    				regulator-max-microvolt = <3300000>;
>>>>    				regulator-name = "vccio_sd";
>>>> @@ -431,7 +433,6 @@
>>>>    	cap-mmc-highspeed;
>>>>    	cap-sd-highspeed;
>>>>    	card-detect-delay = <200>;
>>>> -	disable-wp;			/* wp not hooked up */
>>> I think disable-wp correctly describes that wp is not expected to work and should not be removed.
>>>
>>>   From comment in mmc_sd_get_ro():
>>> "Some systems don't feature a write-protect pin and don't need one.
>>> E.g. because they only have micro-SD card slot. For those systems
>>> assume that the SD card is always read-write."
>>>
>>> Without disable-wp core will call dw_mci_get_ro() to get wp status.
>>>
>>>
>>> This patch also fixes reboot when booting from sd-card and having emmc zeroed out.
>>>
>>> Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
>>>
>>> Regards,
>>> Jonas
>>>
>>>>    	pinctrl-names = "default";
>>>>    	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>>>>    	status = "okay";
>> Hi Jonas,
>>
>> Thanks for testing - did you get an error with "disable-wp" ?
>>
>> We tested this with @TheSaint On ArchLinux Arm, and it worked!
>>
>> With the "regulator-boot-on" and on reboot, it should keep power on the
>> sd card - so reboot should work.
> I tested both with and without "disable-wp" removed and both works without error.
> SD-card reboots now works as it should thanks to "regulator-always-on" and "regulator-boot-on", I only tested using both.
>
> On a side note I have also been testing [1] to make reboot with UHS signal voltage work and will send out a RFC v2
> after I have concluded testing on my other devices supporting UHS signal voltage.
>
> [1] https://github.com/Kwiboo/linux-rockchip/compare/patch-rk-5.x-tinker-uhs%5E%5E%5E...patch-rk-5.x-tinker-uhs
>
> Regards,
> Jonas

Thanks.

Glad your are testing - and I hope the uhs tests work.

Alas for us to test uhs - and our user on Arch isn't so experienced. I 
could push him to try different speeds - but to be honest I expect it to 
be beyond his comfort zone.

But its good to here you confirm "disable-wp" works. To my mind it says 
we are sure that  all three changes in the patch are are correct.

Hopefully this will be straight forward to Heiko to accept. Its the 
simple patch of the 3 to accept ;)

Regards,

David.

>> Regards,
>>
>> David.
>>
>>

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

[Heiko Stübner]

Am Sonntag, 24. Februar 2019, 21:10:50 CET schrieb David Summers:
> On 24/02/2019 19:56, Jonas Karlman wrote:
> > On 2019-02-24 20:35, David Summers wrote:
> >> On 24/02/2019 19:26, Jonas Karlman wrote:
> >>> On 2019-02-22 19:47, David Summers wrote:
> >>>> The Problem:
> >>>> 
> >>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> >>>> card sd slot, then there are constant errors.
> >>>> 
> >>>> Cause:
> >>>> 
> >>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> >>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> >>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> >>>> in the card detect. Now when no card is install, the regulator is
> >>>> powered down. This means that the card detect floats, and this means
> >>>> random card detection.
> >>>> 
> >>>> The Solution:
> >>>> 
> >>>> Make sure that the sd IO is always powered, this means card detection
> >>>> is always active, which is what should be done on a board with an sd
> >>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
> >>>> is made to the .dtsi which takes effect on all Tinker Boards as
> >>>> required.
> >>>> 
> >>>> The change also adds "regulator-boot-on" the Tinker Board boot from
> >>>> uboot, and the sd card is always one option. Hence the IO must be
> >>>> powered in uboot, and so setting this flag.
> >>>> 
> >>>> Also removed is "disable-wp" the micro sd card which are used have no
> >>>> write  protection, so the concept doesn't mean anything, and the
> >>>> Tinker Boards work without this. Hence it is removed to simply.
> >>>> 
> >>>> This change came from ArchLinux Arm, but we note it is the fix also
> >>>> used by Armbian:
> >>>> 
> >>>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> >>>> b.com%2FMiouyouyou%2FRockMyy%2Fblob%2Fmaster%2Fpatches%2Fkernel%2Fv5.0%
> >>>> 2FDTS%2F0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch&
> >>>> amp;data=02%7C01%7C%7Cf5937082939e4163c84b08d69a8f3b61%7C84df9e7fe9f640
> >>>> afb435aaaaaaaaaaaa%7C1%7C0%7C636866337295767294&sdata=tK8QE3bsG9LW%
> >>>> 2FJcvFzLKa8%2BPj5u%2F8exbEn8m2vqKly0%3D&reserved=0
> >>>> 
> >>>> Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> >>>> ---
> >>>> 
> >>>>    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..6b7e55085b0c 100644
> >>>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> >>>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> >>>> @@ -254,6 +254,8 @@
> >>>> 
> >>>>    			};
> >>>>    			
> >>>>    			vccio_sd: LDO_REG5 {
> >>>> 
> >>>> +				regulator-always-on;
> >>>> +				regulator-boot-on;
> >>>> 
> >>>>    				regulator-min-microvolt = <1800000>;
> >>>>    				regulator-max-microvolt = <3300000>;
> >>>>    				regulator-name = "vccio_sd";
> >>>> 
> >>>> @@ -431,7 +433,6 @@
> >>>> 
> >>>>    	cap-mmc-highspeed;
> >>>>    	cap-sd-highspeed;
> >>>>    	card-detect-delay = <200>;
> >>>> 
> >>>> -	disable-wp;			/* wp not hooked up */
> >>> 
> >>> I think disable-wp correctly describes that wp is not expected to work
> >>> and should not be removed.>>> 
> >>>   From comment in mmc_sd_get_ro():
> >>> "Some systems don't feature a write-protect pin and don't need one.
> >>> E.g. because they only have micro-SD card slot. For those systems
> >>> assume that the SD card is always read-write."
> >>> 
> >>> Without disable-wp core will call dw_mci_get_ro() to get wp status.
> >>> 
> >>> 
> >>> This patch also fixes reboot when booting from sd-card and having emmc
> >>> zeroed out.
> >>> 
> >>> Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
> >>> 
> >>> Regards,
> >>> Jonas
> >>> 
> >>>>    	pinctrl-names = "default";
> >>>>    	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
> >>>>    	status = "okay";
> >> 
> >> Hi Jonas,
> >> 
> >> Thanks for testing - did you get an error with "disable-wp" ?
> >> 
> >> We tested this with @TheSaint On ArchLinux Arm, and it worked!
> >> 
> >> With the "regulator-boot-on" and on reboot, it should keep power on the
> >> sd card - so reboot should work.
> > 
> > I tested both with and without "disable-wp" removed and both works without
> > error. SD-card reboots now works as it should thanks to
> > "regulator-always-on" and "regulator-boot-on", I only tested using both.
> > 
> > On a side note I have also been testing [1] to make reboot with UHS signal
> > voltage work and will send out a RFC v2 after I have concluded testing on
> > my other devices supporting UHS signal voltage.
> > 
> > [1]
> > https://github.com/Kwiboo/linux-rockchip/compare/patch-rk-5.x-tinker-uhs%
> > 5E%5E%5E...patch-rk-5.x-tinker-uhs
> > 
> > Regards,
> > Jonas
> 
> Thanks.
> 
> Glad your are testing - and I hope the uhs tests work.
> 
> Alas for us to test uhs - and our user on Arch isn't so experienced. I
> could push him to try different speeds - but to be honest I expect it to
> be beyond his comfort zone.
> 
> But its good to here you confirm "disable-wp" works. To my mind it says
> we are sure that  all three changes in the patch are are correct.
> 
> Hopefully this will be straight forward to Heiko to accept. Its the
> simple patch of the 3 to accept ;)

>From Jonas' explanation, I'd guess we want disable-wp to stay in the node,
and not remove it as it tells the system, that "there is no write protect 
status available" hence it doesn't need to check for it.


Heiko

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

[Heiko Stübner]

Am Sonntag, 24. Februar 2019, 21:10:50 CET schrieb David Summers:
> On 24/02/2019 19:56, Jonas Karlman wrote:
> > On 2019-02-24 20:35, David Summers wrote:
> >> On 24/02/2019 19:26, Jonas Karlman wrote:
> >>> On 2019-02-22 19:47, David Summers wrote:
> >>>> The Problem:
> >>>> 
> >>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> >>>> card sd slot, then there are constant errors.
> >>>> 
> >>>> Cause:
> >>>> 
> >>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> >>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> >>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> >>>> in the card detect. Now when no card is install, the regulator is
> >>>> powered down. This means that the card detect floats, and this means
> >>>> random card detection.
> >>>> 
> >>>> The Solution:
> >>>> 
> >>>> Make sure that the sd IO is always powered, this means card detection
> >>>> is always active, which is what should be done on a board with an sd
> >>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
> >>>> is made to the .dtsi which takes effect on all Tinker Boards as
> >>>> required.
> >>>> 
> >>>> The change also adds "regulator-boot-on" the Tinker Board boot from
> >>>> uboot, and the sd card is always one option. Hence the IO must be
> >>>> powered in uboot, and so setting this flag.
> >>>> 
> >>>> Also removed is "disable-wp" the micro sd card which are used have no
> >>>> write  protection, so the concept doesn't mean anything, and the
> >>>> Tinker Boards work without this. Hence it is removed to simply.
> >>>> 
> >>>> This change came from ArchLinux Arm, but we note it is the fix also
> >>>> used by Armbian:
> >>>> 
> >>>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> >>>> b.com%2FMiouyouyou%2FRockMyy%2Fblob%2Fmaster%2Fpatches%2Fkernel%2Fv5.0%
> >>>> 2FDTS%2F0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch&
> >>>> amp;data=02%7C01%7C%7Cf5937082939e4163c84b08d69a8f3b61%7C84df9e7fe9f640
> >>>> afb435aaaaaaaaaaaa%7C1%7C0%7C636866337295767294&sdata=tK8QE3bsG9LW%
> >>>> 2FJcvFzLKa8%2BPj5u%2F8exbEn8m2vqKly0%3D&reserved=0
> >>>> 
> >>>> Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> >>>> ---
> >>>> 
> >>>>    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..6b7e55085b0c 100644
> >>>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> >>>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> >>>> @@ -254,6 +254,8 @@
> >>>> 
> >>>>    			};
> >>>>    			
> >>>>    			vccio_sd: LDO_REG5 {
> >>>> 
> >>>> +				regulator-always-on;
> >>>> +				regulator-boot-on;
> >>>> 
> >>>>    				regulator-min-microvolt = <1800000>;
> >>>>    				regulator-max-microvolt = <3300000>;
> >>>>    				regulator-name = "vccio_sd";
> >>>> 
> >>>> @@ -431,7 +433,6 @@
> >>>> 
> >>>>    	cap-mmc-highspeed;
> >>>>    	cap-sd-highspeed;
> >>>>    	card-detect-delay = <200>;
> >>>> 
> >>>> -	disable-wp;			/* wp not hooked up */
> >>> 
> >>> I think disable-wp correctly describes that wp is not expected to work
> >>> and should not be removed.>>> 
> >>>   From comment in mmc_sd_get_ro():
> >>> "Some systems don't feature a write-protect pin and don't need one.
> >>> E.g. because they only have micro-SD card slot. For those systems
> >>> assume that the SD card is always read-write."
> >>> 
> >>> Without disable-wp core will call dw_mci_get_ro() to get wp status.
> >>> 
> >>> 
> >>> This patch also fixes reboot when booting from sd-card and having emmc
> >>> zeroed out.
> >>> 
> >>> Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
> >>> 
> >>> Regards,
> >>> Jonas
> >>> 
> >>>>    	pinctrl-names = "default";
> >>>>    	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
> >>>>    	status = "okay";
> >> 
> >> Hi Jonas,
> >> 
> >> Thanks for testing - did you get an error with "disable-wp" ?
> >> 
> >> We tested this with @TheSaint On ArchLinux Arm, and it worked!
> >> 
> >> With the "regulator-boot-on" and on reboot, it should keep power on the
> >> sd card - so reboot should work.
> > 
> > I tested both with and without "disable-wp" removed and both works without
> > error. SD-card reboots now works as it should thanks to
> > "regulator-always-on" and "regulator-boot-on", I only tested using both.
> > 
> > On a side note I have also been testing [1] to make reboot with UHS signal
> > voltage work and will send out a RFC v2 after I have concluded testing on
> > my other devices supporting UHS signal voltage.
> > 
> > [1]
> > https://github.com/Kwiboo/linux-rockchip/compare/patch-rk-5.x-tinker-uhs%
> > 5E%5E%5E...patch-rk-5.x-tinker-uhs
> > 
> > Regards,
> > Jonas
> 
> Thanks.
> 
> Glad your are testing - and I hope the uhs tests work.
> 
> Alas for us to test uhs - and our user on Arch isn't so experienced. I
> could push him to try different speeds - but to be honest I expect it to
> be beyond his comfort zone.
> 
> But its good to here you confirm "disable-wp" works. To my mind it says
> we are sure that  all three changes in the patch are are correct.
> 
> Hopefully this will be straight forward to Heiko to accept. Its the
> simple patch of the 3 to accept ;)

From Jonas' explanation, I'd guess we want disable-wp to stay in the node,
and not remove it as it tells the system, that "there is no write protect 
status available" hence it doesn't need to check for it.


Heiko

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

[Jonas Karlman]

On 2019-02-24 23:54, Heiko Stübner wrote:
> Am Sonntag, 24. Februar 2019, 21:10:50 CET schrieb David Summers:
>> On 24/02/2019 19:56, Jonas Karlman wrote:
>>> On 2019-02-24 20:35, David Summers wrote:
>>>> On 24/02/2019 19:26, Jonas Karlman wrote:
>>>>> On 2019-02-22 19:47, David Summers wrote:
>>>>>> The Problem:
>>>>>>
>>>>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
>>>>>> card sd slot, then there are constant errors.
>>>>>>
>>>>>> Cause:
>>>>>>
>>>>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
>>>>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
>>>>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
>>>>>> in the card detect. Now when no card is install, the regulator is
>>>>>> powered down. This means that the card detect floats, and this means
>>>>>> random card detection.
>>>>>>
>>>>>> The Solution:
>>>>>>
>>>>>> Make sure that the sd IO is always powered, this means card detection
>>>>>> is always active, which is what should be done on a board with an sd
>>>>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
>>>>>> is made to the .dtsi which takes effect on all Tinker Boards as
>>>>>> required.
>>>>>>
>>>>>> The change also adds "regulator-boot-on" the Tinker Board boot from
>>>>>> uboot, and the sd card is always one option. Hence the IO must be
>>>>>> powered in uboot, and so setting this flag.
>>>>>>
>>>>>> Also removed is "disable-wp" the micro sd card which are used have no
>>>>>> write  protection, so the concept doesn't mean anything, and the
>>>>>> Tinker Boards work without this. Hence it is removed to simply.
>>>>>>
>>>>>> This change came from ArchLinux Arm, but we note it is the fix also
>>>>>> used by Armbian:
>>>>>>
>>>>>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
>>>>>> b.com%2FMiouyouyou%2FRockMyy%2Fblob%2Fmaster%2Fpatches%2Fkernel%2Fv5.0%
>>>>>> 2FDTS%2F0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch&
>>>>>> amp;data=02%7C01%7C%7Cf5937082939e4163c84b08d69a8f3b61%7C84df9e7fe9f640
>>>>>> afb435aaaaaaaaaaaa%7C1%7C0%7C636866337295767294&sdata=tK8QE3bsG9LW%
>>>>>> 2FJcvFzLKa8%2BPj5u%2F8exbEn8m2vqKly0%3D&reserved=0
>>>>>>
>>>>>> Signed-off-by: David Summers <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
>>>>>> ---
>>>>>>
>>>>>>    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..6b7e55085b0c 100644
>>>>>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>>>>>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>>>>>> @@ -254,6 +254,8 @@
>>>>>>
>>>>>>    			};
>>>>>>    			
>>>>>>    			vccio_sd: LDO_REG5 {
>>>>>>
>>>>>> +				regulator-always-on;
>>>>>> +				regulator-boot-on;
>>>>>>
>>>>>>    				regulator-min-microvolt = <1800000>;
>>>>>>    				regulator-max-microvolt = <3300000>;
>>>>>>    				regulator-name = "vccio_sd";
>>>>>>
>>>>>> @@ -431,7 +433,6 @@
>>>>>>
>>>>>>    	cap-mmc-highspeed;
>>>>>>    	cap-sd-highspeed;
>>>>>>    	card-detect-delay = <200>;
>>>>>>
>>>>>> -	disable-wp;			/* wp not hooked up */
>>>>> I think disable-wp correctly describes that wp is not expected to work
>>>>> and should not be removed.>>> 
>>>>>   From comment in mmc_sd_get_ro():
>>>>> "Some systems don't feature a write-protect pin and don't need one.
>>>>> E.g. because they only have micro-SD card slot. For those systems
>>>>> assume that the SD card is always read-write."
>>>>>
>>>>> Without disable-wp core will call dw_mci_get_ro() to get wp status.
>>>>>
>>>>>
>>>>> This patch also fixes reboot when booting from sd-card and having emmc
>>>>> zeroed out.
>>>>>
>>>>> Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
>>>>>
>>>>> Regards,
>>>>> Jonas
>>>>>
>>>>>>    	pinctrl-names = "default";
>>>>>>    	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>>>>>>    	status = "okay";
>>>> Hi Jonas,
>>>>
>>>> Thanks for testing - did you get an error with "disable-wp" ?
>>>>
>>>> We tested this with @TheSaint On ArchLinux Arm, and it worked!
>>>>
>>>> With the "regulator-boot-on" and on reboot, it should keep power on the
>>>> sd card - so reboot should work.
>>> I tested both with and without "disable-wp" removed and both works without
>>> error. SD-card reboots now works as it should thanks to
>>> "regulator-always-on" and "regulator-boot-on", I only tested using both.
>>>
>>> On a side note I have also been testing [1] to make reboot with UHS signal
>>> voltage work and will send out a RFC v2 after I have concluded testing on
>>> my other devices supporting UHS signal voltage.
>>>
>>> [1]
>>> https://github.com/Kwiboo/linux-rockchip/compare/patch-rk-5.x-tinker-uhs%
>>> 5E%5E%5E...patch-rk-5.x-tinker-uhs
>>>
>>> Regards,
>>> Jonas
>> Thanks.
>>
>> Glad your are testing - and I hope the uhs tests work.
>>
>> Alas for us to test uhs - and our user on Arch isn't so experienced. I
>> could push him to try different speeds - but to be honest I expect it to
>> be beyond his comfort zone.
>>
>> But its good to here you confirm "disable-wp" works. To my mind it says
>> we are sure that  all three changes in the patch are are correct.
>>
>> Hopefully this will be straight forward to Heiko to accept. Its the
>> simple patch of the 3 to accept ;)
> From Jonas' explanation, I'd guess we want disable-wp to stay in the node,
> and not remove it as it tells the system, that "there is no write protect 
> status available" hence it doesn't need to check for it.

Correct, I may have been unclear ealier but I think that the disable-wp should stay as it correctly describes
that the board has a microSD slot that do not support write protection.

Regards,
Jonas

>
>
> Heiko
>
>

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

[David Summers]

On 24/02/2019 22:54, Heiko Stübner wrote:
> Am Sonntag, 24. Februar 2019, 21:10:50 CET schrieb David Summers:
>> On 24/02/2019 19:56, Jonas Karlman wrote:
>>> On 2019-02-24 20:35, David Summers wrote:
>>>> On 24/02/2019 19:26, Jonas Karlman wrote:
>>>>> On 2019-02-22 19:47, David Summers wrote:
>>>>>> The Problem:
>>>>>>
>>>>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
>>>>>> card sd slot, then there are constant errors.
>>>>>>
>>>>>> Cause:
>>>>>>
>>>>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
>>>>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
>>>>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
>>>>>> in the card detect. Now when no card is install, the regulator is
>>>>>> powered down. This means that the card detect floats, and this means
>>>>>> random card detection.
>>>>>>
>>>>>> The Solution:
>>>>>>
>>>>>> Make sure that the sd IO is always powered, this means card detection
>>>>>> is always active, which is what should be done on a board with an sd
>>>>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
>>>>>> is made to the .dtsi which takes effect on all Tinker Boards as
>>>>>> required.
>>>>>>
>>>>>> The change also adds "regulator-boot-on" the Tinker Board boot from
>>>>>> uboot, and the sd card is always one option. Hence the IO must be
>>>>>> powered in uboot, and so setting this flag.
>>>>>>
>>>>>> Also removed is "disable-wp" the micro sd card which are used have no
>>>>>> write  protection, so the concept doesn't mean anything, and the
>>>>>> Tinker Boards work without this. Hence it is removed to simply.
>>>>>>
>>>>>> This change came from ArchLinux Arm, but we note it is the fix also
>>>>>> used by Armbian:
>>>>>>
>>>>>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
>>>>>> b.com%2FMiouyouyou%2FRockMyy%2Fblob%2Fmaster%2Fpatches%2Fkernel%2Fv5.0%
>>>>>> 2FDTS%2F0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch&
>>>>>> amp;data=02%7C01%7C%7Cf5937082939e4163c84b08d69a8f3b61%7C84df9e7fe9f640
>>>>>> afb435aaaaaaaaaaaa%7C1%7C0%7C636866337295767294&sdata=tK8QE3bsG9LW%
>>>>>> 2FJcvFzLKa8%2BPj5u%2F8exbEn8m2vqKly0%3D&reserved=0
>>>>>>
>>>>>> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
>>>>>> ---
>>>>>>
>>>>>>     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..6b7e55085b0c 100644
>>>>>> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
>>>>>> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
>>>>>> @@ -254,6 +254,8 @@
>>>>>>
>>>>>>     			};
>>>>>>     			
>>>>>>     			vccio_sd: LDO_REG5 {
>>>>>>
>>>>>> +				regulator-always-on;
>>>>>> +				regulator-boot-on;
>>>>>>
>>>>>>     				regulator-min-microvolt = <1800000>;
>>>>>>     				regulator-max-microvolt = <3300000>;
>>>>>>     				regulator-name = "vccio_sd";
>>>>>>
>>>>>> @@ -431,7 +433,6 @@
>>>>>>
>>>>>>     	cap-mmc-highspeed;
>>>>>>     	cap-sd-highspeed;
>>>>>>     	card-detect-delay = <200>;
>>>>>>
>>>>>> -	disable-wp;			/* wp not hooked up */
>>>>> I think disable-wp correctly describes that wp is not expected to work
>>>>> and should not be removed.>>>
>>>>>    From comment in mmc_sd_get_ro():
>>>>> "Some systems don't feature a write-protect pin and don't need one.
>>>>> E.g. because they only have micro-SD card slot. For those systems
>>>>> assume that the SD card is always read-write."
>>>>>
>>>>> Without disable-wp core will call dw_mci_get_ro() to get wp status.
>>>>>
>>>>>
>>>>> This patch also fixes reboot when booting from sd-card and having emmc
>>>>> zeroed out.
>>>>>
>>>>> Tested-by: Jonas Karlman <jonas@kwiboo.se>
>>>>>
>>>>> Regards,
>>>>> Jonas
>>>>>
>>>>>>     	pinctrl-names = "default";
>>>>>>     	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>>>>>>     	status = "okay";
>>>> Hi Jonas,
>>>>
>>>> Thanks for testing - did you get an error with "disable-wp" ?
>>>>
>>>> We tested this with @TheSaint On ArchLinux Arm, and it worked!
>>>>
>>>> With the "regulator-boot-on" and on reboot, it should keep power on the
>>>> sd card - so reboot should work.
>>> I tested both with and without "disable-wp" removed and both works without
>>> error. SD-card reboots now works as it should thanks to
>>> "regulator-always-on" and "regulator-boot-on", I only tested using both.
>>>
>>> On a side note I have also been testing [1] to make reboot with UHS signal
>>> voltage work and will send out a RFC v2 after I have concluded testing on
>>> my other devices supporting UHS signal voltage.
>>>
>>> [1]
>>> https://github.com/Kwiboo/linux-rockchip/compare/patch-rk-5.x-tinker-uhs%
>>> 5E%5E%5E...patch-rk-5.x-tinker-uhs
>>>
>>> Regards,
>>> Jonas
>> Thanks.
>>
>> Glad your are testing - and I hope the uhs tests work.
>>
>> Alas for us to test uhs - and our user on Arch isn't so experienced. I
>> could push him to try different speeds - but to be honest I expect it to
>> be beyond his comfort zone.
>>
>> But its good to here you confirm "disable-wp" works. To my mind it says
>> we are sure that  all three changes in the patch are are correct.
>>
>> Hopefully this will be straight forward to Heiko to accept. Its the
>> simple patch of the 3 to accept ;)
>  From Jonas' explanation, I'd guess we want disable-wp to stay in the node,
> and not remove it as it tells the system, that "there is no write protect
> status available" hence it doesn't need to check for it.
>
>
> Heiko
>
>
Hi Heiko,

I was going to say that: 
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/mmc/mmc.txt 
says:

- disable-wp: When set no physical WP line is present. This property should
   only be specified when the controller has a dedicated write-protect
detection logic.

Do we know that dw_mmc-rockchip.c has write-protect detection logic? Its 
not mentioned in the code, but I don't know my way round the mmc code.

However quick grep for other rk3288 dts, and almost all have disable-wp. 
So in line with this - yes agree to do a patch without that, depending 
on how another post ...

Now I've included Jaehoon and Ulf (and linux-mmc) can you say if the 
rockchip controller can do write-protect detection logic?

Thanks,

David.


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[Doug Anderson]

Hi,

On Mon, Feb 25, 2019 at 1:05 PM David Summers
<beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> wrote:
> I was going to say that:
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/mmc/mmc.txt
> says:
>
> - disable-wp: When set no physical WP line is present. This property should
>    only be specified when the controller has a dedicated write-protect
> detection logic.
>
> Do we know that dw_mmc-rockchip.c has write-protect detection logic? Its
> not mentioned in the code, but I don't know my way round the mmc code.

In general dw_mmc has dedicated write protect logic.  ...so yes the
property is needed.

-Doug

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

[Doug Anderson]

Hi,

On Fri, Feb 22, 2019 at 10:48 AM David Summers
<beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> wrote:
>
> The Problem:
>
> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> card sd slot, then there are constant errors.
>
> Cause:
>
> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> in the card detect. Now when no card is install, the regulator is
> powered down. This means that the card detect floats, and this means
> random card detection.

Yeah, this is broken on a lot of SoCs that use dw_mmc.  :(  Really the
card detect line needs to be on a different rail and this is why all
boards I've worked on recently have a the card detect going to a GPIO
instead of the dw_mmc CD.

IIRC Rockchip moved the Card Detect to a different rail on newer SoCs
(like rk3399) but we still used a GPIO even there since we didn't like
the default/automatic muxing of JTAG and SD signals.

The one board I was involved in that did it wrong (where we discovered
this issue) was exynos5250-snow.  You can see some discussion about
the issue at:

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

In that discussion I'm pretty sure that Ulf suggested that a better
way to go was to use something like "broken-cd" which I think was
supposed to switch us to use polling.  AKA periodically the SD card
would be powered on and we'd check for a card, then we'd power
everything off.  ...but that was never implemented for snow at least
so there may be something more than just adding the property.  You can
read through the whole thread for more details.


IIRC leaving the IO rail always on like you're proposing can also work
OK but there may be some corner cases, especially if you are trying to
reach UHS speeds and/or if the bootloader ever tries to use UHS
speeds.  It's almost certainly busted if the bootloader did UHS since
it will leave the line at ~1.8 V and the kernel will expect it to be
at ~3.3 V.  ...but maybe you rely on the bootloader not doing UHS and
maybe things are generally OK if not?  There may also be cases where
you can't properly power down / reset a card because the card may be
drawing power through the IO lines when you power off its main lines.
That's not good for the card and can also put it in a bad state.  I
haven't done all the research here so this may be a bit of FUD--it's
just a vague recollection from many years ago.


...so to make a long story short, a better solution is to allow the IO
lines to be powered off but then poll for the card periodically.


> The Solution:
>
> Make sure that the sd IO is always powered, this means card detection
> is always active, which is what should be done on a board with an sd
> slot, which both the Tinker Board and Tinker Board S are. Hence change
> is made to the .dtsi which takes effect on all Tinker Boards as
> required.
>
> The change also adds "regulator-boot-on" the Tinker Board boot from
> uboot, and the sd card is always one option. Hence the IO must be
> powered in uboot, and so setting this flag.
>
> Also removed is "disable-wp" the micro sd card which are used have no
> write  protection, so the concept doesn't mean anything, and the
> Tinker Boards work without this. Hence it is removed to simply.

As others have said, please leave disable-wp.  There's no way for the
kernel to know if you have a SD or uSD slot and the only difference
between the two (electrically) is that there's no write protect for
micro SD.


Also: please CC dw_mmc people on future patches in this area.

$ ./scripts/get_maintainer.pl -f drivers/mmc/host/dw_mmc.c
Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> (maintainer:SYNOPSYS DESIGNWARE
MMC/SD/SDIO DRIVER)
Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> (maintainer:MULTIMEDIA CARD
(MMC), SECURE DIGITAL (SD) AND...)
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:SYNOPSYS DESIGNWARE MMC/SD/SDIO DRIVER)

-Doug

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

[David Summers]

On 25/02/2019 17:13, Doug Anderson wrote:
> Hi,
>
> On Fri, Feb 22, 2019 at 10:48 AM David Summers
> <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> wrote:
>> The Problem:
>>
>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
>> card sd slot, then there are constant errors.
>>
>> Cause:
>>
>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
>> in the card detect. Now when no card is install, the regulator is
>> powered down. This means that the card detect floats, and this means
>> random card detection.
> Yeah, this is broken on a lot of SoCs that use dw_mmc.  :(  Really the
> card detect line needs to be on a different rail and this is why all
> boards I've worked on recently have a the card detect going to a GPIO
> instead of the dw_mmc CD.
>
> IIRC Rockchip moved the Card Detect to a different rail on newer SoCs
> (like rk3399) but we still used a GPIO even there since we didn't like
> the default/automatic muxing of JTAG and SD signals.
>
> The one board I was involved in that did it wrong (where we discovered
> this issue) was exynos5250-snow.  You can see some discussion about
> the issue at:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282474.html
>
> In that discussion I'm pretty sure that Ulf suggested that a better
> way to go was to use something like "broken-cd" which I think was
> supposed to switch us to use polling.  AKA periodically the SD card
> would be powered on and we'd check for a card, then we'd power
> everything off.  ...but that was never implemented for snow at least
> so there may be something more than just adding the property.  You can
> read through the whole thread for more details.
>
>
> IIRC leaving the IO rail always on like you're proposing can also work
> OK but there may be some corner cases, especially if you are trying to
> reach UHS speeds and/or if the bootloader ever tries to use UHS
> speeds.  It's almost certainly busted if the bootloader did UHS since
> it will leave the line at ~1.8 V and the kernel will expect it to be
> at ~3.3 V.  ...but maybe you rely on the bootloader not doing UHS and
> maybe things are generally OK if not?  There may also be cases where
> you can't properly power down / reset a card because the card may be
> drawing power through the IO lines when you power off its main lines.
> That's not good for the card and can also put it in a bad state.  I
> haven't done all the research here so this may be a bit of FUD--it's
> just a vague recollection from many years ago.
>
>
> ...so to make a long story short, a better solution is to allow the IO
> lines to be powered off but then poll for the card periodically.
>
>
>> The Solution:
>>
>> Make sure that the sd IO is always powered, this means card detection
>> is always active, which is what should be done on a board with an sd
>> slot, which both the Tinker Board and Tinker Board S are. Hence change
>> is made to the .dtsi which takes effect on all Tinker Boards as
>> required.
>>
>> The change also adds "regulator-boot-on" the Tinker Board boot from
>> uboot, and the sd card is always one option. Hence the IO must be
>> powered in uboot, and so setting this flag.
>>
>> Also removed is "disable-wp" the micro sd card which are used have no
>> write  protection, so the concept doesn't mean anything, and the
>> Tinker Boards work without this. Hence it is removed to simply.
> As others have said, please leave disable-wp.  There's no way for the
> kernel to know if you have a SD or uSD slot and the only difference
> between the two (electrically) is that there's no write protect for
> micro SD.
>
>
> Also: please CC dw_mmc people on future patches in this area.
>
> $ ./scripts/get_maintainer.pl -f drivers/mmc/host/dw_mmc.c
> Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> (maintainer:SYNOPSYS DESIGNWARE
> MMC/SD/SDIO DRIVER)
> Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> (maintainer:MULTIMEDIA CARD
> (MMC), SECURE DIGITAL (SD) AND...)
> linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:SYNOPSYS DESIGNWARE MMC/SD/SDIO DRIVER)
>
> -Doug

I think the possible problem is that without this we were getting a lot 
of errors. Now as the errors happen when the sd io is power down, and so 
CD floats; then the IO will be powered back up gain - to access the 
card, only to find no card.

So this means the power line goes up and down a lot. Now if we have 
broken-cd, and polling has to be used, doesn't this also have to power 
up the IO so it can poll, and the poll puts a bit more load on the 
processor.

So question is which is better? To keep the IO powered up, or to have it 
going up and down?

Anyway I'm happy with either solution. So if we can agree which is best, 
I'll do the patch for that.

Regards,

David.

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

[Doug Anderson]

Hi,
On Mon, Feb 25, 2019 at 1:11 PM David Summers
<beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> wrote:
>
> On 25/02/2019 17:13, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Feb 22, 2019 at 10:48 AM David Summers
> > <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> wrote:
> >> The Problem:
> >>
> >> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> >> card sd slot, then there are constant errors.
> >>
> >> Cause:
> >>
> >> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> >> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> >> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> >> in the card detect. Now when no card is install, the regulator is
> >> powered down. This means that the card detect floats, and this means
> >> random card detection.
> > Yeah, this is broken on a lot of SoCs that use dw_mmc.  :(  Really the
> > card detect line needs to be on a different rail and this is why all
> > boards I've worked on recently have a the card detect going to a GPIO
> > instead of the dw_mmc CD.
> >
> > IIRC Rockchip moved the Card Detect to a different rail on newer SoCs
> > (like rk3399) but we still used a GPIO even there since we didn't like
> > the default/automatic muxing of JTAG and SD signals.
> >
> > The one board I was involved in that did it wrong (where we discovered
> > this issue) was exynos5250-snow.  You can see some discussion about
> > the issue at:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282474.html
> >
> > In that discussion I'm pretty sure that Ulf suggested that a better
> > way to go was to use something like "broken-cd" which I think was
> > supposed to switch us to use polling.  AKA periodically the SD card
> > would be powered on and we'd check for a card, then we'd power
> > everything off.  ...but that was never implemented for snow at least
> > so there may be something more than just adding the property.  You can
> > read through the whole thread for more details.
> >
> >
> > IIRC leaving the IO rail always on like you're proposing can also work
> > OK but there may be some corner cases, especially if you are trying to
> > reach UHS speeds and/or if the bootloader ever tries to use UHS
> > speeds.  It's almost certainly busted if the bootloader did UHS since
> > it will leave the line at ~1.8 V and the kernel will expect it to be
> > at ~3.3 V.  ...but maybe you rely on the bootloader not doing UHS and
> > maybe things are generally OK if not?  There may also be cases where
> > you can't properly power down / reset a card because the card may be
> > drawing power through the IO lines when you power off its main lines.
> > That's not good for the card and can also put it in a bad state.  I
> > haven't done all the research here so this may be a bit of FUD--it's
> > just a vague recollection from many years ago.
> >
> >
> > ...so to make a long story short, a better solution is to allow the IO
> > lines to be powered off but then poll for the card periodically.
> >
> >
> >> The Solution:
> >>
> >> Make sure that the sd IO is always powered, this means card detection
> >> is always active, which is what should be done on a board with an sd
> >> slot, which both the Tinker Board and Tinker Board S are. Hence change
> >> is made to the .dtsi which takes effect on all Tinker Boards as
> >> required.
> >>
> >> The change also adds "regulator-boot-on" the Tinker Board boot from
> >> uboot, and the sd card is always one option. Hence the IO must be
> >> powered in uboot, and so setting this flag.
> >>
> >> Also removed is "disable-wp" the micro sd card which are used have no
> >> write  protection, so the concept doesn't mean anything, and the
> >> Tinker Boards work without this. Hence it is removed to simply.
> > As others have said, please leave disable-wp.  There's no way for the
> > kernel to know if you have a SD or uSD slot and the only difference
> > between the two (electrically) is that there's no write protect for
> > micro SD.
> >
> >
> > Also: please CC dw_mmc people on future patches in this area.
> >
> > $ ./scripts/get_maintainer.pl -f drivers/mmc/host/dw_mmc.c
> > Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> (maintainer:SYNOPSYS DESIGNWARE
> > MMC/SD/SDIO DRIVER)
> > Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> (maintainer:MULTIMEDIA CARD
> > (MMC), SECURE DIGITAL (SD) AND...)
> > linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:SYNOPSYS DESIGNWARE MMC/SD/SDIO DRIVER)
> >
> > -Doug
>
> I think the possible problem is that without this we were getting a lot
> of errors. Now as the errors happen when the sd io is power down, and so
> CD floats; then the IO will be powered back up gain - to access the
> card, only to find no card.

I definitely haven't thought through all the consequences of adding
polling.  ...but given that the problem is really common with SoCs
using dw_mmc it's probably worth it to figure out out something sane.
In theory you could have some code that knows that the card detect
becomes reliable once the IOs are powered on...


> So this means the power line goes up and down a lot. Now if we have
> broken-cd, and polling has to be used, doesn't this also have to power
> up the IO so it can poll, and the poll puts a bit more load on the
> processor.
>
> So question is which is better? To keep the IO powered up, or to have it
> going up and down?
>
> Anyway I'm happy with either solution. So if we can agree which is best,
> I'll do the patch for that.

I don't know which is better.  ...but I wouldn't expect that turning
on regulators and checking a GPIO ever second or so would burn much
power.

-Doug

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

[Heiko Stübner]

Am Montag, 25. Februar 2019, 22:18:28 CET schrieb Doug Anderson:
> Hi,
> On Mon, Feb 25, 2019 at 1:11 PM David Summers
> 
> <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> wrote:
> > On 25/02/2019 17:13, Doug Anderson wrote:
> > > Hi,
> > > 
> > > On Fri, Feb 22, 2019 at 10:48 AM David Summers
> > > 
> > > <beagleboard-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> wrote:
> > >> The Problem:
> > >> 
> > >> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> > >> card sd slot, then there are constant errors.
> > >> 
> > >> Cause:
> > >> 
> > >> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> > >> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> > >> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> > >> in the card detect. Now when no card is install, the regulator is
> > >> powered down. This means that the card detect floats, and this means
> > >> random card detection.
> > > 
> > > Yeah, this is broken on a lot of SoCs that use dw_mmc.  :(  Really the
> > > card detect line needs to be on a different rail and this is why all
> > > boards I've worked on recently have a the card detect going to a GPIO
> > > instead of the dw_mmc CD.
> > > 
> > > IIRC Rockchip moved the Card Detect to a different rail on newer SoCs
> > > (like rk3399) but we still used a GPIO even there since we didn't like
> > > the default/automatic muxing of JTAG and SD signals.
> > > 
> > > The one board I was involved in that did it wrong (where we discovered
> > > this issue) was exynos5250-snow.  You can see some discussion about
> > > the issue at:
> > > 
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282474
> > > .html
> > > 
> > > In that discussion I'm pretty sure that Ulf suggested that a better
> > > way to go was to use something like "broken-cd" which I think was
> > > supposed to switch us to use polling.  AKA periodically the SD card
> > > would be powered on and we'd check for a card, then we'd power
> > > everything off.  ...but that was never implemented for snow at least
> > > so there may be something more than just adding the property.  You can
> > > read through the whole thread for more details.
> > > 
> > > 
> > > IIRC leaving the IO rail always on like you're proposing can also work
> > > OK but there may be some corner cases, especially if you are trying to
> > > reach UHS speeds and/or if the bootloader ever tries to use UHS
> > > speeds.  It's almost certainly busted if the bootloader did UHS since
> > > it will leave the line at ~1.8 V and the kernel will expect it to be
> > > at ~3.3 V.  ...but maybe you rely on the bootloader not doing UHS and
> > > maybe things are generally OK if not?  There may also be cases where
> > > you can't properly power down / reset a card because the card may be
> > > drawing power through the IO lines when you power off its main lines.
> > > That's not good for the card and can also put it in a bad state.  I
> > > haven't done all the research here so this may be a bit of FUD--it's
> > > just a vague recollection from many years ago.
> > > 
> > > 
> > > ...so to make a long story short, a better solution is to allow the IO
> > > lines to be powered off but then poll for the card periodically.
> > > 
> > >> The Solution:
> > >> 
> > >> Make sure that the sd IO is always powered, this means card detection
> > >> is always active, which is what should be done on a board with an sd
> > >> slot, which both the Tinker Board and Tinker Board S are. Hence change
> > >> is made to the .dtsi which takes effect on all Tinker Boards as
> > >> required.
> > >> 
> > >> The change also adds "regulator-boot-on" the Tinker Board boot from
> > >> uboot, and the sd card is always one option. Hence the IO must be
> > >> powered in uboot, and so setting this flag.
> > >> 
> > >> Also removed is "disable-wp" the micro sd card which are used have no
> > >> write  protection, so the concept doesn't mean anything, and the
> > >> Tinker Boards work without this. Hence it is removed to simply.
> > > 
> > > As others have said, please leave disable-wp.  There's no way for the
> > > kernel to know if you have a SD or uSD slot and the only difference
> > > between the two (electrically) is that there's no write protect for
> > > micro SD.
> > > 
> > > 
> > > Also: please CC dw_mmc people on future patches in this area.
> > > 
> > > $ ./scripts/get_maintainer.pl -f drivers/mmc/host/dw_mmc.c
> > > Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> (maintainer:SYNOPSYS DESIGNWARE
> > > MMC/SD/SDIO DRIVER)
> > > Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> (maintainer:MULTIMEDIA CARD
> > > (MMC), SECURE DIGITAL (SD) AND...)
> > > linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:SYNOPSYS DESIGNWARE MMC/SD/SDIO
> > > DRIVER)
> > > 
> > > -Doug
> > 
> > I think the possible problem is that without this we were getting a lot
> > of errors. Now as the errors happen when the sd io is power down, and so
> > CD floats; then the IO will be powered back up gain - to access the
> > card, only to find no card.
> 
> I definitely haven't thought through all the consequences of adding
> polling.  ...but given that the problem is really common with SoCs
> using dw_mmc it's probably worth it to figure out out something sane.
> In theory you could have some code that knows that the card detect
> becomes reliable once the IOs are powered on...
> 
> > So this means the power line goes up and down a lot. Now if we have
> > broken-cd, and polling has to be used, doesn't this also have to power
> > up the IO so it can poll, and the poll puts a bit more load on the
> > processor.
> > 
> > So question is which is better? To keep the IO powered up, or to have it
> > going up and down?
> > 
> > Anyway I'm happy with either solution. So if we can agree which is best,
> > I'll do the patch for that.
> 
> I don't know which is better.  ...but I wouldn't expect that turning
> on regulators and checking a GPIO ever second or so would burn much
> power.

and should also save actual power if the regulator isn't running all
the time :-)

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

[Robin Murphy]

On 25/02/2019 22:20, Heiko Stübner wrote:
> Am Montag, 25. Februar 2019, 22:18:28 CET schrieb Doug Anderson:
>> Hi,
>> On Mon, Feb 25, 2019 at 1:11 PM David Summers
>>
>> <beagleboard@davidjohnsummers.uk> wrote:
>>> On 25/02/2019 17:13, Doug Anderson wrote:
>>>> Hi,
>>>>
>>>> On Fri, Feb 22, 2019 at 10:48 AM David Summers
>>>>
>>>> <beagleboard@davidjohnsummers.uk> wrote:
>>>>> The Problem:
>>>>>
>>>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
>>>>> card sd slot, then there are constant errors.
>>>>>
>>>>> Cause:
>>>>>
>>>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
>>>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
>>>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
>>>>> in the card detect. Now when no card is install, the regulator is
>>>>> powered down. This means that the card detect floats, and this means
>>>>> random card detection.
>>>>
>>>> Yeah, this is broken on a lot of SoCs that use dw_mmc.  :(  Really the
>>>> card detect line needs to be on a different rail and this is why all
>>>> boards I've worked on recently have a the card detect going to a GPIO
>>>> instead of the dw_mmc CD.
>>>>
>>>> IIRC Rockchip moved the Card Detect to a different rail on newer SoCs
>>>> (like rk3399) but we still used a GPIO even there since we didn't like
>>>> the default/automatic muxing of JTAG and SD signals.
>>>>
>>>> The one board I was involved in that did it wrong (where we discovered
>>>> this issue) was exynos5250-snow.  You can see some discussion about
>>>> the issue at:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282474
>>>> .html
>>>>
>>>> In that discussion I'm pretty sure that Ulf suggested that a better
>>>> way to go was to use something like "broken-cd" which I think was
>>>> supposed to switch us to use polling.  AKA periodically the SD card
>>>> would be powered on and we'd check for a card, then we'd power
>>>> everything off.  ...but that was never implemented for snow at least
>>>> so there may be something more than just adding the property.  You can
>>>> read through the whole thread for more details.
>>>>
>>>>
>>>> IIRC leaving the IO rail always on like you're proposing can also work
>>>> OK but there may be some corner cases, especially if you are trying to
>>>> reach UHS speeds and/or if the bootloader ever tries to use UHS
>>>> speeds.  It's almost certainly busted if the bootloader did UHS since
>>>> it will leave the line at ~1.8 V and the kernel will expect it to be
>>>> at ~3.3 V.  ...but maybe you rely on the bootloader not doing UHS and
>>>> maybe things are generally OK if not?  There may also be cases where
>>>> you can't properly power down / reset a card because the card may be
>>>> drawing power through the IO lines when you power off its main lines.
>>>> That's not good for the card and can also put it in a bad state.  I
>>>> haven't done all the research here so this may be a bit of FUD--it's
>>>> just a vague recollection from many years ago.
>>>>
>>>>
>>>> ...so to make a long story short, a better solution is to allow the IO
>>>> lines to be powered off but then poll for the card periodically.
>>>>
>>>>> The Solution:
>>>>>
>>>>> Make sure that the sd IO is always powered, this means card detection
>>>>> is always active, which is what should be done on a board with an sd
>>>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
>>>>> is made to the .dtsi which takes effect on all Tinker Boards as
>>>>> required.
>>>>>
>>>>> The change also adds "regulator-boot-on" the Tinker Board boot from
>>>>> uboot, and the sd card is always one option. Hence the IO must be
>>>>> powered in uboot, and so setting this flag.
>>>>>
>>>>> Also removed is "disable-wp" the micro sd card which are used have no
>>>>> write  protection, so the concept doesn't mean anything, and the
>>>>> Tinker Boards work without this. Hence it is removed to simply.
>>>>
>>>> As others have said, please leave disable-wp.  There's no way for the
>>>> kernel to know if you have a SD or uSD slot and the only difference
>>>> between the two (electrically) is that there's no write protect for
>>>> micro SD.
>>>>
>>>>
>>>> Also: please CC dw_mmc people on future patches in this area.
>>>>
>>>> $ ./scripts/get_maintainer.pl -f drivers/mmc/host/dw_mmc.c
>>>> Jaehoon Chung <jh80.chung@samsung.com> (maintainer:SYNOPSYS DESIGNWARE
>>>> MMC/SD/SDIO DRIVER)
>>>> Ulf Hansson <ulf.hansson@linaro.org> (maintainer:MULTIMEDIA CARD
>>>> (MMC), SECURE DIGITAL (SD) AND...)
>>>> linux-mmc@vger.kernel.org (open list:SYNOPSYS DESIGNWARE MMC/SD/SDIO
>>>> DRIVER)
>>>>
>>>> -Doug
>>>
>>> I think the possible problem is that without this we were getting a lot
>>> of errors. Now as the errors happen when the sd io is power down, and so
>>> CD floats; then the IO will be powered back up gain - to access the
>>> card, only to find no card.
>>
>> I definitely haven't thought through all the consequences of adding
>> polling.  ...but given that the problem is really common with SoCs
>> using dw_mmc it's probably worth it to figure out out something sane.
>> In theory you could have some code that knows that the card detect
>> becomes reliable once the IOs are powered on...

Right, forcing it at the regulator end is somewhat of a blunt instrument 
when faced with all possible subtleties (but it is what all the vendor 
kernels seem to do). My next thought would be some 
"cd-pulled-up-by-vqmmc" quirk where the only difference is that at the 
point we know we *don't* have a card present and go to release vqmmc, 
the quirk turns it back on (or skips turning it off at all). However it 
seems like that that's almost exactly what was proposed last time - I 
hadn't seen that thread, so I'll take some time to digest it fully at 
some point.

>>> So this means the power line goes up and down a lot. Now if we have
>>> broken-cd, and polling has to be used, doesn't this also have to power
>>> up the IO so it can poll, and the poll puts a bit more load on the
>>> processor.
>>>
>>> So question is which is better? To keep the IO powered up, or to have it
>>> going up and down?
>>>
>>> Anyway I'm happy with either solution. So if we can agree which is best,
>>> I'll do the patch for that.
>>
>> I don't know which is better.  ...but I wouldn't expect that turning
>> on regulators and checking a GPIO ever second or so would burn much
>> power.

It's not so much power that bothers me here as the general "doing more 
work" impact of polling - specifically I'm recalling the time we 
discovered that AMD Overdrive boards gained something ridiculous like 5% 
performance uplift in hackbench just from having a card in the MMC slot. 
Admittedly dw_mmc doesn't seem to be *that* bad - a quick play with and 
without "broken-cd" on my little rk3328 suggests that any difference is 
probably way down in the noise, so maybe it's OK.

What would be really fun, though, would be to take advantage of the fact 
that CD is only half-broken - it should still detect a card by virtue of 
the pin being properly pulled to ground, it just can't reliably detect 
not-a-card. AFAICS we could have a quirk to handle phantom insertions, 
which double-checks CD after powering up all the regulators to see if it 
stayed low (hmm, I would hope card-detect-delay might do that anyway...) 
and ignores the event without error if it didn't. Even if we still use a 
timer to delay unmasking the interrupt for rate-limiting, that ought to 
be a fair bit lighter-weight than the rigmarole of trying to initiate 
communication with a possible card and waiting for it to time out.

> and should also save actual power if the regulator isn't running all
> the time :-)

I'd be surprised if it made any noticable difference in the typical SBC 
case, but now I'm going to have to have a go at finding some suitable 
current-measurement points to actually test that assumption ;)

Robin.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[Doug Anderson]

Hi,

On Tue, Feb 26, 2019 at 6:46 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 25/02/2019 22:20, Heiko Stübner wrote:
> > Am Montag, 25. Februar 2019, 22:18:28 CET schrieb Doug Anderson:
> >> Hi,
> >> On Mon, Feb 25, 2019 at 1:11 PM David Summers
> >>
> >> <beagleboard@davidjohnsummers.uk> wrote:
> >>> On 25/02/2019 17:13, Doug Anderson wrote:
> >>>> Hi,
> >>>>
> >>>> On Fri, Feb 22, 2019 at 10:48 AM David Summers
> >>>>
> >>>> <beagleboard@davidjohnsummers.uk> wrote:
> >>>>> The Problem:
> >>>>>
> >>>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> >>>>> card sd slot, then there are constant errors.
> >>>>>
> >>>>> Cause:
> >>>>>
> >>>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> >>>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> >>>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> >>>>> in the card detect. Now when no card is install, the regulator is
> >>>>> powered down. This means that the card detect floats, and this means
> >>>>> random card detection.
> >>>>
> >>>> Yeah, this is broken on a lot of SoCs that use dw_mmc.  :(  Really the
> >>>> card detect line needs to be on a different rail and this is why all
> >>>> boards I've worked on recently have a the card detect going to a GPIO
> >>>> instead of the dw_mmc CD.
> >>>>
> >>>> IIRC Rockchip moved the Card Detect to a different rail on newer SoCs
> >>>> (like rk3399) but we still used a GPIO even there since we didn't like
> >>>> the default/automatic muxing of JTAG and SD signals.
> >>>>
> >>>> The one board I was involved in that did it wrong (where we discovered
> >>>> this issue) was exynos5250-snow.  You can see some discussion about
> >>>> the issue at:
> >>>>
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282474
> >>>> .html
> >>>>
> >>>> In that discussion I'm pretty sure that Ulf suggested that a better
> >>>> way to go was to use something like "broken-cd" which I think was
> >>>> supposed to switch us to use polling.  AKA periodically the SD card
> >>>> would be powered on and we'd check for a card, then we'd power
> >>>> everything off.  ...but that was never implemented for snow at least
> >>>> so there may be something more than just adding the property.  You can
> >>>> read through the whole thread for more details.
> >>>>
> >>>>
> >>>> IIRC leaving the IO rail always on like you're proposing can also work
> >>>> OK but there may be some corner cases, especially if you are trying to
> >>>> reach UHS speeds and/or if the bootloader ever tries to use UHS
> >>>> speeds.  It's almost certainly busted if the bootloader did UHS since
> >>>> it will leave the line at ~1.8 V and the kernel will expect it to be
> >>>> at ~3.3 V.  ...but maybe you rely on the bootloader not doing UHS and
> >>>> maybe things are generally OK if not?  There may also be cases where
> >>>> you can't properly power down / reset a card because the card may be
> >>>> drawing power through the IO lines when you power off its main lines.
> >>>> That's not good for the card and can also put it in a bad state.  I
> >>>> haven't done all the research here so this may be a bit of FUD--it's
> >>>> just a vague recollection from many years ago.
> >>>>
> >>>>
> >>>> ...so to make a long story short, a better solution is to allow the IO
> >>>> lines to be powered off but then poll for the card periodically.
> >>>>
> >>>>> The Solution:
> >>>>>
> >>>>> Make sure that the sd IO is always powered, this means card detection
> >>>>> is always active, which is what should be done on a board with an sd
> >>>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
> >>>>> is made to the .dtsi which takes effect on all Tinker Boards as
> >>>>> required.
> >>>>>
> >>>>> The change also adds "regulator-boot-on" the Tinker Board boot from
> >>>>> uboot, and the sd card is always one option. Hence the IO must be
> >>>>> powered in uboot, and so setting this flag.
> >>>>>
> >>>>> Also removed is "disable-wp" the micro sd card which are used have no
> >>>>> write  protection, so the concept doesn't mean anything, and the
> >>>>> Tinker Boards work without this. Hence it is removed to simply.
> >>>>
> >>>> As others have said, please leave disable-wp.  There's no way for the
> >>>> kernel to know if you have a SD or uSD slot and the only difference
> >>>> between the two (electrically) is that there's no write protect for
> >>>> micro SD.
> >>>>
> >>>>
> >>>> Also: please CC dw_mmc people on future patches in this area.
> >>>>
> >>>> $ ./scripts/get_maintainer.pl -f drivers/mmc/host/dw_mmc.c
> >>>> Jaehoon Chung <jh80.chung@samsung.com> (maintainer:SYNOPSYS DESIGNWARE
> >>>> MMC/SD/SDIO DRIVER)
> >>>> Ulf Hansson <ulf.hansson@linaro.org> (maintainer:MULTIMEDIA CARD
> >>>> (MMC), SECURE DIGITAL (SD) AND...)
> >>>> linux-mmc@vger.kernel.org (open list:SYNOPSYS DESIGNWARE MMC/SD/SDIO
> >>>> DRIVER)
> >>>>
> >>>> -Doug
> >>>
> >>> I think the possible problem is that without this we were getting a lot
> >>> of errors. Now as the errors happen when the sd io is power down, and so
> >>> CD floats; then the IO will be powered back up gain - to access the
> >>> card, only to find no card.
> >>
> >> I definitely haven't thought through all the consequences of adding
> >> polling.  ...but given that the problem is really common with SoCs
> >> using dw_mmc it's probably worth it to figure out out something sane.
> >> In theory you could have some code that knows that the card detect
> >> becomes reliable once the IOs are powered on...
>
> Right, forcing it at the regulator end is somewhat of a blunt instrument
> when faced with all possible subtleties (but it is what all the vendor
> kernels seem to do). My next thought would be some
> "cd-pulled-up-by-vqmmc" quirk where the only difference is that at the
> point we know we *don't* have a card present and go to release vqmmc,
> the quirk turns it back on (or skips turning it off at all). However it
> seems like that that's almost exactly what was proposed last time - I
> hadn't seen that thread, so I'll take some time to digest it fully at
> some point.

I don't remember exactly where we left off last time, but in any case
it would probably be worth re-evaluating any conclusions made 4 years
ago, especially given that there's definitely more than one board in
the same position now.


> >>> So this means the power line goes up and down a lot. Now if we have
> >>> broken-cd, and polling has to be used, doesn't this also have to power
> >>> up the IO so it can poll, and the poll puts a bit more load on the
> >>> processor.
> >>>
> >>> So question is which is better? To keep the IO powered up, or to have it
> >>> going up and down?
> >>>
> >>> Anyway I'm happy with either solution. So if we can agree which is best,
> >>> I'll do the patch for that.
> >>
> >> I don't know which is better.  ...but I wouldn't expect that turning
> >> on regulators and checking a GPIO ever second or so would burn much
> >> power.
>
> It's not so much power that bothers me here as the general "doing more
> work" impact of polling - specifically I'm recalling the time we
> discovered that AMD Overdrive boards gained something ridiculous like 5%
> performance uplift in hackbench just from having a card in the MMC slot.
> Admittedly dw_mmc doesn't seem to be *that* bad - a quick play with and
> without "broken-cd" on my little rk3328 suggests that any difference is
> probably way down in the noise, so maybe it's OK.
>
> What would be really fun, though, would be to take advantage of the fact
> that CD is only half-broken - it should still detect a card by virtue of
> the pin being properly pulled to ground, it just can't reliably detect
> not-a-card. AFAICS we could have a quirk to handle phantom insertions,
> which double-checks CD after powering up all the regulators to see if it
> stayed low (hmm, I would hope card-detect-delay might do that anyway...)
> and ignores the event without error if it didn't. Even if we still use a
> timer to delay unmasking the interrupt for rate-limiting, that ought to
> be a fair bit lighter-weight than the rigmarole of trying to initiate
> communication with a possible card and waiting for it to time out.

I don't _think_ that would work, but I could be wrong.  When you stop
powering the IO rails then that stops powering the logic in the SoC.
I don't think you can reliably detect interrupts in this case.

IMO the ideal case would be to power on the rails periodically and
then check the Card Detect.  That would be better than trying to talk
to a card that doesn't exist.


> > and should also save actual power if the regulator isn't running all
> > the time :-)
>
> I'd be surprised if it made any noticable difference in the typical SBC
> case, but now I'm going to have to have a go at finding some suitable
> current-measurement points to actually test that assumption ;)

Yeah, it does seem likely that keeping the IO rails powered up when
there's no card there is probably a very small amount of power.

-Doug

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[Robin Murphy]

On 26/02/2019 16:43, Doug Anderson wrote:
> Hi,
> 
> On Tue, Feb 26, 2019 at 6:46 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 25/02/2019 22:20, Heiko Stübner wrote:
>>> Am Montag, 25. Februar 2019, 22:18:28 CET schrieb Doug Anderson:
>>>> Hi,
>>>> On Mon, Feb 25, 2019 at 1:11 PM David Summers
>>>>
>>>> <beagleboard@davidjohnsummers.uk> wrote:
>>>>> On 25/02/2019 17:13, Doug Anderson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Fri, Feb 22, 2019 at 10:48 AM David Summers
>>>>>>
>>>>>> <beagleboard@davidjohnsummers.uk> wrote:
>>>>>>> The Problem:
>>>>>>>
>>>>>>> On ASUS Tinker Board S, when booting from the eMMC, and there is no
>>>>>>> card sd slot, then there are constant errors.
>>>>>>>
>>>>>>> Cause:
>>>>>>>
>>>>>>> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
>>>>>>> rk808 on the Tinker Board and Tinker Board S has many regulators, one
>>>>>>> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
>>>>>>> in the card detect. Now when no card is install, the regulator is
>>>>>>> powered down. This means that the card detect floats, and this means
>>>>>>> random card detection.
>>>>>>
>>>>>> Yeah, this is broken on a lot of SoCs that use dw_mmc.  :(  Really the
>>>>>> card detect line needs to be on a different rail and this is why all
>>>>>> boards I've worked on recently have a the card detect going to a GPIO
>>>>>> instead of the dw_mmc CD.
>>>>>>
>>>>>> IIRC Rockchip moved the Card Detect to a different rail on newer SoCs
>>>>>> (like rk3399) but we still used a GPIO even there since we didn't like
>>>>>> the default/automatic muxing of JTAG and SD signals.
>>>>>>
>>>>>> The one board I was involved in that did it wrong (where we discovered
>>>>>> this issue) was exynos5250-snow.  You can see some discussion about
>>>>>> the issue at:
>>>>>>
>>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282474
>>>>>> .html
>>>>>>
>>>>>> In that discussion I'm pretty sure that Ulf suggested that a better
>>>>>> way to go was to use something like "broken-cd" which I think was
>>>>>> supposed to switch us to use polling.  AKA periodically the SD card
>>>>>> would be powered on and we'd check for a card, then we'd power
>>>>>> everything off.  ...but that was never implemented for snow at least
>>>>>> so there may be something more than just adding the property.  You can
>>>>>> read through the whole thread for more details.
>>>>>>
>>>>>>
>>>>>> IIRC leaving the IO rail always on like you're proposing can also work
>>>>>> OK but there may be some corner cases, especially if you are trying to
>>>>>> reach UHS speeds and/or if the bootloader ever tries to use UHS
>>>>>> speeds.  It's almost certainly busted if the bootloader did UHS since
>>>>>> it will leave the line at ~1.8 V and the kernel will expect it to be
>>>>>> at ~3.3 V.  ...but maybe you rely on the bootloader not doing UHS and
>>>>>> maybe things are generally OK if not?  There may also be cases where
>>>>>> you can't properly power down / reset a card because the card may be
>>>>>> drawing power through the IO lines when you power off its main lines.
>>>>>> That's not good for the card and can also put it in a bad state.  I
>>>>>> haven't done all the research here so this may be a bit of FUD--it's
>>>>>> just a vague recollection from many years ago.
>>>>>>
>>>>>>
>>>>>> ...so to make a long story short, a better solution is to allow the IO
>>>>>> lines to be powered off but then poll for the card periodically.
>>>>>>
>>>>>>> The Solution:
>>>>>>>
>>>>>>> Make sure that the sd IO is always powered, this means card detection
>>>>>>> is always active, which is what should be done on a board with an sd
>>>>>>> slot, which both the Tinker Board and Tinker Board S are. Hence change
>>>>>>> is made to the .dtsi which takes effect on all Tinker Boards as
>>>>>>> required.
>>>>>>>
>>>>>>> The change also adds "regulator-boot-on" the Tinker Board boot from
>>>>>>> uboot, and the sd card is always one option. Hence the IO must be
>>>>>>> powered in uboot, and so setting this flag.
>>>>>>>
>>>>>>> Also removed is "disable-wp" the micro sd card which are used have no
>>>>>>> write  protection, so the concept doesn't mean anything, and the
>>>>>>> Tinker Boards work without this. Hence it is removed to simply.
>>>>>>
>>>>>> As others have said, please leave disable-wp.  There's no way for the
>>>>>> kernel to know if you have a SD or uSD slot and the only difference
>>>>>> between the two (electrically) is that there's no write protect for
>>>>>> micro SD.
>>>>>>
>>>>>>
>>>>>> Also: please CC dw_mmc people on future patches in this area.
>>>>>>
>>>>>> $ ./scripts/get_maintainer.pl -f drivers/mmc/host/dw_mmc.c
>>>>>> Jaehoon Chung <jh80.chung@samsung.com> (maintainer:SYNOPSYS DESIGNWARE
>>>>>> MMC/SD/SDIO DRIVER)
>>>>>> Ulf Hansson <ulf.hansson@linaro.org> (maintainer:MULTIMEDIA CARD
>>>>>> (MMC), SECURE DIGITAL (SD) AND...)
>>>>>> linux-mmc@vger.kernel.org (open list:SYNOPSYS DESIGNWARE MMC/SD/SDIO
>>>>>> DRIVER)
>>>>>>
>>>>>> -Doug
>>>>>
>>>>> I think the possible problem is that without this we were getting a lot
>>>>> of errors. Now as the errors happen when the sd io is power down, and so
>>>>> CD floats; then the IO will be powered back up gain - to access the
>>>>> card, only to find no card.
>>>>
>>>> I definitely haven't thought through all the consequences of adding
>>>> polling.  ...but given that the problem is really common with SoCs
>>>> using dw_mmc it's probably worth it to figure out out something sane.
>>>> In theory you could have some code that knows that the card detect
>>>> becomes reliable once the IOs are powered on...
>>
>> Right, forcing it at the regulator end is somewhat of a blunt instrument
>> when faced with all possible subtleties (but it is what all the vendor
>> kernels seem to do). My next thought would be some
>> "cd-pulled-up-by-vqmmc" quirk where the only difference is that at the
>> point we know we *don't* have a card present and go to release vqmmc,
>> the quirk turns it back on (or skips turning it off at all). However it
>> seems like that that's almost exactly what was proposed last time - I
>> hadn't seen that thread, so I'll take some time to digest it fully at
>> some point.
> 
> I don't remember exactly where we left off last time, but in any case
> it would probably be worth re-evaluating any conclusions made 4 years
> ago, especially given that there's definitely more than one board in
> the same position now.
> 
> 
>>>>> So this means the power line goes up and down a lot. Now if we have
>>>>> broken-cd, and polling has to be used, doesn't this also have to power
>>>>> up the IO so it can poll, and the poll puts a bit more load on the
>>>>> processor.
>>>>>
>>>>> So question is which is better? To keep the IO powered up, or to have it
>>>>> going up and down?
>>>>>
>>>>> Anyway I'm happy with either solution. So if we can agree which is best,
>>>>> I'll do the patch for that.
>>>>
>>>> I don't know which is better.  ...but I wouldn't expect that turning
>>>> on regulators and checking a GPIO ever second or so would burn much
>>>> power.
>>
>> It's not so much power that bothers me here as the general "doing more
>> work" impact of polling - specifically I'm recalling the time we
>> discovered that AMD Overdrive boards gained something ridiculous like 5%
>> performance uplift in hackbench just from having a card in the MMC slot.
>> Admittedly dw_mmc doesn't seem to be *that* bad - a quick play with and
>> without "broken-cd" on my little rk3328 suggests that any difference is
>> probably way down in the noise, so maybe it's OK.
>>
>> What would be really fun, though, would be to take advantage of the fact
>> that CD is only half-broken - it should still detect a card by virtue of
>> the pin being properly pulled to ground, it just can't reliably detect
>> not-a-card. AFAICS we could have a quirk to handle phantom insertions,
>> which double-checks CD after powering up all the regulators to see if it
>> stayed low (hmm, I would hope card-detect-delay might do that anyway...)
>> and ignores the event without error if it didn't. Even if we still use a
>> timer to delay unmasking the interrupt for rate-limiting, that ought to
>> be a fair bit lighter-weight than the rigmarole of trying to initiate
>> communication with a possible card and waiting for it to time out.
> 
> I don't _think_ that would work, but I could be wrong.  When you stop
> powering the IO rails then that stops powering the logic in the SoC.
> I don't think you can reliably detect interrupts in this case.

Hmm, it certainly works on RK3288, but in general you do have a point 
there. As I understand the typical case, the external regulator only 
powers the I/O pads, while the controller block itself is at the mercy 
of SoC-internal power domains. On 3288 there's so much other gubbins in 
PD_PERI that the controller itself will effectively never get powered 
down, thus the interrupt logic keeps ticking. Comparing RK3399, though, 
the controller's on its own in the finer-grained PD_SD, which I can see 
getting aggressively auto-suspended by runtime PM...

...and I think you've just solved the puzzle of why my new board's card 
detect works as a GPIO but not as the dedicated function (despite having 
its I/O pad over in the always-on PMU domain away from regulator 
problems). Thanks! :D

> IMO the ideal case would be to power on the rails periodically and
> then check the Card Detect.  That would be better than trying to talk
> to a card that doesn't exist.

Yes, that sounds like the most useful compromise - a (possibly 
dwmmc-specific) property which says that the internal CD *interrupt* is 
unreliable, but the status bit itself will still be accurate after a 
proper powerup sequence. Then the existing polling machinery could 
probably grow an intermediate level wherein it checks ->get_cd() first 
and only bothers calling ->alive() if it looks like a card's actually 
turned up.

Robin.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[David Summers]

Dear All,

So lets do a synthesis of where we are, People who have an interest:

1) Me
2) Jonas Karlman - disable-wp should be set, and Tested. But commented 
"fixes reboot when booting from sd-card and having emmc zeroed out" when 
regulator-boot-on is set
3) Heiko Stubner (Rockchip maintainer) - agrees disable-wp should set
4) Doug Anderson - Card Detect shouldn't be power by vccio_sd. So this 
error in board construction, means should do "broken-cd" as Card Detect 
doesn't work when vccio_sd is down
5) Jaehoon Chung & Ulf Hansson, not posted on this thread - but MMC SD 
maintainer. In past thread 4-5 years ago, strongly said this is a broken 
cd, hence use "broken-cd"
6) Robin Murphy  - who identified the problem with card detected powered 
by vccio_sd. So power on vccio_sd always, but can be swayed. Maybe we 
should have a software correction to this problem.
7) Tony McKahan - involved in Armbian, so interested in Tinker Board S 
support by mainline Linux

And so what to conclude.

Well, although Jaehoon and Ulf haven't posted on this thread, the thread 
from four years ago:

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

And it makes clear that its treated as a broken card detect, and so 
"broken-cd" is the correct solution, now Robin says on some machines 
this causes a high load due to the polling; but this hasn't clearly been 
seen on rk3288 machines, either on this thread or on ArchLinux Arm. To 
my mind this means that Ulf and Jaehoon as maintainers, even with a 4 
year old post, trump and win - and so we go with "broken-cd" over 
enabling the regulator all the time.

Jonas comment though, about warm reboots on sd card. Suggests we do have 
"regulator-boot-on". Haven't been able to confirm this; so would be good 
if Jonas could confirm this is *exactly* what is needed?

So unless anyone says anything to convince me otherwise, my plan is to 
submit v3 of this patch in next few days with:

1) "broken-cd"
2) "disable-wp"
3) "regulator-boot-on"

Now question for Heiko is what schedule are we looking at? My guess is 
that the linux 5.1 boot has been missed? So whats the schedule for 5.2?

Guess I should also say some words on the talk of should there be a 
software work around for this common hardware fault, where the CD is 
powered by vccio_sd. As I see it with "broken-cd" when we want sd status 
the kernel does:

1) Power on vccio_sd
2) Poll the card with timeouts
3) Power down the vccio_sd

Now with an additional software work around, would involve step 2 
replaced with "test cd pin" - but still need steps 1 and 3. Now testing 
the cd pin, should be lower load than polling and timeouts - but still 
have the regulator on-off overhead.

Anyway I don't have time right now to follow such a software work 
around. So plan this patch to be independent.

Any views let me know - otherwise v3 of the patch ~Wednesday.

David.


On 22/02/2019 18:47, David Summers wrote:
> The Problem:
>
> On ASUS Tinker Board S, when booting from the eMMC, and there is no
> card sd slot, then there are constant errors.
>
> Cause:
>
> Thanks must go to Robin Murphy @ ARM for idenifying the problem. The
> rk808 on the Tinker Board and Tinker Board S has many regulators, one
> vccio_sd powers the IO for the sd card. Unfortunatly this is also used
> in the card detect. Now when no card is install, the regulator is
> powered down. This means that the card detect floats, and this means
> random card detection.
>
> The Solution:
>
> Make sure that the sd IO is always powered, this means card detection
> is always active, which is what should be done on a board with an sd
> slot, which both the Tinker Board and Tinker Board S are. Hence change
> is made to the .dtsi which takes effect on all Tinker Boards as
> required.
>
> The change also adds "regulator-boot-on" the Tinker Board boot from
> uboot, and the sd card is always one option. Hence the IO must be
> powered in uboot, and so setting this flag.
>
> Also removed is "disable-wp" the micro sd card which are used have no
> write  protection, so the concept doesn't mean anything, and the
> Tinker Boards work without this. Hence it is removed to simply.
>
> This change came from ArchLinux Arm, but we note it is the fix also
> used by Armbian:
>
> https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v5.0/DTS/0016-ARM-DTSI-rk3288-tinker-Setting-up-the-SD-regulators.patch
>
> Signed-off-by: David Summers <beagleboard@davidjohnsummers.uk>
> ---
>   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..6b7e55085b0c 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dtsi
> +++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
> @@ -254,6 +254,8 @@
>   			};
>   
>   			vccio_sd: LDO_REG5 {
> +				regulator-always-on;
> +				regulator-boot-on;
>   				regulator-min-microvolt = <1800000>;
>   				regulator-max-microvolt = <3300000>;
>   				regulator-name = "vccio_sd";
> @@ -431,7 +433,6 @@
>   	cap-mmc-highspeed;
>   	cap-sd-highspeed;
>   	card-detect-delay = <200>;
> -	disable-wp;			/* wp not hooked up */
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>   	status = "okay";



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[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

[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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> ---
>  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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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.
>

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
>> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
>>
>> +
>> +       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>;
>> +               };
>> +       };

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> ---
>  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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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
> 

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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

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.

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 */

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> > Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> > ---
> >   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 */
>
>

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

[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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> ---
>  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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip



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

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org> 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> ---
>  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

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 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 {

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.

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

[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

[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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
Tested-by: Tony McKahan <tonymckahan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> 
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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org

[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 */
> 

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
>> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
>> Tested-by: Tony McKahan <tonymckahan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>
> 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.

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> >> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> >> Tested-by: Tony McKahan <tonymckahan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> > 
> > 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

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>

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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> 
> 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 */
> 

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-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> Tested-by: Tony McKahan <tonymckahan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> 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

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
---
 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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org

[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

[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

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

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

[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

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.

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

[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.

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> ---
>  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

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

[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

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

[David Summers]

[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 4356 bytes --]

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 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

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> Reviewed by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Reviewed by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
> 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>;
> 

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-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> Reviewed by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Reviewed by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>

in v2, you gave a
Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
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

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> >> Reviewed by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> >> Reviewed by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
> > 
> > in v2, you gave a
> > Tested-by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
> > 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

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
>
>

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-8lkWs+DogrrqRUWtDFdff/XRex20P6io@public.gmane.org>
> Reviewed by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Reviewed by: Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>
> 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

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