The retu device node doesn't have a vendor prefix
in its compatible string, fix it by adding one.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
It's not correct to encode the subsystem in the I2C device name, so
drop the -mfd suffix. To maintain bisect-ability, change driver and
platform code / DTS users in the same patch.
Suggested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This patch fixes the following DTC warnings:
"Node /memory has a reg or ranges property, but no unit name"
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch fixes the following DTC warnings:
"i2c@0 has a unit name, but no reg property"
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Many OMAP2+ DTS are not using the defined constants to express
the GPIO polarity. Replace these so the DTS are easier to read.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The GPMC binding is obviously very confusing as the values
are all over the place. People seem to confuse the GPMC partition
size for the chip select, and the device IO size within the GPMC
partition easily.
The ranges entry contains the GPMC partition size. And the
reg entry contains the size of the IO registers of the
device connected to the GPMC.
Let's fix the issue according to the following table:
Device GPMC partition size Device IO size
connected in the ranges entry in the reg entry
NAND 0x01000000 (16MB) 4
16550 0x01000000 (16MB) 8
smc91x 0x01000000 (16MB) 0xf
smc911x 0x01000000 (16MB) 0xff
OneNAND 0x01000000 (16MB) 0x20000 (128KB)
16MB NOR 0x01000000 (16MB) 0x01000000 (16MB)
32MB NOR 0x02000000 (32MB) 0x02000000 (32MB)
64MB NOR 0x04000000 (64MB) 0x04000000 (64MB)
128MB NOR 0x08000000 (128MB) 0x08000000 (128MB)
256MB NOR 0x10000000 (256MB) 0x10000000 (256MB)
Let's also add comments to the fixed entries while at it.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
By moving i2c devices to DT we can clean up
i2c_board_info and fix a problem with moving
INTC to irq domain where IRQs can be renumbered
on each boot.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add minimal device tree support for n8x0 boards so we
can make omap2 device tree only. Note that we still need
to initialize various platform data quirks to keep
things working until n8x0 drivers support device tree.
Here's a rough todo list for the people using n8x0:
1. Update menelaus for device tree and set up
regulators at least for the MMC driver
2. Remove the MMC regulator platform data callback
by using the Menlaus regulators directly in the
driver passed from the .dts file
3. Update GPMC connected devices for onenand and
tusb6010 for device tree
We're planning to remove all legacy platform data
for mach-omap2 over next few merge cycles, so if
people are still using n8x0, please fix the issues
above.
Cc: devicetree@vger.kernel.org
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
