From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Sat, 19 Jan 2019 11:20:45 +0530 Subject: [U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC In-Reply-To: <20190118174839.456f35d5@donnerap.cambridge.arm.com> References: <20190117170951.23623-1-jagan@amarulasolutions.com> <20190118113335.4cf300d2@donnerap.cambridge.arm.com> <20190118121741.GL27429@bill-the-cat> <20190118123030.33c759a9@donnerap.cambridge.arm.com> <20190118174839.456f35d5@donnerap.cambridge.arm.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Jan 18, 2019 at 11:18 PM Andre Przywara wrote: > > On Fri, 18 Jan 2019 22:11:36 +0530 > Jagan Teki wrote: > > Hi, > > > On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara > > wrote: > > > > > > On Fri, 18 Jan 2019 07:17:41 -0500 > > > Tom Rini wrote: > > > > > > > On Fri, Jan 18, 2019 at 11:53:49AM +0000, Andre Przywara wrote: > > > > > On Thu, 17 Jan 2019 22:39:44 +0530 > > > > > Jagan Teki wrote: > > > > > > > > > > > V2 for previous version[1] changes, for enabling DM_MMC > > > > > > on Allwinner platform. > > > > > > > > > > So this is a neat and simple solution to the DM_MMC problem, to > > > > > the point where I am wondering why we actually need all those > > > > > DT driven clock and reset drivers in the first place. > > > > > But as I understand using plat data in this way is somewhat > > > > > frowned upon and considered deprecated (although it makes a lot > > > > > of sense in this context). > > > > > > > > > > Also, isn't this series independent from the clock gates/reset > > > > > patches? So why do you pile them on top of each other in > > > > > sunxi/next? > > > > > > > > > > If we really want to have the full featured DT driven clock and > > > > > reset support, why not use it together: > > > > > We keep the current mod clock support in the MMC driver, but > > > > > use the newly introduced clock gates and reset support via the > > > > > new clock driver, mostly replacing this series. This would give > > > > > us some test coverage of the new clock driver, while still > > > > > avoiding to rush the MMC mod clock implementation. > > > > > > > > > > Does that make sense? Happy to bake some patches for that on the > > > > > weekend. > > > > > > > > > > Btw: After talking to Tom on IRC, the DM_MMC deadline is > > > > > actually _after_ the 2019.04 release, so we don't need to have > > > > > DM_MMC support in this merge window. > > > > > > > > To be clearer, I plan to mark as BROKEN and start saying we're > > > > going to remove stuff that isn't migrated, after the release. So > > > > it would be good to get things moved this release that can be > > > > moved this release. Trying to use sunxi w/o MMC isn't going to be > > > > fun :) > > > > > > Understood. I just gave it a quick try and it is actually quite > > > easy: We are pretty good already regarding gate clocks and resets, > > > with the new DM_CLK driver (v2 on the list). And using them in > > > sunxi_mmc.c is a piece of cake and very clean. > > > We just need to keep the MMC mod clock hack in (which this series > > > here does as well), but can still enable DM_MMC. > > > And for the next merge window we can tackle this by implementing the > > > MMC mod clock properly in the clock driver, then replacing the hack > > > with the normal clk_get_by_name(); clk_set_rate(); sequence. > > > > I tried with ahb clock and reset, with v2 version of CLK series and > > it's straightforward. but mmc clock may take some time along with > > series of testing. So I just windup this, instead of making some noise > > at last minute. > > What do you mean with that, exactly? > Do you plan to take your platdata hack for 2019.04? > I don't like the idea of hacking something up that has no future and > will be reverted very soon anyway. Instead we should expose the > foundation part of the clock driver to people now for testing (as you > did by pushing it, thanks!), but including the MMC gates and resets. > I have this code ready, just need to test it on some SoCs this evening. > > I think taking this change is the best compromise between changing > not too many things at once, yet still exposing new code to the users > for testing. > > And yes, the MMC mod clock is somewhat of a beast, but if we have > just this in the next release, it should be easier to debug than when > we expose the whole of the new clock framework to MMC by then only. This is I was thinking too, in fact I have created next version wrt CLK support which may override your recent changes. May be I can prepare and by combining both. what do you say?