Device-tree improvements

This is for any ARMv7 device that we do not officially support.

Re: Device-tree improvements

Postby TheSaint » Sat Feb 16, 2019 1:59 am

Hey Summers, have you noted how they do on rk3288-miniarm.dts.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Sat Feb 16, 2019 2:37 pm

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
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby summers » Sat Feb 16, 2019 3:43 pm

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 ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby lategoodbye » Sun Feb 17, 2019 11:07 am

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 :mrgreen:
lategoodbye
 
Posts: 116
Joined: Sat Dec 29, 2018 1:24 am

Re: Device-tree improvements

Postby summers » Sun Feb 17, 2019 12:24 pm

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
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby summers » Sun Feb 17, 2019 3:45 pm

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.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Tue Feb 19, 2019 7:40 am

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.
Attachments
report-tinker-s.power.txt.7z
(21.75 KiB) Downloaded 1190 times
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Tue Feb 19, 2019 10:03 am

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')
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Wed Feb 20, 2019 7:52 am

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

Ah!, my mistake! I forgotten the command.
Here's the report:
$this->bbcode_second_pass_code('', '$ sudo depmod -ae
depmod: WARNING: -e needs -E or -F

===================================================================

$ lsmod
Module Size Used by
8021q 32768 0
garp 16384 1 8021q
mrp 20480 1 8021q
stp 16384 1 garp
llc 16384 2 garp,stp
joydev 20480 0
realtek 16384 1
snd_soc_hdmi_codec 16384 1
dw_hdmi_cec 16384 0
dw_hdmi_i2s_audio 16384 0
snd_soc_simple_card 16384 0
snd_soc_simple_card_utils 16384 1 snd_soc_simple_card
r8723bs 569344 0
evdev 24576 2
rockchip_rga 20480 0
v4l2_mem2mem 24576 1 rockchip_rga
videobuf2_dma_sg 16384 1 rockchip_rga
videobuf2_memops 16384 1 videobuf2_dma_sg
snd_soc_rockchip_i2s 16384 2
snd_soc_rockchip_pcm 16384 1 snd_soc_rockchip_i2s
videobuf2_v4l2 24576 2 v4l2_mem2mem,rockchip_rga
snd_soc_core 159744 5 snd_soc_rockchip_i2s,snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_rockchip_pcm,snd_soc_simple_card
videobuf2_common 45056 3 v4l2_mem2mem,videobuf2_v4l2,rockchip_rga
ac97_bus 16384 1 snd_soc_core
rk_crypto 24576 0
snd_pcm_dmaengine 16384 1 snd_soc_core
cfg80211 294912 1 r8723bs
pwm_rockchip 16384 0
dw_wdt 16384 0
rfkill 24576 3 cfg80211
snd_usb_audio 188416 0
snd_usbmidi_lib 28672 1 snd_usb_audio
snd_hwdep 16384 1 snd_usb_audio
snd_rawmidi 32768 1 snd_usbmidi_lib
snd_seq_device 16384 1 snd_rawmidi
snd_pcm 94208 4 snd_usb_audio,snd_pcm_dmaengine,snd_soc_hdmi_codec,snd_soc_core
snd_timer 32768 1 snd_pcm
dwmac_rk 28672 0
rockchip_saradc 16384 0
stmmac_platform 20480 1 dwmac_rk
stmmac 126976 2 stmmac_platform,dwmac_rk
rockchipdrm 94208 0
analogix_dp 32768 1 rockchipdrm
dw_hdmi 32768 2 rockchipdrm,dw_hdmi_i2s_audio
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
sch_fq_codel 20480 6
crypto_user 20480 0
ip_tables 28672 0
x_tables 32768 1 ip_tables

===================================================================

$ ls /proc/device-tree
'#address-cells' interrupt-controller@ffc01000 qos@ffaf0080
'#size-cells' interrupt-parent reserved-memory
aliases iommu@ff900800 rga@ff920000
amba iommu@ff914000 saradc@ff100000
arm-pmu iommu@ff930300 sdio-pwrseq
bus_intmem@ff700000 iommu@ff940300 sdmmc-regulator
chosen iommu@ff9a0800 serial@ff180000
clock-controller@ff760000 iommu@ff9c0440 serial@ff190000
compatible lvds@ff96c000 serial@ff1b0000
cpu-opp-table memory serial@ff1c0000
cpus mipi@ff960000 serial@ff690000
cypto-controller@ff8a0000 model sound
display-subsystem name sound@ff88b0000
dp@ff970000 oscillator spi@ff110000
dwmmc@ff0c0000 pinctrl spi@ff120000
dwmmc@ff0d0000 power-management@ff730000 spi@ff130000
dwmmc@ff0e0000 pwm@ff680000 sram@ff720000
dwmmc@ff0f0000 pwm@ff680010 syscon@ff740000
efuse@ffb40000 pwm@ff680020 syscon@ff770000
ethernet@ff290000 pwm@ff680030 thermal-zones
external-gmac-clock qos@ffaa0000 timer
gpio-keys qos@ffaa0080 timer@ff810000
gpio-leds qos@ffad0000 tsadc@ff280000
gpu-opp-table qos@ffad0100 usb@ff500000
gpu@ffa30000 qos@ffad0180 usb@ff540000
hdmi@ff980000 qos@ffad0400 usb@ff580000
i2c@ff140000 qos@ffad0480 usb@ff5c0000
i2c@ff150000 qos@ffad0500 vop@ff930000
i2c@ff160000 qos@ffad0800 vop@ff940000
i2c@ff170000 qos@ffad0880 vsys-regulator
i2c@ff650000 qos@ffad0900 watchdog@ff800000
i2c@ff660000 qos@ffae0000
i2s@ff890000 qos@ffaf0000
===================================================================

$ sudo modprobe hci_uart
modprobe: ERROR: could not insert 'hci_uart': Exec format error
===================================================================

$ find /usr/lib/modules/4.20.6-1-ARCH/ -iname *hci_u*
/usr/lib/modules/4.20.6-1-ARCH/kernel/drivers/bluetooth/hci_uart.ko.gz
/usr/lib/modules/4.20.6-1-ARCH/kernel/drivers/bluetooth/hci_uart.ko.old

===================================================================

$ uname -a
Linux alarm 4.20.6-1-ARCH #1 SMP PREEMPT Fri Feb 8 02:30:15 UTC 2019 armv7l GNU/Linux
')
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Wed Feb 20, 2019 4:24 pm

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 ..
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

PreviousNext

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 7 guests