Device-tree improvements

[lategoodbye]

I prefer Vasily's patch series to enable bluetooth than mine quick hack. So i prepared a merged version:
https://gist.github.com/lategoodbye/e72 ... 97a85f348f

Please add the necessary DTS changes for the Tinker Board according to the binding. I've kept the firmware-postfix property to load the board specific firmware.

[TheSaint]

I'm willing to try, but I'm missing some step to compile kernel and modules. I'd rather prefer to cross compile with my i7 on the laptop.

[summers]

Cross Compiling the kernel is one of the easier bits of code to cross compile - as it doesn't depend on libraries, and so doesn't try to link to libraries on on how machine.

If your I7 is running arch you can use https://www.archlinux.org/packages/community/x86_64/arm-none-eabi-gcc/ in the kernel compile IIRC you need to set $this->bbcode_second_pass_code('', 'ARCH=arm') and $this->bbcode_second_pass_code('', 'GCC=arm-none-eabi-gcc').

Yes I think I agree with Stefan than Vasily patch is the way to go, and to set postfix in the device tree to OBDA8723.

[summers]

How many errors were you getting about the sd card when using eMMC? Just trying to decide which patch is best - its not clear ...

[TheSaint]

I'm using$this->bbcode_second_pass_code('', 'make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j6')
Regarding the SD card I have:
$this->bbcode_second_pass_code('', '$ cat /boot/boot.txt
# After modifying, run ./mkscr

setenv rootcmd "LABEL=TB-MM-root"
setenv fdtfile rk3288-tinker-s.dtb
setenv bootargs "console=ttyS2,115200n8 root=${rootcmd} rw rootwait"

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtb/${fdtfile}; then
fdt addr ${fdt_addr_r}
# fdt resize
# fdt set /dwmmc@ff0c0000 broken-cd
# fdt set /usb@ff500000 no-relinquish-port
if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
bootz ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi

$ dmesg |tail
[ 221.485787] mmc0: new high speed SDHC card at address 0007
[ 221.492905] mmcblk0: mmc0:0007 SD16G 14.6 GiB
[ 221.499188] mmcblk0: p1 p2 p3
[ 249.279082] mmc0: card 0007 removed

$ ll /boot/dtbs/rk3288-tinker-s.dtb
-rw-r--r-- 1 root root 52053 Feb 22 09:48 /boot/dtbs/rk3288-tinker-s.dtb
$ md5sum /boot/dtbs/rk3288-tinker-s.dtb
75b2fb6ac8d4154f9732dfaddb0a0383 /boot/dtbs/rk3288-tinker-s.dts')
So I don't see much about error during SD card insertion.

[summers]

Ah sorry I wasn't clear in my question.

Lets give the full background. On the TB(S) the cd pin (which I can't see defined in the dts) is powered by vccio_sd. This means to use CD must have that powered. This seems to be generally considered a mistake, or rather bad design. Ideally vccio_sd would be powered down until a card is inserted, when it then powers up as needed.

However given that this is a mistake, there seem two ways to solve the problem.

1) Power on vccio_sd all the time - so cd gives correct values. This has the problem that vccio_sd isn't designed to be on all the time, its not clear that the sd card should always be powered, and some changes on mode will need power cyclinging (e.g. changing from 1.8 to 3.3V).
2) Have broken_cd set. This means that the cpu regularly powers up vccio_sd and polls the card to see if it gets anything back. This has the problem that power is regularly cycled.

So neither solution is good. Now the kernel mail list hasn't yet come up with a definitive preferred solution. So am slowly adding info.

On question is how often does the floating pin give problems. So with neither 1 nor 2 above, how often do we get errors. This is one limiting case, and guess you know the scale of the problem there ...

[TheSaint]

I tested several times$this->bbcode_second_pass_code('', '[ 99.537274] mmc0: card 0007 removed
[ 115.489051] mmc0: new high speed SDHC card at address 0007
[ 115.495962] mmcblk0: mmc0:0007 SD16G 14.4 GiB
[ 115.502241] mmcblk0: p1 p2 p3
[ 180.013603] mmc0: card 0007 removed
[ 186.239646] mmc0: new high speed SDHC card at address 0007
[ 186.247755] mmcblk0: mmc0:0007 SD16G 14.4 GiB
[ 186.254582] mmcblk0: p1 p2 p3
[ 278.412305] mmc0: card 0007 removed
[ 283.422445] mmc0: new high speed SDHC card at address 0007
[ 283.429376] mmcblk0: mmc0:0007 SD16G 14.4 GiB
[ 283.435799] mmcblk0: p1 p2 p3
[ 289.580203] mmc0: card 0007 removed
[ 290.942370] mmc0: new high speed SDHC card at address 0007
[ 290.949296] mmcblk0: mmc0:0007 SD16G 14.4 GiB
[ 290.955462] mmcblk0: p1 p2 p3
[ 295.052151] mmc0: card 0007 removed
[ 298.846302] mmc0: new high speed SDHC card at address 0007
[ 298.853264] mmcblk0: mmc0:0007 SD16G 14.4 GiB
[ 298.859456] mmcblk0: p1 p2 p3
[ 299.884125] mmc0: card 0007 removed
[ 303.678247] mmc0: new high speed SDHC card at address 0007
[ 303.685201] mmcblk0: mmc0:0007 SD16G 14.4 GiB
[ 303.691391] mmcblk0: p1 p2 p3
[ 666.252059] mmc0: card 0007 removed
[ 668.830490] mmc0: new high speed SDHC card at address 0007
[ 668.841424] mmcblk0: mmc0:0007 SD16G 14.4 GiB
[ 668.847621] mmcblk0: p1 p2 p3')
I think the second option is preferable, if a delay will occur when inserting a card I'd judge it insignificant in an order of one second. Which means that a poll period might be one second long.

[summers]

Now looking at synthesis of the comments, so I can push a final patch - with a slim chance of getting it into linux 5.1.

Its clear that we won't include "disable-wp", as we can write with that flag set, and this is common on rk3288 boards.

With the Card Detect wiring mistake. Probably there is a slight preference for "broken-cd" and take the poll overhead - which seems low on TB(S). E.g. did you knotice a slow down in the TB(S) with "broken-cd". As much as anything the sdio/mmc maintainers have expressed a preference for this in the past. People pushing for regulator always on, don't push so hard, and there are some clear weaknesses - e.g. voltage changes, and constant power usage.

To me whats interesting, is looks like ASUS just followed the development board reference for the TB(S). And worse They didn't correct the TBS after the TB ...

On wifi there has been less talk, I see if I can get some comments back. Anyway seems no major disagreement ...

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'd')id you notice a slow down in the TB(S) with "broken-cd"

[summers]

Just going through comments on the patchset - so I can do synthesis, merge and come up with way forward.

On comment that probably needs checking. When operating off the sd card, can you warm reboot off the cd card, with either of the "broken-cd" or the "regulator power patch" ? Reason for asking, power patch had a correction which allowed this, but not clear if this also work with "broken-cd".