Commit 7800064b ("ARM: dts: Add basic dm816x device tree
configuration") added basic devices for dm816x, but I was not able
to test the GPIO interrupts earlier until I found some suitable pins
to test with. We can mux the MMC card detect and write protect pins
from SD_SDCD and SD_SDWP mode to use a normal GPIO interrupts that
are also suitable for the MMC subsystem.

This turned out several issues that need to be fixed:

- I set the GPIO type wrong to be compatible with omap3 instead
  of omap4. The GPIO controller on dm816x has EOI interrupt
  register like omap4 and am335x.

- I got the GPIO interrupt numbers wrong as each bank has two
  and we only use one. They need to be set up the same way as
  on am335x.

- The gpio banks are missing interrupt controller related
  properties.

With these changes the GPIO interrupts can be used with the
MMC card detect pin, so let's wire that up. Let's also mux all
the MMC lines for completeness while at it.

For the first GPIO bank I tested using GPMC lines temporarily
muxed to GPIOs on the dip switch 10.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Matthijs van Duin <matthijsvanduin@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 7800064b ("ARM: dts: Add basic dm816x device tree
configuration") added basic devices for dm816x, but I was not able
to test the USB completely because of an unconfigured USB phy, and
I only tested it to make sure the Mentor chips are detected and
clocked without a phy.

After testing the USB with actual devices I noticed a few issues
that should be fixed to avoid confusion:

- The USB id pin on dm8168-evm is hardwired and can be changed
  only by software. As there are two USB-A type connectors, let's
  start both in host mode instead of otg.

- The Mentor core is configured in such a way on dm8168-evm that
  it's not capable of multipoint at least on revision c board
  that I have.

- We need ranges for the syscon to properly set up the phy as
  children of the SCM syscon area.

- Let's not disable the second interface, the board specific
  dts files can do that if really needed. Most boards should
  just keep it enabled to ensure the device is idled properly.

Note that also a phy and several musb fixes are still needed to
make the USB to work properly in addition to this fix.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This allows booting the device with basic functionality.

Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.

Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:

http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>