| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add node to support the USB Host and the USB OTG on the IGEP AQUILA
Processor Board.
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The IGEP AQUILA EXPANSION has a 32KBit EEPROM for user data storage.
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Enable the user leds on the IGEP AQUILA EXPANSION. The has two leds,
one green and one red, that are controllable by software.
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Enable the hdmi output and the LCD Controller on IGEP AQUILA. Also
configure the correct pinmux for output of video data from the SoC
to the HDMI encoder.
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The IGEPv2 has a TFP410 DPI-to-DVI encoder attached to OMAP's
Display SubSystem (DSS).
Add mux setup for DSS pins and also for the GPIO 170 pin that
is used to ensure that the DVI-D is powered down on power up.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Add pin muxing support for IGEP boards i2c controllers.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Most of the boards are using the TI AM/DM37x processor, there is only a small
quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
omap36xx.dtsi include instead of omap34xx.dtsi include. We can add support
for the 34xx based variant later on as needed.
To avoid confusion we have added to the model the (TI AM/DM37x) comment.
Signed-off-by: Enric Balletbo i Serra <[email protected]>
[[email protected]: updated comments for the 34xx to 36xx include change]
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The LBEE1USJYC is a WiFi/BT combo module used on OMAP3-based IGEP boards. In
both cases, IGEPv2 Rev. C and IGEP COM MODULE, the module is connected using
the same MMC interface and uses the same GPIOs.
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Both, IGEPv2 and IGEP COM MODULE have a bus-width of 4 not 8, so fix this and
do not mux data pins from mmc1_data4 to mmc1_data7.
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
IGEP's DVI connector's DDC pins are connected to OMAP's third i2c bus.
When booting with Device Trees the requested bus number is set to -1
which means that the bus number should be dynamically assigned. So the
third i2c bus has 2 has a bus number.
Since now only DT booting is supported for IGEP boards after commit
06ff74fd ("ARM: OMAP2+: remove legacy support for IGEP boards"), the
i2c bus number has to be changed.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Enabling of Posted mode is seen to cause problems on dmtimer modules on AM33xx
(much like other OMAPs). Reference discussions on forums [1] [2]. Earlier
patch solving this on other OMAPs [3].
For OMAP SoCs with this errata, the fix has been to not enable Posted mode.
However, on some SoCs (atleast AM33xx) which carry this errata, Posted mode
is enabled on reset. So we not only need to ignore enabling of the POSTED bit
when the timer is requested, but also disable Posted mode if errata is present.
[1] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/285744.aspx
[2] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/270632.aspx
[3] http://www.spinics.net/lists/linux-omap/msg81770.html
Cc: [email protected]
Reported-by: Russ Dill <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Signed-off-by: Joel Fernandes <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into fixes
From Linus Walleij, Ux500 defconfig patches for the v3.13 rc series:
- Allow creation and mounting of devtmpfs, which is used
by OpenEmbedded root filesystems among others.
- Enable CPUidle for the ux500, it has been accidentally
disabled due to a Kconfig change.
* tag 'ux500-defconfig-v3.13-rcs' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
ARM: ux500: u8500_defconfig: add missing cpuidle option
u8500_defconfig: allow creation and mounting of devtmpfs
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into fixes
From Linus Walleij, Ux500 fixes for the v3.13 series:
- Restore platform data for the (e)MMC/SD controllers, so they can
pins and special flags properly like before.
* tag 'ux500-fixes-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
Revert "ARM: ux500: Stop passing MMC's platform data for Device Tree boots"
Revert "ARM: ux500: Remove AUXDATA relating to SDI (MMC) clock-name bindings"
|
|
This reverts commit 49c129519a7a8840767321c38d2eaf84a263529b.
The special settings for the SD/MMC card parameters that are not
yet fully agreed upon how to encode into the device tree went missing
with this commit. We need to first put it into the device tree,
and then remove the platform data.
Cc: Lee Jones <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This reverts commit ce16feb8510cbbcd090c2320c35db2fbbffde210.
This commit stopped tying down the name of the MMC/SD devices, but these
names are used in the pin control table, so the MMC/SD cards stopped
working.
Cc: Lee Jones <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
With the commit d3f2950f2adeea3da0317e952914b59adaa4cdb3, the option
ARM_U8500_CPUIDLE was added to the Kconfig but not reflected in the
default config file, hence the cpuidle driver is no longer enabled
since this commit.
Enable it again by adding the missing option in the default config file.
Signed-off-by: Daniel Lezcano <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This patch enables CONFIG_DETTMPFS and CONFIG_DEVTMPFS_MOUNT
flags for u8500 based devices.
In this way it's possible to create a tmpfs/ramfs already in the
early stages of the boot, allowing programs like udev/mdev to
populate the /dev directory.
Signed-off-by: Andi Shyti <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"Mostly bugfixes and a few small code removals. Worth pointing out is:
- A handful of more fixes to get DT enablement working properly on
OMAP, finding new breakage of things that don't work quite right
yet without the traditional board files. I expect a bit more of
this to come in this release as people test on their hardware.
- Implementation of power_down_finish() on vexpress, to make kexec
work and to stop the MCPM core to produce a warning (the warning
was new to 3.13-rc1).
- A handful of minor fixes for various platforms"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: bcm2835: add missing #xxx-cells to I2C nodes
ARM: dts: Add max77686 RTC interrupt to cros5250-common
ARM: vexpress/TC2: Implement MCPM power_down_finish()
ARM: tegra: Provide dummy powergate implementation
ARM: omap: fix warning with LPAE build
ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init
ARM: OMAP2+: Remove legacy mux code for display.c
ARM: OMAP2+: Fix undefined reference to set_cntfreq
gpio: twl4030: Fix passing of pdata in the device tree case
gpio: twl4030: Fix regression for twl gpio output
ARM: OMAP2+: More randconfig fixes for reconfigure_io_chain
ARM: dts: imx6qdl: disable spdif "rxtx5" clock option
ARM: dts: Fix omap2 specific dtsi files by adding the missing entries
ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x
i2c: omap: Fix missing device tree flags for omap2
|
|
The I2C controller node needs #address-cells and #size-cells properties,
but these are currently missing. Add them. This allows child nodes to be
parsed correctly.
Cc: [email protected]
Signed-off-by: Stephen Warren <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
|
|
git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
The imx fixes for 3.13, part 2:
- Disable S/PDIF "rxtx5" clock option to fix the clocksource breakage
introduced by S/PDIF driver
* tag 'imx-fixes-3.13-2' of git://git.linaro.org/people/shawnguo/linux-2.6:
ARM: dts: imx6qdl: disable spdif "rxtx5" clock option
Signed-off-by: Kevin Hilman <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
|
|
Convert onenand to DT on n8x0 boards.
Signed-off-by: Aaro Koskinen <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
These now come from device tree except for DSS and DMA that
still uses hwmod to initialize. That will get fixed when we
DSS gets device tree bindings and we move completely to the
dmaengine API.
Cc: Paul Walmsley <[email protected]>
[[email protected]: updated to add trailing commas to structs]
Signed-off-by: Tony Lindgren <[email protected]>
|
|
This is no longer needed as pins can be muxed using
pinctrl-single.
Signed-off-by: Tony Lindgren <[email protected]>
|
|
We can now boot with device tree and appended DTB
with basic devices working. If people are still using
this board, patches are welcome to add more complete
support.
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The old 2420 based H4 is probably not used at all as 2420
was Nokia specific SoC. I have one, but I'm not using it because
of it's large size, and I doubt anybody else is using it either.
We do have minimal omap2420-h4.dts in place, so if anybody wants
more support on H4, patches are welcome.
So let's just remove it as that helps us making mach-omap2 to
be device tree only.
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Now we can boot n8x with the appended device tree with:
$ ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make omap2420-n800.dtb
$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap2420-n800.dtb > /tmp/zImage
Note that you need at least the following enabled:
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_SINGLE=y
Tested-by: Aaro Koskinen <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
This allows us to keep things working when booted with
device tree. Note that we still need to initialize most
things with platform data as the drivers are lacking
support for device tree.
Tested-by: Aaro Koskinen <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Initialize some devices using a late_initcall and test for
the device tree based booting for some devices.
This way we can keep things working for legacy platform
devices when booted with device tree.
Tested-by: Aaro Koskinen <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
This allows us to initialize the legacy devices when booted
with device tree.
Tested-by: Aaro Koskinen <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Looks like some boards need to fill in the auxdata before
we call of_platform_populate(). Let's add support for
auxdata quirks like we already have for pdata quirks for
legacy drivers.
Signed-off-by: Tony Lindgren <[email protected]>
|
|
|
|
Basic things like serial, Ethernet, MMC, NAND, DSS, touchscreen
and GPIO keys work.
For twl4030-keypad we're still missing the binding, but
support for that should be trivial to add once the driver
has been updated.
MUSB I'm pretty sure I got got to enumerate once, but I
suspect the battery charging somehow disrupts it and it's
not enumerating in general for some reason.
Patches are welcome to improve things if people are
still using this board.
For reference, here's some more info on this old board:
http://www.openomap.org/wiki/tiki-index.php?page=HardwareInfo
Cc: [email protected]
Cc: "Benoît Cousson" <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
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: [email protected]
Cc: "Benoît Cousson" <[email protected]>
Tested-by: Aaro Koskinen <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
I doubt that there are many people using 2430 sdp, but as
that's been historically an important acid test platform
for omap2+ related changes, let's add minimal device
tree support for it.
If anybody is using it beyond minimal boot testing, patches
for more complete device tree support are welcome.
Cc: [email protected]
Cc: "Benoît Cousson" <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Without the interrupt you'll get problems if you enable
CONFIG_RTC_DRV_MAX77686. Setup the interrupt properly in the device
tree.
Signed-off-by: Doug Anderson <[email protected]>
Tested-by: Marc Zyngier <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
Cc: [email protected]
|
|
|
|
Looks like we need to configure the regulators and use the pdata
quirk to make eMMC work with device tree.
It seems that mostly vaux3 is used, and only some earlier revisions
used vmmc2. This has been tested to work on devices where the
system_rev passed by the bootloader has versions 0x0010, 0x2101
and 0x2204.
Cc: [email protected]
Cc: Pavel Machek <[email protected]>
Cc: Aaro Koskinen <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
[[email protected]: updated with pinctrl changes and comments from Sebastian]
Signed-off-by: Tony Lindgren <[email protected]>
|
|
We do not have REGULATOR_FIXED selected if no boards are selected
and we boot with device tree. This can cause various devices to
fail.
Signed-off-by: Tony Lindgren <[email protected]>
|
|
After dropping the duplicate data in hwmod that now should come from
the .dts files, I noticed few more entries missing. Let's add these
as otherwise devices relying on these won't work.
Looks like the side tone entries are bundled into the mcbsp1 to 3,
so that may needs some special handling in the hwmod code as it's
currently trying to look up mcbsp2_sidetone and mcbsp3_sidetone
entries.
Signed-off-by: Tony Lindgren <[email protected]>
|
|
This patch implements the power_down_finish() method for TC2, to
enable the kernel to confirm when CPUs are safely powered down.
The information required for determining when a CPU is parked
cannot be obtained from any single place, so a few sources of
information must be combined:
* mcpm_cpu_power_down() must be pending for the CPU, so that we
don't get confused by false STANDBYWFI positives arising from
CPUidle. This is detected by waiting for the tc2_pm use count
for the target CPU to reach 0.
* Either the SPC must report that the CPU has asserted
STANDBYWFI, or the TC2 tile's reset control logic must be
holding the CPU in reset.
Just checking for STANDBYWFI is not sufficient, because this
signal is not latched when the the cluster is clamped off and
powered down: the relevant status bits just drop to zero. This
means that STANDBYWFI status cannot be used for reliable
detection of the last CPU in a cluster reaching WFI.
This patch is required in order for kexec to work with MCPM on TC2.
MCPM code was changed in commit 0de0d6467525 ('ARM: 7848/1: mcpm:
Implement cpu_kill() to synchronise on powerdown'), and since then it
will hit a WARN_ON_ONCE() due to power_down_finish not being implemented
on the TC2 platform.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Pawel Moll <[email protected]>
Reviewed-by: Nicolas Pitre <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren:
Few more fixes for issues found booting older omaps using device tree.
Also few randconfig build fixes and removal of some dead code for omap4
as it no longer has legacy platform data based booting support.
* tag 'omap-for-v3.13/more-fixes-for-merge-window-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init
ARM: OMAP2+: Remove legacy mux code for display.c
ARM: OMAP2+: Fix undefined reference to set_cntfreq
gpio: twl4030: Fix passing of pdata in the device tree case
gpio: twl4030: Fix regression for twl gpio output
ARM: OMAP2+: More randconfig fixes for reconfigure_io_chain
ARM: dts: Fix omap2 specific dtsi files by adding the missing entries
ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x
i2c: omap: Fix missing device tree flags for omap2
|
|
Some omap3 code is throwing a warning:
arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
In reality this code will never actually execute with LPAE=y, since
Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
this case.
Signed-off-by: Olof Johansson <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
|
|
Commit 14fd8ed0a7fd19913 ("ARM: mvebu: Relocate Armada 370/XP PCIe
device tree nodes") relocated the PCIe controller DT nodes one level
up in the Device Tree, to reflect a more correct representation of the
hardware introduced by the mvebu-mbus Device Tree binding.
However, while most of the boards were properly adjusted accordingly,
the Armada 370 DB board was left unchanged, and therefore, PCIe is
seen as not enabled on this board. This patch fixes that by moving the
PCIe controller node one level-up in armada-370-db.dts.
Signed-off-by: Thomas Petazzoni <[email protected]>
Cc: <[email protected]> # v3.12+
Fixes: 14fd8ed0a7fd19913 "ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes"
Signed-off-by: Jason Cooper <[email protected]>
|
|
The Armada XP provides a mechanism called "virtual CPU registers" or
"per-CPU register banking", to access the per-CPU registers of the
current CPU, without having to worry about finding on which CPU we're
running. CPU0 has its registers at 0x21800, CPU1 at 0x21900, CPU2 at
0x21A00 and CPU3 at 0x21B00. The virtual registers accessing the
current CPU registers are at 0x21000.
However, in the Device Tree node that provides the register addresses
for the coherency unit (which is responsible for ensuring coherency
between processors, and I/O coherency between processors and the
DMA-capable devices), a mistake was made: the CPU0-specific registers
were specified instead of the virtual CPU registers. This means that
the coherency barrier needed for I/O coherency was not behaving
properly when executed from a CPU different from CPU0. This patch
fixes that by using the virtual CPU registers.
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Thomas Petazzoni <[email protected]>
Cc: <[email protected]> # v3.8+
Fixes: e60304f8cb7bb5 "arm: mvebu: Add hardware I/O Coherency support"
Signed-off-by: Jason Cooper <[email protected]>
|
|
This is required to allow the load address to be supplied
as an environment variable when building a uImage.
LOADADDR=0x40008000 ARCH=arm make uImage
This is necessary since "ARM: shmobile: Remove legacy KZM9D board code"
Signed-off-by: Simon Horman <[email protected]>
|
|
Enable HPB-DMAC driver in 'bockw_defconfig'.
Signed-off-by: Sergei Shtylyov <[email protected]>
Signed-off-by: Simon Horman <[email protected]>
|
|
Enable HPB-DMAC driver in 'marzen_defconfig'.
Signed-off-by: Sergei Shtylyov <[email protected]>
Signed-off-by: Simon Horman <[email protected]>
|
|
CONFIG_SMC911X is not needed by marzen.
It appears to have been accidently enabled as well
as CONFIG_SMSC911X which is needed by marzen.
Signed-off-by: Simon Horman <[email protected]>
|
|
CONFIG_PACKET is required for the ISC dhcpd daemon function.
This change brings the marzen defconfig into line with
other shmobile defconfigs.
Signed-off-by: Simon Horman <[email protected]>
|
|
CONFIG_PACKET is required for the ISC dhcpd daemon function.
This change brings the bockw defconfig into line with
other shmobile defconfigs.
Signed-off-by: Simon Horman <[email protected]>
|