On Thursday 15 March 2012, Per Forlin wrote:

On Thu, Mar 15, 2012 at 4:32 PM, Arnd Bergmann [off-list ref] wrote:

quoted

On Thursday 15 March 2012, Lee Jones wrote:

quoted

quoted

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?

Right, the DMA configuration does not really belong in there, but
the voltage setup might (unless we convert that to the regulator
setup).

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.

Good idea, yes. We should also have a generic mmc binding document
that describes how to set flags like 8-bit mode. We already have
two conflicting variants in .dts files and we should make sure
we bring everybody back together here.

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.

Yes, thanks for the info. Doing this for 3.4 is definitely out of the
question then, and hopefully we can use the new dma bindings when it's
done for 3.5

	Arnd