[PATCH v4 3/6] ARM: vexpress: Add DT support for the motherboard

On Thursday 08 December 2011, Pawel Moll wrote:

On Wed, 2011-12-07 at 22:49 +0000, Arnd Bergmann wrote:

quoted

On Tuesday 06 December 2011 15:43:46 Pawel Moll wrote:

quoted

+
+static struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
+       OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash",
+                       &v2m_flash_data),
+       OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
+       {}
+};

One more thing I noticed. While I'm not familiar with the progress on
device driver conversion, 

I'm aware of these two last non-DT bits and actually already started
working on them, but this won't happen this year (I'm on holiday
starting next Friday without any access to Internet whatsoever :-)

Ok, fine with me. Let's make sure we get everything else ready for 3.3
then.

quoted

I think you should be using the physmap_of
driver instead of physmap, which will remove the need for the
platform data.

There's one bit missing in the physmap_of. The "set_vpp" handle which is
used on VE:

static struct physmap_flash_data v2m_flash_data = {
        .width          = 4,
        .set_vpp        = v2m_flash_set_vpp,
};      

My plan is to extend the physmap_of driver so it could operate VPP via
gpio API and make the sysreg a gpio controller, having Flash VPP, CF &
MMC card detects and DVI output control (that's for CLCD) as internal
GPIO lines.

quoted

For mmci, it should not be hard to do change the driver so it
understands the device tree, too. The easiest implementation for
that would be to add some code into mmci_probe and allocate
an mmci_platform_data structure that gets filled with the required
attributes.

I've started the implementation already, but it turned out much trickier
that I was hoping... One thing is the "status" handle (card detect line
"virtual gpio" I mentioned above), the second problem is the fact that
mmci platform data can take generic caps MMC_CAP_* from
include/linux/mmc/host.h (now even caps2 as well)... This issue was
already briefly mentioned here:
http://article.gmane.org/gmane.linux.kernel.samsung-soc/7639 and as
there was no generic resolution my plan is to reuse as much properties
from other MMC host controllers and forge the missing one (as a superset
of ARM's and STE's cell implementations). But as I said, it's unlikely
to happen this year...

I see. Thanks for the explanation.

	Arnd