Device-tree improvements

[TheSaint]

Hey Summers, have you noted how they do on rk3288-miniarm.dts.

[summers]

Oh yes - its from the minarm that I've learn which pins are connected on the TB(S). My code, and that of @lgb have redone the pins and set up thing in a mainline way. And actually when you look at how we updated the code - you realise its far clearer and better than ASUS device tree.

As regards bluetooth, its not the device tree that slops it working. Its the code set up here https://github.com/TinkerBoard/debian_kernel/commit/5106d9486cf1c2bad4f701611f51a526191c56ad asus modified the hci_h4 code to work with the rtl8723bs.

Mainline kernel read the data sheer for rtl8723, discovered it Bluetooth 4.0 IIRC, and if you get that spec as part of it, it describes 3 wire protocol, and thats why mainline modified the hci_h5 driver which is the 3 wire driver. 3 wire by the name doesn't explain why its better than the old UART interface, 3 wire has a lot of error correction and far more functionally than the old UART spec. So I agree with mainline that using the 3 wire spec is best - but in this case the TB(S) has RT-TX-CTS-RTS connected and so is 5 wire (with GND) - which we can use in mainline linux, but still use 3 wire protocol.

The issue with bluetooth is far more complex, it goes to the core of how bluetooth works, and the layering in linux. rtl8723 is connected via uart, and so mainline uses a uart interface to handle that connection - and that is good. The 3 wire protocol is best, and thats the hci_h5 driver and rtl8723bs should understand. But the complexity is the wake up pins in both directions, and the enable pins in both directions. Linux as far as I can see has no generic way of handling. So one ether writes a driver specifically for rtl devices with the pins it has; or one work out how to integrate with uart+3_wire. This is a complex question and goes to the heart of bluetooth - and so one needs to pull marcel into the discussion, and maybe wider in linux. This is very complex in the linux management set up, probably because its a complex problem.

I guess this is why I'm so hesitant to enter the frey, there is so much to take on board, now maybe I could, but with a full time job - its not what I'm paid for, my job in the space industry has its own complications, and that as my job it takes priority.

[summers]

Now back to @rtl and the bluetooth driver.

Yes I agree in principle that drivers should not be dependent on a device, but the difficulty is that acpi is universal in the x86 world, so it is generic. ACPI and arm though is more complex, it has been accepted for armv8, but not for 32bit arm armv7 and below. These devices as far as I can see have no concept of ACPI - try for yourself to enable acpi in a armv7 in the kernel config - I couldn't manage it, and yes I tried. I'm fairly sure it isn't supported.

And so to the hci_h5 driver, and realtek, this patch applies: https://github.com/torvalds/linux/commit/51474eff2bc2777061ab3658e014a37dc9d7a775

It say that the realtek driver is dependent on acpi, and if you read the hci_h5 code you see that indeed true, and if your remove the code applied above you do indeed get: $this->bbcode_second_pass_code('', 'drivers/bluetooth/hci_h5.c:920:22: warning: 'rtl_vnd' defined but not used [-Wunused-variable]').

To my mind, the question is how to integrate 8723 pins into the driver, and how to set up the driver so it isn't dependent on acpi. This goes beyond my comfort level. So how to find a way forward.

On the patches, I'm still minded to submit the the bluetooth device tree as a RFC. As much as anything you can only submit new device tree compatible bindings with and example in the description. So for the description, we are close in the TB(S) - so I'd like comments, so we can defend when the request for compatible get introduced. Also much work has been put into identify the bluetooth pins, if we do not submit - how would someone else identify the pins?

So can we develop a new bluetooth driver? I'm not sure I have the will to live ...

[lategoodbye]

Okay, here you go a little hack to enable device tree support in hci_h5 (only compile tested and based against Linux next, will never work with 4.20 or below):
https://gist.github.com/lategoodbye/79b ... a3c45eb7f1

As the driver doesn't seem to support host wakeup yet, i leave this out of the binding.

It could be a nice homework to adapt the Tinker Board dts accordingly

[summers]

OK patch submitted. The WiFi one is here:

http://lists.infradead.org/pipermail/linux-rockchip/2019-February/022951.html

But there are also ones for sd card and bluetooth.

[summers]

Had had several replies back already on the patches. This is good - shows more interest than last time. Armbian has had similar problems with the TB(S) and come up with similar solutions - and so are quite supporting.

And interesting suggestion from arm is that the sd card errors may be caused by a powering issue, where the regulator to the sd slot gets turned off.

So to test this another device tree for you : http://davidjohnsummers.uk/TBSpost1.tar.gz

Can you boot from eMMC, but then try the sdCard and see if you get the errors? This device tree doesn't have broken-cd but a power hack to keep the power on ...

And another question, when you are getting the endless sd card errors, do the errors stop if you plug in an sd card?

Also I tried @lgb patch for the hci_h5. Thats attached. Can you try this in a 4.20 kernel. The device tree has the right hooks to auto load this.

[TheSaint]

Tested the SD insertion work like a charm
I didn't find the hci_uart module loaded. If tried to insert it reported wrong exec format.

[summers]

Bingo! That means Robin from Arm solution was correct - it was a power issue that was giving the problems.

This is good broken-cd was a hack, that meant that the CPU had to keep polling the sd interface to see if a card was there, with this change that won't need to happen, instead it can wait for a signal from the CD (Card Detection) and use that to start probing the sd interface.

This really is much better - to my mind the sd io interface should be kept powered, without it we loose IO and that doesn't make sense, and caused your problem.

So I'll remove the patch I've already put in, and replace with this one.

Why the module wasn't loading is confusing - I'll look at the logs closer and see if I can see what the issue is. Actually after moving the .ko.gz to the lib directory did you run $this->bbcode_second_pass_code('', 'depmod -ae')

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'd')id you run $this->bbcode_second_pass_code('', 'depmod -ae')

[summers]

OOps I must have done the .ko object wrong not sure how. When I get the chance I'll do it again, as well as another patch to the same file that was submitted to the bluetooth thread ..