This adds support of device tree probe for Renesas sh-ether driver.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
V6: - Add renesas,sh-eth-gigabit, renesas,sh-eth-sh4 and
renesas,sh-eth-sh3-sh2 to compatible string.
- Remove sh-eth,register-type. This is
On Mon, Mar 18, 2013 at 09:48:16AM +, Lorenzo Pieralisi wrote:
On Mon, Mar 18, 2013 at 03:09:28AM +, David Gibson wrote:
On Mon, Mar 11, 2013 at 05:06:57PM +, Lorenzo Pieralisi wrote:
Hi David,
thanks for your feedback.
On Wed, Mar 06, 2013 at 09:57:14PM +,
This patch series adds support for DRM FIMD DT for Exynos4 DT Machines,
specifically for Exynos4412 SoC.
changes since v7:
- rebased to kgene's for-next
- Migrated to Common Clock Framework
- removed the patch ARM: dts: Add FIMD AUXDATA node entry for exynos4
DT,
Adds common FIMD device node for all Exynos4 SoCs.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos4.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 9ac47d5..2480aaa
From: Sachin Kamat sachin.ka...@linaro.org
Adds the lcd panel related picntrl nodes for Exynos4412 SoC
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 14 ++
1 file changed, 14
Adds FIMD DT support to Origen quad board
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos4412-origen.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
Adds FIMD DT binding documentation for both Samsung SoC and Board, with an
example
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
.../devicetree/bindings/video/samsung-fimd.txt | 61
1 file changed, 61 insertions(+)
create mode 100644
Hi Vikas,
+Example:
+
+SoC specific DT Entry:
+
+ fimd@11c0 {
+ compatible = samsung,exynos4210-fimd;
+ interrupt-parent = combiner;
+ reg = 0x11c0 0x2;
+ interrupt-names = fifo, vsync, lcd_sys;
+
On 03/19/2013 02:54 AM, Mike Turquette wrote:
Quoting Arnd Bergmann (2013-03-16 07:56:54)
On Saturday 16 March 2013, Sebastian Hesselbarth wrote:
This driver adds a DT test clock consumer that exposes debugfs files to
enable/disable and set/get rate of the attached programmable clock.
During
Hi Herbert,
would you please merge this driver or is there anything else you want
me to address first?
Regards.
On 1 March 2013 12:37, Javier Martin javier.mar...@vista-silicon.com wrote:
SAHARA2 HW module is included in the i.MX27 SoC from
Freescale. It is capable of performing cipher
Hi Grant,
The 3rd patch is in preparation for some patches I have in WIP that would allow
drivers to set notifications for properties that are changed in runtime.
I think that since you have the all configuration taking place via DT and you
have a method to alter DT properties in run-time via
Hi Grant,
On Mar 16, 2013, at 11:24 AM, Grant Likely wrote:
On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Hi David,
On Jan 23, 2013, at 6:40 AM, David Gibson wrote:
Ok. Nonetheless it's not hard to avoid a recursive approach here.
How can
On Tue, Mar 19, 2013 at 05:02:39PM +0400, Sergei Shtylyov wrote:
Hello.
On 19-03-2013 8:22, Simon Horman wrote:
[ Cc: Mark Rutland ]
On Tue, Mar 05, 2013 at 06:52:20AM +0900, Nobuhiro Iwamatsu wrote:
This adds support of device tree probe for Renesas sh-ether driver.
Signed-off-by:
Hi,
Based on the discussion in [1], I've implemented device tree
provider for the AUXCLKs on OMAP4.
Please let me know if there are any issues.
This is important to get USB Host support working on Panda with
device tree boot on 3.10.
Roger Quadros (2):
ARM: OMAP4: clock: Add device tree
The USB PHY needs AUXCLK3 to operate. Provide this information
in the device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
On 03/19/2013 04:26 PM, Roger Quadros wrote:
Hi,
Based on the discussion in [1], I've implemented device tree
provider for the AUXCLKs on OMAP4.
[1] - https://lkml.org/lkml/2013/3/12/241
cheers,
-roger
___
devicetree-discuss mailing list
On 03/19/2013 04:26 PM, Roger Quadros wrote:
Register a device tree clock provider for AUX clocks
on the OMAP4 SoC. Also provide the binding information.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/clock/omap4-clock.txt | 32 ++
Hello,
For embedded devices where NAND flash is the only storage media, I was wondering what
are the existing approaches on how to store the device tree blob in flash.
Searching on the Internet I have found only two approaches:
1. Have a dedicated MTD partition for the device tree blob (raw).
On 3/18/2013 10:24 PM, Anton Vorontsov wrote:
On Tue, Mar 12, 2013 at 06:08:05PM -0400, Rhyland Klein wrote:
This patchset adds support for the TPS65090-charger. This charger is
registered as a subdevice of the TPS65090 PMIC.
This series includes a fix for the tps65090 header file where all
On Tue, Mar 19, 2013 at 11:55:33AM -0400, Rhyland Klein wrote:
On 3/18/2013 10:24 PM, Anton Vorontsov wrote:
On Tue, Mar 12, 2013 at 06:08:05PM -0400, Rhyland Klein wrote:
This patchset adds support for the TPS65090-charger. This charger is
registered as a subdevice of the TPS65090 PMIC.
Vinod, Tony, Benoit,
On 02/26/2013 12:27 PM, Jon Hunter wrote:
If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.
Signed-off-by: Jon Hunter jon-hun...@ti.com
On 3/19/2013 11:59 AM, Anton Vorontsov wrote:
On Tue, Mar 19, 2013 at 11:55:33AM -0400, Rhyland Klein wrote:
On 3/18/2013 10:24 PM, Anton Vorontsov wrote:
On Tue, Mar 12, 2013 at 06:08:05PM -0400, Rhyland Klein wrote:
This patchset adds support for the TPS65090-charger. This charger is
On 3/12/2013 6:08 PM, Rhyland Klein wrote:
Add irq resources to pass to the charger mfd sub dev so
the charger can listen for interrupts.
Signed-off-by: Rhyland Klein rkl...@nvidia.com
---
v3:
- no changes since v2
v2:
- no changes since v1
drivers/mfd/tps65090.c | 10 ++
The OMAP2+ code that configures the GPMC for ONENAND devices is copying
structures between functions unnecessarily. Avoid this by passing
pointers instead and simplify the code.
A pointer to structure omap_onenand_platform_data is passed to the
function omap2_onenand_calc_sync_timings(), but only
While adding device-tree support for NOR memories, it became apparent
that there is no common way for configuring various GPMC settings for
devices that interface to the GPMC. These settings include bus-width,
synchronous/asynchronous mode, burst settings, wait monitoring etc.
Therefore, to
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect if the wait-pin being selected is valid or not.
When booting with
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no common function for configuring these options and
various devices set these options by either programming the GPMC CONFIG1
register
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no central structure for storing all these options
when configuring the GPMC for a given device. Some of the options are
stored in the GPMC
Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
This moves the configuration of some GPMC options outside the
nand_gpmc_retime() because these options should only need to be
Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
With the addition of the gpmc_cs_program_settings(), we no longer need
or use gpmc_cs_configure() to configure some of the GPMC chip-select
options. So rename the function to gpmc_configure() and remove code that
modifies options in the CONFIG1 register.
Signed-off-by: Jon Hunter
Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB
of address space. The physical base address where a chip-select starts
is also configurable and must be aligned on a boundary that is equal to
or greater than the size of the address space mapped bt the chip-select.
When
When the GPMC driver is probed, we call gpmc_mem_init() to see which
chip-selects have already been configured and enabled by the boot-loader
and allocate space for them. If we fail to allocate space for one
chip-select, then we return failure from the probe and the GPMC driver
will not be
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Tested-by: Ezequiel Garcia
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a
With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the
variable boot_rom_space is now not needed and the code surrounding
this variable can be cleaned up and simplified. Remove unnecessary
definitions and clean-up the comment as well.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them. Also add either -ps or -ns suffix to
the GPMC timing properties to indicate whether the timing is in
picoseconds or
On 03/18/2013 02:13 AM, Joseph Lo wrote:
The PMC mostly controls the entry and exit of the system from different
sleep modes. Different platform or system may have different configurations.
The power management configurations of PMC is represented as some properties.
The system needs to define
On 03/19/2013 11:00 AM, Stephen Warren wrote:
On 03/18/2013 02:13 AM, Joseph Lo wrote:
The PMC mostly controls the entry and exit of the system from different
sleep modes. Different platform or system may have different configurations.
The power management configurations of PMC is represented
Even on platforms where the entire clock tree is not represented in the DT
it can still be useful to allow parents and rates to be set from the DT.
An example of such a case is when a multiplexable clock output from a SOC
is used to supply external chips (eg an audio codec connected to the i.MX53
On 03/18/2013 03:35 AM, Laxman Dewangan wrote:
Add documentation for device tree binding of NVIDIA's Tegra i2c
controller driver.
Describing all compatible values used for diffenent Tegra SoCs
in details in this documentation.
I have applied this to Tegra's for-3.10/dt branch. I fixed a
Includes:
- A couple fixes for DMTIMER context loss handling.
- Populating DMTIMER errata when booting with device-tree.
- A new function for requesting a DMTIMER by device-tree node.
Based upon v3.9-rc3.
Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 Blaze
and AM335x EVM. Testing
When booting with device-tree the function pointer for detecting context
loss is not populated. Ideally, the pm_runtime framework should be
enhanced to allow a means for reporting context/state loss and we could
avoid populating such function pointers altogether. In the interim until
a generic
From: NeilBrown ne...@suse.de
The context loss handling in dmtimer appears to assume that
omap_dm_timer_set_load_start() or omap_dm_timer_start() and
omap_dm_timer_stop() bracket all interactions. Only the first two
restore the context and the last updates the context loss counter.
However
Currently the DMTIMER errata flags are not being populated when using
device-tree. Add static platform data to populate errata flags when
using device-tree.
Please note that DMTIMER erratum i767 is applicable to OMAP3-5 devices
as well as AM335x devices.
Signed-off-by: Jon Hunter
Add a function so that OMAP dmtimers can be requested by device-tree
node. This allows for devices, such as the internal DSP, or drivers,
such as PWM, to reference a specific dmtimer node via the device-tree.
Given that there are several APIs available for requesting dmtimers
(by ID, by
Update the DMTIMER compatibility property to reflect the register level
compatibilty between devices and update the various OMAP/AM timer
bindings with the appropriate compatibility string.
By doing this we can add platform specific data applicable to specific
timer versions to the driver. For
Add DT OPP table for OMAP4460 family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp4xxx_data.c
This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot
We now use Soc generic cpufreq-cpu0 driver using DT entries.
However to allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist,
we need to ensure the following using the same image:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq
In the case of
Add DT OPP table for OMAP36xx/37xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp3xxx_data.c
This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot
Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp4xxx_data.c
Since the omap4460 OPP tables would be different from OMAP443x,
introduce an new omap443x.dtsi for 443x specific entries and use
Add DT OPP table for OMAP34xx/35xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp3xxx_data.c
Since the omap36xx OPP tables would be different from OMAP34xx/35xx,
introduce an new omap34xx.dtsi for 34xx/35xx specific
Hi,
The following version 2 of the series arose from trying to use BeagleBoard-XM
(OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
generic cpufreq-cpu0 driver to be used in device tree enabled boot while
maintaining support of the legacy omap-cpufreq driver when used
Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP34xx/35xx/36xx/37xx platforms (all use TWL4030 variants with
VDD1 supplying the CPU).
NOTE: This currently will use I2C1 bus communication path to set the
voltage in device tree boot. In the legacy non device tree
PandaBoard, PandaBoard-A4 revisions use OMAP4430.
PandaBoard-ES version of the board uses OMAP4460.
Move the original panda dts file into a common dtsi used by all panda
variants. This allows us to introduce SoC variation for PandaBoard ES
without impacting other PandaBoard versions that are
On 3/15/2013 8:21 AM, Marek Szyprowski wrote:
This scheme of associating devices with CMA regions by base does not
work if you want to let CMA figure out where to place the region (base
= 0). Can we use the name to associate the device with the region? I
had been working on something similar
With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points defined, we can now use the SoC
generic cpufreq-cpu0 driver by registering appropriate device.
As part of this change, add dummy clock node to use cpufreq-cpu0.
This is an suggested solution till we
On Tue, 19 Mar 2013 13:42:32 +0200, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Hi Grant,
The 3rd patch is in preparation for some patches I have in WIP that would
allow
drivers to set notifications for properties that are changed in runtime.
Okay, submit it with that series
On Tue, 19 Mar 2013 13:51:01 +0200, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Hi Grant,
On Mar 16, 2013, at 11:24 AM, Grant Likely wrote:
On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Hi David,
On Jan 23, 2013, at 6:40
Hi Felipe,
* Roger Quadros rog...@ti.com [130315 08:20]:
Hi Tony,
These patches provide the SoC side code required to support
the changes in the OMAP USB Host drivers done in [1], [2] [3].
Device tree support is added for Beagleboard and Panda.
NOTE: The first patch needs to be shared
Am Dienstag, 19. März 2013, 03:28:59 schrieb Rob Herring:
On 03/18/2013 06:34 PM, Heiko Stübner wrote:
Am Montag, 18. März 2013, 23:14:52 schrieb Rob Herring:
On 03/18/2013 11:53 AM, Heiko Stübner wrote:
[...]
My first thought here is this information should not be centralized in
the
Quoting Thomas Abraham (2013-02-18 00:21:10)
Changes since v5:
- Squashed several Exynos4 fixes patch from Tomasz Figa
- Included support for Exynos5250 and Exynos5440, thus converting all
Exynos4 and Exynos5 platforms to common clock framework.
- Depends on the following patch series.
-
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
Check return values from all GPIO APIs and handle errors accordingly.
Remove clk_disable_unprepare which is no more needed.
Patches 6 and 7 each fail checkpatch with WARNING: line over 80
characters.
___
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
This patch updates all Tegra board files so that they contain all the
properties required by the updated USB DT binding. Note that this patch
only adds the new properties and does not yet remove the old properties,
in order to maintain
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
As part of this series, apart from patch containing changes to register TEGRA
USB PHY driver as platform driver, prepared below patches:
1. Re-arranging adding new DT properties.
2. Getting various params from DT properties added.
3. code clean
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
Added a new PHY mode to support OTG.
Obtained Tegra USB PHY mode using DT property.
diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
@@ -713,6 +712,16 @@ struct tegra_usb_phy *tegra_usb_phy_open(struct device
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
As GPIO information is avail through DT, used it to get Tegra ULPI
reset GPIO number. Added a new member to tegra_usb_phy structure to
store this number.
diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
-
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
Check return values from all GPIO APIs and handle errors accordingly.
Remove clk_disable_unprepare which is no more needed.
The call to clk_disable_unprepare is incorrect in the current code. The
way you worded that, it sounds like it's no longer
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
Registered tegra USB PHY as a separate platform driver.
To synchronize host controller and PHY initialization, used deferred
probe mechanism. As PHY should be initialized before EHCI starts running,
deferred probe of Tegra EHCI driver till PHY
Am Dienstag, 19. März 2013, 19:49:38 schrieb Mike Turquette:
Quoting Thomas Abraham (2013-02-18 00:21:10)
Changes since v5:
- Squashed several Exynos4 fixes patch from Tomasz Figa
- Included support for Exynos5250 and Exynos5440, thus converting all
Exynos4 and Exynos5 platforms to
Hi Florian,
Le 16/03/2013 15:41, Florian Fainelli a écrit :
Hello Maxime, Stefan,
Please find below some comments regarding your PHY implementation in the
driver
as well as the transmit and transmit completion routines.
Stefan implemented the changes you asked about the PHY, it will be
On 03/18/2013 04:50 PM, Rob Herring wrote:
On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote:
On 03/13/2013 03:39 PM, Rob Herring wrote:
I fail to see what the hack is. The order of interrupt properties must
be defined by the binding. interrupt-names is auxiliary data and must
not be required
Quoting Heiko Stübner (2013-03-19 14:12:16)
Am Dienstag, 19. März 2013, 19:49:38 schrieb Mike Turquette:
Quoting Thomas Abraham (2013-02-18 00:21:10)
Changes since v5:
- Squashed several Exynos4 fixes patch from Tomasz Figa
- Included support for Exynos5250 and Exynos5440, thus
On 03/19/2013 12:05 AM, Stephen Warren wrote:
On 03/18/2013 04:27 PM, Rob Herring wrote:
On 03/18/2013 01:11 PM, Stephen Warren wrote:
On 03/18/2013 09:50 AM, Rob Herring wrote:
On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote:
Rob,
On 03/13/2013 03:39 PM, Rob Herring wrote:
I fail to see
Mike Turquette wrote:
[...]
Thomas,
Are you planning a V7 series which includes the clock alias bits from
patch #1?
Kukjin has already applied this series into the linux-samsung tree [0].
Thanks, Heiko.
Mike, yes I did, as we discussed before. Since I missed in last window
Hi all,
Last week I came across the issue that building dtbs for ARM in a recent
(3.9-rcX) kernel fails if it's done in a clean tree, right after make
xxx_defconfig. I am quite certain that this used to work in 3.8. The error is
asm/types.h not found. The problem does not happen if zImage is
DTC requires devicetable-offsets.o, which in turn needs asm/types.h to be
present or else it will fail to build.
[...]
CC scripts/mod/devicetable-offsets.s
In file included from include/linux/types.h:5:0,
from include/linux/mod_devicetable.h:11,
from
Hi Simon,
On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
Hi Simon,
On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
Hi Samuel,
On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz sa...@linux.intel.com wrote:
On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
Hi Simon,
On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
The ChromeOS Embedded Controller (EC) is an Open Source EC
Quoting Kukjin Kim (2013-03-19 17:00:09)
Mike Turquette wrote:
[...]
Thomas,
Are you planning a V7 series which includes the clock alias bits from
patch #1?
Kukjin has already applied this series into the linux-samsung tree [0].
Thanks, Heiko.
Mike, yes I did,
Mike Turquette wrote:
Quoting Kukjin Kim (2013-03-19 17:00:09)
Mike Turquette wrote:
[...]
Thomas,
Are you planning a V7 series which includes the clock alias bits from
patch #1?
Kukjin has already applied this series into the linux-samsung tree [0].
On Wednesday 20 March 2013 10:13 AM, Andy Gross wrote:
Add DMM bindings for OMAP4 and OMAP5 devices.
Signed-off-by: Andy Gross andy.gr...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |7 +++
arch/arm/boot/dts/omap5.dtsi |7 +++
2 files changed, 14 insertions(+), 0 deletions(-)
84 matches
Mail list logo
