Glue layers for the DWC3 driver only make sense on specific platforms.
Add dependencies so that they are not built where they aren't needed.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: WingMan Kwok w-kw...@ti.com
Remove all remaining uses of gpmc,device-nand that have been added since
the property was removed by commit f40739faba8e (ARM: dts: OMAP2+:
Simplify NAND support).
Signed-off-by: Johan Hovold jhov...@gmail.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 1 -
On 24/03/14 13:01, Sathya Prakash M R wrote:
Add DT data for the display subsystem, which contains the following
blocks:
dss - the wrapper/glue for the display modules
dispc - display controller
rfbi - MIPI DBI encoder
dss subsystem of am43x is re use from omap3.
On 24/03/14 13:01, Sathya Prakash M R wrote:
Add DSS features for AM43xx.
Signed-off-by: Sathya Prakash M R sath...@ti.com
I can pick this up for 3.16 dss changes.
Tomi
signature.asc
Description: OpenPGP digital signature
Hi Paul,
On 24/03/14 13:01, Sathya Prakash M R wrote:
From: Tomi Valkeinen tomi.valkei...@ti.com
On AM43xx, if a PLL is in bypass at kernel init, the code in
omap2_get_dpll_rate() will not realize this and will try to calculate
the clock rate using the multiplier and the divider, resulting
Hi Joerg,
On Friday 04 April 2014 12:18:11 Joerg Roedel wrote:
On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote:
Right, we indeed need two levels of API, one for drivers such as
remoteproc that need direct control of the IOMMU, and one for drivers that
only need to map
Hi Marek,
On Friday 04 April 2014 14:23:57 Marek Szyprowski wrote:
Hello,
I'm sorry for a delay, I've got back from my holidays and I'm still busy
trying to get thought all the emails.
No worries.
On 2014-03-17 23:44, Laurent Pinchart wrote:
On Monday 17 March 2014 14:58:24 Suman Anna
Add support for CompuLab CM-T54 CoM and SBC-T54 board:
http://compulab.co.il/products/computer-on-modules/cm-t54/
http://compulab.co.il/products/sbcs/sbc-t54/
SBC-T54 is a single board computer based on OMAP5432 CPU.
It is implemented with a CM-T54 CoM providing most of the
Add support of AW-NH387 (mwifiex) WiFi/BT chip connected to MMC3.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/omap5-cm-t54.dts | 27 +++
arch/arm/mach-omap2/pdata-quirks.c | 10 ++
2 files changed, 37 insertions(+), 0
Add support for CM-T54 CoM and SBC-T54 board:
http://compulab.co.il/products/computer-on-modules/cm-t54/
http://compulab.co.il/products/sbcs/sbc-t54/
SBC-T54 is a single board computer based on OMAP5432 CPU.
It is implemented with a CM-T54 CoM providing most of the functions,
and SB-T54 carrier
Hi Laurent,
On Tue, Apr 08, 2014 at 02:50:38PM +0200, Laurent Pinchart wrote:
I agree with you, the two levels are already present, but there's still rough
edges that we need to soften.
The ARM DMA API implementation requires someone to create the VA space
mapping
by calling
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++
Hi Joerg,
On Tuesday 08 April 2014 15:43:22 Joerg Roedel wrote:
On Tue, Apr 08, 2014 at 02:50:38PM +0200, Laurent Pinchart wrote:
I agree with you, the two levels are already present, but there's still
rough edges that we need to soften.
The ARM DMA API implementation requires someone
On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056
* Tomi Valkeinen tomi.valkei...@ti.com [140407 22:42]:
On 08/04/14 03:13, Tony Lindgren wrote:
Tomi,
* Tomi Valkeinen tomi.valkei...@ti.com [140121 03:01]:
Add DT support for panel-dpi.
Looks like this patch did not get merged or am I missing
something?
Yes, I dropped it. None
All GPIO controller drivers have been migrated to use the struct
gpio_chip_ops virtual function table so the embeddeded function
pointers in struct gpio_chip can now be removed.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpiolib.c | 83
In the kernel there are basically two patterns to implement object
oriented code in C. You can either embedded a set of function pointers
in a struct along with other members or have a separate virtual function
table (vtable) structure that hold all the functions and only store a
pointer to that
This is a transitional change to avoid breaking git bisect-ability
while converting GPIO controller drivers to set their operations by
using the newly introduced struct gpio_chip_ops virtual function table.
It should be removed once all GPIO chip drivers have been converted.
Signed-off-by:
A common pattern to implement object oriented code in the kernel is
to use a separate structure to hold all the methods for a particular
kind of object and just have a pointer to this table rather than a
separate pointer for each method.
The alternate approach is to directly embedded function
The GPIO controller operations has been split to be stored
on a separate struct gpio_chip_ops virtual function table.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-twl4030.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff
The GPIO controller operations has been split to be stored
on a separate struct gpio_chip_ops virtual function table.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
Do not try to initialize display for DT boot, since omapdss
is now initialized via Device Tree. Without this patch the
display subsystem does not properly come up.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
Hi,
This patch should be added to 3.15-rc to make display initialization via DT
Hi,
On Tue, Apr 08, 2014 at 10:51:18PM +0200, Sebastian Reichel wrote:
Do not try to initialize display for DT boot, since omapdss
is now initialized via Device Tree. Without this patch the
display subsystem does not properly come up.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
* Aaro Koskinen aaro.koski...@iki.fi [140408 14:48]:
Hi,
On Tue, Apr 08, 2014 at 10:51:18PM +0200, Sebastian Reichel wrote:
Do not try to initialize display for DT boot, since omapdss
is now initialized via Device Tree. Without this patch the
display subsystem does not properly come up.
On Tue, Apr 08, 2014 at 03:23:55PM -0700, Tony Lindgren wrote:
* Aaro Koskinen aaro.koski...@iki.fi [140408 14:48]:
Shouldn't we delete the whole file, since non-DT boot is
not anymore supported?
Legacy support is still there for omap3 until the DSS displays are
converted.
Sorry, I was
During boot, when hwmod tries to cut clocks for debugss it always
gets stuck in transition state and throws the following warning:
[0.139581] omap_hwmod: debugss: _wait_target_disable failed
As per the information provided by folks, clocks to debugss cannot be cut.
So adding
26 matches
Mail list logo
