This is used on all board of our system, so again this is done in the
mx31moboard.c file.
changes since v2: call to gpio_request added in platform code, and
moved device initialization in baseboard files.
changes since v1: pins are claimed in another patch
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
In order to use the gpiolib, we now have to call gpio_request in
the plaform code since it is not done in iomux code anymore.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Since iomux code is not directly related to gpio on mx31, the calls
to gpio_request are removed from iomux.c file.
These calls have to be done in platform initialization files. The
name of the singe pin call for iomux is also changed to
mxc_iomux_alloc_pin.
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Add OTG device definition and resources to i.MX31 and a pure USB device mode
support to the pcm037 board.
Signed-off-by: Guennadi Liakhovetski <lg@denx.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This patch adds the SMSC platform device to the Litekit board.
Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This support both sdhc1 and sdhc2 with WP and CD for the marxbot and
devboard mx31moboard baseboards.
sdhc2 is present on both, but is not directly included in the
mx31moboard file because a third baseboard (not supported yet) without
sdhc2 is planned.
Changes since v1: removed pin initialization from init/exit function and
taken different comments into account
Changes since v2: pin initialiation now is done in another patch for all
current mx31moboard pins
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Changes since v1: all the pins needed for the drivers are claimed in
another patch
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
As suggested by Sascha, here we setup all the pins that we are using in
the current (and currently reviewed) drivers for mx31moboard system.
changes since v1: changed I2C1 pin names
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This hw-random driver add support to RNGA hardware found
on some i.MX processors.
Signed-off-by: Alan Carvalho de Assis <acassis@gmail.com>
Acked-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Various improvements (includes in alphabetical order, platform devices
declaration order change, ...)
The pins now are claimed in a single function call from a main table for
every board for a better clarity and to adopt the current agreement for
mx31 devices.
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This allows us to have more mapping functions for more than one
i.MX architecture in the kernel. As this is the earliest board
specific hook we have, also use it to set the cpu type.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
It is no longer present in newer cores. Unfortunately Freescale decided
to put the bit which decides between automotive clock path and consumer
clock path in the automotive clock path direction. With current code we
cannot detect the core revision, so just remove automotive path completely.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This iomux is called iomux-v3 in the tree because it is the third known
incarnation of MXC iomuxers. It is not only found on the MX35 but also
on the MX51 and probably others.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
AIPS[12] are no mapped from generic MX3 code so we don't need to
map them from machine-specific map_io function anymore.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
With the i.MX31 transition to clkdev clock names have changed, but mistakenly
the "mx3-camera.0" has been registered with a non-NULL connection ID, which is
not necessary, since this is the only clock, used by the capture interface
driver. Fix the clock definition and the driver to use NULL as a connection ID.
Signed-off-by: Guennadi Liakhovetski <lg@denx.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Updated to also specify SMSC911X_FORCE_INTERNAL_PHY, as the external phy
detection hardware strap is incorrectly pulled high on this platform.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
This patch adds basic support for Dave/DENX QongEVB-LITE i.MX31-based
board. It includes support for clocks initialization, UART1, NOR-flash,
FPGA-attached NAND flash and DNET ethernet controller (inside FPGA).
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This patch adds clkdev support for i.MX31. This is done in a
similar way done previously for i.MX27
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
On MX31 we can't do much without mapping the AIPS1/2 register space.
Move these mappings from individual boards to plat-mxc/mm.c
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The i.MX35 basically features the same peripherals as the i.MX31 with
some differences:
- The i.MX35 has a FEC ethernet controller
- The NAND controller base addresses are different
- The i.MX35 has only 3 UARTs
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This patch adds clock support for i.MX35 SoCs. We do not support setting
of clock rates yet, but most interesting clock rates should be reported.
I couldn't test all clock rates and the datasheet contains some obvious
bugs, so expect some bugs in this code.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We had hardcoded cpu_is_ macros for mxc architectures till now. As we
want to run the same kernel on i.MX31 and i.MX35 this patch adds cpu_is_
macros which expand to 0 or 1 if only one architecture is compiled in and
only check for the cpu type if more than one architecture is compiled
in.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This adds the dma (ipu_dma) and fb devices for the mx31 for which drivers now are
available.
v2: merge the ipu and fb device in the same patch as suggested by Sascha
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This enables our mx31moboard to be used on the different baseboards that
we are developping according to the application needs. There are not
many differences between the boards for now, but when other peripherals
are available for mx31 the differences are going to grow.
v2: takes Sascha's comments into account
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The i.MX31ADS supports pluggable PMU modules, including the WM835x based
Wolfson Microelectronics 1133-EV1. These boards provide power, audio,
RTC and watchdiog services to the system. This patch adds initial support
for those boards in I2C mode.
Currently support is limited by the available support for the features
of the i.MX31 in the mainline kernel. Some further work will be needed
once other PMU modules are supported and once there is SPI support.
Many of the regulator constraints will be sharable with other PMU
boards.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This example takes advantage of the possibility to use tables of iomux
configs.
This is inspired from mx1-mx2 iomux code. It allows a better code
readability.
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This new implemenatation avoids that two physical pins are claimed by
the same driver (also with the the gpr hardware modes).
The gpio kernel lib is also called when a capable gpio pin is assigned
its gpio function.
The mxc_iomux_mode function is still here for backward compatibility but
should not be used anymore.
V2:
In the precendent revision, the iomux code was claiming a pin when its
hardware mode was changed. This was uncorrect: when the hardware mode is
changed, the pin must still be claimed through the iomux.
In order to have a pin working in mode hw2, we must fist issue the
mxc_iomux_set_gpr call and then the corresponding mxc_iomux_mode calls
with the FUNC mode (usually done with mxc_iomux_setup_multiple_pins).
The reverse calls must be done to fee the pins.
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
