Re: [RESEND PATCH v7 1/2] mmc: OCTEON: Add DT bindings for OCTEON MMC controller

Matt Redfearn
2016-04-18T12:57:38Z

HI Ulf,

On 18/04/16 13:08, Ulf Hansson wrote:
> [...]
>
>>> Thanks for taking the time to reply and your detailed answer. I see why the bindings currently don't fit into the mmc core model. However, we still have the issue that these bindings are shipping in hardware and we can't change them. As far as I can see, ther major difference between these bindings and what is upstream, is the interpretation of the reg property, and the compatible string of what is connected to the controller. The Octeon MMC controller supports connections to up to 4 devices, either eMMC devices or SD card slots. I think it will be difficult to impossible to programatically interpret the device tree supplied by the bootloader to classify the slots as SD card / eMMC such that the necessary reg / compatible strings can be added.
>>> If we were to remove the slots entirely from the device tree, how would the core deal with having one controller with multiple devices attached? Obviously we need some locking of the shared controller between the child devices.
>> Currently the core doesn't deal with multiple card slots and I doubt
>> we ever will be adding that. The reason is simply because, in practice
>> there don't exist such configurations, even if some HWs supports it. I
>> assume that's the case here as well, right!?
>>
>> Kind regards
>> Uffe
>>
>> Hi Ulf,
>> Unfortunately not, for example the Rhinolabs UTM8 board which we have several of here (http://www.rhinolabsinc.com/rhino-sdna7130-networking-appliance/) contains an eMMC device attached to "slot 1" and a microSD card slot on "slot 2". The driver as it stands supports this board by registering an mmc host for each slot, and it is possible to use both devices while shaing the controller resources.
> I see! Are you sure you don't need any additional out of tree patch
> for the mmc core/block as well?

No, the driver applies to and works with unpatched upstream mmc core. It
create one mmc_host struct per slot and registers it though
mmc_add_host. Sharing the controller resources between slots is handled
within the driver.

>
> Moreover, of course these configurations suffers from poor
> performance, but I guess that's irrelevant for these systems!?

Indeed, the eMMC and SD are not typically used together, and if they
are, there's an explainable hardware performance limitation.

>
> Perhaps we can add specific DT property which tells about whether the
> childnode is a slot? Then you will have to patch your DTB during boot
> and add that information.

The DTB in currently shipping devices has a compatible property
"cavium,octeon-6130-mmc-slot" for each slot. Perhaps that would do? Or,
we could add a property such as "slot-num" rather than encoding this
information in the reg property?

Thanks,
Matt

>
> Or you have another suggestion?
>
> Kind regards
> Uffe