Confused by mmc modules

[feelslikeautumn]

Using the latest Ubuntu raspi2 kernel I'm getting an error in my dmseg. I'm guessing it is to do with the mmc modules. I've picked out the mmc bits of the dmesg:

Code: Select all

[    3.775213] sdhci: Secure Digital Host Controller Interface driver
[    3.778422] sdhci: Copyright(c) Pierre Ossman
[    3.781879] mmc-bcm2835 3f300000.mmc: could not get clk, deferring probe
[    3.785342] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[    3.788708] Error: Driver 'sdhost-bcm2835' is already registered, aborting...
[    3.792028] sdhci-pltfm: SDHCI platform and OF driver helper

[    3.967945] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[    3.971220] mmc-bcm2835 3f300000.mmc: DMA channel allocated
[    4.011940] sdhost: log_buf @ 53f6571a (fa853000)
[    4.032295] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    4.036912] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    4.041633] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    4.050403] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    4.087381] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[    4.091191] hctosys: unable to open rtc device (rtc0)

[    4.172468] mmc1: new high speed SDIO card at address 0001
[    4.198049] mmc0: host does not support reading read-only switch, assuming write-enable
[    4.204236] mmc0: new high speed SDHC card at address aaaa
[    4.208074] mmcblk0: mmc0:aaaa SL08G 7.40 GiB
[    4.213926]  mmcblk0: p1 p2

The kernel seems to have a lot of mmc modules, quite a few of which are built in:

Code: Select all

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_BCM2835_MMC=y
CONFIG_MMC_BCM2835_DMA=y
CONFIG_MMC_BCM2835_PIO_DMA_BARRIER=2
CONFIG_MMC_BCM2835_SDHOST=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_ARMMMCI=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=m
CONFIG_MMC_SDHCI_OF_AT91=m
CONFIG_MMC_SDHCI_CADENCE=m
CONFIG_MMC_SDHCI_F_SDH30=m
CONFIG_MMC_SDHCI_IPROC=m
CONFIG_MMC_SPI=m
CONFIG_MMC_TMIO_CORE=m
CONFIG_MMC_TMIO=m
CONFIG_MMC_DW=m
CONFIG_MMC_DW_PLTFM=m
CONFIG_MMC_DW_EXYNOS=m
CONFIG_MMC_DW_K3=m
CONFIG_MMC_VUB300=m
CONFIG_MMC_USHC=m
CONFIG_MMC_USDHI6ROL0=m
CONFIG_MMC_REALTEK_USB=m
CONFIG_MMC_BCM2835=y
CONFIG_MMC_MTK=m
CONFIG_MMC_SDHCI_XENON=m
# CONFIG_MMC_SDHCI_OMAP is not set
CONFIG_MEMSTICK=m
# CONFIG_MEMSTICK_DEBUG is not set

built in modules:

Code: Select all

kernel/drivers/mmc/core/mmc_core.ko
kernel/drivers/mmc/core/pwrseq_simple.ko
kernel/drivers/mmc/core/pwrseq_emmc.ko
kernel/drivers/mmc/core/mmc_block.ko
kernel/drivers/mmc/host/armmmci.ko
kernel/drivers/mmc/host/sdhci.ko
kernel/drivers/mmc/host/bcm2835-mmc.ko
kernel/drivers/mmc/host/bcm2835-sdhost.ko
kernel/drivers/mmc/host/bcm2835.ko
kernel/drivers/mmc/host/sdhci-pltfm.ko

Running lsmod shows:

Code: Select all

sdhci_iproc            16384  0

Presumably parts of upstream and downstream have been merged to get in this situation and there are several modules trying to do the same job. I want to raise a bug about this, but I have no idea what to write! Can somebody give me a brief guide as to why there are so many mmc modules, and which is the best and recommended to use? Thanks!

[PhilE]

I'm away from a keyboard today so a bit limited, but it would help if you could post the output of:

Code: Select all

dtc -I fs /proc/device-tree

For general guidance, in the Raspberry Pi kernels we use the bcm2835-sdhost driver for the SD card or EMMC interface and bcm2835-mmc for SDIO to the WiFi chip. Upstream uses bcm2835 for SD and sdhci-iproc for SDIO. At some point we may replace the downstream drivers with patched versions of the upstream variants, but it hasn't happened yet.

[feelslikeautumn]

Thanks PhilE that's cleared it up a bit for me.

Output of your command https://pastebin.com/DMXq0ckP

Are there lots of other modules where upstream and downstream differ? (Sorry I've a lot to learn about the pi kernels!)

[PhilE]

Thanks for the DT dump - it confirms that you are using the downstream DTB which includes compatible strings for all four SD/MMC drivers, so configuring out or blacklisting is required to select the preferred drivers.

We are using more upstream drivers than we used to, but there are still a few differences. Aside from the SD drivers as discussed, the main difference is the USB driver - we use a heavily optimised dwc_otg driver that makes use of the ARM's FIQ to reduce the interrupt overhead - upstream is using the standard DWC2 driver. The remaining differences are confined to a few drivers that haven't been upstreamed yet - dpi, smi, etc. - and a few patches to otherwise upstreamed drivers, including add interrupt controller functionality to the AUX clock driver.

[feelslikeautumn]

Thanks again PhilE. Does the pi have a special way to select which driver to use? I saw in an old thread:

Code: Select all

bcm2708.bcm2835_mmc=0

In the past I've passed on the kernel command line something like:

Code: Select all

 module.blacklist=true

(which is just passing an unknown parameter to the module which stops it loading)

Adding a module to /etc/modprobe.d/blacklist.conf doesn't work for built in modules. I assume it is the same if you add to the kernel command line modprobe.blacklist=MODULE_NAME.

Do you think I should raise a bug about this? Should I recommend that the same mmc kernel config options are used as the foundation kernel?

[opfer15]

Sorry for reviving this older thread. But with the information avaible i was not able to fix this issue:

Code: Select all

Error: Driver 'sd-host-bcm2835' is already registered, aborting...

The dtb files are created while compiling the default/master branch (4.14) of rpi-kernel [1] with

Code: Select all

bcmrpi3_defconfig

defconfig.

PihlE infos:
Downstream (suggest raspbian)
- bcm2835-sdhost driver for the SD card or EMMC interface
- bcm2835-mmc for SDIO to the WiFi chip.

Upstream (suggest github kernel and userland and debootstrap?)
- bcm2835 for SD and sdhci-iproc for SDIO.

so i tried to remove the following from my git/upstream kernel config

Code: Select all

        CONFIG_MMC_SDHCI_IPROC=n
	CONFIG_USB_DWC2=n

but the error persists. I found a overlay for dtoverlay=dwc-otg, but this should be default on and adding it didn't fix the issue.

Code: Select all

[    1.550513] bcm2835-wdt 3f100000.watchdog: Broadcom BCM2835 watchdog timer
[    1.552470] bcm2835-cpufreq: min=600000 max=1200000
[    1.554661] sdhci: Secure Digital Host Controller Interface driver
[    1.556375] sdhci: Copyright(c) Pierre Ossman
[    1.558022] mmc-bcm2835 3f300000.mmc: could not get clk, deferring probe
[    1.559046] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[    1.559970] Error: Driver 'sdhost-bcm2835' is already registered, aborting...
[    1.560835] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.562875] ledtrig-cpu: registered to indicate activity on CPUs
[    1.563843] hidraw: raw HID events driver (C) Jiri Kosina
[    1.564801] usbcore: registered new interface driver usbhid
[    1.565665] usbhid: USB HID core driver
[    1.566698] Initializing XFRM netlink socket
[    1.567567] NET: Registered protocol family 17
[    1.568623] Key type dns_resolver registered
[    1.570164] registered taskstats version 1
[    1.571021] Loading compiled-in X.509 certificates
[    1.571936] zswap: loaded using pool lzo/zbud
[    1.572904] AppArmor: AppArmor sha1 policy hashing enabled
[    1.578266] uart-pl011 3f201000.serial: cts_event_workaround enabled
[    1.579256] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 72, base_baud = 0) i                                      s a PL011 rev2
[    1.582296] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[    1.583281] mmc-bcm2835 3f300000.mmc: DMA channel allocated
[    1.610455] sdhost: log_buf @ ffffff80080ad000 (fac47000)
[    1.633497] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    1.636936] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    1.640307] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    1.643916] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    1.662514] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)

I have the following questions:

1. Is this normal behaviour? I didn't expect my kernel to load "thousands" of SD/MMC drivers which are causing trouble if i use default defconfig
2. do we need to edit dtb-files or use an overlay? In my dtb file i just found bcm2835-sdhost or bcm2835-sdhci is it neccessary to remove these definitions or mask them via overlay?

Code: Select all

dtoverlay=sdhost,<param>=<val>

sdhost-overlay doesn't seem to be the correct one too. And to add another the "new"

Code: Select all

sd_*

host dtb parameters seem to be the wrong ones too.
3. Which kernel modules should be removed if you want the default driver back...

Any help would be appriciated. After some days this is starting to annoy me :/
PLS ENLIGHTEN ME

[1] - https://github.com/raspberrypi/linux

[PhilE]

Device Tree is supposed to describe the hardware, not to tell the operating system which driver to use. This means that any (and all) drivers for a device must indicate that they support the standard "compatible" string. If there is more than one driver for a device (a slightly unusual situation), the only ways to select between them are by blacklisting or by not building the unwanted drivers. As has been noted, blacklisting only works for loadable modules, not built-in drivers, but building in multiple drivers for the same device is nonsensical.

Each of the two BCM2835 MMC/SD interfaces has two drivers in the downstream tree. For the Arasan MMC interface we have "sdhci-iproc" (upstream), and "bcm2835-mmc" (downstream), while for the Broadcom SDHOST interface there is "bcm2835" (upstream) and "bcm2835-sdhost" (downstream). These drivers could be consolidated so that, assuming we still want to keep the dowstream-specific features (mainly overclocking support and Device-Tree controlled debugging), the downstream drivers becomes patched versions of the standard upstream ones.

The standard Raspberry Pi defconfigs only enable the downstream drivers, so we see no clashes. You appear to have removed one of the spare MMC drivers and the non-FIQ-accelerated upstream USB driver with:

Code: Select all

CONFIG_MMC_SDHCI_IPROC=n
CONFIG_USB_DWC2=n

In order to disable the upstream SDHOST driver you need to add one more config setting:

Code: Select all

CONFIG_MMC_BCM2835=n

[opfer15]

Hi PhilE,

thank you very much for your clarifications. Since this is the first google hit for this error i am sure others will benefit from it too.

I intent to use the heavily patched downstream drivers.
I try to do this by setting:

Code: Select all

CONFIG_MMC_BCM2835=n
CONFIG_MMC_SDHCI_IPROC=n
CONFIG_USB_DWC2=n

in my kernel config.

While my first post was in moderator queue i found some additional information on [1] a github post which suggest to also patch Kconfig so DMA-Access has "better" dependencies.

Code: Select all

sed -i "s|depends on MMC_BCM2835_MMC && MMC_BCM2835_DMA|depends on MMC_BCM2835_MMC|" "${KERNELSRC_DIR}"/drivers/mmc/host/Kconfig

I compiled a new kernel and the error message dissapeared. Now the SD-Card pops up as:

Code: Select all

mmc: host does not support reading read-only switch, assuming write-enable
mmc: new high speed SDHC card at address e624
bounce: isa pool size: 16 pages
mmcblk0: mmc0:e624 SU04G 3.69 Gib
mmcblk0: p1 p2

I am not able to determin if the correct driver is now loaded, but i don't see Iproc in lsmod anymore. But i also don't see any sd or mmc realted stuff in lsmod.

what persists is:

Code: Select all

[    3.781879] mmc-bcm2835 3f300000.mmc: could not get clk, deferring probe
[    3.785342] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe

I found a commit[2] from pelwell raising this def_info and dev_error if no clock is detected. the parent commit reverted early clock detection. I also found a lot of posts totaly unrealted with this issue, but with same clock messages. So maybe this is just normal...

Maybe we could profit from your knowledge again?
Thx in advance

[1] https://github.com/raspberrypi/linux/issues/2124
[2] https://github.com/raspberrypi/linux/co ... 48696ed0b9

[PhilE]

The probe deferral mechanism is (in my opinion) an ugly workaround for the lack of a proper device dependency mechanism. The idea is that if a driver discovers that one of its required resources is not yet (*) available, it returns -517 (-EPROBE_DEFER) from its .probe function. When other devices are successfully probed, any devices in the deferred queue get retried.

Since there is no defined way to force a particular probe order, these deferrals are essentially impossible to avoid, so there is an argument for adding any message to the kernel log. However, the (*) above highlights an issue - it isn't possible to distinguish a device that hasn't yet been probed from one that has failed to probe or one that will never be probed, so the log message may be the only clue as to why the driver isn't starting as expected.

In other words, the "errors" or "warnings" are nothing to be concerned about.

BTW "pelwell" is my GitHub handle.