Hi Suneel, On 28 July 2017 at 15:34, Suneel Garapati <suneelgli...@gmail.com> wrote: > Hi Simon, > > > On Fri, Jul 28, 2017 at 11:44 AM, Simon Glass <s...@chromium.org> wrote: >> Hi Suneel, >> >> On 27 July 2017 at 23:03, Suneel Garapati <suneelgli...@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 <s...@chromium.org> wrote: >>>> Hi Maxime, >>>> >>>> On 17 July 2017 at 03:26, Maxime Ripard >>>> <maxime.rip...@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.rip...@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.rip...@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 <s...@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@lists.denx.de >>>> https://lists.denx.de/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
