| /rk3399_rockchip-uboot/include/ |
| H A D | dwmmc.h | bda599f7c7d1023a9629cecf3fcb9d90c159c5f0 Mon Oct 09 09:51:29 UTC 2017 Shawn Lin <shawn.lin@rock-chips.com> mmc: dwmmc: Add stride PIO for better burst mode support
This patch enables stride PIO for better burst mode
support on some rockchip platforms, for instance rk3128,
etc. It uses ldm and stm to make multiple accessing from
CPU under some ARM architecture.
Design Note:
1) Carefully test it beyond the armv7(m) core since I don't
test them! If you disassemble the code, dwmci_memcpy_fromio
may be changed to use ldmia.w and stmia.w, as well as some
other optimization for push/pop stack operation, but they
are all fine!
2) Do *NOT* remove noinline and __volatile attributes as
you could fall into trouble by the optimization of GCC.
And please invent new attributes if you use *OTHER* compilers
which have their own keywords claiming the function to be a
"plase don't inline the function and please don't reorder the
groups".
3) If you want to use this feature for other rockchip platforms,
you could append new config in rockchip_dw_mmc.c. But now we only
have CONFIG_ROCKCHIP_RK3128 which means we just enable it for
rk312x platforms.
4) Stride PIO is determined by both of host->stride_pio and
the data payload. The intention of it is to make the block
accessing faster. So now only enable it for who's data payload
is larger(or equal to)than 512 Bytes.
5) MAX_STRIDE means we support burst MAX_STRIDE * 4 Bytes per
stride. Of course you could change that, but please read the
comment before it in the code and do it carefully.
How to test?
1) Prepare a memory, for instance, 0x70000000 on RK3126c.
=> mw 0x70000000 0x55aa55aa 0x200
2) Check it to see if 0x70000000 ~ 0x700000200 are all 0x55aa55aa
=> md 0x70000000 0x200
70000000: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000010: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000020: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000030: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
....
3) Fetch data of 0x70000000 ~ 0x700000200 and wrrite them to eMMC,
for instance, LBA 0x10000, and blk count is 1 as one blk means 0x200
bytes.
=> mmc write 0x70000000 0x10000 1
MMC write: dev # 0, block # 65536, count 1 ... 1 blocks written: OK
4) Clean the merory buffer and double check it
=> mw 0x70000000 0x0 0x200
=> md 0x70000000 0x200
70000000: 00000000 00000000 00000000 00000000 ................
70000010: 00000000 00000000 00000000 00000000 ................
70000020: 00000000 00000000 00000000 00000000 ................
....
5) Well, now let's read back the data from eMMC from the LBA
we wrote before.
=> mmc read 0x70000000 0x10000 1
MMC read: dev # 0, block # 65536, count 1 ... 1 blocks read: OK
6) We expect the 0x70000000 ~ 0x700000200 should be 0x55aa55aa instead
of 0x0 which is cleared by step 4).
=> md 0x70000000 0x200
70000000: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000010: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000020: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000030: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
....
Great, we see that the write and read eMMC are finished well and
the data payload is correct as expected!
Change-Id: I9b68c335449550b95f1a8f5841d46821346e45af
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
|
| /rk3399_rockchip-uboot/drivers/mmc/ |
| H A D | rockchip_dw_mmc.c | bda599f7c7d1023a9629cecf3fcb9d90c159c5f0 Mon Oct 09 09:51:29 UTC 2017 Shawn Lin <shawn.lin@rock-chips.com> mmc: dwmmc: Add stride PIO for better burst mode support
This patch enables stride PIO for better burst mode
support on some rockchip platforms, for instance rk3128,
etc. It uses ldm and stm to make multiple accessing from
CPU under some ARM architecture.
Design Note:
1) Carefully test it beyond the armv7(m) core since I don't
test them! If you disassemble the code, dwmci_memcpy_fromio
may be changed to use ldmia.w and stmia.w, as well as some
other optimization for push/pop stack operation, but they
are all fine!
2) Do *NOT* remove noinline and __volatile attributes as
you could fall into trouble by the optimization of GCC.
And please invent new attributes if you use *OTHER* compilers
which have their own keywords claiming the function to be a
"plase don't inline the function and please don't reorder the
groups".
3) If you want to use this feature for other rockchip platforms,
you could append new config in rockchip_dw_mmc.c. But now we only
have CONFIG_ROCKCHIP_RK3128 which means we just enable it for
rk312x platforms.
4) Stride PIO is determined by both of host->stride_pio and
the data payload. The intention of it is to make the block
accessing faster. So now only enable it for who's data payload
is larger(or equal to)than 512 Bytes.
5) MAX_STRIDE means we support burst MAX_STRIDE * 4 Bytes per
stride. Of course you could change that, but please read the
comment before it in the code and do it carefully.
How to test?
1) Prepare a memory, for instance, 0x70000000 on RK3126c.
=> mw 0x70000000 0x55aa55aa 0x200
2) Check it to see if 0x70000000 ~ 0x700000200 are all 0x55aa55aa
=> md 0x70000000 0x200
70000000: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000010: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000020: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000030: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
....
3) Fetch data of 0x70000000 ~ 0x700000200 and wrrite them to eMMC,
for instance, LBA 0x10000, and blk count is 1 as one blk means 0x200
bytes.
=> mmc write 0x70000000 0x10000 1
MMC write: dev # 0, block # 65536, count 1 ... 1 blocks written: OK
4) Clean the merory buffer and double check it
=> mw 0x70000000 0x0 0x200
=> md 0x70000000 0x200
70000000: 00000000 00000000 00000000 00000000 ................
70000010: 00000000 00000000 00000000 00000000 ................
70000020: 00000000 00000000 00000000 00000000 ................
....
5) Well, now let's read back the data from eMMC from the LBA
we wrote before.
=> mmc read 0x70000000 0x10000 1
MMC read: dev # 0, block # 65536, count 1 ... 1 blocks read: OK
6) We expect the 0x70000000 ~ 0x700000200 should be 0x55aa55aa instead
of 0x0 which is cleared by step 4).
=> md 0x70000000 0x200
70000000: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000010: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000020: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000030: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
....
Great, we see that the write and read eMMC are finished well and
the data payload is correct as expected!
Change-Id: I9b68c335449550b95f1a8f5841d46821346e45af
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
|
| H A D | dw_mmc.c | bda599f7c7d1023a9629cecf3fcb9d90c159c5f0 Mon Oct 09 09:51:29 UTC 2017 Shawn Lin <shawn.lin@rock-chips.com> mmc: dwmmc: Add stride PIO for better burst mode support
This patch enables stride PIO for better burst mode
support on some rockchip platforms, for instance rk3128,
etc. It uses ldm and stm to make multiple accessing from
CPU under some ARM architecture.
Design Note:
1) Carefully test it beyond the armv7(m) core since I don't
test them! If you disassemble the code, dwmci_memcpy_fromio
may be changed to use ldmia.w and stmia.w, as well as some
other optimization for push/pop stack operation, but they
are all fine!
2) Do *NOT* remove noinline and __volatile attributes as
you could fall into trouble by the optimization of GCC.
And please invent new attributes if you use *OTHER* compilers
which have their own keywords claiming the function to be a
"plase don't inline the function and please don't reorder the
groups".
3) If you want to use this feature for other rockchip platforms,
you could append new config in rockchip_dw_mmc.c. But now we only
have CONFIG_ROCKCHIP_RK3128 which means we just enable it for
rk312x platforms.
4) Stride PIO is determined by both of host->stride_pio and
the data payload. The intention of it is to make the block
accessing faster. So now only enable it for who's data payload
is larger(or equal to)than 512 Bytes.
5) MAX_STRIDE means we support burst MAX_STRIDE * 4 Bytes per
stride. Of course you could change that, but please read the
comment before it in the code and do it carefully.
How to test?
1) Prepare a memory, for instance, 0x70000000 on RK3126c.
=> mw 0x70000000 0x55aa55aa 0x200
2) Check it to see if 0x70000000 ~ 0x700000200 are all 0x55aa55aa
=> md 0x70000000 0x200
70000000: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000010: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000020: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000030: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
....
3) Fetch data of 0x70000000 ~ 0x700000200 and wrrite them to eMMC,
for instance, LBA 0x10000, and blk count is 1 as one blk means 0x200
bytes.
=> mmc write 0x70000000 0x10000 1
MMC write: dev # 0, block # 65536, count 1 ... 1 blocks written: OK
4) Clean the merory buffer and double check it
=> mw 0x70000000 0x0 0x200
=> md 0x70000000 0x200
70000000: 00000000 00000000 00000000 00000000 ................
70000010: 00000000 00000000 00000000 00000000 ................
70000020: 00000000 00000000 00000000 00000000 ................
....
5) Well, now let's read back the data from eMMC from the LBA
we wrote before.
=> mmc read 0x70000000 0x10000 1
MMC read: dev # 0, block # 65536, count 1 ... 1 blocks read: OK
6) We expect the 0x70000000 ~ 0x700000200 should be 0x55aa55aa instead
of 0x0 which is cleared by step 4).
=> md 0x70000000 0x200
70000000: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000010: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000020: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
70000030: 55aa55aa 55aa55aa 55aa55aa 55aa55aa .U.U.U.U.U.U.U.U
....
Great, we see that the write and read eMMC are finished well and
the data payload is correct as expected!
Change-Id: I9b68c335449550b95f1a8f5841d46821346e45af
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
|