Am 26.03.2017 um 12:59 schrieb H. Nikolaus Schaller hns@goldelico.com:

...

Am 26.03.2017 um 03:06 schrieb Matthijs van Duin matthijsvanduin@gmail.com:

It turns out that all linux images we've used so far had no support yet for UHS or HS200 or such in the MMC driver, hence the primary SD slot and eMMC were artificially speed-limited.

It turned out patches to fix that had been made but have not yet reached upstream. I've rebased them on top of mainline 4.10.1: https://github.com/mvduin/linux/commits/ti/omap-hsmmc

All you then need to do is declare supported functionality in DT: https://github.com/mvduin/linux/commit/925d93d4e22a

As a bonus they also enhanced DMA support.

Great! TNX.

...

Read speed on the eMMC of the uEVM about 60-65 MB/s.

Enjoy!

Have quickly merged on top of letux-4.10.5:

http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/letux-4...

It seems to have a problem on Pyra:

[ 3.812928] Waiting for root device PARTUUID=00000000-02... [ 4.121999] omap_hsmmc 480ad000.mmc: card claims to support voltages below defined range [ 4.155258] mmc2: new high speed SDIO card at address 0001 [ 4.192311] omap_hsmmc 4809c000.mmc: card busy [ 4.263854] mmc1: error -110 whilst initialising SD card

But I am not sure if my quick build (not clean) is ok. Need more time. Maybe remove high-speed mode from mmc1 to be able to completely boot.

I have removed settings for mmc1 and made a clean build (so that I don't know exactly which ones makes the difference). But this time I could, well, boot:

... [ 8.940642] bq2429x_charger 1-006b: failed to request chg_irq: -22 [ 8.955942] input: twl6040:vibrator as /devices/platform/44000000.ocp/48070000.i2c/i2c-0/0-004b/twl6040-vibra/input/input9 [ 8.978790] modem: done [ 8.982549] wwan-on-off successfully probed [ 9.028533] omap-abe-twl6040 sound: twl6040-legacy <-> 40132000.mcpdm mapping ok [ 9.068073] input: Letux Cortex 15 Headset Jack as /devices/platform/sound/sound/card0/input10 [ 9.117576] txs_probe() [ 9.120232] txs_probe() initial = 0 [ 9.123925] txs_probe() probed [ 9.206221] [drm] Initialized [ 9.677305] dmm 4e000000.dmm: initialized all PAT entries [ 9.767900] not all displays probed (1 of 2) [ 10.147483] mmc0: new HS200 MMC card at address 0001 [ 10.177057] mmcblk0: mmc0:0001 HBG4a2 29.1 GiB [ 10.181004] UBIFS error (pid: 1164): cannot open "ubi0:gta04-rootfs", error -19 [ 10.207075] mmcblk0boot0: mmc0:0001 HBG4a2 partition 1 4.00 MiB [ 10.232624] mmcblk0boot1: mmc0:0001 HBG4a2 partition 2 4.00 MiB [ 10.261875] mmcblk0: p1 p2 [ 10.300761] not all displays probed (1 of 2) [ 10.374266] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.498399] mmcblk0: response CRC error sending r/w cmd command, card status 0xb00 [ 10.596186] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.608403] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.619924] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.631620] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.799005] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.807479] blk_update_request: I/O error, dev mmcblk0, sector 61071344 [ 10.818507] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.849685] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.923261] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.936359] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.949808] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 10.991766] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 11.000127] blk_update_request: I/O error, dev mmcblk0, sector 61071344 [ 11.007386] Buffer I/O error on dev mmcblk0, logical block 7633918, async page read [ 11.050312] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 11.088880] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 11.128199] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 11.141164] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 11.182957] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 11.196182] mmcblk0: response CRC error sending r/w cmd command, card status 0x800b00 [ 11.204550] blk_update_request: I/O error, dev mmcblk0, sector 61071344... ... this continues and ends after a while.

Then I can get:

root@letux:~# cat /sys/kernel/debug/mmc0/ios clock: 192000000 Hz vdd: 18 (3.0 ~ 3.1 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 9 (mmc HS200) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) root@letux:~#

This obviously means as conjectured that the eMMC has severe problems at HS200 speed and there is no mechanism to fall back to slower speeds.

BR, Nikolaus

Am Sun, 26 Mar 2017 18:51:38 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:

Hi,

...

This obviously means as conjectured that the eMMC has severe problems at HS200 speed and there is no mechanism to fall back to slower speeds.

After reducing DT speed to

max-frequency = <92000000>;

the CRC errors are gone.

Well, that's probably because of the MUX, which will not be able to run at HS200.

Next I tried 142MHz and it also works w/o any CRC error and is faster: root@letux:~# hdparm -tT /dev/mmcblk0

/dev/mmcblk0: Timing cached reads: 992 MB in 2.00 seconds = 495.98 MB/sec Timing buffered disk reads: 244 MB in 3.02 seconds = 80.85 MB/sec root@letux:~# hdparm -tT --direct /dev/mmcblk0

Interesting. If I understood correctly, the MUX doesn't support more than 120MHz (or 60MHz, depending whether you run in SDR or DDR)

So that would be quite some overclocking, or not?

The strange thing is that increasing the max-frequency by 50% gives double speed... Maybe someone else can extend experiments based on this to determine the clock limit.

I'm not sure that the frequencies are freely supported. Maybe the eMMC has some fixed frequencies it'll run with and therefore runs lower when clocked with 92MHz...?

No idea :)

Wait nm, this is the primary SD slot. Yes that one should support all speeds.

mmcblk1 cannot support any UHS mode right now due to inability to switch voltage

Am 27.03.2017 um 04:18 schrieb Matthijs van Duin matthijsvanduin@gmail.com:

*sigh* okay I think I need to wake up properly first...

primary SD can switch signal voltage using LDO9. eMMC always uses 1.8V signalling and is speed-limited only by mux. μSD cannot switch signal voltage to 1.8V hence cannot support any UHS mode.

I just noticed that your kernel called eMMC "mmc0" instead of "mmc1", that's confusing as hell. Please apply: https://github.com/mvduin/linux/tree/patch/of-alias

Has this been suggested upstream?

I'd prefer to keep the number of such deviations from mainline core code as low as possible unless it is absolute necessary. This seems to be a patch which makes life a lot easier, but I have no problem using mmc0/1 names by using UUIDs at the right locations. And it should not be omap5 only because Letux supports other SoC as well (omap3/4/am335x). So either do it right and the same for all or don't.

Therefore I have also addressed Tony if such a patch is/can be being considered upstream.

On 26 March 2017 at 18:51, H. Nikolaus Schaller hns@goldelico.com wrote: clock: 142000000 Hz timing spec: 9 (mmc HS200)

Keep in mind that just because overclocking is successful in one instance doesn't mean it will work on the next board.

That is why I urge more people to repeat the test and report their results. Of course the first finding is just what it is: a first finding... And more to prove the test method than to make decisions about reliability and speed.

The strange thing is that increasing the max-frequency by 50% gives double speed...

I think 92 MHz gets rounded down to 48 MHz and 144 MHz gets rounded down to 96 MHz.

Ah yes, that is well possible. And 192 MHz would stay 192 MHz.

Wouldn't/shouldn't that round down be reported by cat /sys/kernel/debug/mmc0/ios ?

A quick test could be to try 191 MHz...

On 27 March 2017 at 01:25, Michael Mrozek EvilDragon@openpandora.org wrote: If I understood correctly, the MUX doesn't support more than 120MHz (or 60MHz, depending whether you run in SDR or DDR)

It doesn't support more than 60 MHz SDR (60 Mbit/s per IO) or 60 MHz DDR (120 Mbit/s per IO) due to max clock frequency. When using 8 data IO lines there's also the skew issue which will limit the speed to an unknown value (probably lower for writes than for reads).

Am 27.03.2017 um 07:33 schrieb Matthijs van Duin matthijsvanduin@gmail.com:

On 27 March 2017 at 07:20, H. Nikolaus Schaller hns@goldelico.com wrote:

...

...

Am 27.03.2017 um 04:18 schrieb Matthijs van Duin matthijsvanduin@gmail.com: I just noticed that your kernel called eMMC "mmc0" instead of "mmc1", that's confusing as hell. Please apply: https://github.com/mvduin/linux/tree/patch/of-alias

Has this been suggested upstream?

A patch along those lines has been periodically posted on linux-mmc and got rejected for bogus reasons. Basically the linux-mmc devs think that, since you don't have reliable numbering of storage devices on PCs (where typically they are enumerated on discoverable buses), everybody using embedded systems should therefore also suffer with unpredictable numbering of devices.

Or they say: define your own udev-rules.

Yes, I know... My last attempt was to get the pre-calibration for our tsc2007 driver upsream. Just 2 lines of code and *we* would be happy.

The argument was that it can be solved in user space. Yes, *I* can fix it in user space by hacks. And aTc for the Pyra. But as soon as someone else wants to use a different user space he/she has to reinvent the wheel. What I don't can and want to is to fork X11 and provide my own xinput server just to do the same as the two lines in kernel...

My patches (or similar ones) have been integrated in Robert Nelson's kernels since he does care about embedded users.

Note that i2c and spi do support DT-provided numbering, except the mcspi driver breaks it. I should perhaps try to upstream that patch, except of course people will complain since it breaks backward compatibility for people who currently hardcode spi device numbers in applications.

Yes, that is the same way of argumentation I had to fight with the tsc2007...

BR, Nikolaus

On 27 March 2017 at 07:20, H. Nikolaus Schaller hns@goldelico.com wrote:

...

I think 92 MHz gets rounded down to 48 MHz and 144 MHz gets rounded down to 96 MHz.

Ah yes, that is well possible. And 192 MHz would stay 192 MHz.

Note that rounding this coarse really isn't necessary, but is probably due to sdhci: sdhci v2: power-of-two up to /256 sdhci v3: /1 or even divider up to /2046 omap-hsmmc: any divider up to /1023

So 192/3 = 64 MHz should really be available at least.

Moreover on the omap5, MMC1 and MMC2 (1-based) each has its own functional clock, selectable from { 64, 96, 128, 192 } MHz.

Wouldn't/shouldn't that round down be reported by cat /sys/kernel/debug/mmc0/ios ?

That would have been nice yes.

So, what's happening is that omap-hsmmc tries to set its functional clock to the DT-specified max frequency. However, although the choices available are { 192, 128, 96, 64 } MHz, it will only pick 192 or 96 MHz, I guess because it's afraid to toggle a mux? (even though it is the only downstream user of that clock).

It will use 128 MHz or 64 MHz if you first toggle the mux in u-boot: mw 4A009630 00070000

I seem to be able to write eMMC at 96 MHz and read it at 128 MHz. The mux seems to hold up quite well, although I'm not sure I'd *trust* it at those speeds, especially not since the driver currently seems to have very bad error handling and treats crc errors as fatal IO errors instead of retrying?

A few large transfers at those speeds did also warm up the whole thing to the point that my charger led started blinking due to battery temperature max.

And what the hell is happening here on my boot disk in primary SD slot:

[ 2.682459] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 480 = 400 kHz [ 2.685264] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 480 = 400 kHz [ 2.687072] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 1 = 192000 kHz [ 2.762999] mmc0: new ultra high speed SDR104 SDHC card at address 59b4 [ 2.768274] mmcblk0: mmc0:59b4 RUNSD 29.5 GiB [ 2.774714] mmcblk0: p1 ... [ 2.908282] EXT4-fs (mmcblk0p1): INFO: recovery required on readonly filesystem [ 2.910205] EXT4-fs (mmcblk0p1): write access will be enabled during recovery [ 2.914126] omap_hsmmc 4809c000.mmc: ADMA err: ST_TFR, desc at 0xfd858020 follows the erroneous one [ 3.008230] omap_hsmmc 4809c000.mmc: ADMA err: ST_TFR, desc at 0xfd858020 follows the erroneous one [ 3.039096] mmcblk0: error -84 transferring data, sector 16672, nr 48, cmd response 0x900, card status 0xb00 [ 3.042740] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 1 = 192000 kHz [ 3.054383] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 1 = 192000 kHz [ 3.089025] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 480 = 400 kHz [ 3.119008] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 480 = 400 kHz [ 3.123061] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 480 = 400 kHz [ 3.153166] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 480 = 400 kHz [ 3.154976] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 4 = 48000 kHz [ 3.156923] omap_hsmmc 4809c000.mmc: set clock to 192000 kHz / 4 = 48000 kHz [ 3.580391] EXT4-fs (mmcblk0p1): recovery complete [ 3.587965] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)

It remains at 3.3V 48 MHz from there on...

The "recovery required" is another interesting bit, this happens every single time, even after I've shut down cleanly. This is with an UHS-I microSD in an SD adapter in the primary slot.

On 27 March 2017 at 17:45, Tony Lindgren tony@atomide.com wrote:

My guess is that the alias names for Pyra should be something like this instead:

"sdio1", "sdio2", "micro-sd"

No, they need to be named specifically with a generic device class name ("mmc" in this case) + unique number. This is what allows them to be used by the of_alias_* API calls.

See e.g. uses of those calls by: * drivers/i2c/i2c-core.c * drivers/spi/spi.c * drivers/tty/serial/8250/8250_of.c (I based my mmc patch on the i2c core specifically.)

On 27 March 2017 at 18:07, Tony Lindgren tony@atomide.com wrote:

Anyways, that still won't help end users are all, this only helps the people who have the TRM fnord instance numbering burnt into their brains :)

It's a numbering consistent across boot, and consistent with u-boot's device numbering, which means the boot script can first load a kernel from mmc $n partition $p and then pass root=/dev/mmcblk${n}p${p} to the kernel.

See the slot_name solution I just replied with.

I don't see how that is helpful at all. If I just wanted some DT-specified label I can slap some property onto the DT nodes and access it via the of_node symlink. This is e.g. what I do for uio devices on beaglebones:

SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}"

On 27 March 2017 at 18:32, Tony Lindgren tony@atomide.com wrote:

And that's where people will say "use UUIDs" as the Linux generic solution. Won't help at all making sense of dmesg output though.

As far as I'm concerned, UUIDs are the last resort of identifiers, since other than being unique they have no desirable trait whatsoever. Moreover the kernel does not even support them last time I checked, so this would force the use of an initramfs.

The mmcblk numbers (with patch) are moreover also useful to unambiguously refer to card slot itself, and the entire block device that resides there. UUIDs are not available for these purposes.

So it's the choice between a long obnoxious identifier usable for only a limited subset of use-cases, or a few-line patch to get a short and convenient identifier usable for all purposes. I don't see this as a difficult choice.

* Matthijs van Duin matthijsvanduin@gmail.com [170327 09:50]:

On 27 March 2017 at 18:32, Tony Lindgren tony@atomide.com wrote:

...

And that's where people will say "use UUIDs" as the Linux generic solution. Won't help at all making sense of dmesg output though.

As far as I'm concerned, UUIDs are the last resort of identifiers, since other than being unique they have no desirable trait whatsoever. Moreover the kernel does not even support them last time I checked, so this would force the use of an initramfs.

The mmcblk numbers (with patch) are moreover also useful to unambiguously refer to card slot itself, and the entire block device that resides there. UUIDs are not available for these purposes.

So it's the choice between a long obnoxious identifier usable for only a limited subset of use-cases, or a few-line patch to get a short and convenient identifier usable for all purposes. I don't see this as a difficult choice.

Well maybe send the omap5-uevm-common.dtsi patch for discussion so we get to hear what Rob thinks?

Regards,

Tony

Am 27.03.2017 um 19:05 schrieb Matthijs van Duin matthijsvanduin@gmail.com:

On 27 March 2017 at 19:01, Tony Lindgren tony@atomide.com wrote: Well maybe send the omap5-uevm-common.dtsi patch for discussion so we get to hear what Rob thinks?

The non-mmc parts thereof are "obvious" and were simply missing. The relevant kernel subsystems already make use of those aliases (except mcspi broke it with an ugly hack that was probably intended to have the same result).

The mmc part is useless without the patch that enables use of them, and that patch (or an equivalent one) has been attempted and rejected by linux-mmc at least three times.

At some point one just gives up, it's far less effort to just maintain the patch out of tree.

Partially agreed. But the At some point also holds for the "it's far less effort to just maintain the patch out of tree". It starts to increase over time when the sum of out-of-tree patches grows and grows as and has more and more dependencies and rebase conflicts when you want to stay in sync with latest kernel.

I work on the letux kernels since 2.6.32 and since 3.14 we tried to upstream things as soon as they become "mature". Some things went through very well (and disappear from our patch sets), whilst for others you are running against a wall of concrete...

I am even tracking statistics how many files we have touched. It was always in the range of 50-150. So just a tiny portion of the whole tree, just to make our devices well supported. Unfortunately it is not really decreasing.

Nevertheless my main goal is to get these things down to 0. But it is much more Sisyphos work than ever anticipated... It was easy to add DT things between 3.13 and 3.19 but that was the general ARM DT rework phase. Nowadays it looks as if maintainers (especially DT maintainers) have much more strict rules what can be accepted and what can't. Basically this is good so and shows how mature DRM DT support is nowadays.

Unfortunately these rules and policies are nowhere written down. You learn them only by wrestling with the maintainers until you squeeze out the answers you need :) Then you can decide to start the next attempt or argumentation.

BR, Nikolaus

On 27 March 2017 at 18:32, Tony Lindgren tony@atomide.com wrote:

So I guess no still no Linux generic solution in sight.

Just to add: a stable identifier for platform resources is platform knowledge, hence always handed down from bootloader to linux. Multiple mechanisms for this exist (DT, ACPI) and aren't going to go away, so a "linux generic" solution isn't possible.

Meanwhile the of_alias mechanism is simple and generic across all architectures that use DT, and is already in use by multiple subsystems. Its main flaw is being poorly documented, like so many kernel-things.

Anyway, hns wanted to know why this isn't upstream or being upstreamed, I think I've informed all parties as well as I can about this. I would still appreciate it being applied at least while we're doing mmc testing since it reduces the risk of confusion. I intend to keep it indefinitely in kernels I build personally. I don't intend to spend more time and energy on this discussion.