Patch series adds omap5 evm mcspi nodes and pinctrl
data in omap5.dtsi and omap5-evm.dts files.
Felipe Balbi (1):
arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file
Sourav Poddar (1):
arm: dts: omap5-evm: Add mcspi data
arch/arm/boot/dts/omap5-evm.dts | 46
From: Felipe Balbi ba...@ti.com
Add all 4 mcspi instances to omap5.dtsi file.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 40
1 files changed, 40 insertions(+), 0
Add mcspi node and pinmux data for omap5 mcspi controller.
Tested on omap5430 evm with 3.8-rc4 custom kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2
Pinctrl nodes were pointing to a different parent.
Fixing the same.
arch/arm/boot/dts/omap5-evm.dts | 46
On Monday 04 February 2013 02:21 PM, Sourav Poddar wrote:
Patch series adds omap5 evm mcspi nodes and pinctrl
data in omap5.dtsi and omap5-evm.dts files.
Felipe Balbi (1):
arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file
Sourav Poddar (1):
arm: dts: omap5-evm: Add mcspi data
On 01/30/2013 12:46 PM, Chen Gang wrote:
the fields must be null-terminated:
the caller may use it as null-terminted string, next.
Signed-off-by: Chen Gang gang.c...@asianux.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c |3 ++-
1 file
So how should we handle such case? Having several dtsi depending
on the Overo's revision would be a mess to my sense, considering
the non-conditional include inside the expansion boards' dts.
Or would it make sense to extend the DT binding for partitions?
Yes makes sense to extend the binding
Hi Tony,
On 02/01/2013 11:45 PM, Tony Lindgren wrote:
* Chen Gang gang.c...@asianux.com [130130 03:50]:
the fields must be null-terminated:
the caller may use it as null-terminted string, next.
Added Peter to cc on this one too, it's best that he queues
all the twl changes.
I can
Hello Benoit,
On 01/24/2013 01:21 PM, Benoit Cousson wrote:
+ Peter who did the original PWM
Hi Florian,
On 01/23/2013 06:56 PM, Florian Vaussard wrote:
Hello Benoit,
This patchset adds some new DT supports to the Overo products. The
first patch converts the PMIC LEDB output to use the
Hi Florian,
On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11
Hi Javier,
On 02/04/2013 10:27 AM, Javier Martinez Canillas wrote:
Hi Florian,
On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Hi Javier,
Hi Florian,
On 02/04/2013 10:27 AM, Javier Martinez Canillas wrote:
Hi Florian,
On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Add device-tree support for
OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.
While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP
On Saturday 02 February 2013 04:07:59 Sergei Shtylyov wrote:
On 02-02-2013 1:30, Russell King - ARM Linux wrote:
because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register
On 02/02/2013 12:11 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130201 17:25]:
On 02/01/2013 03:51 PM, Tony Lindgren wrote:
How about let's fix this properly to start with so we don't add
more blockers moving this code to drivers/bus?
Looks like gpmc_mem_init() gets called
On Thursday 31 January 2013 02:52 PM, Venkatraman S wrote:
On Thu, Jan 31, 2013 at 2:22 PM, Balaji T K balaj...@ti.com wrote:
Update Maintainer email for omap_hsmmc,
as Venkatraman will no longer be able to maintain omap_hsmmc driver.
Signed-off-by: Venkatraman S svenk...@gmail.com
On 01/30/2013 11:04 AM, Jon Hunter wrote:
There is a lot of redundancy in the definitions for the various system
timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
function is the same as the omap3_gp_gptimer_timer_init() function and the
function
Hi,
On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
On Mon, Feb 04, 2013 at 05:41:53PM +0200, Felipe Balbi wrote:
Hi,
On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
I guess to make the MUSB side simpler we would need musb-dma-engine
glue
to map dmaengine to the private MUSB API. Then we would have some
Hi,
On Fri, Feb 01, 2013 at 11:14:24AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130125 02:30]:
Hi,
On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote:
Start using the control module driver for powering on the PHY and for
writing to the mailbox
how to do that
as there is no way to provide a phandle to any of the OMAP generated clocks
in the device tree. Suggestions welcome :).
Based on linux-next:next-20130204
Depends on USB: omap-ehci: Move PHY management to PHY driver
g...@github.com:rogerq/linux.git next-usbhost16
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
drivers/usb/otg/nop-usb-xceiv.c| 31
Add 2 flags, needs_vcc and needs_reset to platform data.
If the flag is set and the regulator couldn't be found
then we bail out with -EPROBE_DEFER.
For device tree boot we depend on presensce of vcc-supply/
reset-supply properties to decide if we should bail out
with -EPROBE_DEFER or just
Enable this driver to probe in device tree boot.
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/mfd/omap-usb-tll.txt | 17 +
drivers/mfd/omap-usb-tll.c |9 +
2 files
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
This is because we want to get rid of platform_data usage from probe().
The only information we need is PORT_MODE, and this can be supplied
to us by the user (i.e. omap-usb-host.c).
We also move channel clock management from runtime PM handlers into
omap_tll_enable/disable().
CC: Samuel Ortiz
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ohci-omap3.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
Allows the OHCI controller found in OMAP3 and later chips to
be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/omap3-ohci.txt | 17 +
drivers/usb/host/ohci-omap3.c | 19 +++
2
Allows the OMAP HS USB host controller to be specified
via device tree.
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 68
drivers/mfd/omap-usb-host.c| 83
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi
Allows the OMAP EHCI controller to be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/omap-ehci.txt | 34 ++
drivers/usb/host/ehci-omap.c | 36 +++-
2 files changed, 69
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 71
1 files
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 55 +
1
Hello.
On 02/04/2013 06:41 PM, Felipe Balbi wrote:
I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.
Why? Inventra is a
Hi,
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
Granted, CPPI 4.1 makes some assumptions about the fact that it's
handling USB
Hello.
On 02/04/2013 07:47 PM, Felipe Balbi wrote:
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
Granted, CPPI 4.1 makes some
Hi,
On Mon, Feb 04, 2013 at 08:54:17PM +0300, Sergei Shtylyov wrote:
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
Granted, CPPI
On Mon, Feb 04, 2013 at 06:47:12PM +0200, Felipe Balbi wrote:
Hi,
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
In my eyes, getting rid of the mess doesn't justify breaking the rules
that
Russell formulated above.
MUSB is no PCI, there is no single, standard
* Felipe Balbi ba...@ti.com [130204 07:57]:
Hi,
On Fri, Feb 01, 2013 at 11:14:24AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130125 02:30]:
Hi,
On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote:
Start using the control module driver for
Hello.
On 02/04/2013 08:02 PM, Felipe Balbi wrote:
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
Granted, CPPI 4.1 makes some
* Javier Martinez Canillas jav...@dowhile0.org [130204 04:00]:
On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
do you have a public git for this, so I can test your work on my setup?
Yes, it is the gpmc-smsc911x-wip
This series consists mainly of clean-ups for clockevents and
clocksource timers on OMAP2+ devices. The most significant change
in functionality comes from the 5th patch which is changing the
selection of the clocksource timer for OMAP3 and AM335x devices
when gptimers are used for clocksource.
Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
device-tree support for selecting a clockevent timer by property.
However, the code is currently ignoring the property passed and
selecting the first available timer found. Hence, for the OMAP3 beagle
board timer-12 is not being
Currently, when configuring the clock-events and clock-source timers
for OMAP2+ devices, we check whether the timer ID is 12 before
attempting to set the parent clock for the timer.
This test was added for OMAP3 general purpose devices (no security
features enabled) that a 12th timer available
Currently on boot, when displaying the name of the gptimer used for
clockevents and clocksource timers, the timer ID is shown. However,
when booting with device-tree, the timer ID is not used to select a
gptimer but a timer property. Hence, it is possible that the timer
selected when booting with
There is a lot of redundancy in the definitions for the various system
timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
function is the same as the omap3_gp_gptimer_timer_init() function and the
function omap4_sync32k_timer_init() can be re-used for OMAP5 devices.
Commit 6bb27d7 (ARM: delete struct sys_timer) changed the function
created by the macro OMAP_SYS_32K_TIMER_INIT from static void to void.
For OMAP4+ devices this created the following sparse warning ...
arch/arm/mach-omap2/timer.c:585:1: warning: symbol
'omap4_sync32k_timer_init' was not
Currently, the timer ID is being passed to the function
omap_dm_timer_init_one(). Instead of passing the ID separately, store it
in the omap_dm_timer structure, that is also passed, and access the ID
from this structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c
In commit c59b537 (ARM: OMAP2+: Simplify dmtimer clock aliases), new
clock aliases for dmtimers were added to simplify the code. These clock
aliases can also be used when configuring the system timers and allow us
to remove the current definitions, simplifying the code.
Please note that for
* Jon Hunter jon-hun...@ti.com [130204 07:09]:
On 02/02/2013 12:11 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130201 17:25]:
On 02/01/2013 03:51 PM, Tony Lindgren wrote:
How about let's fix this properly to start with so we don't add
more blockers moving this code to
On Mon, Feb 04, 2013 at 11:43:02AM -0600, Jon Hunter wrote:
@@ -280,22 +281,22 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(timer-fclk))
return -ENODEV;
- /* FIXME: Need to remove hard-coded test on timer ID */
- if
On 02/04/2013 11:42 AM, Jon Hunter wrote:
This series consists mainly of clean-ups for clockevents and
clocksource timers on OMAP2+ devices. The most significant change
in functionality comes from the 5th patch which is changing the
selection of the clocksource timer for OMAP3 and AM335x
On 02/04/2013 11:46 AM, Russell King - ARM Linux wrote:
On Mon, Feb 04, 2013 at 11:43:02AM -0600, Jon Hunter wrote:
@@ -280,22 +281,22 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(timer-fclk))
return -ENODEV;
-/* FIXME: Need
From: Mugunthan V N mugunthan...@ti.com
Date: Fri, 1 Feb 2013 00:33:20 +0530
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..99696bf 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++
On Mon, Feb 4, 2013 at 6:32 PM, Tony Lindgren t...@atomide.com wrote:
* Javier Martinez Canillas jav...@dowhile0.org [130204 04:00]:
On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
do you have a public git for this, so I
* Peter Ujfalusi peter.ujfal...@ti.com [130204 01:04]:
Hi Tony,
On 02/01/2013 11:45 PM, Tony Lindgren wrote:
* Chen Gang gang.c...@asianux.com [130130 03:50]:
the fields must be null-terminated:
the caller may use it as null-terminted string, next.
Added Peter to cc on this
On 02/04/2013 11:45 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130204 07:09]:
On 02/02/2013 12:11 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130201 17:25]:
On 02/01/2013 03:51 PM, Tony Lindgren wrote:
How about let's fix this properly to start with so we don't
* Jon Hunter jon-hun...@ti.com [130204 10:49]:
On 02/04/2013 11:45 AM, Tony Lindgren wrote:
AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
pins, so using generic pinconf there makes sense. But this of course should
be checked.
Not sure I am a fan of that
On 02/04/2013 12:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Feb 04, 2013 at 08:54:17PM +0300, Sergei Shtylyov wrote:
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines
On 02/04/2013 01:15 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130204 10:49]:
On 02/04/2013 11:45 AM, Tony Lindgren wrote:
AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
pins, so using generic pinconf there makes sense. But this of course should
be
Currently on boot, when displaying the name of the gptimer used for
clockevents and clocksource timers, the timer ID is shown. However,
when booting with device-tree, the timer ID is not used to select a
gptimer but a timer property. Hence, it is possible that the timer
selected when booting with
This series consists mainly of clean-ups for clockevents and
clocksource timers on OMAP2+ devices. The most significant change
in functionality comes from the 5th patch which is changing the
selection of the clocksource timer for OMAP3 and AM335x devices
when gptimers are used for clocksource.
Currently, when configuring the clock-events and clock-source timers
for OMAP2+ devices, we check whether the timer ID is 12 before
attempting to set the parent clock for the timer.
This test was added for OMAP3 general purpose devices (no security
features enabled) that a 12th timer available
In commit c59b537 (ARM: OMAP2+: Simplify dmtimer clock aliases), new
clock aliases for dmtimers were added to simplify the code. These clock
aliases can also be used when configuring the system timers and allow us
to remove the current definitions, simplifying the code.
Please note that for
There is a lot of redundancy in the definitions for the various system
timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
function is the same as the omap3_gp_gptimer_timer_init() function and the
function omap4_sync32k_timer_init() can be re-used for OMAP5 devices.
Currently, the timer ID is being passed to the function
omap_dm_timer_init_one(). Instead of passing the ID separately, store it
in the omap_dm_timer structure, that is also passed, and access the ID
from this structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c
* Jon Hunter jon-hun...@ti.com [130204 11:37]:
On 02/04/2013 01:15 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130204 10:49]:
On 02/04/2013 11:45 AM, Tony Lindgren wrote:
AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
pins, so using generic
Commit 6bb27d7 (ARM: delete struct sys_timer) changed the function
created by the macro OMAP_SYS_32K_TIMER_INIT from static void to void.
For OMAP4+ devices this created the following sparse warning ...
arch/arm/mach-omap2/timer.c:585:1: warning: symbol
'omap4_sync32k_timer_init' was not
When booting with device-tree for OMAP3 and AM335x devices and a gptimer
is used as the clocksource (which is always the case for AM335x), a
gptimer located in a power domain that is not always-on is selected.
Ideally we should use a gptimer located in a power domain that is always
on (such as the
On 02/04/2013 01:47 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130204 11:37]:
On 02/04/2013 01:15 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130204 10:49]:
On 02/04/2013 11:45 AM, Tony Lindgren wrote:
AFAIK SYSBOOT_n values reflect the boot time values of the
* Tony Lindgren t...@atomide.com [130130 14:09]:
* Peter Ujfalusi peter.ujfal...@ti.com [130129 00:34]:
Hi Tony,
On 01/22/2013 11:07 AM, Peter Ujfalusi wrote:
Hi Tony,
The content of this pull:
update for audio support via omap-twl4030 and pwm updates in board level:
On Mon, Jan 28, 2013 at 09:18:29PM +0100, Robert Jarzmik wrote:
Felipe Balbi ba...@ti.com writes:
By simply setting a flag, we can drop some
boilerplate code.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/pxa27x_udc.c | 9 +
Acked-by: Robert Jarzmik
The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7:
Linux 3.8-rc6 (2013-02-01 12:08:14 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.9/fixes-non-critical-signed-v2
for you to fetch
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less than ideal fit for the network driver use case.
The first problem
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience with fitting multiple subsystems on top of this
On Mon, 4 Feb 2013, Roger Quadros wrote:
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
On Mon, 4 Feb 2013, Roger Quadros wrote:
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
On Mon, 4 Feb 2013, Roger Quadros wrote:
Allows the OHCI controller found in OMAP3 and later chips to
be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
For the ohci-omap3 part:
Acked-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send
On Mon, 4 Feb 2013, Roger Quadros wrote:
Allows the OMAP EHCI controller to be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
For the ehci-omap part:
Acked-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send the line unsubscribe
On Monday 04 February 2013, Linus Walleij wrote:
So I think the above concerns are moot. The callback we can
set on cookies is entirely optional, and it's even implemented by
each DMA engine, and some may not even support it but require
polling, and then it won't even be implemented by the
On 02/04/2013 04:11 PM, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience
On 02/01/2013 03:51 PM, Tony Lindgren wrote:
How about let's fix this properly to start with so we don't add
more blockers moving this code to drivers/bus?
Looks like gpmc_mem_init() gets called from gpmc_probe() so
we can pass that information in pdev.
I have re-worked this a bit to use
On 02/04/2013 03:29 PM, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less than ideal fit for the
On 02/04/2013 04:12 PM, Jon Hunter wrote:
On 02/01/2013 03:51 PM, Tony Lindgren wrote:
How about let's fix this properly to start with so we don't add
more blockers moving this code to drivers/bus?
Looks like gpmc_mem_init() gets called from gpmc_probe() so
we can pass that information
于 2013年02月05日 02:18, Tony Lindgren 写道:
* Peter Ujfalusi peter.ujfal...@ti.com [130204 01:04]:
Hi Tony,
I can create a branch for you in our gitorious tree
(git://gitorious.org/omap-audio/linux-audio.git) for this patch. But I
think
for now it would be best if you could take this via
On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
Add 2 flags, needs_vcc and needs_reset to platform data.
If the flag is set and the regulator couldn't be found
then we bail out with -EPROBE_DEFER.
For device tree boot we depend on presensce of vcc-supply/
reset-supply properties to
On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
Enable this driver to probe in device tree boot.
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/mfd/omap-usb-tll.txt | 17 +
On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
Allows the OMAP HS USB host controller to be specified
via device tree.
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 68
On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0
Hi,
On Mon, Feb 04, 2013 at 05:58:48PM +0200, Roger Quadros wrote:
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
On Mon, Feb 04, 2013 at 05:58:57PM +0200, Roger Quadros wrote:
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30
92 matches
Mail list logo
