Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

jmiahman · 2016-11-07 20:16:15

Currently on 4.9 I can do:

watch -n1 cat /sys/devices/pci0000:00/0000:00:0a.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001F:8086:22D8.0004/HID-SENSOR-200073.16.auto/iio:device6/in_accel_x_raw

rotate the screen and see numerical feedback in console.. Might be something to look into for screen rotation.

There's been some intel-ish changes in the last 24 hours for 4.9. I'll see if any of those make a difference. In case you don't know what intel-ish is.. here's a LWN article that explains a bit about this technology https://lwn.net/Articles/690997/ and the iio-sensor-proxy daemon.

In case someone wants/needs it, here's the output of my lsiio
[root@localhost tools]# lsiio -v
Device 003: incli_3d
in_incli_x_raw
in_incli_y_raw
in_incli_z_raw

Device 001: gyro_3d
in_anglvel_z_raw
in_anglvel_x_raw
in_anglvel_y_raw

Device 008: dev_rotation
in_rot_quaternion_raw

Device 006: accel_3d
in_accel_y_raw
in_accel_z_raw
in_accel_x_raw

Device 004: accel_3d
in_accel_y_raw
in_accel_z_raw
in_accel_x_raw

Device 002: incli_3d
in_incli_x_raw
in_incli_y_raw
in_incli_z_raw

Device 000: gyro_3d
in_anglvel_z_raw
in_anglvel_x_raw
in_anglvel_y_raw

Device 009: dev_rotation
in_rot_quaternion_raw

Device 007: magn_3d
in_rot_from_north_magnetic_tilt_comp_raw
in_magn_z_raw
in_magn_x_raw
in_magn_y_raw

Device 005: magn_3d
in_rot_from_north_magnetic_tilt_comp_raw
in_magn_z_raw
in_magn_x_raw
in_magn_y_raw

Trigger 007: magn_3d-dev7
Trigger 005: magn_3d-dev5
Trigger 003: incli_3d-dev3
Trigger 001: gyro_3d-dev1
Trigger 008: dev_rotation-dev8
Trigger 006: accel_3d-dev6
Trigger 004: accel_3d-dev4
Trigger 002: incli_3d-dev2
Trigger 000: gyro_3d-dev0
Trigger 009: dev_rotation-dev9

Last edited by jmiahman (2016-11-08 20:05:21)

pavan · 2016-11-09 14:17:02

jmiahman wrote:

jmiahman wrote:
gmelchett wrote:
{"10EC5648", "cht-bsw-rt5645", "intel/fw_sst_22a8.bin", "cht-bsw", NULL, &chv_platform_data },
{"10EC3270", "cht-bsw-rt5645", "intel/fw_sst_22a8.bin", "cht-bsw", NULL, &chv_platform_data },
And have a try.
I don't think it will be that easy, but I will give this a try on 4.9 as well.
Nope did not work...

Hi, do you have dmesg from this? Or any other observation?

Thanks

jmiahman · 2016-11-09 15:58:12

What are you looking for in a device message? The module loading but not truly initializing the hardware.. firmware failure.. etc..? Give me a few methods and outputs you are wanting to troubleshoot and I will take the time to rebuild a new kernel and the chance in ruining the sound on my T100HA. If you're just wanting me to blanket change things with no real direction or rational, then I am not willing to take the chance of my sound not working for just messing around. I am quite happy waiting to have working sound and not be a martyr for screwball attempts. I've seen hardware adviserly affected before, by very similiar attempts, so please excuse my reluctancy.

Last edited by jmiahman (2016-11-09 16:10:08)

pavan · 2016-11-09 16:34:06

jmiahman wrote:

What are you looking for in a device message? The module loading but not truly initializing the hardware.. firmware failure.. etc..? Give me a few methods and outputs you are wanting to troubleshoot and I will take the time to rebuild a new kernel and the chance in ruining the sound on my T100HA. If you're just wanting me to blanket change things with no real direction or rational, then I am not willing to take the chance of my sound not working for just messing around. I am quite happy waiting to have working sound and not be a martyr for screwball attempts. I've seen hardware adviserly affected before, by very similiar attempts, so please excuse my reluctancy.

I`d like to know whatever information about what is happening in this case. As I understand you`ve already tried this and I just wanted to know what you`ve found - "did not work" is quite short information :-) I suppose there was at least some error message or something. If you don`t have the data any more, never mind, I`ll try myself

jmiahman · 2016-11-10 04:09:47

pavan wrote:

I`d like to know whatever information about what is happening in this case. As I understand you`ve already tried this and I just wanted to know what you`ve found - "did not work" is quite short information :-) I suppose there was at least some error message or something. If you don`t have the data any more, never mind, I`ll try myself

Yeah that was about 15 builds ago.. However there is some sound work going on in master..

https://github.com/torvalds/linux/commi … 52104115b3

You may want to give that a try

gmelchett · 2016-11-10 06:50:18

jmiahman wrote:

pavan wrote:
I`d like to know whatever information about what is happening in this case. As I understand you`ve already tried this and I just wanted to know what you`ve found - "did not work" is quite short information :-) I suppose there was at least some error message or something. If you don`t have the data any more, never mind, I`ll try myself
Yeah that was about 15 builds ago.. However there is some sound work going on in master..
https://github.com/torvalds/linux/commi … 52104115b3
You may want to give that a try

Nothing related to Realtek 3270 :-( included.

What is needed, is the registermap, like this: http://lxr.free-electrons.com/source/so … s/rt5640.h

For the 5460, the default values of these registers are here http://lxr.free-electrons.com/source/so … 5640.c#L63

I would start with trying to dump the registermap, and if that works, compare the values ans see how alike it is. If the 3270 is a diet version of any of the other realtek chips, or not.
Unfortunately, with three children, oldest four, this is a way too big task to squeeze into my very limited spare time.

pavan · 2016-11-10 10:53:15

I have some little progress. I did some reverse engineering of the windows driver (RTII2SAC.sys) and there is some useful information. There is some kind of debugging mechanism, but deactivated (simply try strings RTII2SAC.sys or string -el RTII2SAC.sys to file names, function names, printf format strings). I managed to activate it partially and I now I have some log of i2c communication from windows. I am not sure how complete it is, but it is something. Based on this I suppose that 3270 is close to 5465, at least the driver calls function named ChangePowerStatus_5645 (I suppose so, but this string appears in the log). I can provide the full log and the modified driver if you want.

Yesterday I tried the code change described in post #27. I added one more - I changed this table http://lxr.free-electrons.com/source/so … 45.c#L3544 to:

static const struct acpi_device_id rt5645_acpi_match[] = {
    { "10EC5645", 0 },
    { "10EC5650", 0 },
    { "10EC5640", 0 },
    { "10EC3270", 0 },
    {},
};

With these two changes it looks promising - dmesg:

[   34.099480] intel_sst_acpi 808622A8:00: LPE base: 0x91400000 size:0x200000
[   34.102566] intel_sst_acpi 808622A8:00: IRAM base: 0x914c0000
[   34.105656] intel_sst_acpi 808622A8:00: DRAM base: 0x91500000
[   34.108035] intel_sst_acpi 808622A8:00: SHIM base: 0x91540000
[   34.110312] intel_sst_acpi 808622A8:00: Mailbox base: 0x91544000
[   34.112513] intel_sst_acpi 808622A8:00: DDR base: 0x20000000
[   34.114955] intel_sst_acpi 808622A8:00: Got drv data max stream 25
[   34.158965] cht-bsw-rt5645 cht-bsw-rt5645: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
[   34.169581] cht-bsw-rt5645 cht-bsw-rt5645: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
[   34.172010] compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok
[   34.175062] cht-bsw-rt5645 cht-bsw-rt5645: rt5645-aif1 <-> ssp2-port mapping ok
[   34.181194] input: chtrt5645 Headset as /devices/pci0000:00/808622A8:00/cht-bsw-rt5645/sound/card0/input11

and the content of /proc/asound/cards:

 0 [chtrt5645      ]: chtrt5645 - chtrt5645
                      chtrt5645

This is another sign that the chip is similar to rt5645 - the code here http://lxr.free-electrons.com/source/so … 45.c#L3688 reads the 0xff register which contains the same value as on rt5645. So far I didn`t damage anything, but I didn`t try anything else, e.g. play some sound. Anyone brave enough to do so? :-)

Dumping all registers is good idea and it shouldn`t be difficult, I`ll try that.

Last edited by pavan (2016-11-10 14:23:10)

gmelchett · 2016-11-10 14:18:53

Pavan, nice!
The internal speakers are not that dear to me, so I will give it a try with changing settings. If that works, I might even try to play some sound.
Btw, you mention both rt4565 and rt5645, is rt4565 a typo or?

pavan · 2016-11-10 14:21:44

gmelchett wrote:

Pavan, nice!
The internal speakers are not that dear to me, so I will give it a try with changing settings. If that works, I might even try to play some sound.
Btw, you mention both rt4565 and rt5645, is rt4565 a typo or?

It is rt5645, rt4565 is a typo. I`ll update my post. Thanks.

gmelchett · 2016-11-10 15:01:46

alsamixer looks quite sane. I inserted a pair of headphones, and I noticed nothing. (didn't check /proc/interrupts)
I tried to play an ogg file, and that failed with and I got in dmesg:

Audio Port: ASoC: no backend DAIs enabled for Audio Port

pavan · 2016-11-10 15:08:39

Thank you for the test. I`ll try to find what this could be.

I compared those registers. I dumped all the registers from 0 to 255 and compared with this table http://lxr.free-electrons.com/source/so … 5645.c#L73. There are not all the possible values in this table. These are the different ones.

0x8a 0000 - 0x0120 RT5645_ASRC_4
0xbf 0000 - 0x3100 RT5645_INT_IRQ_ST
0xc3 0000 - 0x2000
0xcf 0013 - 0x1813 RT5645_BASS_BACK
0xdf 0000 - 0x0008 RT5650_4BTN_IL_CMD1
0xe0 0000 - 0x4000 RT5650_4BTN_IL_CMD2
0xe7 0700 - 0x0200 RT5645_DRC1_HL_CTRL1
0xfd 0004 - 0x0002 RT5645_VENDOR_ID

The format is: "address 3270_value - rt5645_default register_name"

The rest is the same.

pavan · 2016-11-10 15:49:06

gmelchett wrote:

alsamixer looks quite sane. I inserted a pair of headphones, and I noticed nothing. (didn't check /proc/interrupts)
I tried to play an ogg file, and that failed with and I got in dmesg:
Audio Port: ASoC: no backend DAIs enabled for Audio Port

This may be only missing alsa configuration - see here https://bugzilla.kernel.org/show_bug.cgi?id=115201#c10 and here https://groups.google.com/forum/#!msg/a … 0NKfwfDQAJ
But this only what I`ve found googling the error message...

pavan · 2016-11-10 16:14:05

pavan wrote:

This may be only missing alsa configuration - see here https://bugzilla.kernel.org/show_bug.cgi?id=115201#c10 and here https://groups.google.com/forum/#!msg/a … 0NKfwfDQAJ
But this only what I`ve found googling the error message...

I take this back - it looks more like that some more changes are required - probably here sound/soc/intel/boards/cht_bsw_rt5645.c.

jmiahman · 2016-11-10 16:19:45

When you think you have something post patches and I will test on 4.9. Are you posting this as a kernel bug to and updating your findings. you may get someone who can point you in the right direction.

Last edited by jmiahman (2016-11-10 16:24:23)

gmelchett · 2016-11-10 18:32:13

pavan wrote:

Thank you for the test. I`ll try to find what this could be.
I compared those registers. I dumped all the registers from 0 to 255 and compared with this table http://lxr.free-electrons.com/source/so … 5645.c#L73. There are not all the possible values in this table. These are the different ones.
0x8a 0000 - 0x0120 RT5645_ASRC_4
0xbf 0000 - 0x3100 RT5645_INT_IRQ_ST
0xc3 0000 - 0x2000
0xcf 0013 - 0x1813 RT5645_BASS_BACK
0xdf 0000 - 0x0008 RT5650_4BTN_IL_CMD1
0xe0 0000 - 0x4000 RT5650_4BTN_IL_CMD2
0xe7 0700 - 0x0200 RT5645_DRC1_HL_CTRL1
0xfd 0004 - 0x0002 RT5645_VENDOR_ID
The format is: "address 3270_value - rt5645_default register_name"
The rest is the same.

More a like than I would have guessed! There are a few more registers in use, http://lxr.free-electrons.com/source/so … 5645.c#L60 How does these look on the T100HAN?

It isn't it weird that the check at http://lxr.free-electrons.com/source/so … 45.c#L3695 as you mentioned before passes?

I guess the windows driver does about the same check, is it visible in those logs? (Yes please, upload them somewhere and describe the scenarios - I'm curious)

And in /proc/interrupts, I get 1-3 interrupts on "intel_sst_driver" everytime I try to play some audio.

gmelchett · 2016-11-10 18:40:58

I ran the amixer lines from https://bugzilla.kernel.org/show_bug.cgi?id=115201#c10 and ogg123 is happily playing - but no sound in the speakers. (Will check headphones), and in /proc/interrupts I get thousens when starting to play, then a few hundred a seconds. Which sounds reasonable.

gmelchett · 2016-11-10 18:59:42

Nope, headphones are quite as well. In alsamixer there are like 100 settings that can be on/off/connected-to/...

gmelchett · 2016-11-15 17:21:29

Anyone tried rc5? It includes a hand full i915 fixes http://lwn.net/Articles/706323/. Probably not fixing our issue, but..

pavan · 2016-11-15 19:37:32

gmelchett wrote:

More a like than I would have guessed! There are a few more registers in use, http://lxr.free-electrons.com/source/so … 5645.c#L60 How does these look on the T100HAN?

I haven`t checked those yet...

gmelchett wrote:

It isn't it weird that the check at http://lxr.free-electrons.com/source/so … 45.c#L3695 as you mentioned before passes?

I don`t know, it simply means that 0xff register contains the same value. It is a simple test.

gmelchett wrote:

I guess the windows driver does about the same check, is it visible in those logs? (Yes please, upload them somewhere and describe the scenarios - I'm curious)

I`ll upload it, but it is not so helpful as I hoped, so I am working on a better version. I plan to hook directly the functions, which send data over i2c (if I found the right ones...) instead of reusing some forgotten debugging mechanism. Basically it works, but it goes slowly...

jmiahman · 2016-11-16 00:49:03

gmelchett wrote:

Anyone tried rc5? It includes a hand full i915 fixes http://lwn.net/Articles/706323/. Probably not fixing our issue, but..

I'm running it now, let me know if there's any specific tests you need me to run. I still need nomodeset to boot.

gmelchett · 2016-11-16 07:00:12

pavan wrote:

gmelchett wrote:
I guess the windows driver does about the same check, is it visible in those logs? (Yes please, upload them somewhere and describe the scenarios - I'm curious)
I`ll upload it, but it is not so helpful as I hoped, so I am working on a better version. I plan to hook directly the functions, which send data over i2c (if I found the right ones...) instead of reusing some forgotten debugging mechanism. Basically it works, but it goes slowly...

Impressive! Yeah, this leftover debugging mechanism might just show parts of what is actually going on.

gmelchett · 2016-11-16 07:04:22

jmiahman wrote:

gmelchett wrote:
Anyone tried rc5? It includes a hand full i915 fixes http://lwn.net/Articles/706323/. Probably not fixing our issue, but..
I'm running it now, let me know if there's any specific tests you need me to run. I still need nomodeset to boot.

I'm interested in if i915 works without reverting those two patches and do some xrandr calls. But if you still need nomodeset, that answers my question.
Btw, I don't use nomodeset, two patches reverted and the xrandr off/auto, and it works just fine. No freezes, no resets.
I do have some new timeouts in dmesg after a few hours, but those are not noticeable otherwise.

jmiahman · 2016-11-16 16:11:29

i915 has changed multiple times now and I've had to revert those patches.. I haven't reapplied because I am hoping it might get fixed. At this point I really don't mind using the fb driver as I am not doing anything graphic intensive.

gmelchett · 2016-12-05 07:29:20

pavan, have you created a kernel bug on your dsdt "fix" for wlan and the sdcard? There might be a possible workaround on driver level.
If you don't have the time, I could do it.

Currently, I'm testing patches for sd-reader's card detect. As it is as now, it works when compiled in the kernel, but that is just co incidents, since it looks like a _DEP to GPO3 is missing. The kernel developer from Intel that does the patches, thinks a software workaround for the sd-card's missing _DEP is possible.

gmelchett · 2016-12-07 09:59:08

Filed a bug on the _ADR to _WADR issue: https://bugzilla.kernel.org/show_bug.cgi?id=189801

Arch Linux

#51 2016-11-07 20:16:15

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#52 2016-11-09 14:17:02

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#53 2016-11-09 15:58:12

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#54 2016-11-09 16:34:06

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#55 2016-11-10 04:09:47

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#56 2016-11-10 06:50:18

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#57 2016-11-10 10:53:15

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#58 2016-11-10 14:18:53

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#59 2016-11-10 14:21:44

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#60 2016-11-10 15:01:46

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#61 2016-11-10 15:08:39

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#62 2016-11-10 15:49:06

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#63 2016-11-10 16:14:05

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#64 2016-11-10 16:19:45

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#65 2016-11-10 18:32:13

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#66 2016-11-10 18:40:58

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#67 2016-11-10 18:59:42

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#68 2016-11-15 17:21:29

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#69 2016-11-15 19:37:32

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#70 2016-11-16 00:49:03

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#71 2016-11-16 07:00:12

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#72 2016-11-16 07:04:22

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#73 2016-11-16 16:11:29

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#74 2016-12-05 07:29:20

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

#75 2016-12-07 09:59:08

Re: Guide: Installing Arch on Asus Transformer T100HA (T100HAN)

Board footer