[PATCH 0/5] MMC: mmci: Provide bindings for Device Tree

[Per Forlin]

On Thu, Mar 15, 2012 at 4:32 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 15 March 2012, Lee Jones wrote:
>> > I would like to see what the minimal required change is to support DT
>> > for mmci without factorization.
>> > 1. Minimal change in mmci.
>> > 2. Add mmci_dt.c which contains the DT-populate code.
>> >
>> > The factorization could be done as step 2 I think.
>> >
>> > What do you say?
>>
>> I'm wondering what the difference is as the work has already been done.
>>
>> It was Arnd's suggestion to separate out the two types of variants, and
>> I'm quite fond of the new (fully featured) layout.
>
> Right, I usually prefer cleanups or other refactoring to be done first, and
> then features added on top.
>
> You could in theory add have just patches 3/4/5 all applied without
> the refactoring, but that I would be worried that this causes dependencies
> between the mmci driver and ux500 specific functionality like the
> stedma40_filter function.
>
About DT
I think I need to catch up on the DT-design a bit. I will try to catch
up on the DT-implementation and maybe then the refactorization will
make sense to me :)

Board specific data in mmci-driver
The stedma40 filter function is not really specific for ux500. ux500
use stedma40 but it should be possible to replace this DMA.IP with
some other DMA-controller. This is board specific configuration. You
should not need to change the mmci-driver just because the dma-driver
has changed, right?
Or will the board-configuration now be placed in mmci-ux500?

Common DT populate code for all mmc host drivers
Some parts of the DT-population is common for all the host driver, for
instance setting the CAP and CAP2. This code should be moved to a
common place to be used by other host drivers as well.

About refactoring
There are numbers of patches stashed up for MMCI waiting for verdict
here http://git.kernel.org/?p=linux/kernel/git/linusw/linux-stericsson.git;a=shortlog;h=refs/heads/mmci.
If doing a refactorization please rebase it on top of these patches.
This needs to be done carefully, there may be more to considerations
than just DT. Maybe the timing is better to do this for 4.5, just
after 4.4 is closed. Then we can make sure that all new patches are
made on top of the refactorized base.

BR
Per