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 Munaut
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Raj
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 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
> Cc: Santosh Shilimkar
> Cc: Felipe Balbi
> Cc: Rajendra nayak
> Signed-off-by: Sourav Podda
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
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 4de2a
* Tomi Valkeinen [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:
> >>
> >> git://gitorious.org/linux-om
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 th
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
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
> ---
> arch/arm/boot/dts/omap5.dtsi
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 indicat
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
---
arch/arm/boot/dts/omap5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ar
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]
http://git.kernel.org/cg
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 do
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 a
Support for OMAP5 is added to the omap_dsp_ctrl_write_boot_addr()
to enable the DSP boot.
Signed-off-by: Suman Anna
---
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 2adb268..31e0dfe 100644
--
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
---
arch/arm/boot/dts/omap4.dtsi | 8
arch/a
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 Tr
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
---
Changes since v1 (suggested by Jon Hunter):
- Split the search for GPMC
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
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 a
Include bandgap devices for OMAP4460 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/b
This patch add the bandgap entry for OMAP4430 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
a
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
Cc: Tony Lindgren
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valen
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
---
arch/arm/boot/dts
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 Benoit's
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
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
---
arch/arm/boot/dts/omap4-panda-es.dts | 33 +
arch/arm/boot/dts/omap4-panda.
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
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 Tr
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 t
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) \
* Igor Grinberg [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 wrote:
> * Roger Quadros [130415 05:44]:
> > On 04/15/2013 03:35 P
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
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
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter wrote:
>
> On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
>> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter wrote:
>>>
>>> On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
>>>
>>> ...
>>>
There are so many patches flying around in this
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() direct
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 cont
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 Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter wrote:
>
> On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
>> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter wrote:
>>>
>>> On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
>>>
>>> ...
>>>
There are so many patches flying around in this
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
> Signed-off-by: Roger Quadros
> ---
> drivers/usb/host/ehci-omap.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --gi
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 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter 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...
>>
>>
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))
>
> w
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter 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 solu
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
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 wrote:
* Roger Quadros [130415 05:44]:
> On 04/15/2013 03:35 PM, Roger Quadros wrote:
>> Provide RESET
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 ether
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
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 automati
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
Move "uart_console" definition to serial core header file, so that it can be
used by serial drivers.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
---
drivers/tty/serial/serial_core.c |6 --
include/linux/serial_core.h |6 ++
2 fil
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
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 "uart_console" definition is now moved to serial core
haeder file . Serial drivers need not define them.
Cc: Sylvain Munaut
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
---
drivers/tty/serial/mpc52xx_uart.c | 10 --
1 files changed, 0
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 GP
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 wrote:
>>> * Roger Quadros [130415 05:44]:
On 04/15/2013 03:35 PM, Roger Quadros wrote:
> Provide RESET and Power regulators for the USB PHY,
> the
As the USB PHY layer never returns NULL we don't need
to check for that condition.
CC: Alan Stern
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
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 th
On 04/17/13 04:30, Robert Nelson wrote:
> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren wrote:
>> * Roger Quadros [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 device.
Al
On Wed, Apr 17, 2013 at 4:00 AM, Jon Hunter wrote:
>
> On 04/16/2013 07:41 PM, Javier Martinez Canillas wrote:
>> On Wed, Apr 17, 2013 at 1:14 AM, 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
60 matches
Mail list logo
