Hi Carlo,
>>>>> As Marcel suggested we can assume that the information in the DSDT is
>>>>> correct so that we can get rid of the config blob also for x86
>>>>> platforms (assuming that the only useful information in the config
>>>>> blobs is the UART configuration).
>>>> in my tests I tried to send only the firmware without the config to my
>>>> RTL8723BS. unfortunately the last firmware chunk (sent to the
>>>> controller) times out in that case (even if I set a proper baudrate
>>>> before or if I specify no baudrate at all and keep the serdev at
>>>> 115200)
>>>
>>> What's in the config blobs besides UART configuration?
>>
>> is anybody writing a rtlfw.c tool (like nokfw.c) so that we can print out what we actually have in these config files?
>>
>>> It's odd because reading into hciattach_rtk.c it seems that the config
>>> file is actually only used by the userspace tools (hciattach) to
>>> retrieve the UART configuration and nothing else, whereas in the
>>> kernel driver the config blob is appended to the firmware.
>>
>> Frankly, I am inclined to not use the config file even for DT based system and just allow specifying the UART settings via normal DT properties like we do for Broadcom and others.
>
> so I googled for a few config files and this is what this turns into:
>
> Analyzing rtl8723d_config_1000000_noflow.dms
> Signature: 0x8723ab55
> Data length: 41
> len=1 offset=f4,{ 01 }
> len=2 offset=f6,{ 81 00 }
> len=2 offset=fa,{ 12 80 }
> len=16 offset=0c,{ 04 50 00 00 50 c5 ea 19 e1 1b fd af 5b 01 a4 0b }
> len=1 offset=d9,{ 0f }
> len=1 offset=e4,{ 08 }
> Analyzing rtl8723d_config.dms
> Signature: 0x8723ab55
> Data length: 41
> len=1 offset=f4,{ 01 }
> len=2 offset=f6,{ 81 00 }
> len=2 offset=fa,{ 12 80 }
> len=16 offset=0c,{ 02 80 92 04 50 c5 ea 19 e1 1b fd af 5f 01 a4 0b }
> len=1 offset=d9,{ 0f }
> len=1 offset=e4,{ 08 }
> Analyzing rtl8822b_config.bin
> Signature: 0x8723ab55
> Data length: 8
> len=1 offset=d9,{ 0f }
> len=1 offset=e4,{ 08 }
>
> The first two are some UART based ones and the last one is USB based.
>
> So the 0x3c offset seems to be the BD_ADDR and 0x0c offset is the UART configuration. It would be good to know which settings the other ones control.
>
> Also the 16 octet UART config blob seems to be decoded like this:
>
> uart_config {
> le32 baudrate;
> u8[8] reserved1;
> u8 flowctl;
> u8[3] reserved2;
> }
>
> Actually hciattach_rtk just takes the baud rate and and hardware flow control bit out of this file. That is clearly two things that are better written in plain text in the DT file.
so this is actually some funny stuff if you start to understand it.
Analyzing rtl8723b_config.dms
Signature: 0x8723ab55
Data len: 38
len=8 offset=00f4,{ 01 00 00 00 05 50 00 00 }
len=16 offset=000c,{ 02 80 92 04 50 c5 ea 19 e1 1b f1 af 5f 01 a4 0b },UART_CONFIG
len=1 offset=0027,{ 63 }
len=1 offset=00fe,{ 01 }
Analyzing rtl8723d_config_1000000_noflow.dms
Signature: 0x8723ab55
Data len: 41
len=1 offset=00f4,{ 01 }
len=2 offset=00f6,{ 81 00 }
len=2 offset=00fa,{ 12 80 }
len=16 offset=000c,{ 04 50 00 00 50 c5 ea 19 e1 1b fd af 5b 01 a4 0b },UART_CONFIG
len=1 offset=00d9,{ 0f }
len=1 offset=00e4,{ 08 }
Seems like Realtek really defines memory offsets in this file and they can be defined in various different ways.
So 00f4,{ 01 00 00 00 05 50 00 00 } defines the whole PCM settings for interface 1 and 2. And 00f4,{ 01 } + 00f6,{ 81 00 } + 00fa,{ 12 80 } is the same PCM settings, but with only pieces of it defined.
This also means a 000c,{ 04 50 00 00 50 } for just setting the baud rate is as valid if flow control defaults to off and all other values are actual defaults. So code inside hciattach_rtk.c is also kind faulty on how it handles the flow control bit. It works if the config files all have offset 000c in it, but if not, then they are going funky.
Since these are efuse settings, I really wonder if there is just a HCI vendor command to read out the defaults and we use that to compare. And what I would really like to know is what these settings are suppose to change. Since even for USB, we are actually not even applying them.
Anyway, I am certain that for Realtek UART devices, we just want to specify max-speed DT property like we do with the others. And then maybe a flow-control DT property to control that one (following what nfcmrvl.txt does). We can use the rtlfw tool that I wrote to extract the values from Realtek provided config files. Frankly the PCM settings we have to deal with as well at some point. But that is also missing for Broadcom and others.
Also if there is no config file, we should be able to just assume no flow control, 115200 baud rate and H:5 as protocol. That means that almost all chips will just work. They are just slow since we do not deal with the max-speed setting.
At the end of the day, this is the same as for Broadcom and ACPI vs DT. This should be no different. The only bit nasty part is that this is H:5 as protocol and we have not really abstracted that one nicely to just have a tiny hci_rtl.c for vendor specific pieces.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
