Device-tree improvements

[summers]

OK just winding up for doing a -lgb and -djs releases this weekend. dtb for each. I'll also have to do a hci_h5 kernel module that has the device tree hooks in.

To do all this need to base on a kernel, my pocket beagle is busy doing 4.20 - so hope you are one that series, as the bluetooth module will need moving into the module directory. I'm hopeful that linux doesn't moan when minor version changes, if it does does you'll have to force the module into the running kernel.

@lgb

The hci_h5 kernel module currently links against the realtek bluetooth code. I think the realtek code just loads the firmware needed, whereas the hci_h5 just does the bluetooth 4.0 3 wire interface, and the uart code does the 5 wire uart.

What this means to me is that it isn't clear who should handle reset, device_wake, host_wake? I think we'll have to discuss with marcel, the bluetooth maintainer. I'm tempted to leave that alone for the time being.

So really all that needed is the device tree realtek-rtl8723bs-bt hook adding to hci_h5; and this is where this part of the thread started. What complicated this, is marcel needs documentation adding when the hook is added. Documentation is owned by Rob Herring, and he needs an example in all documentation; and in particular needs it to be correct for the linux style.

I take Rob line to be that the device tree accurately describes the hardware, and so would plan to make that as complete as possible. Then in the covering email, explain that the handles aren't processed by the hci_h5, nor should they be, and that should be an extended discussion with Marcel.

Hopefully that will be enough for Marcel and Rob to accept.

Anyway only bluetooth hardware we aren't describing is the 32kHz clock; as asus code gives no hints there. Its almost certainly the rk808 32kHz line I expect.

Anyway really need to roll out dtb for TheSaint to try, as then we can at least say tested ...

[summers]

@TheSaint

Can you try http://davidjohnsummers.uk/TBSnew.tar.gz

You'll need to copy the hci_uart.ko file into $this->bbcode_second_pass_quote('', '/')lib/modules/4.20.*-ARCH/kernel/drivers/bluetooth/

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'E')dit: not sure that the .ko is correct

[summers]

Apols should have been cleared, its only the rk3288-tinker-s dtb that are aimed at the TBS, the others are aimed at the TB. becuase WiFi is common to both boards, I made changes to the include file which both depend on. So Actually had both dtb generated which was why passed onto you.

Its actually the hci_uart module that needs loading, that is for serial connections, whereas btrtl is for usb ...

I think in the lib directory its just the .ko gzipped?

Anyway, as said yesterday the hci_uart file wasn't linking in the realtek bits - its a bit subtle, but have a hack way round, and will look for a proper solution tonight. Problem is that the rtl code needs ACPI for some reason ...

Did any of the provided dtb bring up wifi btw? I can see the sdio interface coming up, but not if there is WiFi on the far end ...

[summers]

Hmmm - I've a horrible suspicion that bluetooth depends on ACPI, and that you can't do ACPI on arm ....

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'I') think in the lib directory its just the .ko gzipped?

[summers]

Yup problem is that the hci_h5 code for realtek has been written in a ACPI way. ACPI exists on armv8 I think, but I think it never went to 32bit arms.

Alas if this is the case, I'd conclude that the realtek 3wire uart bluetooth driver needs rewriting before it can work on arm machines, and IIRC there are several machines using this chip. Daft thing is that most desk tops using this chip wouldn't use the uart interface - and this means a different driver. So most of the boards using the uart are probably arm and won't work.

Annoying, but I think such is life. Unless anyone sees a way forward ...

[lategoodbye]

Hi,
i was busy with Kernel 5.1 pull requests, so here my short feedback. I can confirm that Wifi isn't detected via SDIO. At this point it must be checked that the Wifi chip is really powered and not tied in reset. I think this would be hard to realise.

[summers]

Thanks lgb. I'll keep comparing with the asus patch - and try and dig out the functional difference. Didn't realise that you also have a tinker board ...

[summers]

I asked ASUS for the schematics for the TBS. Alas its just like the TB schematics, doesn't show UART0. The clocks on RK808 don't have a osc, and one output goes staight to VCCC33, the other to T8111 TPC26b which makes no sense. The clock osc on the RK3288 is. So there is no where to get the 32MHz for the wifi/bluetooth.

Indeed I not it it has been changed from the TB schematic.

Anyway I'l look carefully at it ...