Tony,
On Friday 08 February 2013 08:41 PM, Santosh Shilimkar wrote:
Commit bbd707ac {ARM: omap2: use machine specific hook for late init}
accidentally added two declarations for omap4430_init_late().
Remove the duplicate declaration.
Cc: Shawn Guo shawn@linaro.org
Cc: Tony Lindgren
2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:
On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger matthias@gmail.com
wrote:
Hi Benoit,
2012/12/12 Benoit Cousson b-cous...@ti.com:
Hi Matthias,
On 12/12/2012 04:33 PM, Matthias Brugger wrote:
This patch is a follow-up patch
Hi Matthias,
On 2/15/2013 10:35 AM, Matthias Brugger wrote:
2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:
On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger matthias@gmail.com
wrote:
Hi Benoit,
2012/12/12 Benoit Cousson b-cous...@ti.com:
Hi Matthias,
On 12/12/2012 04:33
On Thu, Feb 14, 2013 at 08:47:53PM +, Paul Walmsley wrote:
Regarding ioremap(), it seems reasonable for drivers to call ioremap(), as
long as the implementation of ioremap() can be overridden by the device's
bus. PCI device drivers already do this -- albeit in a PCI-specific way
--
On Thu, Feb 14, 2013 at 09:40:29PM +, Paul Walmsley wrote:
Hi,
On Thu, 14 Feb 2013, Paul Walmsley wrote:
So instead of something bus-specific like that, a better way would be to
use something like:
va = dev-bus-ioremap( ... );
va = dev-bus-iounmap( ... );
Something like
OMAP UART IP needs manual idle modes based on state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
This however breaks in case of device tree because of missing
idle handling.
The series tries to address the issue
Patches has been tested
OMAP UART IP needs manual idle modes based on state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
This however breaks in case of device tree because of missing
idle handling. With the provided flags, idle mode handling is transparently
UART IP idle handling now taken care by runtime pm apis so remove
the hackery from the driver.
Signed-off-by: Rajendra nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/serial.c | 31 ---
On Fri, Feb 15, 2013 at 05:38:26PM +0530, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
This however breaks in case of device tree because of missing
idle
On Friday 15 February 2013 06:20 PM, Felipe Balbi wrote:
On Fri, Feb 15, 2013 at 05:38:26PM +0530, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
This however
Hi,
On Fri, Feb 15, 2013 at 05:38:55PM +0530, Santosh Shilimkar wrote:
UART IP idle handling now taken care by runtime pm apis so remove
the hackery from the driver.
Signed-off-by: Rajendra nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Hi,
On Friday 15 February 2013 05:36 PM, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
This however breaks in case of device tree because of missing
idle
On Fri, Feb 15, 2013 at 06:33:58PM +0530, a0131647 wrote:
Hi,
On Friday 15 February 2013 05:36 PM, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
This
On Fri, Feb 15, 2013 at 03:07:45PM +0200, Felipe Balbi wrote:
On Fri, Feb 15, 2013 at 06:33:58PM +0530, a0131647 wrote:
Hi,
On Friday 15 February 2013 05:36 PM, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on state of the
IP. Currently this is handled by the driver
On Friday 15 February 2013 06:27 PM, Felipe Balbi wrote:
Hi,
On Fri, Feb 15, 2013 at 05:38:55PM +0530, Santosh Shilimkar wrote:
UART IP idle handling now taken care by runtime pm apis so remove
the hackery from the driver.
Signed-off-by: Rajendra nayak rna...@ti.com
Signed-off-by: Santosh
Russell,
On Friday 15 February 2013 03:46 PM, Russell King - ARM Linux wrote:
On Thu, Feb 14, 2013 at 08:47:53PM +, Paul Walmsley wrote:
[..]
So instead of something bus-specific like that, a better way would be to
use something like:
va = dev-bus-ioremap( ... );
va =
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller() hook ? This can allow
us to avoid the dual ioremap() issue discussed here if the hook
maintains the list of mapped ios.
I was even thinking of having such intelligence within the
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller() hook ? This can allow
us to avoid the dual ioremap() issue discussed here if the hook
maintains the list of
Hi,
On Fri, Feb 15, 2013 at 06:49:20PM +0530, Santosh Shilimkar wrote:
@@ -279,8 +259,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
- serial_omap_set_forceidle(up);
-
pm_runtime_mark_last_busy(up-dev);
Hi,
On Friday 15 February 2013 06:38 PM, Felipe Balbi wrote:
On Fri, Feb 15, 2013 at 03:07:45PM +0200, Felipe Balbi wrote:
On Fri, Feb 15, 2013 at 06:33:58PM +0530, a0131647 wrote:
Hi,
On Friday 15 February 2013 05:36 PM, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on
On Friday 15 February 2013 07:04 PM, Felipe Balbi wrote:
Hi,
On Fri, Feb 15, 2013 at 06:49:20PM +0530, Santosh Shilimkar wrote:
@@ -279,8 +259,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
-
Hi,
On Friday 15 February 2013 07:13 PM, Santosh Shilimkar wrote:
On Friday 15 February 2013 07:04 PM, Felipe Balbi wrote:
Hi,
On Fri, Feb 15, 2013 at 06:49:20PM +0530, Santosh Shilimkar wrote:
@@ -279,8 +259,6 @@ static void serial_omap_stop_tx(struct
uart_port *port)
On Friday 15 February 2013 07:12 PM, a0131647 wrote:
Hi,
On Friday 15 February 2013 06:38 PM, Felipe Balbi wrote:
On Fri, Feb 15, 2013 at 03:07:45PM +0200, Felipe Balbi wrote:
On Fri, Feb 15, 2013 at 06:33:58PM +0530, a0131647 wrote:
Hi,
On Friday 15 February 2013 05:36 PM, Santosh Shilimkar
Hi Felipe,
Felipe Balbi ba...@ti.com writes:
Eventually, we need to be able to remove
ti,hwmods DT attribute (or at a minimum
ignore it).
For new platforms, this patch could enable
the transition by not relying on ti,hwmods
to have functioning PM and Idle implementation.
Notice that
Felipe Balbi ba...@ti.com writes:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own SYSCONFIG
register.
Remove that relyance on hwmod by moving SYSCONFIG
handling to
Roger Quadros rog...@ti.com writes:
Hi Kevin,
On 02/15/2013 12:50 AM, Kevin Hilman wrote:
Felipe, Roger,
Using Tony's current master branch, and enabling EHCI support, I see
the clock framework spitting loudly about the EHCI driver (full boot log
below.) The same thing happens on
2013/2/1 Tony Lindgren t...@atomide.com:
Hi,
* Robert Nelson robertcnel...@gmail.com [130124 07:58]:
On Wed, Jan 23, 2013 at 12:50 PM, Matthias Brugger
matthias@gmail.com wrote:
This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot
Hi,
On Fri, Feb 15, 2013 at 07:40:04AM -0800, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own SYSCONFIG
On Fri, Feb 15, 2013 at 07:54:47AM -0800, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Hi Kevin,
On 02/15/2013 12:50 AM, Kevin Hilman wrote:
Felipe, Roger,
Using Tony's current master branch, and enabling EHCI support, I see
the clock framework spitting loudly about
Hi Kevin,
On Fri, Feb 15, 2013 at 07:28:22AM -0800, Kevin Hilman wrote:
@@ -796,13 +796,18 @@ static int __init omap_early_device_register(struct
platform_device *pdev)
static int _od_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
Hi,
On Tue, Feb 12, 2013 at 8:48 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
Currently gpmc_cs_reserved() return value is somewhat inconsistent,
returning a negative value on an error condition, a positive value
if the chip select is reserved and zero if it's available.
Fix
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller() hook ? This can allow
us to avoid the dual
Hi,
On Fri, Feb 15, 2013 at 08:30:32AM -0800, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of
Hello,
I'd like to know which are the current constraints
preventing us from moving OMAP's GPMC memory controller driver
from mach-omap2/ to drivers/memory-controller.
I imagine one of the biggest issues is GPMC's dependency on
hwmod code. Can anyone shed some light on how to handle this?
Is
Hi Anil,
On Fri, Feb 15, 2013 at 09:49:21PM +0530, Anil Kumar wrote:
Hi,
On Tue, Feb 12, 2013 at 8:48 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
Currently gpmc_cs_reserved() return value is somewhat inconsistent,
returning a negative value on an error condition, a
Hi,
On Fri, Feb 15, 2013 at 10:31 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
Hi Anil,
On Fri, Feb 15, 2013 at 09:49:21PM +0530, Anil Kumar wrote:
Hi,
On Tue, Feb 12, 2013 at 8:48 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
Currently gpmc_cs_reserved()
Hi,
On Fri, 15 Feb 2013, Ezequiel Garcia wrote:
I imagine one of the biggest issues is GPMC's dependency on
hwmod code. Can anyone shed some light on how to handle this?
What dependency is this? I'm not aware of any GPMC dependency to hwmod;
there shouldn't be any.
- Paul
--
To
From: Mugunthan V N mugunthan...@ti.com
Date: Thu, 14 Feb 2013 23:56:46 +0530
+enum {
+ CPDMA_EOI_RX_THRESH = 0,
+ CPDMA_EOI_RX,
+ CPDMA_EOI_TX,
+ CPDMA_EOI_MISC,
+};
Do not use enumerations for hardware register values, which must be
exact, otherwise you are potentially
Also please indicate, clearly, what tree your patch is targetted at.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/15/2013 01:53 PM, Paul Walmsley wrote:
Hi,
On Fri, 15 Feb 2013, Ezequiel Garcia wrote:
I imagine one of the biggest issues is GPMC's dependency on
hwmod code. Can anyone shed some light on how to handle this?
What dependency is this? I'm not aware of any GPMC dependency to
On Fri, 2013-02-15 at 15:05 -0500, David Miller wrote:
From: Mugunthan V N mugunthan...@ti.com
Date: Thu, 14 Feb 2013 23:56:46 +0530
+enum {
+ CPDMA_EOI_RX_THRESH = 0,
+ CPDMA_EOI_RX,
+ CPDMA_EOI_TX,
+ CPDMA_EOI_MISC,
+};
Do not use enumerations for hardware
From: Joe Perches j...@perches.com
Date: Fri, 15 Feb 2013 12:18:59 -0800
On Fri, 2013-02-15 at 15:05 -0500, David Miller wrote:
From: Mugunthan V N mugunthan...@ti.com
Date: Thu, 14 Feb 2013 23:56:46 +0530
+enum {
+ CPDMA_EOI_RX_THRESH = 0,
+ CPDMA_EOI_RX,
+ CPDMA_EOI_TX,
On Friday 15 February 2013 09:10 PM, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own SYSCONFIG
register.
Remove that
On Friday 15 February 2013 10:00 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of
On Fri, 15 Feb 2013, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller()
On Saturday 16 February 2013 11:06 AM, Nicolas Pitre wrote:
On Fri, 15 Feb 2013, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar
On Friday 15 February 2013 10:12 PM, Felipe Balbi wrote:
Hi,
On Fri, Feb 15, 2013 at 08:30:32AM -0800, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM
DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.
This patch adds the basic DT support for devkit8000. At this time, Information
of twl4030 (PMIC),
Add the needed sections to enable audio support on
Devkit8000 when booted with DT blob.
Signed-off-by: Anil Kumar anilk...@gmail.com
---
This patch is based on top of kernel 3.8-rc5 and
the following patches.
Peter Ujfalusi:-
ASoC: twl4030: Correct the support for Voice port
ASoC: twl4030:
49 matches
Mail list logo
