[U-Boot] [PATCH 10/14] dm: mmc: sunxi: Add support for driver model

Mon Jul 31 14:45:33 UTC 2017

Hi Suneel,

On 28 July 2017 at 15:34, Suneel Garapati <suneelglinux at gmail.com> wrote:
> Hi Simon,
>
>
> On Fri, Jul 28, 2017 at 11:44 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Suneel,
>>
>> On 27 July 2017 at 23:03, Suneel Garapati <suneelglinux at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> I have similar requirement of Cavium boards using two card slots on
>>> one host and currently trying to figure out to support it using
>>> DM_MMC.
>>> Would like to know if you have quick thoughts or seen similar use case
>>> with some other boards too?
>>
>> It should work correctly - what sort of problem do you have?
>
> Each mmc_bind call creates child blk_device and initialize the mmc
> structure with defaults and further mmc_init or driver_probe would set
> the rest of the members.
> For the case, one host and two card slots, assuming card slots put up
> as child nodes to mmc node in devicetree
>      - driver probe called for once on host, initiates only one
> mmc_bind call -> only one child blk device(udevice) created
>      - also 'struct mmc' includes card specific data cid csd scr rca
> which should scale for multiple slots simultaneously
>      - assuming boot up detects two cards on two slots, mmc dev 0 will
> chose host but not slot
>      - mmc_uclass_priv holds mmc reference but depending on slot it
> should get updated.
>      - maybe need to split mmc into mmc_host and mmc_card structures like Linux.
>
> Also, mmc dev 0/1 from cmd prompt would choose host and not the card slot.

I thought this thread was about switching between different MMC controllers...

OK, I see. I did not know that an MMC controller could support two
devices. How do you switch between slots? Does U-Boot have any support
for this at present?

It should be possible to add a second child device for MMC easily
enough. But there will need to be some changes, e.g.
mmc_get_blk_desc() will need an extra parameter with the slot number.

Regards,
Simon

>
> Please correct me.
>
> Regards,
> Suneel
>
>>
>>>
>>> Please correct me if I miss something obvious.
>>>
>>
>> Regards,
>> Simon
>>
>>> Regards,
>>> Suneel
>>>
>>>
>>> On Thu, Jul 27, 2017 at 9:19 PM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Maxime,
>>>>
>>>> On 17 July 2017 at 03:26, Maxime Ripard
>>>> <maxime.ripard at free-electrons.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Fri, Jul 14, 2017 at 07:47:45AM -0600, Simon Glass wrote:
>>>>>> On 5 July 2017 at 14:14, Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
>>>>>> > On Wed, Jul 05, 2017 at 04:57:40PM +0200, Maxime Ripard wrote:
>>>>>> >> On Tue, Jul 04, 2017 at 01:33:25PM -0600, Simon Glass wrote:
>>>>>> >> > Hi Maxime,
>>>>>> >> >
>>>>>> >> > On 21 June 2017 at 01:31, Maxime Ripard
>>>>>> >> > <maxime.ripard at free-electrons.com> wrote:
>>>>>> >> > > Hi Simon,
>>>>>> >> > >
>>>>>> >> > > On Mon, Jun 19, 2017 at 11:11:27AM -0600, Simon Glass wrote:
>>>>>> >> > >> Add a driver-model version of this driver which mostly uses the existing
>>>>>> >> > >> code. The old code can be removed once all boards are switched over.
>>>>>> >> > >>
>>>>>> >> > >> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>>>> >> > >
>>>>>> >> > > I'm not sure if you tested that, but we have some code that switches
>>>>>> >> > > the MMC indices when using both an eMMC and an external MMC.
>>>>>> >> > >
>>>>>> >> > > http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c#l494
>>>>>> >> > >
>>>>>> >> > > This predates my time, but it seems that it was done to have a
>>>>>> >> > > consistent boot MMC device ID.
>>>>>> >> > >
>>>>>> >> > > I'm not really sure we can get rid of it (even if it creates some
>>>>>> >> > > issues of it's own), but what would be the impact of a switch to the
>>>>>> >> > > device model on that logic?
>>>>>> >> >
>>>>>> >> > That is a pretty terrible hack.
>>>>>> >>
>>>>>> >> Yes, I know. This is especially bad when used together with other
>>>>>> >> tools that rely on one MMC index for example (such as fastboot).
>>>>>> >>
>>>>>> >> I wanted to kill it for quite some time, but I'm a bit reluctant due
>>>>>> >> to the possible side effects.
>>>>>> >>
>>>>>> >> > I'm not sure whether it will continue to work with DM. It does still
>>>>>> >> > use the device number in the block device, so maybe...  Do you have
>>>>>> >> > a board would use this?
>>>>>> >>
>>>>>> >> I guess I do. I'll give it a try or tonight and let you know.
>>>>>> >
>>>>>> > I just tested. Even with an eMMC (which was the first use case for
>>>>>> > that hack), it works, even things that are not mainline yet (fastboot,
>>>>>> > etc).
>>>>>> >
>>>>>> > It obviously break the old scripts relying on the mmc index, but I
>>>>>> > guess that's ok.
>>>>>> >
>>>>>> > There's one regression though. Our eMMC will always be the second one,
>>>>>> > which means that the distro bootargs will always boot on the external
>>>>>> > SD first (which is always going to be mmc0).
>>>>>> >
>>>>>> > That's due to the fact that the eMMC controller is the third one, and
>>>>>> > is thus probed last. We obviously want something deterministic for
>>>>>> > fastboot for example, but booting partitions of the media you started
>>>>>> > from make sense I guess. And this is what this hack was trying to
>>>>>> > address.
>>>>>>
>>>>>> OK...so what should we do here?
>>>>>
>>>>> I guess we should just drop the hack. We'll have to at some point
>>>>> anyway. But I guess we should also find a way to tweak the distro
>>>>> bootcmd at boot time to search for the medium that we booted on first.
>>>>>
>>>>> I'm not really sure how to do this though.
>>>>
>>>> Well in that case let's drop the hack and someone will pick it up when
>>>> it hits them.
>>>>
>>>> Regards,
>>>> Simon
>>>> _______________________________________________
>>>> U-Boot mailing list
>>>> U-Boot at lists.denx.de
>>>> https://lists.denx.de/listinfo/u-boot