* 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
@ 2015-12-12 14:04 Alex Ballas
2015-12-16 3:42 ` Peter Guo
0 siblings, 1 reply; 15+ messages in thread
From: Alex Ballas @ 2015-12-12 14:04 UTC (permalink / raw)
To: peter.guo, adam.lee, ulf.hansson; +Cc: linux-mmc
[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]
Hello,
I have a Dell Latitude E7450 with a O2 Micro, SD/MMC Card Reader
[1217:8520] card reader. When I insert my Sandisk ultra 64GB microSD
(with a SD card adapter) I get the following errors.
Dmesg output after I insert the SD card:
[ 306.054203] sdhci: Timeout waiting for Buffer Read Ready interrupt
during tuning procedure, falling back to fixed sampling clock
[ 306.055982] mmc0: tuning execution failed
[ 306.055987] mmc0: error -5 whilst initialising SD card
[ 306.466185] sdhci: Timeout waiting for Buffer Read Ready interrupt
during tuning procedure, falling back to fixed sampling clock
[ 306.467964] mmc0: tuning execution failed
[ 306.467970] mmc0: error -5 whilst initialising SD card
[ 306.890205] sdhci: Timeout waiting for Buffer Read Ready interrupt
during tuning procedure, falling back to fixed sampling clock
[ 306.891993] mmc0: tuning execution failed
[ 306.892005] mmc0: error -5 whilst initialising SD card
[ 307.330197] sdhci: Timeout waiting for Buffer Read Ready interrupt
during tuning procedure, falling back to fixed sampling clock
[ 307.331980] mmc0: tuning execution failed
[ 307.331990] mmc0: error -5 whilst initialising SD card
I used the latest mainline kernel available to me [1]
$ uname -a
Linux cosmo 4.4.0-040400rc4-generic #201512061930 SMP Mon Dec 7
00:32:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
It was working fine for kernel versions older than 4.1.8.
I did a bisection and here is the first bad commit
> e6c69099f63c84e1825c0f742a76ff4a8afeaa9b is the first bad commit
> commit e6c69099f63c84e1825c0f742a76ff4a8afeaa9b
> Author: Adam Lee <adam.lee@canonical.com>
> Date: Mon Aug 3 14:33:28 2015 +0800
>
> mmc: sdhci-pci: set the clear transfer mode register quirk for O2Micro
>
> commit 143b648ddf1583905fa15d32be27a31442fc7933 upstream.
>
> This patch fixes MMC not working issue on O2Micro/BayHub Host, which
> requires transfer mode register to be cleared when sending no DMA
> command.
>
> Signed-off-by: Peter Guo <peter.guo@bayhubtech.com>
> Signed-off-by: Adam Lee <adam.lee@canonical.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I originally logged this issue to the Ubuntu bug tracker[2], but it
appears to be an upstream issue and so I was instructed to report
here.
Please note that I use the latest Bios version for the model.
$ sudo dmidecode -s bios-version;sudo dmidecode -s bios-release-date
A08
10/28/2015
[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc4-wily/
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523178
Thanks,
Alex
[-- Attachment #2: Environment_info --]
[-- Type: application/octet-stream, Size: 48142 bytes --]
$ cat /proc/version
Linux version 4.4.0-040400rc4-generic (kernel@tangerine) (gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) ) #201512061930 SMP Mon Dec 7 00:32:31 UTC 2015
$ lsb_release -rd
Description: Ubuntu 15.10
Release: 15.10
$ /usr/src/linux-headers-4.4.0-040400rc4/scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux cosmo 4.4.0-040400rc4-generic #201512061930 SMP Mon Dec 7 00:32:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
GNU C 5.2.1
GNU Make 4.0
Binutils 2.25.1
Util-linux 2.26.2
Mount 2.26.2
Module-init-tools 21
E2fsprogs 1.42.12
Pcmciautils 018
PPP 2.4.6
Linux C Library 2.21
Dynamic linker (ldd) 2.21
Linux C++ Library 6.0.21
Procps 3.3.9
Net-tools 1.60
Kbd 1.15.5
Console-tools 1.15.5
Sh-utils 8.23
Udev 225
Wireless-tools 30
Modules Loaded 8250_dw 8250_fintek ablk_helper ac97_bus acpi_als acpi_pad acpi_thermal_rel aesni_intel aes_x86_64 ahci ansi_cprng arc4 autofs4 binfmt_misc bluetooth bnep bridge btbcm btintel btrtl btusb ccm cfg80211 coretemp crc32_pclmul crct10dif_pclmul cryptd ctr dcdbas dell_laptop dell_rbtn dell_smm_hwmon dell_smo8800 dell_wmi dm_bio_prison dm_bufio dm_persistent_data dm_thin_pool drbg drm drm_kms_helper dw_dmac dw_dmac_core e1000e ebtable_filter ebtables elan_i2c fb_sys_fops fjes gf128mul glue_helper hid hid_generic i2c_algo_bit i2c_designware_core i2c_designware_platform i2c_hid i915 industrialio input_leds int3400_thermal int3402_thermal int3403_thermal int340x_thermal_zone intel_powerclamp intel_rapl intel_soc_dts_iosf iosf_mbi ip6table_filter ip6_tables iptable_filter iptable_mangle iptable_nat ip_tables ipt_MASQUERADE ipt_REJECT irqbypass iwlmvm iwlwifi joydev kfifo_buf kvm kvm_intel libahci libcrc32c llc lp lpc_ich lrw mac80211 mac_hid media mei mei_me nf_conntrack nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat nf_nat_ipv4 nf_nat_masquerade_ipv4 nf_reject_ipv4 nls_iso8859_1 parport parport_pc pci_stub ppdev pps_core processor_thermal_device psmouse ptp rfcomm sdhci sdhci_acpi sdhci_pci serio_raw shpchp snd snd_compress snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_core snd_hda_intel snd_hwdep snd_pcm snd_pcm_dmaengine snd_rawmidi snd_seq snd_seq_device snd_seq_midi snd_seq_midi_event snd_soc_core snd_soc_rl6231 snd_soc_rt5640 snd_soc_ssm4567 snd_soc_sst_acpi snd_timer snd_usb_audio snd_usbmidi_lib soundcore sparse_keymap spi_pxa2xx_platform stp syscopyarea sysfillrect sysimgblt uas usbhid usb_storage uvcvideo v4l2_common vboxdrv vboxnetadp vboxnetflt vboxpci video videobuf2_core videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc videodev wmi x86_pkg_temp_thermal x_tables xt_addrtype xt_CHECKSUM xt_conntrack xt_tcpudp
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 61
model name : Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
stepping : 4
microcode : 0x21
cpu MHz : 1812.238
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb pln pts dtherm intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt
bugs :
bogomips : 4589.48
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 61
model name : Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
stepping : 4
microcode : 0x21
cpu MHz : 2051.492
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb pln pts dtherm intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt
bugs :
bogomips : 4589.48
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 61
model name : Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
stepping : 4
microcode : 0x21
cpu MHz : 1331.574
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb pln pts dtherm intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt
bugs :
bogomips : 4589.48
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 61
model name : Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
stepping : 4
microcode : 0x21
cpu MHz : 1304.531
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb pln pts dtherm intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt
bugs :
bogomips : 4589.48
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
$ cat /proc/modules
pci_stub 16384 1 - Live 0x0000000000000000
vboxpci 24576 0 - Live 0x0000000000000000 (OE)
vboxnetadp 28672 0 - Live 0x0000000000000000 (OE)
vboxnetflt 28672 0 - Live 0x0000000000000000 (OE)
vboxdrv 454656 3 vboxpci,vboxnetadp,vboxnetflt, Live 0x0000000000000000 (OE)
drbg 32768 1 - Live 0x0000000000000000
ansi_cprng 16384 0 - Live 0x0000000000000000
ctr 16384 3 - Live 0x0000000000000000
ccm 20480 3 - Live 0x0000000000000000
rfcomm 69632 2 - Live 0x0000000000000000
snd_usb_audio 176128 2 - Live 0x0000000000000000
snd_usbmidi_lib 36864 1 snd_usb_audio, Live 0x0000000000000000
xt_CHECKSUM 16384 1 - Live 0x0000000000000000
iptable_mangle 16384 1 - Live 0x0000000000000000
ipt_REJECT 16384 2 - Live 0x0000000000000000
nf_reject_ipv4 16384 1 ipt_REJECT, Live 0x0000000000000000
xt_tcpudp 16384 6 - Live 0x0000000000000000
ebtable_filter 16384 0 - Live 0x0000000000000000
ebtables 36864 1 ebtable_filter, Live 0x0000000000000000
ip6table_filter 16384 0 - Live 0x0000000000000000
ip6_tables 28672 1 ip6table_filter, Live 0x0000000000000000
xt_addrtype 16384 2 - Live 0x0000000000000000
xt_conntrack 16384 2 - Live 0x0000000000000000
ipt_MASQUERADE 16384 4 - Live 0x0000000000000000
nf_nat_masquerade_ipv4 16384 1 ipt_MASQUERADE, Live 0x0000000000000000
iptable_nat 16384 1 - Live 0x0000000000000000
nf_conntrack_ipv4 16384 3 - Live 0x0000000000000000
nf_defrag_ipv4 16384 1 nf_conntrack_ipv4, Live 0x0000000000000000
nf_nat_ipv4 16384 1 iptable_nat, Live 0x0000000000000000
iptable_filter 16384 1 - Live 0x0000000000000000
ip_tables 28672 3 iptable_mangle,iptable_nat,iptable_filter, Live 0x0000000000000000
x_tables 36864 12 xt_CHECKSUM,iptable_mangle,ipt_REJECT,xt_tcpudp,ebtables,ip6table_filter,ip6_tables,xt_addrtype,xt_conntrack,ipt_MASQUERADE,iptable_filter,ip_tables, Live 0x0000000000000000
nf_nat 24576 2 nf_nat_masquerade_ipv4,nf_nat_ipv4, Live 0x0000000000000000
nf_conntrack 106496 5 xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat, Live 0x0000000000000000
bridge 126976 0 - Live 0x0000000000000000
stp 16384 1 bridge, Live 0x0000000000000000
llc 16384 2 bridge,stp, Live 0x0000000000000000
dm_thin_pool 61440 1 - Live 0x0000000000000000
dm_persistent_data 65536 1 dm_thin_pool, Live 0x0000000000000000
dm_bio_prison 16384 1 dm_thin_pool, Live 0x0000000000000000
dm_bufio 28672 1 dm_persistent_data, Live 0x0000000000000000
libcrc32c 16384 1 dm_persistent_data, Live 0x0000000000000000
binfmt_misc 20480 1 - Live 0x0000000000000000
bnep 20480 2 - Live 0x0000000000000000
nls_iso8859_1 16384 1 - Live 0x0000000000000000
dell_wmi 16384 0 - Live 0x0000000000000000
sparse_keymap 16384 1 dell_wmi, Live 0x0000000000000000
uvcvideo 90112 0 - Live 0x0000000000000000
videobuf2_vmalloc 16384 1 uvcvideo, Live 0x0000000000000000
dell_laptop 20480 0 - Live 0x0000000000000000
videobuf2_memops 16384 1 videobuf2_vmalloc, Live 0x0000000000000000
videobuf2_v4l2 28672 1 uvcvideo, Live 0x0000000000000000
dcdbas 16384 1 dell_laptop, Live 0x0000000000000000
videobuf2_core 36864 2 uvcvideo,videobuf2_v4l2, Live 0x0000000000000000
dell_smm_hwmon 16384 0 - Live 0x0000000000000000
btusb 45056 0 - Live 0x0000000000000000
v4l2_common 16384 1 videobuf2_v4l2, Live 0x0000000000000000
arc4 16384 2 - Live 0x0000000000000000
btrtl 16384 1 btusb, Live 0x0000000000000000
intel_rapl 20480 0 - Live 0x0000000000000000
btbcm 16384 1 btusb, Live 0x0000000000000000
videodev 176128 4 uvcvideo,videobuf2_v4l2,videobuf2_core,v4l2_common, Live 0x0000000000000000
btintel 16384 1 btusb, Live 0x0000000000000000
x86_pkg_temp_thermal 16384 0 - Live 0x0000000000000000
intel_powerclamp 16384 0 - Live 0x0000000000000000
media 24576 2 uvcvideo,videodev, Live 0x0000000000000000
bluetooth 520192 29 rfcomm,bnep,btusb,btrtl,btbcm,btintel, Live 0x0000000000000000
coretemp 16384 0 - Live 0x0000000000000000
crct10dif_pclmul 16384 0 - Live 0x0000000000000000
crc32_pclmul 16384 0 - Live 0x0000000000000000
aesni_intel 167936 6 - Live 0x0000000000000000
snd_hda_codec_hdmi 53248 1 - Live 0x0000000000000000
aes_x86_64 20480 1 aesni_intel, Live 0x0000000000000000
iwlmvm 311296 0 - Live 0x0000000000000000
lrw 16384 1 aesni_intel, Live 0x0000000000000000
snd_hda_codec_realtek 81920 1 - Live 0x0000000000000000
gf128mul 16384 1 lrw, Live 0x0000000000000000
glue_helper 16384 1 aesni_intel, Live 0x0000000000000000
mac80211 724992 1 iwlmvm, Live 0x0000000000000000
snd_hda_codec_generic 77824 1 snd_hda_codec_realtek, Live 0x0000000000000000
ablk_helper 16384 1 aesni_intel, Live 0x0000000000000000
cryptd 20480 2 aesni_intel,ablk_helper, Live 0x0000000000000000
snd_hda_intel 36864 5 - Live 0x0000000000000000
snd_hda_codec 135168 4 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel, Live 0x0000000000000000
snd_soc_ssm4567 16384 0 - Live 0x0000000000000000
joydev 20480 0 - Live 0x0000000000000000
snd_hda_core 65536 5 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec, Live 0x0000000000000000
input_leds 16384 0 - Live 0x0000000000000000
snd_soc_rt5640 114688 0 - Live 0x0000000000000000
iwlwifi 196608 1 iwlmvm, Live 0x0000000000000000
snd_hwdep 16384 2 snd_usb_audio,snd_hda_codec, Live 0x0000000000000000
serio_raw 16384 0 - Live 0x0000000000000000
snd_soc_rl6231 16384 1 snd_soc_rt5640, Live 0x0000000000000000
snd_soc_core 212992 2 snd_soc_ssm4567,snd_soc_rt5640, Live 0x0000000000000000
cfg80211 557056 3 iwlmvm,mac80211,iwlwifi, Live 0x0000000000000000
snd_compress 20480 1 snd_soc_core, Live 0x0000000000000000
ac97_bus 16384 1 snd_soc_core, Live 0x0000000000000000
snd_pcm_dmaengine 16384 1 snd_soc_core, Live 0x0000000000000000
snd_pcm 102400 8 snd_usb_audio,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core,snd_soc_rt5640,snd_soc_core,snd_pcm_dmaengine, Live 0x0000000000000000
lpc_ich 24576 0 - Live 0x0000000000000000
mei_me 32768 0 - Live 0x0000000000000000
mei 98304 1 mei_me, Live 0x0000000000000000
shpchp 36864 0 - Live 0x0000000000000000
snd_seq_midi 16384 0 - Live 0x0000000000000000
snd_seq_midi_event 16384 1 snd_seq_midi, Live 0x0000000000000000
snd_rawmidi 32768 2 snd_usbmidi_lib,snd_seq_midi, Live 0x0000000000000000
8250_fintek 16384 0 - Live 0x0000000000000000
snd_seq 69632 2 snd_seq_midi,snd_seq_midi_event, Live 0x0000000000000000
snd_seq_device 16384 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x0000000000000000
acpi_als 16384 0 - Live 0x0000000000000000
snd_timer 32768 2 snd_pcm,snd_seq, Live 0x0000000000000000
int3403_thermal 16384 0 - Live 0x0000000000000000
kfifo_buf 16384 1 acpi_als, Live 0x0000000000000000
industrialio 57344 2 acpi_als,kfifo_buf, Live 0x0000000000000000
dell_smo8800 16384 0 - Live 0x0000000000000000
dw_dmac 16384 0 - Live 0x0000000000000000
dw_dmac_core 24576 1 dw_dmac, Live 0x0000000000000000
snd_soc_sst_acpi 16384 0 - Live 0x0000000000000000
processor_thermal_device 16384 0 - Live 0x0000000000000000
elan_i2c 36864 0 - Live 0x0000000000000000
snd 81920 29 snd_usb_audio,snd_usbmidi_lib,snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_soc_core,snd_compress,snd_pcm,snd_rawmidi,snd_seq,snd_seq_device,snd_timer, Live 0x0000000000000000
dell_rbtn 16384 0 - Live 0x0000000000000000
kvm_intel 167936 0 - Live 0x0000000000000000
intel_soc_dts_iosf 16384 1 processor_thermal_device, Live 0x0000000000000000
acpi_pad 20480 0 - Live 0x0000000000000000
int3402_thermal 16384 0 - Live 0x0000000000000000
8250_dw 16384 0 - Live 0x0000000000000000
iosf_mbi 16384 2 intel_rapl,intel_soc_dts_iosf, Live 0x0000000000000000
int3400_thermal 16384 0 - Live 0x0000000000000000
kvm 532480 1 kvm_intel, Live 0x0000000000000000
soundcore 16384 1 snd, Live 0x0000000000000000
int340x_thermal_zone 16384 3 int3403_thermal,processor_thermal_device,int3402_thermal, Live 0x0000000000000000
mac_hid 16384 0 - Live 0x0000000000000000
spi_pxa2xx_platform 24576 0 - Live 0x0000000000000000
i2c_designware_platform 16384 0 - Live 0x0000000000000000
i2c_designware_core 20480 1 i2c_designware_platform, Live 0x0000000000000000
acpi_thermal_rel 16384 1 int3400_thermal, Live 0x0000000000000000
irqbypass 16384 1 kvm, Live 0x0000000000000000
parport_pc 32768 0 - Live 0x0000000000000000
ppdev 20480 0 - Live 0x0000000000000000
lp 20480 0 - Live 0x0000000000000000
parport 49152 3 parport_pc,ppdev,lp, Live 0x0000000000000000
autofs4 40960 2 - Live 0x0000000000000000
hid_generic 16384 0 - Live 0x0000000000000000
usbhid 49152 0 - Live 0x0000000000000000
uas 24576 0 - Live 0x0000000000000000
usb_storage 69632 1 uas, Live 0x0000000000000000
i915 1204224 8 - Live 0x0000000000000000
psmouse 126976 0 - Live 0x0000000000000000
ahci 36864 3 - Live 0x0000000000000000
i2c_algo_bit 16384 1 i915, Live 0x0000000000000000
libahci 32768 1 ahci, Live 0x0000000000000000
drm_kms_helper 135168 1 i915, Live 0x0000000000000000
syscopyarea 16384 1 drm_kms_helper, Live 0x0000000000000000
sysfillrect 16384 1 drm_kms_helper, Live 0x0000000000000000
sysimgblt 16384 1 drm_kms_helper, Live 0x0000000000000000
sdhci_pci 28672 0 - Live 0x0000000000000000
fb_sys_fops 16384 1 drm_kms_helper, Live 0x0000000000000000
e1000e 237568 0 - Live 0x0000000000000000
drm 360448 9 i915,drm_kms_helper, Live 0x0000000000000000
ptp 20480 1 e1000e, Live 0x0000000000000000
pps_core 20480 1 ptp, Live 0x0000000000000000
wmi 20480 1 dell_wmi, Live 0x0000000000000000
video 40960 3 dell_wmi,dell_laptop,i915, Live 0x0000000000000000
sdhci_acpi 16384 0 - Live 0x0000000000000000
sdhci 45056 2 sdhci_pci,sdhci_acpi, Live 0x0000000000000000
fjes 28672 0 - Live 0x0000000000000000
i2c_hid 20480 0 - Live 0x0000000000000000
hid 118784 3 hid_generic,usbhid,i2c_hid, Live 0x0000000000000000
$ cat /proc/ioports
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0077 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0680-069f : pnp 00:00
0930-0930 : PNP0C09:00
0930-0930 : EC data
0934-0934 : PNP0C09:00
0934-0934 : EC cmd
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
164e-164f : pnp 00:00
1800-1803 : ACPI PM1a_EVT_BLK
1804-1805 : ACPI PM1a_CNT_BLK
1808-180b : ACPI PM_TMR
1810-1815 : ACPI CPU throttle
1830-1833 : iTCO_wdt.0.auto
1850-1850 : ACPI PM2_CNT_BLK
1854-1857 : pnp 00:02
1860-187f : iTCO_wdt.0.auto
1880-189f : ACPI GPE0_BLK
f000-f03f : 0000:00:02.0
f040-f05f : 0000:00:1f.3
f060-f07f : 0000:00:1f.2
f060-f07f : ahci
f080-f09f : 0000:00:19.0
f0a0-f0a3 : 0000:00:1f.2
f0a0-f0a3 : ahci
f0b0-f0b7 : 0000:00:1f.2
f0b0-f0b7 : ahci
f0c0-f0c3 : 0000:00:1f.2
f0c0-f0c3 : ahci
f0d0-f0d7 : 0000:00:1f.2
f0d0-f0d7 : ahci
ffff-ffff : pnp 00:00
ffff-ffff : pnp 00:00
ffff-ffff : pnp 00:00
$ cat /proc/iomem
00000000-00000fff : reserved
00001000-00057fff : System RAM
00058000-00058fff : reserved
00059000-0009efff : System RAM
0009f000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000cfdff : Video ROM
000d0000-000d99ff : Adapter ROM
000da000-000dafff : Adapter ROM
000f0000-000fffff : System ROM
00100000-bc063fff : System RAM
02000000-0280103f : Kernel code
02801040-02f3ba3f : Kernel data
030b2000-031f4fff : Kernel bss
bc064000-bc4eafff : reserved
bc4eb000-da606fff : System RAM
da607000-da740fff : reserved
da741000-da76ffff : ACPI Tables
da770000-daee4fff : System RAM
daee5000-db642fff : ACPI Non-volatile Storage
db643000-dba62fff : reserved
dba63000-dbafefff : reserved
dbaff000-dbafffff : System RAM
dbb00000-dbffffff : RAM buffer
dd000000-df7fffff : reserved
dd800000-df7fffff : Graphics Stolen Memory
df800000-feafffff : PCI Bus 0000:00
e0000000-efffffff : 0000:00:02.0
f6000000-f6ffffff : 0000:00:02.0
f7000000-f70fffff : PCI Bus 0000:02
f7000000-f7001fff : 0000:02:00.0
f7000000-f7001fff : iwlwifi
f7100000-f71fffff : PCI Bus 0000:01
f7100000-f71007ff : 0000:01:00.0
f7101000-f7101fff : 0000:01:00.0
f7101000-f7101fff : mmc0
f7200000-f721ffff : 0000:00:19.0
f7200000-f721ffff : e1000e
f7220000-f722ffff : 0000:00:14.0
f7220000-f722ffff : xhci-hcd
f7230000-f7237fff : 0000:00:04.0
f7238000-f723bfff : 0000:00:1b.0
f7238000-f723bfff : ICH HD audio
f723c000-f723ffff : 0000:00:03.0
f723c000-f723ffff : ICH HD audio
f7240000-f72400ff : 0000:00:1f.3
f7241000-f72417ff : 0000:00:1f.2
f7241000-f72417ff : ahci
f7242000-f72423ff : 0000:00:1d.0
f7242000-f72423ff : ehci_hcd
f7243000-f7243fff : 0000:00:19.0
f7243000-f7243fff : e1000e
f7246000-f724601f : 0000:00:16.0
f7246000-f724601f : mei_me
f7fe0000-f7feffff : pnp 00:06
f7ff0000-f7ffffff : pnp 00:06
f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f]
f8000000-fbffffff : reserved
f8000000-fbffffff : pnp 00:06
fec00000-fec00fff : reserved
fec00000-fec003ff : IOAPIC 0
fed00000-fed03fff : reserved
fed00000-fed003ff : HPET 0
fed00000-fed003ff : PNP0103:00
fed10000-fed17fff : pnp 00:06
fed18000-fed18fff : pnp 00:06
fed19000-fed19fff : pnp 00:06
fed1c000-fed1ffff : reserved
fed1c000-fed1ffff : pnp 00:06
fed1f410-fed1f414 : iTCO_wdt.0.auto
fed20000-fed3ffff : pnp 00:06
fed45000-fed8ffff : pnp 00:06
fed90000-fed90fff : dmar0
fed91000-fed91fff : dmar1
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
ff000000-ffffffff : reserved
ff000000-ffffffff : INT0800:00
ff000000-ffffffff : pnp 00:06
100000000-21e7fffff : System RAM
21e800000-21fffffff : RAM buffer
$ sudo lspci -vvv
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
Subsystem: Dell Device 062e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: bdw_uncore
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) (prog-if 00 [VGA controller])
DeviceName: Onboard IGD
Subsystem: Dell Device 062e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 48
Region 0: Memory at f6000000 (64-bit, non-prefetchable) [size=16M]
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00018 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
Subsystem: Dell Device 062e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 52
Region 0: Memory at f723c000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00338 Data: 0000
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
Kernel driver in use: snd_hda_intel
00:04.0 Signal processing controller: Intel Corporation Broadwell-U Camarillo Device (rev 09)
Subsystem: Dell Device 062e
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f7230000 (64-bit, non-prefetchable) [size=32K]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: proc_thermal
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) (prog-if 30 [XHCI])
Subsystem: Dell Device 062e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 45
Region 0: Memory at f7220000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Address: 00000000fee00298 Data: 0000
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
Subsystem: Dell Device 062e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 49
Region 0: Memory at f7246000 (64-bit, non-prefetchable) [size=32]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee002f8 Data: 0000
Kernel driver in use: mei_me
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-LM (rev 03)
DeviceName: Onboard LAN
Subsystem: Dell Device 062e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 46
Region 0: Memory at f7200000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f7243000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at f080 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee002d8 Data: 0000
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
Subsystem: Dell Device 062e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 51
Region 0: Memory at f7238000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00378 Data: 0000
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #1 (rev e3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 42
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f7100000-f71fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR+, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00238 Data: 0000
Capabilities: [90] Subsystem: Dell Device 062e
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v0] #00
Capabilities: [200 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=40us PortTPowerOnTime=10us
Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #4 (rev e3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin D routed to IRQ 43
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f7000000-f70fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR+, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00258 Data: 0000
Capabilities: [90] Subsystem: Dell Device 062e
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v0] #00
Capabilities: [200 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=40us PortTPowerOnTime=10us
Kernel driver in use: pcieport
00:1c.4 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #5 (rev e3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 44
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #5, Speed 5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #4, PowerLimit 25.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR+, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00278 Data: 0000
Capabilities: [90] Subsystem: Dell Device 062e
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v0] #00
Capabilities: [200 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=40us PortTPowerOnTime=10us
Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03) (prog-if 20 [EHCI])
Subsystem: Dell Device 062e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 21
Region 0: Memory at f7242000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
Subsystem: Dell Device 062e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 03)
Subsystem: Dell Device 062e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 47
Region 0: I/O ports at f0d0 [size=8]
Region 1: I/O ports at f0c0 [size=4]
Region 2: I/O ports at f0b0 [size=8]
Region 3: I/O ports at f0a0 [size=4]
Region 4: I/O ports at f060 [size=32]
Region 5: Memory at f7241000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00318 Data: 0000
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
Subsystem: Dell Device 062e
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 255
Region 0: Memory at f7240000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at f040 [size=32]
01:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 01) (prog-if 01)
Subsystem: Dell Device 062e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f7101000 (32-bit, non-prefetchable) [size=4K]
Region 1: Memory at f7100000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [6c] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [80] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [230 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Capabilities: [240 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=120us PortTPowerOnTime=10us
Kernel driver in use: sdhci-pci
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
Subsystem: Intel Corporation Dual Band Wireless-AC 7265
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 50
Region 0: Memory at f7000000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00358 Data: 0000
Capabilities: [40] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L1, Exit Latency L0s <4us, L1 <32us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR+, OBFF Via WAKE#
DevCtl2: Completion Timeout: 16ms to 55ms, TimeoutDis-, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 94-65-9c-ff-ff-5a-48-44
Capabilities: [14c v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Capabilities: [154 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=30us PortTPowerOnTime=60us
Kernel driver in use: iwlwifi
$ cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: SAMSUNG SSD PM87 Rev: 2D0Q
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: Generic Model: USB SD Reader Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 00
Host: scsi2 Channel: 00 Id: 00 Lun: 01
Vendor: Generic Model: USB CF Reader Rev: 1.01
Type: Direct-Access ANSI SCSI revision: 00
Host: scsi2 Channel: 00 Id: 00 Lun: 02
Vendor: Generic Model: USB xD/SM Reader Rev: 1.02
Type: Direct-Access ANSI SCSI revision: 00
Host: scsi2 Channel: 00 Id: 00 Lun: 03
Vendor: Generic Model: USB MS Reader Rev: 1.03
Type: Direct-Access ANSI SCSI revision: 00
$ ls /proc
1 1063 1124 1300 1389 150 1549 167 196 2024 21 2529 2696 282 3099 33 3485 4 45 4731 64 73 83 9 986 devices ioports locks schedstat timer_list
10 1064 1180 1319 1397 151 1566 1675 1964 2026 2103 2531 27 29 31 3303 3499 408 450 474 65 74 84 902 987 diskstats irq mdstat scsi timer_stats
1011 1065 1185 1321 1400 152 158 1676 197 2031 2168 2542 2702 3 3104 331 35 41 4525 4784 66 75 840 903 acpi dma kallsyms meminfo self tty
1012 1066 1186 1332 1403 1520 1587 168 1973 2033 2178 2543 2703 30 3122 3342 3564 411 46 4795 67 76 85 92 asound driver kcore misc slabinfo uptime
1013 1067 1190 1356 1405 1522 159 169 1983 2035 22 2568 2713 3006 3139 3357 3566 413 4609 5 68 77 86 923 buddyinfo execdomains keys modules softirqs version
1015 1068 12 1359 1416 1523 16 17 1985 2043 2227 2571 2723 3042 3143 3381 359 416 4620 527 69 78 860 933 bus fb key-users mounts stat vmallocinfo
1020 107 1266 1374 1417 1525 160 171 199 2058 23 2572 274 3050 3183 34 36 417 4621 528 7 79 861 943 cgroups filesystems kmsg mtrr swaps vmstat
1058 1094 1276 1376 1426 153 161 18 2 2067 2374 26 2766 3051 32 340 37 420 4657 584 70 8 884 954 cmdline fs kpagecgroup net sys zoneinfo
1059 11 1288 1380 1439 1531 1631 1930 20 2076 24 2636 2772 3055 3200 3409 38 4293 4669 61 71 80 887 958 consoles i8k kpagecount pagetypeinfo sysrq-trigger
106 1108 1299 1381 1453 1533 1651 1956 200 2087 243 2652 2779 3057 3201 3429 39 44 4672 62 712 81 889 959 cpuinfo interrupts kpageflags partitions sysvipc
1061 1110 13 1386 15 1546 1660 1957 2001 2094 25 2653 28 3060 3242 3442 392 4462 4728 63 72 82 897 985 crypto iomem loadavg sched_debug thread-self
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-12 14:04 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work Alex Ballas
@ 2015-12-16 3:42 ` Peter Guo
2015-12-16 9:48 ` Alex Ballas
0 siblings, 1 reply; 15+ messages in thread
From: Peter Guo @ 2015-12-16 3:42 UTC (permalink / raw)
To: Alex Ballas, adam.lee, ulf.hansson; +Cc: linux-mmc
Hi Alex,
Thanks for your Test, According to your info.
I find the root cause of this issue is quirks SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD is not suitable for our host for
all cases. Our host just want to clear SDHCI_TRANS_DMA bit only.
to Adam,
I will commit new patch this week, please check it.
BR
Peter.Guo
-----Original Message-----
From: Alex Ballas [mailto:alex@ballas.org]
Sent: Saturday, December 12, 2015 10:04 PM
To: Peter Guo; adam.lee@canonical.com; ulf.hansson@linaro.org
Cc: linux-mmc@VGER.KERNEL.ORG
Subject: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
Hello,
I have a Dell Latitude E7450 with a O2 Micro, SD/MMC Card Reader [1217:8520] card reader. When I insert my Sandisk ultra 64GB microSD (with a SD card adapter) I get the following errors.
Dmesg output after I insert the SD card:
[ 306.054203] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 306.055982] mmc0: tuning execution failed [ 306.055987] mmc0: error -5 whilst initialising SD card [ 306.466185] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 306.467964] mmc0: tuning execution failed [ 306.467970] mmc0: error -5 whilst initialising SD card [ 306.890205] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 306.891993] mmc0: tuning execution failed [ 306.892005] mmc0: error -5 whilst initialising SD card [ 307.330197] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 307.331980] mmc0: tuning execution failed [ 307.331990] mmc0: error -5 whilst initialising SD card
I used the latest mainline kernel available to me [1] $ uname -a Linux cosmo 4.4.0-040400rc4-generic #201512061930 SMP Mon Dec 7
00:32:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
It was working fine for kernel versions older than 4.1.8.
I did a bisection and here is the first bad commit
> e6c69099f63c84e1825c0f742a76ff4a8afeaa9b is the first bad commit
> commit e6c69099f63c84e1825c0f742a76ff4a8afeaa9b
> Author: Adam Lee <adam.lee@canonical.com>
> Date: Mon Aug 3 14:33:28 2015 +0800
>
> mmc: sdhci-pci: set the clear transfer mode register quirk for
> O2Micro
>
> commit 143b648ddf1583905fa15d32be27a31442fc7933 upstream.
>
> This patch fixes MMC not working issue on O2Micro/BayHub Host, which
> requires transfer mode register to be cleared when sending no DMA
> command.
>
> Signed-off-by: Peter Guo <peter.guo@bayhubtech.com>
> Signed-off-by: Adam Lee <adam.lee@canonical.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I originally logged this issue to the Ubuntu bug tracker[2], but it appears to be an upstream issue and so I was instructed to report here.
Please note that I use the latest Bios version for the model.
$ sudo dmidecode -s bios-version;sudo dmidecode -s bios-release-date
A08
10/28/2015
[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc4-wily/
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523178
Thanks,
Alex
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-16 3:42 ` Peter Guo
@ 2015-12-16 9:48 ` Alex Ballas
2015-12-18 3:14 ` Peter Guo
0 siblings, 1 reply; 15+ messages in thread
From: Alex Ballas @ 2015-12-16 9:48 UTC (permalink / raw)
To: Peter Guo, adam8157; +Cc: ulf.hansson, linux-mmc@VGER.KERNEL.ORG
Re-adding Adam as the initial mail address is bouncing.
Kind Regards,
Alex
On Wed, Dec 16, 2015 at 5:42 AM, Peter Guo <peter.guo@bayhubtech.com> wrote:
> Hi Alex,
>
> Thanks for your Test, According to your info.
> I find the root cause of this issue is quirks SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD is not suitable for our host for
> all cases. Our host just want to clear SDHCI_TRANS_DMA bit only.
>
> to Adam,
>
> I will commit new patch this week, please check it.
>
>
> BR
> Peter.Guo
>
> -----Original Message-----
> From: Alex Ballas [mailto:alex@ballas.org]
> Sent: Saturday, December 12, 2015 10:04 PM
> To: Peter Guo; adam.lee@canonical.com; ulf.hansson@linaro.org
> Cc: linux-mmc@VGER.KERNEL.ORG
> Subject: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
>
> Hello,
>
> I have a Dell Latitude E7450 with a O2 Micro, SD/MMC Card Reader [1217:8520] card reader. When I insert my Sandisk ultra 64GB microSD (with a SD card adapter) I get the following errors.
>
> Dmesg output after I insert the SD card:
>
> [ 306.054203] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 306.055982] mmc0: tuning execution failed [ 306.055987] mmc0: error -5 whilst initialising SD card [ 306.466185] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 306.467964] mmc0: tuning execution failed [ 306.467970] mmc0: error -5 whilst initialising SD card [ 306.890205] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 306.891993] mmc0: tuning execution failed [ 306.892005] mmc0: error -5 whilst initialising SD card [ 307.330197] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure
, falling back to fixed sampling clock [ 307.331980] mmc0: tuning execution failed [ 307.331990] mmc0: error -5 whilst initialising SD card
>
> I used the latest mainline kernel available to me [1] $ uname -a Linux cosmo 4.4.0-040400rc4-generic #201512061930 SMP Mon Dec 7
> 00:32:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> It was working fine for kernel versions older than 4.1.8.
>
> I did a bisection and here is the first bad commit
>
>> e6c69099f63c84e1825c0f742a76ff4a8afeaa9b is the first bad commit
>> commit e6c69099f63c84e1825c0f742a76ff4a8afeaa9b
>> Author: Adam Lee <adam.lee@canonical.com>
>> Date: Mon Aug 3 14:33:28 2015 +0800
>>
>> mmc: sdhci-pci: set the clear transfer mode register quirk for
>> O2Micro
>>
>> commit 143b648ddf1583905fa15d32be27a31442fc7933 upstream.
>>
>> This patch fixes MMC not working issue on O2Micro/BayHub Host, which
>> requires transfer mode register to be cleared when sending no DMA
>> command.
>>
>> Signed-off-by: Peter Guo <peter.guo@bayhubtech.com>
>> Signed-off-by: Adam Lee <adam.lee@canonical.com>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> I originally logged this issue to the Ubuntu bug tracker[2], but it appears to be an upstream issue and so I was instructed to report here.
> Please note that I use the latest Bios version for the model.
>
> $ sudo dmidecode -s bios-version;sudo dmidecode -s bios-release-date
> A08
> 10/28/2015
>
> [1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc4-wily/
> [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523178
>
> Thanks,
> Alex
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-16 9:48 ` Alex Ballas
@ 2015-12-18 3:14 ` Peter Guo
2015-12-18 8:51 ` Ulf Hansson
0 siblings, 1 reply; 15+ messages in thread
From: Peter Guo @ 2015-12-18 3:14 UTC (permalink / raw)
To: Alex Ballas, adam8157; +Cc: ulf.hansson, linux-mmc@VGER.KERNEL.ORG
[-- Attachment #1: Type: text/plain, Size: 4071 bytes --]
Hi Alex & Adam,
I have send the patch. Please check it.
Attachment is the patch file.
BR
Peter.Guo
-----Original Message-----
From: Alex Ballas [mailto:alex@ballas.org]
Sent: Wednesday, December 16, 2015 5:49 PM
To: Peter Guo; adam8157@gmail.com
Cc: ulf.hansson@linaro.org; linux-mmc@VGER.KERNEL.ORG
Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
Re-adding Adam as the initial mail address is bouncing.
Kind Regards,
Alex
On Wed, Dec 16, 2015 at 5:42 AM, Peter Guo <peter.guo@bayhubtech.com> wrote:
> Hi Alex,
>
> Thanks for your Test, According to your info.
> I find the root cause of this issue is quirks
> SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD is not suitable for our host for all cases. Our host just want to clear SDHCI_TRANS_DMA bit only.
>
> to Adam,
>
> I will commit new patch this week, please check it.
>
>
> BR
> Peter.Guo
>
> -----Original Message-----
> From: Alex Ballas [mailto:alex@ballas.org]
> Sent: Saturday, December 12, 2015 10:04 PM
> To: Peter Guo; adam.lee@canonical.com; ulf.hansson@linaro.org
> Cc: linux-mmc@VGER.KERNEL.ORG
> Subject: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader
> doesn't work
>
> Hello,
>
> I have a Dell Latitude E7450 with a O2 Micro, SD/MMC Card Reader [1217:8520] card reader. When I insert my Sandisk ultra 64GB microSD (with a SD card adapter) I get the following errors.
>
> Dmesg output after I insert the SD card:
>
> [ 306.054203] sdhci: Timeout waiting for Buffer Read Ready interrupt
> during tuning procedure, falling back to fixed sampling clock [
> 306.055982] mmc0: tuning execution failed [ 306.055987] mmc0: error
> -5 whilst initialising SD card [ 306.466185] sdhci: Timeout waiting
> for Buffer Read Ready interrupt during tuning procedure, falling back
> to fixed sampling clock [ 306.467964] mmc0: tuning execution failed [
> 306.467970] mmc0: error -5 whilst initialising SD card [ 306.890205]
> sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning
> procedure, falling back to fixed sampling clock [ 306.891993] mmc0:
> tuning execution failed [ 306.892005] mmc0: error -5 whilst
> initialising SD card [ 307.330197] sdhci: Timeout waiting for Buffer
> Read Ready interrupt during tuning procedure, falling back to fixed
> sampling clock [ 307.331980] mmc0: tuning execution failed [
> 307.331990] mmc0: error -5 whilst initialising SD card
>
> I used the latest mainline kernel available to me [1] $ uname -a Linux
> cosmo 4.4.0-040400rc4-generic #201512061930 SMP Mon Dec 7
> 00:32:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> It was working fine for kernel versions older than 4.1.8.
>
> I did a bisection and here is the first bad commit
>
>> e6c69099f63c84e1825c0f742a76ff4a8afeaa9b is the first bad commit
>> commit e6c69099f63c84e1825c0f742a76ff4a8afeaa9b
>> Author: Adam Lee <adam.lee@canonical.com>
>> Date: Mon Aug 3 14:33:28 2015 +0800
>>
>> mmc: sdhci-pci: set the clear transfer mode register quirk for
>> O2Micro
>>
>> commit 143b648ddf1583905fa15d32be27a31442fc7933 upstream.
>>
>> This patch fixes MMC not working issue on O2Micro/BayHub Host, which
>> requires transfer mode register to be cleared when sending no DMA
>> command.
>>
>> Signed-off-by: Peter Guo <peter.guo@bayhubtech.com>
>> Signed-off-by: Adam Lee <adam.lee@canonical.com>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> I originally logged this issue to the Ubuntu bug tracker[2], but it appears to be an upstream issue and so I was instructed to report here.
> Please note that I use the latest Bios version for the model.
>
> $ sudo dmidecode -s bios-version;sudo dmidecode -s bios-release-date
> A08
> 10/28/2015
>
> [1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc4-wily/
> [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523178
>
> Thanks,
> Alex
[-- Attachment #2: 0001-mmc-sdhci-Add-QUIRK2_CLEAR_TRANSFERMODE_DMA_BEFORE_CMD.patch --]
[-- Type: application/octet-stream, Size: 2534 bytes --]
From b3862562928dfbc1fa971d2d092a6f0580294d4b Mon Sep 17 00:00:00 2001
From: "peter.guo" <peter.guo@bayhubtech.com>
Date: Fri, 18 Dec 2015 10:44:16 +0800
Subject: [PATCH 1/1] mmc: sdhci: Add QUIRK2_CLEAR_TRANSFERMODE_DMA_BEFORE_CMD for o2Micro chip
Add SDHCI_QUIRK2_CLEAR_TRANSFERMODE_DMA_BEFORE_CMD quirks2 for requires transfer
mode register SDHCI_TRNS_DMA bit to be cleared when sending no DMA.
Apply this quirks for O2Micro chip instead of SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD:
a. MMC card not working issue
b. SD tuning failed issue.
Signed-off-by: Peter Guo <peter.guo@bayhubtech.com>
---
drivers/mmc/host/sdhci-pci-core.c | 2 +-
drivers/mmc/host/sdhci.c | 4 ++++
drivers/mmc/host/sdhci.h | 3 +++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index cf7ad45..3a6f179 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -614,7 +614,7 @@ static int jmicron_resume(struct sdhci_pci_chip *chip)
static const struct sdhci_pci_fixes sdhci_o2 = {
.probe = sdhci_pci_o2_probe,
.quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
- .quirks2 = SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD,
+ .quirks2 = SDHCI_QUIRK2_CLEAR_TRANSFERMODE_DMA_BEFORE_CMD,
.probe_slot = sdhci_pci_o2_probe_slot,
.resume = sdhci_pci_o2_resume,
};
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index b48565e..fba9260 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -902,6 +902,10 @@ static void sdhci_set_transfer_mode(struct sdhci_host *host,
} else {
/* clear Auto CMD settings for no data CMDs */
mode = sdhci_readw(host, SDHCI_TRANSFER_MODE);
+ if (host->quirks2 &
+ SDHCI_QUIRK2_CLEAR_TRANSFERMODE_DMA_BEFORE_CMD) {
+ mode &= ~(SDHCI_TRNS_DMA);
+ }
sdhci_writew(host, mode & ~(SDHCI_TRNS_AUTO_CMD12 |
SDHCI_TRNS_AUTO_CMD23), SDHCI_TRANSFER_MODE);
}
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 9d4aa31..97fd107 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -417,6 +417,9 @@ struct sdhci_host {
* SD clock frequency or enabling back the internal clock.
*/
#define SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST (1<<16)
+/* need clear transfer mode register SDHCI_TRNS_DMA BIT before send cmd */
+#define SDHCI_QUIRK2_CLEAR_TRANSFERMODE_DMA_BEFORE_CMD (1<<17)
+
int irq; /* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.9.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-18 3:14 ` Peter Guo
@ 2015-12-18 8:51 ` Ulf Hansson
2015-12-18 9:39 ` Peter Guo
0 siblings, 1 reply; 15+ messages in thread
From: Ulf Hansson @ 2015-12-18 8:51 UTC (permalink / raw)
To: Peter Guo; +Cc: Alex Ballas, adam8157, linux-mmc@VGER.KERNEL.ORG
On 18 December 2015 at 04:14, Peter Guo <peter.guo@bayhubtech.com> wrote:
> Hi Alex & Adam,
>
> I have send the patch. Please check it.
> Attachment is the patch file.
Thanks Peter for helping out!
Although I would appreciate if you don't send patches as attachments.
Moreover, even if the patch can be used to check whether it solves the
problem - I won't accept it as is.
The reason is simply that I don't allow any more quirks/callbacks to
be added for SDHCI.
Kind regards
Uffe
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-18 8:51 ` Ulf Hansson
@ 2015-12-18 9:39 ` Peter Guo
2015-12-18 10:43 ` Alex Ballas
0 siblings, 1 reply; 15+ messages in thread
From: Peter Guo @ 2015-12-18 9:39 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Alex Ballas, adam8157, linux-mmc@VGER.KERNEL.ORG
Hi Ulf,
Thanks for your reply.
So currently the problem is SDHCI_TRANS_DMA bit need to be cleared before send Non DMA SD/MMC command for some of our host,
Could you please give me any suggestion on what kind of code modification you can accept?
BR
Peter.Guo
-----Original Message-----
From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
Sent: Friday, December 18, 2015 4:52 PMT
To: Peter Guo
Cc: Alex Ballas; adam8157@gmail.com; linux-mmc@VGER.KERNEL.ORG
Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
On 18 December 2015 at 04:14, Peter Guo <peter.guo@bayhubtech.com> wrote:
> Hi Alex & Adam,
>
> I have send the patch. Please check it.
> Attachment is the patch file.
Thanks Peter for helping out!
Although I would appreciate if you don't send patches as attachments.
Moreover, even if the patch can be used to check whether it solves the problem - I won't accept it as is.
The reason is simply that I don't allow any more quirks/callbacks to be added for SDHCI.
Kind regards
Uffe
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-18 9:39 ` Peter Guo
@ 2015-12-18 10:43 ` Alex Ballas
2015-12-18 22:55 ` Alex Ballas
0 siblings, 1 reply; 15+ messages in thread
From: Alex Ballas @ 2015-12-18 10:43 UTC (permalink / raw)
To: Peter Guo; +Cc: Ulf Hansson, adam8157, linux-mmc@VGER.KERNEL.ORG
Hello Uffe, Peter,
Thank you both. I'll try out Peter's patch to see if it's addressing
the issue and we can work through it based on Uffe's guidelines.
Kind Regards,
Alex
On Fri, Dec 18, 2015 at 11:39 AM, Peter Guo <peter.guo@bayhubtech.com> wrote:
> Hi Ulf,
>
> Thanks for your reply.
>
> So currently the problem is SDHCI_TRANS_DMA bit need to be cleared before send Non DMA SD/MMC command for some of our host,
> Could you please give me any suggestion on what kind of code modification you can accept?
>
>
> BR
> Peter.Guo
>
>
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> Sent: Friday, December 18, 2015 4:52 PMT
> To: Peter Guo
> Cc: Alex Ballas; adam8157@gmail.com; linux-mmc@VGER.KERNEL.ORG
> Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
>
> On 18 December 2015 at 04:14, Peter Guo <peter.guo@bayhubtech.com> wrote:
>> Hi Alex & Adam,
>>
>> I have send the patch. Please check it.
>> Attachment is the patch file.
>
> Thanks Peter for helping out!
>
> Although I would appreciate if you don't send patches as attachments.
>
> Moreover, even if the patch can be used to check whether it solves the problem - I won't accept it as is.
> The reason is simply that I don't allow any more quirks/callbacks to be added for SDHCI.
>
> Kind regards
> Uffe
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-18 10:43 ` Alex Ballas
@ 2015-12-18 22:55 ` Alex Ballas
2015-12-22 3:24 ` Peter Guo
0 siblings, 1 reply; 15+ messages in thread
From: Alex Ballas @ 2015-12-18 22:55 UTC (permalink / raw)
To: Peter Guo; +Cc: Ulf Hansson, adam8157, linux-mmc@VGER.KERNEL.ORG
Hello Peter & Uffe,
I tested the patch with the latest mainline kernel and it played nicely.
@Uffe how should we move forward with this?
Kind Regards,
Alex
On Fri, Dec 18, 2015 at 12:43 PM, Alex Ballas <alex@ballas.org> wrote:
> Hello Uffe, Peter,
>
> Thank you both. I'll try out Peter's patch to see if it's addressing
> the issue and we can work through it based on Uffe's guidelines.
>
> Kind Regards,
> Alex
>
> On Fri, Dec 18, 2015 at 11:39 AM, Peter Guo <peter.guo@bayhubtech.com> wrote:
>> Hi Ulf,
>>
>> Thanks for your reply.
>>
>> So currently the problem is SDHCI_TRANS_DMA bit need to be cleared before send Non DMA SD/MMC command for some of our host,
>> Could you please give me any suggestion on what kind of code modification you can accept?
>>
>>
>> BR
>> Peter.Guo
>>
>>
>> -----Original Message-----
>> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
>> Sent: Friday, December 18, 2015 4:52 PMT
>> To: Peter Guo
>> Cc: Alex Ballas; adam8157@gmail.com; linux-mmc@VGER.KERNEL.ORG
>> Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
>>
>> On 18 December 2015 at 04:14, Peter Guo <peter.guo@bayhubtech.com> wrote:
>>> Hi Alex & Adam,
>>>
>>> I have send the patch. Please check it.
>>> Attachment is the patch file.
>>
>> Thanks Peter for helping out!
>>
>> Although I would appreciate if you don't send patches as attachments.
>>
>> Moreover, even if the patch can be used to check whether it solves the problem - I won't accept it as is.
>> The reason is simply that I don't allow any more quirks/callbacks to be added for SDHCI.
>>
>> Kind regards
>> Uffe
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-18 22:55 ` Alex Ballas
@ 2015-12-22 3:24 ` Peter Guo
2015-12-22 8:30 ` Ulf Hansson
0 siblings, 1 reply; 15+ messages in thread
From: Peter Guo @ 2015-12-22 3:24 UTC (permalink / raw)
To: Alex Ballas; +Cc: Ulf Hansson, adam8157, linux-mmc@VGER.KERNEL.ORG
Hi Ulf & Alex,
Below is the complete analysis of this issue.
The basic flow of send command is as below:
(1) Upper layer prepare the command parameter;
(2) Call sdhci_send_command, and sdhci_send_command will call sdhci_set_transfer_mode to set Host Register 0xC;
(3) Call sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND) to send command;
For Linux kernel mainstream (without any quirk), MMC case:
(1) It will call mmc_get_ext_csd and this is an DMA transfer, then DMA enable bit will be set to 1 (0xC[0]=1'b1).
(2) Then next Command is mmc_switch(cmd6) which is none-data command, the driver will keep DMA enable bit to 1; this will let our Host failed to execute the CMD06.
According to SD Host Spec(SD Host Controller Specification verson 4.1 page 41):
Bit0 of Transfer Mode Register(0x0C) is DMA Enable bit, this bit set to 1 means a DMA operation shall begin when Host Driver writes to the upper byte of Command Register(0x0F).
The DMA enable bit should be set to zero for this none-data command(CMD6).
Our host follow the spec. so I think it should be the sdhci driver’s issue (sdhci_set_transfer_mode).
So We tried SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD to fix above issue.
But it encounter new problem as Alex reported for tuning command as tuning command flow in sdhci_execute_tuning function is:
(1). cmd.data = NULL;
(2). sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
(3). sdhci_send_command(host, &cmd);
As data is null, this quirk will set 0x0C[0:15] to ALL zero before send tuning command including SDHCI_TRNS_READ, and the tuning command will failed.
So, can we commit one patch as below to fix this DMA enable bit for non-data command bug if you cannot accept add new QUIRK?
Code should like below(sdhci_set_transfer_mode):
if (data == NULL) {
if (host->quirks2 &
SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD) {
sdhci_writew(host, 0x0, SDHCI_TRANSFER_MODE);
} else {
/* clear Auto CMD settings for no data CMDs */
mode = sdhci_readw(host, SDHCI_TRANSFER_MODE);
sdhci_writew(host, mode & ~(SDHCI_TRNS_AUTO_CMD12 | SDHCI_TRNS_DMA /*Clear DMA enable bit also for no data CMDs*/
SDHCI_TRNS_AUTO_CMD23), SDHCI_TRANSFER_MODE);
}
return;
}
BR
Peter.Guo
-----Original Message-----
From: Alex Ballas [mailto:alex@ballas.org]
Sent: Saturday, December 19, 2015 6:56 AM
To: Peter Guo
Cc: Ulf Hansson; adam8157@gmail.com; linux-mmc@VGER.KERNEL.ORG
Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
Hello Peter & Uffe,
I tested the patch with the latest mainline kernel and it played nicely.
@Uffe how should we move forward with this?
Kind Regards,
Alex
On Fri, Dec 18, 2015 at 12:43 PM, Alex Ballas <alex@ballas.org> wrote:
> Hello Uffe, Peter,
>
> Thank you both. I'll try out Peter's patch to see if it's addressing
> the issue and we can work through it based on Uffe's guidelines.
>
> Kind Regards,
> Alex
>
> On Fri, Dec 18, 2015 at 11:39 AM, Peter Guo <peter.guo@bayhubtech.com> wrote:
>> Hi Ulf,
>>
>> Thanks for your reply.
>>
>> So currently the problem is SDHCI_TRANS_DMA bit need to be cleared
>> before send Non DMA SD/MMC command for some of our host, Could you please give me any suggestion on what kind of code modification you can accept?
>>
>>
>> BR
>> Peter.Guo
>>
>>
>> -----Original Message-----
>> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
>> Sent: Friday, December 18, 2015 4:52 PMT
>> To: Peter Guo
>> Cc: Alex Ballas; adam8157@gmail.com; linux-mmc@VGER.KERNEL.ORG
>> Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card
>> Reader doesn't work
>>
>> On 18 December 2015 at 04:14, Peter Guo <peter.guo@bayhubtech.com> wrote:
>>> Hi Alex & Adam,
>>>
>>> I have send the patch. Please check it.
>>> Attachment is the patch file.
>>
>> Thanks Peter for helping out!
>>
>> Although I would appreciate if you don't send patches as attachments.
>>
>> Moreover, even if the patch can be used to check whether it solves the problem - I won't accept it as is.
>> The reason is simply that I don't allow any more quirks/callbacks to be added for SDHCI.
>>
>> Kind regards
>> Uffe
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-22 3:24 ` Peter Guo
@ 2015-12-22 8:30 ` Ulf Hansson
2015-12-23 6:39 ` Peter Guo
2015-12-23 11:13 ` Russell King - ARM Linux
0 siblings, 2 replies; 15+ messages in thread
From: Ulf Hansson @ 2015-12-22 8:30 UTC (permalink / raw)
To: Peter Guo
Cc: Alex Ballas, adam8157, linux-mmc@VGER.KERNEL.ORG, Adrian Hunter,
Russell King - ARM Linux
+ Adrian, Russell
On 22 December 2015 at 04:24, Peter Guo <peter.guo@bayhubtech.com> wrote:
> Hi Ulf & Alex,
>
> Below is the complete analysis of this issue.
>
> The basic flow of send command is as below:
> (1) Upper layer prepare the command parameter;
> (2) Call sdhci_send_command, and sdhci_send_command will call sdhci_set_transfer_mode to set Host Register 0xC;
> (3) Call sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND) to send command;
>
> For Linux kernel mainstream (without any quirk), MMC case:
> (1) It will call mmc_get_ext_csd and this is an DMA transfer, then DMA enable bit will be set to 1 (0xC[0]=1'b1).
> (2) Then next Command is mmc_switch(cmd6) which is none-data command, the driver will keep DMA enable bit to 1; this will let our Host failed to execute the CMD06.
>
> According to SD Host Spec(SD Host Controller Specification verson 4.1 page 41):
> Bit0 of Transfer Mode Register(0x0C) is DMA Enable bit, this bit set to 1 means a DMA operation shall begin when Host Driver writes to the upper byte of Command Register(0x0F).
>
> The DMA enable bit should be set to zero for this none-data command(CMD6).
> Our host follow the spec. so I think it should be the sdhci driver’s issue (sdhci_set_transfer_mode).
>
>
> So We tried SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD to fix above issue.
This quirk seems a bit strange. It looks like a generic problem being
solved by the wrong approach. Although, my knowledge of sdhci HW is
limited so I might be wrong.
Why doesn't sdhci *always* reset the related registers when the
command or data transfer gets *completed*? Instead as currently,
delaying that until the *next* request is started and via using
SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD?
>
> But it encounter new problem as Alex reported for tuning command as tuning command flow in sdhci_execute_tuning function is:
> (1). cmd.data = NULL;
> (2). sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
> (3). sdhci_send_command(host, &cmd);
> As data is null, this quirk will set 0x0C[0:15] to ALL zero before send tuning command including SDHCI_TRNS_READ, and the tuning command will failed.
I see.
Sdhci's sdhci_execute_tuning() function must be converted to use
mmc_send_tuning().
This means the regular request path will be maintained and thus no
special treatment should be needed.
Nevertheless, if my suggestions around changing sdhci's default
behaviour instead of using
SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD, perhaps you don't need
to fix sdhci_execute_tuning() to solve the error here!?
>
> So, can we commit one patch as below to fix this DMA enable bit for non-data command bug if you cannot accept add new QUIRK?
Nope, no new quirks.
> Code should like below(sdhci_set_transfer_mode):
> if (data == NULL) {
> if (host->quirks2 &
> SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD) {
> sdhci_writew(host, 0x0, SDHCI_TRANSFER_MODE);
> } else {
> /* clear Auto CMD settings for no data CMDs */
> mode = sdhci_readw(host, SDHCI_TRANSFER_MODE);
> sdhci_writew(host, mode & ~(SDHCI_TRNS_AUTO_CMD12 | SDHCI_TRNS_DMA /*Clear DMA enable bit also for no data CMDs*/
> SDHCI_TRNS_AUTO_CMD23), SDHCI_TRANSFER_MODE);
> }
> return;
> }
Thanks for the suggested solution, although I think this looks like
yet another hacky workaround for a generic problem.
Before I further consider that change, can you please look into my
suggestions above and see if any of those can simplify the solution?
[...]
Kind regards
Uffe
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-22 8:30 ` Ulf Hansson
@ 2015-12-23 6:39 ` Peter Guo
2015-12-23 14:24 ` Wan ZongShun
2015-12-23 11:13 ` Russell King - ARM Linux
1 sibling, 1 reply; 15+ messages in thread
From: Peter Guo @ 2015-12-23 6:39 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alex Ballas, adam8157, linux-mmc@VGER.KERNEL.ORG, Adrian Hunter,
Russell King - ARM Linux
Hi Ulf,
Thanks for your suggestion, Please check my comment.
BR
Peter.guo
-----Original Message-----
From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
Sent: Tuesday, December 22, 2015 4:30 PM
To: Peter Guo
Cc: Alex Ballas; adam8157@gmail.com; linux-mmc@VGER.KERNEL.ORG; Adrian Hunter; Russell King - ARM Linux
Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
+ Adrian, Russell
On 22 December 2015 at 04:24, Peter Guo <peter.guo@bayhubtech.com> wrote:
>> Hi Ulf & Alex,
>>
>> Below is the complete analysis of this issue.
>>
>> The basic flow of send command is as below:
>> (1) Upper layer prepare the command parameter;
>> (2) Call sdhci_send_command, and sdhci_send_command will call
>> sdhci_set_transfer_mode to set Host Register 0xC;
>> (3) Call sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags),
>> SDHCI_COMMAND) to send command;
>>
>> For Linux kernel mainstream (without any quirk), MMC case:
>> (1) It will call mmc_get_ext_csd and this is an DMA transfer, then DMA enable bit will be set to 1 (0xC[0]=1'b1).
>> (2) Then next Command is mmc_switch(cmd6) which is none-data command, the driver will keep DMA enable bit to 1; this will let our Host failed to execute the CMD06.
>>
>> According to SD Host Spec(SD Host Controller Specification verson 4.1 page 41):
>> Bit0 of Transfer Mode Register(0x0C) is DMA Enable bit, this bit set to 1 means a DMA operation shall begin when Host Driver writes to the upper byte of Command Register(0x0F).
>>
>> The DMA enable bit should be set to zero for this none-data command(CMD6).
> Our host follow the spec. so I think it should be the sdhci driver’s issue (sdhci_set_transfer_mode).
>>
>>
>> So We tried SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD to fix above issue.
>This quirk seems a bit strange. It looks like a generic problem being solved by the wrong approach. Although, my knowledge of sdhci HW is limited so I might be wrong.
>Why doesn't sdhci *always* reset the related registers when the command or data transfer gets *completed*? Instead as currently, delaying that until the *next* request is started and via using SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD?
Yes, this is one solution. We can clear TRANSMER_MODE register(0xC) after SD cmd done to solve current issue, below is the change method:
static void sdhci_tasklet_finish(unsigned long param) {
.....
host->mrq = NULL;
host->cmd = NULL;
host->data = NULL;
sdhci_writew(host, 0x0, SDHCI_TRANSFER_MODE);//Add Clear Transfer Mode here
.....
}
But the Disadvantage of this method is: Driver need do additional one register write operation after each command. Please check whether you can accept this change or not. Also it is looks weird to touch setting registers here.
>>
>> But it encounter new problem as Alex reported for tuning command as tuning command flow in sdhci_execute_tuning function is:
>> (1). cmd.data = NULL;
>> (2). sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE); (3).
>> sdhci_send_command(host, &cmd); As data is null, this quirk will set
>> 0x0C[0:15] to ALL zero before send tuning command including SDHCI_TRNS_READ, and the tuning command will failed.
>I see.
>Sdhci's sdhci_execute_tuning() function must be converted to use mmc_send_tuning().
>This means the regular request path will be maintained and thus no special treatment should be needed.
>Nevertheless, if my suggestions around changing sdhci's default behaviour instead of using SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD, >perhaps you don't need to fix sdhci_execute_tuning() to solve the error here!?
I have checked the mmc_send_tuning flow, and it can't replace sdhci_execute_tuning because the tuning command for sdhci.c is special command compare with normal command for 2 points:
(1) It don't generate Command Complete Interrupt(register 0x30 bit0)
(2) It has no data for host driver to read but SDHCI_TRNS_READ flag need to be set.
>>
>> So, can we commit one patch as below to fix this DMA enable bit for non-data command bug if you cannot accept add new QUIRK?
>Nope, no new quirks.
>> Code should like below(sdhci_set_transfer_mode):
>> if (data == NULL) {
>> if (host->quirks2 &
>> SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD) {
>> sdhci_writew(host, 0x0, SDHCI_TRANSFER_MODE);
>> } else {
>> /* clear Auto CMD settings for no data CMDs */
>> mode = sdhci_readw(host, SDHCI_TRANSFER_MODE);
>> sdhci_writew(host, mode & ~(SDHCI_TRNS_AUTO_CMD12 | SDHCI_TRNS_DMA /*Clear DMA enable bit also for no data CMDs*/
>> SDHCI_TRNS_AUTO_CMD23), SDHCI_TRANSFER_MODE);
>> }
>> return;
>> }
>Thanks for the suggested solution, although I think this looks like yet another hacky workaround for a generic problem.
>Before I further consider that change, can you please look into my suggestions above and see if any of those can simplify the solution?
>[...]
So my suggestion is:
(1) mmc_send_tuning can't replace sdhci_execute_tuning as tuning command is special one;
(2) modify the sdhci_set_transfer_mode to clear SDHCI_TRNS_DMA without quirk is better than clear transfer mode after command done. From my point of view, SDHCI_TRNS_DMA should be cleared for no-data command before issue command. It follows the spec.
BR
Peter.Guo
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-22 8:30 ` Ulf Hansson
2015-12-23 6:39 ` Peter Guo
@ 2015-12-23 11:13 ` Russell King - ARM Linux
2015-12-28 11:47 ` Ulf Hansson
1 sibling, 1 reply; 15+ messages in thread
From: Russell King - ARM Linux @ 2015-12-23 11:13 UTC (permalink / raw)
To: Ulf Hansson
Cc: Peter Guo, Alex Ballas, adam8157, linux-mmc@VGER.KERNEL.ORG,
Adrian Hunter
On Tue, Dec 22, 2015 at 09:30:00AM +0100, Ulf Hansson wrote:
> This quirk seems a bit strange. It looks like a generic problem being
> solved by the wrong approach. Although, my knowledge of sdhci HW is
> limited so I might be wrong.
>
> Why doesn't sdhci *always* reset the related registers when the
> command or data transfer gets *completed*? Instead as currently,
> delaying that until the *next* request is started and via using
> SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD?
That would be additional overhead. The real problem is that the tuning
paths compete with the normal request paths over how to set the registers.
This competition needs to be killed, and a saner structure for dealing
with requests and tuning commands needs to be created.
This is something I'm working on as I get time: I'm restructuring
sdhci_send_command() with the aim of getting to the point where the
tuning code is _not_ writing to any registers at all, and that's all
handled by code common to both paths.
> Sdhci's sdhci_execute_tuning() function must be converted to use
> mmc_send_tuning().
That will make the request path more complex, because we then need to
detect the tuning commands and have special handling for them. With
SDHCI, they are not a standard data transfer command, which is what
mmc_send_tuning() wants.
This means we end up with more complexity in what is supposed to be a
fast path, which means more room for bugs to creep in.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-23 6:39 ` Peter Guo
@ 2015-12-23 14:24 ` Wan ZongShun
0 siblings, 0 replies; 15+ messages in thread
From: Wan ZongShun @ 2015-12-23 14:24 UTC (permalink / raw)
To: Peter Guo
Cc: Ulf Hansson, Alex Ballas, adam8157, linux-mmc@VGER.KERNEL.ORG,
Adrian Hunter, Russell King - ARM Linux
2015-12-23 14:39 GMT+08:00 Peter Guo <peter.guo@bayhubtech.com>:
> Hi Ulf,
>
> Thanks for your suggestion, Please check my comment.
>
> BR
> Peter.guo
>
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> Sent: Tuesday, December 22, 2015 4:30 PM
> To: Peter Guo
> Cc: Alex Ballas; adam8157@gmail.com; linux-mmc@VGER.KERNEL.ORG; Adrian Hunter; Russell King - ARM Linux
> Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
>
> + Adrian, Russell
>
> On 22 December 2015 at 04:24, Peter Guo <peter.guo@bayhubtech.com> wrote:
>>> Hi Ulf & Alex,
>>>
>>> Below is the complete analysis of this issue.
>>>
>>> The basic flow of send command is as below:
>>> (1) Upper layer prepare the command parameter;
>>> (2) Call sdhci_send_command, and sdhci_send_command will call
>>> sdhci_set_transfer_mode to set Host Register 0xC;
>>> (3) Call sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags),
>>> SDHCI_COMMAND) to send command;
>>>
>>> For Linux kernel mainstream (without any quirk), MMC case:
>>> (1) It will call mmc_get_ext_csd and this is an DMA transfer, then DMA enable bit will be set to 1 (0xC[0]=1'b1).
>>> (2) Then next Command is mmc_switch(cmd6) which is none-data command, the driver will keep DMA enable bit to 1; this will let our Host failed to execute the CMD06.
>>>
>>> According to SD Host Spec(SD Host Controller Specification verson 4.1 page 41):
>>> Bit0 of Transfer Mode Register(0x0C) is DMA Enable bit, this bit set to 1 means a DMA operation shall begin when Host Driver writes to the upper byte of Command Register(0x0F).
>>>
>>> The DMA enable bit should be set to zero for this none-data command(CMD6).
>> Our host follow the spec. so I think it should be the sdhci driver’s issue (sdhci_set_transfer_mode).
>>>
>>>
>>> So We tried SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD to fix above issue.
>
>>This quirk seems a bit strange. It looks like a generic problem being solved by the wrong approach. Although, my knowledge of sdhci HW is limited so I might be wrong.
>
>>Why doesn't sdhci *always* reset the related registers when the command or data transfer gets *completed*? Instead as currently, delaying that until the *next* request is started and via using SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD?
>
> Yes, this is one solution. We can clear TRANSMER_MODE register(0xC) after SD cmd done to solve current issue, below is the change method:
> static void sdhci_tasklet_finish(unsigned long param) {
> .....
> host->mrq = NULL;
> host->cmd = NULL;
> host->data = NULL;
> sdhci_writew(host, 0x0, SDHCI_TRANSFER_MODE);//Add Clear Transfer Mode here
> .....
> }
>
> But the Disadvantage of this method is: Driver need do additional one register write operation after each command. Please check whether you can accept this change or not. Also it is looks weird to touch setting registers here.
I noticed your discussing since it is me to send this
SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD patch long time ago. :)
As I know, It is not necessary to clear this transfer mode register
for a normal workable host. But I must do this quirk for my abnormal
host behavior.
>
>>>
>>> But it encounter new problem as Alex reported for tuning command as tuning command flow in sdhci_execute_tuning function is:
>>> (1). cmd.data = NULL;
>>> (2). sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE); (3).
>>> sdhci_send_command(host, &cmd); As data is null, this quirk will set
>>> 0x0C[0:15] to ALL zero before send tuning command including SDHCI_TRNS_READ, and the tuning command will failed.
>
>>I see.
>
>>Sdhci's sdhci_execute_tuning() function must be converted to use mmc_send_tuning().
>
>>This means the regular request path will be maintained and thus no special treatment should be needed.
>
>>Nevertheless, if my suggestions around changing sdhci's default behaviour instead of using SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD, >perhaps you don't need to fix sdhci_execute_tuning() to solve the error here!?
>
> I have checked the mmc_send_tuning flow, and it can't replace sdhci_execute_tuning because the tuning command for sdhci.c is special command compare with normal command for 2 points:
> (1) It don't generate Command Complete Interrupt(register 0x30 bit0)
> (2) It has no data for host driver to read but SDHCI_TRNS_READ flag need to be set.
>
Here it is reason why I did not met same issue with yours in tuning
mode when I am using this quirk, since I just use mmc_send_tuning to
do software tuning, which is precondition of using this quirk.
>>>
>>> So, can we commit one patch as below to fix this DMA enable bit for non-data command bug if you cannot accept add new QUIRK?
>
>>Nope, no new quirks.
>
>>> Code should like below(sdhci_set_transfer_mode):
>>> if (data == NULL) {
>>> if (host->quirks2 &
>>> SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD) {
>>> sdhci_writew(host, 0x0, SDHCI_TRANSFER_MODE);
>>> } else {
>>> /* clear Auto CMD settings for no data CMDs */
>>> mode = sdhci_readw(host, SDHCI_TRANSFER_MODE);
>>> sdhci_writew(host, mode & ~(SDHCI_TRNS_AUTO_CMD12 | SDHCI_TRNS_DMA /*Clear DMA enable bit also for no data CMDs*/
>>> SDHCI_TRNS_AUTO_CMD23), SDHCI_TRANSFER_MODE);
>>> }
>>> return;
>>> }
>
>>Thanks for the suggested solution, although I think this looks like yet another hacky workaround for a generic problem.
>
>>Before I further consider that change, can you please look into my suggestions above and see if any of those can simplify the solution?
>
>>[...]
>
>
> So my suggestion is:
> (1) mmc_send_tuning can't replace sdhci_execute_tuning as tuning command is special one;
> (2) modify the sdhci_set_transfer_mode to clear SDHCI_TRNS_DMA without quirk is better than clear transfer mode after command done. From my point of view, SDHCI_TRNS_DMA should be cleared for no-data command before issue command. It follows the spec.
>
>
> BR
> Peter.Guo
>
>
--
---
Vincent Wan(Zongshun)
www.mcuos.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-23 11:13 ` Russell King - ARM Linux
@ 2015-12-28 11:47 ` Ulf Hansson
2016-01-02 12:50 ` Russell King - ARM Linux
0 siblings, 1 reply; 15+ messages in thread
From: Ulf Hansson @ 2015-12-28 11:47 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Peter Guo, Alex Ballas, adam8157, linux-mmc@VGER.KERNEL.ORG,
Adrian Hunter
On 23 December 2015 at 12:13, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Dec 22, 2015 at 09:30:00AM +0100, Ulf Hansson wrote:
>> This quirk seems a bit strange. It looks like a generic problem being
>> solved by the wrong approach. Although, my knowledge of sdhci HW is
>> limited so I might be wrong.
>>
>> Why doesn't sdhci *always* reset the related registers when the
>> command or data transfer gets *completed*? Instead as currently,
>> delaying that until the *next* request is started and via using
>> SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD?
>
> That would be additional overhead. The real problem is that the tuning
Well, yes but I wonder if it isn't negligible.
Of course, if it's more suitable to deal with clearing the register
*before* starting a new request, that should work fine as well.
Anyway, my point is that I find it odd to have a quirk for something
that should be common.
> paths compete with the normal request paths over how to set the registers.
> This competition needs to be killed, and a saner structure for dealing
> with requests and tuning commands needs to be created.
>
> This is something I'm working on as I get time: I'm restructuring
> sdhci_send_command() with the aim of getting to the point where the
> tuning code is _not_ writing to any registers at all, and that's all
> handled by code common to both paths.
Sounds great!
>
>> Sdhci's sdhci_execute_tuning() function must be converted to use
>> mmc_send_tuning().
>
> That will make the request path more complex, because we then need to
> detect the tuning commands and have special handling for them. With
> SDHCI, they are not a standard data transfer command, which is what
> mmc_send_tuning() wants.
If the regular request path isn't used, the core isn't in control of
the request.
I don't like that, as it becomes an exception of how requests are
managed. It also means the host driver will not benefit from the
common error handling paths in the core.
>
> This means we end up with more complexity in what is supposed to be a
> fast path, which means more room for bugs to creep in.
I assume you refer to that the sdhci's host_ops->request() callback
would need to check for the tuning commands and thus treat these as
special cases.
I agree, we should avoid these kind of checks in host drivers.
Typically we can address this by adding a new MMC_CAP* and/or a new
host_ops callback.
In this case I think a new optional host_ops callback, which
mmc_send_tuning() would invoke, should to the trick for sdhci.
What do you think?
Kind regards
Uffe
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
2015-12-28 11:47 ` Ulf Hansson
@ 2016-01-02 12:50 ` Russell King - ARM Linux
0 siblings, 0 replies; 15+ messages in thread
From: Russell King - ARM Linux @ 2016-01-02 12:50 UTC (permalink / raw)
To: Ulf Hansson
Cc: Peter Guo, Alex Ballas, adam8157, linux-mmc@VGER.KERNEL.ORG,
Adrian Hunter
On Mon, Dec 28, 2015 at 12:47:26PM +0100, Ulf Hansson wrote:
> On 23 December 2015 at 12:13, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Dec 22, 2015 at 09:30:00AM +0100, Ulf Hansson wrote:
> >> This quirk seems a bit strange. It looks like a generic problem being
> >> solved by the wrong approach. Although, my knowledge of sdhci HW is
> >> limited so I might be wrong.
> >>
> >> Why doesn't sdhci *always* reset the related registers when the
> >> command or data transfer gets *completed*? Instead as currently,
> >> delaying that until the *next* request is started and via using
> >> SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD?
> >
> > That would be additional overhead. The real problem is that the tuning
>
> Well, yes but I wonder if it isn't negligible.
>
> Of course, if it's more suitable to deal with clearing the register
> *before* starting a new request, that should work fine as well.
>
> Anyway, my point is that I find it odd to have a quirk for something
> that should be common.
It's not "common". While it can be viewed as just another MMC command
and data transaction, the way hosts handle it vary. In the case of
SDHCI, the host needs to be placed into a special mode, and DMA must
not be used:
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
ctrl |= SDHCI_CTRL_EXEC_TUNING;
if (host->quirks2 & SDHCI_QUIRK2_TUNING_WORK_AROUND)
ctrl |= SDHCI_CTRL_TUNED_CLK;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
/*
* As per the Host Controller spec v3.00, tuning command
* generates Buffer Read Ready interrupt, so enable that.
* Note: The spec clearly says that when tuning sequence
* is being performed, the controller does not generate
* interrupts other than Buffer Read Ready interrupt. But
* to make sure we don't hit a controller bug, we _only_
* enable Buffer Read Ready interrupt here.
*/
sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE);
sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE);
These are different from the normal request path.
/*
* Issue CMD19 repeatedly till Execute Tuning is set to 0 or the number
* of loops reaches 40 times or a timeout of 150ms occurs.
*/
...
/*
* In response to CMD19, the card sends 64 bytes of tuning
* block to the Host Controller. So we set the block size
* to 64 here.
*/
if (cmd.opcode == MMC_SEND_TUNING_BLOCK_HS200) {
if (mmc->ios.bus_width == MMC_BUS_WIDTH_8)
sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 128),
SDHCI_BLOCK_SIZE);
else if (mmc->ios.bus_width == MMC_BUS_WIDTH_4)
sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 64),
SDHCI_BLOCK_SIZE);
} else {
sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 64),
SDHCI_BLOCK_SIZE);
}
This seems to set a block size of 128 for width-8.
/*
* The tuning block is sent by the card to the host controller.
* So we set the TRNS_READ bit in the Transfer Mode register.
* This also takes care of setting DMA Enable and Multi Block
* Select in the same register to 0.
*/
sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
This is again at odds with the normal request path.
> >> Sdhci's sdhci_execute_tuning() function must be converted to use
> >> mmc_send_tuning().
> >
> > That will make the request path more complex, because we then need to
> > detect the tuning commands and have special handling for them. With
> > SDHCI, they are not a standard data transfer command, which is what
> > mmc_send_tuning() wants.
>
> If the regular request path isn't used, the core isn't in control of
> the request.
>
> I don't like that, as it becomes an exception of how requests are
> managed. It also means the host driver will not benefit from the
> common error handling paths in the core.
See what SDHCI has to do above which is exceptional to the normal
request path processing.
> > This means we end up with more complexity in what is supposed to be a
> > fast path, which means more room for bugs to creep in.
>
> I assume you refer to that the sdhci's host_ops->request() callback
> would need to check for the tuning commands and thus treat these as
> special cases.
>
> I agree, we should avoid these kind of checks in host drivers.
> Typically we can address this by adding a new MMC_CAP* and/or a new
> host_ops callback.
>
> In this case I think a new optional host_ops callback, which
> mmc_send_tuning() would invoke, should to the trick for sdhci.
Please read through sdhci_execute_tuning(). I think this will add
complexity, because we'd need to detect these tuning requests, and
change the host configuration to perform the tuning.
We'd also need some way to distinguish between the "standard" SDHCI
tuning (which needs special handing), and the "embedded" SDHCI tuning
implemented by MSM, SiRF and iMX which do use mmc_send_tuning().
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-01-02 12:50 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-12 14:04 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work Alex Ballas
2015-12-16 3:42 ` Peter Guo
2015-12-16 9:48 ` Alex Ballas
2015-12-18 3:14 ` Peter Guo
2015-12-18 8:51 ` Ulf Hansson
2015-12-18 9:39 ` Peter Guo
2015-12-18 10:43 ` Alex Ballas
2015-12-18 22:55 ` Alex Ballas
2015-12-22 3:24 ` Peter Guo
2015-12-22 8:30 ` Ulf Hansson
2015-12-23 6:39 ` Peter Guo
2015-12-23 14:24 ` Wan ZongShun
2015-12-23 11:13 ` Russell King - ARM Linux
2015-12-28 11:47 ` Ulf Hansson
2016-01-02 12:50 ` Russell King - ARM Linux
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.