On Mon, 8 Jul 2019 at 19:33, Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> wrote: > > WiP - only partially working - see performance numbers. > > Odroid-C1 eMMC (HS-200): > Amlogic's vendor driver @ Linux 3.10: > 7781351936 bytes (7.8 GB) copied, 134.714 s, 57.8 MB/s > This driver: > 7781351936 bytes (7.8 GB, 7.2 GiB) copied, 189.02 s, 41.2 MB/s > > EC-100 eMMC (HS MMC): > Amlogic's vendor driver @ Linux 3.10: > 15762194432 bytes (16 GB) copied, 422.967 s, 37.3 MB/s > This driver: > 15762194432 bytes (16 GB, 15 GiB) copied, 9232.65 s, 1.7 MB/s > > 1) Amlogic's vendor driver does some magic with the divider: > clk_div = input_rate / clk_ios - !(input_rate%clk_ios); > if (!(clk_div & 0x01)) // if even number, turn it to an odd one > clk_div++; > It's not clear to me whether what the reason behind this is, what is > supposed to be achieved with this? > > 2) The hardcoded RX clock phases are taken from the vendor driver. It > seems that these are only valid when fclk_div3 is used as input > clock (however, there are four more inputs). It's not clear to me how > to calculate the RX clock phases in set_ios based on the input clock > and the ios rate. > > 3) The hardware supports a timeout IRQ but the max_busy_timeout is not > documented anywhere. > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> Martin, overall this looks good to me. Once you moved from RFC to a formal patch I will check again, of course. There are a couple of calls to readl_poll_timeout(), for different reasons, that I have some questions about, but we can discuss those in the next step. [...] Kind regards Uffe
