| Message ID | 20170619171131.185337-11-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Simon Glass |
| Headers | show |
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@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? Thanks, Maxime
Hi Maxime, On 21 June 2017 at 01:31, Maxime Ripard <maxime.ripard@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@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. 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? Regards, Simon
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@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@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. Maxime
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@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@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. Maxime
Hi Maxime, On 5 July 2017 at 14:14, Maxime Ripard <maxime.ripard@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@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@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? Regards, Simon
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@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@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@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. Maxime
Hi Maxime, On 17 July 2017 at 03:26, Maxime Ripard <maxime.ripard@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@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@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@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
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? Please correct me if I miss something obvious. Regards, Suneel On Thu, Jul 27, 2017 at 9:19 PM, Simon Glass <sjg@chromium.org> wrote: > Hi Maxime, > > On 17 July 2017 at 03:26, Maxime Ripard > <maxime.ripard@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@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@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@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
On Thu, Jul 27, 2017 at 10:19:44PM -0600, Simon Glass wrote: > Hi Maxime, > > On 17 July 2017 at 03:26, Maxime Ripard > <maxime.ripard@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@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@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@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. That works for me. Maxime
Hi Suneel, On 27 July 2017 at 23:03, Suneel Garapati <suneelglinux@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@chromium.org> wrote: >> Hi Maxime, >> >> On 17 July 2017 at 03:26, Maxime Ripard >> <maxime.ripard@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@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@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@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
On Fri, 28 Jul 2017 18:08:31 +0200 Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > On Thu, Jul 27, 2017 at 10:19:44PM -0600, Simon Glass wrote: > > Hi Maxime, > > > > On 17 July 2017 at 03:26, Maxime Ripard > > <maxime.ripard@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@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@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@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. You can check how this is done for USB FEL boot. Basically, we set an environment variable if we see that the boot source is FEL: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=af654d14613f22f4910601d86e584030ee392b94 And then check this environment variable from bootcmd: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=f3b589c09b43a231706f11ab391e5ea7f9670f12 This can be done in a pretty much the same way for eMMC. Or maybe even generalized to also use this for different boot sources and non-sunxi SoCs. > > > > Well in that case let's drop the hack and someone will pick it up when > > it hits them. > > That works for me. Deliberately breaking something just to see if some end user runs into troubles, wastes time to bisect the problem and comes up with a fix looks like a dick move.
Hi Simon, On Fri, Jul 28, 2017 at 11:44 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Suneel, > > On 27 July 2017 at 23:03, Suneel Garapati <suneelglinux@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. 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@chromium.org> wrote: >>> Hi Maxime, >>> >>> On 17 July 2017 at 03:26, Maxime Ripard >>> <maxime.ripard@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@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@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@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
Hi Suneel, On 28 July 2017 at 15:34, Suneel Garapati <suneelglinux@gmail.com> wrote: > Hi Simon, > > > On Fri, Jul 28, 2017 at 11:44 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Suneel, >> >> On 27 July 2017 at 23:03, Suneel Garapati <suneelglinux@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@chromium.org> wrote: >>>> Hi Maxime, >>>> >>>> On 17 July 2017 at 03:26, Maxime Ripard >>>> <maxime.ripard@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@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@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@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
Hi Siarhei, On Fri, Jul 28, 2017 at 11:15:44PM +0300, Siarhei Siamashka wrote: > On Fri, 28 Jul 2017 18:08:31 +0200 > Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > > > On Thu, Jul 27, 2017 at 10:19:44PM -0600, Simon Glass wrote: > > > Hi Maxime, > > > > > > On 17 July 2017 at 03:26, Maxime Ripard > > > <maxime.ripard@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@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@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@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. > > You can check how this is done for USB FEL boot. Basically, we set an > environment variable if we see that the boot source is FEL: > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=af654d14613f22f4910601d86e584030ee392b94 > > And then check this environment variable from bootcmd: > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=f3b589c09b43a231706f11ab391e5ea7f9670f12 > > This can be done in a pretty much the same way for eMMC. Or maybe even > generalized to also use this for different boot sources and non-sunxi > SoCs. That looks like a good solution, we'll give it a shot. Thanks! Maxime
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 23bef94f24..8886e351f0 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -9,6 +9,7 @@ */ #include <common.h> +#include <dm.h> #include <errno.h> #include <malloc.h> #include <mmc.h> @@ -19,14 +20,21 @@ #include <asm/arch/mmc.h> #include <asm-generic/gpio.h> +struct sunxi_mmc_plat { + struct mmc_config cfg; + struct mmc mmc; +}; + struct sunxi_mmc_priv { unsigned mmc_no; uint32_t *mclkreg; unsigned fatal_err; + struct gpio_desc cd_gpio; /* Change Detect GPIO */ struct sunxi_mmc *reg; struct mmc_config cfg; }; +#if !CONFIG_IS_ENABLED(DM_MMC) /* support 4 mmc hosts */ struct sunxi_mmc_priv mmc_host[4]; @@ -83,6 +91,7 @@ static int mmc_resource_init(int sdc_no) return ret; } +#endif static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz) { @@ -224,6 +233,7 @@ static int sunxi_mmc_set_ios_common(struct sunxi_mmc_priv *priv, return 0; } +#if !CONFIG_IS_ENABLED(DM_MMC) static int sunxi_mmc_core_init(struct mmc *mmc) { struct sunxi_mmc_priv *priv = mmc->priv; @@ -234,6 +244,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc) return 0; } +#endif static int mmc_trans_data_by_cpu(struct sunxi_mmc_priv *priv, struct mmc *mmc, struct mmc_data *data) @@ -408,6 +419,7 @@ out: return error; } +#if !CONFIG_IS_ENABLED(DM_MMC) static int sunxi_mmc_set_ios_legacy(struct mmc *mmc) { struct sunxi_mmc_priv *priv = mmc->priv; @@ -488,3 +500,125 @@ struct mmc *sunxi_mmc_init(int sdc_no) return mmc_create(cfg, mmc_host); } +#else + +static int sunxi_mmc_set_ios(struct udevice *dev) +{ + struct sunxi_mmc_plat *plat = dev_get_platdata(dev); + struct sunxi_mmc_priv *priv = dev_get_priv(dev); + + return sunxi_mmc_set_ios_common(priv, &plat->mmc); +} + +static int sunxi_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd, + struct mmc_data *data) +{ + struct sunxi_mmc_plat *plat = dev_get_platdata(dev); + struct sunxi_mmc_priv *priv = dev_get_priv(dev); + + return sunxi_mmc_send_cmd_common(priv, &plat->mmc, cmd, data); +} + +static int sunxi_mmc_getcd(struct udevice *dev) +{ + struct sunxi_mmc_priv *priv = dev_get_priv(dev); + + if (dm_gpio_is_valid(&priv->cd_gpio)) + return dm_gpio_get_value(&priv->cd_gpio); + + return 1; +} + +static const struct dm_mmc_ops sunxi_mmc_ops = { + .send_cmd = sunxi_mmc_send_cmd, + .set_ios = sunxi_mmc_set_ios, + .get_cd = sunxi_mmc_getcd, +}; + +static int sunxi_mmc_probe(struct udevice *dev) +{ + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); + struct sunxi_mmc_plat *plat = dev_get_platdata(dev); + struct sunxi_mmc_priv *priv = dev_get_priv(dev); + struct mmc_config *cfg = &plat->cfg; + struct ofnode_phandle_args args; + u32 *gate_reg; + int bus_width, ret; + + cfg->name = dev->name; + bus_width = dev_read_u32_default(dev, "bus-width", 1); + + cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34; + cfg->host_caps = 0; + if (bus_width == 8) + cfg->host_caps |= MMC_MODE_8BIT; + if (bus_width >= 4) + cfg->host_caps |= MMC_MODE_4BIT; + cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS; + cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT; + + cfg->f_min = 400000; + cfg->f_max = 52000000; + + priv->reg = (void *)dev_read_addr(dev); + + /* We don't have a sunxi clock driver so find the clock address here */ + ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0, + 1, &args); + if (ret) + return ret; + priv->mclkreg = (u32 *)ofnode_get_addr(args.node); + + ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0, + 0, &args); + if (ret) + return ret; + gate_reg = (u32 *)ofnode_get_addr(args.node); + setbits_le32(gate_reg, 1 << args.args[0]); + priv->mmc_no = args.args[0] - 8; + + ret = mmc_set_mod_clk(priv, 24000000); + if (ret) + return ret; + + /* This GPIO is optional */ + if (!gpio_request_by_name(dev, "cd-gpios", 0, &priv->cd_gpio, + GPIOD_IS_IN)) { + int cd_pin = gpio_get_number(&priv->cd_gpio); + + printf("cd_pin = %d\n", cd_pin); + sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP); + } + + upriv->mmc = &plat->mmc; + + /* Reset controller */ + writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl); + udelay(1000); + + return 0; +} + +static int sunxi_mmc_bind(struct udevice *dev) +{ + struct sunxi_mmc_plat *plat = dev_get_platdata(dev); + + return mmc_bind(dev, &plat->mmc, &plat->cfg); +} + +static const struct udevice_id sunxi_mmc_ids[] = { + { .compatible = "allwinner,sun5i-a13-mmc" }, + { } +}; + +U_BOOT_DRIVER(sunxi_mmc_drv) = { + .name = "sunxi_mmc", + .id = UCLASS_MMC, + .of_match = sunxi_mmc_ids, + .bind = sunxi_mmc_bind, + .probe = sunxi_mmc_probe, + .ops = &sunxi_mmc_ops, + .platdata_auto_alloc_size = sizeof(struct sunxi_mmc_plat), + .priv_auto_alloc_size = sizeof(struct sunxi_mmc_priv), +}; +#endif
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@chromium.org> --- drivers/mmc/sunxi_mmc.c | 134 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 134 insertions(+)