Fix the following warnings from dtc by adding the unit name to memory
nodes:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
Converted using the following command:
perl -p0777i -e 's/memory \{\n\t\treg = \<0x+([0-9a-f])/memory\@$1$\0000000 \{\n\t\treg = <0x$1/m' `find ./arch/arm/boot/dts -name "imx*"`
The files below were manually fixed:
-imx1-ads.dts
-imx1-apf9328.dts
-imx6q-pistachio.dts
Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The lcdif node has a property named "display" and also a child node
called "display", which causes the following warning:
device-tree: Duplicate name in lcdif@80030000, renamed to "display#1"
Rename the child node name in order to avoid the warning.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
The device tree specification recommends that generic name should be
used for nodes. So instead of naming those fixed regulator nodes
arbitrarily, let's use the generic name 'regulator@num' for those nodes.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Convert mx23/mx28 dts files to use the padconfig defintions from
mxs-pinfunc.h.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Convert mx23/mx28 dts filed to use the pinctrl header files.
NOTE: During automatic conversion of these files to use the pinconfig
definitions an inconsistency has been found in:
arch/arm/boot/dts/imx28-apx4devkit.dts
According to the comment the function for pad SSP2_SS0 should have
been MX28_PAD_SSP2_SS0__GPIO_2_19, while the given value 0x2131
represents: MX28_PAD_SSP2_SS0__AUART3_TX
I used the later (though probably wrong) definition because that's
what is actually being used in the DTB.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The i.MX23 has a internal Low Resolution ADC; this enables the support
for this device.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The i.MX23EVK board provides a USB port so the USB PHY and controller
need to be enabled for it to be usable.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Instead of using a custom binding for retrieving the GPIO that activates the
LCD from devicetree, use a standard regulator.
This approach has the advantage to be more generic.
For example: in the case of a board that has a PMIC supplying the LCD voltage,
the current approach would not work, as it only searches for a GPIO pin.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Move display timing configurations into device tree, so that the
auxdata for mxsfb driver can be killed.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Instead of assigning SSP1_DETECT inside mmc0_4bit_pins_a, let the board dts
handle this setup.
Not every board will use MX23_PAD_SSP1_DETECT as SSP1 functionality.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
hog_pins is used to setup the pin functions, and it is not neccesarily used only
for GPIO pins, so use only 'hog' to describe a more generic term.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The 8-bit mode mmc has pin conflicts with display. Let's use 4-bit
mode by default, so that display can be enabled together later.
Also add vmmc-supply for mmc device.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Before gpio_request can directly ask pinctrl system to configure the
requested pin into gpio mode, we use "hog" entry (pinctrl state of
pin controller itself) to configure gpios.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
It adds initial device tree support for imx23-evk board, and only
serial console is enabled.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Marek Vasut <marex@denx.de>
