[U-Boot] MMC driver questions

[U-Boot] MMC driver questions

[Aaron Williams]

Hi all,

I'm working on a eMMC/SD driver for our Thunder ARMv8 SoCs by porting 
the MIPS driver I wrote earlier but I'm running into some issues and 
have some comments.

First of all, our SoC performs a number of high-level operations in 
hardware which are not supported by the U-Boot model. The biggest issue 
is how we handle data transfers. We do not support sending CMD12 to stop 
a transmission and instead rely on CMD23 for multi-sector transfers. The 
mmc_read_blocks/mmc_write_blocks functions don't work with our hardware. 
For our Octeon SoC I basically had to replicate everything in mmc.c for 
our SoC and replace all of the functionality. I am wondering if this is 
considered acceptable because our hardware just does not fit the U-Boot 
MMC driver model very well. I also ran into a lot of issues with 
sd_send_op_cond/mmc_send_op_cond. Our SoC hardware also automatically 
handles things like polling the status. It would be nice if most or all 
of the functions inside mmc.c could be overridden by the driver.

Also, our MMC controller shows up as a PCI device but the single PCI 
device can handle up to four MMC slots using the same registers. The 
probe support does not allow for this. There can be multiple PCI devices 
as well in our NUMA configurations, with one PCI device per SoC.

-Aaron
-- 

Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198  (510) 789-8988 (cell)

[U-Boot] MMC driver questions

[Jaehoon Chung]

Hi Aaron,

On 10/13/2016 03:23 PM, Aaron Williams wrote:
> Hi all,
> 
> I'm working on a eMMC/SD driver for our Thunder ARMv8 SoCs by porting the MIPS driver I wrote earlier but I'm running into some issues and have some comments.
> 
> First of all, our SoC performs a number of high-level operations in hardware which are not supported by the U-Boot model. The biggest issue is how we handle data transfers. We do not support sending CMD12 to stop a transmission and instead rely on CMD23 for multi-sector transfers. The mmc_read_blocks/mmc_write_blocks functions don't work with our hardware. For our Octeon SoC I basically had to replicate everything in mmc.c for our SoC and replace all of the functionality. I am wondering if this is considered acceptable because our hardware just does not fit the U-Boot MMC driver model very well. I also ran into a lot of issues with sd_send_op_cond/mmc_send_op_cond. Our SoC hardware also automatically handles things like polling the status. It would be nice if most or all of the functions inside mmc.c could be overridden by the driver.

If CMD12 didn't support on your SoC, it should be just used CMD23. (or just use only single block read/write.)
But as you mentioned, it needs to implement for your SoC..(It should be split to driver for yours.)
Because it's not supported on u-boot mainline.
(As i know, u-boot-mmc didn't support the pre-defined read/write about normal case.)

There is a problem..when error is occurred..because it can't send the stop command..

Well..pre-defined concept can be applied on u-boot, but other things need to discuss about applying on u-boot.

I want to know how handles things like polling the status..?
If then don't need to send continuously for sd/mmc_op_cond...just return and waiting for completing..?

> 
> Also, our MMC controller shows up as a PCI device but the single PCI device can handle up to four MMC slots using the same registers. The probe support does not allow for this. There can be multiple PCI devices as well in our NUMA configurations, with one PCI device per SoC.

This also needs to make the slot concept..but slot concept should not be good thing.
And u-boot is running only one thread..so i think it's similar to using 4 IPs..

If you want to discuss about this more..i will check more..how we improve this. :)

Anyway..I'm checking my other tasks..After finishing mine..i will reply more things.

Best Regards,
Jaehoon Chung

> 
> -Aaron