SDHCI: Introduce a driver for NXP QorIQ LS10xx SoCs.

[ar_semihalf.com]

Summary

Implement support for an eSDHC controller found in NXP QorIQ Layerscape SoCs.

This driver has been tested with NXP LS1046A, which is incompatible with the existing sdhci_fsl driver (aiming at older chips from this family). As such, it is not intended as replacement for the old driver, but rather serves as an improved alternative for SoCs that support it.
It comes with support for both PIO and Single DMA modes and samples the clock from the extres clk API.

[ar_semihalf.com]

@manu @mmel @mw Any remarks to this patch?

[manu]

Sorry I forgot about it, I'll review this later today.
Two quick question :

• could you drop the all right reserved ?
• Was it tested with an MMCCAM kernel ? I'd like us to switch to it for 13.

[ar_semihalf.com]

In D26153#583257, @manu wrote:

Sorry I forgot about it, I'll review this later today.
Two quick question :

• could you drop the all right reserved ?

Sure.

• Was it tested with an MMCCAM kernel ? I'd like us to switch to it for 13.

I just tested this driver with MMCCAM on hardware that contains a single eMMC chip. On the old mmc stack this card (correctly) displays the following partitions:

mmcsd0
mmcsd0boot0
mmcsd0boot1
mmcsd0p1
mmcsd0p2
mmcsd0p3
mmcsd0p4
mmcsd0rpmb

however, with MMCCAM I only get sdda0 and no partitions:

sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0
sdda0: Relative addr: 00000002
Card features: <MMC Memory High-Capacity>
Card memory OCR: 00ff8080
sdda0: Serial Number C565B3C
sdda0: MMCHC 008G30 0.4 SN C565B3CD MFG 03/2002 by 17 0x0000

I reckon this is not an expected behavior with eMMC and I'm not missing any extra hooks for this stack in my driver?

I currently have no access to LS1046A hardware with a general SD slot to test MMCCAM with non-eMMC cards, but this could be arranged at a later date.
For reference, to test MMCCAM I am building the kernel with the stock KERNCONF=GENERIC-MMCCAM.

[manu]

Adding @kibab, maybe he can find something weird related to MMCCAM.

[manu]

Otherwise it looks good, I'll re-read the code tomorow with a clear mind to be sure.
Thanks

[imp]

I didn't think that MMC CAM supported the 'partitions' that mmc can do... that's half of the partitions listed...

[manu]

In D26153#583597, @imp wrote:

I didn't think that MMC CAM supported the 'partitions' that mmc can do... that's half of the partitions listed...

There is code (don't remember if it's enabled or not right now) but they should at least see the gpt partitions that are present with the current stack.

[mmel]

Can you please add following compatibility string before commit?
https://github.com/strejda/freebsd/commit/3f9ef1815b12048dba47504ff1ce9f48cce0fac1
(tested on honeycomb board with LX2160A SOC)
In any case its OK for me, all potential MMCCAM related problems should be fixed in own commit.
Thanks for your effort.

[ar_semihalf.com]

changes:

• drop "All rights reserved",
• bump copyright to 2020,
• add SPDX identifier,
• integrate @mmel's changes for LX2160A compat. string

[kibab]

At the first glance I don't see anything weird wrt MMCCAM intergration; I agree that MMCCAM-related problems should be fixed in the follow-up commits and not here.
Regarding the partitions: it would be interesting to see the output of ls /dev/sdda* on MMCCAM kernel, probably the partitions got detected but not printed on boot.

[ar_semihalf.com]

In D26153#583890, @kibab wrote:

Regarding the partitions: it would be interesting to see the output of ls /dev/sdda* on MMCCAM kernel, probably the partitions got detected but not printed on boot.

With GENERIC-MMCCAM, my kernel failed to mount a rootfs located on an unrelated usb drive (perhaps this hints towards a bigger issue?), so I wasn't able to properly inspect the mmc partitions from userspace. I did however list all available drives via mountroot and there were no partitions listed for sdda0.

[manu]

In D26153#583898, @ar_semihalf.com wrote:

In D26153#583890, @kibab wrote:

Regarding the partitions: it would be interesting to see the output of ls /dev/sdda* on MMCCAM kernel, probably the partitions got detected but not printed on boot.

With GENERIC-MMCCAM, my kernel failed to mount a rootfs located on an unrelated usb drive (perhaps this hints towards a bigger issue?), so I wasn't able to properly inspect the mmc partitions from userspace. I did however list all available drives via mountroot and there were no partitions listed for sdda0.

That's really weird ...
Is there any shared clocks/regulator between mmc and usb that could explain usb not being available if mmc isn't probed/init correctly ?

[ar_semihalf.com]

In D26153#583899, @manu wrote:

In D26153#583898, @ar_semihalf.com wrote:

In D26153#583890, @kibab wrote:

Regarding the partitions: it would be interesting to see the output of ls /dev/sdda* on MMCCAM kernel, probably the partitions got detected but not printed on boot.

With GENERIC-MMCCAM, my kernel failed to mount a rootfs located on an unrelated usb drive (perhaps this hints towards a bigger issue?), so I wasn't able to properly inspect the mmc partitions from userspace. I did however list all available drives via mountroot and there were no partitions listed for sdda0.

That's really weird ...
Is there any shared clocks/regulator between mmc and usb that could explain usb not being available if mmc isn't probed/init correctly ?

Not to my knowledge. sdhci_fsl_fdt doesn't modify the parent clock in any way and the prescalers/dividers it sets are internal to this IP block.

[mw]

In D26153#583969, @ar_semihalf.com wrote:

In D26153#583899, @manu wrote:

In D26153#583898, @ar_semihalf.com wrote:

In D26153#583890, @kibab wrote:

Regarding the partitions: it would be interesting to see the output of ls /dev/sdda* on MMCCAM kernel, probably the partitions got detected but not printed on boot.

With GENERIC-MMCCAM, my kernel failed to mount a rootfs located on an unrelated usb drive (perhaps this hints towards a bigger issue?), so I wasn't able to properly inspect the mmc partitions from userspace. I did however list all available drives via mountroot and there were no partitions listed for sdda0.

That's really weird ...
Is there any shared clocks/regulator between mmc and usb that could explain usb not being available if mmc isn't probed/init correctly ?

Not to my knowledge. sdhci_fsl_fdt doesn't modify the parent clock in any way and the prescalers/dividers it sets are internal to this IP block.

IMO it is not related. With config GENERIC the platform works fine without the SDHCI driver, i.e. the USB is absolutely independent.