[U-Boot] [PATCH 10/14] dm: mmc: sunxi: Add support for driver model
Simon Glass
sjg at chromium.org
Fri Jul 28 18:44:53 UTC 2017
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?
>
> 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
More information about the U-Boot
mailing list