This bases on a patch by Fabio Estevam who added the device before it
was allocated dynamically.
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
While adapting the #defines for this I noticed that the offset
used for USB HS on i.MX35 differs from the documented offset.
I kept the working offset and commented that the documentation
differs.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Compared to the static devices the dynamic have a DMA resource.
This should be save as it seems unused in the driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Some usages of ARCH_MX25 are assuming that if it is
defined the other SoCs are undefined. Use SOC_IMX25 for the save
places.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This way FB_IMX can just depend on HAVE_FB_IMX and machines
just need to select IMX_HAVE_PLATFORM_IMX_FB without bothering
about HAVE_FB_IMX.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The mxc-keypad device seems to be the result of an early and partial
merge of the keypad driver. It's unused and there is no corresponding
driver available, so just remove it.
Cc: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
To use common macros to define the gpio ports for imx{1,21,25,27} the
existing ones had to made more general and a few more base address defines
were necessary.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
According to the reference manual of the i.MX25 the host controller uses an
offset of 0x200 not 0x400 as was specified in the resources for mxc_usbh2.
Needs-Testing: yes
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This function should be marked as __init because it is used only
in the init phase.
This fix the compiler warning:
LD arch/arm/mach-mx3/built-in.o
WARNING: arch/arm/mach-mx3/built-in.o(.text+0x1328): Section mismatch in reference from the function eet_init_devices() to the (unknown reference) .init.rodata:(unknown)
The function eet_init_devices() references
the (unknown reference) __initconst (unknown).
This is often because eet_init_devices lacks a __initconst
annotation or the annotation of (unknown) is wrong.
Signed-off-by: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Group soc specific data in a global struct instead of repeating it for each
call to imxXX_add_flexcanX. The structs holding the actual data are placed
in .init.constdata and so don't do much harm. Compared to the previous
approach this reduces code size to call imx_add_flexcan.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Currently there is no platform data used in the driver. In case this
changes and for consistency NULL is passed unused to the soc specific
functions.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Currently there is no platform data used in the driver. In case this
changes NULL is passed unused to the soc specific functions.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Now only the virtual addresses [0xf4000000, 0xf5ffffff] are used for
static per-SoC mappings. The few mappings of whole chip selects are
moved accordingly.
The now wrong defines for virtual base addresses are removed.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This allows changing the mapping without the need to adapt all users.
While at it remove some unneeded casts to void __iomem *, this is already
taken care for in the IO_ADDRESS macros
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
