[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[André Przywara]

On 19/01/2019 05:50, Jagan Teki wrote:
> On Fri, Jan 18, 2019 at 11:18 PM Andre Przywara <andre.przywara at arm.com> wrote:
>>
>> On Fri, 18 Jan 2019 22:11:36 +0530
>> Jagan Teki <jagan at amarulasolutions.com> wrote:
>>
>> Hi,
>>
>>> On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara
>>> <andre.przywara at arm.com> wrote:
>>>>
>>>> On Fri, 18 Jan 2019 07:17:41 -0500
>>>> Tom Rini <trini at konsulko.com> 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 <jagan at amarulasolutions.com> 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?

It's hard to say without seeing the code, but I think we should take it
easy, since I believe we have enough invasive changes for one release
already.

Given the sheer number of Allwinner boards that we change (142!)
compared to the number of boards that we can test ourselves we should be
more careful, thinking about the breakages we had in December alone.

What's in sunxi/master is probably in good shape, and together with the
part that enables MMC to use it we get rid of the warnings already, so I
think it's worth trying to push this into the 2019.04 release. This
relieves us from the pressure and allows to give the new clock framework
some testing.

And by running buildman I saw that we still get warnings about DM_VIDEO
(95 boards) and DM_SCSI (22 boards), so there is still enough work ahead.

So sure, let's share the code, but lets keep the changes as minimal as
possible. The MMC mod clock certainly isn't minimal.

Cheers,
Andre.