On Wed, Apr 17, 2013 at 4:00 AM, Jon Hunter jon-hun...@ti.com wrote:
On 04/16/2013 07:41 PM, Javier Martinez Canillas wrote:
On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter jon-hun...@ti.com wrote:
On 04/16/2013 05:11 PM, Stephen Warren wrote:
On 04/16/2013 01:27 PM, Jon Hunter wrote:
On
On 04/17/13 04:30, Robert Nelson wrote:
On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren t...@atomide.com wrote:
* Roger Quadros rog...@ti.com [130415 05:44]:
On 04/15/2013 03:35 PM, Roger Quadros wrote:
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY
On 04/16/2013 06:32 PM, Alan Stern wrote:
On Mon, 15 Apr 2013, Roger Quadros wrote:
As the USB PHY layer never returns NULL we don't need
to check for that condition.
If we fail to get the PHY device it could be due
to missing USB PHY drivers. Give this hint to the user
in the error
As the USB PHY layer never returns NULL we don't need
to check for that condition.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On 04/17/2013 10:56 AM, Igor Grinberg wrote:
On 04/17/13 04:30, Robert Nelson wrote:
On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren t...@atomide.com wrote:
* Roger Quadros rog...@ti.com [130415 05:44]:
On 04/15/2013 03:35 PM, Roger Quadros wrote:
Provide RESET and Power regulators for the USB
Hi Javier!
On Thursday 14 March 2013 at 22:54:11, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC
Since uart_console definition is now moved to serial core
haeder file . Serial drivers need not define them.
Cc: Sylvain Munaut t...@246tnt.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Rajendra nayak rna...@ti.com
Signed-off-by: Sourav Poddar
Remove the OMAP_DEVICE_NO_IDLE_ON_SUSPEND check, since UART was the only one
making
use of it. Now serial core/driver takes care of the case when
no_console_suspend
is used in the bootargs and you need to keep the clock enable for console even
while suspend.
Signed-off-by: Sourav Poddar
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using no_console_suspend in the bootargs.
We can get rid of the previous implementation of setting the od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND from platform
and omap_device
Move uart_console definition to serial core header file, so that it can be
used by serial drivers.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Rajendra nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/tty/serial/serial_core.c
Hi,
This patch series contains fixes and cleanups around the issue that
the console UART should not idled on suspend while using no_console_suspend
in bootargs.
The approach thought of is to modify the serial core/serial driver to bypass
runtime PM if the UART in contention is a console and we
The ti,no_idle_on_suspend property was required to keep ocmcram
clocks running during idle.
But the commit below[1], added in v3.6 should prevent the
any automaic clock gating for devices without drivers bound. Since
there is no driver for the OCM RAM block, we are not affected by
the automatic
The patch adapt the serial core/driver to take care of the case when
no_console_suspend
is used in the bootargs. The patch will remove dependency to set od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND in serial.c(non dt case) and omap_device.c(dt
case).
Prepare and complete callbacks will ensure
On 04/17/2013 11:40 AM, Lars Poeschel wrote:
Hi Javier!
On Thursday 14 March 2013 at 22:54:11, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet
On 04/17/13 11:38, Roger Quadros wrote:
On 04/17/2013 10:56 AM, Igor Grinberg wrote:
On 04/17/13 04:30, Robert Nelson wrote:
On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren t...@atomide.com wrote:
* Roger Quadros rog...@ti.com [130415 05:44]:
On 04/15/2013 03:35 PM, Roger Quadros wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying around in this thread that I missed it :-)
Sorry about that...
No problem.
I was trying to see if we could find a common solution that everyone
could use as it seems that ideally we should all
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying around in this thread that I missed it :-)
Sorry about that...
No problem.
I was trying to see if we could find a common
On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
...
Yes, in fact I just realized that for_each_node_by_name() expand to:
#define for_each_node_by_name(dn, name) \
for (dn = of_find_node_by_name(NULL, name); dn; \
dn = of_find_node_by_name(dn, name))
which
On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying around in this thread that I missed it :-)
Sorry about that...
No
On 04/17/2013 03:48 PM, Jon Hunter wrote:
On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
...
Yes, in fact I just realized that for_each_node_by_name() expand to:
#define for_each_node_by_name(dn, name) \
for (dn = of_find_node_by_name(NULL, name); dn; \
On Wed, 17 Apr 2013, Roger Quadros wrote:
As the USB PHY layer never returns NULL we don't need
to check for that condition.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c |4 ++--
1 files changed, 2
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying
On Wednesday 17 April 2013 at 14:05:58, Javier Martinez Canillas wrote:
...
Yes, in fact I just realized that for_each_node_by_name() expand to:
#define for_each_node_by_name(dn, name) \
for (dn = of_find_node_by_name(NULL, name); dn; \
dn = of_find_node_by_name(dn,
On Tue, Mar 26, 2013 at 12:00:15AM +0100, Matthias Brugger wrote:
+- The spi slave nodes can provide the following information which is used
+ by the spi controller.
+- ti,spi-cs-per-word: Set chipselect to be toggled on every word send.
Why is this part of the DT binding for the SPI
On 04/16/2013 05:14 PM, Jon Hunter wrote:
On 04/16/2013 05:11 PM, Stephen Warren wrote:
On 04/16/2013 01:27 PM, Jon Hunter wrote:
On 04/16/2013 01:40 PM, Stephen Warren wrote:
On 04/15/2013 05:04 PM, Jon Hunter wrote:
...
If some driver is calling gpio_request() directly, then they will
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying
The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip as a GPMC child
and all its dependencies (regulators, GPIO and pin muxs).
Signed-off-by: Javier Martinez Canillas
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any
* Igor Grinberg grinb...@compulab.co.il [130417 05:31]:
On 04/17/13 11:38, Roger Quadros wrote:
On 04/17/2013 10:56 AM, Igor Grinberg wrote:
On 04/17/13 04:30, Robert Nelson wrote:
On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren t...@atomide.com wrote:
* Roger Quadros rog...@ti.com [130415
On 04/17/2013 09:07 AM, Javier Martinez Canillas wrote:
On 04/17/2013 03:48 PM, Jon Hunter wrote:
On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
...
Yes, in fact I just realized that for_each_node_by_name() expand to:
#define for_each_node_by_name(dn, name) \
for (dn =
On 04/17/2013 08:33 PM, Jon Hunter wrote:
On 04/17/2013 09:07 AM, Javier Martinez Canillas wrote:
On 04/17/2013 03:48 PM, Jon Hunter wrote:
On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
...
Yes, in fact I just realized that for_each_node_by_name() expand to:
#define
On 04/17/2013 11:37 AM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
The LED GPIOs between the 4430 (a1-a4) and 4460 (es) panda boards
are different. This patch abstracts the LED definitions into the
respective board files.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
Abstract away the pinmux and the LED definitions for the two boards.
Signed-off-by: Dan Murphy dmur...@ti.com
---
arch/arm/boot/dts/omap4-panda-es.dts | 33 +
On 04/17/2013 02:09 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
Abstract away the pinmux and the LED definitions for the two boards.
Just a heads-up but you should base this upon Benoit's for_3.10 branch
[1] as there is now a
On 04/17/2013 02:18 PM, Jon Hunter wrote:
On 04/17/2013 02:09 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
Abstract away the pinmux and the LED definitions for the two boards.
Just a heads-up but you should base this upon
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
Introduce HAS_BANDGAP config entry. This config is a
boolean value so that arch code can flag is they
feature a bandgap device.
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc:
This patch add the bandgap entry for OMAP4430 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc:
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.
This problem could
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any
If any of the GPMC child nodes fails, this shouldn't make the
whole gpmc_probe_dt() function to fail. It is better to just
WARN and allow other devices probe function to succeed.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1 (suggested by Jon
On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
The carveouts that have been reserved for multimedia usecases
are not being used currently by any driver and so have been
cleaned up. Memory will be allocated runtime through CMA for
enabling the multimedia usecases.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 8
Support for OMAP5 is added to the omap_dsp_ctrl_write_boot_addr()
to enable the DSP boot.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/control.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index
On 04/17/2013 11:27 PM, Jon Hunter wrote:
On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and
On 04/17/2013 05:10 PM, Javier Martinez Canillas wrote:
On 04/17/2013 11:27 PM, Jon Hunter wrote:
On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not
Hi,
This series includes patches for fixing/enhancing the timer capabilities
on OMAP4+ devices. The patches are created on top of Tony's DT branch for
3.10 [1], but they apply just fine on 3.9-rc7 as well. The patches are
independent of each other functionality-wise.
[1]
OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
The PWM capability property is missing from the node definitions of
couple of timers, and this has been fixed.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 3 +++
1 file changed, 3 insertions(+)
Some instances of the DMTIMER peripheral on OMAP4+ devices have the
ability to interrupt the on-chip image processor unit (IPU) subsystem
(a common name for the dual Cortex-M3 subsystem on OMAP4 or the dual
Cortex-M4 subsystem on OMAP5) in addition to the ARM CPU. Add a
DMTIMER attribute to
On 04/17/2013 06:23 PM, Suman Anna wrote:
OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
The PWM capability property is missing from the node definitions of
couple of timers, and this has been fixed.
Signed-off-by: Suman Anna s-a...@ti.com
---
On 04/17/2013 06:23 PM, Suman Anna wrote:
Some instances of the DMTIMER peripheral on OMAP4+ devices have the
ability to interrupt the on-chip image processor unit (IPU) subsystem
(a common name for the dual Cortex-M3 subsystem on OMAP4 or the dual
Cortex-M4 subsystem on OMAP5) in addition to
On 04/17/2013 07:04 PM, Jon Hunter wrote:
On 04/17/2013 06:23 PM, Suman Anna wrote:
Some instances of the DMTIMER peripheral on OMAP4+ devices have the
ability to interrupt the on-chip image processor unit (IPU) subsystem
(a common name for the dual Cortex-M3 subsystem on OMAP4 or the dual
* Tomi Valkeinen tomi.valkei...@ti.com [130415 21:25]:
On 2013-04-16 00:20, Tony Lindgren wrote:
So, to recap, the common header changes are located in:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
And the branch for linux-omap is:
The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.10/dss-signed
for you to fetch changes up to
On 2013-04-18 03:34, Tony Lindgren wrote:
Just one request: Let's do branches like this early on before -rc6,
not what might be five days before the merge window potentially
opens..
Agreed, it got a bit late. But the branch itself has been stable and in
linux-next for some time.
Perhaps it
On Wed, Apr 17, 2013 at 05:04:23PM +0530, Sourav Poddar wrote:
Since uart_console definition is now moved to serial core
haeder file . Serial drivers need not define them.
Cc: Sylvain Munaut t...@246tnt.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc:
Hi,
On Wed, Apr 17, 2013 at 05:04:24PM +0530, Sourav Poddar wrote:
@@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops =
{
SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
On Thursday 18 April 2013 09:26 AM, Felipe Balbi wrote:
On Wed, Apr 17, 2013 at 05:04:23PM +0530, Sourav Poddar wrote:
Since uart_console definition is now moved to serial core
haeder file . Serial drivers need not define them.
Cc: Sylvain Munautt...@246tnt.com
Cc: Santosh
60 matches
Mail list logo
